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

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

• asmcli を実行して、Anthos Service Mesh から Anthos Service Mesh 1.12.9 にアップグレードします。

• 必要に応じて、Ingress ゲートウェイをデプロイします。

• カナリア アップグレードを実行して、ワークロードを新しいコントロール プレーンに移行します。

アップグレード可能な Anthos Service Mesh のバージョンは、プラットフォームによって異なります。

GKE

Google Kubernetes Engine の Anthos Service Mesh 1.12.9-asm.3 には、次のバージョンから直接アップグレードできます。

1.10+

オンプレミス

次のバージョンから、GKE on VMware の Anthos Service Mesh 1.12.9-asm.3 と、Google Distributed Cloud Virtual for Bare Metal に直接アップグレードできます。

1.10+

GKE on AWS

次のバージョンから、GKE on AWS の Anthos Service Mesh 1.12.9-asm.3 に直接アップグレードできます。

1.10+

Amazon EKS

EKS に Anthos Service Mesh 1.7 がインストールされている場合は、新しいクラスタに Anthos Service Mesh 1.12 をインストールする必要があります。Anthos Service Mesh 1.7 から Anthos Service Mesh 1.12 へのアップグレードは、サポートされていません。

Microsoft AKS

AKS に Anthos Service Mesh 1.7 がインストールされている場合は、新しいクラスタに Anthos Service Mesh 1.12 をインストールする必要があります。Anthos Service Mesh 1.7 から Anthos Service Mesh 1.12 へのアップグレードは、サポートされていません。

始める前に

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

• 前提条件を確認する。
• アップグレードの計画を確認する。
• 必要なツールをインストールする。
• asmcli をダウンロードする。
• クラスタ管理者の権限を付与する。
• プロジェクトとクラスタを検証する。

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

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

注意: オーバーレイ ファイルを省略すると、正常にインストールされます。ただし、コントロール プレーンと Ingress ゲートウェイが再デプロイされると、省略された値はデフォルト値に戻されるため、サービス メッシュは意図したものと異なる構成になります。

認証局

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

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

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

1. Anthos Service Mesh 認証局（Mesh CA）を使用する GKE でマルチクラスタ メッシュをアップグレードする場合は、asmcli create-mesh を実行して、フリートの Workload Identity を信頼し、アップグレード中にクラスタ間でロード バランシングが停止しないように、マルチクラスタを構成します。

2. asmcli install を実行して、単一クラスタに Anthos Service Mesh をインストールします。コマンドラインの例については、以降のセクションをご覧ください。これらの例には、必須の引数とオプション引数の両方が含まれています。サンプルのゲートウェイやツール（istioctl など）を簡単に見つけられるように、必ず output_dir 引数を指定することをおすすめします。例の一覧については、右側のナビゲーション バーをご覧ください。

3. 必要に応じて、Ingress ゲートウェイをインストールまたはアップグレードします。デフォルトでは、asmcli は istio-ingressgateway をインストールしません。コントロール プレーンとゲートウェイを個別にデプロイして管理することをおすすめします。クラスタ内コントロール プレーンにデフォルトの istio-ingressgateway をインストールする必要がある場合は、--option legacy-default-ingressgateway 引数を指定します。

4. Anthos Service Mesh の設定を完了するには、自動サイドカー インジェクションを有効にして、ワークロードをデプロイまたは再デプロイする必要があります。

フリートの Workload Identity を信頼するようにマルチクラスタ メッシュを構成する

Mesh CA を認証局として使用する GKE でマルチクラスタ メッシュをアップグレードする場合は、各クラスタをアップグレードする前に asmcli create-mesh を実行する必要があります。このコマンドは、アップグレード後にフリートの Workload Identity プール FLEET_PROJECT_ID.svc.id.goog を信頼ドメインとして使用するように Mesh CA を構成します。asmcli create-mesh コマンド:

• すべてのクラスタを同じフリートに登録します。
• フリート Workload Identity を信頼するようにメッシュを構成します。
• リモート シークレットを作成します。

各クラスタの URI または kubeconfig ファイルのパスを指定できます。

クラスタ URI

