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

最終更新日: 2020 年 8 月 26 日

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

簡単な説明

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

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

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

注意: ポッドエビクションとリソース制限の管理に関する情報については、Kubernetes ドキュメントの「Configure Out of Resource Handling」を参照してください。

解決方法

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 に進んでください。 詳細については、Kubernetes ドキュメントの「DaemonSet」を参照してください。

ノードのステータスが 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

5.    ステップ 4 のコマンドからの出力で、ポッドを起動できない理由を調べます。

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

6.    AWS ガイドラインに基づいて、 aws-node と kube-proxy のバージョンが、クラスターのバージョンと互換性があることを確認します。たとえば、以下のコマンドを実行して Pod のバージョンを確認できます。

$ 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 のアップグレード」を参照してください。kube-proxy のバージョンを更新するには、「 既存のクラスターの更新」のステップ 4 に従います。

場合によっては、ノードが 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!

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

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

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 リージョンに置き換えてください。

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

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

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

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

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

apiVersion: v1
kind: 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

この記事はお役に立ちましたか?

フィードバックを送信

請求に関するサポートまたは技術的なサポートが必要ですか?

AWS サポートに問い合わせる