1. Pod — 最小単位
Podは1つ以上のコンテナのグループで、同じネットワークネームスペース（同一IP、ポート空間）とストレージボリュームを共有します。PodはKubernetesにおけるスケジューリングの単位です。
┌─────────────────────────────────────┐
│ POD │
│ IP: 10.244.1.5 │
│ ┌────────────┐ ┌───────────────┐ │
│ │ Container │ │ Sidecar │ │
│ │ (app) │ │ (log-agent) │ │
│ └────────────┘ └───────────────┘ │
│ Shared Volume: /var/log │
└─────────────────────────────────────┘Podライフサイクル
| Phase | 意味 | デバッグヒント |
|---|---|---|
| Pending | まだスケジュールされていないか、イメージをプル中 | イベントを確認：kubectl describe pod |
| Running | 実行中、少なくとも1つのコンテナがアクティブ | 正常な状態 |
| Succeeded | すべてのコンテナがコード0で終了 | Jobが完了 |
| Failed | 少なくとも1つのコンテナがエラーで終了 | kubectl logs --previous |
| Unknown | ノードとの通信ができない | ノードのネットワーク問題 |
| CrashLoopBackOff | コンテナが繰り返しクラッシュと再起動 | kubectl logs -p |
試験のポイント： CrashLoopBackOffは正式なPodフェーズではありません。WaitingのContainerステートです。「pod phase」と「container state」の違いを問う問題が出ます。
2. ワークロードコントローラー
| コントローラー | 使用場面 | 主な特徴 |
|---|---|---|
| Deployment | ステートレスアプリ（Webサーバー、API） | ローリングアップデート、ロールバック、ReplicaSet管理 |
| ReplicaSet | N個のレプリカを保証（通常はDeployment経由で使用） | ラベルセレクター、直接使用することは稀 |
| StatefulSet | ステートフルアプリ（データベース、Kafka、Elasticsearch） | 安定したPod名（web-0、web-1）、安定したストレージ、順序付きデプロイ |
| DaemonSet | すべてのノードで実行するエージェント（ロギング、モニタリング、ネットワーク） | 1 Pod/ノード、新しいノード参加時に自動デプロイ |
| Job | 完了まで実行するバッチタスク | completions、parallelism、backoffLimit |
| CronJob | 定期的なバッチタスク | cron構文、concurrencyPolicy、schedule |
Deployment vs StatefulSet
DEPLOYMENT (Stateless) STATEFULSET (Stateful)
───────────────────── ────────────────────────
Pod names: web-a1b2c3 Pod names: web-0, web-1, web-2
Any order scale up/down Ordered: web-0 first, then web-1...
Shared or no storage Each Pod gets its own PVC
Pod replaced = new identity Pod replaced = same identity
Examples: nginx, api-server Examples: MySQL, MongoDB, Kafka3. ラベル、セレクター、アノテーション
| 概念 | 用途 | 例 |
|---|---|---|
| Labels | リソースにタグを付けてselectやgroup | app: frontend, env: prod |
| Selectors | ラベルでリソースをクエリ | selector: {app: frontend} |
| Annotations | select用ではないメタデータ（ビルド情報、連絡先） | maintainer: [email protected] |
試験のポイント： ServiceはPodのlabelsに一致するselectorでPodを見つけます。selectorが一致しない場合、ServiceのEndpointsは空になり、トラフィックがPodに到達しません。
4. DaemonSetのユースケース
NODE 1 NODE 2 NODE 3
┌──────┐ ┌──────┐ ┌──────┐
│fluentd│ │fluentd│ │fluentd│ ← ログコレクターDaemonSet
│ Pod │ │ Pod │ │ Pod │
├──────┤ ├──────┤ ├──────┤
│calico│ │calico│ │calico│ ← CNIネットワークプラグインDaemonSet
│ Pod │ │ Pod │ │ Pod │
└──────┘ └──────┘ └──────┘DaemonSetの一般的な用途：Fluentd/Filebeat（ログ収集）、Prometheus Node Exporter（メトリクス）、kube-proxy（ネットワーキング）、CNIプラグイン（Calico、Cilium）。
5. チートシート
| 試験の質問 | 回答 |
|---|---|
| ステートフルアプリ、安定したIDが必要？ | StatefulSet |
| ノードごとに1 Pod（監視エージェント）？ | DaemonSet |
| ステートレスアプリでローリングアップデート？ | Deployment |
| 一度限りのバッチ処理？ | Job |
| スケジュールされたバッチ（夜間バックアップ）？ | CronJob |
| StatefulSetのPod命名パターン？ | name-0, name-1, name-2 |
6. 練習問題
Q1: 安定したネットワークIDとレプリカごとの専用ストレージを持つMySQLデータベースをKubernetesにデプロイする必要があります。どのワークロードタイプを使用すべきですか？
- A) PersistentVolumeClaimを持つDeployment
- B) StatefulSet ✓
- C) DaemonSet
- D) ReplicaSet
解説：StatefulSetは安定したPod名（mysql-0、mysql-1）、順序付きデプロイ/スケーリングを提供し、各PodがvolumeClaimTemplates経由で独自のPVCを取得します。これらの特性はデータベースに不可欠です。
Q2: クラスター内のすべてのノード（将来参加するノードを含む）で正確に1つのPodが実行されることを保証するワークロードはどれですか？
- A) ノード数に一致するレプリカを持つDeployment
- B) nodeSelectorを持つReplicaSet
- C) DaemonSet ✓
- D) StatefulSet
解説：DaemonSetは自動的にノードごとに1つのPodをデプロイし、クラスターメンバーシップを監視します。新しいノードが参加すると、DaemonSetコントローラーは直ちにそのノード上にPodを作成します。
Q3: PodがPending状態にあります。最も可能性の高い原因は何ですか？
- A) コンテナアプリケーションがクラッシュした
- B) スケジューリング要件を満たすノードがない ✓
- C) livenessプローブが失敗した
- D) コンテナイメージが破損している
解説：Pendingは、Podが受け入れられたがまだ開始されていないことを意味します。最も一般的な理由：ノードのCPU/メモリ不足、ノードアフィニティ/taintの条件未達、PVCが未バインド。kubectl describe podのイベントを確認してください。