K8s Deployment+3Probe【CKAD第12回】

DB 接続の有無は readinessProbe（/health/ready）が担当します。DB 切断時には readinessProbe が DOWN を返して該当 Pod だけが Endpoints から外れ、DB が復旧すれば自動で Endpoints に戻る、という挙動になります。

「livenessProbe で DB 接続を確認しない」という設計は MicroProfile Health 公式ガイドラインでも推奨されており、本シリーズ全体の方針として採用します。

Probe パラメータ詳解 — failureThreshold・periodSeconds・initialDelaySeconds・timeoutSeconds

各 Probe には複数のパラメータがあり、組み合わせによって挙動が大きく変わります。本セクションで定量的に整理し、Payara Micro の起動時間（約 7,471 ms = 7.5 秒）を根拠とした設計値を確定します。

Probe 共通パラメータ一覧

startupProbe の設計計算（Payara Micro 実測値ベース）

本シリーズでは startupProbe を failureThreshold: 30 + periodSeconds: 10 で設計します。計算根拠を示します。

Payara Micro 起動時間実測値: 約 7,471 ms (= 7.5 秒・ep3 PoC 実機確認値)

startupProbe 設定:
  failureThreshold: 30
  periodSeconds: 10
  最大待機時間: 30 × 10 = 300 秒 (= 5 分)

設計余裕: 300 秒 ÷ 7.5 秒 ≒ 40 倍
余裕の意図: 高負荷ノード・コールドスタート・JVM ウォームアップの分散・Init Container の DB 接続待ちを含めた最悪ケース

40 倍は過剰に見えますが、本番では JVM の GC やクラウド環境のディスク I/O 揺らぎで起動が 30 秒以上かかる場面もあるため、5 分の上限は現実的な値です。設計時に「最大待機時間 = failureThreshold × periodSeconds」の式を必ず計算し、ピアレビューで根拠を明示するのが運用の定石です。

livenessProbe / readinessProbe のパラメータ設計

本シリーズでは livenessProbe と readinessProbe を以下の値で設計します。

readinessProbe の periodSeconds: 5 は livenessProbe より短く設定しています。理由は「Service への投入判定（追加 / 除外）はリアルタイム性が求められる」ためです。本番でロードバランサ前段の Pod が一時的に DB 接続を失った場合、5 秒以内に Endpoints から除外して影響を最小化したい、という運用要件です。

パラメータ設計のアンチパターン

やってみよう②：Deployment に 3 Probe を追加して Rolling Update を実施する

演習①で作成した Deployment に 3 Probe を追加し、kubectl apply で Rolling Update がトリガーされる様子を観察します。

さらに kubectl set env で環境変数を追加して 2 回目の Rolling Update を実施し、kubectl rollout history で履歴確認、kubectl rollout undo でロールバックを体験します。所要時間目安は約 35 分です。

演習の全体フローは以下のとおりです。

1. fanclub-backend-deployment.yaml に 3 Probe を追加して保存
2. kubectl apply で更新（リビジョン 2 が生成される）
3. kubectl rollout status で進行確認
4. kubectl get pods で 2 Pod が Running/Ready を確認
5. kubectl rollout history でリビジョン 1→2 の履歴確認
6. kubectl annotate で CHANGE-CAUSE を付与
7. kubectl set env で環境変数を追加 → リビジョン 3 を生成
8. kubectl rollout history でリビジョン 3 を確認
9. kubectl rollout undo でロールバック → リビジョン 4（= リビジョン 2 内容）が生成
10. kubectl describe deployment で 3 Probe 設定を確認

Step 1: 3 Probe 追加版の Deployment YAML を作成

演習①の fanclub-backend-deployment.yaml を編集し、spec.template.spec.containers[0] に startupProbe / livenessProbe / readinessProbe の 3 つを追加します。

実行コマンド：

$ vi ~/fanclub-manifests/fanclub-backend-deployment.yaml

ファイル内容（3 Probe 追加版・全量）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fanclub-backend-deployment
  namespace: default
  labels:
    app: fanclub-backend
spec:
  replicas: 2
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: fanclub-backend
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: fanclub-backend
    spec:
      serviceAccountName: fanclub-backend-sa
      automountServiceAccountToken: false
      initContainers:
        - name: wait-for-db
          image: busybox:1.36
          imagePullPolicy: IfNotPresent
          command:
            - sh
            - -c
            - "until nc -z fanclub-db 5432; do echo waiting for db; sleep 2; done"
      containers:
        - name: fanclub-backend
          image: fanclub-backend:0.1.0
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: fanclub-config
            - secretRef:
                name: fanclub-secret
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "1000m"
          startupProbe:
            httpGet:
              path: /health/started
              port: 8080
            failureThreshold: 30
            periodSeconds: 10
            timeoutSeconds: 5
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
            failureThreshold: 3
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            failureThreshold: 3
            timeoutSeconds: 5

