Container Service for Kubernetes:Pod troubleshooting

エラーメッセージ

説明

ソリューション

no nodes available to schedule pods.

クラスターには Pod スケジューリングに利用できるノードがありません。

1. クラスター内のいずれかのノードが NotReady 状態になっていないか確認します。ノードが NotReady の場合は、検査して修復します。

2. Pod が nodeSelector、nodeAffinity、または Taint の Toleration を定義しているかどうかを確認します。そのようなスケジューリング制約が定義されていない場合は、ノードプールにノードを追加することを検討してください。

• 0/x nodes are available: x Insufficient cpu.

• 0/x nodes are available: x Insufficient memory.

クラスター内に、Pod の CPU またはメモリリソースリクエストを満たすことができる利用可能なノードがありません。

実際の CPU またはメモリ使用率が低くても、割り当てられたリソースの requests の合計がそのキャパシティに達した場合、ノードはスケジュール不可能と見なされます。

対象クラスターの詳細ページで、ノード > ノード に移動し、対象ノードの CPU またはメモリのリクエスト割り当て率を確認します。割り当て率にマウスを上に置くと、具体的なリソース割り当て値を表示できます。

ノードリソース使用量の詳細を表示するには、「kubectl を使用してノードのリソース使用量を確認する」をご参照ください。

• リソース設定の最適化：

  • ノードのリソース 使用量 が一貫してその リクエスト よりも低い場合、リソースが無駄になっていることを示します。ワークロードの requests 設定を下げることができます。詳細については、「コンテナの CPU およびメモリリソース制限の設定」をご参照ください。

    リソースプロファイリング を有効にして、推奨される requests 設定を取得できます。

  • ビジネスコンテナに対して Horizontal Pod Autoscaler (HPA) を有効にして、オフピーク時のレプリカ数を減らし、全体的なリソース消費を削減します。

• 不要なワークロードのクリーンアップ：重要でない Pod を廃止またはスケールダウンします。

• ノードプールのスケールアウト：対象ノードのリソース使用率が一貫して高い場合、ノードは飽和状態です。ノードプールをスケールアウトできます。

x node(s) didn't match pod's node affinity/selector.

クラスター内の既存のノードが、Pod に宣言されたノードアフィニティポリシー (nodeAffinity/nodeSelector) に一致しません。詳細については、「Pod をノードに割り当てる」をご参照ください。

1. ノード上のすべてのラベルを表示します。

   コンソール

   1. 対象クラスターの詳細ページで、ノード > ノード に移動します。

   2. ノード ページで、対象のノードを見つけ、アクション 列で 詳細 > ラベルとテイントの管理 をクリックして、そのラベルを表示します。

   Kubectl

   <YOUR_NODE_NAME> を実際のノード名に置き換えます。

   kubectl get node <YOUR_NODE_NAME> --show-labels

2. ワークロード (Deployment) のノードアフィニティルールを確認し、調整します。

   コンソール

   新しいワークロードを作成する場合：

   1. Deployment を作成するするための上級ページで、スケジューリングセクションにあるノードアフィニティを見つけ、追加をクリックします。

   2. ビジネスニーズに基づいて、満たす必要があります (ハードアフィニティ) または できる限り ~ を満たす (ソフトアフィニティ) のいずれかを設定します。複数の セレクター は論理 AND 関係になり、複数の ルール は論理 OR 関係になります。

   既存のワークロードの場合：

   1. ノード > ノード ページで、対象の Deployment の アクション 列にある > ノードアフィニティ をクリックします。

   2. 設定方法は上記と同じです。

   YAML の例

   NodeAffinity

   アフィニティポリシーは、ハードアフィニティ (requiredDuringSchedulingIgnoredDuringExecution) とソフトアフィニティ (preferredDuringSchedulingIgnoredDuringExecution) に分かれます。ハードアフィニティは満たされなければならないルールを指定し、ソフトアフィニティは優先事項を指定します。次の例ではハードアフィニティを使用しています。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-node-affinity-deploy
     labels:
       app: demo-node-affinity
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: demo-node-affinity
     template:
       metadata:
         labels:
           app: demo-node-affinity
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         affinity:
           nodeAffinity:
             # ハードアフィニティ：ルールは満たされなければなりません。
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: disktype
                   operator: In
                   values:
                   - ssd
                   - nvme  # ロジック：ノードの 'disktype' ラベルは 'ssd' または 'nvme' でなければなりません。

   NodeSelector

   これは単純な完全一致を提供します。Pod は、ノードのラベルが条件を満たす場合にのみスケジュールされます。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-node-selector-deploy
     labels:
       app: demo-node-selector
   spec:
     replicas: 2  
     selector:
       matchLabels:
         app: demo-node-selector  
     template:
       metadata:
         labels:
           app: demo-node-selector
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         # Pod は、ノードに disktype=ssd ラベルがある場合にのみスケジュールされます。
         nodeSelector:
           disktype: ssd

