mhKubernetesでは、アプリケーションの状態を監視して、適切に管理する仕組みが用意されています。それが「Liveness Probe」と「Readiness Probe」です。
この2つを使うことで、以下のようなことが可能になります：
- フリーズしたコンテナを自動で再起動する
- サービスとしてリクエストを受け付けるかどうか判断する
✅ それぞれの役割
| 項目 | 説明 | 主な使い道 |
|---|---|---|
| Liveness Probe | 「このコンテナ、生きてる？」 | 死んでいたら自動再起動 |
| Readiness Probe | 「このコンテナ、今リクエスト受けられる？」 | 受けられない場合、Serviceの対象から外す |
🧠 イメージで理解する
- アプリがフリーズ：
→ Liveness Probeが失敗 → Pod再起動 - 起動直後でまだ準備中：
→ Readiness Probeが失敗 → サービスはまだトラフィックを送らない
これにより、不安定なPodをユーザーに見せずに、安全にサービス提供できます。
🛠️ Probeの種類
Kubernetesでは、以下の方法で状態をチェックできます：
| 種類 | 概要 | 使用例 |
|---|---|---|
| HTTP | 指定URLにHTTPリクエストして応答を見る | /health など |
| TCP | ポートが開いているかを確認 | データベースなど |
| Command | コンテナ内でコマンドを実行し、終了コードで判断 | pgrepやcurlなど |
🔧 YAML設定の例（Liveness + Readiness）
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 3各フィールドの意味：
initialDelaySeconds: 起動直後の待機時間（チェック開始まで待つ）periodSeconds: チェックの頻度httpGet.path: チェック対象のURLパス
📌 注意点
- Liveness Probeが連続で失敗すると、Podは自動で再起動されます
- Readiness Probeが失敗中のPodにはServiceからのトラフィックが来ません
- 両方設定するのが一般的（起動中の不安定な状態も考慮できる）
💡 まとめ
| 項目 | 内容 |
|---|---|
| Liveness Probe | アプリがハングしていないかを監視 |
| Readiness Probe | アプリがリクエストを受けられる状態か監視 |
| メリット | 不安定なPodの自動回復、ユーザーへの影響を最小化 |
| 設定方法 | httpGet, tcpSocket, execなどで柔軟に設定可能 |
🧪 補足：どう使い分ける？
| 状態 | 対応 |
|---|---|
| 起動直後で準備中 | Readinessが失敗（→トラフィックを送らない） |
| アプリがフリーズ | Livenessが失敗（→Podを再起動） |
| 一時的に重くて応答しない | Readiness失敗だけで済むケースも多い（再起動は避けたい） |
