このページは Cloud Translation API によって翻訳されました。

Istio メッシュ拡張を使用して移行をデプロイする

Last reviewed 2023-11-02 UTC

このドキュメントでは、オンプレミスのデータセンターから Google Cloud に機能を 1 つずつ移行できるようにするために、サービスメッシュを初期化して構成する方法を説明します。このドキュメントは、関連するリファレンスアーキテクチャに精通していることを前提としています。このガイドは、移行元の環境または Google Cloud にトラフィックを動的にルーティングするサービスメッシュを使用する管理者、デベロッパー、エンジニアを対象としています。

このデプロイメントガイドは、Google Cloud 以外の環境（オンプレミスや他のクラウドプロバイダ）から Google Cloud に移行できるよう支援することを目的としています。このような移行では、Google Cloud 以外の環境と Google Cloud 環境の間にセキュアな通信チャネルを設定する必要があるため、ネットワークが複雑になります。

アーキテクチャ

次の図は、サービスメッシュを使用して、移行元の環境内で稼働するマイクロサービスか Google Cloud のいずれかにトラフィックをルーティングする方法を示しています。

以前の環境内で稼働するマイクロサービスか Google Cloud のいずれかにトラフィックをルーティングするサービスメッシュを使用するアーキテクチャ。

この図では、Istio Gateway がアプリケーションのマイクロサービスをリンクするサービスメッシュを提供しています。Google Kubernetes Engine（GKE）は各マイクロサービスの境界を定義するコンテナとして機能します。詳細については、Istio メッシュ拡張を使用した移行のサポートをご覧ください。

このデプロイメントでは、次のソフトウェアを使用します。

Ubuntu Server と Container-Optimized OS: このデプロイメントで使用するオペレーティングシステム。
Docker Engine: コンテナ化されたワークロードを実行するためのプラットフォーム。
Docker Compose: Docker アプリを定義して実行する際に使用するツール。
Istio: オープンソースのサービスメッシュ。
Kiali: Istio サービスメッシュを可視化するためのツール。
Envoy: メッシュにサービスを含めるために Istio が使用するサイドカープロキシ。

サンプルワークロード

このデプロイメントで使用する Bookinfo アプリは 4 層からなる多言語で記述されたマイクロサービスアプリで、書籍情報を表示します。このアプリは Kubernetes 上で稼働するように設計されていますが、最初に Docker と Docker Compose を使用して Compute Engine インスタンス上にデプロイします。Docker Compose で、YAML 記述子を使用してマルチコンテナアプリを記述します。これにより、単一のコマンドを実行するだけでアプリを起動できます。

このサンプルワークロードはすでにコンテナ化されていますが、この手法はコンテナ化されていないサービスにも適用できます。その場合、移行を予定しているサービスをコンテナ化するには、モダナイゼーションフレーズを追加します。

Bookinfo アプリは、次の 4 つのマイクロサービスコンポーネントからなります。

productpage: 書籍情報ページにデータを取り込むために、details、ratings、reviews の各マイクロサービスを呼び出します。
details: 書籍に関する情報を提供します。
reviews: 書評を格納します。
ratings: 書評に伴う書籍ランキング情報を返します。

上記のコンポーネントの一部については、Istio とその機能を具体的な例で説明するために、Bookinfo アプリの作成者と保守担当者が複数のバージョンを実装しています。このデプロイメントでは、各コンポーネントの 1 つのバージョンのみをデプロイします。

目標

オンプレミスのデータセンターをシミュレートする環境を初期化する。
オンプレミスのデータセンターにサンプルワークロードをデプロイし、テストする。
Google Cloud で移行先の環境を構成する。
ワークロードをオンプレミスのデータセンターから移行先の環境に移行する。
移行先の環境で実行中のワークロードをテストする。
オンプレミスのデータセンターを廃止する。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

環境を準備する

