☰

マスターノードの1つを削除した後、etcdが不健全になったので、修正方法を探しています

tag-icon • tag-icon kubernetes
マスターノードの1つを削除した後、etcdが不健全になったので、修正方法を探しています

kubeadm を使用して Kubernetes クラスターをセットアップし、マスター ノードを 3 つ持っています。ある日、マスター ノードの 1 つを廃止する必要が生じ (インフラストラクチャの移行)、'kubectl delete node ***' を実行してそのマスター ノードを削除しました。数日前まで、新しい VM をインストールし、それをマスターとしてクラスターに再度参加させようとしましたが、etcd のヘルス状態をチェックする際に失敗しました。

[check-etcd] Checking that the etcd cluster is healthy
error execution phase check-etcd: error syncing endpoints with etc: dial tcp 10.233.42.22:2379: connect: no route to host

次に、残りの etcd ポッドのログを確認すると、マスター ノードが削除されてから etcd が正常でないことが報告され始めているようです。

rafthttp: health check for peer 55ab807fd1dc1d4 could not connect: dial tcp 10.233.42.22:2380: i/o timeout

kubectl logs etcd-ne1-prd-lnxstgivt01.ubisoft.org -n kube-system | grep 'could not connect: dial tcp 10.233.42.22:2380: i/o timeout' | awk '{ print $1 }' | uniq
2019-08-12
2019-08-13
2019-08-14
2019-08-15
2019-08-16
2019-08-17
2019-08-18
2019-08-19
2019-08-20
2019-08-21
2019-08-22

上記からわかるように、エラーは数日間継続的に報告されています。これは、etcd が削除済みのノードをまだ記憶しているためであると考えられます。もしそうであれば、不健全な状態を回避するために、etcd でもそのノードを完全に削除したいと思います。

この問題に遭遇したことがあり、解決策を見つけたかどうかはわかりません。

ありがとう。

答え1

ついに解決策を見つけました。

まず、etcd ポッドのいずれかに接続して、etcd クラスターに残っている削除されたマスター ノードを削除し、クラスターが最終的に正常であることを確認する必要があります。

**List current nodes to get failed node id**
/ # etcdctl --endpoint=https://10.0.1.31:2379 --ca-file=/etc/kubernetes/pki/etcd/ca.crt --cert-file=/etc/kubernetes/pki/etcd/peer.crt --key-file=/etc/kubernetes/pki/etcd/peer.key member list
55ab807fd1dc1d4: name=ae1-prd-lnxstgivt01.ubisoft.org peerURLs=https://10.233.42.22:2380 clientURLs=https://10.233.42.22:2379 isLeader=false
3da60ac5e6f29b0e: name=pdc-prd-lnxstginvt01.ubisoft.org peerURLs=https://10.0.1.31:2380 clientURLs=https://10.0.1.31:2379 isLeader=false
d13a6c20fbb32f2d: name=ne1-prd-lnxstgivt01.ubisoft.org peerURLs=https://10.136.66.170:2380 clientURLs=https://10.136.66.170:2379 isLeader=true

**Remove the dead one**
/ # etcdctl --endpoint=https://10.0.1.31:2379 --ca-file=/etc/kubernetes/pki/etcd/ca.crt --cert-file=/etc/kubernetes/pki/etcd/peer.crt --key-file=/etc/kubernetes/pki/etcd/peer.key member remove 55ab807fd1dc1d4
Removed member 55ab807fd1dc1d4 from cluster

**Verify it is removed**
/ # etcdctl --endpoint=https://10.0.1.31:2379 --ca-file=/etc/kubernetes/pki/etcd/ca.crt --cert-file=/etc/kubernetes/pki/etcd/peer.crt --key-file=/etc/kubernetes/pki/etcd/peer.key member list
3da60ac5e6f29b0e: name=pdc-prd-lnxstginvt01.ubisoft.org peerURLs=https://10.0.1.31:2380 clientURLs=https://10.0.1.31:2379 isLeader=false
d13a6c20fbb32f2d: name=ne1-prd-lnxstgivt01.ubisoft.org peerURLs=https://10.136.66.170:2380 clientURLs=https://10.136.66.170:2379 isLeader=true

次に、kube-public 名前空間に kubeadm-config という configmap があり、削除されたマスター ノードを API エンドポイントの 1 つとして記憶しています。これにより、etcd クラスターのヘルス状態を確認する段階で新しいマスター ノードに参加できなくなります。これは、kubeadm がその configmap を読み取り、削除されたものをチェック対象の etcd ノードとして取得するためです。そのため、その名前空間を yaml ファイルにエクスポートし、ファイルを編集して再度適用し、API エンドポイント リストから削除します。

kubectl get configmap kubeadm-config -n kube-system -o yaml
apiVersion: v1
data:
  …
  ClusterStatus: |
    apiEndpoints:
      ae1-prd-lnxstgivt01.ubisoft.org:
        advertiseAddress: 10.233.42.22
        bindPort: 6443
      ne1-prd-lnxstgivt01.ubisoft.org:
        advertiseAddress: 10.136.66.170
        bindPort: 6443
      pdc-prd-lnxstginvt01.ubisoft.org:
        advertiseAddress: 10.0.1.31
        bindPort: 6443
    apiVersion: kubeadm.k8s.io/v1beta1
    kind: ClusterStatus
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: …

テスト済みバージョン: 1.14.3

関連情報