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

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

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

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

始める前に

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

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

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

認証局

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

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

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

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

  2. 必要に応じて、Ingress ゲートウェイをインストールまたはアップグレードします。

  3. 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 を構成します。

オンプレミス

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

    kubectl config use-context CLUSTER_NAME

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

    ./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 を使用します。アップグレード中に認証局を変更すると、ダウンタイムが発生します。

オンプレミス

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

     kubectl config use-context CLUSTER_NAME

  2. 次のコマンドを実行して、デフォルトの機能と 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: オーバーレイ ファイルの名前を指定します。

オンプレミス

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

    kubectl config use-context CLUSTER_NAME

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

    ./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: オーバーレイ ファイルの名前を指定します。

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

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

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

  1. 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 です。

  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. Pod が新しいバージョンの istiod を指すように構成されていることを確認します。

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

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

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

  7. アプリケーションが想定どおりに動作していることを確認したら、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 と一致するように変更してください。ゲートウェイのインストールとアップグレード ガイドのインプレース アップグレードの手順を行います。