Cloud Service Mesh 認証局へのカナリアベースの移行

注: このガイドでは、ダウンタイムを最小限に抑えながら（またはダウンタイムなしで）カナリアベースのアプローチにより、Istio CA から Cloud Service Mesh 認証局に移行する方法について説明します。コントロール プレーンを移行せず、ダウンタイムを最小限に抑えながら CA を移行する場合は、インプレース CA 移行をご覧ください。

Istio CA（Citadel とも呼ばれる）から Cloud Service Mesh 認証局（Cloud Service Mesh 認証局）に移行するには、ルート オブ トラストを移行する必要があります。 Cloud Service Mesh 1.10 より前では、Google Kubernetes Engine（GKE）の Istio から Cloud Service Mesh 認証局を使用する Cloud Service Mesh に移行する場合、Cloud Service Mesh で複数のルート証明書を読み込むことができないため、ダウンタイムのスケジューリングが必要になりました。 したがって、移行中、新しくデプロイされたワークロードは新しいルート証明書を信頼しますが、他のワークロードは古いルート証明書を信頼します。異なるルート証明書で署名された証明書を使用するワークロードは相互に認証できません。つまり、移行中は相互 TLS（mTLS）トラフィックが中断されます。クラスタ全体が完全に復元されるのは、コントロール プレーンとすべての名前空間内のすべてのワークロードが、Cloud Service Mesh 認証局の証明書を使用して再デプロイされている場合だけです。複数のクラスタがあり、ワークロードが他のクラスタにリクエストを送信している場合は、これらのクラスタのすべてのワークロードも更新する必要があります。

このガイドでは、次のユースケースについて説明します。

• Istio on GKE から Cloud Service Mesh 認証局を使用する Cloud Service Mesh 1.19.10-asm.9 クラスタ内コントロール プレーンに移行します。
• Istio CA を使用する Cloud Service Mesh 1.15 or a 1.16 patch release から、Cloud Service Mesh 認証局を使用する Cloud Service Mesh 1.19.10-asm.9 クラスタ内コントロール プレーンにアップグレードします。

制限事項

• すべての GKE クラスタが同じ Google Cloud プロジェクト内にある必要があります。

前提条件

依存ツールのインストールとクラスタの検証の手順に沿って、次の操作を行います。

• 必要なツールをインストールする
• asmcli をダウンロードする
• クラスタ管理者の権限を付与する
• プロジェクトとクラスタを検証する

必要なツール

移行中に、Google 提供のツール migrate_ca を実行して、クラスタ内の各 Pod に対して次のことを確認します。

• Istio CA と Cloud Service Mesh 認証局のルート証明書。
• Istio CA と Cloud Service Mesh 認証局によって発行されたワークロード mTLS 証明書。
• Istio CA と Cloud Service Mesh 認証局によって構成された信頼ドメイン。

このツールには、次の依存関係があります。

• awk
• grep
• istioctl。asmcli install を実行すると、インストールする Cloud Service Mesh のバージョンと一致する istioctl のバージョンがダウンロードされます。
• jq
• kubectl
• openssl

移行の概要

Cloud Service Mesh 認証局に移行するには、リビジョン ベースの移行プロセス（「カナリア アップグレード」とも呼ばれます）に従います。リビジョンベースの移行では、既存のコントロール プレーンと一緒に新しいコントロール プレーンのリビジョンがデプロイされます。その後、ワークロードを新しいリビジョンに段階的に移行します。これにより、移行プロセスの結果をモニタリングできます。移行プロセス中は、Cloud Service Mesh 認証局を使用するワークロードと Istio CA を使用するワークロードの間で認証と認可が完全に機能します。

Cloud Service Mesh 認証局への移行の概要は次のとおりです。

1. Cloud Service Mesh 認証局のルート オブ トラストを配布します。

   1. Cloud Service Mesh 認証局のルート オブ トラストを配布するオプションを使用して、Istio CA を使用する新しいコントロール プレーンのリビジョンをインストールします。

   2. 名前空間ごとにワークロードを新しいコントロール プレーンに移行し、アプリケーションをテストします。すべてのワークロードが新しいコントロール プレーンに正常に移行されたら、古いコントロール プレーンを削除します。