次のコマンドで、FLEET_PROJECT_ID をフリート ホスト プロジェクトのプロジェクト ID に置き換え、クラスタ URI を各クラスタのクラスタ名、ゾーンまたはリージョン、プロジェクト ID に置き換えます。

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

kubeconfig ファイル

次のコマンドで、FLEET_PROJECT_ID をフリート ホスト プロジェクトのプロジェクト ID に、PATH_TO_KUBECONFIG を各 kubeconfig へのパスに置き換えます。

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

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

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

プラットフォームに関する注意: Mesh CA は、GKE on AWS、Amazon EKS、Microsoft AKS ではサポートされていません。これらのプラットフォームで --ca mesh_ca を指定して asmcli install を実行すると、インストールに失敗します。

GKE

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

./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 はここでは機能しません。
注: この --output_dir ディレクトリをメモしておきます。ゲートウェイをデプロイするときに、これを参照する必要があります。
• --enable_all: スクリプトが次の処理を行います。
  • 必要な IAM 権限を付与する。
  • 必要な Google API を有効にする。
  • メッシュを識別するラベルをクラスタに設定する。
  • クラスタを登録する（まだ登録されていない場合）。
• --ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli はフリート Workload Identity を使用するように Mesh CA を構成します。

オンプレミス

GKE on VMware または Bare Metal 向け Google Distributed Cloud Virtual で次のコマンドを実行して、デフォルト機能と Mesh CA を備えたコントロール プレーンをアップグレードします。プレースホルダに値を入力します。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   ./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 はここでは機能しません。また、「~」を使用する kubeconfig ファイルの相対的な場所も機能しません。
   • --platform multicloud: オンプレミスがプラットフォームであることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • --ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli は、フリート Workload Identity を使用するように Mesh CA を構成します。

CA Service とデフォルト機能をアップグレードする

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

GKE

次のコマンドを実行して、デフォルト機能と Certificate Authority Service を備えたコントロール プレーンをアップグレードします。プレースホルダに値を入力します。

./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 gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

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

オンプレミス

GKE on VMware または Google Distributed Cloud Virtual for Bare Metal で次のコマンドを実行して、デフォルト機能と Certificate Authority Service を備えたコントロール プレーンをアップグレードします。プレースホルダに値を入力します。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   ./asmcli install \
    --kubeconfig KUBECONFIG_FILE \
    --fleet_id FLEET_PROJECT_ID \
    --output_dir DIR_PATH \
    --enable_all \
    --ca gcp_cas \
    --platform multicloud \
    --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

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

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

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

GKE

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

./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 はここでは機能しません。
注: この --output_dir ディレクトリをメモしておきます。ゲートウェイをデプロイするときに、これを参照する必要があります。
• --enable_all: スクリプトが次の処理を行います。
  • 必要な IAM 権限を付与する。
  • 必要な Google API を有効にする。
  • メッシュを識別するラベルをクラスタに設定する。
  • クラスタを登録する（まだ登録されていない場合）。
• -ca citadel: Istio CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。

オンプレミス

GKE on VMware または Google Distributed Cloud Virtual for Bare Metal で次のコマンドを実行して、デフォルト機能と Istio CA を備えたコントロール プレーンをアップグレードします。プレースホルダに値を入力します。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
   • --kubeconfig: kubeconfig ファイルのフルパス。環境変数 $PWD はここでは機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。また、「~」を使用する kubeconfig ファイルの相対的な場所も機能しません。
   • --platform multicloud: オンプレミスがプラットフォームであることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • -ca citadel: 認証局として Istio CA を使用します。
   • --ca_cert: 中間証明書
   • --ca_key: 中間証明書の鍵
   • --root_cert: ルート証明書
   • --cert_chain: 証明書チェーン

AWS

GKE on AWS で次のコマンドを実行して、デフォルトの機能と Istio CA を備えたコントロール プレーンをアップグレードします。プレースホルダに値を入力します。公開サブネットまたは非公開サブネットで Ingress を有効にすることもできます。

公開

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
   • --kubeconfig: kubeconfig ファイルのフルパス。環境変数 $PWD はここでは機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。また、「~」を使用する kubeconfig ファイルの相対的な場所も機能しません。
   • --platform multicloud: オンプレミスがプラットフォームであることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • -ca citadel: 認証局として Istio CA を使用します。
   • --ca_cert: 中間証明書
   • --ca_key: 中間証明書の鍵
   • --root_cert: ルート証明書
   • --cert_chain: 証明書チェーン