3 Probe の port: 8080 はコンテナの containerPort: 8080 と一致させます。Probe は Pod の中から localhost に対して実行されるため、Service の port ではなくコンテナポートを指定します。

Step 2: apply で Rolling Update をトリガー

実行コマンド：

$ kubectl apply -f ~/fanclub-manifests/fanclub-backend-deployment.yaml

実行結果：

deployment.apps/fanclub-backend-deployment configured

configured が返れば Pod テンプレートに変更があったため Rolling Update がトリガーされます。Pod テンプレートのハッシュ値が変わるため、新 ReplicaSet（リビジョン 2）が生成されます。

Step 3: rollout status で進行確認

Rolling Update の進行状況をリアルタイム確認します。rollout status は更新完了までブロックする同期コマンドです。

実行コマンド：

$ kubectl rollout status deployment/fanclub-backend-deployment -n default

実行結果：

Waiting for deployment "fanclub-backend-deployment" rollout to finish: 0 out of 2 new replicas have been updated...
Waiting for deployment "fanclub-backend-deployment" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "fanclub-backend-deployment" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "fanclub-backend-deployment" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "fanclub-backend-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "fanclub-backend-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "fanclub-backend-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "fanclub-backend-deployment" successfully rolled out

新 Pod が Ready になるまで startupProbe（最大 300 秒）の余裕分の待機が発生する可能性があります。実際は Payara Micro が約 7.5 秒で起動するため、おおむね 30〜60 秒で完了します。

Step 4: ReplicaSet と Pod の状態を確認

実行コマンド：

$ kubectl get replicaset,pods -l app=fanclub-backend -n default

実行結果：

NAME                                                    DESIRED   CURRENT   READY   AGE
replicaset.apps/fanclub-backend-deployment-7df85c6644   0         0         0       2m36s
replicaset.apps/fanclub-backend-deployment-86cf676cf7   2         2         2       71s

NAME                                              READY   STATUS    RESTARTS   AGE
pod/fanclub-backend-deployment-86cf676cf7-m9z4f   1/1     Running   0          71s
pod/fanclub-backend-deployment-86cf676cf7-gp58r   1/1     Running   0          55s

旧 ReplicaSet が DESIRED 0 / READY 0 で残存している点が重要です。kubectl rollout undo でロールバックする際、この旧 ReplicaSet の Pod テンプレートを元に新しい ReplicaSet が再生成されます。完全削除されているわけではない、というのが「リビジョン保持」の実体です。

Step 5: rollout history で履歴を確認

実行コマンド：

$ kubectl rollout history deployment/fanclub-backend-deployment -n default

実行結果（リビジョン 1 と 2 が表示される）：

deployment.apps/fanclub-backend-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

リビジョン 1 が初版（Probe なし）、リビジョン 2 が現在の 3 Probe 追加版です。CHANGE-CAUSE 列が <none> なのは、まだアノテーションを付与していないためです。次のステップで付与します。

Step 6: CHANGE-CAUSE アノテーションを付与

運用では「いつ何のために更新したか」を後追いできるように kubernetes.io/change-cause アノテーションを必ず付ける文化を作ります。

実行コマンド：

$ kubectl annotate deployment fanclub-backend-deployment kubernetes.io/change-cause="3 Probe 追加 (startup/liveness/readiness)" --overwrite -n default

実行結果：

deployment.apps/fanclub-backend-deployment annotated

注意点として、annotate だけでは Pod テンプレートが変わらないため新たな Rolling Update はトリガーされません。CHANGE-CAUSE は「現リビジョン」の情報として記録されます。次の更新を行うと、annotate した内容が「直前リビジョン」のメッセージとして history に残ります。

Step 7: kubectl set env で 2 回目の Rolling Update をトリガー

同じイメージタグでは Rolling Update がトリガーされません。本演習では kubectl set env で環境変数を追加することで Pod テンプレートを変更し、Rolling Update を意図的に走らせます。

実行コマンド：

$ kubectl set env deployment/fanclub-backend-deployment DEMO_VERSION=v3 -n default

実行結果：

deployment.apps/fanclub-backend-deployment env updated

続けて完了まで待機します。

実行コマンド：

$ kubectl rollout status deployment/fanclub-backend-deployment -n default

実行結果：

deployment "fanclub-backend-deployment" successfully rolled out

Step 8: rollout history でリビジョン 3 を確認

実行コマンド：

$ kubectl rollout history deployment/fanclub-backend-deployment -n default

実行結果：

deployment.apps/fanclub-backend-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         3 Probe 追加 (startup/liveness/readiness)
3         <none>

Step 6 で annotate したメッセージがリビジョン 2 の CHANGE-CAUSE として記録されている点を確認します。「annotate した時点の現リビジョン」が後の history に「過去リビジョン」として残る、という挙動です。

Step 9: rollout undo でロールバック

