説明
コンテナープロセスが動いていても、デッドロックや無期限の待機でアプリケーションが応答しないことがあります。liveness probe はその状態を確認し、kubelet によるコンテナーの再起動を支援します。
すべてのワークロードに必須ではありません。プロセス終了時の restart_policy とは別の制御であり、不適切な検査は再起動の繰り返しや連鎖障害を引き起こす場合があります。
想定される影響
- 再起動で復旧できる障害が、手動対応まで継続する場合があります。
- 共通の依存サービスの障害を liveness 失敗と判断すると、多くのインスタンスが不要に再起動される場合があります。
対処方法
- HTTP、TCP、exec などの対応する
liveness_probeで、再起動が必要な状態を確認してください。外部サービスの可用性だけで失敗させないでください。 - 実際の初期化と復旧時間に合わせて間隔と閾値を調整し、必要なら startup probe を使ってください。トラフィックを処理できるかは readiness で別途確認してください。
例
変更後は /health を別途実装したアプリケーションを想定しています。既定の nginx イメージはこのパスを自動提供しないため、設定を用意し、保守されているイメージを使ってください。
変更前
hcl
resource "kubernetes_pod" "app" {
metadata {
name = "app"
}
spec {
container {
name = "app"
image = "nginx:1.27"
port {
container_port = 80
}
}
}
}
変更後
hcl
resource "kubernetes_pod" "app" {
metadata {
name = "app"
}
spec {
container {
name = "app"
image = "nginx:1.27"
port {
container_port = 80
}
liveness_probe {
http_get {
path = "/health"
port = 80
}
initial_delay_seconds = 10
period_seconds = 10
}
}
}
}
補足:
- 変更前: 応答不能を確認する liveness 検査はありません。プロセス終了には restart_policy が別途適用されます。
- 変更後: HTTP 検査の失敗が続くとコンテナーを再起動します。閾値とパスは実際の復旧基準に合っている必要があります。