Liveness ProbeとReadiness Probe
KubernetesにはLiveness ProbeとReadiness Probeってのがある。これの使い分けについて考えてたら混乱したのでメモ。
- Liveness Probeは「コンテナが生きてるかどうか」
- Readiness Probeは「コンテナがリクエストを受け付けるかどうか」
を示すらしい。
- Liveness ProbeがNGのときは、コンテナが再起動される。
- Readiness ProbeがNGのコンテナを持ったPodには、リクエストが送られてこない。
うん。ここまでは理解できる。
んだけど、なんでReadiness Probeだけじゃだめなの？
と思ったので考えてみた。Readiness Probeだけでまかなえるんじゃないの？って。ReadinessがOKの場合って、アプリが生きてるわけだから、それで済むじゃん。って思ったのだ。
この「オレンジじゃなくて黄色の部分」の意味よなぁ・・・。
と思ったらこんな風に書いてあった
- コンテナに問題があったらクラッシュするんだったら、勝手に再起動されるからLiveness Probeの設定要らない。
- ProbeがNGのときにコンテナを再起動して欲しいなら、Liveness Probeを設定したら再起動してくれる。
- ProbeがOKになってからコンテナにトラフィックを送って欲しいなら、Readiness Probeを設定する。Readiness ProbeとLiveness Probeは同じものになるかもしれないけど、Readiness Probeがあるってことは「最初はリクエストを受け付けない状態で起動してReadinessがOKになってからリクエストを受け付けるようになるよ」ってことを表す。
- メンテナンスとかでリクエストを受け付けるのを停止したい場合にはReadiness Probeを使うことができる。
- Podが削除されるときにリクエストを受け付けないようにしたいだけならReadiness Probeを使わなくても大丈夫。削除するときにはReadiness Probeに関係なくunready状態になって停止するのを待つから。
起動してるけどまだリクエストを受け付けてない、ってのを分ける必要は、なさそうかなー。メンテナンスかぁ。でも、メンテナンスとかの場合は、k8sのサービス側でコントロールしそうかなー。だから、あんまり区別しなくて良さそうかな。
SpringBoot使ってる人はどんな風にしてるのかなー？
ってぐぐってみたらこんなの見つけた。
こんな感じに設定してるみたい。
readinessProbe: httpGet: scheme: HTTP path: /health port: 8080 initialDelaySeconds: 240 periodSeconds: 5 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 10 livenessProbe: httpGet: scheme: HTTP path: /health port: 8080 initialDelaySeconds: 300 periodSeconds: 60 timeoutSeconds: 10 successThreshold: 1 failureThreshold: 3
まぁ、やっぱりだいたい同じの設定しておけばいいよねって感じだ。SpringBootアプリの場合は、initialDelaySecondsを長めに設定しとかなきゃなってくらいかなー。
どういうケースでこの２つのProbeを使い分けるんだろう？ってのはスッキリしないままだけど、自分の中での使い方は納得したからいっか。
