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

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

利用可能なバージョン

Anthos Service Mesh をアップグレードする

このページでは、次の作業の方法を説明します。

asmcli を実行して Anthos Service Mesh またはオープンソースの Istio 1.9 or a 1.10 patch release から Anthos Service Mesh 1.10.6 にアップグレードします。これより前のバージョンからのアップグレードはサポートされていません。
カナリアアップグレードを実行して、ワークロードを新しいコントロールプレーンに移行します。

始める前に

始める前に、次のことを行ってください。

前提条件を確認する。現在 asmcli は、asmcli を使用して最初に Anthos Service Mesh をインストールしない限り、異なるプロジェクトのマルチクラスタメッシュにある GKE クラスタでの Anthos Service Mesh のアップグレードをサポートしていません。
アップグレードの計画を確認する
必要なツールをインストールする
asmcli をダウンロードする
クラスタ管理者の権限を付与する
プロジェクトとクラスタを検証する

コントロールプレーンのカスタマイズ

以前のインストールをカスタマイズした場合は、Anthos Service Mesh バージョンにアップグレードするか、Istio から移行する際に、同じカスタマイズを行う必要があります。--set values フラグを istioctl install に追加してインストールをカスタマイズした場合は、それらの設定をオーバーレイファイルと呼ばれる IstioOperator YAML ファイルに追加する必要があります。オーバーレイファイルを指定するには、スクリプトの実行時にファイル名で --custom_overlay オプションを使用します。このスクリプトは、オーバーレイファイルを istioctl install に渡します。

認証局

アップグレード中に認証局（CA）が変更されると、ダウンタイムが発生します。アップグレード中は、すべてのワークロードが新しい CA で新しいコントロールプレーンを使用するように切り替わるまで、mTLS トラフィックが中断されます。

Anthos Service Mesh をアップグレードする

Anthos Service Mesh のアップグレード方法の概要は次のとおりです。

asmcli install を実行して、単一クラスタに Anthos Service Mesh をインストールします。コマンドラインの例については、以降のセクションをご覧ください。これらの例には、必須の引数とオプション引数の両方が含まれています。サンプルのゲートウェイやツール（istioctl など）を簡単に見つけられるように、必ず output_dir 引数を指定することをおすすめします。例の一覧については、右側のナビゲーションバーをご覧ください。
必要に応じて、Ingress ゲートウェイをインストールまたはアップグレードします。
Anthos Service Mesh の設定を完了するには、自動サイドカーインジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。

デフォルトの機能と Mesh CA を使用してアップグレードする

このセクションでは、asmcli を実行して、プラットフォームのデフォルトのサポート機能を使用して Anthos Service Mesh をアップグレードし、認証局として Anthos Service Mesh 認証局（Mesh CA）を有効にする方法について説明します。

GKE

次のコマンドを実行して、デフォルト機能を備えた新しいコントロールプレーンをインストールします。プレースホルダに値を入力します。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

--project_id、--cluster_name、--cluster_location: クラスタが属するプロジェクト ID、クラスタ名、クラスタゾーンまたはリージョンを指定します。
--fleet_id: フリートホストプロジェクトのプロジェクト ID。このオプションを指定しない場合、asmcli は、クラスタ登録時にクラスタが作成されたプロジェクトを使用します。
--output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストールファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
--enable_all: スクリプトが次の処理を行います。
- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する（まだ登録されていない場合）。
--ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli はフリート Workload Identity を使用するように Mesh CA を構成します。

オンプレミス

