二进制k8s集群下线master组件流程分析和实践

文章目录 @[toc]事出因果环境介绍个人思路准备实践当前 master 节点信息切换 apiserver 访问流量查看 nginx 配置文件停止下线节点的 apiserver 服务 生成新的证书生成 etcd 新证书生成 apiserver 新证书 修改 apiserver 配置文件下线 etcd 节点查找当前 leader 节点etcd 数据快照etcd 节点下线停止下线节点 etcd 服务修改保留节点的 etcd 配置文件重启 etcd 服务 重启 apiserver 节点验证节点是否正常关闭下线节点其他 k8s master 组件 事出因果

自己虚拟跑了一个 3 master + 2 node 的 k8s 集群，因为当初验证部署脚本，验证完成后，就开始部署一些服务来验证环境可用性，目前的环境情况，其实也不需要 3 master 这样的架构，有点浪费电脑的资源，于是有了这样的一个想法

虽说虚拟机，不影响，只需要铲了重装就好，但是这样的习惯也并非好事情

咱要做一个优雅的人，要让他优雅的离场，毕竟也是功臣，怎能直接踹了她 [ k8s 这么可爱，一 jio 上去会哭很久的吧 ]

环境介绍

先介绍一下我的集群架构和情况

部署方式 - 二进制etcd 节点数量 - 3个k8s master 组件节点数量 - 3个k8s apiserver 是否开启高可用 - 使用 nginx 做反向代理，并使用 upstream 负载均衡到三个 apiserver 节点 使用 127.0.0.1 来访问本机 nginx 反向代理，因此所有 node 节点均有 nginx 个人思路 我的架构没有涉及到 keepalived 一类的高可用，也没有云主机的 SLB 做高可用，我这里需要先把 nginx 的 upstream 模块内需要下线的节点先置为 down 我这边也不考虑替换证书的 apiserver 访问地址，还是延续我之前的 127.0.0.1:8443 如果有更换 apiserver 访问地址的需求，需要用之前的 ca 根证书，重新生成相关的 kubeconfig 文件，并做替换 修改 apiserver 访问的 etcd 地址，以及相关的 etcd 证书文件下线需要下线的 etcd 节点 通过 etcdctl member remove 的方式，先将需要下线的 etcd 节点踢出集群 etcd 重启无异常后，重启 apiserver 节点 准备实践 当前 master 节点信息 节点 ip节点角色是否下线172.72.0.95master 节点不下线172.72.0.96master 节点下线 etcd 和 master 组件172.72.0.97master 节点下线 etcd 和 master 组件 切换 apiserver 访问流量

如上面所说，我这边需要把所有节点的 nginx 的配置做一个修改，将需要下线的节点置为 down

大家要按照自己实际的场景做处理，这里无法一一道来，整体思路就是将需要下线的节点踢出高可用的场景

以下的操作，仅代表个人环境，大家了解一个思路就好了，具体的实操，还是要以自己的实际环境为准 查看 nginx 配置文件

先看看 nginx 配置文件在哪

systemctl cat kube-nginx # /etc/systemd/system/kube-nginx.service [Unit] Description=kube-apiserver nginx proxy After=network.target After=network-online.target Wants=network-online.target [Service] Type=forking ExecStartPre=/approot/data/k8s/bin/nginx \ -c /approot/data/k8s/kube-nginx/kube-nginx.conf \ -p /approot/data/k8s/kube-nginx -t ExecStart=/approot/data/k8s/bin/nginx \ -c /approot/data/k8s/kube-nginx/kube-nginx.conf \ -p /approot/data/k8s/kube-nginx ExecReload=/approot/data/k8s/bin/nginx \ -c /approot/data/k8s/kube-nginx/kube-nginx.conf \ -p /approot/data/k8s/kube-nginx -s reload PrivateTmp=true Restart=always RestartSec=5 StartLimitInterval=0 LimitNOFILE=65536 [Install] WantedBy=multi-user.target

修改 nginx 配置文件

worker_processes 1; events { worker_connections 1024; } stream { upstream apiserver { hash $remote_addr consistent; server 172.72.0.95:6443 max_fails=3 fail_timeout=30s; server 172.72.0.96:6443 max_fails=3 fail_timeout=30s down; server 172.72.0.97:6443 max_fails=3 fail_timeout=30s down; } server { listen *:8443; proxy_connect_timeout 1s; proxy_pass apiserver; } }

验证配置文件，这里是为了美观，毕竟路径太长了

nginx_home='/approot/data/k8s/kube-nginx'

使用 -p 参数修改 prefix 路径，nginx 编译完，默认的 prefix 路径是编译的时候指定的路径，在这里使用会报错

nginx -p ${nginx_home} \ -c ${nginx_home}/kube-nginx.conf -t

返回如下结果，说明配置文件格式没有问题

