k8s 集群灾难恢复

环境准备:

192.168.244.11  k8s-company01-master01
192.168.244.12  k8s-company01-master02
192.168.244.13  k8s-company01-master03
192.168.244.15  k8s-company01-lb
192.168.244.14  k8s-company01-worker001

三台 master 宕掉两台或三台

在宕掉两台或三台 master 后集群已宕掉,worker 节点中的 pod 可以正常运行,这里考虑机器可以正常修复,并能正常启动。

这里模拟测试:

  • 停掉 192.168.244.12,192.168.244.13 两台 master 机器
  • 让 192.168.244.11 上的 etcd 正常工作
  • 待 192.168.244.12,192.168.244.13 启动后,恢复整个集群

停掉 12 和 13 机器,使集群无法工作

在关闭之前集群是正常的:

[root@k8s-company01-master01 ~]# kubectl get nodes
NAME                      STATUS   ROLES    AGE     VERSION
k8s-company01-master01    Ready    master   11m     v1.14.1
k8s-company01-master02    Ready    master   9m23s   v1.14.1
k8s-company01-master03    Ready    master   7m10s   v1.14.1
k8s-company01-worker001   Ready    <none>   13s     v1.14.1

关闭之后:

[root@k8s-company01-master01 ~]# kubectl get nodes
Unable to connect to the server: unexpected EOF

集群无法正常工作,etcd 也无法使用。

使 11 节点上的 etcd 以单节点集群的形式启动

集群中 etcd 读取的配置是 /etc/kubernetes/manifests/etcd.yaml 中的。
在其中添加两条命令,使其变成单节点集群的形式:

- command:
    - etcd
    - --advertise-client-urls=https://192.168.244.11:2379
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --client-cert-auth=true
    - --data-dir=/var/lib/etcd
    - --initial-advertise-peer-urls=https://192.168.244.11:2380
    - --initial-cluster=k8s-company01-master01=https://192.168.244.11:2380
    - --initial-cluster-state=new      ##新加 1
    - --force-new-cluster              ##新加 2
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --listen-client-urls=https://127.0.0.1:2379,https://192.168.244.11:2379
    - --listen-peer-urls=https://192.168.244.11:2380
    - --name=k8s-company01-master01
    - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
    - --peer-client-cert-auth=true
    - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --snapshot-count=10000
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

etcd 集群此时只有一个节点。而且有的 pod 是无法正常运行的,etcd 的另外两个节点都处于 CrashLoopBackOff 状态。

恢复 etcd 集群,使整个 k8s 集群恢复正常

启动 12 和 13 服务器。

在 11 服务器上添加 12 和 13 的 etcd 节点,使其组成一个集群,在添加之前,要先清掉 12 和 13 上 etcd 的数据:

cd /var/lib/etcd
rm -rf member/

添加 12 节点 (添加节点的操作,均在 11 上执行 ):

[root@k8s-company01-master01 ~]# ETCDCTL_API=3 etcdctl member add etcd-k8s-company01-master02 --peer-urls="https://192.168.244.12:2380" --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --cacert=/etc/kubernetes/pki/etcd/ca.crt
Member 9ada83de146cad81 added to cluster 7b96e402e17890a5

输出上面的内容,表示添加成功,此时还需要重启 12 的 kubelet 服务。

systemctl restart kubelet.service

集群已变成两个节点的。

继续添加 13 节点 (添加后重启 13 的 kubelet 服务):

[root@k8s-company01-master01 ~]# ETCDCTL_API=3 etcdctl member add etcd-k8s-company01-master03 --peer-urls="https://192.168.244.13:2380" --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --cacert=/etc/kubernetes/pki/etcd/ca.crt
Member efa2b7e4c407fb7a added to cluster 7b96e402e17890a5

etcd 集群已恢复正常。

集群恢复正常:

[root@k8s-company01-master01 ~]#  kubectl get node
NAME                      STATUS   ROLES    AGE   VERSION
k8s-company01-master01    Ready    master   33m   v1.14.1
k8s-company01-master02    Ready    master   31m   v1.14.1
k8s-company01-master03    Ready    master   29m   v1.14.1
k8s-company01-worker001   Ready    <none>   22m   v1.14.1

如有出现节点添加成功,但 etcd 集群仍为宕掉的状态,可以稍等,11 节点会自动将添加失败的节点踢出,然后重复添加即可。

猜你喜欢

转载自www.cnblogs.com/k8s/p/12163680.html