ゼロダウンタイム Pod ローリング更新のための Readiness Gates を構成 - ACK

LoadBalancer サービスを介して Pod を公開する場合、ローリングアップデート中に一時的なトラフィックの中断が発生する可能性があります。Pod コンテナは、cloud-controller-manager (CCM) がクラシックロードバランサー (CLB) または Network Load Balancer (NLB) のバックエンドサーバーグループに登録するよりも早く準備状態になります。レディネスゲートを設定すると、各 Pod が完全に登録され、トラフィックを処理するまでローリングアップデートサイクルから除外されるため、これを防ぐことができます。

前提条件

開始する前に、以下を確認してください。

以下の構成を持つ Container Service for Kubernetes (ACK) マネージドクラスターまたは ACK サーバーレスクラスター。
- ネットワークプラグインが Terway に設定されていること (ACK マネージドクラスターのみ)
- Kubernetes バージョン 1.24 以降。アップグレード手順については、「クラスターのアップグレード」をご参照ください。
- CCM バージョン 2.10.0 以降。バージョンの詳細については、「CCM」をご参照ください。
kubectl がクラスターに接続済みであること。セットアップ手順については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。

クラスターの作成については、「ACK マネージドクラスターの作成」または「ACK サーバーレスクラスターの作成」をご参照ください。

仕組み

レディネスゲートがない場合、このシーケンスはローリングアップデート中にトラフィックの中断を引き起こします。

ローリングアップデートが開始されます。Kubernetes は古い Pod を終了し、新しい Pod を起動します。
新しい Pod のコンテナはヘルスチェックに合格し、数秒で Running ステータスに到達します。
Kubernetes は Pod を Ready とマークし、トラフィックをルーティングします。
CCM はまだ Pod を CLB または NLB バックエンドサーバーグループに登録していません。登録は通常、コンテナの起動よりも時間がかかります。
登録が完了するまで、Pod にルーティングされたリクエストは失敗します。

conditionType: service.readiness.alibabacloud.com/<Service Name> を持つレディネスゲートを追加すると、Kubernetes は各 Pod にカスタム条件を追加します。CCM は、Pod がバックエンドサーバーグループに登録され、正常な状態になった後にのみ、この条件を True に設定します。この条件が満たされるまで、Pod の READINESS GATES ステータスは 0/1 と表示され、Kubernetes はトラフィックをルーティングしたり、ローリングアップデートを進めたりしません。

Pod が複数のロードバランサーにマウントされている場合は、LoadBalancer サービスごとに 1 つのレディネスゲートを設定してください。

ステップ 1: CLB または NLB インスタンスの作成

以下のいずれかのテンプレートを使用して、my-svc.yaml という名前のファイルを作成します。

CLB

apiVersion: v1
kind: Service
metadata:
  name: my-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: nginx
  type: LoadBalancer

NLB

apiVersion: v1
kind: Service
metadata:
  name: my-svc
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-zone-maps: "${zone-A}:${vsw-A},${zone-B}:${vsw-B}" # 例: cn-hangzhou-k:vsw-i123456,cn-hangzhou-j:vsw-j654321.
spec:
  loadBalancerClass: alibabacloud.com/nlb # NLB に設定します。
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: nginx
  type: LoadBalancer

サービスマニフェストを適用します。
```
kubectl apply -f my-svc.yaml
```
サービスが外部 IP アドレスを持つまで待ちます。
```
kubectl get service my-svc
```
EXTERNAL-IP 列に IP アドレスが表示されたら、CLB または NLB インスタンスの準備が完了です。
```
NAME     TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)        AGE
my-svc   LoadBalancer   192.XX.XX.215   <IP address>     80:30493/TCP   8s
```

ステップ 2: テスト Deployment の作成

my-nginx.yaml という名前のファイルを作成します。conditionType を service.readiness.alibabacloud.com/my-svc に設定して、Pod のレディネスゲートを my-svc サービスに紐付けます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx    # Deployment の名前。
  labels:
    app: nginx
spec:
  replicas: 2       # レプリカ Pod の数。
  selector:
    matchLabels:
      app: nginx     # サービス内のセレクターと一致する必要があります。
  template:
    metadata:
      labels:
        app: nginx
    spec:
      readinessGates:
      - conditionType: service.readiness.alibabacloud.com/my-svc # my-svc サービスのレディネスゲート。
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80

Deployment をデプロイします。
```
kubectl apply -f my-nginx.yaml
```
Pod ステータスとレディネスゲートの状態を確認します。
```
kubectl get pod -owide -l app=nginx
```
最初は、READINESS GATES は 0/1 と表示されます。これは、CCM がまだ Pod を登録していないことを意味します。
```
NAME                       READY   STATUS    RESTARTS   AGE   IP               NODE                         NOMINATED NODE   READINESS GATES
my-nginx-d9f95dcf9-8dhwj   1/1     Running   0          14s   172.XX.XXX.188   cn-hangzhou.172.XX.XXX.174   <none>           0/1
my-nginx-d9f95dcf9-z9hjm   1/1     Running   0          14s   172.XX.XXX.182   cn-hangzhou.172.XX.XXX.174   <none>           0/1
```
しばらく待ってからコマンドを再度実行します。READINESS GATES が 1/1 に変わると、Pod は CLB または NLB バックエンドサーバーグループに登録され、トラフィックを処理する準備が完了です。

ステップ 3: ローリングアップデートの実行

ローリングアップデートをトリガーします。
```
kubectl rollout restart deployment my-nginx
```
予想される出力:
```
deployment.apps/my-nginx restarted
```

ローリングアップデートの進行中に Pod ステータスを監視します。

kubectl get pod -owide -l app=nginx

アップデート中、古い Pod と新しい Pod が共存します。新しい Pod は、CCM が登録するまで READINESS GATES: 0/1 で待機します。

NAME                       READY   STATUS    RESTARTS   AGE    IP               NODE                         NOMINATED NODE   READINESS GATES
my-nginx-d9f95dcf9-8dhwj   1/1     Running   0          113s   172.XX.XXX.188   cn-hangzhou.172.XX.XXX.174   <none>           1/1
my-nginx-df5c9cf7d-6p5jc   1/1     Running   0          6s     172.XX.XXX.182   cn-hangzhou.172.XX.XXX.174   <none>           0/1
my-nginx-df5c9cf7d-7dh2v   1/1     Running   0          15s    172.XX.XXX.189   cn-hangzhou.172.XX.XXX.174   <none>           1/1

ローリングアップデートは、現在の新しい Pod が READINESS GATES: 1/1 に到達した後にのみ次の Pod に進み、アップデート全体を通して中断のないトラフィックを保証します。

トラブルシューティング

レディネスゲートが長期間 0/1 のままになる

Pod の READINESS GATES が数分経っても 1/1 に変わらない場合は、Pod のステータス条件を調べて原因を特定してください。

kubectl get pod <pod-name> -o yaml | grep -A8 'service.readiness.alibabacloud.com'

出力には、CCM によって設定された条件が表示され、登録が完了していない理由を示す reason フィールドが含まれています。一般的な原因としては、CCM バージョンが 2.10.0 未満であること、Terway がアクティブなネットワークプラグインではないこと、またはバックエンドサーバーグループがまだプロビジョニングされていないことなどが挙げられます。

詳細については、CCM ログを確認してください。

kubectl logs -n kube-system -l app=cloud-controller-manager --tail=100