Anthos Service Mesh 1.10 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

Mesh CA への移行

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

このページでは、ダウンタイムを最小限に抑えながら Istio CA から Mesh CA に移行する方法について説明します。このガイドでは、次のユースケースについて説明します。

GKE の Istio から Mesh CA を使用する Anthos Service Mesh 1.10.6-asm.2 クラスタ内コントロールプレーンに移行する。
Istio CA を使用する Anthos Service Mesh 1.9 or a 1.10 patch release から Mesh CA を使用する Anthos Service Mesh 1.10.6-asm.2 クラスタ内コントロールプレーンにアップグレードする。

制限事項

Mesh CA は GKE でのみサポートされています。
すべての GKE クラスタが同じ Google Cloud プロジェクト内にある必要があります。

前提条件

このガイドは、以下のものがあることを前提としています。

Google Cloud プロジェクト
Cloud 請求先アカウント
install_asm スクリプトの実行に必要なツール
Istio CA を使用するマルチクラスタメッシュの場合、各クラスタに同じルート証明書を設定する必要があります。

必要なツール

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

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

このスクリプトには次の依存関係があります。

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

移行の概要

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

Mesh CA への移行の概要は次のとおりです。

Mesh CA のルートオブトラストを配布します。
1. Mesh CA ルートオブトラストを配布するオプションを使用して、新しいコントロールプレーンのリビジョンをインストールします。
2. 名前空間ごとにワークロードを新しいコントロールプレーンに移行し、アプリケーションをテストします。すべてのワークロードが新しいコントロールプレーンに正常に移行されたら、古いコントロールプレーンを削除します。
Mesh CA に移行します。すべてのサイドカープロキシが古いルートオブトラストと Mesh CA のルートオブトラストで構成されたので、ダウンタイムなしで Mesh CA に移行できます。前述のとおり、リビジョンベースの移行プロセスを行います。
1. Mesh CA を有効にしてコントロールプレーンのリビジョンをインストールします。
2. 名前空間ごとにワークロードを新しいコントロールプレーンリビジョンに移行し、アプリケーションをテストします。すべてのワークロードが新しいコントロールプレーンに正常に移行されたら、古いコントロールプレーンを削除します。
3. 古い CA に関連付けられているクラスタの CA Secret を削除し、新しいコントロールプレーンを再起動します。

Mesh CA ルートオブトラストを配布する

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

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

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

GKE への Anthos Service Mesh のインストールの手順を行い、Google 提供のスクリプト install_asm を実行して新しいコントロールプレーンリビジョンをインストールする準備を行います。
Anthos Service Mesh 1.10 以降をインストールする install_asm のバージョンがあることを確認します。
```
./install_asm --version
```
install_asm を実行します。次のコマンドのプレースホルダは実際の値に置き換えます。
- PROJECT_ID: 必須。クラスタが作成されたプロジェクトのプロジェクト ID。
- CLUSTER_NAME: 必須。クラスタの名前。
- CLUSTER_LOCATION: 必須。クラスタが存在するゾーンまたはリージョン。
- REVISION_1: 推奨。リビジョンラベルは、コントロールプレーンで設定されている Key-Value ペアです。リビジョンラベルキーは常に istio.io/rev になります。デフォルトでは、スクリプトは Anthos Service Mesh のバージョンに基づいてリビジョンラベルの値を設定します（例: asm-1106-2）。このオプションを指定して、REVISION_1 をインストールの名前（asm-1106-2-distribute-root など）に置き換えることをおすすめします。この名前は DNS-1035 のラベルにします。ラベルには小文字の英数字または - を使用し、ラベルの先頭は英字に、ラベルの最後は英数字にする必要があります（例: my-name'、abc-123）。検証に使用される正規表現は '[a-z]([-a-z0-9]*[a-z0-9])?') です。
- DIR_PATH : 必須。スクリプトによって anthos-service-mesh パッケージと Anthos Service Mesh インストールファイル（istioctl、サンプル、マニフェストを含む）がダウンロードされるディレクトリの相対パス。
- OVERLAYS: 省略可。オプションの機能を有効にするには、機能ごとにオーバーレイファイルの名前を指定して --custom_overlay を使用します。オプションの機能を有効にしない場合は、この行と前の行のバックスラッシュを削除します。
```
./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all \
  --option ca-migration-citadel \
  --revision_name REVISION_1  \
  --output_dir DIR_PATH \
  OVERLAYS
```
次のコマンドライン引数は必須です。
- --ca citadel: ダウンタイムを回避するには、Istio CA を指定します（citadel オプションは Istio CA に対応します）。この時点では、まだ Mesh CA に切り替えないでください。
- --option ca-migration-citadel: ワークロードを再デプロイするすると、このオプションにより、ワークロードのサイドカープロキシへの新しいルートオブトラストの配布がトリガーされます。

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

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