nginx: the configuration file /approot/data/k8s/kube-nginx/kube-nginx.conf syntax is ok nginx: configuration file /approot/data/k8s/kube-nginx/kube-nginx.conf test is successful

重载 nginx，因为的 systemctl 配置了 reload 参数，如果没有配置，使用 nginx -s reload 也可以实现

reload 相比 restart 要优雅很多

systemctl reload kube-nginx

所有的节点，都按照上面的方式修改 nginx 的配置文件，实现 apiserver 流量的切换

停止下线节点的 apiserver 服务

既然已经把 apiserver 的访问转移到指定的节点了，那正常情况下，咱们停止了下线节点的 apiserver 服务，不会对集群造成影响（顺便把开机自启也关了）

systemctl disable kube-apiserver --now

此时，我们可以去不下线的节点执行 kubectl get node 验证是否正常能获取的到节点信息，没有问题就可以继续停止下一个下线节点的 apiserver 服务

生成新的证书

如果新的 csr json 文件找不到了，那就只能通过 openssl 校验证书，获取对应的信息，重新生成证书

csr json 文件模板 { "CN": "", "hosts": [ "127.0.0.1", "kubernetes", "kubernetes.default", "kubernetes.default.svc", "kubernetes.default.svc.cluster", "kubernetes.default.svc.cluster.local" ], "key": { "algo": "", "size": }, "names": [ { "C": "", "ST": "", "L": "", "O": "", "OU": "" } ] }

从原有的 pem 文件获取 csr json 文件的内容 [这里就举个例子，pem 文件名称以自己实际的为准]

openssl x509 -noout -text -in kubernetes.pem | egrep -i 'issuer|dns|public' CN 、 C 、 ST 、 L 、 O 、 OU 、 CN 都在 Issuer 字段可以获取的到hosts 在 DNS 字段可以获取的到key 在 Public Key Algorithm 和 Public-Key 里面可以获取得到，这里对应的 algo 是 rsa ，size 是 2048 Issuer: C=CN, ST=ShangHai, L=ShangHai, O=k8s, OU=System, CN=kubernetes Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster, DNS:kubernetes.default.svc.cluster.local, IP Address:172.72.0.95, IP Address:172.72.0.96, IP Address:172.72.0.97, IP Address:127.0.0.1, IP Address:10.254.0.1 生成 etcd 新证书

配置 csr-json 文件，去除需要下线节点的 ip

{ "CN": "etcd", "hosts": [ "172.72.0.95", "127.0.0.1" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "ShangHai", "L": "ShangHai", "O": "k8s", "OU": "System" } ] }

生成新的 pem 文件

cfssl gencert -ca=ca.pem \ -ca-key=ca-key.pem \ -config=ca-config.json \ -profile=kubernetes etcd-csr.json | cfssljson -bare etcd

备份老的 etcd 证书，注意，这里的路径也要以自己的实际路径为准

mv /etc/kubernetes/ssl/etcd.pem{,-bak-$(date +%FT%T%z)} mv /etc/kubernetes/ssl/etcd-key.pem{,-bak-$(date +%FT%T%z)}

复制新的 etcd 证书到 etcd 证书路径，这里先不着急重启服务，因为还没将要下线的节点踢出集群

生成 apiserver 新证书

配置 csr-json 文件，去除需要下线节点的 ip

{ "CN": "kubernetes", "hosts": [ "172.72.0.95", "127.0.0.1", "10.254.0.1", "kubernetes", "kubernetes.default", "kubernetes.default.svc", "kubernetes.default.svc.cluster", "kubernetes.default.svc.cluster.local" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "ShangHai", "L": "ShangHai", "O": "k8s", "OU": "System" } ] }

生成新的 pem 文件

cfssl gencert -ca=ca.pem \ -ca-key=ca-key.pem \ -config=ca-config.json \ -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes

备份老的 apiserver 证书，注意，这里的路径也要以自己的实际路径为准

mv /etc/kubernetes/ssl/kubernetes.pem{,-bak-$(date +%FT%T%z)} mv /etc/kubernetes/ssl/kubernetes-key.pem{,-bak-$(date +%FT%T%z)}

复制新的 apiserver 证书到 apiserver 证书路径，这里先不着急重启服务，因为还没修改 etcd 集群的访问地址

修改 apiserver 配置文件

我的二进制部署，是将 apiserver 启动参数写进 systemctl 管理的 service 文件内的，没有单独的去引用，这里需要备份一下 service 文件

cp /etc/systemd/system/kube-apiserver.service{,-bak-$(date +%FT%T%z)}

修改 etcd 的地址，只保留需要的节点，同样先不重启 apiserver 服务

--etcd-servers= 172.72.0.95:2379 下线 etcd 节点 查找当前 leader 节点

找 leader 节点是因为 leader 节点的数据是最新的，操作之前，需要先快照一下 etcd 的数据，出了问题还能恢复回去

这里也是用的新生成的 etcd 证书来查询的

