すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:Kruise Rollout を使用して段階的リリース (カナリア & A/B テスト) を実装する

    ドキュメントセンター

    Container Service for Kubernetes:Kruise Rollout を使用して段階的リリース (カナリア & A/B テスト) を実装する

    最終更新日:Nov 09, 2025

    Kruise Rollout は Kubernetes の標準拡張コンポーネントです。デプロイメントや StatefulSet などのネイティブワークロード、および CloneSet や Advanced StatefulSet などの OpenKruise ワークロードと連携します。Kruise Rollout は、カナリアリリース、A/B テスト、段階的リリースなどの機能を提供します。このトピックでは、例を使用して、Kruise Rollout を使用してクラウドネイティブアプリケーションの段階的リリースを実行する方法について説明します。

    前提条件

    • Kubernetes クラスターが作成されていること。詳細については、「ACK マネージドクラスターの作成」をご参照ください。

      • A/B テストまたはカナリアリリース機能を使用するには、クラスターのバージョンが 1.19 以降である必要があります。

      • 段階的リリース機能を使用するには、クラスターのバージョンが 1.16 以降である必要があります。

    • kubectl-kruise がインストールされていること。kubectl-kruise のインストール方法の詳細については、「kubectl-kruise」をご参照ください。

    Kruise Rollout の概要

    Kruise Rollout は、OpenKruise コミュニティのオープンソースのプログレッシブデリバリーフレームワークです。Kruise Rollout は、トラフィックとインスタンスのスケーリングと連携する段階的リリース、ブルーグリーンリリース、および A/B テストをサポートしています。Prometheus メトリックに基づいて、Kruise Rollout はリリースプロセス中のバッチ処理と一時停止を自動化することもできます。シームレスなバイパス統合を提供し、デプロイメント、CloneSet、StatefulSet などのさまざまな既存のワークロードと互換性があります。詳細については、「Kruise Rollout」をご参照ください。

    Kruise Rollout を使用するには、Rollout リソースを構成し、それを Kubernetes クラスターに適用する必要があります。その後のアプリケーションのリリースやアップグレードに追加の操作は必要ありません。Kruise Rollout は、Helm や Platform as a Service (PaaS) などのプラットフォームとシームレスかつコスト効率よく統合できます。次の図は、Kruise Rollout を使用して段階的リリースを実行するためのアーキテクチャを示しています。gray

    準備

    1. Kruise Rollout コンポーネントをインストールします。

      1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

      2. クラスター ページで、管理するクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、[アドオン] をクリックします。

      3. [コンポーネント管理] ページで、[アプリケーション管理] タブをクリックし、[ack-kruise] カードの右下隅にある [インストール] をクリックします。

      4. ダイアログボックスで情報を確認し、[確認] をクリックします。

      説明

      [ack-kruise] コンポーネントのバージョン 1.8 以降は、v1beta1 API をサポートしています。詳細については、「API 仕様」をご参照ください。

    2. ビジネスアプリケーション (デプロイメントおよびサービス) をデプロイします。

      説明

      ビジネスアプリケーションの構成では、デプロイメントに基づいて echoserver サービスをデプロイし、Nginx Ingress を介してサービスを公開します。

      1. echoserver.yaml ファイルを作成します。

        YAML コンテンツを展開して表示

        apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
  labels:
    app: echoserver
