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

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

• asmcli を実行して、Cloud Service Mesh から Cloud Service Mesh1.27.1にアップグレードする。

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

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

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

始める前に

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

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

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

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

認証局

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

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

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

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

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

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

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

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

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

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

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

./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

./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 を実行して、プラットフォームのデフォルトのサポートされている機能を使用して Cloud Service Mesh をアップグレードし、認証局として Cloud Service Mesh 認証局を有効にする方法について説明します。

./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

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

このセクションでは、asmcli を実行して、プラットフォームのデフォルトのサポート機能を使用して Cloud Service Mesh をアップグレードし、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

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

このセクションでは、asmcli を実行して、プラットフォームのデフォルトのサポート機能を使用して Cloud Service Mesh をアップグレードし、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

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

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

./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

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

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

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

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

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

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

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-1271-5-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1264-7
   istiod-asm-1271-5-67998f4b55-r76kr           1/1     Running   0          68m   asm-1264-7
   istiod-1264-7-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1271-5
   istiod-1264-7-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1271-5

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

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

2. リビジョン ラベルをアプリケーションの名前空間に追加し、istio-injection ラベル（存在する場合）を削除します。次のコマンドで、REVISION を istiod の新しいリビジョンと一致する値に変更します。

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

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

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 REVISION --overwrite
      

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

      移行

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

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

      アップグレード

      1. 以前の Cloud 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=true
         

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

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system --ignore-not-found=true
      

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

      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 --ignore-not-found=true
      

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

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

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

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

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

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

このスクリプトは、リビジョン ラベルを istio.io/rev=asm-1271-5 形式で 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-1271-5
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1271-5
   istiod-asm-1271-5-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1264-7
   istiod-asm-1271-5-67998f4b55-r76kr          1/1     Running   0          68m   asm-1264-7
   istiod-asm-1264-7-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1271-5
   istiod-asm-1264-7-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1271-5

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

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

2. istio-ingressgateway を新しいリビジョンに切り替えます。次のコマンドで、REVISION を新しいバージョンのリビジョン ラベルと一致する値に変更します。

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

   予想される出力: service/istio-ingressgateway patched

3. リビジョン ラベルを名前空間に追加し、istio-injection ラベルを削除します（ある場合）。次のコマンドで、REVISION を istiod の新しいリビジョンと一致する値に変更します。

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

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

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

7. アプリケーションが想定どおりに動作していることを確認したら、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> --overwrite
      

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

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

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

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system --ignore-not-found=true
      

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

      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. 新しい istio-ingressgateway Deployment を削除します。次のコマンドの REVISION の値が正しいことを確認します。

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

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

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

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

      kubectl delete IstioOperator installed-state-REVISION -n istio-system --ignore-not-found=true
      

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

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

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