1 つ前のリビジョン（リビジョン 2）の状態にロールバックします。rollout undo はリビジョンを「巻き戻す」のではなく、過去リビジョンの設定で新しいリビジョンを再生成する挙動です。リビジョン 2 の設定がリビジョン 4 として再生成されます。

実行コマンド：

$ kubectl rollout undo deployment/fanclub-backend-deployment -n default

実行結果：

deployment.apps/fanclub-backend-deployment rolled back

続けて履歴を確認します。

実行コマンド：

$ kubectl rollout history deployment/fanclub-backend-deployment -n default

実行結果：

deployment.apps/fanclub-backend-deployment
REVISION  CHANGE-CAUSE
1         <none>
3         <none>
4         <none>

注意：rollout undo するとリビジョン 2 自体は履歴から消え、リビジョン 4 として再登場します。これは「同じ Pod テンプレートが二重に履歴に残らない」設計のためで、history 上は一見リビジョンが飛んだように見えます。慣れるまで戸惑いやすい挙動なので、CKAD 試験でも頻出の理解度確認ポイントです。

特定のリビジョンに戻したい場合は kubectl rollout undo deployment/<name> --to-revision=N を使います。--to-revision=1 なら初版（Probe なし）に戻ります。本演習では undo（リビジョン 2 への暗黙ロールバック）のみ実行します。

Step 10: describe で 3 Probe 設定を確認

実行コマンド：

$ kubectl describe deployment fanclub-backend-deployment -n default

実行結果（Pod Template > Containers > Liveness / Readiness / Startup の 3 行）：

Pod Template:
  Labels:           app=fanclub-backend
  Service Account:  fanclub-backend-sa
  Init Containers:
   wait-for-db:
    Image:  busybox:1.36
  Containers:
   fanclub-backend:
    Image:  fanclub-backend:0.1.0
    Port:   8080/TCP
    Liveness:   http-get http://:8080/health/live delay=30s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:8080/health/ready delay=5s timeout=5s period=5s #success=1 #failure=3
    Startup:    http-get http://:8080/health/started delay=0s timeout=5s period=10s #success=1 #failure=30

3 行が出力されていれば 3 Probe が正しく設定されています。#failure=30（startupProbe）/ #failure=3（liveness/readiness）の値が設計通りです。

実機観察ポイント：Rolling Update 直後に kubectl describe pod の Events で以下のような一過性の Warning が出ることがあります。

Warning  Unhealthy  9s    kubelet    spec.containers{fanclub-backend}: Startup probe failed: HTTP probe failed with statuscode: 503

これは Payara Micro が起動中（JVM 初期化中）に startupProbe が最初のチェックを行い、まだ /health/started が HTTP 503 を返している瞬間に記録された一過性の失敗です。failureThreshold: 30 の余裕があるため、数秒後に Payara Micro の起動が完了して UP（HTTP 200）を返すと startupProbe が成功し、以降は liveness / readiness が正常に評価されます。

この Warning は設計通りの動作であり、Pod 再起動には至りません。

やってみよう③：Probe デバッグ実践 — 意図的に失敗する Probe を設定して原因を特定する

livenessProbe に存在しないポート（9999）への TCP socket 接続を設定した Pod を意図的に作成し、再起動が繰り返される過程を観察します。kubectl describe の Events で Unhealthy: connection refused → Killing → Created → Started の一連を読み取り、kubectl logs --previous で再起動前のログを取得します。

さらに kubectl debug で ephemeral container を起動して同 Pod 内をライブ調査する手順も体験します。所要時間目安は約 30 分です。

演習の全体フローは以下のとおりです。

1. 意図的に壊れた Probe の Pod YAML を作成（broken-probe-pod.yaml・tcpSocket port: 9999）
2. kubectl apply で Pod を起動
3. 約 60 秒待機して RESTARTS 増加を確認
4. kubectl describe pod の Events を確認
5. kubectl logs --previous で再起動前のログを確認
6. kubectl debug ephemeral container でライブ調査
7. 修正版 Pod YAML（tcpSocket → httpGet /health/live）を作成
8. 旧 Pod を削除して修正版を apply
9. RESTARTS が 0 のままで安定することを確認
10. kubectl delete pod でクリーンアップ

Step 1: 壊れた Probe の Pod YAML を作成

livenessProbe に存在しないポート 9999 への TCP socket 接続を設定します。fanclub-backend は 9999 番ポートを Listen していないため、必ず connection refused になり Probe が連続失敗します。

実行コマンド：

$ vi ~/fanclub-manifests/broken-probe-pod.yaml

ファイル内容：

apiVersion: v1
kind: Pod
metadata:
  name: broken-probe
  labels:
    app: broken-probe
spec:
  containers:
    - name: app
      image: fanclub-backend:0.1.0
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 8080
      envFrom:
        - configMapRef:
            name: fanclub-config
        - secretRef:
            name: fanclub-secret
      livenessProbe:
        tcpSocket:
          port: 9999
        initialDelaySeconds: 10
        periodSeconds: 5
        failureThreshold: 3
        timeoutSeconds: 3

