はじめに
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.ymlPodと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待ってからREADYDeploymentの方を確認してみると、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.20kubectl 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 7m50sDeploymentを確認すると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が終了する
