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

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

利用可能なバージョン

Istio 1.7 以降から Anthos Service Mesh と Mesh CA への移行

このドキュメントでは、Google Kubernetes Engine（GKE）管理者が Anthos Service Mesh をインストールし、Istio サービスメッシュで実行中のワークロードを移行する方法について説明します。デプロイされた Anthos Service Mesh 構成には、テレメトリー用の Cloud Monitoring と、マネージド型の高可用性メッシュ証明書管理用の Anthos Service Mesh 認証局（Mesh CA）が含まれます。移行時に、ゲートウェイ、仮想サービス、メッシュトポロジを定義するその他のメッシュ構成が維持されます。

このプロセスでは、単一クラスタのインストールを行います。マルチクラスタメッシュのインストールについては、GKE でのマルチクラスタメッシュの設定をご覧ください。ここでは、Anthos Service Mesh にクラスタを追加する手順が記載されています。

このドキュメントで説明する手順を完了するには、GKE クラスタで Istio 1.7 以降を使用する必要があります。Anthos Service Mesh では、インストールまたは構成に Helm を使用できません。メッシュの構成には IstioOperator API を使用することをおすすめします。このプロセスにより、認証局の切り替え中にアプリケーションでダウンタイムが生じる可能性があります。このプロセスは、定期メンテナンスの時間枠に実施することをおすすめします。

Anthos Service Mesh は、同じ Istio API と Envoy API を使用してメッシュを構成するため、既存のリソースを変更する必要はありません。

移行後の実装上の違いは次のとおりです。

Istio コントロールプレーンは、Anthos Service Mesh コントロールプレーンに置き換わります。
Citadel 認証局が削除されます。証明書は Google Cloud Mesh CA サービスによって管理されます。
テレメトリーが Cloud Logging と Cloud Monitoring に送信されます。Google Cloud Console でダッシュボードと SLO 管理を利用できます。
IstioOperator リソースをカスタマイズしている場合は、そのリソースをスクリプトの入力として使用できます。
オープンソースの Istio インストール（バージョン 1.7 以降）は、Mesh CA により Anthos Service Mesh バージョン 1.10 に移行されます。異なるバージョンの Istio を使用している場合や、異なるバージョンの Anthos Service Mesh が必要な場合、あるいは Google が管理するコントロールプレーンを使用して Anthos Service Mesh をデプロイする場合は、Istio からの移行の準備をご覧ください。

前提条件

このガイドを完了するには、次の要件を満たす必要があります。

Istio バージョン 1.7 以降がインストールされている GKE クラスタがある。GKE クラスタがない場合や、このガイドを新しい（テスト）クラスタでテストする場合は、付録の手順に沿ってテストアプリケーションを使用して、Istio バージョン 1.7 以降がデプロイされている新しい GKE クラスタを作成してください。
このガイドの手順は Cloud Shell を使用して行います。このガイドは Cloud Shell でテストされています。

目標

このガイドでは、移行パスを選択します。ワンステップで移行するのか、段階的に移行するのかを選択できます。

詳細については、移行パスを選択するをご覧ください。

この移行に関するよくある質問への回答については、Istio 1.7 以降から Anthos Service Mesh と Mesh CA への移行に関するよくある質問をご覧ください。

始める前に

このガイドでは、Istio がインストールされている GKE クラスタの管理者権限が必要です。移行プロセス中にアプリケーションの動作を確認するには、まず、開発環境またはステージング環境のクラスタを使用して、このプロセスを実施することをおすすめします。

Anthos Service Mesh には次の要件があります。手動で実行することも、付属のツールを使用してプリインストールプロセスで依存関係を有効にすることもできます。

次の Google Cloud APIs を有効にします。
- container.googleapis.com
- meshca.googleapis.com
- meshconfig.googleapis.com
- gkehub.googleapis.com
- stackdriver.googleapis.com
GKE クラスタ用の Workload Identity と Stackdriver を有効にします。
クラスタにラベルを付けて Service ユーザーインターフェースを有効にします。
Kubernetes クラスタに対するクラスタ管理者権限を取得します。
クラスタをフリートに登録します。
フリートで servicemesh 機能を有効にします。