etcdctl -w table \ --cert /etc/kubernetes/ssl/etcd.pem \ --key /etc/kubernetes/ssl/etcd-key.pem \ --cacert /etc/kubernetes/ssl/ca.pem \ --endpoints 172.72.0.95:2379 \ endpoint status --cluster

这里可以看到，172.72.0.96 节点是 leader

+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS | +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | 172.72.0.95:2379 | 26c65c850c80d42d | 3.4.12 | 4.5 MB | false | false | 263 | 642041 | 642041 | | | 172.72.0.96:2379 | 2ae7ff74540f0760 | 3.4.12 | 4.5 MB | true | false | 263 | 642041 | 642041 | | | 172.72.0.97:2379 | 4785dde924d48108 | 3.4.12 | 4.6 MB | false | false | 263 | 642041 | 642041 | | +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ etcd 数据快照

这里的 --endpoints 使用 172.72.0.96

etcdctl -w table \ --cert /etc/kubernetes/ssl/etcd.pem \ --key /etc/kubernetes/ssl/etcd-key.pem \ --cacert /etc/kubernetes/ssl/ca.pem \ --endpoints 172.72.0.96:2379 \ snapshot save 172.72.0.95-etcd-snapshot.db etcd 节点下线

查看节点信息

etcdctl -w table \ --cert /etc/kubernetes/ssl/etcd.pem \ --key /etc/kubernetes/ssl/etcd-key.pem \ --cacert /etc/kubernetes/ssl/ca.pem \ --endpoints 172.72.0.95:2379 \ member list

返回的结果如下，后面开始下线对应的节点

+------------------+---------+-------------+--------------------------+--------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+-------------+--------------------------+--------------------------+------------+ | 26c65c850c80d42d | started | 172.72.0.95 | 172.72.0.95:2380 | 172.72.0.95:2379 | false | | 2ae7ff74540f0760 | started | 172.72.0.96 | 172.72.0.96:2380 | 172.72.0.96:2379 | false | | 4785dde924d48108 | started | 172.72.0.97 | 172.72.0.97:2380 | 172.72.0.97:2379 | false | +------------------+---------+-------------+--------------------------+--------------------------+------------+

下线 172.72.0.97 节点，预期会返回类似如下的输出 Member 4785dde924d48108 removed from cluster 5957c47fd14d3795

etcdctl \ --cert /etc/kubernetes/ssl/etcd.pem \ --key /etc/kubernetes/ssl/etcd-key.pem \ --cacert /etc/kubernetes/ssl/ca.pem \ --endpoints 172.72.0.95:2379 \ member remove 4785dde924d48108

下线 172.72.0.96 节点，预期会返回类似如下的输出 Member 2ae7ff74540f0760 removed from cluster 5957c47fd14d3795

etcdctl \ --cert /etc/kubernetes/ssl/etcd.pem \ --key /etc/kubernetes/ssl/etcd-key.pem \ --cacert /etc/kubernetes/ssl/ca.pem \ --endpoints 172.72.0.95:2379 \ member remove 2ae7ff74540f0760

再次查看 etcd 节点信息，就只剩下当前需要保留的节点了

+------------------+---------+-------------+--------------------------+--------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+-------------+--------------------------+--------------------------+------------+ | 26c65c850c80d42d | started | 172.72.0.95 | 172.72.0.95:2380 | 172.72.0.95:2379 | false | +------------------+---------+-------------+--------------------------+--------------------------+------------+ 停止下线节点 etcd 服务 systemctl disable kube-etcd --now 修改保留节点的 etcd 配置文件

这里只保留当前节点的信息

--initial-cluster=172.72.0.95= 172.72.0.95:2380

重载一下 service 文件

systemctl daemon-reload 重启 etcd 服务

这里我们重启一下当前保留的 etcd 节点，确保 etcd 能正常工作

systemctl restart kube-etcd

查看集群健康状态

etcdctl -w table \ --cert /etc/kubernetes/ssl/etcd.pem \ --key /etc/kubernetes/ssl/etcd-key.pem \ --cacert /etc/kubernetes/ssl/ca.pem \ --endpoints 172.72.0.95:2379 \ endpoint health

返回类似如下的信息，说明 etcd 服务是正常的

+--------------------------+--------+------------+-------+ | ENDPOINT | HEALTH | TOOK | ERROR | +--------------------------+--------+------------+-------+ | 172.72.0.95:2379 | true | 5.818866ms | | +--------------------------+--------+------------+-------+ 重启 apiserver 节点 systemctl restart kube-apiserver 验证节点是否正常

查看 k8s 节点信息是否正常加载

kubectl get node

删一个带有副本控制集的 pod，验证是否会重启 pod

kubectl delete pod -n monitor node-exporter-jlxxl 关闭下线节点其他 k8s master 组件

要记得把开机自启也关闭了

systemctl disable kube-controller-manager kube-scheduler --now

到此，关于 master 节点缩容的实践就结束了