Amazon EKS の Kubernetes ポッドの問題をトラブルシューティングする方法を教えてください。

解決策

Pod の問題を引き起こすエラーを特定する

1. ポッドに関する情報を取得するには、次の kubectl describe コマンドを実行します。

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   注: YOUR_POD_NAME を実際のポッド名に、YOUR_NAMESPACE を実際の名前空間に置き換えてください。

2. コマンド出力の Events セクションでエラーメッセージを確認します。

   出力例:

   Events:
     Type     Reason            Age                From               Message
     ----     ------            ----               ----               -------
     Warning  FailedScheduling  24s                default-scheduler  no nodes available to schedule pods
     Warning  FailedScheduling  19s (x2 over 22s)  default-scheduler  no nodes available to schedule pods

表示されたエラーメッセージに基づいて、次のトラブルシューティングを実行して Pod の問題を解決してください。

EBS ボリュームマウントの問題

次の出力例は、kubectl describe pod ebs-pod コマンドからのものです。出力には、Amazon Elastic Block Store (Amazon EBS) ボリュームマウントのボリュームノードアフィニティエラーが表示されます。

Name:         ebs-pod
...
Status:       Pending
...
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning FailedScheduling 88s (x20 over 96m) default-scheduler 0/2 nodes are available 2 node(s) had volume node affinity conflict

上記のエラーは、複数のアベイラビリティーゾーンでポッドの永続ボリュームクレーム (PVC) をスケジュールするときに発生します。ポッドは別のアベイラビリティーゾーンのボリュームに接続できないため、ポッドをスケジュールできません。この問題を解決するには、1 つのアベイラビリティーゾーンで PVC をスケジュールする必要があります。

このエラーをトラブルシューティングするには、次の手順を実行します。

1. 名前空間内のすべての PVC に関する情報を取得するには、次の kubectl get pvc コマンドを実行します。

   kubectl get pvc -n YOUR_NAMESPACE

   注: YOUR_NAMESPACE を実際の名前空間に置き換えます。

2. 永続ボリューム (PV) に関する情報を取得するには、次の kubectl get pv コマンドを実行します。

   kubectl get pv

3. お使いの PVC に対応する PV を見つけるには、次の kubectl describe pv コマンドを実行します。

   kubectl describe pv your_PV

   注: your_PV を実際の PV 名に置き換えてください。

4. 前のコマンドから受け取ったボリューム ID が正しいアベイラビリティーゾーンに関連付けられていることを確認します。

5. アベイラビリティーゾーンがあるノードを確認します。

ボリュームノードのアフィニティ競合が発生した場合は、以下のいずれかのアクションを実行してください。

• テイントと許容範囲を使用して、Amazon EBS マウントを使用するポッドが正しいノードでスケジュールされるようにしてください。ノードは EBS ボリュームがあるアベイラビリティーゾーンにある必要があります。詳細については、Kubernetes のウェブサイトで「Taint と Toleration」を参照してください。
• Deployment の代わりに StatefulSet を使用して、StatefulSet 内の各ポッドの同じアベイラビリティーゾーンに固有の EBS ボリュームを作成します。詳細については、Kubernetes ウェブサイトの「StatefulSet」を参照してください。

ポッドまたは StatefulSet が 保留状態 のままになっている可能性があります。これは、ポッドまたは StatefulSet が EBS ボリュームと同じアベイラビリティーゾーンにある場合でも当てはまります。この問題を解決するには、次の kubectl logs コマンドを実行して Amazon EBS CSI ドライバーポッドのログを確認してください。

kubectl logs your-ebs-csi-controller -n your-kube-system -c your-csi-provisioner

注: your-ebs-csi-controller を実際の Amazon EBS CSI コントローラに置き換えてください。また、 your-kube-system を事前定義された名前空間に置き換え、your-csi-provisioner をログのプルに使用するコンテナ名に置き換えてください。

ContainerCreating 状態エラー

次のエラーメッセージは、ポッドが ContainerCreating 状態でスタックしていて、NetworkPlugin: cni がポッドに IP アドレスを割り当てていない場合に表示されます。

"Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0fdf25254b1888afeda8bf89bc1dcb093d0661ae2c8c65a4736e473c73714c65" network for pod "test": networkPlugin cni failed to set up pod "test" network: add cmd: failed to assign an IP address to container."

ContainerCreating 状態エラーをトラブルシューティングするには、以下のアクションを実行してください。

• サブネットに、問題を解決するための利用可能な IP アドレスがあるかどうかを確認してください。Amazon Virtual Private Cloud (Amazon VPC) コンソールを開きます。ナビゲーションペインの [仮想プライベートクラウド] で、[サブネット] を選択します。
• aws-node のポッドが** [実行中]** の状態であることを確認します。また、サポートされている最新バージョンの Amazon VPC CNI を使用していることを確認してください。
• インスタンスの Pod の数が Pod の最大数に達したかどうかを確認します。
• ポッドをスケジュールしたノードで、ipamd ログと var/log/aws-routed-eni パスの下にあるプラグインでエラーメッセージを探します。

CrashLoopBackOff 状態エラー

"Back-Off restarting failed container" というエラーメッセージが表示されます。

