10日で覚えるKubernetesDay 3: Podを理解する
books.chapter 310日で覚えるKubernetes

Day 3: Podを理解する

今日学ぶこと

  • Podとは何か、なぜコンテナではなくPod単位なのか
  • Podのライフサイクルと状態遷移
  • マルチコンテナPodのパターン
  • Probe（プローブ）によるヘルスチェック

Podとは

PodはKubernetesにおけるデプロイの最小単位です。1つ以上のコンテナをまとめたグループで、同じネットワーク空間とストレージを共有します。

Dockerでは個々のコンテナが管理単位でしたが、Kubernetesではコンテナを直接管理しません。必ずPodという単位でラップされます。

flowchart TB
    subgraph Pod["Pod"]
        C1["コンテナ A"]
        C2["コンテナ B"]
        NET["共有ネットワーク\n(localhost)"]
        VOL["共有ボリューム"]
    end
    C1 --- NET
    C2 --- NET
    C1 --- VOL
    C2 --- VOL
    style Pod fill:#3b82f6,color:#fff

PodとDockerコンテナの対応

特性 Docker コンテナ Kubernetes Pod
実行単位 1コンテナ 1つ以上のコンテナ
ネットワーク コンテナごとに独立 Pod内で共有（localhost）
ストレージ Volume で明示的に共有 Pod内で共有可能
IPアドレス コンテナごとに割当 Podごとに割当
スケーリング コンテナ単位 Pod単位

Podのライフサイクル

Podには以下の状態（Phase）があります。

flowchart LR
    A["Pending"] --> B["Running"]
    B --> C["Succeeded"]
    B --> D["Failed"]
    A --> D
    style A fill:#f59e0b,color:#fff
    style B fill:#22c55e,color:#fff
    style C fill:#3b82f6,color:#fff
    style D fill:#ef4444,color:#fff
Phase 説明
Pending Podが作成されたが、コンテナがまだ起動していない
Running 少なくとも1つのコンテナが実行中
Succeeded 全コンテナが正常終了
Failed 少なくとも1つのコンテナが異常終了
Unknown Pod の状態を取得できない（ノード障害等）

コンテナの状態

Pod内の各コンテナにも状態があります。

状態 説明
Waiting コンテナ起動の待機中（イメージプル等）
Running コンテナが実行中
Terminated コンテナが終了（正常/異常） 
# Podの状態を詳しく確認
kubectl describe pod my-nginx

# コンテナの状態が表示される
# State:          Running
#   Started:      Mon, 27 Jan 2026 10:00:00 +0900
# Ready:          True
# Restart Count:  0

Pod定義の詳細

より実践的なPod定義を見てみましょう。

apiVersion: v1
kind: Pod
metadata:
  name: web-app
  labels:
    app: web
    environment: development
  annotations:
    description: "Sample web application pod"
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
          protocol: TCP
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "250m"
          memory: "256Mi"
      env:
        - name: APP_ENV
          value: "development"
  restartPolicy: Always

labels（ラベル）

ラベルはリソースを識別するためのキーバリューペアです。Kubernetesの多くの機能がラベルに依存しています。

metadata:
  labels:
    app: web           # アプリケーション名
    environment: prod  # 環境
    version: v1.0      # バージョン

# ラベルでフィルタリング
kubectl get pods -l app=web
kubectl get pods -l environment=prod
kubectl get pods -l 'app=web,environment=prod'

# ラベルの追加
kubectl label pod web-app tier=frontend

# ラベルの表示
kubectl get pods --show-labels

resources（リソース制限）

Docker書籍で学んだリソース制限と同様に、Kubernetesでもコンテナのリソースを制御できます。

設定 説明
requests コンテナに保証されるリソース量。スケジューリングに使用
limits コンテナが使用できるリソースの上限 
resources:
  requests:
    cpu: "100m"       # 0.1 CPUコア
    memory: "128Mi"   # 128 MiB
  limits:
    cpu: "250m"       # 0.25 CPUコア
    memory: "256Mi"   # 256 MiB

CPUは「ミリコア（m）」で指定します。1000m = 1 CPUです。

restartPolicy（再起動ポリシー）

ポリシー 説明
Always コンテナが終了すると常に再起動（デフォルト）
OnFailure 異常終了した場合のみ再起動
Never 再起動しない

マルチコンテナPod

1つのPodに複数のコンテナを含めるパターンがあります。密接に連携するコンテナをまとめるために使います。

サイドカーパターン

メインコンテナを補助するコンテナを追加するパターンです。

flowchart LR
    subgraph Pod["Pod"]
        MAIN["メインコンテナ\n(Webアプリ)"]
        SIDE["サイドカー\n(ログ収集)"]
        VOL["共有ボリューム\n(/var/log)"]
    end
    MAIN --> VOL
    SIDE --> VOL
    SIDE --> EXT["外部ログ\nシステム"]
    style Pod fill:#3b82f6,color:#fff
    style EXT fill:#8b5cf6,color:#fff

apiVersion: v1
kind: Pod
metadata:
  name: web-with-sidecar
