はじめに
Kubernetesでアプリケーション（Deployment）をデプロイする際に、Probeの設定をすることは多いと思います。ドキュメントや色々な記事でLiveness / Readiness Probeの説明がありますが仕組みは分かっても、なぜ両方設定が必要なのか？ という疑問がふんわりありました。
そこで疑問解決ベースで言語化することで自分を納得させてみようと思いました。
※ 本記事ではStartup Probeについては説明しません。
各Probeを軽くおさらい
いずれのProbeも、kubelet（各ノードにあるリソース）からPodにヘルスチェックを発信することで死活監視やトラフィックの制御をする。
Liveness Probe
コンテナは稼働中か（生存しているか）をチェックするためのもの。
異常と判断された場合、コンテナは再起動される。
Readiness Probe
コンテナはトラフィックを受け入れるための準備ができているか（Readiness）を確認するために使用する。
異常と判断された場合（例えば起動初期のロード処理や、重いリクエストの処理中で別のリクエストを返せない場合）、そのコンテナを含むPodはServiceのロードバランシング先から切り離される。
疑問
1. ReadinessProbe は必要か？
多くの人が初めに「 LivenessProbe さえ設定すれば、コンテナの死活監視できてるから十分じゃね？」と思いそうです。
しかしながら、コンテナ起動後、リクエストを処理できる状態になるまでの準備に時間がかかる場合に、無限再起動に陥る恐れがあります。
例えば、上記のように準備に時間がかかる場合に、もし LivenessProbe だけを設定すると、常に LivenessProbe に失敗することになります。すると起動から準備を待たずコンテナが再起動され準備が最初からになり、LivenessProbe による無限再起動のループに陥ってしまいます。
そこで、LivenessProbe にinitialDelaySeconds（コンテナが起動してからProbe開始までの秒数。デフォルト0秒）を設定することで、強引にLivenessProbeだけを設定することも思い付きます。
しかしその場合、秒数だけで厳密に準備状態のチェックをしないため、何らかの理由でコンテナの準備が遅延しても、トラフィックは送られ始めることになりその間はエラーを返し続けてしまいます。
可用性の点で不十分です。
2. LivenessProbe は必要か？
今度は逆に「 ReadinessProbe だけ設定すれば、リクエストは受けられる状態だから良くね？」と思いそうです。
場合によっては問題ないかもですが、コンテナの特性や ReadinessProbe の設定によっては取りこぼしが発生する可能性があります。
例えば、execであるコマンドを実行するだけだったり、tcpSocketで特定ポートのコネクション確立だけだった場合、対象のプロセスは生きているがコンテナ自体に問題がある可能性があります。
具体的には、下記のような問題が挙げられます。
- リソース不足： コンテナが外部リソースとの接続を問題なく行える状態でも、Podのメモリ・CPU確保量やノードのリソースが不足している場合、実際のリクエストに適切に応答できない可能性がある。このような時、LivenessProbe がタイムアウトやエラーを検出できる可能性がある。
- DB接続の問題: コンテナがDBとの接続を確立する必要があり、ReadinessProbe によりその疎通確認がとれていても、実際のクエリに対してエラーを返す可能性がある。この場合も、LivenessProbe がタイムアウトやエラーを検出できる可能性がある。
- バックグラウンドプロセスのクラッシュ: バックグラウンドプロセスがそのコンテナの重要な機能を担っている場合、アプリの全体的な機能に影響を与える可能性がある。LivenessProbe が適切であれば、バックグラウンドプロセスのクラッシュも検知する可能性がある。
さいごに
まとめると、下記のような危険があります。
- LivenessProbe だけを設定した場合
- コンテナの無限再起動
- リクエストを受ける準備ができてないのにトラフィックが送られる
- ReadinessProbe だけを設定した場合
- コンテナ全体で見ると問題があるのにトラフィックが送られる
記事を書いてみて、Liveness / Readiness Probe はそれぞれ互いにカバーし合う関係にあると思いました。
コンテナの特性等によっては、これらのProbeは必要なかったり片方で事足りたりするかもしれませんが、基本的にいずれの Probe も設定した方が、アプリケーションの安定運用につながるはずです。