【Kubernetes】ローリングアップデートでのminReadySecondsとreadinessProbe

はじめに
readinessProbe
minReadySeconds
ローリングアップデートでどうなるか
まとめ
参考

はじめに

Kubernetesでローリングアップデートをする時に、readinessProbeとminReadySecondsを設定するとどう動くのか気になったので実際に試してみました。

readinessProbe

readinessProbeは、コンテナがリクエストに応答できるかを判断する設定です。

readinessProbe.initialDelaySecondsで最初にチェックするまでの待機時間を、readinessProbe.periodSecondsでチェックする間隔を設定できます。

readinessProbe:
  tcpSocket:              # ポートによるチェック
    port: 80
  initialDelaySeconds: 30 # 最初にチェックするまでの待機時間
  periodSeconds: 60       # チェックする頻度

【Kubernetes】LivenessProbeとReadinessProbeを試してみる

はじめにKubernetesにおけるLivenessProbeとReadinessProbeについて解説し、実際に設定してPodを動かしてみたいと思います。LivenessProbe/ReadinessProbeとはLivenessProb...

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つずつアップデートされています。

【Kubernetes】ローリングアップデートをやってみる

はじめにKubernetesのデプロイ戦略として、ローリングアップデートを実際に動かして試してみます。Kubernetesでの代表的なデプロイ戦略については、下記でざっくりまとめています。ローリングアップデートとはローリングアップデートは、...

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