Podを作成すると、その中にContainerが作成されてPodとContainerの状態がRunningになって、ContainerのAppも正常に稼働される。
そしてPodとServiceが接続されてServiceのIPアドレスからユーザーがリアルタイムでアクセスが可能になる。
上の図のように1つのServiceに2つのPodが繋がっていて50％ずつTrafficを分散していると仮定したとき、もしNode2サーバーが落ちた場合は全てのユーザーはNode1に接続されることになる。
そして落ちたPodはAutoHealing機能によって他のNodeであるNode3に再生成される。
再生成される間にContainerはRunning状態になってServiceと接続されたが、Appがまだ起動中の場合がある。
Serviceと接続しているのでTrafficがPod2の方に流れて行くとAppはまだ起動中なのでTrafficエラーになってしまう。
Podを作成するときに「ReadinessProbe」を指定すると上記の問題を避けることができる。
「ReadinessProbe」はAppが起動されるまでにはServiceと繋がらないようにしてくれるのでPod2の状態はRunningであるが、TrafficはPod1に行くようになる。
AppがRunning状態になったらServiceと接続されてTrafficは50:50になる。
Pod2のAppは落ちたがPod2はRunning状態、例えばWeb ServiceのTomcatは正常に稼動しているが、その上で動くAppがメモリオーバーフローなどの問題で500サーバーエラーを返すことがある。
Tomcat自体のプロセスが落ちたのではなく、Tomcat上で稼働しているサービスの問題なので、Tomcatのプロセスを見ているPodはRunning状態になるのでTrafficは入ってくる問題が発生してしまう。
この時、Appの障害を検知してくれる機能が「LivenessProbe」だ。
Podを作成するときに「LivenessProbe」を指定すると、そのAppに問題が発生した場合はPodを再実行させて、一瞬のTrafficエラーは発生するが、エラー状態が続くのを防いでくれる。
安定したServiceを提供するために「ReadinessProbe」を使ってAppが稼動している間のTrafficの失敗をなくして、「LivenessProbe」を使ってAppの問題を検知して障害状態が長くなることをPodを作成するときに設定することで防げる。
