xDev Asia

Deployment戦略（RollingUpdate/Recreate）。DaemonSetのユースケース。 StatefulSetと安定したネットワークID。CKA試験でのワークロード管理。

1. Deploymentの詳細

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1         # ローリング中に追加できるPod数
      maxUnavailable: 0   # ローリング中に利用不可になれるPod数
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

戦略	動作	ダウンタイム
RollingUpdate	新旧Podを段階的に入れ替え	なし（ゼロダウンタイム）
Recreate	全Pod停止 → 新Pod起動	あり（デプロイメント間にダウンタイム）

# ロールバック
kubectl rollout undo deployment/web-app
kubectl rollout undo deployment/web-app --to-revision=2

# ロールアウト履歴
kubectl rollout history deployment/web-app
kubectl rollout status deployment/web-app

2. DaemonSet

DaemonSetは各ノードに1つのPodを配置することを保証します。

ユースケース	例
ログ収集	fluentd、filebeat
監視エージェント	Prometheus node exporter、Datadog
ネットワーキング	kube-proxy、Calico、Cilium
ストレージ	CSI node driver

# DaemonSetの作成（直接コマンドなし — YAMLが必要）
# ヒント: Deploymentから変換
kubectl create deployment ds-template --image=fluentd --dry-run=client -o yaml > ds.yaml
# kind: DaemonSetに変更、replicas削除、strategyを削除

3. StatefulSet

StatefulSet vs Deployment:
  - 安定したネットワークID: pod-0, pod-1, pod-2（Deploymentはランダムな接尾辞）
  - 順序付きデプロイ: 0 → 1 → 2の順で起動
  - 安定した永続ストレージ: 各PodにPVCが割り当て
  - Headless Service必須

ユースケース: データベース、分散システム（MySQL、Redis Cluster、Kafka）

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql-headless  # Headless Service名
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

4. チートシート

タスク	コマンド
Deployment作成	`kubectl create deploy NAME --image=IMG --replicas=N`
イメージ更新	`kubectl set image deploy/NAME CONTAINER=IMAGE:TAG`
ロールバック	`kubectl rollout undo deploy/NAME`
DaemonSet確認	`kubectl get daemonset -A`
StatefulSet確認	`kubectl get statefulset`

5. 練習問題

Q1：Deploymentのstrategy type: Recreateを使用する場合、デプロイメント中に何が起きますか？

A) 新旧Podが同時に実行される
B) 全ての旧Podが停止してから新Podが起動する — ダウンタイムが発生 ✓
C) 1つのPodずつ順次更新される
D) トラフィックが自動的に新Podにルーティングされる

解説：Recreate戦略は全ての旧Podを停止してから新Podを起動します。RollingUpdateではゼロダウンタイムで更新できますが、アプリケーションが旧新バージョンの同時実行をサポートしない場合はRecreateを使用します。

Q2：DaemonSetのPodはどのようにスケジューリングされますか？

A) kube-schedulerがノードを選択する
B) DaemonSetコントローラーが各ノードに1つのPodを自動配置する ✓
C) ユーザーが手動でnodeSelectorを設定する必要がある
D) ランダムなノードに配置される

解説：DaemonSetコントローラーが各ノードに1つのPodを自動配置します。新しいノードが追加されると、自動的にPodが作成されます。tolerationを使用してコントロールプレーンノードにも配置できます。

Q3：StatefulSetでserviceNameフィールドが必要な理由は？

A) ロードバランシングのため
B) 各PodにDNSレコード（pod-0.serviceName）を提供するHeadless Serviceが必要なため ✓
C) 自動スケーリングを有効にするため
D) ストレージプロビジョニングのため

解説：StatefulSetの各Podは安定したDNS名を持ちます（例: mysql-0.mysql-headless.namespace.svc.cluster.local）。これにはHeadless Service（clusterIP: None）が必要です。serviceName はこのHeadless Serviceを参照します。

レッスン4: Deployments、DaemonSets & StatefulSets

1. Deploymentの詳細

2. DaemonSet

3. StatefulSet

4. チートシート

5. 練習問題