• x node(s) didn't match pod affinity rules.

• x node(s) didn't match pod anti-affinity rules.

• アフィニティルールの不一致。Pod には Pod アフィニティ ルール (例えば、特定のラベルを要求する) がありますが、一致するラベルを持つ Pod をホストするノードがないため、スケジューリングができません。

• アンチアフィニティの競合。Pod には Pod アンチアフィニティ ルール (例えば、別のアプリケーションと共存できない) がありますが、利用可能なすべてのノードがすでに競合する Pod をホストしているため、スケジューリングができません。

1. ノード上の Pod ラベルを表示します。

   コンソール

   1. 対象クラスターの詳細ページで、ノード > ノード に移動します。

   2. ノード ページで、対象ノードの名前をクリックして詳細ページを表示します。ポッド セクションまで下にスクロールすると、タグ 列でさまざまな Pod のラベルの値を確認できます。

   Kubectl

   • 特定のノード上の Pod とそのラベルを表示する：<YOUR_NAMESPACE> を名前空間名に、<YOUR_NODE_NAME> を実際のノード名に置き換えます。

     kubectl get pods -n <YOUR_NAMESPACE> --field-selector spec.nodeName=<YOUR_NODE_NAME> -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels

   • ラベルで Pod をクエリする：<LABEL> を実際のキーと値のペア (例：app=nginx) に置き換えます。

     kubectl get pods -A -l <LABEL> -o wide

2. ワークロード (Deployment) の Pod アフィニティルールを確認し、調整します。

   コンソール

   1. 新しいワークロードを作成する際、作成する Deployment の 上級 ページで、ポッドアフィニティ/Pod のアンチアフィニティ を スケジューリング セクションで見つけ、追加 をクリックします。

   2. ビジネス要件に応じて、満たす必要があります（ハードアフィニティ）またはできる限り ~ を満たす（ソフトアフィニティ）を設定します。複数のセレクターは論理積（AND）関係を持ち、複数のルールの追加は論理和（OR）関係を持ちます。

   YAML の例

   アフィニティポリシーは、ハードアフィニティ (requiredDuringSchedulingIgnoredDuringExecution) とソフトアフィニティ (preferredDuringSchedulingIgnoredDuringExecution) に分類されます。ハードアフィニティルールは満たされなければならず、ソフトアフィニティルールは優先されます。次の例は、必須の Pod アフィニティ の設定を示しています。

   Pod アンチアフィニティを設定するには、単に podAffinity を podAntiAffinity に置き換えます。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-podaffinity-deploy
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: demo-podaffinity
     template:
       metadata:
         labels:
           app: demo-podaffinity
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         affinity:
           podAffinity:
             # ハードアフィニティ：Pod は 'app: nginx' ラベルを持つ Pod と同じ場所に配置されなければなりません。
             requiredDuringSchedulingIgnoredDuringExecution:
             - labelSelector:
                 matchExpressions:
                 - key: app
                   operator: In
                   values:
                   - nginx
               # トポロジードメインの範囲：ホストレベルの隔離。
               topologyKey: kubernetes.io/hostname