spec:
  containers:
    - name: web
      image: nginx:1.27
      volumeMounts:
        - name: logs
          mountPath: /var/log/nginx
    - name: log-collector
      image: busybox:1.37
      command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]
      volumeMounts:
        - name: logs
          mountPath: /var/log/nginx
  volumes:
    - name: logs
      emptyDir: {}

主なマルチコンテナパターン

パターン 説明 例
サイドカー メインコンテナを補助 ログ収集、プロキシ
アンバサダー 外部通信を仲介 DB接続プロキシ
アダプター 出力形式を変換 メトリクス変換

Init Container

Podのメインコンテナが起動する前に実行される特殊なコンテナです。初期化処理やDBマイグレーションなどに使います。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.37
      command: ['sh', '-c', 'until nc -z db-service 5432; do echo waiting for db; sleep 2; done']
  containers:
    - name: app
      image: my-app:1.0

flowchart LR
    I1["Init Container 1\n(DB待機)"] --> I2["Init Container 2\n(設定取得)"]
    I2 --> M["メインコンテナ\n(アプリ起動)"]
    style I1 fill:#f59e0b,color:#fff
    style I2 fill:#f59e0b,color:#fff
    style M fill:#22c55e,color:#fff

Init Containerの特徴：

  • 順番に1つずつ実行される
  • 全てのInit Containerが成功しないとメインコンテナは起動しない
  • 失敗した場合、restartPolicyに従って再試行される

Probe（ヘルスチェック）

Kubernetesは3種類のProbeでコンテナの状態を監視します。Docker書籍で学んだHEALTHCHECKの発展版です。

Probe 目的 失敗時の動作
livenessProbe コンテナが生きているか確認 コンテナを再起動
readinessProbe トラフィックを受ける準備ができているか Serviceから除外
startupProbe 起動が完了したか 起動完了まで他のProbeを無効化 
apiVersion: v1
kind: Pod
metadata:
  name: web-with-probes
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 10
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 3
        periodSeconds: 5
      startupProbe:
        httpGet:
          path: /
          port: 80
        failureThreshold: 30
        periodSeconds: 10

Probeの種類

flowchart TB
    subgraph ProbeTypes["Probe の実行方法"]
        HTTP["httpGet\nHTTPリクエスト"]
        TCP["tcpSocket\nTCP接続"]
        CMD["exec\nコマンド実行"]
        GRPC["grpc\ngRPCヘルスチェック"]
    end
    style ProbeTypes fill:#8b5cf6,color:#fff
方法 説明 使用例
httpGet HTTPエンドポイントに200-399を期待 Webサーバー
tcpSocket TCPポートへの接続を試行 データベース
exec コンテナ内でコマンドを実行し終了コード0を期待 カスタムチェック
grpc gRPCヘルスチェックプロトコル gRPCサービス

実践: Podの操作

Pod内のコンテナにアクセス

# シェルでアクセス
kubectl exec -it web-app -- /bin/bash

# マルチコンテナPodの場合、コンテナを指定
kubectl exec -it web-with-sidecar -c log-collector -- /bin/sh

# コンテナ内のファイルをローカルにコピー
kubectl cp web-app:/etc/nginx/nginx.conf ./nginx.conf

# ローカルファイルをコンテナにコピー
kubectl cp ./index.html web-app:/usr/share/nginx/html/

Podのデバッグ

# Podの詳細とイベント確認
kubectl describe pod web-app

# ログの確認
kubectl logs web-app
kubectl logs web-app -f              # リアルタイム表示
kubectl logs web-app --previous      # 前回のコンテナのログ
kubectl logs web-app -c log-collector # 特定のコンテナのログ

# リソース使用量の確認
kubectl top pod web-app

まとめ

概念 説明
Pod 1つ以上のコンテナをまとめたKubernetesの最小実行単位
ラベル リソースを識別するキーバリューペア
リソース制限 requests（保証量）とlimits（上限）でリソースを管理
マルチコンテナPod サイドカー、アンバサダー、アダプターパターン
Init Container メインコンテナ起動前に実行される初期化コンテナ
Probe liveness、readiness、startupの3種類のヘルスチェック

重要ポイント

  1. KubernetesではコンテナではなくPodが管理単位。Pod内のコンテナはネットワークとストレージを共有する
  2. ラベルはKubernetesの多くの機能の基盤。適切なラベル設計が重要
  3. Probeを適切に設定することで、Kubernetesが自動的にアプリケーションの健全性を維持する

練習問題

問題1: 基本

以下の要件でPodを作成するYAMLを書いてください。

  • 名前: my-app
  • イメージ: httpd:2.4
  • CPU requests: 50m、limits: 100m
  • Memory requests: 64Mi、limits: 128Mi
  • livenessProbeとreadinessProbeを設定（httpGet、ポート80）

問題2: マルチコンテナ

Webサーバー（nginx）とログ転送用サイドカー（busybox）を含むPodを作成してください。共有ボリュームでログを連携させましょう。

チャレンジ問題

Init Containerを使って、メインコンテナが起動する前に「welcome.html」ファイルを作成するPodを設計してください。Init Containerで作成したファイルをメインのnginxコンテナで配信します。

参考リンク

次回予告: Day 4では「ReplicaSetとDeployment」について学びます。Podを直接作成するのではなく、Deploymentを通じてPodを管理する方法を習得しましょう。