xDev Asia

Sidecar、Ambassador、Adapterパターン。Init Containersの仕組みとユースケース。通常コンテナとの違い、実践的なYAML例とCKAD練習問題。

マルチコンテナPodパターン — Sidecar、Ambassador、Adapter

1. マルチコンテナPodパターン

パターン	機能	例
Sidecar	メインコンテナの機能を拡張（logging、monitoringなど）	Fluentdでログ収集、Envoy proxy
Ambassador	外部サービスへのProxy/Load Balancer	Redis proxy、DB connection pooler
Adapter	メインコンテナの出力を標準化	ログフォーマット変換、metrics変換

Sidecar Pattern:

  ┌──────────────────────────────────┐
  │           Pod                     │
  │  ┌─────────────┐ ┌────────────┐  │
  │  │  Main App    │ │  Sidecar   │  │
  │  │  (nginx)     │ │  (fluentd) │  │
  │  └──────┬───────┘ └─────┬──────┘  │
  │         │    shared     │          │
  │         └──── volume ───┘          │
  │              /var/log              │
  └──────────────────────────────────┘

2. マルチコンテナPod YAML

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app                    # メインコンテナ
    image: nginx:1.25
    ports:
    - containerPort: 80
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  - name: sidecar-logger         # Sidecarコンテナ
    image: fluentd:v1.16
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx  # 同じvolumeをマウント
      readOnly: true

  volumes:
  - name: shared-logs
    emptyDir: {}                 # Pod内コンテナ間の共有storage

試験のポイント: CKADではSidecarパターンが最も頻出。同じPod内のコンテナはネットワーク（localhost）とストレージ（shared volumes）を共有します。emptyDirはPodの存在期間中だけ存在する一時ストレージです。

3. Init Containers

Init Containersはメインコンテナの前に順番に実行されます。すべてのInit Containerが成功した後にメインコンテナが起動します。

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  initContainers:
  - name: wait-for-db           # Init 1: DBの起動を待つ
    image: busybox
    command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']

  - name: db-migrate            # Init 2: マイグレーション実行
    image: myapp:migrate
    command: ['python', 'manage.py', 'migrate']

  containers:
  - name: app                   # Init成功後に起動
    image: myapp:latest
    ports:
    - containerPort: 8080

4. Init Containers vs 通常のコンテナ

特徴	Init Containers	通常のコンテナ
実行タイミング	メインコンテナの前に順番に実行	同時並行で実行
完了条件	成功して終了（exit 0）する必要がある	継続的に実行
失敗時の動作	成功するまで再起動	restartPolicyに従う
Probes	Probes未対応	liveness/readiness/startup対応
ユースケース	前提条件チェック、データ初期化	アプリケーション実行

5. チートシート

タスク	コマンド
Podのコンテナ一覧	`kubectl describe pod <name>`
特定コンテナのログ	`kubectl logs <pod> -c <container>`
Init containerのログ	`kubectl logs <pod> -c <init-container>`
コンテナにexec	`kubectl exec -it <pod> -c <container> -- sh`

6. 練習問題

Q1: Pod内にnginxコンテナとfluentd sidecarコンテナがあります。nginxが/var/log/nginx/にログを書き込みます。fluentdがそのログを読むにはどうすればよいですか？

A) Fluentdがlocalhostのnginxのファイルシステムにアクセスする
B) /var/log/nginx/にemptyDirボリュームをマウントし、両コンテナで共有する ✓
C) FluentdがnginxログをHTTP経由でpullする
D) hostPathボリュームを使用する

解説: 同じPod内のコンテナはemptyDirボリュームでストレージを共有できます。両コンテナが同じパスにボリュームをマウントします。emptyDirはPodのライフサイクルに紐づいた一時ストレージです。コンテナは直接お互いのファイルシステムにアクセスできません。

Q2: Init Containerが失敗した場合、Podの動作はどうなりますか？

A) 失敗したInit Containerをスキップしてメインコンテナを起動する
B) Init Containerを成功するまで再起動する（PodのrestartPolicyに従う） ✓
C) Pod全体が直ちに削除される
D) メインコンテナは起動するが「degraded」状態で実行される

解説: Init Containerが失敗すると、KubernetesはPodのrestartPolicyに従って再起動を試みます。すべてのInit Containerが成功するまでメインコンテナは起動しません。restartPolicy: Neverの場合、Podは失敗状態のままになります。

Q3: 以下のうちInit Containersの有効なユースケースはどれですか？

A) アプリケーションの継続的なヘルスチェック
B) メインアプリが起動する前にデータベースの可用性を確認する ✓
C) Sidecarとしてのログ収集
D) Service endpointとしてのトラフィック提供