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

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

目標

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

費用

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

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

環境を準備する

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

  1. 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.

  2. Cloud Shell で空き容量を確認します。

    df -h
    

    このデプロイメントを完了するには、約 200 MB の空き容量が必要です。

  3. 作業ディレクトリを ${HOME} ディレクトリに変更します。

    cd "${HOME}"
    
  4. サンプル ワークロードをデプロイして構成するスクリプトとマニフェスト ファイルが含まれる Git リポジトリのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/solutions-istio-mesh-expansion-migration
    
  5. アプリケーションのデフォルト認証情報(ADC)を使用して認証します。

    gcloud auth application-default login
    

    出力に Application Default Credentials ファイルのパスが表示されます。

    Credentials saved to file:
    [/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
    

    Application Default Credentials ファイルのパスをメモしておきます。これらの認証情報は、ADC をリクエストするライブラリで使用されます。

  6. 環境変数を初期化します。

    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 を使用して、移行元の環境と移行先の環境を自動的にプロビジョニングします。

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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 作業ディレクトリを初期化します。
  3. 作業ディレクトリを terraform ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
    
  4. Terraform を使用して変更を適用します。

    terraform apply
    
  5. プロンプトが表示されたら、提案された変更を確認して「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 クラスタノードのサービス アカウントに必要なロールは次のとおりです。
  • 移行先の環境としてワークロードをホストするための GKE クラスタをプロビジョニングして構成します。GKE クラスタをプロビジョニングするために、Terraform では kubernetes-engine Terraform モジュールを使用します。

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

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

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

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

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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 をインストールする

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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 インスタンスをサービス メッシュに接続します。サービス メッシュは、移行先の環境に移行する以前の環境のマイクロサービスとの接続を処理します。このフェーズでは、サービス メッシュは空白であるため、サービスが登録されるのを待機します。サービス メッシュでまだ本番環境トラフィックを受信していません。

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 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 スクリプトは、サービス メッシュを使用して、以前の環境で実行されているサービスと移行先の環境で実行されているサービスの間で本番環境トラフィックを分割するルーティング ルールを設定します。サービス メッシュ内のトラフィック ルーティングはクライアントに対して透過的であるため、クライアントはルーティング構成の変更を認識しません。

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. ワークロードを公開します。

    scripts/workloads.sh \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}" \
    --expose-with "ISTIO_COMPUTE_ENGINE"
    
  3. 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 を使用してサービス メッシュを視覚的に表示します。

  1. ブラウザを開き、以下の 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 サービス ダッシュボードが表示されます。

  2. 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
    [...]
    

    リクエストが完了するまでには時間がかかります。リクエストを実行したまま次のステップに進みます。

  3. Kiali サービス ダッシュボードに現在のメッシュの図が表示され、Compute Engine で実行中のサービスにルーティングされたトラフィックが示されます。すべてのトラフィックが istio-ingressgateway から compute-engine バージョン ラベル付きの Compute Engine インスタンスで実行されている productpage マイクロサービス、さらに kiali サービスに転送され、サービス メッシュが可視化されます。

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

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

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

    Kiali ダッシュボードには、トラフィックのルーティング方法が表示されます。

    Kiali ダッシュボードの図は、Compute Engine で実行されているサービスにトラフィックがルーティングされることを示しています。

  4. Cloud Shell でトラフィック生成コマンドを停止するには、Control+C を押します。

ワークロードを移行する

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

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

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

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

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

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

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. ワークロードを移行先の環境にデプロイします。

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

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

    デプロイの確認とアクセス方法が表示されます。出力は次のようになります。

    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 を使用してサービス メッシュを視覚的に表示します。

  1. ブラウザを開き、以下の 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
    
  2. 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
    [...]
    
  3. Kiali サービス ダッシュボードに現在のメッシュの図が表示され、Compute Engine と GKE で実行中のサービスにルーティングされたトラフィックが示されます。

    マイクロサービスの各インスタンスには、リビジョンを説明するラベルがあります。

    • Compute Engine で実行されているインスタンスのラベルは compute-engine です。
    • GKE で実行されているインスタンスには、v1v3 などの追加の文字列があります。

    Compute Engine で実行されているインスタンスは、サービス メッシュを経由せずに Compute Engine の他のインスタンスに直接接続されます。そのため、Compute Engine で実行されているインスタンスから他のインスタンスへのトラフィックは表示されません。

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

    Kiali ダッシュボードには、トラフィックのルーティング方法が表示されます。

    Kiali ダッシュボードの図は、Compute Engine で実行されているサービスと GKE で実行されているサービスにルーティングされるトラフィックを示しています。

  4. Cloud Shell でトラフィック生成コマンドを停止するには、Control+C を押します。

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

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

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

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 移行先の環境でのみワークロードを公開します。

    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 を使用してサービス メッシュを視覚的に表示します。

  1. ブラウザを開き、以下の 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
    
  2. 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
    [...]
    
  3. Kiali サービス ダッシュボードに、GKE で実行されているサービスにルーティングされたトラフィックを含む現在のメッシュの図が表示されます。マイクロサービスの 2 つのインスタンスをデプロイしました。1 つは Compute Engine インスタンスで実行され、もう 1 つは GKE クラスタで実行されています。ただし、Compute Engine で実行されるマイクロサービス インスタンスを指す WorkloadEntry 参照を削除したため、サービスは GKE クラスタで実行されているマイクロサービス インスタンスのみを選択します。

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

    Kiali ダッシュボードには、トラフィックのルーティング方法が表示されます。

    Kiali ダッシュボードの図は、GKE で実行されているサービスにルーティングされるトラフィックを示しています。

  4. Cloud Shell でトラフィック生成コマンドを停止するには、Control+C を押します。

移行元の環境を廃止する

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

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

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

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

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

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

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. 移行先の環境でのみワークロードを公開します。

    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 アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

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

  1. Cloud Shell で、作業ディレクトリをリポジトリ ディレクトリに変更します。

    cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
    
  2. プロビジョニングしたリソースを削除します。

    terraform destroy -auto-approve
    

次のステップ

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