readiness probe とは？準備完了までトラフィックを制御する

readiness probe とは、pod がトラフィックを受け取るべきかを Kubernetes が判断するために実行する check で、失敗すると pod は通過するまで load balancer から外されます。

コンテナは実行中でも、まだ処理を提供する準備ができていないことがあります - まだ cache を温めている、データベースに接続している、config を読み込んでいる、などです。readiness probe はその区別を捉えます。Kubernetes は readiness probe が通過した pod にのみトラフィックをルーティングし、それが rolling update をシームレスにします。

何を check するか

probe - HTTP リクエスト、TCP 接続、またはコマンド - を定義し、Kubernetes がそれを定期的に実行します。成功は「トラフィック受け入れ可」を意味し、失敗は回復するまで pod をその Service の endpoint から除外します。

readiness と liveness の違い

readiness probe の失敗はトラフィックを止めますが、pod を再起動はしません。liveness probe の失敗はコンテナを再起動します。readiness は「今は準備できていない」と言い、liveness は「壊れた、再起動してくれ」と言います。

なぜデプロイを安全にするのか

rolling update の間、新しい pod は readiness probe が通過するまでローテーションから外されたままです。したがってユーザーは、起動を終えていない pod にルーティングされることは決してありません - デプロイ中のエラーが起きません。

典型的な設定

準備完了時に 200 を返す /healthz への HTTP GET。
アプリが起動する時間を確保する初期遅延。
アプリに合わせて調整された period と失敗しきい値。

CI/CD とのつながり

readiness probe こそが、CD が新しいイメージをゼロダウンタイムでロールアウトできるようにします。同じ考え方は CI の service container にも当てはまります。connection-refused の flakiness を避けるため、テスト実行前に readiness を待ちましょう。

重要なポイント

readiness probe は、pod がトラフィックを受け取るべきかを判断します。
準備できていない pod を、再起動せずにローテーションから外します。
readiness probe こそが、rolling deploy をゼロダウンタイムにします。