ノードのステータスを NotReady または Unknown ステータスから Ready ステータスに変更するにはどうすればよいですか?

NotReady または Unknown ステータスのノードでポッドをスケジュールすることはできません。ポッドをスケジュールできるのは Ready ステータスのノードのみです。

次の解決方法は、NotReady または Unknown ステータスのノードに対応するものです。

ノードのステータスが MemoryPressure、DiskPressure、または PIDPressure になっている場合、そのノードで追加のポッドをスケジュールできるようにリソースを管理する必要があります。ノードのステータスが NetworkUnavailable の場合は、ノードのネットワークを正しく設定する必要があります。詳細については、「Node Status」を参照してください。

注意 : ポッドエビクションとリソース制限の管理に関する情報については、「Configure Out of Resource Handling」および「Managing Compute Resources for Containers」を参照してください。

aws-node ポッドと kube-proxy ポッドをチェックして、ノードが NotReady ステータスになっている理由を確認する

スケジュールされるポッドのために NotReady ステータスのノードを使用することはできません。

1.    次のコマンドを実行して、aws-node ポッドと kube-proxy ポッドのステータスをチェックします。

$ kubectl get pods -n kube-system -o wide

2.    ステップ 1 の出力を確認して、aws-node ポッドと kube-proxy ポッドのステータスをチェックします。

注意: aws-node ポッドと kube-proxy ポッドは DaemonSet によって管理されるため、クラスター内の各ノードで 1 つの aws-node ポッドと kube-proxy ポッドが実行されている必要があります。aws-node ポッドまたは kube-proxy ポッドがリストされていない場合は、ステップ 4 に進んでください。

ノードのステータスが normal の場合は、aws-node ポッドと kube-proxy ポッドのステータスが Running になっているはずです。例:

$ kubectl get pods -n kube-system -o wide
NAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
aws-node-qvqr2                   1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
kube-proxy-292b4                 1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal

ポッドのいずれかが Running 以外のステータスになっている場合は、次のコマンドを実行します。

$ kubectl describe pod yourPodName -n kube-system

3.    次のコマンドを実行して、aws-node ポッドおよび kube-proxy ポッドのログから追加情報を取得します。

$ kubectl logs yourPodName -n kube-system

describe 出力からのログとイベントは、ポッドが Running ステータスではない理由を示すことができます。ノードのステータスが Ready に変更されるには、そのノードで aws-node ポッドと kube-proxy ポッドの両方が Running ステータスになっている必要があります。

注意: 上記の例にあるように、ポッドの名前は aws-node-qvqr2 および kube-proxy-292b4 とは異なる場合があります。

4.    ステップ 1 のコマンドを実行しても aws-node ポッドおよび kube-proxy ポッドがリストされない場合は、次のコマンドを実行します。

$ kubectl describe daemonset aws-node -n kube-system

$ kubectl describe daemonset kube-proxy -n kube-system

上記のコマンドからの出力で、ポッドを起動できない理由を調べます。

ヒント: Amazon EKS コントロールプレーンのログ記録でポッドをスケジュールできない理由に関する情報を調べることができます。

場合によっては、ノードが Unknown ステータスになることがあります。これは、ノードの kubelet がノードの正しいステータスでコントロールプレーンと通信できないことを意味します。

Unknown ステータスのノードをトラブルシューティングするには、次のセクションのステップを完了します。

• ノードとコントロールプレーン間のネットワーク設定をチェックする
• kubelet のステータスをチェックする
• Amazon EC2 API エンドポイントが到達可能であることをチェックする

ノードとコントロールプレーン間のネットワーク設定をチェックする

1.    Amazon EKS コントロールプレーンとワーカーノード間のトラフィックをブロックするネットワーク ACL ルールがサブネットに存在しないことを確認します。

2.    コントロールプレーンとノードのセキュリティグループが最小インバウンドおよび最小アウトバウンドの要件に従っていることを確認します。

3.    (オプション) ノードがプロキシを使用するように設定されている場合は、そのプロキシが API サーバーエンドポイントへのトラフィックを許可していることを確認します。

4.    次の netcat コマンドを実行して、ノードが API サーバーにアクセスできることを検証します。

$ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443
Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

kubelet のステータスをチェックする

1.    SSH を使用して、対象のワーカーノードに接続します。

2.    次のコマンドを実行して、kubelet ログをチェックします。

$ journalctl -u kubelet > kubelet.log

注意: kubelet.log ファイルには、ノードステータス問題の根本的な原因を見つけるために役立つ kubelet 操作に関する情報が含まれています。

ログに問題の原因に関する情報がない場合は、次のコマンドを実行してワーカーノードの kubelet のステータスをチェックしてください。

$ sudo systemctl status kubelet
  kubelet.service - Kubernetes Kubelet
   Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-eksclt.al2.conf
   Active: inactive (dead) since Wed 2019-12-04 08:57:33 UTC; 40s ago

kubelet のステータスが Running ではない場合は、次のコマンドを実行して kubelet を再起動します。

$ sudo systemctl restart kubelet

Amazon EC2 API エンドポイントが到達可能であることをチェックする

1.    SSH を使用して、ワーカーノードの 1 つに接続します。

2.    次のコマンドを実行して、お使いの AWS リージョンにある Amazon Elastic Compute Cloud (Amazon EC2) API エンドポイントが到達可能かどうかをチェックします。

$ nc -vz ec2.<region>.amazonaws.com 443
Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

注意: us-east-1 は、お使いのワーカーノードが設置されている AWS リージョンに置き換える必要があります。