Anthos Service Mesh の最新バージョンへのアップグレード

このページでは、同じ Cloud プロジェクト内に存在する 1 つ以上のクラスタを含むメッシュ用の GKE クラスタでスクリプトを実行して Anthos Service Mesh を 1.7.3+ or a 1.8 patch release から 1.8.2 バージョンへ移行する方法を説明します。

このページは Anthos Service Mesh のアップグレードを目的としています。Istio から新規のインストールと移行を目的としてスクリプトを実行する方法については、以下をご覧ください。

• Anthos Service Mesh のインストール
• Istio からの移行

始める前に

アップグレードを開始する前に、次の点をご確認ください。

• 要件を確認した
• クラスタを登録した
• 必要なツールをインストールした
• スクリプトをダウンロードした

このスクリプトを使用するには、必要な権限が付与されているか、スクリプトが権限を有効にできるように --enable_all フラグまたは --enable_gcp_iam_roles フラグを追加する必要があります。同様に、スクリプトで必要な API を有効にしてクラスタを更新できるようにするには、--enable_all フラグを指定するか、より詳細な有効化フラグを指定します。

アップグレードの準備を行う

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

注意: オーバーレイ ファイルを省略すると、正常にインストールされます。ただし、Anthos Service Mesh が再デプロイされると、省略した値がデフォルト値にリセットされるため、サービス メッシュは意図したものと異なる構成になります。Anthos Service Mesh にアップグレードする場合は、同じ構成を使用する必要があります。

このスクリプトはリビジョン アップグレード プロセスに従います（Istio ドキュメントでは「カナリア」アップグレードと呼ばれます）。リビジョン アップグレードを使用すると、既存のコントロール プレーンとともに新しいバージョンのコントロール プレーン（istiod）がインストールされます。バージョンのインストール時に、このスクリプトに新しいコントロール プレーンのバージョンを識別する revision ラベルが含められます。各リビジョンは、独自の Deployment と Service を持つ完全なコントロール プレーンの実装です。

新しいコントロール プレーンを参照するようにワークロードに同じ revision ラベルを設定し、ローリング再起動を行い、新しい Anthos Service Mesh バージョンでプロキシを再挿入して新しいバージョンに移行します。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後に、すべてのトラフィックを新しいバージョンに移行できます。これは、インプレース アップグレードを行うよりもはるかに安全です。インプレース アップグレードでは、以前のバージョンのコントロール プレーンが新しいコントロール プレーンで瞬時に置き換わります。

重要: Ingress ゲートウェイはインプレースでアップグレードされます。Ingress ゲートウェイ経由のトラフィックは中断されるため、この点を考慮する必要があります。Blue / Green デプロイのロードバランサまたはルーターを設定していない場合を除いて、ステージング環境での移行と Pod の再起動をテストして、サービスがトラフィックの中断に対処できることをおすすめします。

Anthos Service Mesh の更新

1. オプションを設定し、スクリプトを実行するフラグを指定します。常に project_id、cluster_name、cluster_location、mode のオプションを含めます。

   次のセクションでは、スクリプトを実行するための一般的な例について説明します。例の一覧については、右側のナビゲーション バーをご覧ください。スクリプトの引数の詳細については、オプションとフラグをご覧ください。

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

例

このセクションでは、アップグレードのスクリプトの実行例と、その他の有用な引数をいくつか紹介します。例の一覧については、右側のナビゲーション バーをご覧ください。

検証のみ

次の例は、--only_validate オプションを使用してスクリプトを実行する方法を示しています。このオプションを使用すると、プロジェクトやクラスタは変更されず、Anthos Service Mesh はインストールされません。--only_validate を指定した場合、--enable_* フラグのいずれかがあると、スクリプトは失敗します。

スクリプトは以下を検証します。

• 環境に必要なツールがある。
• 指定されたプロジェクトに対する必要な権限がある。
• クラスタが最小要件を満たしている。
• プロジェクトで必要な Google API がすべて有効になっている。

デフォルトでは、このスクリプトでインストール ファイルをダウンロードして抽出し、GitHub から asm 構成パッケージを一時ディレクトリにダウンロードします。終了する前に、このスクリプトで一時ディレクトリの名前を指定するメッセージが出力されます。--output_dir DIR_PATH オプションを使用して、ダウンロード用の既存のディレクトリを指定できます。--output_dir オプションを使用すると、必要に応じて istioctl コマンドライン ツールを使用できます。また、オプションの機能を有効にする構成ファイルが asm/istio/options ディレクトリにあります。

次のコマンドを実行して構成を検証し、インストール ファイルと asm パッケージを OUTPUT_DIR ディレクトリにダウンロードします。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --output_dir DIR_PATH \
  --only_validate

成功すると、以下が出力されます。

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

いずれかのテストで検証が失敗した場合、エラー メッセージが出力されます。たとえば、プロジェクトで必要な Google API のすべてが有効になっていない場合は、次のエラーが表示されます。

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

有効化フラグを使用してスクリプトを実行する必要があるというエラー メッセージが表示された場合は、--only_validate を使用せずにスクリプトを実行する際に、エラー メッセージまたは --enable_all フラグから特定のフラグを追加できます。必要に応じて、スクリプトを実行する前に、プロジェクトとクラスタをご自分で更新することもできます。詳細については、マルチ プロジェクト インストール ガイドのプロジェクトの設定とクラスタの設定のセクションをご覧ください。

アップグレード

次のコマンドは、スクリプトを実行してアップグレードします。別の CA に変更できないため、ca オプションを含める必要はありません。