TCP socket probe は指定ポートへの接続試行で成否を判定します。HTTP probe と異なりアプリの応答内容に依存しないため、「ポートが開いているか」という単純な生死確認に使います。今回はデバッグ演習の目的で、意図的に 存在しないポート 9999 を指定して確実に connection refused を発生させます。

Step 2: Pod を apply

実行コマンド：

$ kubectl apply -f ~/fanclub-manifests/broken-probe-pod.yaml

実行結果：

pod/broken-probe created

Step 3: RESTARTS の増加を確認

初回 livenessProbe は initialDelaySeconds: 10 秒後に始まり、periodSeconds: 5 × failureThreshold: 3 = 15 秒後に再起動が発動します。合計で起動から約 60 秒後に RESTARTS が 1 になり始めます。

実行コマンド：

$ sleep 90; kubectl get pod broken-probe -n default

実行結果（RESTARTS が 1 以上 + STATUS が Running）：

NAME           READY   STATUS    RESTARTS      AGE
broken-probe   1/1     Running   1 (29s ago)   90s

STATUS が Running + RESTARTS 1 は「liveness probe 3 回連続失敗でコンテナが再起動された直後の状態」です。再起動が繰り返されると kubelet の指数バックオフが働き、再起動間隔が広がって CrashLoopBackOff に遷移することもあります。

Step 4: kubectl describe pod で Events を確認

Probe デバッグの最重要コマンドが kubectl describe pod です。Events セクションに kubelet が何を判定したかが時系列で記録されています。

実行コマンド：

$ kubectl describe pod broken-probe -n default

実行結果（Events セクション抜粋）：

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  91s                default-scheduler  Successfully assigned default/broken-probe to kind-control-plane
  Normal   Pulled     40s (x2 over 90s)  kubelet            spec.containers{app}: Container image "fanclub-backend:0.1.0" already present on machine and can be accessed by the pod
  Normal   Created    40s (x2 over 90s)  kubelet            spec.containers{app}: Container created
  Normal   Started    40s (x2 over 90s)  kubelet            spec.containers{app}: Container started
  Warning  Unhealthy  20s (x6 over 80s)  kubelet            spec.containers{app}: Liveness probe failed: dial tcp 10.244.0.53:9999: connect: connection refused
  Normal   Killing    20s (x2 over 70s)  kubelet            spec.containers{app}: Container app failed liveness probe, will be restarted

注目すべきメッセージは以下の 2 つです。

• Unhealthy: Liveness probe failed: dial tcp 10.244.0.53:9999: connect: connection refused ← 原因がここに書いてある（9999 番ポートは存在しない）
• Killing: Container app failed liveness probe, will be restarted ← 結果として再起動が発動

TCP socket probe の失敗メッセージは dial tcp <pod-ip>:<port>: connect: connection refused の形式になります。HTTP probe の HTTP probe failed with statuscode: NNN とは異なり、TCP レベルで接続拒否された状態を示します。

ポート番号誤り・対象プロセス未起動・アプリのクラッシュを疑います。

Step 5: kubectl logs --previous で再起動前のログを取得

RESTARTS が 1 以上のとき、現在の Pod インスタンスのログ（kubectl logs broken-probe）は新しいコンテナのものになります。再起動前のログを見るには --previous（または短縮形 -p）を付けます。

実行コマンド：

$ kubectl logs broken-probe --previous -n default

実行結果（Payara Micro 起動ログが表示される）：

[2026-05-10T21:45:12.305+0000] [] [INFO] [] [PayaraMicro] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1746917112305] [levelValue: 800] Payara Micro 7.2026.4 #badassfish started in 7,471 (ms)
[2026-05-10T21:45:19.820+0000] [] [WARNING] [] [KernelLogger] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1746917119820] [levelValue: 900] Container app failed liveness probe

本演習ではアプリ自身は正常に起動しています（Payara Micro started in 7,471 (ms) が確認できる）。アプリに ERROR や Exception は発生しておらず、「アプリは正常 → Probe 設定が原因」という切り分けが --previous ログから読み取れます。

TCP socket probe の場合、アプリ側には一切ログが残らないため、Events の connection refused メッセージが唯一の手がかりになります。

Step 6: kubectl debug ephemeral container でライブ調査

Pod が動いている状態で同じ namespace に ephemeral container を割り込ませて調査する kubectl debug コマンドを使います。CrashLoopBackOff 中の Pod に対して、コンテナ内のネットワーク・プロセスを生で確認できる強力なデバッグ手段で、CKAD D3「Kubernetes でのデバッグ」の Competency に対応します。

実行コマンド：