0/x nodes are available: x node(s) had volume node affinity conflict.

ボリュームのノードアフィニティの競合によりスケジューリングが失敗します。これは通常、クラウドディスクが異なるゾーン間でマウントできないために発生します。

• 静的にプロビジョニングされた PV の場合、Pod のノードアフィニティを設定して、PV と同じゾーンのノードにスケジュールされるようにします。

• 動的にプロビジョニングされた PV の場合、StorageClass の volumeBindingMode を WaitForFirstConsumer に設定します。これにより、Pod がノードにスケジュールされた後にのみ PV が作成され、クラウドディスクが Pod のノードと同じゾーンに作成されることが保証されます。

InvalidInstanceType.NotSupportDiskCategory

ECS インスタンスは指定されたクラウドディスクタイプをサポートしていません。

ご利用の ECS インスタンスでサポートされているクラウドディスクタイプを確認するには、「インスタンスファミリー」をご参照ください。マウント時に、クラウドディスクタイプを ECS インスタンスでサポートされているものに更新します。

0/x nodes are available: x node(s) had taints that the pod didn't tolerate.

Pod は、ノードの Taint のいずれかに対する Toleration がないため、ノードにスケジュールできません。

• Taint が手動で追加された場合は、意図しない Taint を削除できます。Taint を削除できない場合は、Pod に対応する Toleration を設定できます。詳細については、「Taint と Toleration」および「ノードのラベルと Taint の管理」をご参照ください。

• Taint がシステムによって自動的に追加された場合は、以下に説明するように根本的な問題を解決し、Pod が再スケジュールされるのを待ちます。

  システムによって追加された Taint を表示する

  • node.kubernetes.io/not-ready：ノードは NotReady 状態です。

  • node.kubernetes.io/unreachable：ノードコントローラーからノードに到達できません。これは、ノードの Ready ステータスが Unknown であることと同じです。

  • node.kubernetes.io/memory-pressure：ノードはメモリプレッシャー下にあります。

  • node.kubernetes.io/disk-pressure：ノードはディスクプレッシャー下にあります。

  • node.kubernetes.io/pid-pressure：ノードは PID プレッシャー下にあります。

  • node.kubernetes.io/network-unavailable：ノードのネットワークは利用できません。

  • node.kubernetes.io/unschedulable：ノードはスケジュール不可能としてマークされています。

0/x nodes are available: x Insufficient ephemeral-storage.

ノードのエフェメラルストレージが不足しています。

1. Pod のエフェメラルストレージリクエストを確認します。これは Pod YAML の spec.containers.resources.requests.ephemeral-storage の値です。値が高すぎてノードの実際の利用可能容量を超えている場合、Pod のスケジュールは失敗します。

2. kubectl describe node | grep -A10 Capacity コマンドを実行して、各ノードの合計エフェメラルストレージ容量を表示します。容量が不足している場合は、ノードのディスクを拡張するか、ノードを追加します。

0/x nodes are available: pod has unbound immediate persistent volume claims.

Pod が永続ボリューム要求 (PVC) にバインドできませんでした。

Pod によって指定された PVC または PV が作成されているか確認します。kubectl describe pvc <pvc-name> または kubectl describe pv <pv-name> を実行して、PVC と PV のイベントを表示し、さらに診断します。詳細については、「ストレージ FAQ - CSI」をご参照ください。

エラーメッセージ

説明

推奨されるソリューション

Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:

Pod の作成時に imagePullSecret が指定されなかったため、イメージリポジトリへのアクセスが拒否されました。

ワークロードの YAML ファイルの spec.imagePullSecrets フィールドで指定された Secret が存在することを確認します。

Container Registry (ACR) を使用する場合、認証情報ヘルパーを使用してパスワードなしでイメージをプルできます。詳細については、「同じアカウントからイメージをプルする」をご参照ください。

Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host

