クラウドとコンテナの基礎
KubernetesのWebアプリケーションで、livenessプローブの確認の処理の中で、依存先のデータベースに接続できるかまで調べるようにした。この設定で起こりうる問題として、最も適切なものはどれか。
- Aデータベースが止まると、Podがデータベースのあるノードに自動で移され、そのノードのほかのアプリケーションの性能が下がる
- Bデータベースが一時的に止まっただけで、すべてのPodのコンテナが再起動をくり返し、データベースが戻っても回復が遅れる
- Clivenessプローブが失敗してもPodがServiceの振り分け先から外れるだけなので、特に問題は起こらない
答えと解説を見る
正解：B. データベースが一時的に止まっただけで、すべてのPodのコンテナが再起動をくり返し、データベースが戻っても回復が遅れる
livenessプローブは、コンテナ自身が応答しなくなった(デッドロックなど)ときに、再起動で回復させるためのものです。依存先まで調べると、データベースが止まったときにすべてのPodの livenessプローブが失敗し、再起動しても直らないのに、コンテナの再起動がくり返されます。再起動の間は要求を処理できず、くり返すうちに次の再起動までの待ち時間が長くなることもあるので、データベースが戻った後の回復も遅れます。livenessプローブではプロセス自身が応答できるかだけを調べ、依存先の状態は、必要に応じて readinessプローブやアプリケーションのエラー処理で扱います。
- A. プローブの失敗で、Podが別のノードに移されることはありません。livenessプローブが失敗すると、コンテナが再起動されます。
- B. 正しい。依存先の障害で、すべてのPodの再起動がくり返されます。
- C. 振り分け先から外すのは readinessプローブの働きです。livenessプローブが失敗すると、コンテナが再起動されます。