このデプロイメントのほとんどの手順は、Cloud Shell で実行します。

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Cloud Shell で空き容量を確認します。
```
df -h
```
このデプロイメントを完了するには、約 200 MB の空き容量が必要です。
作業ディレクトリを ${HOME} ディレクトリに変更します。
```
cd "${HOME}"
```
サンプルワークロードをデプロイして構成するスクリプトとマニフェストファイルが含まれる Git リポジトリのクローンを作成します。
```
git clone https://github.com/GoogleCloudPlatform/solutions-istio-mesh-expansion-migration
```
アプリケーションのデフォルト認証情報（ADC）を使用して認証します。
```
gcloud auth application-default login
```
出力に Application Default Credentials ファイルのパスが表示されます。
```
Credentials saved to file:
[/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
```
Application Default Credentials ファイルのパスをメモしておきます。これらの認証情報は、ADC をリクエストするライブラリで使用されます。
環境変数を初期化します。
```
APPLICATION_DEFAULT_CREDENTIALS_PATH=APPLICATION_DEFAULT_CREDENTIALS_PATH
BILLING_ACCOUNT_ID=BILLING_ACCOUNT_ID
DEFAULT_FOLDER=DEFAULT_FOLDER
DEFAULT_PROJECT=DEFAULT_PROJECT
DEFAULT_REGION=DEFAULT_REGION
DEFAULT_ZONE=DEFAULT_ZONE
GKE_CLUSTER_NAME=istio-migration
DEPLOYMENT_DIRECTORY_PATH="$(pwd)"/solutions-istio-mesh-expansion-migration
ORGANIZATION_ID=ORGANIZATION_ID
```
次のように置き換えます。
- APPLICATION_DEFAULT_CREDENTIALS_PATH: 前のステップの ADC ファイルのパス。
- BILLING_ACCOUNT_ID: 使用する請求先アカウントの ID。
- DEFAULT_FOLDER: Google Cloud プロジェクトを作成する Google Cloud フォルダの ID。Terraform で Google Cloud 組織のすぐ下に Google Cloud プロジェクトを作成する場合は、この文字列を空のままにします。
- DEFAULT_PROJECT: このデプロイメントを完了するためにリソースをプロビジョニングする Google Cloud プロジェクトの ID。Terraform では、環境のプロビジョニング時にこのプロジェクトが作成されます。
- DEFAULT_REGION: リソースがプロビジョニングされるデフォルトのリージョン。
- DEFAULT_ZONE: リソースがプロビジョニングされるデフォルトのゾーン。
- ORGANIZATION_ID: Google Cloud 組織の ID。

環境をプロビジョニングする

このセクションでは、このデプロイメント用に次の環境をプロビジョニングします。

移行元のオンプレミスデータセンターをシミュレートする環境。
移行先をシミュレートする環境。

このデプロイメントでは、どちらの環境も Google Cloud 内で実行します。このアプローチでは、ブートストラップフェーズが 1 つしかないため、セットアッププロセスが簡単になります。Terraform を使用して、移行元の環境と移行先の環境を自動的にプロビジョニングします。

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```

Terraform バックエンドの構成を初期化します。

scripts/init.sh \
--application-credentials "${APPLICATION_DEFAULT_CREDENTIALS_PATH}" \
--billing-account-id "${BILLING_ACCOUNT_ID}" \
--default-folder "${DEFAULT_FOLDER}" \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--organization-id "${ORGANIZATION_ID}"

init.sh スクリプトは次のことを行います。

Terraform バックエンドを構成するための記述子を生成します。
Terraform 作業ディレクトリを初期化します。

作業ディレクトリを terraform ディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
```
Terraform を使用して変更を適用します。
```
terraform apply
```
プロンプトが表示されたら、提案された変更を確認して「yes」と入力します。

出力は次のようになります。
```
Apply complete! Resources: 27 added, 0 changed, 0 destroyed
```

Terraform で提案された変更を適用することで、次のタスクを自動化します。

マイクロサービス、データベース、ノード間の通信への外部アクセスが可能になるファイアウォールルールの作成。
Compute Engine インスタンスで使用するサービスアカウントの作成と有効化。サービスアカウントは、アプリの実行に必要なロールとアクセス権限のみに制限することをおすすめします。このデプロイメントでは、Compute Engine インスタンスのサービスアカウントには Compute 閲覧者のロール（roles/compute.viewer）のみが必要です。このロールでは、Compute Engine リソースへの読み取り専用アクセス権が付与されます。
移行するワークロードを移行元の環境としてホストする Compute Engine インスタンスのプロビジョニングと構成。Compute Engine インスタンスを構成するときに、Docker、Docker Compose、Dnsmasq をインストールする起動スクリプトを提供します。
ワークロードを移行先の環境としてホストする GKE クラスタのサービスアカウントの作成と有効化。このデプロイメントでは、GKE クラスタノードで使用するサービスアカウントを作成します。サービスアカウントには、アプリの実行に必要なロールとアクセス許可のみを割り当てることをおすすめします。このデプロイメントでは、GKE クラスタノードのサービスアカウントに必要なロールは次のとおりです。
- モニタリング閲覧者（roles/monitoring.viewer）
- モニタリング指標の書き込み（roles/monitoring.metricWriter）
- ログ書き込み（roles/logging.logWriter）（クラスタのセキュリティの強化を参照）
移行先の環境としてワークロードをホストするための GKE クラスタをプロビジョニングして構成します。GKE クラスタをプロビジョニングするために、Terraform では kubernetes-engine Terraform モジュールを使用します。