現在のコンテキストをユーザークラスタに設定します。
```
kubectl config use-context CLUSTER_NAME
```
次のコマンドを実行して、デフォルト機能を備えた新しいコントロールプレーンをインストールします。プレースホルダに値を入力します。
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
```
- --fleet_id: フリートホストプロジェクトのプロジェクト ID。
- --kubeconfig: kubeconfig ファイルのパス。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
- --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストールファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
- --platform multicloud: オンプレミスがプラットフォームであることを指定します。
- --enable_all: スクリプトが次の処理を行います。
  - 必要な IAM 権限を付与する。
  - 必要な Google API を有効にする。
  - メッシュを識別するラベルをクラスタに設定する。
  - クラスタを登録する（まだ登録されていない場合）。
- --ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli は、フリート Workload Identity を使用するように Mesh CA を構成します。

Istio CA を使用するデフォルト機能をアップグレードする

このセクションでは、asmcli を実行して、プラットフォームのデフォルトのサポート機能を使用して Anthos Service Mesh をアップグレードし、Istio CA を有効にする方法について説明します。

GKE

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

--project_id、--cluster_name、--cluster_location: クラスタが属するプロジェクト ID、クラスタ名、クラスタゾーンまたはリージョンを指定します。
--fleet_id: フリートホストプロジェクトのプロジェクト ID。このオプションを指定しない場合、asmcli は、クラスタ登録時にクラスタが作成されたプロジェクトを使用します。
--output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストールファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
--enable_all: スクリプトが次の処理を行います。
- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する（まだ登録されていない場合）。
-ca citadel: Istio CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。

オンプレミス

現在のコンテキストをユーザークラスタに設定します。
```
 kubectl config use-context CLUSTER_NAME
```
次のコマンドを実行して、デフォルトの機能と Istio CA を使用する Anthos Service Mesh をインストールします。
```
 ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --output_dir DIR_PATH \
   --platform multicloud \
   --enable_all \
   --ca citadel \
```
- --fleet_id: フリートホストプロジェクトのプロジェクト ID。
- --kubeconfig: kubeconfig ファイルのパス。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
- --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストールファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
- --platform multicloud: オンプレミスがプラットフォームであることを指定します。
- --enable_all: スクリプトが次の処理を行います。
  - 必要な IAM 権限を付与する。
  - 必要な Google API を有効にする。
  - メッシュを識別するラベルをクラスタに設定する。
  - クラスタを登録する（まだ登録されていない場合）。
- -ca citadel: Istio CA を使用します。アップグレード中に認証局が変更されると、ダウンタイムが発生します。

オプション機能を使用してアップグレードする

オーバーレイファイルは IstioOperator カスタムリソース（CR）を含む YAML ファイルです。asmcli に渡してコントロールプレーンを構成します。YAML ファイルを asmcli に渡すことで、デフォルトのコントロールプレーン構成をオーバーライドし、オプション機能を有効にできます。複数のオーバーレイを重ねることができます。各オーバーレイファイルは、以前のレイヤの構成をオーバーライドします。

GKE

次のコマンドを実行して、デフォルト機能を備えた新しいコントロールプレーンをインストールします。プレースホルダに値を入力します。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

--project_id、--cluster_name、--cluster_location: クラスタが属するプロジェクト ID、クラスタ名、クラスタゾーンまたはリージョンを指定します。
--fleet_id: フリートホストプロジェクトのプロジェクト ID。このオプションを指定しない場合、asmcli は、クラスタ登録時にクラスタが作成されたプロジェクトを使用します。
--output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストールファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
--enable_all: スクリプトが次の処理を行います。
- 必要な IAM 権限を付与する。
- 必要な Google API を有効にする。
- メッシュを識別するラベルをクラスタに設定する。
- クラスタを登録する（まだ登録されていない場合）。
--ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli はフリート Workload Identity を使用するように Mesh CA を構成します。
--custom_overlay: オーバーレイファイルの名前を指定します。

オンプレミス

現在のコンテキストをユーザークラスタに設定します。
```
kubectl config use-context CLUSTER_NAME
```
次のコマンドを実行して、デフォルト機能を備えた新しいコントロールプレーンをインストールします。プレースホルダに値を入力します。
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE
```
- --fleet_id: フリートホストプロジェクトのプロジェクト ID。
- --kubeconfig: kubeconfig ファイルのパス。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
- --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストールファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
- --platform multicloud: オンプレミスがプラットフォームであることを指定します。
- --enable_all: スクリプトが次の処理を行います。
  - 必要な IAM 権限を付与する。
  - 必要な Google API を有効にする。
  - メッシュを識別するラベルをクラスタに設定する。
  - クラスタを登録する（まだ登録されていない場合）。