$ TARGET=broken-probe
$ kubectl debug -it $TARGET --image=curlimages/curl:8.20.0 --target=app --profile=general -n default -- sh -c 'echo "=== nc port 9999 ===" ; nc -zv localhost 9999 2>&1; echo "=== curl /health/live ==="; curl -s http://localhost:8080/health/live'

ephemeral container に入った後、Probe と同じ TCP socket 接続を手動で試みてから、正常な HTTP エンドポイントとの対比を確認します。

実行結果：

Targeting container "app". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-9l2sm.
=== nc port 9999 ===
nc: connect to localhost port 9999 (tcp) failed: Connection refused
=== curl /health/live ===
{"status":"UP","checks":[{"name":"fanclub-api-live","status":"UP","data":{}}]}

--target=app で対象コンテナの PID 名前空間を共有しているため、nc / curl は対象コンテナの localhost に届きます。ポート 9999 が Connection refused であること（TCP socket probe が失敗する理由）と、ポート 8080 の /health/live が HTTP 200 を返すこと（アプリ自体は正常）の対比が実機で確認できます。

「probe 設定誤りでポートが間違っていた」と原因が確定します。

ephemeral container は Pod を終了させずに調査を行えるため、本番でも安全に使えます。kubectl exec がコンテナイメージにシェルが含まれていない場合に使えないのに対して、kubectl debug は別イメージを差し込めるため curl/jq/tcpdump 等の調査ツールを後から持ち込めるのが利点です。CKAD 試験でも頻出のテクニックです。

/health/nonexistent  → HTTP 200  {"status":"UP","checks":[]}
/totally-bogus-path  → HTTP 404

Step 7: 修正版 Pod YAML を作成

原因が「livenessProbe の tcpSocket ポート誤り（存在しない 9999 番）」と確定したので、正しい HTTP probe（/health/live ポート 8080）に修正します。

実行コマンド：

$ vi ~/fanclub-manifests/broken-probe-pod.yaml

変更箇所（livenessProbe を tcpSocket から httpGet に変更）：

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3
  timeoutSeconds: 5

Step 8: 旧 Pod を削除して修正版を apply

Pod は spec の大半が不変フィールドのため、Probe のパス変更には Pod 削除 + 再 apply が必要です。Deployment ならこの作業は不要で、kubectl apply で自動 Rolling Update がトリガーされます（だからこそ本番では Pod 単体ではなく Deployment を使う動機になります）。

実行コマンド：

$ kubectl delete pod broken-probe -n default
$ kubectl apply -f ~/fanclub-manifests/broken-probe-pod.yaml

実行結果：

pod "broken-probe" deleted
pod/broken-probe created

Step 9: RESTARTS が 0 で安定することを確認

実行コマンド：

$ sleep 90; kubectl get pod broken-probe -n default

実行結果（RESTARTS が 0 のまま Running）：

NAME           READY   STATUS    RESTARTS   AGE
broken-probe   1/1     Running   0          90s

RESTARTS が 0 のまま 90 秒経過すれば、Probe 修正が正しく効いています。

Step 10: クリーンアップ

演習③で作成したデモ用 Pod を削除します。fanclub-backend Deployment は残します。

実行コマンド：

$ kubectl delete pod broken-probe -n default

実行結果：

pod "broken-probe" deleted

Deployment + 3 Probe の CKAD 試験頻出パターン — kubectl dry-run と explain の活用

CKAD 試験は Performance-based（実機操作）形式で、120 分の制限時間の中で複数の課題を解く必要があります。Deployment + 3 Probe 関連の頻出パターンと、それを高速に解くためのテクニックを整理します。

CKAD 試験頻出パターン 3 選

1. 「起動に N 秒かかるアプリに startupProbe を設定して liveness の誤射を防ぐ」→ failureThreshold × periodSeconds ≥ N の式で算出。例：60 秒なら failureThreshold: 12, periodSeconds: 5
2. 「Rolling Update でダウンタイムをゼロにする Deployment を作成する」→ maxSurge: 1, maxUnavailable: 0（または比率で 25% / 0）
3. 「readinessProbe が失敗したときに Service への影響を確認する」→ kubectl get endpoints <service-name> -w で Endpoints の Pod IP が外れる様子を観察

速攻テクニック：dry-run スケルトン → 手書き追加

試験では「Deployment を nginx:1.27-alpine イメージで replicas: 3 で作成し、livenessProbe を設定せよ」のような複合課題が出ます。dry-run でスケルトンを生成してから Probe を手書き追加する流れが定石です。

実行コマンド：

$ kubectl create deployment myapp --image=nginx:1.27-alpine --replicas=3 --dry-run=client -o yaml > myapp.yaml
$ vi myapp.yaml

spec.template.spec.containers[0] 配下に livenessProbe: ブロックを手書き追加して保存し、kubectl apply -f myapp.yaml で適用します。Probe のフィールド名や値が思い出せない場合は kubectl explain pod.spec.containers.livenessProbe.httpGet で確認します。

