はじめに
Kubernetesでローリングアップデートをする時に、readinessProbe
とminReadySeconds
を設定するとどう動くのか気になったので実際に試してみました。
readinessProbe
readinessProbe
は、コンテナがリクエストに応答できるかを判断する設定です。
readinessProbe.initialDelaySeconds
で最初にチェックするまでの待機時間を、readinessProbe.periodSeconds
でチェックする間隔を設定できます。
readinessProbe:
tcpSocket: # ポートによるチェック
port: 80
initialDelaySeconds: 30 # 最初にチェックするまでの待機時間
periodSeconds: 60 # チェックする頻度

minReadySeconds
minReadySeconds
は、Deploymentで新しく作成されたPodが利用可能と見なされるまでに必要な最小時間の設定です。
デフォルトの値は0
です。つまり、PodがREADYになるとすぐDeploymentから利用可能とみなされます。
ローリングアップデートでどうなるか
実際にreadinessProbe
とminReadySeconds
を設定してローリングアップデートをするとどうなるか試してみます。
Deployment
Deploymentのマニフェストdeployment.yml
は下記の通りです。readinessProbe
とminReadySeconds
を設定しています。
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 2
minReadySeconds: 100 # READYとなったPodが揃ってから100秒待つ
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx:1.21
readinessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 10 # 最初にチェックするまで10秒待つ
periodSeconds: 10
マニフェストを適用します。
kubectl apply -f deployment.yml
PodとDeploymentの確認
Podを確認してみるとinitialDelaySeconds
とperiodSeconds
後にREADYになっていることがわかります。
おそらく
periodSeonds
ごとにチェックはするが最初のinitialDelaySeonds
間は待つので、下記のような結果になっているのだと思います。
❯ kubectl get pod -w
NAME READY STATUS RESTARTS AGE
myapp-79cb479965-9vd7q 0/1 Running 0 4s
myapp-79cb479965-kdzbq 0/1 Running 0 4s
myapp-79cb479965-9vd7q 1/1 Running 0 21s # initialDelaySeconds+periodSeonds待ってからREADY
myapp-79cb479965-kdzbq 1/1 Running 0 21s # initialDelaySeconds+periodSedonds待ってからREADY
Deploymentの方を確認してみると、READYとなったPodが2つになってもminReadySeconds
待ってからAVAILABLEになっているのがわかります。
❯ kubectl get deploy -w
NAME READY UP-TO-DATE AVAILABLE AGE
myapp 0/2 0 0 0s
myapp 0/2 2 0 1s
myapp 1/2 2 0 21s
myapp 2/2 2 0 21s # READYが揃ってもAVAILABLEにならない
myapp 2/2 2 2 2m # minReadySeconds待ってからAVAILABLE
マニフェストの変更(ローリングアップデート)
マニフェストのイメージを下記の様に変更して、Podをローリングアップデートさせます。
image: nginx:1.20
kubectl apply -f deployment.yml
ローリングアップデートの設定はデフォルトなので、レプリカが2つの場合は1つずつアップデートされています。

PodとDeploymentの確認
PodがREADYとなるまで先ほどと同じ時間が経過してからREADYとなっています。ただし、レプリカが3つ揃っても古いPodが削除されるまで約100秒ほど時間が経っています。
❯ kubectl get pod -w
NAME READY STATUS RESTARTS AGE
myapp-587cddb9b-pp22q 0/1 Running 0 3s
myapp-79cb479965-9vd7q 1/1 Running 0 3m51s
myapp-79cb479965-kdzbq 1/1 Running 0 3m51s
myapp-587cddb9b-pp22q 1/1 Running 0 20s
myapp-79cb479965-9vd7q 1/1 Terminating 0 5m48s # Podが3つ揃ってから100秒ほど待っている
myapp-587cddb9b-2khcb 0/1 ContainerCreating 0 0s
myapp-79cb479965-9vd7q 0/1 Terminating 0 5m49s
myapp-587cddb9b-2khcb 0/1 Running 0 1s
myapp-79cb479965-9vd7q 0/1 Terminating 0 5m57s
myapp-587cddb9b-2khcb 1/1 Running 0 20s
myapp-79cb479965-kdzbq 1/1 Terminating 0 7m48s # Podが3つ揃ってから100秒ほど待っている
myapp-79cb479965-kdzbq 0/1 Terminating 0 7m48s
myapp-79cb479965-kdzbq 0/1 Terminating 0 7m50s
Deploymentを確認するとREADYとなったPodが3つ揃ってもminReadySeconds
待っていることがわかります。
❯ kubectl get deploy -w
NAME READY UP-TO-DATE AVAILABLE AGE
myapp 2/2 2 2 3m46s
myapp 2/2 2 2 3m48s
myapp 2/2 0 2 3m48s
myapp 2/2 1 2 3m48s
myapp 3/2 1 2 4m8s
myapp 3/2 1 3 5m48s # READYとなるPodが揃ってもminReadySeconds待つ
myapp 2/2 1 2 5m48s # minReadySeconds経過したらPodを減らす
myapp 2/2 2 2 5m48s
myapp 3/2 2 2 6m8s
myapp 3/2 2 3 7m48s
myapp 2/2 2 2 7m48s
まとめ
readinessProbe
でPodがREADYになってからminReadySeconds
で利用可能になるまで待つ- ローリングアップデートではPodがREADYになっても
minReadySeconds
待ってから古いPodが終了する