HTTPS 経由でイメージをプルする際に、イメージリポジトリのアドレスを解決できませんでした。

1. Pod の YAML ファイルの spec.containers.image にあるイメージリポジトリのアドレスが正しいことを確認します。正しくない場合は更新します。

2. アドレスが正しい場合は、Pod が実行されているノードからイメージリポジトリへのネットワーク接続を確認します。ノードにログインし (詳細については、「ECS リモート接続方法の選択」をご参照ください)、curl -kv https://xxxxxx/xxxxx/ コマンドを実行してアドレスにアクセスできるか確認します。エラーが発生した場合は、不正なネットワーク設定、ファイアウォールルール、DNS 解決の問題など、潜在的なネットワークの問題を調査します。

Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device

ノードのディスク領域が不足しています。

Pod が実行されているノードにログインし (詳細については、「ECS リモート接続方法の選択」をご参照ください)、df -h を実行してディスク領域を確認します。ディスクがいっぱいの場合は、クラウドディスクのサイズを変更します。詳細については、「ステップ 1：クラウドディスクのサイズ変更」をご参照ください。

Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority

サードパーティのイメージリポジトリが、不明または安全でない認証局 (CA) によって署名された証明書を使用しています。

1. サードパーティのリポジトリは、信頼できる CA によって発行された証明書を使用する必要があります。

2. プライベートイメージリポジトリを使用している場合は、「プライベートイメージリポジトリからアプリケーションを作成する」をご参照ください。

3. 証明書を変更できない場合は、安全でない証明書を使用するリポジトリからイメージをプルおよびプッシュできるようにノードを設定できます。この方法は、ノード上の他の Pod に影響を与える可能性があるため、テスト環境でのみ使用することを推奨します。

Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

操作はキャンセルされました。おそらくイメージファイルが大きすぎるためです。Kubernetes にはイメージをプルするためのデフォルトのタイムアウトがあります。プルが特定の期間進行しない場合、Kubernetes は操作が失敗したか応答がないと判断し、タスクをキャンセルします。

1. Pod の YAML ファイルで imagePullPolicy が IfNotPresent に設定されていることを確認します。

2. Pod が実行されているノードにログインし (詳細については、「ECS リモート接続方法の選択」をご参照ください)、docker pull または crictl pull を実行してイメージをプルできるか確認します。

Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

ネットワークの問題により、イメージリポジトリに接続できません。

1. Pod が実行されているノードにログインし (詳細については、「ECS リモート接続方法の選択」をご参照ください)、curl https://xxxxxx/xxxxx/ コマンドを実行してアドレスにアクセスできるか確認します。エラーが発生した場合は、不正なネットワーク設定、ファイアウォールルール、DNS 解決の問題など、潜在的なネットワークの問題を調査します。

2. SNAT エントリやバインドされた EIP (Elastic IP Address) の設定など、ノードのパブリックネットワークポリシーを確認します。

Failed to pull image "xxxx:xxx": failed to pull and unpack image "xxxx:xxx": failed to resolve reference "xxxx:xxx": failed to do request: Head "xxxx:xxx": dial tcp xxx.xxx.xx.x:xxx: i/o timeout

海外のリポジトリからイメージをプルする際に、ネットワークの問題により接続がタイムアウトしました。

Docker Hub などの海外リポジトリからのイメージプルは、キャリアネットワークが不安定なため、ACK クラスターで失敗することがあります。これを解決するには、以下のソリューションを検討してください：

• Container Registry を使用して海外のソースイメージをサブスクライブします。手順については、「アーティファクトサブスクリプションを使用して中国以外のソースからイメージを同期する」をご参照ください。

• Global Accelerator (GA) インスタンスを作成し、そのグローバルアクセラレーションネットワークを使用して直接イメージをプルします。詳細については、「GA を使用して ACK でのクロスリージョンコンテナイメージプルを高速化する」をご参照ください。

Too Many Requests.

Docker Hub は、イメージのプルリクエストにレート制限を課しています。