ワークロードを移行元の環境にデプロイする

このデプロイメントでは、移行対象のワークロードとして Istio Bookinfo App をデプロイします。次の図は、移行元の環境のアーキテクチャを示しています。

移行元の環境のターゲットアーキテクチャ。

この図では、クライアントは Compute Engine で実行されているサンプルワークロードにアクセスしています。この例では、複雑さを軽減するため、クライアントは単一の Compute Engine インスタンスに直接接続しています。本番環境では、複数のワークロードインスタンスを実行するためにロードバランシングレイヤが必要なため、このような直接接続を行う可能性はあまりありません。

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Compute Engine インスタンスにワークロードをデプロイします。
```
scripts/workloads.sh \
--deploy-with "COMPOSE" \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}"
```
workloads.sh スクリプトは次のことを行います。
- デフォルトのプロジェクト、リージョン、ゾーンを構成します。
- Docker Compose 記述子を Compute Engine インスタンスにコピーします。
- Docker Compose を使用してサンプルワークロードをデプロイします。
Compute Engine インスタンスで認証するための SSH 認証鍵ファイルをまだ作成していない場合、gcloud CLI のプロンプトが表示され、鍵ファイルの作成が求められます。

出力にデプロイの確認とアクセス方法が表示されます。出力は次のようになります。
```
You can access the workload by loading http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
```
出力で、COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP はワークロードが提供される IP アドレスです。後のステップで使用するため、IP アドレスをメモしておいてください。

移行元の環境内のデプロイメントをテストする

ブラウザを開き、以下の URL に移動します。COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP は、前のステップで確認した IP アドレスです。
```
http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
```

Bookinfo のページが開き、書籍に関する情報と書籍に関連する評価が表示されます。

Istio を構成する

このセクションでは、Google Cloud で移行先の環境を構成します。Istio をインストールして、Istio でサンプルワークロードを公開します。次の図は、移行先の環境のアーキテクチャを示しています。

Istio がインストールされている移行先の環境。

この図では、Istio は Compute Engine で実行されているワークロードを公開しています。

Istio をインストールする

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Istio をインストールします。
```
scripts/install-istio.sh \
--cluster-name "${GKE_CLUSTER_NAME}" \
--google-cloud-project "${DEFAULT_PROJECT}" \
--cluster-region "${DEFAULT_REGION}"
```
install-istio.sh スクリプトは次のことを行います。
- Istio ディストリビューションをダウンロードします。
- 移行先の環境の GKE クラスタに Istio をインストールします。
- Gateway をデプロイして、サービスメッシュ内のサービスを公開します。
- 移行元の環境をシミュレートする Compute Engine インスタンスにサービスメッシュ拡張を許可するように Istio を構成します。
- Kiali などのサービスメッシュのモニタリングツールと可視化ツールをインストールします。
このコマンドが完了すると、コンソールにインストールの確認が表示されます。出力は次のようになります。
```
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Egress gateways installed
✔ Installation complete
```

Istio メッシュ拡張を構成する

このセクションでは、移行元の環境をシミュレートする Compute Engine インスタンスをサービスメッシュに接続します。サービスメッシュは、移行先の環境に移行する以前の環境のマイクロサービスとの接続を処理します。このフェーズでは、サービスメッシュは空白であるため、サービスが登録されるのを待機します。サービスメッシュでまだ本番環境トラフィックを受信していません。

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Compute Engine インスタンスに Istio をインストールして構成します。
```
scripts/compute-engine-mesh-expansion-setup.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}"
```
compute-engine-mesh-expansion-setup.sh スクリプトは次のことを行います。
- 移行元の環境の Compute Engine インスタンスに Istio をインストールします。
- Compute Engine インスタンスで Istio サービスを開始します。

ワークロードを公開する

このセクションでは、Compute Engine インスタンスで実行され、移行元の環境をシミュレートしているワークロードを Istio サービスメッシュに登録します。

