Istio メッシュ拡張を使用して移行をサポートする: チュートリアル

Last reviewed 2022-09-29 UTC

このチュートリアルでは、オンプレミスのデータセンターから Google Cloud に機能を 1 つずつ移行できるようにするために、サービス メッシュを初期化して構成する方法を説明します。このチュートリアルと付随するコンセプトに関する記事は、サービス メッシュを使用して移行元の環境または Google Cloud に動的にトラフィックをルーティングする必要があるシステム管理者、開発者、エンジニアの方を対象としています。

サービス メッシュを使用すると、ネットワーク機能がサービス機能から切り離されるため、移行もリファクタリングも複雑さが大幅に軽減されます。さらに、サービス メッシュはロード バランシング、トラフィック管理、モニタリング、オブザーバビリティにも対応するため、ネットワーク運用の複雑さも軽減されます。

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

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

レガシー環境内で稼働するマイクロサービスか Google Cloud のいずれかにトラフィックをルーティングするサービス メッシュ。

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

このチュートリアルでは、次のソフトウェアを使用します。

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

目標

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

費用

このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。

始める前に

  1. Google Cloud 組織を作成するか、既存の組織を使用します。また、組織のプロジェクト作成者ロールも必要です。
  2. Google Cloud プロジェクトで課金が有効になっていることを確認します

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

環境を準備する

このチュートリアルのほとんどの手順は、Cloud Shell で実行します。

  1. Cloud Shell を開きます。

    Cloud Shell を開く

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

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

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

      gcloud auth application-default login
    

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

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

    これらの認証情報は、ADC をリクエストするライブラリで使用されます。

    Application Default Credentials ファイルのパスをメモしておきます。

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

    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
    TUTORIAL_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。

サンプル ワークロード

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

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

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

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

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

このセクションでは、このチュートリアル用に次の環境をプロビジョニングします。

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

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

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

    cd "${TUTORIAL_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 "${TUTORIAL_DIRECTORY_PATH}"/terraform
    
  4. Terraform を使用して変更を適用します。

    terraform apply
    

    プロンプトが表示されたら、提案された変更を審査し、「yes」と入力して確認します。

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

    Apply complete! Resources: 27 added, 0 changed, 0 destroyed
    

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

  • マイクロサービス、データベース、ノード間の通信への外部アクセスが可能になるファイアウォール ルールの作成
  • Compute Engine インスタンスのサービス アカウントの作成と有効化。このチュートリアルでは、使用する 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 "${TUTORIAL_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 を使用してサンプル ワークロードをデプロイします。

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

    You can access the workload by loading http://[COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP]:9080/productpage
    

    IP アドレス COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_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 "${TUTORIAL_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 "${TUTORIAL_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 サービス メッシュに登録します。

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

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

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

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

    • デフォルトのプロジェクト、リージョン、ゾーンを構成します。
    • 自動サイドカー インジェクションを有効にして、デプロイ記述子を手動で編集しないようにします。
    • WorkloadEntries エンドポイントと対応するサービスを構成して、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
      

      IP アドレス ISTIO_INGRESS_GATEWAY_EXTERNAL_IP は後のステップで使用するため、メモしておきます。

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

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

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

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

    次の図に示すように、ページには書籍に関する情報と、関連する評価が表示されます。

    Istio メッシュ拡張テストの後に表示される書籍と評価のページ。

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

このセクションでは、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 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 で実行中のサービスにルーティングされたトラフィックが示されます。すべてのトラフィックが istio-ingressgateway から、compute-engine バージョン ラベル付きの Compute Engine インスタンスで実行されている productpage マイクロサービス、kiali サービスにルーティングされ、サービス メッシュを可視化します。

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

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

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

    Kiali ダッシュボード ページ。

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

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

ワークロードを移行する

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

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

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

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

上の図に示すように、Cloud Load Balancing はトラフィックを Istio ゲートウェイにルーティングし、Istio は Compute Engine で実行されているサービスまたは GKE で実行されているサービスにトラフィックをルーティングします。

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

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

    cd "${TUTORIAL_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 にデプロイしたサンプル ワークロードをテストした後の書籍と評価のページ

    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 で実行されているインスタンスから他のインスタンスへのトラフィックは表示されません。

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

    トラフィックは、Compute Engine で実行されているサービスと GKE で実行されているサービスでほぼ均等に分割されます。サービスは、GKE クラスタと Compute Engine インスタンスのどちらで実行されているかにかかわらず、選択したサービスのインスタンス間でトラフィックを均等に分散します。

    DestinationRule リソースを使用して、各サービスのリビジョンのロード バランシング ポリシーを構成できます。Kiali ダッシュボードに次の図が表示されない場合は、ページを更新します。

    Kiali ダッシュボード ページ。

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

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

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

このセクションでは、GKE クラスタで実行されているサービス インスタンスにのみトラフィックをルーティングします。サンプル ワークロードのサービスごとに、Compute Engine で実行されているサービスを指す WorkloadEntry を削除します。これにより、サービスは GKE クラスタで実行されているマイクロサービス インスタンスのみを選択します。

次の図は、システムのターゲット アーキテクチャを示しています。

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

このアーキテクチャでは、トラフィックは GKE クラスタにのみルーティングされます。

このルーティングを適用するには、次の手順を行います。

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

    cd "${TUTORIAL_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 で実行されているマイクロサービス インスタンスを指す WorkloadEntries が GKE クラスタから削除されます。

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

    You can access the workload by loading http://[ISTIO_INGRESS_GATEWAY_EXTERNAL_IP]/productpage
    

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

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

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

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

    次の図に示すように、[Bookinfo] ページには、書籍に関する情報と、関連する評価が表示されます。

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

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

    マイクロサービス インスタンス。

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

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

移行元の環境を廃止する

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

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

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

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

次の手順で移行元の環境を廃止します。

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

    cd "${TUTORIAL_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. Google Cloud コンソールで、[リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

個々のリソースの削除

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

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

    terraform destroy -auto-approve
    

次のステップ