2. Cloud Service Mesh 認証局に移行します。すべてのサイドカー プロキシが古いルート オブ トラストと Cloud Service Mesh 認証局のルート オブ トラストで構成されたので、ダウンタイムなしで Cloud Service Mesh 認証局に移行できます。前述のとおり、リビジョンベースの移行プロセスを行います。

   1. Cloud Service Mesh 認証局を有効にしてコントロール プレーンのリビジョンをインストールします。

   2. 名前空間ごとにワークロードを新しいコントロール プレーン リビジョンに移行し、アプリケーションをテストします。すべてのワークロードが新しいコントロール プレーンに正常に移行されたら、古いコントロール プレーンを削除します。

   3. 古い CA に関連付けられているクラスタの CA Secret を削除し、新しいコントロール プレーンを再起動します。

Cloud Service Mesh 認証局のルート オブ トラストを配布する

Cloud Service Mesh 認証局に移行する前に、メッシュ内のすべての GKE クラスタに Cloud Service Mesh 1.10 以降が必要です。また、クラスタ上のすべてのワークロードのプロキシへの、Cloud Service Mesh 認証局のルート オブ トラストの配布をトリガーするコントロール プレーン オプションを使用して、すべてのクラスタを構成する必要があります。このプロセスが完了すると、各プロキシは古いルートと新しいルート オブ トラストの両方を使用して構成されます。このスキームでは、Cloud Service Mesh 認証局に移行すると、Cloud Service Mesh 認証局を使用するワークロードは古い CA を使用するワークロードで認証できるようになります。

新しいコントロール プレーン リビジョンをインストールする

Cloud Service Mesh 認証局のルート オブ トラストを配布するオプションを使用して、コントロール プレーンのリビジョンをインストールします。

1. 依存ツールのインストールとクラスタの検証の手順に従って、Google 提供のツール asmcli を使用して新しいコントロール プレーンのリビジョンをインストールする準備を行います。

2. Cloud Service Mesh 1.11 以降をインストールする asmcli のバージョンがあることを確認します。

   ./asmcli --version
   

3. asmcli install を実行します。次のコマンドのプレースホルダは実際の値に置き換えます。

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --enable_all \
      --ca citadel \
      --ca_cert CA_CERT_FILE_PATH \
      --ca_key CA_KEY_FILE_PATH \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH \
      --option ca-migration-citadel \
      --revision_name REVISION_1 \
      --output_dir DIR_PATH
   

• --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
• --kubeconfig: kubeconfig ファイルのパス。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
• --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
• --enable_all ツールを使用して次のことができます。
  • 必要な IAM 権限を付与する。
  • 必要な Google API を有効にする。
  • メッシュを識別するラベルをクラスタに設定する。
  • フリートにクラスタを登録する（まだ登録されていない場合）。
• -ca citadel: ダウンタイムを回避するには、Istio CA を指定します（`citadel` オプションは Istio CA に対応します）。この時点では、まだ Cloud Service Mesh 認証局に切り替えないでください。
• --ca_cert: 中間証明書
• --ca_key: 中間証明書の鍵
• --root_cert: ルート証明書
• --cert_chain: 証明書チェーン
• --option ca-migration-citadel: ワークロードを再デプロイするすると、このオプションにより、ワークロードのサイドカー プロキシへの新しいルート オブ トラストの配布がトリガーされます。
• REVISION_1: 推奨。[リビジョン ラベル]（/service-mesh/docs/revisions-overview）は、コントロール プレーンで設定されている Key-Value ペアです。リビジョン ラベルキーは常に istio.io/rev になります。デフォルトでは、スクリプトは Cloud Service Mesh のバージョンに基づいてリビジョン ラベルの値を設定します（例: asm-11910-9）。このオプションを指定して、REVISION_1 をインストールの名前（asm-11910-9-distribute-root など）に置き換えることをおすすめします。名前は DNS-1035 のラベルにします。ラベルには小文字の英数字または - を使用し、ラベルの先頭は英字に、ラベルの最後は英数字にする必要があります（例: my-name、abc-123 など）。