spec:
  replicas: 6
  selector:
    matchLabels:
      app: echoserver
  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
      - name: echoserver
        image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        env:
        - name: NODE_NAME
          value: version1
        - name: PORT
          value: '8080'
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
---
apiVersion: v1
kind: Service
metadata:
  name: echoserver
  labels:
    app: echoserver
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: echoserver

    次のセクションでは、カナリアリリース、A/B テスト、および段階的リリースを実行する方法の例を示します。

    シナリオ 1: Ingress に基づいてカナリアリリースまたは A/B テストリリースを実装する

    Nginx Ingress と MSE Ingress は、サービスを公開するためによく使用されます。この例では、Nginx Ingress または MSE Ingress と Kruise Rollout を使用してカナリアリリースまたは A/B テストを実装する方法を示します。

    1. Ingress コンポーネントをインストールし、ビジネスアプリケーション用の Ingress を作成します。

      Nginx Ingress Controller

      1. Nginx Ingress Controller をインストールします。

      2. echoserver-ingress.yaml ファイルを作成します。

        apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserver
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: echoserver
            port:
              number: 80
        path: /apis/echo
        pathType: Exact

      3. ビジネスアプリケーション用の Ingress をデプロイします。

        kubectl apply -f echoserver-ingress.yaml

      MSE Ingress Controller

      1. MSE Ingress Controller をインストールし、MseIngressConfig と IngressClass を作成します。詳細については、「MSE Ingress を介してコンテナーサービスにアクセスする」をご参照ください。

      2. echoserver-ingress.yaml ファイルを作成します。

        apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserver
spec:
  # ingressClassName を mse に設定する必要があります。
  ingressClassName: mse
  rules:
    - http:
        paths:
          - backend:
              service:
                name: echoserver
                port:
                  number: 80
            path: /apis/echo
            pathType: Exact

      3. ビジネスアプリケーション用の Ingress をデプロイします。

        kubectl apply -f echoserver-ingress.yaml

    2. アクセスを確認します。

      1. 外部 IP アドレスを取得します。

        Nginx Ingress

        export EXTERNAL_IP=$(kubectl get ingress echoserver -o jsonpath="{.status.loadBalancer.ingress[0].ip}" )

        MSE Ingress

        export EXTERNAL_IP=$(kubectl get ingress echoserver -o jsonpath="{.status.loadBalancer.ingress[0].hostname}" )

      2. アクセスをテストします。

        curl http://${EXTERNAL_IP}/apis/echo

        期待される出力:

        Hostname: echoserver-75d49c475c-ls2bs

Pod Information:
    node name:    version1
    pod name:    echoserver-75d49c475c-ls2bs
    pod namespace:    default

Server values:
    server_version=nginx: 1.13.3 - lua: 10008
...

    3. Kruise Rollout の段階的リリースルールを定義します。

      次の Rollout リソースは、段階的リリースルールを定義します。リリースは 3 つのバッチに分かれています。

      カナリア

      • 最初のバッチ: カナリアリリース。トラフィックの 20% が新しいバージョンにルーティングされ、残りは古いバージョンにルーティングされます。

      • 2 番目のバッチ: トラフィックの割合に基づく段階的リリース。このバッチでは、インスタンスとトラフィックの 50% がリリースされます。

      • 3 番目のバッチ: すべてのインスタンスの完全リリース。

      A/B テスト

      • 最初のバッチ: A/B テストリリース。header[User-Agent]=Android に一致するトラフィックは新しいバージョンにルーティングされ、他のすべてのトラフィックは古いバージョンにルーティングされます。

      • 2 番目のバッチ: Pod の割合に基づく段階的リリース。このバッチでは、インスタンスの 50% がリリースされます。

      • 3 番目のバッチ: すべてのインスタンスの完全リリース。

      1. 次の内容で rollout.yaml ファイルを作成します。

        カナリア

        apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: echoserver
  strategy:
    canary:
      steps:
      - weight: 20
        replicas: 1
        pause: {}
      - weight: 50
        replicas: 50%
        pause: {duration: 60}
      - weight: 100
        replicas: 100%
        pause: {duration: 60}
      trafficRoutings:
      - service: echoserver
        ingress:
          name: echoserver

        A/B テスト

        apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: echoserver
  strategy:
    canary:
      steps:
        # ステージ 1: 1 Pod、Android トラフィックに一致
        - matches:
            - headers:
                - type: Exact
                  name: User-Agent
                  value: Android
          pause: {}
          replicas: 1
        # ステージ 2: 50% の Pod、60 秒間自動的に一時停止
        - matches:
            - headers:
                - type: Exact
                  name: User-Agent
                  value: Android
          pause: {duration: 60}
          replicas: 50%
        # ステージ 3: トラフィックに一致する 100% の Pod
        - matches:
            - headers:
                - type: Exact
                  name: User-Agent
                  value: Android
          pause: {duration: 60}
          replicas: 100%
      trafficRoutings:
        - service: echoserver
          ingress:
            name: echoserver

      2. 次のコマンドを実行して、Rollout リソースをクラスターに適用します。

        kubectl apply -f rollout.yaml

      3. 次のコマンドを実行して、Rollout リソースのステータスを確認します。

        kubectl get rollout

        期待される出力:

        NAME            STATUS    CANARY_STEP   CANARY_STATE   MESSAGE                            AGE
