潍坊建设局网站优秀网剧

事出因果

自己虚拟跑了一个 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

个人思路

1. 我的架构没有涉及到 keepalived 一类的高可用，也没有云主机的 SLB 做高可用，我这里需要先把 nginx 的 upstream 模块内需要下线的节点先置为 down
   • 我这边也不考虑替换证书的 apiserver 访问地址，还是延续我之前的 127.0.0.1:8443
     • 如果有更换 apiserver 访问地址的需求，需要用之前的 ca 根证书，重新生成相关的 kubeconfig 文件，并做替换
2. 修改 apiserver 访问的 etcd 地址，以及相关的 etcd 证书文件
3. 下线需要下线的 etcd 节点
   • 通过 etcdctl member remove 的方式，先将需要下线的 etcd 节点踢出集群
4. etcd 重启无异常后，重启 apiserver 节点

准备实践

当前 master 节点信息

节点 ip	节点角色	是否下线
172.72.0.95	master 节点	不下线
172.72.0.96	master 节点	下线 etcd 和 master 组件
172.72.0.97	master 节点	下线 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=kubernetesSubject Public Key Info:Public Key Algorithm: rsaEncryptionPublic-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=https://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 https://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 |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://172.72.0.95:2379 | 26c65c850c80d42d |  3.4.12 |  4.5 MB |     false |      false |       263 |     642041 |             642041 |        |
| https://172.72.0.96:2379 | 2ae7ff74540f0760 |  3.4.12 |  4.5 MB |      true |      false |       263 |     642041 |             642041 |        |
| https://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 https://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 https://172.72.0.95:2379 \
member list

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

+------------------+---------+-------------+--------------------------+--------------------------+------------+
|        ID        | STATUS  |    NAME     |        PEER ADDRS        |       CLIENT ADDRS       | IS LEARNER |
+------------------+---------+-------------+--------------------------+--------------------------+------------+
| 26c65c850c80d42d | started | 172.72.0.95 | https://172.72.0.95:2380 | https://172.72.0.95:2379 |      false |
| 2ae7ff74540f0760 | started | 172.72.0.96 | https://172.72.0.96:2380 | https://172.72.0.96:2379 |      false |
| 4785dde924d48108 | started | 172.72.0.97 | https://172.72.0.97:2380 | https://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 https://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 https://172.72.0.95:2379 \
member remove 2ae7ff74540f0760

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

+------------------+---------+-------------+--------------------------+--------------------------+------------+
|        ID        | STATUS  |    NAME     |        PEER ADDRS        |       CLIENT ADDRS       | IS LEARNER |
+------------------+---------+-------------+--------------------------+--------------------------+------------+
| 26c65c850c80d42d | started | 172.72.0.95 | https://172.72.0.95:2380 | https://172.72.0.95:2379 |      false |
+------------------+---------+-------------+--------------------------+--------------------------+------------+

停止下线节点 etcd 服务

systemctl disable kube-etcd --now

修改保留节点的 etcd 配置文件

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

--initial-cluster=172.72.0.95=https://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 https://172.72.0.95:2379 \
endpoint health

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

+--------------------------+--------+------------+-------+
|         ENDPOINT         | HEALTH |    TOOK    | ERROR |
+--------------------------+--------+------------+-------+
| https://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 节点缩容的实践就结束了