ワークロードを新しいコントロール プレーンに移行する

新しいルート オブ トラストの配布を終了するには、リビジョン ラベル istio.io/rev=<var>REVISION_1</var>-distribute-root を使用して名前空間にラベルを設定し、ワークロードを再起動する必要があります。再起動後にワークロードをテストするには、ツールを実行して、サイドカー プロキシに Cloud Service Mesh 認証局の新旧両方のルート オブ トラストが構成されていることを確認します。

1. kubectl の現在のコンテキストを設定します。シングルゾーン クラスタの場合は、次のコマンドの --region を --zone に変更します。

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --region=CLUSTER_LOCATION
   

2. 検証ツールをダウンロードします。

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
   

3. ツールで実行可能ビットを設定します。

   chmod +x migrate_ca
   

4. migrate_ca ツールは、バージョンに依存する istioctl を呼び出します。asmcli ツールは、--output_dir に指定したディレクトリの istioctl にシンボリック リンクを追加します。ディレクトリがパスの先頭にあることを確認します。次のコマンドで、ISTIOCTL_PATH はツールがダウンロードした istioctl を含むディレクトリに置き換えます。

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

5. istiod と istio-ingressgateway のリビジョン ラベルを取得します。

   kubectl get pod -n istio-system -L istio.io/rev
   

   出力は次のようになります。

   NAME                                                             READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
   istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
   istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
   istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
   istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
   istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

   1. 出力の REV 列で、新しいリビジョンのリビジョン ラベルの値をメモします。この値は、asmcli install を実行したときに指定したリビジョン ラベルと一致します。この例の値は asm-11910-9-distribute-root です。

   2. ワークロードを新しいリビジョンに移行したら、istiod の古いリビジョンを削除する必要があります。古い istiod リビジョンのリビジョン ラベルの値をメモします。この出力例は、default リビジョンを使用している Istio からの移行を示しています。

6. リビジョン ラベルを名前空間に追加し、istio-injection ラベルを削除します（ある場合）。次のコマンドで、NAMESPACE はラベルを付ける名前空間に置き換えます。

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite

   出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクション動作は未定義になるため、Cloud Service Mesh ドキュメント内のすべての kubectl label コマンドでは明示的に一方のみが設定されることになります。

7. Pod を再起動してインジェクションを再度トリガーします。

   kubectl rollout restart deployment -n NAMESPACE
   

8. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。

9. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。

10. クラスタ上のすべてのワークロードのサイドカー プロキシが、古いルート証明書と新しいルート証明書の両方で構成されていることを確認します。

    ./migrate_ca check-root-cert
    

    予想される出力:

    Namespace: foo
    httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
    sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]

11. ゲートウェイを移行する必要がある場合は、カナリア アップグレード（高度）の手順に従って新しいゲートウェイ デプロイをインストールします。その際、以下の点にご注意ください。

    • リビジョン ラベルとして REVISION_1 を使用します。
    • 以前インストールしたゲートウェイと同じ名前空間にゲートウェイ リソースをデプロイして、ゼロ ダウンタイムでの移行を実行します。古いゲートウェイを指すサービス リソースに、新しいデプロイも含めるようにしてください。
    • アプリケーションが正常に動作していることを確認する（次のステップの後）まで、古いゲートウェイ デプロイを削除しないでください。