イメージを Container Registry (ACR) にアップロードし、ACR イメージリポジトリからプルします。

ステータス Pulling image が一貫して表示される

kubelet のイメージプルレート制限メカニズムがトリガーされた可能性があります。

ノードプールの kubelet 設定をカスタマイズする機能を使用して、registryPullQPS (イメージリポジトリの最大 QPS) と registryBurst (最大バーストイメージプル数) を調整します。

エラーメッセージ

説明

ソリューション

Init:N/M 状態でスタック

Pod には M 個の init コンテナが含まれています。そのうち N 個は完了しましたが、残りの M-N 個の init コンテナは起動に失敗しました。

1. kubectl describe pod -n <ns> <pod name> コマンドを実行して Pod のイベントを表示し、未起動の init コンテナの問題を確認します。

2. kubectl logs -n <ns> <pod name> -c <container name> コマンドを実行して、未起動の init コンテナのログを表示し、それらを使用して問題をトラブルシューティングします。

3. ヘルスチェック設定など、Pod の設定を確認して、init コンテナが正しく設定されていることを確認します。

init コンテナの詳細については、「init コンテナのデバッグ」をご参照ください。

Init:Error 状態でスタック

Pod 内の init コンテナが起動に失敗しました。

Init:CrashLoopBackOff 状態でスタック

Pod 内の init コンテナが起動に失敗し、再起動ループに陥っています。

エラーメッセージ

説明

ソリューション

failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx

これは Flannel ネットワークプラグインの設計による期待される動作です。

Flannel コンポーネントを v0.15.1.11-7e95fe23-aliyun 以降にアップグレードします。詳細については、「Flannel」をご参照ください。

Kubernetes バージョン 1.20 より前のクラスターでは、Pod が繰り返し再起動したり、CronJob の Pod がタスクを完了してすぐに終了したりすると、IP アドレスのリークが発生する可能性があります。

クラスターを Kubernetes 1.20 以降にアップグレードします。最新のクラスターバージョンを使用することを推奨します。詳細については、「クラスターを手動でアップグレードする」をご参照ください。

containerd と runC の欠陥がこの問題を引き起こします。

緊急の修正については、「Pod が「範囲内で利用可能な IP アドレスがありません」というエラーで起動に失敗するのはなぜですか？」をご参照ください。

error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found

Terway ネットワークプラグインは、ノード上に内部データベースを維持して Elastic Network Interface (ENI) を追跡および管理します。このエラーは、データベースの状態が実際のネットワークデバイス設定と一致しない場合に発生し、ENI の割り当てが失敗します。

1. ネットワークインターフェイスは非同期でロードされます。CNI 設定中にインターフェイスがまだロード中である可能性があり、これにより自動的な CNI のリトライがトリガーされます。このプロセスは最終的な ENI 割り当てには影響しません。Pod の最終ステータスを確認して成功を確認します。

2. 長時間経過しても Pod の作成が失敗し、このエラーが続く場合は、高次メモリ不足のためにドライバが ENI のロードに失敗した可能性が高いです。この問題を解決するには、ECS インスタンスを再起動します。詳細については、「インスタンスの再起動」をご参照ください。

• cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded

• cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition

Terway ネットワークプラグインが vSwitch から IP アドレスを要求できなかった可能性があります。

1. ノード上の Terway コンポーネント Pod 内の Terway コンテナのログを表示して、ENI 割り当てプロセスを確認します。

2. kubectl logs -n kube-system  <terwayPodName > -c terway | grep <podName> コマンドを実行して、Terway Pod の ENI 情報を表示します。IP アドレスリクエストのリクエスト ID と OpenAPI エラーメッセージを取得します。

3. リクエスト ID とエラーメッセージを使用して、失敗を調査します。

エラーメッセージ

説明

ソリューション

ログに exit(0) が含まれています。

1. 異常なワークロードがデプロイされているノードにログインします。

2. docker ps -a | grep $podName コマンドを実行します。コンテナに永続的なプロセスがない場合、ステータスコード 0 で終了します。

