簡単にまとめると Liveness に失敗したらザキ Readiness に失敗したらやけつく息。…いや逆にわからんような気もする。
Liveness は Pod が稼働できるかどうかの判定をする。判定に失敗した場合は Kubernetes がその Pod を作り直す。
Pod が提供するべき最低限の機能すら提供できない場合にこのチェックを失敗させるべきだろう。
たとえば自分のアプリケーションが待ち受けるサーバーを提供するんだけど、そこへの疎通が一切できないとか。それが最初から起きるならアプリケーションは起動しないだろうが、起動してから何かしらの理由でサーバが落ちるといったことが無いわけではないはず。
Readiness は Pod と疎通できるかの判定をする。判定に失敗すると Kubernetes が Service から切り離す。このとき Pod は生きたままになる。 デッカい初期データを読み込むなどと起動に時間のかかるようなアプリケーションだったとき、アプリケーションは無事に起動する（=Liveness をパスできる）が、リクエストを受け付けることができないので、そういった場合は Readiness を設定して、Serviceから切り離されるべきだろう。
あと、他のアプリケーションに依存している部分を Liveness や Readiness には入れないほうがよいはず。 その確認をいれていると、回り回って全ての依存関係が全滅するとか Liveness / Readiness のデッドロックが起こってしまいそうな予感がする。
A は B への疎通確認を Liveness にいれて、 B は C への疎通確認を Liveness にいれて、としたときに、仮に C が何かの影響で疎通できないような状態になると B が作り直され A が作り直され、結局 A → B → C とつながった機能が提供できなくなる。
接続できるけど Unavailable な状態、 HTTP でいうと 5xx なステータスを、アプリケーションあるいはプロキシするサイドカーな何かで返すほうがよいのでは？
ほら nginx も upstream につながらなくなっても nginx は終了せずに「upstream に繋がらないけど」というエラーが出るじゃん？
これを各 Pod でもできるようにしたほうがいいと思うのよ。
Liveness も Readiness もどちらも、監視までの時間、監視する間隔、判定失敗とするまでの許容する失敗回数といったオプション値を設定できる。
このあたりは公式ドキュメントを見るとまとまってるのでこまかい話はそっちを見るようにしたらよい。
Configure Liveness and Readiness Probes - Kubernetes
それと Liveness も Readiness も、どちらも時間や間隔の調整は必要なものの、基本的にはヘビーな処理が発生しないようにする必要がある。 Liveness や Readiness のチェックでかかる負荷によって、自分自身をを失敗させる原因にならならないようにするために。