rollouts-demo   Healthy   3             Completed      workload deployment is completed   7s                              rollout is healthy   32s

        期待される出力 STATUS=Healthy は、Rollout リソースが正常であることを示します。

    4. アプリケーションのバージョンをアップグレードします。

      Kruise Rollout は永続的な構成です。クラスターに適用した後は、後続のアプリケーションリリースではデプロイメント構成を調整するだけで済みます。Kruise Rollout に対する他の操作は必要ありません。たとえば、echoserver サービスのイメージバージョンを 1.10.3 にアップグレードするには、kubectl apply -f echoserver.yaml コマンドを実行してクラスター内のデプロイメントを更新します。kubectl に加えて、Helm や Vela などのツールを使用して、デプロイメント構成を Kubernetes クラスターに適用することもできます。

      1. echoserver.yaml ファイルを変更して、echoserver サービスのイメージバージョンを 1.10.3 にアップグレードします。

        # echoserver.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
...
spec:
  ...
  containers:
  - name: echoserver
    # mac m1 はイメージ e2eteam/echoserver:2.2-linux-arm を選択できます
    image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.3
    imagePullPolicy: IfNotPresent
        env:
    - name: NODE_NAME
      # オプション。段階的リリースの効果を明確に示すために、値を version2 に変更します。
      value: version2

      2. 次のコマンドを実行して、Rollout リソースのステータスを確認します。

        kubectl get rollouts rollouts-demo -n default

        期待される出力:

        NAME            STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                         AGE
rollouts-demo   Progressing   1             StepPaused     Rollout is in step(1/3), and you need manually confirm to enter the next step   41m

        期待される出力の STATUS フィールドと CANARY フィールドは、ロールアウトのステータスと進行状況を示します。

        • STATUS=Progressing の出力は、カナリアリリースが進行中であることを示します。

        • CANARY_STEP=1 の出力は、リリースが最初のバッチにあることを意味します。

        • 出力が CANARY_STATE=StepPaused の場合、現在のバッチは完了しています。続行するには手動で確認する必要があります。

      3. 旧バージョンと新バージョンの間のトラフィック分散を確認します。

        カナリア

        1. サービスに 10 回連続でアクセスし、返された node name の値を確認します。

          for i in {1..10}; do curl -s http://${EXTERNAL_IP}/apis/echo | grep 'node name'; sleep 1; done

          期待される出力:

                  node name:      version1
        node name:      version1
        node name:      version2
        node name:      version1
        node name:      version2
        node name:      version1
        node name:      version1
        node name:      version1
        node name:      version1
        node name:      version1

          出力は、バージョン 1 とバージョン 2 のトラフィック比が約 8:2 であることを示しています。これは、最初のバッチの重みの期待値を満たしています。

        2. 手動で次のバッチに進みます。

          kubectl-kruise rollout approve rollouts/rollouts-demo -n default

        3. ロールアウトのステータスを継続的に確認します。

          kubectl get rollouts rollouts-demo -n default -w

          期待される出力:

          NAME            STATUS        CANARY_STEP   CANARY_STATE         MESSAGE                                                        AGE
