ESXi 参加タイムアウトにより、新しいコントロールプレーン VM でワークロードクラスタのアップグレードが停止、または変更が停止する。

Products

VMware vSphere Kubernetes Service

Issue/Introduction

免責事項：これは英文の記事「Workload Cluster Upgrade Stuck or Change Stuck at New Control Plane VM due to ESXi Join Time-outs」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

ワークロードクラスタのアップグレード、またはコントロールプレーンノードに対するワークロードクラスタ変更を開始した後、最新のコントロールプレーン VM は Running 状態になりますが、その後処理が進行しません。

Supervisor クラスタのコンテキストに接続した状態で、以下の事象が確認されます：

新しいコントロールプレーンマシンが Running 状態になります：
```
kubectl get machine -n <workload cluster namespace>
```
しかし、コントロールプレーンノードを管理する kubeadm control plane（KCP）オブジェクトでは、新しいコントロールプレーン VM が非正常（unhealthy）かつ利用不可（unavailable）と表示されます：
```
kubectl get kcp -n <workload cluster namespace>
```
クラスタを describe すると、新しいコントロールプレーンノードに対して Remediation Failed が表示されます：
```
kubectl describe cluster <workload cluster name> -n <workload cluster namespace>

Remediation Failed @ <new control plane VM>
```

ワークロードクラスタのコンテキストに接続した状態で、以下の事象が確認されます：

新しいコントロールプレーンノードはノード一覧に表示されますが、Roles が割り当てられておらず、ROLES <none> と表示されます：
```
kubectl get nodes

NAME                           STATUS      ROLES
<new control plane node>       Ready       <none>
```
新しいコントロールプレーンノード上で実行中の Pod は存在しません：
```
kubectl get pods -A -o wide | grep <new control plane node>
```

新しいコントロールプレーンノードに SSH 接続した状態で、以下の事象が確認されます：

新しいコントロールプレーンノード上で実行中のコンテナは存在しません：
```
crictl ps -a
```

cloud-init-output ログに以下のようなエラーが出力されており、新しいコントロールプレーンノードが ETCD クォーラムへの参加に失敗していることを示しています：

cat /var/log/cloud-init-output

adding etcd member as learner
retrying of unary invoker failed
error execution phase control-plane-join-etcd: error creating local static pod manifest file: etcdserver: Peer URLs already exists
kubeadm join phase control-plane-join etcd failed
fatal error, exiting
removing member from cluster status

promoting a learner as a voting member
retrying of unary invoker failed
etcdserver: can only promote a learner member which is in sync with leader
etcdserver: request timed out, waiting for the applied index took too long
etcdserver: can only promote a learner member 
error execution phase control-plane-join-etcd: error creating local static pod manifest file: etcdserver: can only promote a learner member
kubeadm join phase control-plane-join etcd failed
fatal error, exiting
removing member from cluster status

新しいコントロールプレーンノードは、ワークロードクラスタの VIP および、他のコントロールプレーンノード上で稼働している ETCD と kube-apiserver に正常に到達できます。

Environment

vSphere Supervisor

本問題は、ワークロードクラスタが Tanzu Mission Control（TMC）によって管理されているかどうかに関わらず発生する可能性があります。

Cause

新しいコントロールプレーンノードが作成されると、既存の正常なコントロールプレーンノードが構成する ETCD クォーラムに参加することで、ETCD データベース情報を取得します。

しかし、ETCD にはデフォルトで 2 分のタイムアウトが設定されており、新しいコントロールプレーンノードが 2 分以内に参加できない場合、システムはそのノードを失敗と判断します。

cloud-init-output ログのとおり、kubeadm join フェーズの etcd ステップが失敗した場合、クリーンアップ処理が開始され、新しいコントロールプレーンノード上のすべてのコンテナが削除されます。

再作成に備えて、失敗と判定された新しいコントロールプレーンノードからは、Kubernetes マニフェストおよび ETCD データが削除されます。

シングルコントロールプレーンノード構成のクラスタでは、失敗した新しいコントロールプレーンノードをシステムが正常に再作成できず、Remediation Failed の状態のまま Running 状態で残る場合があることが確認されています。

高いリソース使用率やネットワークの遅延により、ETCD の新メンバー参加プロセスでタイムアウトが発生する可能性があります。

Resolution

重要: アップグレードやローリング再デプロイを進める目的で、既存のコントロールプレーン VM を削除することは適切ではありません。これにより、データ損失やクラスタ全体のデータベースが破壊される可能性があります。

ETCD 参加時のタイムアウトの原因を特定し、解消する必要があります。

これは、ワークロードクラスタ内の他のコントロールプレーンノードにおける高いリソース使用率、または既存のコントロールプレーンノードと新しいコントロールプレーンノード間のネットワーク問題が原因である可能性があります。

ワークロードクラスタのコンテキストに接続した状態で、kubectl top を使用して高いリソース使用率を特定できます：

kubectl top pods -A --sort-by=memory

-o wide フラグを使用することで、Pod がどのノード上で実行されているかを確認することも可能です：

kubectl get pod <pod name> -n <pod namespace> -o wide

コントロールプレーンノード上で過剰なリソースを使用しているカスタマーアプリケーションの Pod がある場合、それらを一時的にスケールダウンすることで、次回のコントロールプレーンノード再作成時に ETCD へ正常に参加できるようになります。

ワークロードクラスタ内のコントロールプレーンノード間でネットワークテストを実施し、ETCD の参加プロセスが 2 分以上かかる原因となる遅延が存在しないかを確認してください。

kube-apiserver はポート 6443 を使用します。ETCD はポート 2379 および 2380 を使用します。
デフォルトでは、vSphere Supervisor VM では ping は無効化されています。

Additional Information

etcdctl による確認では、新しいコントロールプレーンノードが ETCD クォーラムへ正常に参加したように見える場合がありますが、前述のタイムアウト問題により、cloud-init-output では失敗として検知され、新しいノードが破棄されます。