kubectl の現在のコンテキストを設定します。シングルゾーンクラスタの場合は、次のコマンドの --region を --zone に変更します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION
```

検証スクリプトをダウンロードします。

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

スクリプトで実行可能ビットを設定します。
```
chmod +x migrate_ca
```
migrate_ca スクリプトは、バージョンに依存する istioctl を呼び出します。install_asm スクリプトは、--output_dir に指定したディレクトリの istioctl にシンボリックリンクを追加します。ディレクトリがパスの先頭にあることを確認します。次のコマンドで、ISTIOCTL_PATH はスクリプトがダウンロードした istioctl を含むディレクトリに置き換えます。
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

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

出力の REV 列で、新しいリビジョンのリビジョンラベルの値をメモします。この値は、install_asm を実行したときに指定したリビジョンラベルと一致します。この例の値は asm-1106-2-distribute-root です。
ワークロードを新しいリビジョンに移行したら、istiod の古いリビジョンを削除する必要があります。古い istiod リビジョンのリビジョンラベルの値をメモします。この出力例は、default リビジョンを使用している Istio からの移行を示しています。

istio-ingressgateway を新しいリビジョンに切り替えます。次のコマンドは、REVISION_1 が新しいリビジョンのリビジョンラベルの値と一致することを確認します。
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_1"}]'
```
予想される出力:
```
service/istio-ingressgateway patched
```
リビジョンラベルを名前空間に追加し、istio-injection ラベルを削除します（ある場合）。次のコマンドで、NAMESPACE はラベルを付ける名前空間に置き換えます。
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
```
出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。
Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n NAMESPACE
```
Pod が新しいバージョンの istiod を指すように構成されていることを確認します。
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION_1
```
アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
クラスタ上のすべてのワークロードのサイドカープロキシが、古いルート証明書と新しいルート証明書の両方で構成されていることを確認します。
```
./migrate_ca check-root-cert
```
予想される出力:
```
Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
```
アプリケーションが想定どおりに動作していることを確認したら、istiod の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。
移行を完了させる
アプリケーションが想定どおりに動作していることを確認したら、古いコントロールプレーンを削除して新しいバージョンへの移行を完了します。
1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。
2. 新しいコントロールプレーンを使用するように検証 Webhook を構成します。
```
kubectl apply -f asm/istio/istiod-service.yaml
```
3. 古い istio-ingressgateway Deployment を削除します。実行するコマンドは、Istio から移行するか、以前のバージョンの Anthos Service Mesh からアップグレードするかによって異なります。
  移行
  Istio から移行した場合、古い istio-ingressgateway にはリビジョンラベルがありません。
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  アップグレード
  以前の Anthos 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 から移行するか、以前のバージョンの Anthos Service Mesh からアップグレードするかによって異なります。
  移行
  Istio から移行した場合、古い istio-ingressgateway にはリビジョンラベルがありません。
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  アップグレード
  以前の Anthos 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. istio-ingressgatewqy を古いバージョンに戻します。次のコマンドの OLD_REVISION は、古いリビジョンに置き換えます。
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
```
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-1106-2-distribute-root -n istio-system
```
  予想される出力は次のようになります。
```
istiooperator.install.istio.io "installed-state-asm-1106-2-distribute-root" deleted
```

Mesh CA に移行する

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

Mesh CA を有効にした新しいコントロールプレーンをインストールする

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

以前のインストールをカスタマイズした場合は、install_asm の実行時に同じオーバーレイファイルを指定する必要があります。
install_asm を実行します。次のコマンドのプレースホルダは実際の値に置き換えます。
- PROJECT_ID: 必須。クラスタが作成されたプロジェクトのプロジェクト ID。
- CLUSTER_NAME: 必須。クラスタの名前。
- CLUSTER_LOCATION: 必須。クラスタが存在するゾーンまたはリージョン。
- REVISION_2: 推奨。REVISION_2 は、インストールを表す名前（asm-1106-2-meshca-ca-migration など）に置き換えます。この名前は DNS-1035 のラベルにします。ラベルには小文字の英数字または - を使用し、ラベルの先頭は英字に、ラベルの最後は英数字にする必要があります（例: my-name'、abc-123）。検証に使用される正規表現は '[a-z]([-a-z0-9]*[a-z0-9])?') です。
- DIR_PATH : 必須。スクリプトによって anthos-service-mesh パッケージと Anthos Service Mesh インストールファイル（istioctl、サンプル、マニフェストを含む）がダウンロードされるディレクトリの相対パス。
- OVERLAYS: 省略可。オプションの機能を有効にするには、機能ごとにオーバーレイファイルの名前を指定して --custom_overlay を使用します。オプションの機能を有効にしない場合は、この行と前の行のバックスラッシュを削除します。
```
./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --enable_all \
  --option ca-migration-meshca \
  --revision_name REVISION_2 \
  --output_dir DIR_PATH \
  OVERLAYS
