Kubernetes によるヘルスチェックには、Liveness ProbeとReadiness Probeと呼ばれる二つのものがあります。これらは混乱しがちな一方、日本語による情報が多くない(2018/07/26現在で、Google検索の1ページ目にヒットするのが4件ほど)ため、ここで一つ情報をまとめておきます。
共通
Liveness ProbeとReadiness Probeの設定は共通で、Deployment
やPod
のマニフェスト内で、containers
の中にlivenessProbe
とreadinessProbe
としてそれぞれProbe
spec
を記述します。
次の項目を設定することが出来ます。
failureThreshold
Success
状態の時、何回失敗したらFailure
になるか。最小で1回。- Default: 3
initialDelaySeconds
- コンテナが起動してからヘルスチェックを始めるまでの秒数。
- Default: 0
periodSeconds
- ヘルスチェックの間隔。最小で1秒
- Default: 10
- successThreshold
Failure
状態の時、何回成功したらSuccess
になるか。最小で1回。- Default: 1
- timeoutSeconds
- ヘルスチェックのタイムアウト秒数。最小で1秒。
- Default: 1
- httpGet
- ヘルスチェックでアクセスするhttpエンドポイントの情報を書く。
httpGet
の項目は次の様な項目を持ったobjectを書きます。
host
- 対象のホスト名。
- Default: PodのIP
httpHeaders
- リクエストのカスタムヘッダ指定。
{name: HEADER_NAME, value: HEADER_VALUE}
の形のオブジェクトの配列で書く。
- リクエストのカスタムヘッダ指定。
port
- アクセスするポート番号または名称
path
- アクセスするパス。
scheme
- アクセスする際のスキーム。
- Default: HTTP
Liveness Probe
一つ目はLiveness Probeです。公式ドキュメント には次の様に書いてあります。
livenessProbe
: Indicates whether the Container is running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy . If a Container does not provide a liveness probe, the default state isSuccess
.
Liveness Probeの役割はその名の通り、アプリケーションの生存確認です。コンテナ起動後の状態はSuccess
で、Failure
になるとKubernetesはコンテナをkillします。コンテナがkillされた後は、Podのrestart policyに従います。
よく使用されるエンドポイントパスは/healthz
です(最後のzがどこから来たのか、知ってる人がいたら教えてください)。
Go言語でのLiveness Probe用エンドポイントのサンプルを次に示します。
|
|
Readiness Probe
もう一つのヘルスチェックがReadiness Probeです。公式ドキュメント の説明は次の通りです。
readinessProbe
: Indicates whether the Container is ready to service requests. If the readiness probe fails, the endpoints controller removes the Pod’s IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay isFailure
. If a Container does not provide a readiness probe, the default state isSuccess
.
ReadinessProbeは、サービスがリクエストを受け付けられる状態かどうかを確認します。例えば、DB接続の初期化処理に時間がかかる場合など、アプリケーションは生きているがまだ対応出来ない、という状態を判断します。コンテナ起動後の状態はFailure
で、Success
になるとKubernetesはPodのIPを、セレクタがマッチするサービスの対象として追加します。また、Success
からFailure
になった場合は、同様にサービスからIPを削除します。これにより、準備が出来ていないPodはServiceによるロードバランシングの対象から外れることとなります。
よく使用されるエンドポイントパスは/readiness
です。
Go言語でのサンプルは次の様なものです。
|
|