rollouts-demo   Progressing   2             StepTrafficRouting   Rollout is in step(2/3), and upgrade workload to new version   31m
rollouts-demo   Progressing   2             StepMetricsAnalysis   Rollout is in step(2/3), and upgrade workload to new version   31m
rollouts-demo   Progressing   2             StepPaused            Rollout is in step(2/3), and upgrade workload to new version   31m
rollouts-demo   Progressing   2             StepPaused            Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   31m
rollouts-demo   Progressing   2             StepReady             Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   32m
rollouts-demo   Progressing   3             BeforeStepUpgrade     Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepTrafficRouting    Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepMetricsAnalysis   Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepPaused            Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             StepReady             Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             Completed             Rollout is in step(3/3), and upgrade workload to new version                    32m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  32m
rollouts-demo   Progressing   3             Completed             Rollout progressing has been completed                                          33m
rollouts-demo   Healthy       3             Completed             Rollout progressing has been completed                                          33m

          出力は、approve コマンドを実行した後、Rollout リソースが 2 番目のバッチに進み、待機期間の後に自動的に 3 番目のバッチに進むことを示しています。最後に、ステータスが STATUS=Healthy に、CANARY_STATE=Completed に変わり、ロールアウトが完了したことを示します。

        A/B テスト

        1. header[User-Agent]=Android リクエストヘッダーの有無にかかわらずアプリケーションにアクセスできます。

          curl -s http://${EXTERNAL_IP}/apis/echo |grep 'Pod Information:' -A 3
curl -sH "User-Agent: Android" http://${EXTERNAL_IP}/apis/echo | grep 'Pod Information:' -A 3

          期待される出力:

          Pod Information:
        node name:      version1
        pod name:       echoserver-69598f9458-7c66v
        pod namespace:  default
Pod Information:
        node name:      version2
        pod name:       echoserver-fvhzg-687b4b56-qbhc8
        pod namespace:  default

          出力は、2 つのリクエストが version1 と version2 を返すことを示しています。これは、リクエストヘッダーベースのルーティングルールが有効になったことを示します。

        2. 手動で次のバッチに進みます。

          kubectl-kruise rollout approve rollouts/rollouts-demo -n default

        3. ロールアウトのステータスを継続的に確認します。

          kubectl get rollouts rollouts-demo -n default -w

          期待される出力:

          NAME            STATUS        CANARY_STEP   CANARY_STATE         MESSAGE                                                        AGE
rollouts-demo   Progressing   2             StepTrafficRouting   Rollout is in step(2/3), and upgrade workload to new version   26m
rollouts-demo   Progressing   2             StepMetricsAnalysis   Rollout is in step(2/3), and upgrade workload to new version   26m
rollouts-demo   Progressing   2             StepPaused            Rollout is in step(2/3), and upgrade workload to new version   26m
rollouts-demo   Progressing   2             StepPaused            Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   26m
rollouts-demo   Progressing   2             StepReady             Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   27m
rollouts-demo   Progressing   3             BeforeStepUpgrade     Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepUpgrade           Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepTrafficRouting    Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepMetricsAnalysis   Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepPaused            Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             StepReady             Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             Completed             Rollout is in step(3/3), and upgrade workload to new version                    27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  27m
rollouts-demo   Progressing   3             Completed             Rollout progressing has been completed                                          27m
rollouts-demo   Healthy       3             Completed             Rollout progressing has been completed                                          27m

          出力は、approve コマンドを実行した後、Rollout リソースが 2 番目のバッチに進み、待機期間の後に自動的に 3 番目のバッチに進むことを示しています。最後に、ステータスが STATUS=Healthy に、CANARY_STATE=Completed に変わり、ロールアウトが完了したことを示します。

    5. (オプション) 新しいバージョンが異常な場合は、アプリケーションをロールバックします。

      ロールアウト中に新しいバージョンが異常になった場合は、デプロイメント構成を使用して以前のバージョンを復元できます。次に、kubectl apply -f echoserver.yaml コマンドを実行して再デプロイします。Rollout リソースを変更する必要はありません。

      # echoserver.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