速攻テクニック：kubectl debug で実機確認

試験では「Probe 失敗の原因を特定せよ」という課題も出ます。describe で Events を読む基本フローに加えて、kubectl debug ephemeral container で対象 Pod に curl/jq/tcpdump を持ち込めると CrashLoopBackOff 中の Pod でも調査が進みます。

実行コマンド（典型形）：

$ kubectl debug -it <pod-name> --image=curlimages/curl:8.20.0 --target=<container-name> -- sh

--target は対象コンテナの PID 名前空間を共有するためのオプションです。これにより ephemeral container 内から localhost:8080 で対象コンテナのアプリにアクセスできます。指定しないと、ephemeral container は Pod の他コンテナとは独立した PID 名前空間で動きます。

速攻テクニック：rollout コマンド一覧

kubectl rollout restart は本演習②で使った kubectl set env の代替手段です。Pod テンプレートに kubectl.kubernetes.io/restartedAt アノテーションを自動付与することで Rolling Update をトリガーします。

Secret や ConfigMap を更新したけれど Pod に反映されない、というときに rollout restart で全 Pod を順次再起動するのが定石の運用テクニックです。

現場ヒヤリハット — startupProbe 不足と readinessProbe 設定漏れ

Probe の設計ミスは本番で発覚すると深刻な障害につながります。本セクションでは典型的な 2 件のヒヤリハットを根本原因と本番ガードレールまで含めて整理します。

ヒヤリハット 1: startupProbe なし・initialDelaySeconds 不足での再起動ループ

シナリオ：JVM 系アプリ（Spring Boot + Payara Micro 等）の Deployment に livenessProbe.initialDelaySeconds: 15 のみを設定した。

ローカル開発環境では起動 5〜6 秒で問題なかったが、本番の高負荷ノードでは JVM の初期化が 15〜20 秒かかることがあり、livenessProbe の最初の評価（initialDelaySeconds 経過後）が起動途中に行われて失敗 → コンテナ再起動 → また初期化 → また失敗 → CrashLoopBackOff に陥った。

確認コマンド（事故時の Events 確認）：

$ kubectl describe pod <pod-name>

実行結果（Events 抜粋）：

Events:
  Warning  Unhealthy  ...  Liveness probe failed: Get "http://10.244.0.42:8080/health/live": dial tcp 10.244.0.42:8080: connect: connection refused
  Normal   Killing    ...  Container app failed liveness probe, will be restarted
  Warning  Unhealthy  ...  Liveness probe failed: Get "http://10.244.0.42:8080/health/live": dial tcp 10.244.0.42:8080: connect: connection refused
  Normal   Killing    ...  Container app failed liveness probe, will be restarted
  ...

HTTP statuscode が connection refused（実質ステータス 0）になっているため、「アプリプロセスがまだポートを Listen していない」という状態です。アプリが起動完了する前に Probe が走っているのが原因と判定できます。

根本原因：initialDelaySeconds のみで起動遅延に対応しようとすると、起動時間のばらつきに脆弱になります。特に JVM はノードの CPU 負荷・GC 設定・JIT コンパイル状況で起動時間が大きく変動し、固定値の initialDelaySeconds ではカバーしきれません。

解決策：startupProbe を追加して liveness / readiness の評価を「起動完了後」に遅延させます。本シリーズの設計では startupProbe.failureThreshold: 30 × periodSeconds: 10 = 300 秒 の余裕を持たせています。

本番ガードレール：JVM 系・Ruby on Rails・機械学習モデルロード等、起動が遅いアプリには必ず startupProbe を設定する。failureThreshold × periodSeconds で最大起動待機時間を設計し、ピアレビューで根拠を文書化する。

CI/CD では PR レビュー時に「livenessProbe があるが startupProbe がない」を検出する Linter を導入する運用が一般的です。

ヒヤリハット 2: readinessProbe 設定漏れで起動中 Pod に Service トラフィック

シナリオ：Deployment に livenessProbe と startupProbe は設定したが readinessProbe を設定し忘れた。

Rolling Update で新 Pod が起動する際、Payara Micro の起動（約 7.5 秒）中でも Pod が Running 状態（startupProbe が成功すると Ready 判定される）になった瞬間に Service の Endpoints に追加されてしまい、本来はリクエストを受けられない瞬間にトラフィックが流れてクライアントが 503 Service Unavailable を受け取った。

確認コマンド：

$ kubectl get endpoints fanclub-backend -w

readinessProbe がない場合、Pod の Ready 条件は startupProbe 成功または「コンテナプロセスが起動した時点」で判定されます。アプリが完全にトラフィック処理可能になる前に Endpoints に追加されるタイムラグが発生します。

根本原因：readinessProbe が定義されていない場合、kubelet は startupProbe 成功（または startupProbe もない場合はプロセス起動）の時点で Pod を Ready と判定します。

