緑の意味と遅い起動の時間予算

一言でいうと

プローブの成功は、選んだ検査条件が真であるという意味です。ポートが開いているという事実を業務の成功と解釈したり、遅い初期化をすぐに殺すべき障害と解釈したりすると、自動復旧がかえって障害を生みます。

なぜ必要なのか

電話がつながるレストランと、注文を受けられるレストランは違います。スタッフは電話に出ても、厨房が止まっているかもしれません。モニタリングで「接続の成功」を「注文の成功」に読み替えた瞬間、緑の画面と顧客の不満が同時に存在することになります。サーバーのhealth endpointも、名前にhealthが入っているからといって、自動的に正しい検査になるわけではありません。成功条件を誰が何で実装したのかまで見る必要があります。

どう動くのか

TCP検査は、指定されたポートに接続できるかを確認します。HTTP検査は、指定されたパスのレスポンスコードを観察します。たとえば、Webサーバーがすべての注文に503を返していても、TCP接続を受け付けるソケットは開いていることがあります。この場合、TCPのreadinessは成功するのに、ユーザーは失敗のレスポンスを受け取ります。

だからといって、すべてのアプリでTCP検査が間違っているという意味ではありません。検査の目的が接続を受け付けるかどうかなら、正確な質問です。問題は、その結果が保証しない業務上の意味まで付け加えてしまうことです。HTTP検査も同様で、常に200を返すパスなら、データベースの参照の失敗を見つけられません。逆に、ヘルスチェックのたびに重い参照を実行すると、検査自体がサービスに負担をかけることがあります。

パスの例	確認したいこと	むやみに混ぜてはいけないこと
/startupz	今回のプロセスの初期化が終わったか	すでに起動したあとで、毎回同じ初期化を実行すること
/livez	実行し続けることに意味があるか	すべての外部依存サービスの一時的な障害
/readyz	新しい業務リクエストを任せられるか	ユーザーの全行程の完全な成功の保証
実際の業務パス	実際のリクエスト結果とレスポンスの内容	たった1回成功したことを、可用性の保証に拡大すること

startup probeは、遅い起動を保護するための別の検査です。これが成功する前は、livenessとreadinessは実行されません。初期化に時間がかかるアプリに、攻撃的なlivenessから適用すると、アプリが起動を終える前に死に続ける状況が生じることがあります。起動に許容する時間と、実行中に回復不能な状態を検知する時間を、別々に扱う理由です。

たとえば、実験アプリは、起動してから20秒間は初期化中のレスポンスを返し、その後に正常なレスポンスを返します。startupの検査周期が1秒、連続失敗の上限が45なら、20秒の初期化に対して余裕のある設定です。この数値は、あらゆる環境でちょうど45.000秒後に終了するという保証ではありません。実行・スケジューリング・検査の所要時間があるので、実際の遷移は観測する必要があります。試験でも、数字を覚えることより、どのバジェットがどの失敗を保護しているのかを説明できるかが重要です。

初期化が終わったあとでreadinessが一時的に失敗したからといって、startupが最初からやり直されるわけではありません。逆に、コンテナが再起動されると、新しいプロセスの起動段階が生じます。このとき、以前のプロセスの成功記録を、新しいプロセスの証拠として再利用してはいけません。Pod UIDだけでなく、コンテナIDとアプリの実行識別子も一緒に記録する理由が、ここにあります。

現場での姿

新しいバージョンがデプロイされたあと、接続検査には成功するのに、実際のAPIだけが失敗するとしましょう。まず、probeをなくしたり、Serviceが準備できていないアドレスまで公開するように変えたりはしません。業務パスと検査パスの違い、Podの条件、EndpointSliceの対象、実際のリクエスト結果を分けて調べます。そのあと、そのサービスが約束する準備状態を表現するように、検査を直します。検査から赤いランプが消えることと、障害が解決することは違います。

検査を変えるときも、オブジェクトの寿命を尊重する必要があります。実行中の独立したPodのprobeフィールドは、勝手に変更できません。宣言を修正し、どの管理オブジェクトが新しいPodを作るのか、入れ替えの間に利用可能な比較群があるのかを確認します。教材の使い捨ての単一Pod入れ替え手順を、本番のDeploymentの無停止デプロイ手順として、そのまま使わないでください。

次のラボですること

正常な2つのPodのうち片方のreadinessを失敗させて、再起動なしにリクエストの割り当てだけが変わるかを見ます。続けて、擬似的なlivenessの障害でコンテナの再起動を観察し、TCPのreadinessを通過しながらHTTP 503を返す別のPodを比較します。最後に、遅い起動の間の状態と、初期化完了後の状態を、実際の記録に結び付けます。遷移には時間がかかることがあるので、設定を繰り返し上書きする前に、同じオブジェクトの進行状況を見ます。

公式の根拠: プローブの構成と注意事項