IT 技書の森

Pod

Kubernetes の最小デプロイ単位で、1 つ以上のコンテナをまとめて管理するリソース

Kubernetesコンテナ

Pod とは

Pod は Kubernetes の最小デプロイ単位で、1 つ以上のコンテナをまとめて管理するリソースである。同じ Pod 内のコンテナはネットワーク (localhost) とストレージ (Volume) を共有する。通常は 1 Pod = 1 コンテナだが、サイドカーパターンで複数コンテナを含む場合もある。

Pod の定義

apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api-server
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports:
        - containerPort: 3000
      resources:
        requests: { cpu: 100m, memory: 128Mi }
        limits: { cpu: 500m, memory: 512Mi }
      readinessProbe:
        httpGet: { path: /ready, port: 3000 }
      livenessProbe:
        httpGet: { path: /healthz, port: 3000 }

Pod のライフサイクル

Pending → Running → Succeeded / Failed
            ↓
        CrashLoopBackOff (再起動ループ)
フェーズ 説明
Pending スケジューリング待ち、イメージのプル中
Running 少なくとも 1 つのコンテナが実行中
Succeeded 全コンテナが正常終了 (Job)
Failed コンテナが異常終了
CrashLoopBackOff 起動 → クラッシュを繰り返している

サイドカーパターン

spec:
  containers:
    - name: app
      image: myapp:1.0
    - name: log-agent       # サイドカー: ログ収集
      image: fluentbit:latest
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
  volumes:
    - name: logs
      emptyDir: {}

メインコンテナとサイドカーコンテナが同じ Volume を共有し、ログ収集、プロキシ、モニタリングなどの横断的関心事を分離する。

kubectl での操作

# Pod の一覧
kubectl get pods

# Pod の詳細 (イベント、状態)
kubectl describe pod api-server

# Pod のログ
kubectl logs api-server
kubectl logs api-server -c log-agent  # サイドカーのログ

# Pod に入る
kubectl exec -it api-server -- /bin/sh

# Pod の削除
kubectl delete pod api-server

Pod を直接作らない

本番環境では Pod を直接作成せず、Deployment 経由で管理する。Deployment が Pod の数を維持し、異常終了時に自動再作成する。

✅ Deployment → ReplicaSet → Pod (自動管理)
❌ Pod を直接作成 (異常終了しても再作成されない)

ECS タスクとの比較

観点 Kubernetes Pod ECS タスク
最小単位 Pod (1+ コンテナ) タスク (1+ コンテナ)
サイドカー ネイティブ対応 サポートあり
ネットワーク Pod 内は localhost タスク内は localhost
ストレージ共有 Volume Bind mount

現場での応用を知るには関連書籍も役立つ。

関連用語