このセクションで実行する workloads.sh スクリプトは、サービスメッシュを使用して、以前の環境で実行されているサービスと移行先の環境で実行されているサービスの間で本番環境トラフィックを分割するルーティングルールを設定します。サービスメッシュ内のトラフィックルーティングはクライアントに対して透過的であるため、クライアントはルーティング構成の変更を認識しません。

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```

ワークロードを公開します。

scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--expose-with "ISTIO_COMPUTE_ENGINE"

workloads.sh スクリプトは次のことを行います。
- デフォルトのプロジェクト、リージョン、ゾーンを構成します。
- 自動サイドカーインジェクションを有効にして、デプロイ記述子が手動で編集されないようにします。
- WorkloadEntry エンドポイントと対応するサービスを構成して、Compute Engine インスタンスで実行されているワークロードをメッシュに登録します。
- ServiceEntries をデプロイして、Compute Engine メタデータサーバーと Cloud APIs へのトラフィックを許可します。
- Istio Gateway から Compute Engine インスタンスで実行されている productpage インスタンスにトラフィックをルーティングするために、仮想サービスをデプロイします。
出力にデプロイの確認とアクセス方法が表示されます。出力は次のようになります。
```
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```
出力で、ISTIO_INGRESS_GATEWAY_EXTERNAL_IP はワークロードが提供される IP アドレスです。後のステップで使用するため、IP アドレスをメモしておいてください。

Istio メッシュ拡張をテストする

このセクションでは、Istio を使用して公開した Compute Engine インスタンスで実行されているサンプルワークロードをテストします。

ブラウザを開き、以下の URL に移動します。ISTIO_INGRESS_GATEWAY_EXTERNAL_IP は、前のステップで確認した IP アドレスです。
```
http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```

この段階では、移行元の環境のエントリポイント（Compute Engine インスタンスに接続する）をまだ使用できます。本番環境を移行するときに、ロードバランシングレイヤの構成を更新して、徐々にトラフィックを移行先の環境にリダイレクトすることをおすすめします。

サービスメッシュを可視化する

このセクションでは、Kiali を使用してサービスメッシュを視覚的に表示します。

ブラウザを開き、以下の URL に移動します。ISTIO_INGRESS_GATEWAY_EXTERNAL_IP は、前のステップで確認した IP アドレスです。

http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre

Kiali サービスダッシュボードが表示されます。

Cloud Shell で、サンプルワークロードのメインページに対するリクエストを複数回実行します。
```
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"

