EKS Anywhere で etcdadm コントローラーの問題をトラブルシューティングする方法を教えてください。

所要時間2分

ETCD のブートストラップ障害問題のトラブルシューティングの手がかりを探して、etcdadm ポッドのログを確認したいと考えています。

簡単な説明

Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere ノードでブートストラップ障害が発生した場合は、etcdadm ポッドのログを確認してください。また、スタック型 etcd クラスター用に作成した etcd ポッドのログも確認してください。

さらにデバッグするには、etcd 仮想マシン (VM) のいずれかにログインします。ブートストラップ障害が発生する前に etcd VM を作成していなかった場合、その VM を使用してデバッグすることはできません。

解決方法

etcdadm ポッドのログを確認する

注: 次のコマンドでは、SUFFIX をブートストラッププロバイダーのサフィックスに置き換えます。KUBECONFIG_FILE を実際の kubeconfig ファイルの場所に置き換えます。

クラスターを作成したら、ローカルディレクトリに生成された KUBECONFIG ファイルで使用できます。

KUBECONFIG=${PWD}/${CLUSTER_NAME}/${CLUSTER_NAME}-eks-a-cluster.kubeconfig

etcdadm-bootstrap-provider-controller のログを確認するには、次のコマンドを実行します。

kubectl -n etcdadm-bootstrap-provider-system logs etcdadm-bootstrap-provider-controller-SUFFIX  
    --kubeconfig=KUBECONFIG_FILE

etcdadm-controller-controller-manager のログを確認するには、次のコマンドを実行します。

kubectl -n etcdadm-controller-system logs etcdadm-controller-controller-manager-SUFFIX --kubeconfig=KUBECONFIG_FILE

スタック型 etcd のログを確認する

スタック型 etcd クラスター用のポッドを作成した場合は、次のコマンドを実行してそれらのポッドのログを確認します。

kubectl logs -n kube-system etcd-$CONTROL_PLANE_VM_IP --kubeconfig=KUBECONFIG_FILE

**注:**KUBECONFIG_FILE を実際の kubec ファイルの場所に置き換えます。

VM ログを確認する

kubectl クライアントを使用してログを確認したら、VM でログを確認することもできます。

VM のコントロールプレーンにログインします。

ssh -i $PRIV_KEY ec2-user@$CONTROL_PLANE_VM_IP

注: PRIV_KEY を自分のプライベートキーに置き換えます。CONTROL_PLANE_VM_IP をコントロールプレーンの VM の IP アドレスに置き換えます。

Bottlerocket オペレーティングシステム (OS) の場合、 BottleRocket OS 上で動作するノードのルートシェルを取得するには、sudo sheltie コマンドを実行します。
etcd VM にログインすると、以下の場所でその他の関連コンテナのログを確認できます。

cd /var/log/containers

非スタック型 etcd または外部 etcd のログを確認する

非スタック型 etcd または外部 etcd の場合は、作成した etcd VM にログインします。

etcd VM にログインするには、次のコマンドを実行します。

ssh -i $PRIV_KEY ec2-user@$ETCD_VM_IP

注: PRIV_KEY を自分のプライベートキーに置き換えます。ETCD_VM_IP を VM の IP アドレスに置き換えます。

Bottlerocket オペレーティングシステム (OS) の場合、 BottleRocket OS 上で動作するノードのルートシェルを取得するには、sudo sheltie コマンドを実行します。
etcd VM にログインすると、以下の場所でその他の関連コンテナのログを確認できます。

cd /var/log/containers  
bash-5.1# ls -lrt  
total 4  
lrwxrwxrwx. 1 root root 90 Apr 11 16:38 etcd-mgmt-etcd-4mt4g_kube-system_etcd-aa91be45434b920903e0630254cb5f319b86b50c56b87d8f992b0285272b93c4.log -> /var/log/pods/kube-system_etcd-mgmt-etcd-4mt4g_88b6dbc1be367b4ffc5a6bfab65e7376/etcd/0.log

ヘルスチェックを実行する

ETCD_CONTAINER_ID=$(ctr -n k8s.io c ls | grep -w "etcd-io" | cut -d " " -f1)  
ctr -n k8s.io t exec -t --exec-id etcd ${ETCD_CONTAINER_ID} etcdctl \  
     --cacert=/var/lib/etcd/pki/ca.crt \  
     --cert=/var/lib/etcd/pki/server.crt \  
     --key=/var/lib/etcd/pki/server.key \  
     endpoint health  

127.0.0.1:2379 is healthy: successfully committed proposal: took = 10.241212ms

エラーメッセージの例

ログで、ブートストラップの障害に関連するさまざまなエラーメッセージを確認できることがあります。最も一般的なエラーの例をいくつか次に示します。

「外部 ETCD の準備が整うのを待機しています。」

このエラーをトラブルシューティングするには、Amazon EKS Anywhere のトラブルシューティングドキュメントを参照してください。

「ETCD VM の kubelet がクラッシュしました。」

ETCD VM の作成後に、クラスターのプロビジョニングは続行されません。この問題は、次の kubelet エラーメッセージでも発生します。

「ContainerManager の起動に失敗しました」err= 「ノード割り当て可能な構成が無効です。リソース「エフェメラルストレージ」の割り当て可能値は {{1175812097 0} {<nil>} BinarySI}、容量は {{-155109377 0} {<nil>} BinarySI} です」

これは、ノード上のエフェメラルストレージに十分な空き容量がないことを示しています。各 Kubernetes ノードでは、kubelet のルートディレクトリ (デフォルトでは /var/lib/kubelet) とログディレクトリ (/var/log) はノードのルートパーティションにあります。

特定のファイルシステムの空きディスク容量を表示するには、次のコマンドを実行します。

"df -h"

すべてのファイルとそれぞれのサイズのリストを表示するには、次のコマンドを実行します。

"sudo du -d 3 /var/lib/"

ディスクの空き容量が足りない場合は、ノードをクリーンアップして空き容量を増やしてください。または、ノードのルートパーティションのストレージ容量を拡張してください。