このドキュメントでは、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 をアクティブにする] をクリックします。
Google Cloud コンソールの下部で Cloud Shell セッションが開き、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
このガイドで使用する環境変数を作成します。
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 ページに移動します。
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
- オプション 1: カスタム
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 への移行に関するよくある質問をご覧ください。