アプリが内部的にまだ「DB プールの初期化中」「キャッシュロード中」等の前処理を実行している瞬間でも Service 投入されるため、503 や 500 系エラーが断続的に発生します。

解決策：readinessProbe を追加し、アプリ側で「リクエスト受付準備完了」を返すエンドポイント（例：MicroProfile Health の /health/ready）を実装する。readinessProbe が UP を返すまで Endpoints に追加されないため、Rolling Update 中のトラフィック損失を防げます。

本番ガードレール：Rolling Update 中のゼロダウンタイムには readinessProbe が必須。livenessProbe のみでは新 Pod が起動途中でリクエストを受ける時間帯が必ず発生する。3 Probe はセットで設定する文化を作る。

kubectl get endpoints <service> -w で Rolling Update 中の Endpoints 変化を観察し、Pod IP が遅れて追加されることを確認する習慣を持つと事故が減ります。

ep12 完了後の模擬アプリ状態と第4部第1回まとめ + ep13 への橋渡し

本回で fanclub-backend が単体 Pod から Deployment + 3 Probe に格上げされ、本番に近い構成になりました。第4部「ワークロード戦略」第1回として ep13・ep14 への橋渡しを行います。

ep12 完了後のクラスタ状態

fanclub-api をどう作ってきたか

第7回:  Pod (Backend) 起動
第8回:  Service で外部接続性
第9回:  StatefulSet (DB) で 3 層構成完成
第10回: ConfigMap / Secret / SA で設定外部化
第11回: Job / CronJob / DaemonSet でバッチ系・デーモン系を追加
第12回: ★ Deployment + 3 Probe で本番常駐サービス化  ← 今ここ
        - 自己回復 (replicas: 2)
        - ゼロダウンタイム更新 (RollingUpdate maxSurge:1 maxUnavailable:0)
        - ヘルスチェック完備 (startup / liveness / readiness)
        - リビジョン履歴管理 (rollout history / undo)

第3部「アプリリソース」（ep7〜ep11）でリソース基盤が揃い、第4部第1回（ep12）で「常駐サービスの本番運用準備」が完了しました。

CKAD ドメイン D2「Application Deployment」の中核 Competency「Deployment とローリングアップデートの実施」と D3「Application Observability and Maintenance」の中核 Competency「Probe とヘルスチェックの実装」「Kubernetes でのデバッグ」を本回で網羅しました。

ep13 への橋渡し

ep13 では本回で作成した fanclub-backend Deployment をベースに、複数のデプロイ戦略を実機で比較します。

• Blue/Green デプロイ：2 つの Deployment（blue / green）を別 selector で稼働させ、Service の selector を切り替えて瞬時にトラフィックを切り替える
• Canary リリース：本番 Deployment と Canary Deployment のレプリカ比率でトラフィック分割を実現する
• Recreate 戦略の詳細演習：本回で概念整理した Recreate を実際に実行してダウンタイムを実機で確認する

ep13 では本回で確認した「spec.selector は不変フィールド」という制約と正面から向き合い、Blue/Green の selector 切り替えが Deployment の再作成を伴うことを実機で扱います。CKAD D2 の残り Competency「共通デプロイ戦略の実装」を完全網羅して第4部第2回が完結します。

理解度チェック・第12回まとめ・次回予告・シリーズ一覧

理解度チェック（○×形式・9 問）

問 1：Deployment の spec.selector は一度 apply した後に kubectl apply で値を変更できる。

問 2：maxSurge: 1 / maxUnavailable: 0 に設定した Rolling Update では、更新中に常に replicas 数の Pod が稼働している状態を維持できる。

問 3：strategy.type: Recreate を設定した Deployment を更新すると、旧 Pod がすべて削除されてから新 Pod が起動するためダウンタイムが発生する。

問 4：startupProbe が成功するまでの間、livenessProbe と readinessProbe は評価されない。

問 5：readinessProbe が failureThreshold 回連続で失敗すると、コンテナが再起動される。

問 6：livenessProbe が failureThreshold 回連続で失敗すると、Pod が削除されて新しい Pod に置き換えられる。

問 7：Payara Micro のような起動が遅いアプリに対して livenessProbe.initialDelaySeconds のみで対応するより、startupProbe を使う方が起動時間のばらつきに強い。

問 8：kubectl rollout undo deployment/<name> を実行すると、Deployment 自体が削除される。

問 9：Deployment の Rolling Update 完了後、旧バージョンの ReplicaSet は完全に削除される。

解答：

第12回まとめ

第12回では以下を実施しました。