for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
```
このリクエストにより、Bookinfo アプリへのトラフィックが生成されます。出力には、productpage サービスに対する HTTP リクエストのタイムスタンプのリストと、各リクエストの HTTP 戻りコード（この場合は 200）が表示されます。

出力は次のようになります。
```
2021-06-09T10:16:15,355323181+00:00 - 200
2021-06-09T10:16:15,355323182+00:00 - 200
2021-06-09T10:16:15,355323183+00:00 - 200
[...]
```
リクエストが完了するまでには時間がかかります。リクエストを実行したまま次のステップに進みます。
Kiali サービスダッシュボードに現在のメッシュの図が表示され、Compute Engine で実行中のサービスにルーティングされたトラフィックが示されます。すべてのトラフィックが istio-ingressgateway から compute-engine バージョンラベル付きの Compute Engine インスタンスで実行されている productpage マイクロサービス、さらに kiali サービスに転送され、サービスメッシュが可視化されます。

グラフに他のサービス（details、reviews、ratings）は表示されません。これは Compute Engine で実行される productpage マイクロサービが、Compute Engine で実行されているその他のマイクロサービスに直接接続されるためです。productpage マイクロサービスはサービスメッシュを通過しません。

すべてのトラフィックがサービスメッシュを通過する場合は、Compute Engine で実行されているワークロードをサービスメッシュに直接接続するのではなく、サービスメッシュ内のサービスを指すように再構成する必要があります。

Kiali ダッシュボードに次の図が表示されない場合は、ページを更新します。

Kiali ダッシュボードの図は、Compute Engine で実行されているサービスにトラフィックがルーティングされることを示しています。
Cloud Shell でトラフィック生成コマンドを停止するには、Control+C を押します。

ワークロードを移行する

このセクションでは、サンプルワークロードのコンポーネントを Compute Engine インスタンスから GKE クラスタに移行します。サンプルワークロードのマイクロサービスごとに、次の操作を行います。

GKE クラスタにマイクロサービスのインスタンスをデプロイします。
Compute Engine で実行中のマイクロサービスインスタンスと GKE で実行中のマイクロサービスインスタンスの両方にトラフィックのルーティングを開始します。

次の図は、このセクションで説明するシステムのアーキテクチャを示しています。

Compute Engine 内と GKE 内のマイクロサービスインスタンスにトラフィックがルーティングされるターゲットアーキテクチャ。

この図では、Cloud Load Balancing がトラフィックを Istio Gateway にルーティングし、Istio が Compute Engine で実行されているサービスまたは GKE で実行されているサービスにトラフィックをルーティングします。

サンプルワークロードのコンポーネントを移行するには、次の操作を行います。

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
ワークロードを移行先の環境にデプロイします。
```
scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--deploy-with "GKE"
```
workloads.sh スクリプトは次のことを行います。
- 自動サイドカーインジェクションを有効にして、デプロイ記述子が手動で編集されないようにします。
- ServiceAccounts と Deployment をデプロイして、GKE クラスタでサンプルワークロードを実行します。
デプロイの確認とアクセス方法が表示されます。出力は次のようになります。
```
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```

サービスメッシュは、Compute Engine インスタンスで実行されているサンプルワークロードと GKE クラスタで実行されているサンプルワークロードの両方にトラフィックをルーティングします。

Compute Engine と GKE で実行されているワークロードをテストする

このセクションでは、Compute Engine と GKE にデプロイしたサンプルワークロードをテストします。

ブラウザを開き、以下の URL に移動します。ISTIO_INGRESS_GATEWAY_EXTERNAL_IP は、前のステップで確認した IP アドレスです。
```
http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```
Bookinfo のページが開き、書籍に関する情報と書籍に関連する評価が表示されます。

Compute Engine と GKE クラスタに同じバージョンのサンプルワークロードをデプロイしたため、出力は前のテストと同じです。

サービスメッシュを可視化する

このセクションでは、Kiali を使用してサービスメッシュを視覚的に表示します。

ブラウザを開き、以下の URL に移動します。ISTIO_INGRESS_GATEWAY_EXTERNAL_IP は、前のステップで確認した IP アドレスです。

http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre

Cloud Shell で、サンプルワークロードのメインページに対するリクエストを複数回実行します。

ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done

このコマンドによって Bookinfo アプリへのトラフィックが生成されます。想定される出力は、productpage サービスへの HTTP リクエストの日付と、各リクエストの HTTP 戻りコード（この場合は 200 OK）です。出力は次のようになります。

2021-06-09T10:16:15,355323181+00:00 - 200
2021-06-09T10:16:15,355323182+00:00 - 200
2021-06-09T10:16:15,355323183+00:00 - 200
[...]

Kiali サービスダッシュボードに現在のメッシュの図が表示され、Compute Engine と GKE で実行中のサービスにルーティングされたトラフィックが示されます。

マイクロサービスの各インスタンスには、リビジョンを説明するラベルがあります。
- Compute Engine で実行されているインスタンスのラベルは compute-engine です。
- GKE で実行されているインスタンスには、v1 や v3 などの追加の文字列があります。
Compute Engine で実行されているインスタンスは、サービスメッシュを経由せずに Compute Engine の他のインスタンスに直接接続されます。そのため、Compute Engine で実行されているインスタンスから他のインスタンスへのトラフィックは表示されません。

Kiali ダッシュボードに次の図が表示されない場合は、ページを更新します。

Kiali ダッシュボードの図は、Compute Engine で実行されているサービスと GKE で実行されているサービスにルーティングされるトラフィックを示しています。
Cloud Shell でトラフィック生成コマンドを停止するには、Control+C を押します。

GKE クラスタにのみトラフィックをルーティングする

このセクションでは、GKE クラスタで実行されているワークロードサービスインスタンスにのみトラフィックをルーティングします。サンプルワークロードのサービスごとに、Compute Engine で実行されているサービスを指す WorkloadEntry 参照を削除します。削除すると、サービスは GKE クラスタで実行されているマイクロサービスインスタンスのみを選択し、トラフィックは GKE クラスタにのみルーティングされます。次の図は、このセクションで説明するシステムのアーキテクチャを示しています。

GKE クラスタにトラフィックがルーティングされるターゲットアーキテクチャ。

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
移行先の環境でのみワークロードを公開します。
```
scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--expose-with "GKE_ONLY"
```
workloads.sh スクリプトは、Compute Engine で実行されているマイクロサービスインスタンスを指す WorkloadEntry 参照を GKE クラスタから削除します。

デプロイの確認とアクセス方法が表示されます。出力は次のようになります。
```
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```

サービスエントリは、workloadSelector を使用して、GKE クラスタで実行されているサンプルワークロードを自動的に選択します。

GKE で実行されているワークロードをテストする

ブラウザを開き、以下の URL に移動します。ISTIO_INGRESS_GATEWAY_EXTERNAL_IP は、前のステップで確認した IP アドレスです。
```
http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```
Bookinfo のページが開き、書籍に関する情報と書籍に関連する評価が表示されます。

サービスメッシュを可視化する

このセクションでは、Kiali を使用してサービスメッシュを視覚的に表示します。

ブラウザを開き、以下の URL に移動します。ISTIO_INGRESS_GATEWAY_EXTERNAL_IP は、前のステップで確認した IP アドレスです。

http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre

Cloud Shell で、サンプルワークロードのメインページに対するリクエストを複数回実行します。

ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done

このコマンドによって、Bookinfo アプリへのトラフィックが生成されます。想定される出力は、productpage サービスへの HTTP リクエストの日付と、各リクエストの HTTP 戻りコード（この場合は 200 OK）です。出力は次のようになります。

2021-06-09T10:16:15,355323181+00:00 - 200
2021-06-09T10:16:15,355323182+00:00 - 200
2021-06-09T10:16:15,355323183+00:00 - 200
[...]

Kiali サービスダッシュボードに、GKE で実行されているサービスにルーティングされたトラフィックを含む現在のメッシュの図が表示されます。マイクロサービスの 2 つのインスタンスをデプロイしました。1 つは Compute Engine インスタンスで実行され、もう 1 つは GKE クラスタで実行されています。ただし、Compute Engine で実行されるマイクロサービスインスタンスを指す WorkloadEntry 参照を削除したため、サービスは GKE クラスタで実行されているマイクロサービスインスタンスのみを選択します。

Kiali ダッシュボードに次の図が表示されない場合は、ページを更新します。

Kiali ダッシュボードの図は、GKE で実行されているサービスにルーティングされるトラフィックを示しています。
Cloud Shell でトラフィック生成コマンドを停止するには、Control+C を押します。

移行元の環境を廃止する

すべてのトラフィックが GKE クラスタにルーティングされるため、Compute Engine で実行されているワークロードのインスタンスを停止できるようになりました。

本番環境の移行では、ロールバック戦略の実施に備えるために移行元のデータセンターを保持してください。移行元のデータセンターの廃止は、新しいソリューションが期待どおりに機能していること、バックアップとフォールトトレランスのメカニズムがすべて揃っていることを確認できてから開始することをおすすめします。

次の図は、このセクションで説明するシステムのアーキテクチャを示しています。

Compute Engine でワークロードインスタンスが実行されていない移行元の環境。

この図では、Istio は GKE で実行されているサービスにトラフィックをルーティングし、Compute Engine で実行されているワークロードは廃止されています。

移行元の環境を廃止する手順は次のとおりです。

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
移行先の環境でのみワークロードを公開します。
```
scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--deploy-with "GKE_ONLY"
```
workloads.sh スクリプトでは、Compute Engine インスタンスで実行されているコンテナが停止されます。

クリーンアップ

このデプロイメントで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

個々のリソースを削除する

Cloud Shell で、作業ディレクトリをリポジトリディレクトリに変更します。
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
```
プロビジョニングしたリソースを削除します。
```
terraform destroy -auto-approve
```

次のステップ

GKE について読む。
Istio について読む。
Cloud Architecture Center で、リファレンスアーキテクチャ、図、ベストプラクティスを確認する。

Istio メッシュ拡張を使用して移行をデプロイする

アーキテクチャ

サンプル ワークロード

目標

費用

環境を準備する

環境をプロビジョニングする

ワークロードを移行元の環境にデプロイする

移行元の環境内のデプロイメントをテストする

Istio を構成する

Istio をインストールする

Istio メッシュ拡張を構成する

ワークロードを公開する

Istio メッシュ拡張をテストする

サービス メッシュを可視化する

ワークロードを移行する

Compute Engine と GKE で実行されているワークロードをテストする

サービス メッシュを可視化する

GKE クラスタにのみトラフィックをルーティングする

GKE で実行されているワークロードをテストする

サービス メッシュを可視化する

移行元の環境を廃止する

クリーンアップ

プロジェクトを削除する

個々のリソースを削除する

次のステップ

サンプルワークロード

サービスメッシュを可視化する

サービスメッシュを可視化する

サービスメッシュを可視化する