KubernetesのPodのProbe（診断）3つ（Liveness・Readiness・Startup）を完全に理解。きめ細かく診断を設定できたんだね...

はじめに

ミリシタ新イベ、不気味がすぎるよ... 怖いのガチでダメなnikkieです。

KubernetesのPodのProbeについて知ったことのまとめです。
「似たようなものが3つあるなー」くらいの認識から始めて、1つ1つがどういったものかを完全に理解しました！

目次

まとめ：Podの3つのProbe

Probe＝診断。コマンドを実行するイメージ。
Probeには成功と失敗がある（コマンドの終了コードが0かそれ以外かに相当するという理解）

• Liveness Probe：コンテナが生きているかを診断
  • 失敗した場合、生きていないコンテナになるので再起動される
• Readiness Probe：コンテナの準備ができているかを診断
  • 成功した場合、準備ができているのでトラフィックが送られるようになる
• Startup Probe：コンテナの立ち上がりを診断
  • 立ち上がる（成功）まで他のProbeは無効
  • 失敗した場合、立ち上がっていないのでコンテナが再起動される

参照したドキュメント¹

1. Liveness Probe、Readiness ProbeおよびStartup Probeを使用する
2. コンテナのProbe（Podのライフサイクル）

PodのProbe

k8sのPodやDeploymentの定義（YAMLファイル）において、probeというものを設定できます。

ドキュメント1をもとにした設定イメージ

kind: Pod
spec:
  containers:
  - name: awesome
    livenessProbe:
      ...
    readinessProbe:
      ...
    startupProbe:
      ...

Probeはkubelet により定期的に実行されるコンテナの診断です。（ドキュメント2）

コンテナの診断にはいくつかの方法が提供されています²

• コマンド実行
  • ドキュメント1の https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command
• HTTP GETリクエスト
  • ドキュメント1の https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request
  • ヘルスチェックのエンドポイントを叩くイメージです

Probeの役割と使い所

Liveness Probe

生きている（live ライブ）の名詞でliveness³と理解しました。
Liveness Probeがfail（失敗）したら、コンテナが生きていないということなので、再起動されます

ドキュメント2より

コンテナが動いているかを示します。 livenessProbeに失敗すると、kubeletはコンテナを殺します

Probeに失敗したときにコンテナを殺したり再起動させたりするには、livenessProbeを設定し （livenessProbeをいつ使うべきか? より）

Readiness Probe

ready（準備ができている）の名詞のreadiness。
準備ができているということは、トラフィックが回されます（ドキュメント1より、「コンテナがトラフィックを受け入れられる状態」）

ドキュメント2より

コンテナがリクエスト応答する準備ができているかを示します。

Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
（略）readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。（readinessProbeをいつ使うべきか? より）

興味深かった点は、readinessProbeにより、コンテナをメンテナンスのために停止できるということ。
readinessProbeが見ているエンドポイントをfailさせることで、トラフィックが送られなくなり、メンテナンス停止が実現しますね。

Startup Probe

Startup＝立ち上げ。
アプリケーションの起動に関係します。

ドキュメント2より

コンテナ内のアプリケーションが起動したかどうかを示します。

startupProbeに失敗すると、kubeletはコンテナを殺します

startupProbeは、サービスの開始に時間がかかるコンテナを持つPodに役立ちます。
livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。（startupProbeをいつ使うべきか? より）

いつ使うべきかの説明はわかりやすいと思いました。
livenessProbeの間隔を長く設定すると、liveでなくなったときの再起動までに時間がかかってしまいます。
startupProbeを使ってprobeを分けることで、初回起動まではstartupProbeに担当してもらい、起動後はlivenessProbeが失敗次第再起動してくれます。
いい感じに役割分担できていますよね。

機械学習モデルをサーブするAPIは、モデル読み込みをstartupProbeに設定するというのが1つありそうです。
ただし、実装にもよると思いますし、readinessProbeも候補です

ドキュメント1より⁴

Startup Probeを使用している場合、Startup Probeが成功するまでは、Liveness Probeと Readiness Probeによるチェックを無効にし、これらがアプリケーションの起動に干渉しないようにします。

Probeの設定値

ドキュメント1の「Probeの構成」より

すでにコマンド実行やHTTP GETリクエストを設定できることを見ましたが、ここではprobeの間隔の設定についてです。

• initialDelaySeconds

  • コンテナが起動してから、Liveness ProbeまたはReadiness Probeが開始されるまでの秒数。

  • デフォルトは0秒。

• periodSeconds

  • Probeが実行される頻度(秒数)。

  • デフォルトは10秒。

• failureThreshold

  • Probeが失敗した場合、KubernetesはfailureThresholdに設定した回数までProbeを試行します。

  • デフォルトは3

※Startup Probeが成功した後にLiveness ProbeやReadiness Probeが開始されます

コマンド実行やHTTP GETリクエストだけを指定した場合、デフォルト値が使われ

• コンテナが起動したら0秒で（＝即時）probeを実行
• probeは10秒おき
• 4回連続して失敗したらprobe失敗
  • probeが最短で失敗するまで、コンテナ起動から30秒（=0+10*3）
  • 起動 & 失敗 - 10秒 - 失敗 - 10秒 - 失敗 - 10秒 - 失敗

となります。

例えば、以下のように設定すると

initialDelaySeconds: 30
periodSeconds: 20
failureThreshold: 10

• コンテナが起動したら30秒経過後にprobeを実行
• probeは20秒おき
• 一度失敗した後、続く10回でも全部失敗したらprobe失敗
  • probeが最短で失敗するまで、コンテナ起動から230秒（=30+20*10）
  • 起動 - 30秒 - 失敗 - 20秒 - 失敗 - ・・・ - 20秒 - 失敗

Probeを設定しないとどうなるの？

Probeによる診断は常時成功します（してしまいます）。

ドキュメント2より
https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe

コンテナにlivenessProbeが設定されていない場合、デフォルトの状態はSuccessです。

コンテナにreadinessProbeが設定されていない場合、デフォルトの状態はSuccessです。

コンテナにstartupProbeが設定されていない場合、デフォルトの状態はSuccessです。

startupProbeの設定がなければ起動成功とみなされ、
readinessProbeの設定がなければトラフィックが送られ、
livenessProbeの設定がなければコンテナに問題が起こったとしても自動で再起動されません。

なので、これらを適切に設定することが重要だと痛感しました。
k8s使いこなしの小さな一歩！

終わりに

k8sのPodの3つのProbe、完全に理解した！
似ているなんとかProbeがあるなーくらいの理解でしたが、単語の意味+ドキュメントの情報量で各Probeがどんなものかが掴めた気がします。
いままで「よくわからないなー」と思っていたk8sのPodの動きも、Probeたちの設定を読み解けていなかったからではないかと感じ始めています。

---

1. 新しい概念だったので日本語を参照しました。ですが、いずれも英語版よりも古い可能性ありと通知されています↩
2. 全部で4つです https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#probe-check-methods （ドキュメント2）↩
3. 読みはライブネス？↩
4. ドキュメント2でも「startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。」↩