12. アプリケーションが想定どおりに動作していることを確認したら、istiod の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。

    移行を完了させる

    アプリケーションが想定どおりに動作していることを確認したら、古いコントロール プレーンを削除して新しいバージョンへの移行を完了します。

    1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。

    2. 新しいコントロール プレーンを使用するように検証 Webhook を構成します。

       kubectl apply -f asm/istio/istiod-service.yaml
       

    3. 古い istio-ingressgateway Deployment を削除します。実行するコマンドは、Istio から移行するか、以前のバージョンの Cloud Service Mesh からアップグレードするかによって異なります。

       移行

       Istio から移行した場合、古い istio-ingressgateway にはリビジョン ラベルがありません。

       kubectl delete deploy/istio-ingressgateway -n istio-system
       

       アップグレード

       以前の Cloud Service Mesh バージョンからアップグレードした場合は、次のコマンドで、OLD_REVISION を以前のバージョンの istio-ingressgateway のリビジョン ラベルに置き換えます。

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
       

    4. istiod の古いリビジョンを削除します。使用するコマンドは、Istio から移行するか、以前のバージョンの Cloud Service Mesh からアップグレードするかによって異なります。

       移行

       Istio から移行した場合、古い istio-ingressgateway にはリビジョン ラベルがありません。

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
       

       アップグレード

       以前の Cloud Service Mesh バージョンからアップグレードした場合は、次のコマンドで、OLD_REVISION が以前のバージョンの istiod のリビジョン ラベルと一致することを確認します。

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
       

    5. 古いバージョンの IstioOperator 構成を削除します。

       kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
       

       想定される出力は次のようになります。

       istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    ロールバック

    新しいバージョンの istiod でアプリケーションをテストしたときに問題が発生した場合、以前のバージョンにロールバックする手順は次のとおりです。

    1. 手順 11 の一部としてインストールした新しいゲートウェイ デプロイを削除します。

    2. 以前のバージョンの istiod で自動挿入を有効にする場合は、名前空間に再びラベルを付けます。使用するコマンドは、リビジョン ラベルと以前のバージョンの istio-injection=enabled のどちらを使用するかによって異なります。

       • 自動挿入にリビジョン ラベルを使用した場合:

         kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
         

       • istio-injection=enabled を使用した場合:

         kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
         

       予想される出力:

       namespace/NAMESPACE labeled

    3. 名前空間のリビジョン ラベルが、以前のバージョンの istiod のリビジョン ラベルと一致していることを確認します。

       kubectl get ns NAMESPACE --show-labels
       

    4. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

       kubectl rollout restart deployment -n NAMESPACE
       

    5. 新しい istio-ingressgateway Deployment を削除します。

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
       

    6. istiod の新しいリビジョンを削除します。

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
       

    7. 新しい IstioOperator 構成を削除します。

       kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system
       

       予想される出力は次のようになります。

       istiooperator.install.istio.io "installed-state-asm-11910-9-distribute-root" deleted

Cloud Service Mesh 認証局に移行する

すべてのワークロードのサイドカー プロキシが、Cloud Service Mesh 認証局の新旧両方のルート オブ トラストを使用して構成されているため、Cloud Service Mesh 認証局に移行する手順は、Cloud Service Mesh 認証局のルート オブ トラストを配布する手順と似ています。

Cloud Service Mesh 認証局を有効にした新しいコントロール プレーンをインストールする

asmcli install を使用して、Mesh CA を有効にした新しいコントロール プレーン リビジョンをインストールします。

1. 以前のインストールをカスタマイズした場合は、asmcli install の実行時に同じオーバーレイ ファイルを指定する必要があります。

2. asmcli install を実行します。次のコマンドのプレースホルダは実際の値に置き換えます。

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --output_dir DIR_PATH \
      --enable_all \
      --ca mesh_ca \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH
      --option ca-migration-meshca \
     --revision_name REVISION_2 \
     --output_dir DIR_PATH \
     OVERLAYS
   

   • --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
   • --kubeconfig: kubeconfig ファイルのパス。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
   • --enable_all ツールを使用して次のことができます。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • --ca mesh_ca: Cloud Service Mesh 認証局のルート オブ トラストが配布されているため、Cloud Service Mesh 認証局に切り替えることができます。
   • （推奨 REVISION_2）REVISION_2 は、インストールを表す名前（asm-11910-9-meshca-ca-migration など）に置き換えます。名前は DNS-1035 のラベルにします。ラベルには小文字の英数字または - を使用し、ラベルの先頭は英字に、ラベルの末尾は英数字にする必要があります（例: my-name、abc-123）。
   • --option ca-migration-migration: [ワークロードを再デプロイする](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads) ときに、このオプションにより、Cloud Service Mesh 認証局のルート オブ トラストを使用するようにプロキシを構成します。

ワークロードを新しいコントロール プレーンに移行する

インストールを完了するには、新しいリビジョン ラベルで名前空間にラベルを付け、ワークロードを再起動する必要があります。

