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

所要時間3分

Amazon Elastic Kubernetes Service (Amazon EKS) ワーカーノードのステータスが NotReady または Unknown になっており、ワーカーノードのステータスを Ready に戻したいと考えています。

簡単な説明

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

次の解決策は、NotReady または Unknown ステータスのノードに対応します。

ノードが MemoryPressure、DiskPressure、または PIDPressure ステータスになっている場合は、そのノードで追加のポッドをスケジュールできるようにリソースを管理する必要があります。

ノードが NetworkUnavailable ステータスになっている場合は、ノードのネットワークを正しく設定する必要があります。詳細については、Kubernetes ウェブサイトの「Node status」を参照してください。

注: ポッドエビクションとリソース制限の管理方法については、Kubernetes ウェブサイトの「Node-pressure eviction」を参照してください。

解決策

aws-node ポッドと kube-proxy ポッドを確認して、ノードが NotReady ステータスである理由を特定する

NotReady ステータスのノードを使用して、ポッドをスケジュールすることはできません。

セキュリティ体制を改善するために、マネージドノードグループはノードのロールの Amazon リソースネーム (ARN) から、コンテナネットワークインターフェイス (CNI) ポリシーを削除する場合があります。このように CNI ポリシーがないことで、ノードは NotReady ステータスに変わります。この問題を解決するには、ガイドラインに従って aws-node DaemonSet のサービスアカウント (IRSA) の IAM ロールを設定します。

aws-node ポッドと kube-proxy ポッドのステータスを確認するには、次のコマンドを実行します。

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

出力は次のようになります。

$ kubectl get pods -n kube-system -o wideNAME                             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

出力を確認します。ノードのステータスが正常であれば、aws-node ポッドと kube-proxy ポッドは Running ステータスになっています。
aws-node ポッドまたは kube-proxy ポッドがリストされていない場合は、ステップ 3 に進んでください。aws-node ポッドと kube-proxy ポッドは DaemonSet によって管理されます。そのため、クラスター内の各ノードには、そのノード上で動作する aws-node と kube-proxy ポッドが 1 つ必要になります。詳細については、Kubernetes ウェブサイトの「DaemonSet」を参照してください。

いずれかのポッドが Running 以外のステータスになっている場合は、次のコマンドを実行します。
```
$ kubectl describe pod yourPodName -n kube-system
```
aws-node および kube-proxy ポッドのログから追加情報を取得するには、次のコマンドを実行します。
```
$ kubectl logs yourPodName -n kube-system
```
describe 出力のログとイベントで、ポッドが Running ステータスになっていない理由がわかります。ノードが Ready ステータスになるには、そのノードで aws-node ポッドと kube-proxy ポッドの両方が Running になっている必要があります。

aws-node ポッドと kube-proxy ポッドがコマンド出力に表示されない場合は、次のコマンドを実行します。

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

出力を検索して、ポッドを起動できない理由を調べます。

注: Amazon EKS コントロールプレーンのログで、ポッドをスケジュールできない理由を調べることもできます。

AWS ガイドラインに基づいて、aws-node と kube-proxy のバージョンがクラスターバージョンと互換性があることを確認します。例えば、次のコマンドを実行してポッドのバージョンを確認します。

$ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

注: aws-node のバージョンを更新するには、「Amazon VPC CNI plugin for Kubernetes Amazon EKS アドオンの使用」を参照してください。kube-proxy バージョンを更新するには、「Amazon EKS クラスターに必要な Kubernetes バージョンを更新する」のステップ 4 に従います。

ノードは Unknown ステータスになることもあります。この場合、ノード上の kubelet がノードの正しいステータスをコントロールプレーンに伝えられなくなります。

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

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

Amazon EKS コントロールプレーンとワーカーノード間のトラフィックをブロックするネットワークアクセスコントロールリスト (ACL) ルールがサブネットにないことを確認します。
コントロールプレーンとノードのセキュリティグループが、インバウンドとアウトバウンドの最小要件を満たしていることを確認します。
(オプション) ノードがプロキシを使用するように設定されている場合、そのプロキシが API サーバーエンドポイントへのトラフィックを許可していることを確認します。

ノードが API サーバーにアクセスできることを確認するには、ワーカーノード内から次の netcat コマンドを実行します。

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

注: 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com は、お使いの API サーバーエンドポイントに置き換えてください。

ルートテーブルが API サーバーエンドポイントとの通信を行えるように設定されていることを確認します。この通信は、インターネットゲートウェイまたは NAT ゲートウェイを経由して行います。クラスターが PrivateOnly ネットワーキングを使用している場合は、VPC エンドポイントが正しく設定されていることを確認します。

kubelet のステータスを確認する

SSH を使用して、該当するワーカーノードに接続します。
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 2023-12-04 08:57:33 UTC; 40s ago

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

$ sudo systemctl restart kubelet

Amazon EC2 API エンドポイントがアクセス可能であることを確認する

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

該当する AWS リージョンの Amazon Elastic Compute Cloud (Amazon EC2) API エンドポイントがアクセス可能であるかを確認するには、次のコマンドを実行します。

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

注: us-east-1 は、ワーカーノードが置かれている AWS リージョンに置き換えてください。

ワーカーノードのインスタンスプロファイルと ConfigMap を確認する

ワーカーノードのインスタンスプロファイルに推奨ポリシーがあることを確認します。

ワーカーノードインスタンスのロールが、aws-auth ConfigMap にあることを確認します。ConfigMap を確認するには、次のコマンドを実行します。

$ kubectl get cm aws-auth -n kube-system -o yaml

ConfigMap には、ワーカーノードインスタンスの AWS Identity and Access Management (IAM) ロールのエントリが必要です。例:

apiVersion: v1kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

トピック

コンテナ

タグ

Amazon Elastic Kubernetes Service

言語

日本語