非公開

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. 次の YAML を istio-operator-internal-lb.yaml というファイルに保存します。

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. asmcli install を実行します。

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml
   

   • --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
   • --kubeconfig: kubeconfig ファイルのフルパス。環境変数 $PWD はここでは機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。また、「~」を使用する kubeconfig ファイルの相対的な場所も機能しません。
   • --platform multicloud: オンプレミスがプラットフォームであることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • -ca citadel: 認証局として Istio CA を使用します。
   • --ca_cert: 中間証明書
   • --ca_key: 中間証明書の鍵
   • --root_cert: ルート証明書
   • --cert_chain: 証明書チェーン

Amazon EKS

Amazon EKS で次のコマンドを実行して、デフォルトの機能と Istio CA を備えたコントロール プレーンをアップグレードします。プレースホルダに値を入力します。

プラットフォームに関する注: EKS に Anthos Service Mesh 1.7 がインストールされている場合は、新しいクラスタに Anthos Service Mesh 1.12 をインストールする必要があります。Anthos Service Mesh 1.7 から Anthos Service Mesh 1.12 へのアップグレードは、サポートされていません。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
   • --kubeconfig: kubeconfig ファイルのフルパス。環境変数 $PWD はここでは機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。また、「~」を使用する kubeconfig ファイルの相対的な場所も機能しません。
   • --platform multicloud: オンプレミスがプラットフォームであることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • -ca citadel: 認証局として Istio CA を使用します。
   • --ca_cert: 中間証明書
   • --ca_key: 中間証明書の鍵
   • --root_cert: ルート証明書
   • --cert_chain: 証明書チェーン

Microsoft AKS

Amazon EKS で次のコマンドを実行して、デフォルトの機能と Istio CA を備えたコントロール プレーンをアップグレードします。プレースホルダに値を入力します。

注: AKS に Anthos Service Mesh 1.7 がインストールされている場合は、新しいクラスタに Anthos Service Mesh 1.12 をインストールする必要があります。Anthos Service Mesh 1.7 から Anthos Service Mesh 1.12 へのアップグレードは、サポートされていません。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: フリート ホスト プロジェクトのプロジェクト ID。
   • --kubeconfig: kubeconfig ファイルのフルパス。環境変数 $PWD はここでは機能しません。
   • --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。また、「~」を使用する kubeconfig ファイルの相対的な場所も機能しません。
   • --platform multicloud: オンプレミスがプラットフォームであることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • -ca citadel: 認証局として Istio CA を使用します。
   • --ca_cert: 中間証明書
   • --ca_key: 中間証明書の鍵
   • --root_cert: ルート証明書
   • --cert_chain: 証明書チェーン

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

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

GKE

次のコマンドを実行して、オプション機能を備えたコントロール プレーンをインストールします。複数のファイルを追加するには、--custom_overlay とファイル名を指定します（例: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml）。指定されたプレースホルダに値を入力します。

./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 はここでは機能しません。
注: この --output_dir ディレクトリをメモしておきます。ゲートウェイをデプロイするときに、これを参照する必要があります。
• --enable_all: スクリプトが次の処理を行います。
  • 必要な IAM 権限を付与する。
  • 必要な Google API を有効にする。
  • メッシュを識別するラベルをクラスタに設定する。
  • クラスタを登録する（まだ登録されていない場合）。
• --ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli はフリート Workload Identity を使用するように Mesh CA を構成します。
• --custom_overlay: オーバーレイ ファイルの名前を指定します。

Google Cloud 以外

GKE on VMware、Bare Metal 向け Google Distributed Cloud Virtual、GKE on AWS、Amazon EKS、または Microsoft AKS で次のコマンドを実行します。プレースホルダに値を入力します。

プラットフォームに関する注: EKS に Anthos Service Mesh 1.7 がインストールされている場合は、新しいクラスタに Anthos Service Mesh 1.12 をインストールする必要があります。Anthos Service Mesh 1.7 から Anthos Service Mesh 1.12 へのアップグレードは、サポートされていません。