前述のエラーメッセージは、コンテナが繰り返し起動に失敗し、その後 CrashLoopBackoff 状態になり、Pod 内で再起動を繰り返し続けている場合に発生します。

次の問題により、コンテナの起動が繰り返し失敗する可能性があります。

• メモリ不足
• リソース過負荷
• デプロイエラー
• DNS エラーなどの外部依存問題
• サードパーティーの依存関係
• ポートの競合によるコンテナレベルの障害

現在のポッドのログのエラーを取得するには、次の kubectl logs コマンドを実行します。

kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE

注: YOUR_POD_NAME を実際のポッド名に、YOUR_NAMESPACE を実際の名前空間に置き換えてください。

クラッシュした前回の Pod のログにエラーを表示するには、次の kubectl logs --previous コマンドを実行します。

kubectl logs --previous YOUR_POD_NAME -n YOUR_NAMESPACE

注: YOUR_POD_NAME を実際のポッド名に、YOUR_NAMESPACE を実際の名前空間に置き換えてください。

プローブ障害エラー

Pod がクラッシュすると、接続が拒否されたり、クライアントがタイムアウトしたりして、プローブ障害エラーが発生します。

拒否された接続のトラブルシューティング

接続が拒否されたためにプローブが失敗した場合は、次のエラーメッセージのいずれかが表示されることがあります。

• "Liveness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused."
• "Readiness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused."

接続をトラブルシューティングするには、次の手順を実行してください。

1. Pod マニフェストで定義されているヘルスチェックパスをワーカーノードから手動で取得するには、次のコマンドを実行します。

   [ec2-user@ip-10-5-1-12 ~]$ curl -ikv podIP:8080//your_healthcheck_path

   注: podIP を実際のポッドの IP アドレスに、your_healthcheck_path を実際のパス名に置き換えてください。

2. liveness probe または readiness probe に失敗したポッドのポッドマニフェストで定義されているヘルスチェックパスを確認します。ヘルスチェックパスを確認するには、次のコマンドを実行します。

   local@bastion-host ~ % kubectl exec YOUR_POD_NAME -- curl -ikv "http://localhost:8080/your_healthcheck_path"

   注: YOUR_POD_NAME は、実際のポッド名に置き換えます。

3. 踏み台ホストで同じコンテナイメージを実行します。

4. マニフェストのプローブで定義されているヘルスチェックパスを取得できるかどうかを確認します。次に、コンテナログに障害、タイムアウト、またはエラーがないか確認します。

5. ポッドが実行されているワーカーノードの kubelet ログにエラーがないかどうかを確認するには、次の journalctl コマンドを実行します。

   [ec2-user@ip-10-5-1-12 ~]$ journalctl -u kubelet //optionally 'grep' with pod name

クライアントタイムアウトのトラブルシューティング

クライアントのタイムアウトが原因でプローブが失敗した場合は、次のエラーメッセージのいずれかが表示されることがあります。

• "Liveness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)."
• "Readiness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)."

クライアントのタイムアウトをトラブルシューティングするには、アプリケーションポッドの liveness probe と readiness probe の設定が正しいかどうかを確認します。

ポッドにセキュリティグループを使用し、ENABLE_POD_eni=True を使用する場合は、TCP early demux を無効にする必要があります。このアクションにより、kubelet は TCP を使用するブランチネットワークインターフェース上のポッドに接続できます。

TCP early demux を無効にするには、次の kubectl patch コマンドを実行します。

kubectl patch daemonset aws-node -n kube-system \-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'

ImagePullBackOff エラー

ImagePullBackoff エラーは、ポッドで実行されているコンテナがコンテナレジストリから必要なイメージを取得できなかった場合に発生します。

次の問題により、このエラーが発生する場合もあります。

• ネットワーク接続に問題がある
• 画像名またはタグが間違っている
• 認証情報が見つからない
• アクセス許可が不十分

問題の原因を特定するには、次の手順を実行します。

1. Pod のステータスを取得するには、以下のコマンドを実行します。

   kubectl get pods -n YOUR_NAMESPACE

   注: YOUR_NAMESPACE を実際の名前空間に置き換えます。

2. Pod の障害の詳細を取得するには、以下のコマンドを実行します。

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   注: YOUR_POD_NAME を実際のポッド名に、YOUR_NAMESPACE を実際の名前空間に置き換えてください。

   出力例:

   Events:
   Type     Reason     Age                From                Message
   ----     ------     ----               ----                -------
   Normal   Scheduled  18m                default-scheduler   Successfully assigned kube-system/kube-proxy-h4np6 to XXX.XXX.eu-west-1.compute.internal
   Normal   Pulling    16m (x4 over 18m)  kubelet             Pulling image "<account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2"
   Warning  Failed     16m (x4 over 18m)  kubelet             Failed to pull image "<account-d>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2": rpc error: code = Unknown desc = Error response from daemon: manifest for <account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2 not found: manifest unknown: Requested image not found

ImagePullBackoff エラーのトラブルシューティングについては、「Amazon EKS のポッドステータス ErrImagePull と ImagePullBackoff のエラーをトラブルシューティングする方法を教えてください」を参照してください。