本篇内容,对之前研究的内容做一些查漏补缺
在前面的内容中,组了一个2节点的K3S集群,后来我又给集群添加了3个节点,添加集群的过程参考第一篇文章中关于agent节点安装的部分,需要特别注意的是,每个节点别忘了通过命令yum install nfs-utils
安装nfs-utils
,参考第三篇文章。
目前节点状态为:
一个server节点(master),4个agent节点(slave-01、agent-04、agent-05、agent-06)
策略是给Deployment添加一个nodeName
的节点选择器。
这里需要注意的是,修改nodeName的同时,需要修改.spec.strategy.type==Recreate
,因为Deployment默认的更新策略为RollingUpdate
,它会先创建新的Pod,等新的Pod启动完成后,再让MySQL的service切换到新的Pod上,再把旧的Pod删除,这样保证平滑更新,但是我们MySQL的pvc的ReadWriteOnce模式的,默认的更新策略会导致新的Pod因为没有办法挂在数据卷而无法启动,导致迁移失败。改成Recreate后,就会先删除老的Pod,这样新的Pod就可以顺利创建。但是这也有问题,会导致MySQL服务中断。
这里我们并不能假设数据库一定会安装在master节点上,但是可以确定数据库对应的Pod有一个标签app:mysql
,所以使用Pod亲和性来来达到目的。关于节点亲和性的说明,可以参考官方文档。
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress
namespace: mysql
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
replicas: 2
template:
metadata:
labels:
app: wordpress
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- mysql
topologyKey: kubernetes.io/hostname
containers:
- name: wordpress
image: wordpress
目前,slave-01节点用的服务器是腾讯云送的一台一个月的4核4G轻量应用服务器,它一个月之后就到期了,所以需要在他到期的时候对它做删除操作。当然我们可以直接把他删了,但是我觉得还是值得研究一下,找一个优雅的方案。
有几个命令可以了解一下
kubectl cordon slave-01
将slave-01
节点标记为不可调度
kubectl uncordon slave-01
解锁节点slave-01
,标记为可调度
kubectl drain slave-01
将slave-01
上的Pod平滑的迁移到其它节点,如果提示错误的话根据提示加上对应参数
kubectl delete node slave-01
删除节点
在第三篇安装longhorn的内容中,提到通过以下方式longhorn dashboard的登陆密码:
USER=<USERNAME_HERE>; PASSWORD=<PASSWORD_HERE>; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> auth
kubectl -n longhorn-system create secret generic basic-auth --from-file=auth
这一段是官网安装文档中介绍的,具体到创建Secret,这里引用一下这个网页的内容:
username=admin
和 password=1f2d1e2e67df
到 Secret 中,请先将数据的值转化为 base64 编码,执行如下命令:echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
kubectl apply -f ./secret.yaml
有时,您并不想先将用户名和密码转换为 base64 编码之后再创建 Secret,则,您可以通过 定义 stringData 来达成,此时 stringData 中的取值部分将被 apiserver 自动进行 base64 编码之后再保存。
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
username: admin
password: 1f2d1e2e67df
下面来实操一下:在安装MySQL的时候,当时把root用户的密码直接写在了YAML文件里面了,这样其实不太好,最好还是把密码使用Secret的形式提供给Pod。
apiVersion: v1
kind: Secret
metadata:
name: mysql-root-password
type: Opaque
stringData:
password: root
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql2
labels:
app: mysql2
spec:
selector:
matchLabels:
app: mysql2
template:
metadata:
labels:
app: mysql2
spec:
containers:
- name: mysql2
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef::
name: mysql-root-password
key: password
ports:
- containerPort: 3306
name: mysql
另外,Secret也有好多类型(以下内容引用自K8S官方文档):
内置类型 | 用法 |
---|---|
| 用户定义的任意数据 |
| 服务账号令牌 |
|
|
|
|
| 用于基本身份认证的凭据 |
| 用于 SSH 身份认证的凭据 |
| 用于 TLS 客户端或者服务器端的数据 |
| 启动引导令牌数据 |
默认类型是Opaque,另外basic-auth这种类型,就是配置longhorn dashboard登录密码的类型。
kubernetes.io/basic-auth
类型用来存放用于基本身份认证所需的凭据信息。 使用这种 Secret 类型时,Secret 的 data
字段必须包含以下两个键:
username
: 用于身份认证的用户名;password
: 用于身份认证的密码或令牌。以上两个键的键值都是 base64 编码的字符串。 当然你也可以在创建 Secret 时使用 stringData
字段来提供明文形式的内容。 下面的 YAML 是基本身份认证 Secret 的一个示例清单:
apiVersion: v1
kind: Secret
metadata:
name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
username: admin # kubernetes.io/basic-auth 类型的必需字段
password: t0p-Secret # kubernetes.io/basic-auth 类型的必需字段
提供基本身份认证类型的 Secret 仅仅是出于方便性考虑。 你也可以使用 Opaque
类型来保存用于基本身份认证的凭据。 不过,使用预定义的、公开的 Secret 类型(kubernetes.io/basic-auth
) 有助于帮助其他用户理解 Secret 的目的,并且对其中存在的主键形成一种约定。 API 服务器会检查 Secret 配置中是否提供了所需要的主键。
搞K3S,少不了要写YAML文件,如果你和我一样使用VS Code的话,大家可以尝试一下kubernetes-templates
插件,让他帮我们生成模板,我们按照自己的需求删减、修改一下就行了,我觉得还挺方便的。
新建一个YAML文件,然后输入k8s
或者 kube
,选择需要的模板就可以了。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。