備忘録。いつもどっちがどっちか分からなくなるので ChatGPT に聞いてみる。
「Liveness Probe と Readiness Probe の違いを教えて」
Liveness Probe と Readiness Probe は、コンテナ内のアプリケーションが正常に動作しているかどうかを監視するために使用される Kubernetes の機能です。
Liveness Probe は、コンテナ内のアプリケーションが稼働しているかどうかを定期的にチェックし、アプリケーションが正常に動作していない場合にはコンテナを再起動します。これは、アプリケーションがフリーズしたり、クラッシュしたりする場合に便利です。
一方、Readiness Probe は、コンテナ内のアプリケーションがトラフィックを処理できる状態になったかどうかを定期的にチェックします。これにより、アプリケーションが起動するまで待機することができ、アプリケーションがトラフィックを処理できるようになったときにのみトラフィックをルーティングすることができます。これは、アプリケーションが起動するのに時間がかかる場合や、アプリケーションがトラフィックを処理する前に接続を受け入れることができる場合に役立ちます。
簡単に言えば、Liveness Probe はアプリケーションが稼働しているかどうかをチェックし、必要に応じてコンテナを再起動します。一方、Readiness Probe はアプリケーションがトラフィックを処理できる状態になったかどうかをチェックし、トラフィックをルーティングする前に待機することができます。
「Liveness Probe と Readiness Probe は DB にもアクセスするの？」
Liveness Probe や Readiness Probe は、DB にアクセスすることができますが、通常はアプリケーションが DB にアクセスする必要があるため、そのように構成することが一般的です。
ただし、DB へのアクセスが負荷が高く、Probe による DB へのアクセスがアプリケーションの正常な動作に影響を与える場合は、DB へのアクセスを制限する必要がある場合があります。
一般的には、Liveness Probe と Readiness Probe は、アプリケーションが正常に動作しているかどうかを確認するために、単純なヘルスチェックを実行することが推奨されます。例えば、アプリケーションが期待されるレスポンスを返すかどうか、アプリケーションが起動してからの時間が一定時間以内であるかどうかなどをチェックすることが一般的です。
なるほど、とりあえずなんとなく分かったけど、ドキュメントを読む。
If your app has a strict dependency on back-end services, you can implement both a liveness and a readiness probe. The liveness probe passes when the app itself is healthy, but the readiness probe additionally checks that each required back-end service is available. This helps you avoid directing traffic to Pods that can only respond with error messages.
「Readiness Probe はさらに各バックエンドサービスが利用可能かチェックする」って書いてある。Probe で DB の応答までチェックするなら Liveness Probe ではなく Readiness Probe がよさそう。
あと、今さら気が付いたけど、Readiness は Read (読む) じゃなくて Ready (準備) の名詞ですね...。