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

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

利用可能なバージョン

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

このページでは、スクリプトを実行して同じ Google Cloud プロジェクト内にある 1 つ以上のクラスタを含むメッシュの GKE クラスタ上で、1.8 or a 1.9 patch release から Anthos Service Mesh 1.9.8 にアップグレードする方法について説明します。

Anthos Service Mesh インストール 1.7 以降は、バージョンスキップアップグレードをサポートしています。1.10 に直接アップグレードするには、Anthos Service Mesh の最新バージョンへのアップグレードをご覧ください。

クラスタが異なるプロジェクトにある場合にアップグレードするには、GKE マルチプロジェクトガイドをご覧ください。

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

始める前に

アップグレードを開始する前に、次のことが完了していることを確認してださい。

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

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

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

スクリプトは、リビジョンアップグレードプロセス（Istio ドキュメントでは「カナリア」アップグレード）に沿って実行されます。リビジョンベースのアップグレードでは、スクリプトは既存のコントロールプレーンを残しながら、コントロールプレーンの新しいリビジョンをインストールします。新しいバージョンをインストールすると、新しいコントロールプレーンを識別する revision ラベルがスクリプトに追加されます。

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

Anthos Service Mesh のアップグレード

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

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

イネーブルメントフラグを使用したスクリプトを実行する必要があるというエラーメッセージが表示された場合は、次の選択肢があります。

スクリプトを実行して実際のインストールを行うときに、エラーメッセージからの特定のフラグまたは --enable_all フラグを含めます（この場合、--only_validate は含めません）。
必要に応じて、GKE に Anthos Service Mesh をインストールするための設定で説明されているように、スクリプトを実行する前に、プロジェクトとクラスタを自分で更新できます。

なお、install_asm では、--only_validate が指定されたイネーブルメントフラグは使用できません。

アップグレード

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

./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --option revisioned-istio-ingressgateway \
  --enable_all

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

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

YAML ファイルで複数の CR を指定した場合、install_asm は、ファイルを CR ごとに一時的な 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 \
  --option revisioned-istio-ingressgateway \
  --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 revisioned-istio-ingressgateway \
  --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.9-asm asm

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

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

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

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

また、スクリプトによって、リビジョンされた istio-ingressgateway Deployment も作成されます。これにより、新しいバージョンに切り替えるタイミングを管理できます。

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-198-6
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-198-6
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-186-8
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-186-8
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-198-6
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-198-6
```
1. istio-ingressgateway の古いバージョンと新しいバージョンの両方があることを確認します。
  - アップグレード時に revisioned-istio-ingressgateway オプションを含めた場合は、istio-ingressgateway のカナリアアップグレードは完了です。この場合、出力には istio-ingressgateway の古いバージョンと新しいバージョンの両方が含まれます。
  - アップグレード時に revisioned-istio-ingressgateway を含めなかった場合、istio-ingressgateway のインプレースアップグレードが行われています。この場合、出力には新しいバージョンのみが含まれます。
2. 出力の REV 列にある、新しいバージョンのリビジョンラベルの値をメモします。この例での値は asm-198-6 です。
3. 古い istiod バージョンのリビジョンラベルの値もメモしてください。これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンの istiod を削除するために必要です。この出力例では、古いバージョンのリビジョンラベルの値は asm-186-8 です。
istio-ingressgateway の古いバージョンと新しいバージョンの両方がある場合は、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
リビジョンラベルを名前空間に追加し、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 の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。
次のコマンドをもう一度実行して、istio-ingressgateway の古いバージョンと新しいバージョンの両方が存在するか、新しいバージョンのみであることを確認します。これにより、istio-ingressgateway の新しいバージョンへの移行または古いバージョンへのロールバックの処理方法が決まります。
```
kubectl get pod -n istio-system -L istio.io/rev
```
注意: istio-ingressgateway の新しいバージョンのみがある場合は、istio-ingressgateway Deployment を削除するコマンドを実行しないでください。これにより、トラフィックがサービスメッシュに入るのを防ぐことができます。
移行を完了させる
アプリケーションが想定どおりに動作していることを確認したら、古いコントロールプレーンを削除して新しいバージョンへの移行を完了します。
1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。
2. 新しいコントロールプレーンを使用するように検証 Webhook を構成します。
```
kubectl apply -f asm/istio/istiod-service.yaml
```
3. istio-ingressgateway の古いバージョンと新しいバージョンの両方がある場合は、古い 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
4. 古いバージョンの istiod を削除します。使用するコマンドは、Istio から移行するか、以前のバージョンの Anthos Service Mesh からアップグレードするかによって異なります。
  移行
  Istio から移行した場合、古い istiod にはリビジョンラベルがありません。
  
  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
5. 古いバージョンの IstioOperator 構成を削除します。
```
kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
```
  想定される出力は次のようになります。
```
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
```
ロールバック
新しいバージョンの istiod でアプリケーションをテストしたときに問題が発生した場合、以前のバージョンにロールバックする手順は次のとおりです。
1. istio-ingressgateway を古いバージョンに戻します。使用するコマンドは、istio-ingressgateway の古いバージョンと新しいバージョンの両方が存在するのか、新しいバージョンのみが存在するのかによって異なります。
  - 古いバージョンと新しいバージョンの istio-ingressgateway がある場合は、kubectl patch service コマンドを実行し、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"}]'
  - 新しいバージョンの istio-ingressgateway のみが存在する場合は、kubectl rollout undo コマンドを実行します。
    
    kubectl -n istio-system rollout undo deploy istio-ingressgateway
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 の古いバージョンと新しいバージョンの両方がある場合は、新しい 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 コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービスコントローラの有効化と無効化をご覧ください。

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

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

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

Google Cloud コンソールで、[Anthos Service Mesh] に移動します。

Anthos の [サービスメッシュ] に移動する
メニューバーのプルダウンリストから Google Cloud プロジェクトを選択します。
複数のサービスメッシュがある場合は、[サービスメッシュ] プルダウンリストからメッシュを選択します。

詳細については、Google Cloud コンソールでの Anthos Service Mesh の確認をご覧ください。

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

指標を表示するには:

Google Cloud コンソールで、[Monitoring] ページに移動します。

[Monitoring] に移動
[リソース] > [Metrics Explorer] を選択します。

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

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

始める前に

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

Anthos Service Mesh のアップグレード

例

検証のみ

アップグレード

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

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

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

移行を完了させる

移行

アップグレード

移行

アップグレード

ロールバック

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

次のステップ

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