環境の設定

環境の設定手順は次のとおりです。

Google Cloud Console で、[Cloud Shell をアクティブにする] をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開き、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
注: このスクリプトは macOS では機能しません。このスクリプトは Cloud Shell でのみテストされています。このスクリプトを使用するには、次のアプリケーションが必要です（すべて Cloud Shell にデフォルトで含まれています）。
- gcloud（バージョン 346.0.0 以降）
- kubectl（クライアントバージョン 1.21 以降）
- jq
- sed
- curl
- awk

このガイドで使用する環境変数を作成します。

export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE

WORKDIR フォルダを作成します。

mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`

このガイドの KUBECONFIG ファイルを作成します。

touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

GKE クラスタに接続します。

ゾーンクラスタ

gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --zone ${CLUSTER_LOCATION}

リージョンクラスタ

gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --region ${CLUSTER_LOCATION}

移行スクリプトをダウンロードします。

curl -LO https://storage.googleapis.com/csm-artifacts/asm/migrate-to-asm
chmod +x ./migrate-to-asm

移行パスを選択する

Anthos Service Mesh への移行パスは 2 つあります。いずれかの方法を選択して次のセクションに進みます。

Anthos Service Mesh にワンステップで段階する。その名前のとおり、Anthos Service Mesh への移行に必要なすべての手順を 1 つのコマンドで実行します。これは、多くのクラスタが存在し、これらのクラスタを Anthos Service Mesh に迅速かつ簡単にアップグレードする必要がある場合に便利な方法です。ただし、この方法ではアプリケーションのダウンタイムが発生する可能性があります。
Anthos Service Mesh に段階的に移行する。この方法では、各手順をより細かく制御できます。Anthos Service Mesh への移行に必要なものを正確に把握できます。

Anthos Service Mesh にワンステップで移行する

このセクションでは、現在の Istio バージョン 1.7 以降を Anthos Service Mesh バージョン 1.10 に移行します。この手順では、1 つのステップで移行を完了できます。移行を段階的に行う場合は、Anthos Service Mesh に段階的に移行するをご覧ください。

Anthos Service Mesh に移行するには、次のコマンドを実行します。どのコマンドでも、--dry-run フラグを使用すると、コマンドを実際に実行せずに、結果のみを出力できます。また、--verbose フラグを使用すると、スクリプトで実行中にコマンドの結果を出力できます。始める前にで説明したように、依存関係をすでに構成している場合は、--enable-dependencies フラグを省略できます。

カスタムリソースがない場合

カスタムの IstioOperator リソースがない場合は、次のコマンドを使用します。

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --verbose

カスタムリソースがある使用

カスタムの IstioOperator リソースがある場合は、次のコマンドを使用します。

export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --custom_overlay ${ISTIO_OPERATOR_FILEPATH} \
    --verbose

このコマンドは、次の処理を実行します。

Istio のバージョンが 1.7 以降であることを確認します。
クラスタで Workload Identity を有効にします。Mesh CA には Workload Identity が必要です。既存のノードプールで GKE メタデータサーバーを有効にする必要はありません。
Anthos Service Mesh に必要な API を有効にします。
クラスタをフリートに登録します。
必要なラベルを設定してクラスタを更新します。
指定したクラスタに対して、Google が管理するコントロールプレーンのほうが適しているかどうかを評価します。
最適なコントロールプレーン構成で Anthos Service Mesh をデプロイします。
必要な Anthos Service Mesh のラベルを使用して、Istio が有効になっているすべての Namespace のラベルを再設定します。
ワークロードが新しい Anthos Service Mesh プロキシを使用できるように、Anthos Service Mesh が有効なすべての Namespace でワークロードを再起動します。
Istio コントロールプレーンを削除します。

Anthos Service Mesh に段階的に移行する

このセクションでは、Istio バージョン 1.7 以降を Anthos Service Mesh バージョン 1.10 に移行します。この移行では、一連の手順を段階的に行います。移行をワンステップで行う場合は、Anthos Service Mesh にワンステップで移行するをご覧ください。

Anthos Service Mesh に移行するには、次の手順を行う必要があります。

移行前の手順を行い、Anthos Service Mesh に移行するクラスタと環境を検証して準備します。
既存の Istio コントロールプレーンと並行して、Anthos Service Mesh をカナリアコントロールプレーンとしてインストールし、ワークロードを準備します。
Anthos Service Mesh でワークロードをテストし、Anthos Service Mesh サイドカーインジェクション用に Namespace のラベルを再設定します。
Anthos Service Mesh ダッシュボードにアクセスして検査します。
Istio アーティファクトをクリーンアップするか、既存の Istio バージョンにロールバックします。

移行前の手順を行う

移行前の手順では、次のことを行います。

プロジェクトとクラスタの情報が正しく、インストールされている Istio のバージョンが移行に対応していることを確認します。
デフォルトゲートウェイの構成と現在の Istio サービスメッシュのラベルをバックアップします。
--enable-dependencies フラグを使用すると、依存関係が自動的に有効になります。それ以外の場合は、依存関係が有効かどうか検証します。

移行前のスクリプトが現在のディレクトリに configuration_backup というフォルダを新規作成します（すでに存在する場合は上書きされます）。

移行前の手順を行うには、次のコマンドを実行します。

依存関係

依存関係を有効にします。

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies

依存関係を有効にしない場合

依存関係を有効にしない場合は、次のコマンドを実行します。

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID

出力は次のようになります。

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Confirming cluster information for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Confirming node pool requirements for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Checking existing Istio version(s)...
    migrate-to-asm:   1.9.5
    migrate-to-asm: No version issues found.
    migrate-to-asm: Enabling required APIs...
    migrate-to-asm:
    migrate-to-asm: APIs enabled.
    migrate-to-asm: Enabling the service mesh feature...
    migrate-to-asm:
    migrate-to-asm: The service mesh feature is already enabled.
    migrate-to-asm: Enabling Stackdriver on $LOCATION/$CLUSTER_NAME...
    Updating $CLUSTER_NAME...
    .........................done.
    Updated [https://container.googleapis.com/v1/projects/$PROJECT_ID/zones/$LOCATION/clusters/$CLUSTER_NAME].
    To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/$LOCATION/$CLUSTER_NAME?project=$PROJECT_ID
    migrate-to-asm:
    migrate-to-asm: Stackdriver enabled.
    migrate-to-asm: Querying for core/account...
    migrate-to-asm: Binding user@example.com to cluster admin role...
    migrate-to-asm:
    migrate-to-asm:
    migrate-to-asm: Successfully bound to cluster admin role.
    migrate-to-asm: Initializing meshconfig API...
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100     3    0     3    0     0      6      0 --:--:-- --:--:-- --:--:--     6
    migrate-to-asm:
    migrate-to-asm: Finished pre-migration!

Anthos Service Mesh をインストールしてワークロードを作成する

この手順では、次のことを行います。

configuration_backup フォルダの有無を確認します。存在しない場合は、確実に移行前のツールが正常に動作するように、処理を中断します。
これにより、クラスタとメッシュ構成の分析に基づいて、Anthos Service Mesh コントロールプレーンがインストールされ、構成されます。
カスタムの IstioOperator リソースがある場合は、それを使用します。カスタムゲートウェイまたは IstioOperator リソースを使用して構成した複数のゲートウェイがある場合は、この手順で同じリソースを使用します。

分析をスキップし、クラスタのリソースで実行されている非マネージドコントロールプレーンをツールにインストールさせるには、コマンドに --no-mcp フラグを追加します。

Anthos Service Mesh をインストールする場合、次の 3 つのパスのいずれかを選択できます。

オプション 1: カスタム IstioOperator リソースを使用しない場合。Anthos Service Mesh はカスタムリソースなしでインストールできます。このオプションを使用すると、Istio のデフォルトの構成がインストールされて、デフォルトの istio-ingressgateway が更新されます。
オプション 2: --no-gateways オプションを使用する場合。カスタム IstioOperator リソースを使用せずに Anthos Service Mesh をインストールする場合は、--no-gateways オプションを使用して、デフォルトの istio-ingressgateway を更新しないようにすることもできます。このオプションを使用した場合は、インストール後にゲートウェイを手動でアップグレードする必要があります。
オプション 3: カスタム IstioOperator リソースを使用する場合。カスタム IstioOperator リソースを使用して Anthos Service Mesh をインストールできます。カスタム IstioOperator リソースを使用して Istio をデプロイしている場合は、Anthos Service Mesh のインストール時に同じ IstioOperator リソースを使用することをおすすめします。

Anthos Service Mesh をインストールするには、次のいずれかのコマンドを実行します。

オプション 1

デフォルトの istio-ingressgateway をアップグレードします。

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

オプション 2

デフォルトの istio-ingressgateway をアップグレードしません。

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --no-gateways

オプション 3

カスタム IstioOperator リソースを使用してゲートウェイをアップグレードします。

 export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --custom-overlay ${ISTIO_OPERATOR_FILEPATH}

出力は次のようになります。

 migrate-to-asm: Checking installation tool dependencies...
 migrate-to-asm: Checking for $PROJECT_ID...
 migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
 Fetching cluster endpoint and auth data.
 kubeconfig entry generated for $CLUSTER_NAME.
 migrate-to-asm:
 migrate-to-asm: Verifying connectivity (20s)...
 migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
 migrate-to-asm: Configuring kpt package...
 asm/
 set 20 field(s) of setter "gcloud.container.cluster" to value "$CLUSTER_NAME"
 asm/
 set 28 field(s) of setter "gcloud.core.project" to value "$PROJECT_ID"
 asm/
 set 2 field(s) of setter "gcloud.project.projectNumber" to value "42"
 asm/
 set 5 field(s) of setter "gcloud.project.environProjectNumber" to value "42"
 asm/
 set 20 field(s) of setter "gcloud.compute.location" to value "$LOCATION"
 asm/
 set 1 field(s) of setter "gcloud.compute.network" to value "$PROJECT_ID-default"
 asm/
 set 6 field(s) of setter "anthos.servicemesh.rev" to value "asm-1102-2"
 asm/
 set 5 field(s) of setter "anthos.servicemesh.tag" to value "1.10.2-asm.2"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.hubTrustDomain" to value "$PROJECT_ID.svc.id.goog"
 asm/
 set 2 field(s) of setter "anthos.servicemesh.hub-idp-url" to value "https://container.googleapis.com/v1/projects/$PROJECT_ID/locations/$LOCATION/clusters/$CLUSTER_NAME"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.trustDomainAliases" to value "$PROJECT_ID.svc.id.goog"
 migrate-to-asm: Configured.
 migrate-to-asm: Installing Anthos Service Mesh control plane...
 migrate-to-asm:
 - Processing resources for Istio core.
 ✔ Istio core installed
 - Processing resources for Istiod.
 - Processing resources for Istiod. Waiting for Deployment/istio-system/istiod-asm-1102-2
 ✔ Istiod installed
 - Processing resources for CNI, Ingress gateways.
 - Processing resources for CNI, Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ CNI installed
 - Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ Ingress gateways installed
 - Pruning removed resources
 migrate-to-asm:
 migrate-to-asm:
 namespace/asm-system created
 customresourcedefinition.apiextensions.k8s.io/canonicalservices.anthos.cloud.google.com configured
 role.rbac.authorization.k8s.io/canonical-service-leader-election-role created
 clusterrole.rbac.authorization.k8s.io/canonical-service-manager-role configured
 clusterrole.rbac.authorization.k8s.io/canonical-service-metrics-reader unchanged
 serviceaccount/canonical-service-account created
 rolebinding.rbac.authorization.k8s.io/canonical-service-leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-manager-rolebinding unchanged
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-proxy-rolebinding unchanged
 service/canonical-service-controller-manager-metrics-service created
 deployment.apps/canonical-service-controller-manager created
 deployment.apps/canonical-service-controller-manager condition met
 migrate-to-asm:
 migrate-to-asm:
 migrate-to-asm: *******
 migrate-to-asm: Control plane installation complete!

ワークロードの再挿入とアプリケーションの動作確認を行う

ここまでで、Anthos Service Mesh コントロールプレーンでワークロードを処理する準備が整いましたが、既存のワークロードはまだ既存の Istio コントロールプレーンによって管理されています。これらのワークロードを移行するには、Anthos Service Mesh のリビジョンラベルを使用して、Istio 挿入用のラベルが付いている Kubernetes Namespace のラベルを再設定する必要があります。その後、これらの Namespace でワークロードを再起動する必要があります。この操作は手動で行うことも（手順 1 の注を参照）、ツールを使用してワンステップで行うこともできます。

ラベル再設定の手順は次のとおりです。

現在 Istio インジェクションラベルを使用しているすべての Namespace が検出します。
これらの Namespace のラベルを istio.io/rev=asm-1102-2 に変更します。
Namespace 内のワークロードを再起動します。

ワークロードの再挿入を行う方法は次のとおりです。

Istio が有効になっているすべての Namespace のラベルを再設定し、ワークロードを再起動するには、次のコマンドを実行します。

 ./migrate-to-asm relabel \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

出力は次のようになります。

migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for $CLUSTER_NAME.
migrate-to-asm:
migrate-to-asm: Verifying connectivity (20s)...
migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
******
migrate-to-asm: Installation of Anthos Service Mesh has completed. Migration will continue
migrate-to-asm: by relabeling and restarting workloads in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with migration? (Y/n)Y
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!

すべての Deployment が再起動したら、次のコマンドを実行してデータプレーンのバージョンを確認します。
```
istioctl version
```
出力は次のようになります。
```
client version: 1.8.0
pilot version: 1.9.5
istiod version: 1.10.2-asm.2
data plane version: 1.10.2-asm.2 (14 proxies)
```
再起動後、アプリケーションが正常に動作していることを確認します。

Anthos Service Mesh ダッシュボードにアクセスする

このセクションでは、Anthos Service Mesh ダッシュボードに移動し、すべての Service についてゴールデンシグナルを受信していることを確認します。アプリケーショントポロジの表示権限も必要です。

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

Anthos Service Mesh に移動する
Service の指標とトポロジの表示権限が必要です。

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

移行を完了する

移行を完了する前に、すべてのアプリケーションが適切に機能していることを確認してください。移行の完了後は、既存の Istio バージョンにロールバックすることはできません。移行を完了するには、次の手順を行います。

ここでは、クラスタ内で実行されているすべてのプロキシが Anthos Service Mesh を使用していることを確認します。
使用されていない Istio コンポーネントはクラスタから削除します。この手順は元に戻せません。

Anthos Service Mesh への移行を完了するには、次のコマンドを実行します。

 ./migrate-to-asm finalize \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

出力は次のようになります。

migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for asm-scriptaro-oss...
migrate-to-asm: All proxies running Anthos Service Mesh!
Remove previous control plane resources? (Y/n)
migrate-to-asm: ****
migrate-to-asm: Previous Istio control plane has been removed.

既存の Istio バージョンにロールバックする

ロールバック手順を行い、以前の Istio インジェクションラベルで Namespace にラベルを付け直し、ワークロードを再起動してゲートウェイの変更をロールバックします。その後、クラスタにデプロイされたすべての Anthos Service Mesh コンポーネントが削除されます。

移行前の手順で有効にした依存関係は、手動で元に戻す必要があります。

Istio にロールバックするには、次のコマンドを実行します。

 ./migrate-to-asm rollback \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

出力は次のようになります。

migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
******
migrate-to-asm: Rolling back migration by relabeling and restarting workloads
migrate-to-asm: in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with rollback? (Y/n)
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!
service/istio-ingressgateway configured
deployment.apps/istio-ingressgateway configured
There are still 14 proxies pointing to the control plane revision asm-1102-2
istio-ingressgateway-66c85975d-2gt8c.istio-system
istio-ingressgateway-66c85975d-jdd96.istio-system
...
frontend-685dcb78d6-9l45j.default
If you proceed with the uninstall, these proxies will become detached from any control plane and will not function correctly.

Removed HorizontalPodAutoscaler:istio-system:istio-ingressgateway.
Removed HorizontalPodAutoscaler:istio-system:istiod-asm-1102-2.
...
Removed ClusterRoleBinding::mdp-controller.
✔ Uninstall complete
namespace "asm-system" deleted
migrate-to-asm: ****
migrate-to-asm: Anthos Service Mesh has been uninstalled from the cluster.

付録

Istio がインストールされた GKE クラスタを作成する

このセクションでは、Istio を有効にした GKE クラスタをデプロイします。限定公開または一般公開 GKE クラスタを使用できます。限定公開 GKE クラスタには、一般公開の GKE エンドポイントが必要です。また、Istio のインストールも確認します。

GKE クラスタがすでに存在する場合は、作成手順をスキップし、KUBECONFIG ファイルを使用するクラスタにアクセス可能であることを確認します。このガイドで使用するコンテキストは、変数 ${CLUSTER_1_CTX} で定義されます。この変数にクラスタのコンテキストを設定できます。

このガイドで使用する環境変数を作成します。

# Enter your project ID
export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export CLUSTER_CTX=gke_${PROJECT_ID}_${CLUSTER_LOCATION}_${CLUSTER_NAME}
export ISTIO_VERSION=ISTIO_VERSION # Must be versions 1.7 through 1.10 and must be of the form major.minor.patch, for example 1.7.4 or 1.9.5

Istio を有効にした GKE クラスタを作成します（これは限定公開クラスタです）。これらの手順は、一般公開の GKE クラスタにも実行できます。

ゾーンクラスタ

gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --zone ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

リージョンクラスタ

gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --region ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

クラスタが RUNNING であることを確認します。

 gcloud container clusters list

出力は次のようになります。

NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING

クラスタに接続します。

ゾーンクラスタ

gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION}

リージョンクラスタ

gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --region ${CLUSTER_LOCATION}

最後に、KUBECONFIG 変数の設定を解除します。この作業は忘れずに行ってください。

Istio をインストールする

このセクションでは、GKE クラスタに Istio バージョン 1.7 をデプロイします。

Istio をダウンロードします。

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -

istioctl コマンドラインツールを使用して Istio をインストールします。次からいずれかのオプションを選択します。

オプション 1: カスタム IstioOperator リソースを使用しない場合
オプション 2: カスタム IstioOperator リソース使用する場合

オプション 1

カスタムの IstioOperator リソースを使用しない場合:

./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -y

出力は次のようになります。

✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

オプション 2

カスタムの IstioOperator リソースを使用する場合:

cat <<EOF > istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 name: istio-operator
spec:
 components:
   base:
     enabled: true
   ingressGateways:
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         metrics:
         - resource:
             name: cpu
             targetAverageUtilization: 80
           type: Resource
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     name: istio-ingressgateway
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     label:
       istio: istio-api-ingressgateway
     name: istio-api-ingressgateway
 meshConfig:
   defaultConfig:
     tracing:
       sampling: 1
       zipkin:
         address: jaeger-collector.observability.svc.cluster.local:9411
   enableTracing: true
EOF

./istio-${ISTIO_VERSION}/bin/istioctl install -f istio-operator.yaml -y

出力は次のようになります。

✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

Istio Services と Pod がデプロイされ、実行していることを確認します。

kubectl --context=${CLUSTER_CTX} -n istio-system get services,pods

出力は次のようになります。

オプション 1

カスタムの IstioOperator リソースを使用しない場合:

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)                                                      AGE
service/istio-ingressgateway   LoadBalancer   10.64.5.113    <pending>           15021:31285/TCP,80:31740/TCP,443:30753/TCP,15443:31246/TCP   33s
service/istiod                 ClusterIP      10.64.15.184   <none>              15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP                45s

NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-6f44d6745b-22q9h   1/1     Running   0          34s
pod/istiod-b89f5cc6-nhsrc                   1/1     Running   0          48s

オプション 2

カスタムの IstioOperator リソースを使用する場合:

NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
service/istio-api-ingressgateway   LoadBalancer   10.100.0.84    104.196.26.108   15021:32489/TCP,80:30083/TCP,443:30565/TCP,15443:30705/TCP   76s
service/istio-ingressgateway       LoadBalancer   10.100.3.221   34.139.111.125   15021:30966/TCP,80:31557/TCP,443:31016/TCP,15443:31574/TCP   75s
service/istiod                     ClusterIP      10.100.13.72   <none>           15010/TCP,15012/TCP,443/TCP,15014/TCP                        86s

NAME                                            READY   STATUS    RESTARTS   AGE
pod/istio-api-ingressgateway-79978ddc65-hslbv   1/1     Running   0          61s
pod/istio-api-ingressgateway-79978ddc65-z92w8   1/1     Running   0          77s
pod/istio-ingressgateway-fb47c4859-pkdn7        1/1     Running   0          60s
pod/istio-ingressgateway-fb47c4859-t2pfq        1/1     Running   0          77s
pod/istiod-9445656d7-fxk9j                      1/1     Running   0          89s

Online Boutique をデプロイする

このセクションでは、Online Boutique という、マイクロサービスベースのサンプルアプリケーションを GKE クラスタにデプロイします。Online Boutique は Istio 対応の Namespace にデプロイされます。アプリケーションが機能していること、Istio によってすべての Pod にサイドカープロキシが挿入されていることを確認します。

アプリケーションにすでにクラスタ存在する場合は、新しい Namespace を作成して Online Boutique のデプロイをスッキプすることもできます。Anthos Service Mesh をインストールし、ワークロードを準備するセクションで、すべての Namespace に同じ処理を行います。

Online Boutique を GKE クラスタにデプロイします。

kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_CTX} -n online-boutique apply -f online-boutique

すべての Deployment の準備が整うまで待機します。

kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

Pod ごとに、2 つのコンテナ（Istio によって Pod に自動的に挿入されるアプリケーションコンテナと Istio サイドカープロキシ）があることを確認します。

kubectl --context=${CLUSTER_CTX} -n online-boutique get pods

出力は次のようになります。

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

いずれかの Pod からサイドカーの Envoy プロキシのバージョンを確認して、Istio バージョン 1.4 の Envoy プロキシがデプロイされていることを確認することもできます。

export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

出力は次のようになります。

"docker.io/istio/proxyv2:1.7.4"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

istio-ingressgateway Service IP アドレスの IP アドレスに移動して、アプリケーションにアクセスします。

kubectl --context=${CLUSTER_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

次のステップ

この移行に関するよくある質問への回答については、Istio 1.7 以降から Anthos Service Mesh と Mesh CA への移行に関するよくある質問をご覧ください。

Istio 1.7 以降から Anthos Service Mesh と Mesh CA への移行

前提条件

目標

始める前に

環境の設定

ゾーンクラスタ

リージョン クラスタ

移行パスを選択する

Anthos Service Mesh にワンステップで移行する

カスタム リソースがない場合

カスタム リソースがある使用

Anthos Service Mesh に段階的に移行する

移行前の手順を行う

依存関係

依存関係を有効にしない場合

Anthos Service Mesh をインストールしてワークロードを作成する

オプション 1

オプション 2

オプション 3

ワークロードの再挿入とアプリケーションの動作確認を行う

Anthos Service Mesh ダッシュボードにアクセスする

移行を完了する

既存の Istio バージョンにロールバックする

付録

Istio がインストールされた GKE クラスタを作成する

ゾーンクラスタ

リージョン クラスタ

ゾーンクラスタ

リージョン クラスタ

Istio をインストールする

オプション 1

オプション 2

オプション 1

オプション 2

Online Boutique をデプロイする

次のステップ

リージョンクラスタ

カスタムリソースがない場合

カスタムリソースがある使用

リージョンクラスタ

リージョンクラスタ