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

  1. 次の Google Cloud APIs を有効にします。

    • container.googleapis.com
    • meshca.googleapis.com
    • meshconfig.googleapis.com
    • gkehub.googleapis.com
    • stackdriver.googleapis.com
  2. GKE クラスタ用の Workload Identity と Stackdriver を有効にします。

  3. クラスタにラベルを付けて Service ユーザー インターフェースを有効にします。

  4. Kubernetes クラスタに対するクラスタ管理者権限を取得します。

  5. クラスタをフリートに登録します。

  6. フリートで servicemesh 機能を有効にします。

環境の設定

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

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

    Cloud Shell をアクティブにする

    Google Cloud コンソールの下部で Cloud Shell セッションが開き、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

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

    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
    
  3. WORKDIR フォルダを作成します。

    mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`
    
  4. このガイドの KUBECONFIG ファイルを作成します。

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
    
  5. GKE クラスタに接続します。

    ゾーンクラスタ

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

    リージョン クラスタ

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
       --region ${CLUSTER_LOCATION}
    
  6. 移行スクリプトをダウンロードします。

    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 に移行するには、次の手順を行う必要があります。

  1. 移行前の手順を行い、Anthos Service Mesh に移行するクラスタと環境を検証して準備します。
  2. 既存の Istio コントロール プレーンと並行して、Anthos Service Mesh をカナリア コントロール プレーンとしてインストールし、ワークロードを準備します。
  3. Anthos Service Mesh でワークロードをテストし、Anthos Service Mesh サイドカー インジェクション用に Namespace のラベルを再設定します。
  4. Anthos Service Mesh ダッシュボードにアクセスして検査します。
  5. 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 内のワークロードを再起動します。

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

  1. 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!
    
  2. すべての 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)
    
  3. 再起動後、アプリケーションが正常に動作していることを確認します。

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

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

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

    Anthos Service Mesh に移動する

  2. 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} で定義されます。この変数にクラスタのコンテキストを設定できます。

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

    # 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
    
  2. 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
    
  3. クラスタが 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
    
  4. クラスタに接続します。

    ゾーンクラスタ

    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 をデプロイします。

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

    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -
    
  2. 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
    
  3. 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 に同じ処理を行います。

  1. 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
    
  2. すべての 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
    
  3. 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
    
  4. いずれかの 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"
    
  5. istio-ingressgateway Service IP アドレスの IP アドレスに移動して、アプリケーションにアクセスします。

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

次のステップ