Pod のイベントに Liveness probe failed: ... と表示されます。

liveness プローブが失敗し、アプリケーションが再起動しました。

• liveness プローブの構成: ターゲットの ワークロード の 編集 ページで、ヘルスチェックのリクエストパス (例: /healthz) とポートが、アプリケーションで提供されているものと一致することを確認します。遅延検出時間（秒） を増やして、アプリケーションが完全に起動した後にのみ liveness プローブが開始されるようにします。

  一時的に 有効性チェック を無効化できます。その後、Pod のターミナルまたはそのホストノードにアクセスし、curl などのコマンドを使用して、ヘルスチェックメソッドが正しく機能することを確認します。

• アプリケーションの問題のトラブルシューティング: Pod のイベントとLogを確認して問題を調査します。最後のコンテナーが終了した時のログを表示するを選択します。

Pod のイベントに Startup probe failed: ... と表示されます。

startup プローブが失敗し、アプリケーションが再起動しました。

• スタートアッププローブの構成: 対象の 編集 ページで ワークロード のヘルスチェックリクエストパス（例: /healthz）およびポートがアプリケーションが提供するものと一致することを確認します。アプリケーションの起動に時間がかかる場合は、早期再起動を防ぐために 異常のしきい値 を増やします。

  「起動」を一時的に無効化できます。その後、Pod のターミナルまたはそのホストノードにアクセスし、curl などのコマンドを使用して、ヘルスチェックメソッドが正しく機能することを確認します。

• アプリケーションの問題をトラブルシューティングする: Pod の イベント と ログ を確認して、問題を調査します。最後のコンテナーが終了した時のログを表示する を選択します。

Pod のログに no space left on device が含まれています。

クラウドディスクの領域が不足しています。

• クラウドディスクのサイズを変更します。詳細については、「ステップ 1：クラウドディスクのサイズ変更」をご参照ください。

• 不要なイメージをクリーンアップしてディスク領域を解放し、imageGCHighThresholdPercent を設定してノードでのイメージのガベージコレクションのしきい値を設定します。

イベント情報なしで起動が失敗します。

この問題は、コンテナが宣言された制限を超えるリソースを必要とし、その結果失敗する場合に発生します。

Pod のリソース設定が正しいか確認します。リソースプロファイリングを有効にして、コンテナの推奨されるリクエストと制限の設定を取得できます。

Pod のログに Address already in use と表示されます。

同じ Pod 内のコンテナ間でポートの競合が存在します。

1. Pod が hostNetwork: true で設定されているか確認します。この設定により、Pod 内のコンテナはホストのネットワーク名前空間とポート空間を共有します。これが必要ない場合は、hostNetwork: false に変更します。

2. Pod が hostNetwork: true を必要とする場合は、Pod アンチアフィニティを設定して、同じレプリカセットの Pod が異なるノードにスケジュールされるようにします。

3. 同じノード上の他の Pod がそのポートを使用していないことを確認します。

Pod のログに container init caused "setenv: invalid argument": unknown と表示されます。

ワークロードが Secret をマウントしていますが、Secret 内の値が Base64 エンコードされていません。

• コンソールで Secret を作成します。値は自動的に Base64 エンコードされます。詳細については、「Secret の管理」をご参照ください。

• YAML ファイルから Secret を作成し、echo -n "xxxxx" | base64 コマンドを実行して手動で値を Base64 エンコードします。

アプリケーション固有の問題。

Pod のログを調べて問題をトラブルシューティングします。

エラーメッセージ

説明

ソリューション

Pod のイベントに Readiness probe failed: ... と表示されます。

readiness プローブが失敗し、対象の Pod がトラフィックを受信できなくなりました。