注意: 以前のインストールをカスタマイズした場合は、--custom_overlay オプションを使用して IstioOperator 構成ファイルを指定する必要があります。構成ファイルを省略すると、Anthos Service Mesh がリセットされてデフォルト値に戻ります。

./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all

オーバーレイ ファイルを使用したアップグレード

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

YAML ファイルで複数の CR を指定した場合、install_asm は、ファイルを CR ごとに 1 つずつの一時的な YAML ファイルに分割します。istioctl install は複数の CR を含む YAML ファイルの最初の CR のみを適用するため、このスクリプトは CR を別個のファイルに分割します。

次の例では、アップグレードを行い、オーバーレイ ファイルを含めてコントロール プレーンの構成をカスタマイズします。次のコマンドでは、OVERLAY_FILE を YAML ファイルの名前に変更します。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

オプションを使用したアップグレード

次の例では、アップグレードを行い、anthos-service-mesh パッケージの egressgateways.yaml ファイルを含めて、Egress ゲートウェイを有効にします。.yaml 拡張子は含めないように注意してください。スクリプトによってファイルが取得されるため、最初に asm パッケージをダウンロードする必要はありません。

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --option egressgateways

--option を使用すると、オプション機能を有効にできます。asm パッケージの asm/istio/options ディレクトリにあるファイルのいずれかを変更する必要がある場合は、asm パッケージをダウンロードして変更し、--custom_overlay を使用してファイルを含めます。

asm パッケージを現在の作業ディレクトリにダウンロードしてファイルを変更するには:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm

--output_dir オプションを指定した検証のみの例を実行した場合、構成ファイルは asm/istio/options の下の指定した出力ディレクトリにあります。

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

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

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

自動挿入の有効化

自動挿入を有効にする手順は次のとおりです。

1. kubectl の現在のコンテキストを設定します。

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID
   

   注: デフォルトのゾーンやリージョンが設定されていない場合は、コマンドでリージョン（--region=REGION）やゾーン（--zone=ZONE）を指定する必要があります。

2. 次のコマンドを使用して、istiod のリビジョンラベルを探します。

   kubectl -n istio-system get pods -l app=istiod --show-labels
   

   このコマンドからの出力は、次のようになります。 移行による出力は、アップグレードとは少し異なります。次の出力例は、移行によるものです。

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
   istiod-asm-182-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-182-2,istio=istiod,pod-template-hash=85d86774f7
   istiod-asm-182-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-182-2,istio=istiod,pod-template-hash=85d86774f7

   1. 出力の LABELS 列の下で、接頭辞 istio.io/rev= に続く、新しいバージョンの istiod リビジョン ラベルの値をメモします。この例での値は asm-182-2 です。

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

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 ラベルの削除が含まれています。

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

   kubectl rollout restart deployment -n NAMESPACE

5. Pod が新しいバージョンの istiod を指すように構成されていることを確認します。

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

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

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

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

   移行を完了させる

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

   1. 古いバージョンの istiod を削除します。次のコマンドの OLD_REVISION は、以前のバージョンの istiod のリビジョン ラベルに置き換えます。

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

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

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

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

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

   ロールバック

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

   1. 以前のバージョンの istiod で自動挿入を有効にする場合は、Namespace に再びラベルを付けます。使用するコマンドは、リビジョン ラベルと以前のバージョンの 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. Namespace のリビジョン ラベルが、以前のバージョンの istiod のリビジョン ラベルと一致していることを確認します。

      kubectl get ns NAMESPACE --show-labels
      

   3. プロキシが以前のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

      kubectl rollout restart deployment -n NAMESPACE
      

   4. 以前のバージョンの istio-ingressgateway を再デプロイします。

      kubectl -n istio-system rollout undo deploy istio-ingressgateway
      

      成功時に想定される出力:

      deployment.apps/istio-ingressgateway rolled back

   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
      

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

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

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

Anthos Service Mesh ダッシュボードの表示

サイドカー プロキシが挿入されたクラスタにワークロードをデプロイすると、Cloud Console の Anthos Service Mesh ページで、Anthos Service Mesh が提供するすべてのオブザーバビリティ機能を確認できます。ワークロードをデプロイした後、Cloud Console にテレメトリー データが表示されるまでに 1～2 分ほどかかることがあります。

Cloud Console での Anthos サービス メッシュへのアクセスは、Identity and Access Management（IAM）によって制御されます。Anthos Service Mesh ページにアクセスするには、プロジェクト オーナーがユーザーに対して、プロジェクト編集者または閲覧者のロール、または、より限定的なロール（Cloud Console での Anthos Service Mesh へのアクセスの制御を参照）を付与する必要があります。

1. Google Cloud Console で、[Anthos Service Mesh] に移動します。

   Anthos Service Mesh に移動する

2. メニューバーのプルダウン リストから Cloud プロジェクトを選択します。

3. 複数のサービス メッシュがある場合は、[サービス メッシュ] プルダウン リストからメッシュを選択します。

詳細については、Cloud Console での Anthos Service Mesh の確認をご覧ください。

Anthos Service Mesh ページに加えて、サービスに関連する指標（特定のサービスで受信したリクエストの数など）が Cloud Monitoring に送信され、Metrics Explorer に表示されます。

指標を表示するには:

1. Google Cloud Console で、[Monitoring] ページに移動します。

   [モニタリング] に移動

2. [リソース] > [Metrics Explorer] を選択します。

指標の完全なリストについては、Cloud Monitoring のドキュメントの Istio 指標をご覧ください。

次のステップ

• Online Boutique サンプル アプリケーションをデプロイする
• Anthos Service Mesh にクラスタを追加する