1. 現在のコンテキストをユーザー クラスタに設定します。

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install を実行します。

   ./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 はここでは機能しません。また、「~」を使用する kubeconfig ファイルの相対的な場所も機能しません。
   • --platform multicloud: オンプレミスがプラットフォームであることを指定します。
   • --enable_all: スクリプトが次の処理を行います。
     • 必要な IAM 権限を付与する。
     • 必要な Google API を有効にする。
     • メッシュを識別するラベルをクラスタに設定する。
     • クラスタを登録する（まだ登録されていない場合）。
   • --ca mesh_ca: 認証局として Mesh CA を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。asmcli はフリート Workload Identity を使用するように Mesh CA を構成します。
   • --custom_overlay: オーバーレイ ファイルの名前を指定します。

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

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

警告: asmcli 以外の方法で Anthos Service Mesh をインストールした場合、デフォルトの Ingress ゲートウェイは --option legacy-default-ingressgateway 引数で渡さない限り削除されます。

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

1. istiod のにリビジョン ラベルを取得します。

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

   このコマンドからの出力は、次のようになります。

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-1129-3-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1118-4
   istiod-asm-1129-3-67998f4b55-r76kr           1/1     Running   0          68m   asm-1118-4
   istiod-1128-2-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1129-3
   istiod-1128-2-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1129-3

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

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

2. リビジョン ラベルをアプリケーションの名前空間に追加し、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 ラベルの削除が含まれています。

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   移行を完了させる

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

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

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

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

   3. デフォルトのタグを移動します。

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

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

      移行

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

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

   アップグレード

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

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

   2. 古いリビジョンの validatingwebhookconfiguration リソースを削除します。

      kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
      

   1. 古いバージョンの 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 フラグを含めなかった場合、asmcli で Canonical Service コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービス コントローラの有効化と無効化をご覧ください。

   7. ゲートウェイをデプロイしている場合は、名前空間またはデプロイメントのリビジョン ラベルを以前のバージョンの istiod と一致するように変更してください。ゲートウェイのインストールとアップグレード ガイドのインプレース アップグレードの手順を行います。

ワークロードのデプロイと再デプロイ

自動サイドカー プロキシ インジェクション（自動インジェクション）を有効にするまで、インストール（またはアップグレード）は完了しません。OSS Istio からの移行とアップグレードは、リビジョン ベースのアップグレード プロセスに沿って進めます（Istio ドキュメントでは「カナリア アップグレード」と呼ばれます）。リビジョンベースのアップグレードでは、既存のコントロール プレーンに並ぶ形で新しいバージョンのコントロール プレーンがインストールされます。次に、一部のワークロードを新しいバージョンに移行します。これにより、すべてのトラフィックを新しいバージョンに移行する前に、ワークロードのごく一部でアップグレードの影響をモニタリングできます。

このスクリプトは、リビジョン ラベルを istio.io/rev=asm-1129-3 形式で istiod に設定します。自動挿入を有効にするには、一致するリビジョン ラベルを名前空間に追加します。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入するために名前空間内の Pod を再起動します。

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

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

   このコマンドからの出力は、次のようになります。

   NAME                                                READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk               1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz               1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb      1/1     Running   0          5s    asm-1129-3
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1129-3
   istiod-asm-1129-3-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1118-4
   istiod-asm-1129-3-67998f4b55-r76kr          1/1     Running   0          68m   asm-1118-4
   istiod-asm-1128-2-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1129-3
   istiod-asm-1128-2-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1129-3

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

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

2. リビジョン ラベルを名前空間に追加し、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 ラベルの削除が含まれています。

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   移行を完了させる

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

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

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

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

   3. デフォルトのタグを移動します。

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

   4. 古い 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
      

   5. 古いバージョンの 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
      

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

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

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

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

   ロールバック

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

   1. istio-ingressgateway を古いバージョンに戻します。次のコマンドの 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 を削除します。次のコマンドの REVISION の値が正しいことを確認します。

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

   6. istiod の新しいバージョンを削除します。次のコマンドの REVISION の値が正しいことを確認します。

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

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

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

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

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

   8. --disable_canonical_service フラグを含めなかった場合、スクリプトで Canonical Service コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービス コントローラの有効化と無効化をご覧ください。