• Readiness プローブの構成：ターゲットのワークロードの編集ページで、ヘルスチェックのリクエストパス (例: /healthz) とポートが、アプリケーションが提供するものと一致することを確認します。アプリケーションの起動時間が長い場合は、早期の失敗を回避するために、異常のしきい値を大きくします。

  一時的にレディチェックを無効化し、Pod の端末またはそのホストにログインして、curl などのコマンドを使用し、ヘルスチェックメソッドが正しく応答することを確認できます。

• アプリケーションの問題をトラブルシューティングする：Pod の イベント および ログ を確認して問題を調査します。最後のコンテナーが終了した時のログを表示する を選択します。

Pod のステータスは上記と同じです。Pod のイベントに Startup probe failed: ... と表示されます。

startup プローブの失敗により、コンテナが再起動します。このエラーは、永続的な Running/NotReady 状態ではなく、「CrashLoopBackOff」状態になるはずです。

この問題のトラブルシューティングは、「Pod が起動しない (CrashLoopBackOff)」セクションに記載されている手順に従って、起動 について行います。

OOM レベル

説明

推奨されるソリューション

OS レベル

Pod のノードのカーネルログ /var/log/messages を確認します。ログに強制終了されたプロセスが表示されているが、cgroup ログが含まれていない場合、OOM イベントは OS レベルで発生しました。

• ノードのメモリリソースを増やすか、ワークロードをより多くのノードに分散させます。詳細については、「ノードリソースのスケール」および「特定のノードへのアプリケーションのスケジューリング」をご参照ください。

• ノード上でメモリ消費量が多い Pod を特定し、適切なメモリ制限を設定します。

cgroup レベル

Pod のノードのカーネルログ /var/log/messages を確認します。ログに Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx のようなエラーメッセージが含まれている場合、OOM イベントは cgroup レベルで発生しました。

• ビジネスニーズに基づいて Pod のメモリ制限を増やします。実際の使用量を設定された制限の 80% 未満に保つことを推奨します。詳細については、「Pod の管理」および「ノードリソースのスケール」をご参照ください。

• リソースプロファイリングを有効にして、コンテナのリクエストと制限の推奨設定を取得します。

考えられる原因

説明

推奨されるソリューション

ノードが NotReady 状態です。

ノードが NotReady 状態から回復した後、Pod は自動的に削除されます。

Pod に finalizer が設定されています。

Pod に finalizer が設定されている場合、Kubernetes は Pod を削除する前に finalizer で指定されたクリーンアップ操作を実行します。クリーンアップ操作が応答に失敗した場合、Pod は Terminating 状態のままになります。

kubectl get pod -n <ns> <pod name> -o yaml コマンドを実行して、Pod のファイナライザー構成を表示し、原因を調査します。

Pod の preStop フックが無効またはスタックしています。

Pod に preStop フックが設定されている場合、Kubernetes はコンテナを終了する前にフックを実行します。フックの実行中、Pod は Terminating 状態のままになります。

kubectl get pod -n <ns> <pod name> -o yaml コマンドを実行して、Pod の preStop フック構成を確認し、原因を調査します。

Pod にグレースフルシャットダウン期間が設定されています。

Pod にグレースフルシャットダウン期間 (terminationGracePeriodSeconds) が設定されている場合、Pod は kubectl delete pod <pod_name> などの終了コマンドを受け取った後、Terminating 状態に入ります。Kubernetes は、terminationGracePeriodSeconds で指定された時間が経過するか、コンテナが終了した後にのみ、Pod が正常にシャットダウンされたと見なします。

コンテナがグレースフルシャットダウンを完了した後、Kubernetes は自動的に Pod を削除します。

コンテナが応答しません。

Pod の停止または削除を要求すると、Kubernetes は Pod 内のコンテナに SIGTERM シグナルを送信します。コンテナが終了中に SIGTERM シグナルを正しく処理しない場合、Pod は Terminating 状態のままになることがあります。

1. kubectl delete pod <pod-name> --grace-period=0 --force コマンドを実行して Pod を強制的に削除し、そのリソースを解放します。

2. Pod のノード上の containerd または Docker のログを確認して、さらに調査します。

考えられる原因

説明

