説明
コンテナープロセスが動いていても、アプリケーションが正常とは限りません。デッドロック、無期限の待機、応答不能によって、プロセスが生きたままサービスが止まる場合があります。livenessProbe は kubelet がその状態を確認し、コンテナーを再起動するために使えます。
すべてのワークロードに必須ではありません。終了したプロセスに適用される restartPolicy とは別の機能であり、不適切な検査は正常なコンテナーの繰り返し再起動や連鎖障害を招く場合があります。
想定される影響
- 再起動で回復できる障害が、手動対応まで続く場合があります。
- 共通の依存サービスの障害を liveness 失敗とすると、多数のインスタンスが不要に再起動される場合があります。
対処方法
- HTTP、TCP、exec などサポートされる方式で、再起動が必要な状態を検査する livenessProbe を設定してください。外部の依存サービスの異常だけで失敗させないでください。
- 実際の初期化・回復時間に合わせて周期としきい値を調整し、必要なら startup probe を使ってください。トラフィックを受ける準備状態は readiness probe で別途確認してください。
例
変更後は /health を別途実装したアプリケーションを前提にしています。標準の nginx イメージはこのパスを自動提供しないため、必要な設定を用意してください。既存のイメージと時間の値は例示です。
変更前
yaml
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: nginx:1.27
ports:
- containerPort: 80
応答不能を確認する liveness 検査がありません。プロセスが終了した場合は、restartPolicy が別途適用されます。
変更後
yaml
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: nginx:1.27
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 10
periodSeconds: 10
HTTP 検査の失敗がしきい値まで続くと、コンテナーの再起動処理を行います。パスと時間設定は実際の復旧要件に合わせる必要があります。