【Kubernetes】Probeの設定値の設計観点
はじめに
Kubernetesのヘルスチェック機能である3種類のProbeについて、どのような観点で値を設定すべきかを考えてみました。
Probeの基本的な説明は本記事では割愛します。
公式の情報：
Liveness Probe、Readiness ProbeおよびStartup Probeを使用する | Kubernetes
Probeの設定値は、パフォーマンスや異常検知のスピードや精度のトレードオフを考慮して調整すべきです。
各Probeの「設定する目的」「NGになったときの振る舞い」をおさえたうえで、
どのパラメーターをどう調整(値を大きくするor小さくする)すると、どんなリスクがあるか、という観点でまとめてみました。
Liveness Probe
目的
再起動されるまで回復できないような異常な状態を検知し、自動で復旧する
NGになった場合の振る舞い
restartPolicyに従う
設定
| パラメータ | 説明 | 大きくするリスク | 小さくするリスク |
|---|---|---|---|
| initialDelaySeconds | コンテナが起動してから、Liveness Probeが開始されるまでの秒数。 Liveness Probeの開始タイミングはstartupProbeで制御できるので、startupProbeを定義する場合は不要。 |
必要以上に増やしすぎると、起動完了後に異常状態になった場合の検知と復旧が遅れる場合がある | コンテナの起動時間(ProbeがOKで帰ってくるようになるまでの時間)が設定した値を超えた場合、コンテナが起動しきらないまま、再起動がかかり、永遠に起動してこない事象に陥る |
| periodSeconds | Probeが実行される頻度(秒数) | 異常の検知・復旧が遅れる場合がある | リクエスト数が多くなるので、コンテナへの負荷がかかる |
| timeoutSeconds | Probeがタイムアウトになるまでの秒数 | レスポンスに時間がかかりすぎることを異常として検知できない | レスポンス時間の必要分確保されていないと、異常を誤検知してしまう可能性がある |
| failureThreshold | Probeが失敗した場合、KubernetesはfailureThresholdに設定した回数までProbeを試行する。試行回数に到達すると、再起動される | 異常が発生してから再起動までの時間が長くなる | 誤検知により再起動が発動してしまう可能性が上がる |
| successThreshold | 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数 | 異常を誤検知してしまう可能性がある | 異常状態の検知が遅れる可能性がある |
Readiness Probe
目的
トラフィックを処理できない状態(例：依存するリソースの起動を待機している)を検知して、リクエストを一時的に遮断する
NGになった場合の振る舞い
トラフィックの遮断(Service のロードバランシングから切り離される)
設定
| パラメータ | 説明 | 大きくするリスク | 小さくするリスク |
|---|---|---|---|
| initialDelaySeconds | コンテナが起動してから、Readiness Probeが開始されるまでの秒数。 Readiness Probeの開始タイミングはstartupProbeで制御できるので、startupProbeを定義する場合は不要。 |
必要以上に増やしすぎると、起動完了後に異常状態になった場合の検知とトラフィックの遮断が遅れる場合がある | コンテナの起動時間(ProbeがOKで帰ってくるようになるまでの時間)が設定した値を超えた場合、コンテナが起動しきらないまま、再起動がかかり、永遠に起動してこない |
| periodSeconds | Probeが実行される頻度(秒数) | 異常の検知・トラフィックの遮断が遅れる場合がある | リクエスト数が多くなるので、コンテナへの負荷がかかる |
| timeoutSeconds | Probeがタイムアウトになるまでの秒数 | レスポンスに時間がかかりすぎることを異常として検知できない | レスポンス時間の必要分確保されていないと、異常を誤検知してしまう可能性がある |
| failureThreshold | Probeが失敗した場合、KubernetesはfailureThresholdに設定した回数までProbeを試行する。試行回数に到達すると、トラフィックが遮断される | 異常が発生してからトラフィック遮断までの時間が長くなる | 誤検知によりトラフィック遮断が発動してしまう可能性が上がる |
| successThreshold | 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数 | 異常を誤検知してしまう可能性がある | 異常状態の検知が遅れる可能性がある |
Startup Probe
目的
コンテナアプリケーションの起動完了を検知し、Liveness ProbeとReadiness Probeの開始タイミングを制御する。
起動に時間がかかるが、どれくらい時間がかかるか予測できないアプリケーションに対して有効。
NGになった場合の振る舞い
restartPolicyに従う
設定
| パラメータ | 説明 | 大きくするリスク | 小さくするリスク |
|---|---|---|---|
| initialDelaySeconds | コンテナが起動してからstartupProbeが開始されるまでの秒数 | 必要以上に増やしすぎると、Probeの開始が遅れ、起動完了後の異常の検知や再起動やトラフィック遮断が送れる可能性がある | |
| periodSeconds | Probeが実行される頻度(秒数) | startupProbe完了までの時間が必要以上にかかってしまう可能性がある | リクエスト数が多くなるので、コンテナへの負荷がかかる |
| timeoutSeconds | Probeがタイムアウトになるまでの秒数 | レスポンスに時間がかかりすぎている状態で、「起動完了」と判定してしまう | レスポンス時間の必要分確保されていないと、異常を誤検知してしまう可能性がある |
| failureThreshold | Probeが失敗した場合、KubernetesはfailureThresholdに設定した回数までProbeを試行する。試行回数に到達すると、再起動される | (periodSeconds*failureThreshold)秒が想定しうる起動時間より短い場合、永遠に起動してこない | |
| successThreshold | 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数 | 異常を誤検知してしまう可能性がある | 異常状態の検知が遅れる可能性がある |
おわりに
エイヤーで実装しがちですが、異常を検知して自動で復旧するのはKubernetesの強みの一つだと思うので、ちゃんと設計に向きあうことは大事ですね。
解釈が誤ってそうな点があれば随時修正します。