推奨されるソリューション

ノードは、メモリやディスク使用量などの要因によるリソースプレッシャー下にあります。

ノードは、メモリプレッシャー、ディスクプレッシャー、または PID プレッシャーを経験している可能性があります。

• kubectl describe node <node name> | grep Taints コマンドを実行します。出力には以下の Taint が含まれる場合があります：

  • メモリプレッシャー：ノードには node.kubernetes.io/memory-pressure Taint があります。

  • ディスクプレッシャー：ノードには node.kubernetes.io/disk-pressure Taint があります。

  • PID プレッシャー：ノードには node.kubernetes.io/pid-pressure Taint があります。

• Pod のステータスは以下のいずれかです：

  • Evicted

  • ContainerStatusUnknown、そして Pod の YAML ファイルの reason フィールドに Evicted と表示されます。

• メモリプレッシャー：

  • Pod のリソース構成を、ビジネス要件に応じて調整します。詳細については、「Pod の管理」をご参照ください。

  • ノードをアップグレードします。詳細については、「ノードリソースのスケール」をご参照ください。

• ディスク圧力:

  • ノード上の Pod から定期的にアプリケーションログをクリアして、ディスク領域を解放します。

  • ノードのディスクを拡張します。詳細については、「ステップ 1：クラウドディスクのサイズ変更」をご参照ください。

• PID プレッシャー：ビジネス要件に基づいて Pod のリソース設定を調整します。詳細については、「プロセス ID の制限と予約」をご参照ください。

予期しないエビクションが発生します。

Pod のノードに手動で追加された NoExecute Taint が予期しないエビクションを引き起こしました。

kubectl describe node <node name> | grep Taints コマンドを実行して、ノードに NoExecute Taint があるか確認します。ある場合は、それを削除します。

エビクションが期待どおりに進みません。

• --pod-eviction-timeout：障害が発生したノード上の Pod は、このタイムアウト期間後にエビクションされます。デフォルトは 5 分です。

• --node-eviction-rate：ノードから 1 秒あたりにエビクションされる Pod の数。デフォルトは 0.1 で、10 秒ごとに最大 1 つの Pod がノードからエビクションされることを意味します。

• --secondary-node-eviction-rate：セカンダリノードのエビクションレート。クラスター内で多数のノードが障害を起こした場合、エビクションレートはこの値に減少します。デフォルトは 0.01 です。

• --unhealthy-zone-threshold：異常なアベイラビリティゾーンのしきい値。デフォルトは 0.55 です。アベイラビリティゾーン内の障害ノードの割合がこのしきい値を超えると、そのゾーンは異常と見なされます。

• --large-cluster-size-threshold：大規模クラスターのサイズしきい値。デフォルトは 50 です。50 ノードを超えるクラスターは大規模と見なされます。

小規模クラスター (50 ノード以下) では、ノードの 55% 以上が障害を起こすと、Pod のエビクションは停止します。詳細については、「エビクションのレート制限」をご参照ください。

大規模クラスター (50 ノード超) では、異常なノードの割合が --unhealthy-zone-threshold (デフォルト 0.55) を超えると、エビクションレートは --secondary-node-eviction-rate (デフォルト 1 秒あたり 0.01 Pod) の値に減少します。詳細については、「エビクションのレート制限」をご参照ください。

Pod がエビクションされた後、頻繁に元のノードに再スケジュールされます。

kubelet は実際のリソース使用量に基づいて Pod をエビクションしますが、スケジューラはリソースリクエストに基づいて Pod を配置します。エビクションによってリソースが解放されるため、リクエストがまだ収まる場合、スケジューラは Pod を同じノードに再スケジュールする可能性があります。

Pod のリソースリクエストがノードの割り当て可能なリソースに対して適切であることを確認し、必要に応じて調整します。詳細については、「コンテナの CPU およびメモリリソースの設定」をご参照ください。また、リソースプロファイリングを有効にして、コンテナの推奨リクエストと制限の設定を取得することもできます。