- --ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli はフリート Workload Identity を使用するように Mesh CA を構成します。
- --custom_overlay: オーバーレイファイルの名前を指定します。

ゲートウェイをアップグレードする

ゲートウェイをデプロイしている場合は、それもアップグレードする必要があります。簡単なアップグレード方法については、ゲートウェイのインストールとアップグレードガイドでインプレースアップグレードのセクションをご覧ください。

新しいコントロールプレーンに切り替える

istiod のにリビジョンラベルを取得します。
```
kubectl get pod -n istio-system -L istio.io/rev
```
このコマンドからの出力は、次のようになります。
```
NAME                                             READY   STATUS    RESTARTS   AGE   REV
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2
```
1. 出力の REV 列にある、新しいバージョンのリビジョンラベルの値をメモします。この例での値は asm-1106-2 です。
2. 古い istiod バージョンのリビジョンラベルの値もメモしてください。これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンの istiod を削除するために必要です。この出力例では、古いバージョンのリビジョンラベルの値は asm-198-3 です。
リビジョンラベルをアプリケーションの名前空間に追加し、istio-injection ラベル（存在する場合）を削除します。次のコマンドで、REVISION を istiod の新しいリビジョンと一致する値に変更します。
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION 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
```
アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。
アプリケーションが想定どおりに動作していることを確認したら、istiod の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。
移行を完了させる
アプリケーションが想定どおりに動作していることを確認したら、古いコントロールプレーンを削除して新しいバージョンへの移行を完了します。
1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。
2. 新しいコントロールプレーンを使用するように検証 Webhook を構成します。
  kubectl apply -f asm/istio/istiod-service.yaml
3. 古いバージョンの 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
4. 古いバージョンの IstioOperator 構成を削除します。
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  想定される出力は次のようになります。
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
ロールバック
新しいバージョンの istiod でアプリケーションをテストしたときに問題が発生した場合、以前のバージョンにロールバックする手順は次のとおりです。
1. 以前のバージョンの 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
2. 名前空間のリビジョンラベルが、以前のバージョンの istiod のリビジョンラベルと一致していることを確認します。
  kubectl get ns NAMESPACE --show-labels
3. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。
  kubectl rollout restart deployment -n NAMESPACE
4. istiod の新しいバージョンを削除します。次のコマンドの REVISION の値が正しいことを確認します。
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
5. 新しいバージョンの IstioOperator 構成を削除します。
  kubectl delete IstioOperator installed-state-REVISION -n istio-system
  予想される出力は次のようになります。
  istiooperator.install.istio.io "installed-state-REVISION" deleted
6. --disable_canonical_service フラグを含めなかった場合、スクリプトで Canonical Service コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービスコントローラの有効化と無効化をご覧ください。
7. ゲートウェイをデプロイしている場合は、名前空間またはデプロイメントのリビジョンラベルを以前のバージョンの istiod と一致するように変更してください。ゲートウェイのインストールとアップグレードガイドのインプレースアップグレードの手順を行います。

Anthos Service Mesh をアップグレードする

始める前に

コントロール プレーンのカスタマイズ

認証局

Anthos Service Mesh をアップグレードする

デフォルトの機能と Mesh CA を使用してアップグレードする

GKE

オンプレミス

Istio CA を使用するデフォルト機能をアップグレードする

GKE

オンプレミス

オプション機能を使用してアップグレードする

GKE

オンプレミス

ゲートウェイをアップグレードする

新しいコントロール プレーンに切り替える

移行を完了させる

移行

アップグレード

ロールバック

コントロールプレーンのカスタマイズ

新しいコントロールプレーンに切り替える