説明
readinessProbe はコンテナーが要求を処理できる状態か確認します。設定がないと、アプリケーションの初期化中でも Service のトラフィックが届く場合があります。
更新や再起動の際に、準備ができていない Pod を通常の Service の転送先から外せるよう適切な readiness probe を設定してください。readiness の失敗は、コンテナーの再起動や Pod への直接アクセスの遮断を意味しません。
想定される影響
- 準備ができていないコンテナーへの要求が失敗する場合があります。
- デプロイ時に一時的な障害や応答失敗が増えるおそれがあります。
- 初期化と実際にサービスを提供できる時点を区別しにくくなります。
対処方法
- 要求を処理するサービスコンテナーに
readinessProbeを設定してください。 - HTTP、TCP、command など、アプリケーションに合う検査を選んでください。TCP 接続の成功だけで業務要求を処理できるかは別途判断してください。
- 初期化時間に合わせて間隔と遅延を調整し、デプロイ時や障害時の実際の Service トラフィックをテストしてください。
例
既存の TCP 検査例です。利用可能なイメージを選び、サービスが実際にポート 8080 で待ち受けるよう構成してください。遅延と間隔は例です。
変更前
yaml
apiVersion: v1
kind: Pod
metadata:
name: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
livenessProbe:
tcpSocket:
port: 8080
変更後
yaml
apiVersion: v1
kind: Pod
metadata:
name: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
補足:
- 変更前: liveness probe だけがあり、個別の readiness 基準がないため、初期化の完了前に Service の転送先になる場合があります。
- 変更後: TCP 接続の成功を準備完了の基準とします。未準備の間は通常の Service 経路から外れますが、直接アクセスを遮断するセキュリティ制御ではありません。