K8S Pod Pending の障害の原因と解決策を徹底的に理解する

ポッド保留は、成熟度の高い Kubernetes クラスターでも広く見られます。

Kubernetes を扱う DevOps エンジニアに、彼らの悪夢を悩ませる最も一般的なエラーを特定するようにランダムに尋ねると、ポッド保留が非常に一般的な問題である可能性が高くなります (おそらく CrashLoopBackOff に次ぐ)。

アップデートをプッシュしようとしてそれが停止してしまうと、DevOps は不安に陥る可能性があります。解決策がかなり単純な場合でも、ポッドがハングしている理由を見つけ、適用する必要がある変更を理解することが重要です (Kubernetes のトラブルシューティングはめったに簡単ではありません)。

この記事では、この問題につながるさまざまな状況を明らかにし、DevOps チームが迅速に解決策を見つけ、そして最も重要なことに、可能であればこの問題を回避できるようにします。

Kubernetes Pod が保留中とはどういう意味ですか?

Kubernetes の Pod のライフサイクルは、いくつかの異なるフェーズで構成されます。

• ポッドが作成されると、保留段階から開始されます。
• ポッドがスケジュールされ、コンテナが起動すると、ポッドは実行フェーズに入ります。

ほとんどのポッドは、保留状態から実行状態に移行するのに数秒しかかからず、ほとんどの時間をその状態で過ごします。

この時点で、Pod は Kubernetes クラスターによって受け入れられています。ただし、1 つ以上のコンテナーはまだサービスを提供できる状態ではありません。これには、ポッドがスケジュールを待機するのにかかる時間と、ネットワーク経由でコンテナ イメージをダウンロードするのにかかる時間が含まれます。

ポッドが PendingtoRunning フェーズから進むことができない場合、ライフサイクルは停止し、進むのを妨げている問題が修正されるまでポッドを保持します。

kubectl を使用してポッドを一覧表示すると、Kubernetes ポッドがハングしていることを示す出力が表示されます。

 $ kubectl -n troubleshooting get pods NAME READY STATUS RESTARTS AGE stress-6d6cbc8b9d-s4sbh 0/1 Pending 0 17s

問題を修正しない限り、ポッドは停止し、実行されなくなります。

Kubernetes ポッド保留の一般的な原因のトラブルシューティング

Pod の実行を妨げる理由はいくつかありますが、ここでは主に次の 3 つの問題について説明します。

• スケジューリングの問題: ポッドをどのノードでもスケジュールできません。
• イメージの問題: コンテナ イメージのダウンロード中に問題が発生しました。
• 依存関係の問題: Pod を実行するには、ボリューム、シークレット、または ConfigMap が必要です。

最初のものが最も一般的ですが、最後のものはまれです。それぞれのケースを詳しく説明しましょう。

Kubernetes Pod Pending の原因となるスケジュールの問題

Pod が作成されると、Kubernetes クラスターが最初に行うことは、いずれかのノードで Pod を実行するようにスケジュールすることです。このプロセスは通常非常に高速であり、ポッドはそれを実行するのに十分なリソースを持つノードにすぐに割り当てられます。

配置するには、クラスター内のポッドは、要求されていないリソースがさらに多いノードに割り当てられ、要求に対する SLO 準拠の応答で満たされた楽しく素晴らしい生活を続けます。

ただし、このプロセスが毎回機能する場合、クラスターがポッドを割り当てられない原因となる要因がいくつかあります。

最も一般的なものを確認してみましょう。

どのノードにもポッドを割り当てるのに十分なリソースがありません

Kubernetes は、スケジューリング要求を使用して、fits ノードにポッドがあるかどうかを決定します。リソースの実際の使用状況は重要ではなく、他のポッドが要求したものだけが重要です。

有効なリクエスト ポッドのメモリと CPU に参加するのに十分なリクエスト可能なリソースがある場合、ポッドはノードにスケジュールされます。また、ノードが実行できるポッドの最大数に達していない必要があります。

ポッドのすべての要件を満たすノードがない場合、一部のリソースが解放されるまで、Kubernetes ポッドは保留状態のままになります。

スケジュール不可能なノード

さまざまな問題 (ノードのストレス) または人間の行動 (ノードのブロッキング) により、ノードがスケジュール不能になる場合があります。これらのノードは、状態が変化するまでポッドをスケジュールしません。

汚染と寛容

テイントは、異なるノードに割り当てることができるポッドを制限できる Kubernetes のメカニズムです。ノードに taint がある場合、そのノードでは許容範囲に一致するポッドのみが実行できます。