...
spec:
  ...
  containers:
  - name: echoserver
    # mac m1 はイメージ e2eteam/echoserver:2.2-linux-arm を選択できます。
    image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
    imagePullPolicy: IfNotPresent
        env:
    - name: NODE_NAME
      value: version1

    シナリオ 2: Pod インスタンスの数に基づく段階的リリース (Nacos などのマイクロサービスフレームワークを使用するアプリケーション向け)

    Nacos などのマイクロサービスフレームワークを使用するほとんどのアプリケーションでは、対応するサービスまたは Ingress 構成は必要ありません。トラフィックの再ルーティング機能は、すでにマイクロサービスフレームワークに統合されています。このタイプのアプリケーションには、Kruise Rollout の段階的リリース機能がより適しています。

    説明

    マイクロサービスフレームワークは段階的リリースのためのトラフィックシフトを処理するため、このシナリオには旧バージョンと新バージョンの間のトラフィック分散の検証は含まれていません。ロールアウトバッチ間の切り替え方法のみを示します。

    1. Kruise Rollout の段階的リリースルールを定義してデプロイします。

      次の Rollout リソースは、trafficRoutings フィールドを構成する必要がない段階的リリースルールを定義します。リリースは 3 つのバッチに分かれています。

      • 最初のバッチ: 1 つの Pod をリリースします。

      • 2 番目のバッチ: Pod の 50% をリリースします。

      • 3 番目のバッチ: 残りのすべてのインスタンスをリリースします。

      # 次の内容を rollout.yaml という名前のファイルに保存します。
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
  annotations:
    rollouts.kruise.io/rolling-style: partition
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      # デプロイメント名
      name: echoserver
  strategy:
    canary:
      steps:
      # ステップ 1: 1 つの Pod を更新し、一時停止して手動での確認を待ちます。
      - replicas: 1
        pause: {} # 次のバッチに進むかどうかを手動で決定します。
      # ステップ 2: Pod インスタンスの 50% を更新します。
      - replicas: 50%
        # 60 秒間の一時停止後、自動的に次のバッチに進みます。
        pause: {duration: 60}
      # ステップ 3: 完全リリース。すべての Pod を新しいバージョンに更新します。
      - replicas: 100%
        pause: {duration: 60}

    2. echoserver.yaml ファイルを変更して、echoserver サービスのイメージバージョンを 1.10.3 にアップグレードします。

      # echoserver.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
...
spec:
  ...
  containers:
  - name: echoserver
    # mac m1 はイメージ e2eteam/echoserver:2.2-linux-arm を選択できます
    image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.3
    imagePullPolicy: IfNotPresent
        env:
    - name: NODE_NAME
      # オプション。段階的リリースの効果を明確に示すために、値を version2 に変更します。
      value: version2

    3. Rollout リソースのステータスを確認します。

      kubectl get rollouts rollouts-demo -n default

      期待される出力:

      NAME            STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                         AGE
rollouts-demo   Progressing   1             StepPaused     Rollout is in step(1/3), and you need manually confirm to enter the next step   41m

      期待される出力の STATUS フィールドと CANARY フィールドは、ロールアウトの進行状況を示します。

      • STATUS=Progressing の出力は、カナリアリリースが進行中であることを示します。

      • CANARY_STEP=1 の出力は、リリースが最初のバッチにあることを示します。

      • CANARY_STATE=StepPaused の出力は、現在のバッチが完了し、続行するかどうかを手動で確認する必要があることを示します。

    4. 手動で次のバッチに進みます。

      kubectl-kruise rollout approve rollouts/rollouts-demo -n default

    5. ロールアウトのステータスを継続的に確認します。

      kubectl get rollouts rollouts-demo -n default -w

      期待される出力:

      NAME            STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                         AGE
rollouts-demo   Progressing   2             StepPaused     Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   45m
rollouts-demo   Progressing   2             StepReady      Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   45m
rollouts-demo   Progressing   3             BeforeStepUpgrade   Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(2/3), and wait duration(60 seconds) to enter the next step   45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    45m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             StepUpgrade         Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             StepMetricsAnalysis   Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             StepPaused            Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             StepReady             Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             Completed             Rollout is in step(3/3), and upgrade workload to new version                    46m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  46m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  46m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  46m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  46m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  46m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  46m
rollouts-demo   Progressing   3             Completed             Rollout has been completed and some closing work is being done                  46m
rollouts-demo   Progressing   3             Completed             Rollout progressing has been completed                                          46m
rollouts-demo   Healthy       3             Completed             Rollout progressing has been completed                                          46m