• Pod / ReplicaSet / Deployment の 3 層構造を整理した。Deployment が ReplicaSet を、ReplicaSet が Pod を管理する階層関係を kube-system の coredns / metrics-server で実機観察した。本番常駐サービスには Deployment を使うのが定石で、ReplicaSet を直接作成する場面はほぼないことを確認した
• Deployment YAML の主要フィールド（replicas / selector / template / strategy）を網羅した。spec.selector は一度 apply すると変更不可な不変フィールドで、変更には Deployment 削除 + 再作成が必要であることを確認した。kubectl create deployment --dry-run=client -o yaml でスケルトン生成 → 手書きで Probe や envFrom を追加する CKAD 試験テクニックを習得した
• Rolling Update を maxSurge: 1 / maxUnavailable: 0 のゼロダウンタイム設定で実装した。新旧 ReplicaSet の共存メカニズム、revisionHistoryLimit（本番推奨 3〜5）、kubectl rollout status / history / undo / restart の使い分けを実機で確認した。kubectl set env で Rolling Update をトリガーし、rollout undo 後のリビジョン番号が増える仕組み（リビジョン 2 → リビジョン 4 として再生成）を体験した
• 3 種の Probe（startupProbe / livenessProbe / readinessProbe）を体系的に学んだ。startupProbe は起動完了判定専用で成功するまで liveness/readiness を保留する。livenessProbe はコンテナ再起動を発動する。readinessProbe は Service Endpoints からの除外のみでコンテナは再起動されない。MicroProfile Health の /health/started / /health/live / /health/ready エンドポイントを 3 Probe に対応させ、Payara Micro 7.5 秒起動を根拠に startupProbe.failureThreshold: 30 × periodSeconds: 10 = 300 秒 を設計した
• Probe デバッグ実践として、意図的に壊れた livenessProbe（tcpSocket: port 9999・存在しないポート）の Pod で再起動ループを発生させ、kubectl describe pod の Events で Unhealthy: dial tcp 10.244.0.53:9999: connect: connection refused を読み取った。kubectl logs --previous で再起動前のログを取得し、kubectl debug ephemeral container で対象 Pod に nc / curl を持ち込んでライブ調査するテクニックを習得した。なお実機検証で判明した Payara MicroProfile Health の挙動として /health/nonexistent は HTTP 200 を返す（/health/* 配下はすべて UP）ため、HTTP probe を意図的に失敗させるには /totally-bogus-path（HTTP 404）を使う必要があることも確認した
• 現場ヒヤリハットを 2 件扱った。startupProbe なし + livenessProbe.initialDelaySeconds 不足での再起動ループ、readinessProbe 設定漏れで起動中 Pod に Service トラフィックが流れて 503 が出た事例を、根本原因と本番ガードレールまで整理した。本シリーズ全体で「JVM 系アプリには startupProbe 必須」「3 Probe はセットで設定」を方針として確立した

次回予告

第13回 Deployment 戦略補完（Blue/Green + Canary + Recreate）では、本回で作成した fanclub-backend Deployment をベースに、複数のデプロイ戦略を実機で比較します。Blue/Green デプロイ（2 つの Deployment を Service の selector 切り替えで切り替える）・Canary リリース（レプリカ比率でトラフィック分割）・Recreate 戦略の詳細演習を行い、CKAD D2 の残り Competency「共通デプロイ戦略の実装」を完全網羅します。

本回で確認した「spec.selector は不変フィールド」という制約と正面から向き合い、Blue/Green の selector 切り替えが Deployment の再作成を伴うことを実機で扱います。

シリーズ一覧

第1部：コンテナと Docker

• 第1回 コンテナ技術概念 + Docker 環境準備
• 第2回 Docker 基本操作
• 第3回 Dockerfile + マルチステージビルド + JDK 25 / Payara Micro イメージビルド
• 第4回 コンテナレジストリ + イメージタグ戦略 + Trivy スキャン

第2部：Kubernetes 基礎

• 第5回 Kubernetes の全体像 + kind で軽量 K8s
• 第6回 kubectl 基本操作 + Observability・Debug

第3部：アプリリソース

• 第7回 Pod + Multi-container パターン
• 第8回 Service とネットワーキング
• 第9回 ストレージ（PVC + StatefulSet）+ PostgreSQL DB 追加
• 第10回 ConfigMap + Secret + ServiceAccount 基礎
• 第11回 Job + CronJob + DaemonSet

第4部：ワークロード戦略

• 第12回 Deployment + 3 Probe + Rolling Update + Probe デバッグ実践 ← 今ここ
• 第13回 Deployment 戦略補完（Blue/Green + Canary + Recreate）
• 第14回 ResourceQuota + LimitRange + Multi-tenant Namespace

第5部：セキュリティ基礎

• 第15回 RBAC + SecurityContext + Admission Controller 概念 + CRD 利用
• 第16回 NetworkPolicy 基礎

第6部：パッケージ管理 + HTTPS 公開

• 第17回 Helm v4 基礎 + fanclub-api Helm Chart 作成
• 第18回 Gateway API + Traefik + cert-manager で HTTPS 公開
• 第19回 総合演習 — fanclub-api 全機構デプロイ + CKAD 対策まとめ