このメカニズムにより、異なるワークロードに異なるタイプのノード (GPU を備えたノード、異なる CPU/メモリ比のノードなど) を使用するなど、Kubernetes の特別な使用が可能になります。

それぞれの原因を個別に説明したとしても、スケジュールの問題はこれらの問題の組み合わせによって発生することがよくあります。一部のノードがいっぱいで他のノードが汚染されているためスケジュールできないことが多く、また、メモリ不足のためにノードをスケジュールできないこともあります。

スケジューリングの問題が何であるかを調べるには、ポッドに関してスケジューラによって生成されたイベントを確認する必要があります。このイベントには、ノードの割り当てを妨げている原因が詳細に説明されています。イベントを表示するには、kubectl describe を使用できます。次に例を示します。

 $ kubectl -n troubleshooting describe pod stress-6d6cbc8b9d-s4sbh Name: stress-6d6cbc8b9d-s4sbh Namespace: troubleshooting Priority: 0 Node: <none> Labels: app=stress pod-template-hash=6d6cbc8b9d Annotations: <none> Status: Pending IP: IPs: <none> Controlled By: ReplicaSet/stress-6d6cbc8b9d Containers: stress: Image: progrium/stress Port: <none> Host Port: <none> Args: --cpu 1 --vm 2 --vm-bytes 150M Limits: cpu: 300m memory: 120000Mi Requests: cpu: 200m memory: 100000Mi Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-snrww (ro) Conditions: Type Status PodScheduled False Volumes: kube-api-access-snrww: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: <nil> DownwardAPI: true QoS Class: Burstable Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 4m17s (x41 over 34m) default-scheduler 0/5 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 4 Insufficient memory.

正確な理由は出力のメッセージで確認できます。

 0/5 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 4 Insufficient memory.

• ノードの 1 つが汚染されています。
• 4 つのノードには要求可能なメモリが十分にありませんでした。

この問題を解決するには、2 つの選択肢があります。

• ポッド定義のリソース要求サイズを減らします。
• ノードを追加するか、各ノードのサイズを増やすことで、クラスターの容量を増やします。

現在実行中のワークロードを更新する場合、考慮すべきもう 1 つの重要な要素として、アップグレード戦略があります。

この戦略により、Kubernetes は更新中にワークロードが通常よりも多くのポッドを作成できるようにし、新しいポッドが作成されている間、古いポッドを一定期間保持することができます。これは、ワークロードが一定期間、予想よりも多くのリソースを要求する可能性があることを意味します。クラスターに十分な予備リソースがない場合、更新はブロックされ、プロセスがブロック解除されるまで (またはロールバック タイムアウトによって更新が停止されるまで) 一部のポッドは保留状態になります。

画像の問題によりポッドは保留中

ポッドがノードに割り当てられると、kubelet はポッド内のすべてのコンテナを起動しようとします。これを行うには、イメージをダウンロードして実行しようとします。

画像のダウンロードを妨げる可能性のあるエラーがいくつかあります。

• 画像名が間違っています。
• 画像タグが間違っています。
• ストレージリポジトリが間違っています。
• リポジトリには認証が必要です。

依存関係の問題によりKubernetes Podがハングする

ポッドが起動する前に、kubelet は他の Kubernetes 要素とのすべての依存関係をチェックしようとします。これらの依存関係のいずれかを満たすことができない場合、依存関係が満たされるまでポッドは保留状態のままになります。

この場合、kubectl はポッドを次のように表示します。

 $ kubectl -n mysql get pods NAME READY STATUS RESTARTS AGE mysql-0 0/1 ContainerCreating 0 97s

このイベントでは、次のことがわかります。

 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m19s default-scheduler Successfully assigned mysql/mysql-0 to ip-172-20-38-115.eu-west-1.compute.internal Warning FailedMount 76s kubelet Unable to attach or mount volumes: unmounted volumes=[config], unattached volumes=[kube-api-access-gxjf8 data config]: timed out waiting for the condition Warning FailedMount 71s (x9 over 3m19s) kubelet MountVolume.SetUp failed for volume "config" : configmap "mysql" not found

メッセージ列には、不足している要素を正確に特定するのに十分な情報が表示されます。一般的な原因は次のとおりです:

• ConfigMap または Secret が作成されていないか、指定された名前が正しくありません。
• ボリュームは別のノードによって解放されていないため、ノードにマウントできません。これは特に、マウントされたボリュームが古いポッドと同じである必要があるステートフルセットを更新するときに発生します。

結論は

ポッドが保留フェーズのままである理由を理解することは、Kubernetes でワークロードを安全にデプロイおよび更新するための鍵となります。問題を素早く特定し、展開を高速化できれば、頭痛の種が減り、ダウンタイムが短縮されます。