1. istiod と istio-ingressgateway のリビジョン ラベルを取得します。

   kubectl get pod -n istio-system -L istio.io/rev
   

   出力は次のようになります。

   NAME                                                                          READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-asm-11910-9-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-11910-9-distribute-root
   istio-ingressgateway-asm-11910-9-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-11910-9-distribute-root
   istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-11910-9-meshca-ca-migration
   istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-11910-9-meshca-ca-migration
   istiod-asm-11910-9-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-11910-9-distribute-root
   istiod-asm-11910-9-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-11910-9-distribute-root
   istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration
   istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration

   1. 出力の REV 列にある、新しいバージョンのリビジョン ラベルの値をメモします。この例での値は asm-11910-9-meshca-ca-migration です。

   2. 古い istiod バージョンのリビジョン ラベルの値にも注意してください。これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンの istiod を削除するために必要です。この例で、前のリビジョンのリビジョン ラベルの値は asm-11910-9-distribute-root です。

2. 新しいリビジョン ラベルを名前空間に追加します。次のコマンドで、NAMESPACE はラベルを付ける名前空間に置き換えます。

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
   

3. Pod を再起動してインジェクションを再度トリガーします。

   kubectl rollout restart deployment -n NAMESPACE
   

4. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。mTLS 通信が古い名前空間のワークロードと新しい名前空間のワークロードの間で機能することを確認します。

5. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。

6. インプレース アップグレードの手順に沿って、前のセクションのステップ 11 でインストールした古いゲートウェイ デプロイメントを最新のリビジョン REVISION_2 にアップグレードします。

7. アプリケーションが想定どおりに動作していることを確認したら、新しいコントロール プレーンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。

   移行を完了させる

   アプリケーションが想定どおりに動作していることを確認したら、古いコントロール プレーンを削除して新しいバージョンへの移行を完了します。

   1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。

   2. 新しいコントロール プレーンを使用するように検証 Webhook を構成します。

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. 古い istio-ingressgateway Deployment を削除します。次のコマンドの OLD_REVISION は、前バージョンの istio-ingressgateway のリビジョン ラベルに置き換えます。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   4. 古い istiod リビジョンを削除します。次のコマンドの OLD_REVISION は、以前のバージョンの istiod のリビジョン ラベルに置き換えます。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. 古い IstioOperator 構成を削除します。

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      想定される出力は次のようになります。

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   ロールバック

   新しい istiod リビジョンでアプリケーションをテストしたときに問題が発生した場合は、次の手順で以前のバージョンにロールバックします。

   1. インプレース アップグレードの手順に沿って、このセクションのステップ 6 で以前にアップグレードしたゲートウェイ デプロイメントを古いリビジョン REVISION_1 にダウングレードします。

   2. 以前の istiod リビジョンで自動挿入を有効にするには、名前空間のラベルを変更します。

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
      

      予想される出力:

      namespace/NAMESPACE labeled

   3. 名前空間のリビジョン ラベルが、以前のバージョンの istiod のリビジョン ラベルと一致していることを確認します。

      kubectl get ns NAMESPACE --show-labels
      

   4. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

      kubectl rollout restart deployment -n NAMESPACE
      

   5. 新しい istio-ingressgateway Deployment を削除します。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
      

   6. istiod の新しいバージョンを削除します。次のコマンドのリビジョン ラベルがリビジョンと一致していることを確認します。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
      

   7. 新しいバージョンの IstioOperator 構成を削除します。

      kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
      

      予想される出力は次のようになります。

      istiooperator.install.istio.io "installed-state-REVISION_2" deleted

CA Secret を削除して新しいコントロール プレーンを再起動する

1. 必要な場合にのみ Secret を維持します。

   kubectl get secret/cacerts -n istio-system -o yaml > save_file_1
   kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2
   

2. 古い CA に関連付けられたクラスタ内の CA Secret を削除します。

   kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
   

3. 新しくインストールしたコントロール プレーンを再起動します。これにより、古いルート オブ トラストが、メッシュ内で実行中のすべてのワークロードからクリーンアップされます。

   kubectl rollout restart deployment -n istio-system