Podのライフサイクルと状態

Podは静的なものではなく、旅のようにさまざまな段階を経ます。この「ライフサイクル」を理解することは、Kubernetesでアプリケーションを効果的に管理するうえで重要です。

アプリが正常か、起動中か、問題が発生しているかを把握できるようになります。

Kubernetesでは、Podを5つの主要なフェーズに分類します。これらのフェーズによって、Podの現在の状態を大まかに把握できます。

• Pending：PodはKubernetesに受け付けられていますが、コンテナはまだ起動していません。
• Running：Pod内の少なくとも1つのコンテナが実行中または起動中です。
• Succeeded：Pod内のすべてのコンテナが正常に完了し、再起動されることはありません。
• Failed：すべてのコンテナが終了し、そのうち少なくとも1つが失敗しました（例：ゼロ以外の終了コードで終了）。
• Unknown：Podの状態を判定できません。多くの場合、通信に問題があります。

PodがKubernetes APIサーバーに受け付けられたものの、1つ以上のコンテナがまだ作成または設定されていない場合、PodはPendingフェーズになります。

一般的な原因は次のとおりです。

• コンテナイメージをまだダウンロード中です。
• クラスターにPodをスケジュールするための十分なリソース（CPUやメモリ）がありません。
• ボリュームをまだプロビジョニング中またはマウント中です。

例を見てみましょう。存在しないイメージを使ってPodをデプロイしようとすると、「Pending」のままになるか、イメージのプルエラーが表示されることがあります。

Pod定義の例を示します。

apiVersion: v1
kind: Pod
metadata:
  name: pending-pod-demo
spec:
  containers:
  - name: my-container
    image: non-existent-image:latest
    ports:
    - containerPort: 80

状態を確認するには、kubectl get podを使います。次のような結果が表示されることがあります。

$ kubectl get pod pending-pod-demo
NAME               READY   STATUS         RESTARTS   AGE
pending-pod-demo   0/1     ErrImagePull   0          5s

ErrImagePullはイメージを取得できなかったことを示しており、そのためPodはRunning状態になりません。

Runningフェーズは、Podがノードに割り当てられ、すべてのコンテナが正常に作成された状態を意味します。少なくとも1つのコンテナが実行中であるか、起動中または再起動中です。

Running状態のPodだからといって、その中のアプリケーションが正常に動作している、または完全に機能しているとは限らない点に注意してください。これは、コンテナがアクティブであることを示しているだけです。

これは、Nginx Webサーバー用の標準的なPod定義です。これを適用すると、Podはすぐに「Running」状態になるはずです。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

デプロイ後、kubectl get podを実行すると、次のように表示されます。

$ kubectl get pod nginx-pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          10s

READYの1/1は、定義された1つのコンテナのうち、1つがReady状態であることを示しています。

これらのフェーズは、Podの終了状態を表します。

• Succeeded：Pod内のすべてのコンテナが正常に終了し、再起動されない場合に、このフェーズになります。単発のタスクやバッチジョブを実行するPodでよく見られます。
• Failed：Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが失敗して終了した場合（ゼロ以外の終了ステータスコードで終了した場合など）、PodはFailedフェーズになります。

これらを理解すると、ジョブの完了状況やアプリケーションのエラーを診断しやすくなります。

Unknownフェーズは、Podの状態を判定できないことを意味します。これはまれですが、重大なフェーズです。

通常、Podが実行されているノード上のKubelet（エージェント）が、Kubernetes APIサーバーとの通信を停止した場合に発生します。ネットワークの問題、Kubeletのクラッシュ、またはノード自体の問題などが原因として考えられます。

Pod全体にはフェーズがありますが、Pod内の個々のコンテナにも、より詳細な独自の状態があります。これらの状態は、Pod全体のフェーズに直接影響します。

• Waiting：コンテナが現在、起動を待機しています。イメージの取得、リソースの割り当て、initコンテナの完了待ちなどが理由になります。
• Running：コンテナが問題なく実行中です。
• Terminated：コンテナの実行が完了しています。正常終了の場合も失敗の場合もあります。

新しいPodをデプロイしたばかりだとします。kubectl get pod my-appを実行すると、次の出力が表示されました。

NAME      READY   STATUS     RESTARTS   AGE
my-app    0/1     Pending    0          12s

my-app Podが0/1個のコンテナがReady状態で、Pending状態になっている最も可能性の高い理由は何でしょうか？

KubernetesのPodは、Pending、Running、Succeeded、Failed、Unknownという異なるフェーズを順に進むことを学びました。これらのフェーズから、Podの運用状態を大まかに把握できます。

また、Pod全体のフェーズに影響する個々のコンテナ状態（Waiting、Running、Terminated）についても触れました。kubectl get podやkubectl describe pod（詳しくは後のレッスンで扱います）を使ってこれらの状態を監視することは、アプリケーションの健全性を理解するうえで重要です。

次は、より高度なPodパターンとして、サイドカーパターンを使って1つのPod内で複数のコンテナを同じ場所に配置して実行する方法を見ていきます。