```
次のコマンドライン引数は必須です。
- --ca mesh_ca: Mesh CA のルートオブトラストが配布されているため、Mesh CA に切り替えることができます。
- --option ca-migration-migration: ワークロードを再デプロイするときに、このオプションにより、Mesh CA ルートオブトラストを使用するようにプロキシを構成します。

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

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

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

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

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

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

出力の REV 列にある、新しいバージョンのリビジョンラベルの値をメモします。この例での値は asm-1106-2-meshca-ca-migration です。
古い istiod バージョンのリビジョンラベルの値もメモしてください。これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンの istiod を削除するために必要です。この例で、前のリビジョンのリビジョンラベルの値は asm-1106-2-distribute-root です。

istio-ingressgateway を新しいリビジョンに切り替えます。次のコマンドで、REVISION_2 を新しいバージョンのリビジョンラベルと一致する値に変更します。
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_2"}]'
```
予想される出力:
```
service/istio-ingressgateway patched
```
新しいリビジョンラベルを名前空間に追加します。次のコマンドで、NAMESPACE はラベルを付ける名前空間に置き換えます。
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
```
Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n NAMESPACE
```
Pod が新しいバージョンの istiod を指すように構成されていることを確認します。
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION_2
```
アプリケーションをテストして、ワークロードが正しく機能していることを確認します。mTLS 通信が古い名前空間のワークロードと新しい名前空間のワークロードの間で機能することを確認します。
他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
アプリケーションが想定どおりに動作していることを確認したら、新しいコントロールプレーンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。
移行を完了させる
アプリケーションが想定どおりに動作していることを確認したら、古いコントロールプレーンを削除して新しいバージョンへの移行を完了します。
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. 以前の istio-ingressgatewqy に戻します。次のコマンドの OLD_REVISION は、古いリビジョンに置き換えます。
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
```
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 を削除して新しいコントロールプレーンを再起動する

必要な場合にのみ 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

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

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

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

Mesh CA への移行

制限事項

前提条件

必要なツール

移行の概要

Mesh CA ルート オブ トラストを配布する

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

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

移行を完了させる

移行

アップグレード

移行

アップグレード

ロールバック

Mesh CA に移行する

Mesh CA を有効にした新しいコントロール プレーンをインストールする

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

移行を完了させる

ロールバック

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

Mesh CA ルートオブトラストを配布する

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

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

Mesh CA を有効にした新しいコントロールプレーンをインストールする

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

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