Anthos Service Mesh への Compute Engine 仮想マシンの追加

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

注: 現在、Compute Engine 仮想マシン（VM）は Anthos Service Mesh 1.11 でのみサポートされています。

このページでは、Compute Engine 仮想マシン（VM）を Google Kubernetes Engine（GKE）の Anthos Service Mesh に追加する方法について説明します。このページでは、VM を追加するクラスタを準備するオプションを使用して、Anthos Service Mesh 1.10.6 をインストールする方法について説明します。

• Anthos Service Mesh 1.9 or a 1.10 patch release がすでにインストールされている場合は、このページで説明するように、VM の追加に必要なオプションを使用して、Anthos Service Mesh 1.10.6 にアップグレードします。

• Anthos Service Mesh 1.9 を使用しており、アップグレードを行わない場合は、Anthos Service Mesh 1.9 ガイドで VM を Anthos Service Mesh 1.9 に追加する手順をご覧ください。

• 以前のバージョンの Anthos Service Mesh を使用している場合は、まず Anthos Service Mesh を 1.9 以降にアップグレードする必要があります。

このページでは、クラスタ内コントロール プレーンをインストールするためのコマンドラインについて説明します。

はじめに

Anthos Service Mesh を使用すると、マネージド インスタンス グループ（MIG）で実行されているサービスを、メッシュ内の Google Kubernetes Engine（GKE）クラスタで実行されているサービスと併せて管理、監視、保護できます。これにより、メッシュ内で Compute Engine インスタンスを使用して次のことができるようになります。

• トラフィックを管理する。
• mTLS を適用する。
• サービス トラフィックにアクセス制御を適用する。
• Google Cloud サービスに安全にアクセスする。
• 指標、ロギング、トレースデータを収集する。
• Google Cloud コンソールを使用してサービスをモニタリングする。

これにより、コンテナ化に適さない、またはコンテナ化の準備ができていない以前のアプリケーションが、Anthos Service Mesh の機能を活用でき、ワークロードを残りのサービスと統合できるようになります。

仕組み

ASM には、仮想マシンのワークロードを表す 2 つの関連するカスタム リソース定義（CRD）があります。

• WorkloadGroup は、共通のプロパティを共有する仮想マシン ワークロードの論理グループを表します。これは、Kubernetes における Deployment のようなものです。
• WorkloadEntry は、仮想マシンのワークロードの単一のインスタンスを表します。これは、Kubernetes における Pod のようなものです。
• そのうえで、Service は WorkloadGroup を選択して、Pod と同様の方法で、ASM にトラフィックを VM インスタンスへ転送させます。これにより、メッシュ内で VM が他のワークロードと同じように動作できます。

Compute Engine インスタンス グループごとに Compute Engine インスタンス テンプレートを作成します。各インスタンス グループは、そのグループ内の Compute Engine インスタンスごとにサービス プロキシ エージェントを指定します。インストールの間に、エージェントはサービス プロキシをブートストラップしてトラフィックを傍受するように設定し、Compute Engine インスタンスが存続する間、サービス プロキシの状態をモニタリングします。プロキシは Anthos Service Mesh のコントロール プレーンに接続し、各 Compute Engine インスタンスを、対応する WorkloadGroup の WorkloadEntry として自動的に登録します。これにより、Anthos Service Mesh は、各インスタンスをクラスタ内の Kubernetes Pod のようにサービス エンドポイントとして扱えるようになります。また、Kubernetes Pod の場合と同様、VM ワークロード用の Kubernetes Service を作成することもできます。

Compute Engine インスタンスのワークロード数を最小 MIG サイズのゼロ以上にスケールアウトするには、インスタンスのグループの自動スケーリングをご覧ください。

サービス プロキシ エージェントは、VM Manager を使用して、エージェントが MIG の各 VM にインストールされていることを確認します。インスタンス グループと VM 管理の詳細については、マネージド インスタンス グループ（MIG）と VM Manager をご覧ください。

サポートされている Linux ディストリビューション

OS バージョン	サポート対象
Debian 10
Debian 9
CentOs 8
CentOS 7

OS ディストリビューションの詳細については、Debian のサポートまたは CentOS のサポートをご覧ください。

制限事項

• メッシュ コントロール プレーンは Anthos Service Mesh 1.9 以降である必要があります。
• Compute Engine インスタンス テンプレートから作成された Compute Engine マネージド インスタンス グループのみがサポートされます。
• クラスタと VM は、同一ネットワークで同一プロジェクト内にあり、単一のネットワーク インターフェースを使用しなければなりません。
• この機能は GKE Enterprise のサブスクリプションがなくても使用できますが、Google Cloud コンソールの UI 要素や機能の中には GKE Enterprise のサブスクライバーのみが使用できるものがあります。サブスクライバーと非サブスクライバーが使用できる機能については、GKE Enterprise と Anthos Service Mesh の UI の違いをご覧ください。

前提条件

始める前に、次のことを行います。

前提条件で説明されている Cloud プロジェクト、GKE Enterprise ライセンス、一般的な要件を確認します。

クラスタ要件

続行する前に、クラスタが GKE の要件を満たしていることを確認してください。さらに、Anthos Service Mesh VM のサポートには、以下のことが必要です。

• Anthos Service Mesh をインストールするときに、Mesh CA を認証局（CA）として指定する。
• テレメトリー用に Stackdriver をオーバーライドしない。Anthos Service Mesh をインストールすると、デフォルトで Stackdriver が構成されます。
• クラスタがフリートに登録されている。クラスタが登録されていない場合は、VM のインストール プロセスにより、指定のプロジェクトにクラスタが登録されます。

始める

使ってみるの手順に沿って、以下を行ってください。

• 必要なツールをインストールする
• asmcli をダウンロードする
• クラスタ管理者の権限を付与する
• プロジェクトとクラスタを検証する

Anthos Service Mesh がインストールされていない場合は、次のセクションに進みます。Anthos Service Mesh がすでにインストールされている場合は、既存のインストールの手順を行います。

新規インストール

Anthos Service Mesh 1.10 のコントロール プレーンを準備することで、VM 用の Anthos Service Mesh クラスタをセットアップします。

次のコマンドを使用して、--option vm を使用して Anthos Service Mesh クラスタ内コントロール プレーンをインストールし、VM を追加するコントロール プレーンを作成します。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm

• --project_id、--cluster_name、--cluster_location: クラスタが属するプロジェクト ID、クラスタ名、クラスタゾーンまたはリージョンを指定します。
• --output_dir: asmcli が anthos-service-mesh パッケージをダウンロードして、istioctl、サンプル、マニフェストを含むインストール ファイルを抽出するディレクトリを指定する場合に指定します。それ以外の場合、asmcli はファイルを tmp ディレクトリにダウンロードします。相対パスまたはフルパスを指定できます。環境変数 $PWD はここでは機能しません。
• --enable_all: スクリプトが次の処理を行います。
  • 必要な IAM 権限を付与する。
  • 必要な Google API を有効にする。
  • メッシュを識別するラベルをクラスタに設定する。
  • フリートにクラスタを登録する（まだ登録されていない場合）。

• --ca mesh_ca: 認証局として Mesh CA を使用します。asmcli は、フリート Workload Identity を使用するように Mesh CA を構成します。
• --option vm: サービス メッシュに、VM を追加するクラスタを準備します。

クラスタで既存のワークロードが実行されている場合は、ワークロードを再デプロイしてから、このページに戻って VM を追加してください。

既存のインストール

クラスタに Anthos Service Mesh がすでにインストールされている場合は、次の手順を行います。

1. まだ行っていない場合は、クラスタをフリートに登録します。

2. 次のコマンドを実行して、Anthos Service Mesh のインストールされている環境が VM ワークロードに対応できるよう準備して確認します。

   ./asmcli experimental vm prepare-cluster \
       --project_id PROJECT_ID \
       --cluster_name CLUSTER_NAME \
       --cluster_location CLUSTER_LOCATION
   

   成功すると、コマンドによって次の内容が出力されます。

   The cluster is ready for adding VM workloads.
   Please follow the Anthos Service Mesh for Compute Engine VM user guide to add
   Compute Engine VMs to your mesh.
   

このコマンドは、次のことを行います。

1. VM 自動登録を有効化: PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION 変数と PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY 変数を true に設定することで有効化します。VM 自動登録が有効になると、新しい VM インスタンスは WorkloadGroup に登録され、新しい WorkloadEntry CR が作成されて、VM にトラフィックが転送されるようになります。asmcli を使用してインストールされたすべての Anthos Service Mesh 1.9 以降のコントロール プレーンでは、VM 自動登録がデフォルトで有効になります。

2. Expansion ゲートウェイのインストール: このゲートウェイは、eastwest ゲートウェイという名前で、Anthos Service Mesh 構成ファイル パッケージに定義されています。また、このインストールにより、コントロール プレーンが VM に公開されます。

3. IdentityProvider CRD のインストールと Google IdentityProvider CR の登録を行い、VM が Anthos Service Mesh コントロール プレーンを認証して、他のサービス メッシュと安全に通信できるようにします。

4. asmcli スクリプトで --enable_all または --enable_registration を使用する場合は、クラスタをフリートに登録し、Workload Identity を有効にします。

5. フリート内で Service Mesh 機能を有効にします。この機能により、VM がメッシュと安全に通信するために必要なポリシーが管理されます。

Ingress ゲートウェイをインストールする

Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。

1. Ingress ゲートウェイの名前空間をまだ作成していない場合は作成します。ゲートウェイはユーザー ワークロードであり、コントロール プレーンの名前空間にデプロイすることはおすすめしません。GATEWAY_NAMESPACE は、名前空間の名前に置き換えます。

   kubectl create namespace GATEWAY_NAMESPACE
   

2. ゲートウェイの名前空間にリビジョン ラベルを適用することで、ゲートウェイで自動インジェクションを有効にします。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたプロキシを特定のコントロール プレーン リビジョンに関連付けます。使用するリビジョン ラベルは、マネージド Anthos Service Mesh をデプロイしたか、クラスタ内コントロール プレーンをデプロイしたかによって異なります。

   1. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

      kubectl -n istio-system get pods -l app=istiod --show-labels
      

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

      NAME                                READY   STATUS    RESTARTS   AGE   LABELS
      istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
      istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586

      出力の LABELS 列で、接頭辞 istio.io/rev= に続く istiod リビジョン ラベルの値をメモします。この例での値は asm-1106-2 です。

   2. リビジョン ラベルを名前空間に適用します。次のコマンドで、REVISION は前の手順でメモした istiod リビジョン ラベルの値です。

      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
      

   出力内のメッセージ "istio-injection not found" は無視して構いません。これは、今までは名前空間に istio-injection ラベルが付いていなかったことを意味します。Anthos Service Mesh の新規インストールや新規デプロイでは、こうなって当然です。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

3. --output_dir で指定したディレクトリに移動します。

4. samples/gateways/istio-ingressgateway/ ディレクトリにある Ingress ゲートウェイ構成のサンプルをそのままデプロイするか、必要に応じて変更します。

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
   

ゲートウェイのベスト プラクティスの詳細を確認してください。

VM の追加

このセクションでは、gcloud で作成したインスタンス テンプレートに基づいて、Compute Engine インスタンスをメッシュに追加します。gcloud は、サービス プロキシ エージェントに必要な構成のみを生成します。インスタンス テンプレートに構成を追加するには、gcloud リファレンス ガイドをご覧ください。

VM をメッシュに追加する手順は次のとおりです。

1. 続く手順で使用する環境変数を設定します。これらの変数は、VM ワークロードごとに設定します。

   • WORKLOAD_NAME は、VM が属しているワークロードの名前です。小文字の英数字で構成される DNS-1123 準拠のサブドメインを指定する必要があります。
   • WORKLOAD_VERSION は、VM が属しているワークロードのバージョンです。省略可。
   • WORKLOAD_SERVICE_ACCOUNT は、VM が実行されるサービスの GCP サービス アカウントです。
   • WORKLOAD_NAMESPACE は、ワークロードの名前空間です。
   • ASM_INSTANCE_TEMPLATE は、作成されるインスタンス テンプレートの名前です。Compute Engine インスタンス テンプレート名にアンダースコアは使用できません。

2. VM ワークロードの Namespace をまだ作成していない場合は作成します。

   kubectl create ns WORKLOAD_NAMESPACE
   

3. コントロール プレーンのリビジョンで名前空間にラベルを付けます。

   次の例で REVISION と示されているコントロール プレーンのリビジョンを見つける方法の例については、ワークロードのデプロイと再デプロイをご覧ください。

   kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
   

4. 登録する VM の WorkloadGroup を作成します。

   kubectl apply -f - << EOF
   apiVersion: networking.istio.io/v1alpha3
   kind: WorkloadGroup
   metadata:
     name: WORKLOAD_NAME
     namespace: WORKLOAD_NAMESPACE
   spec:
     metadata:
       labels:
         app.kubernetes.io/name: WORKLOAD_NAME
         app.kubernetes.io/version: WORKLOAD_VERSION
       annotations:
         security.cloud.google.com/IdentityProvider: google
     template:
       serviceAccount: WORKLOAD_SERVICE_ACCOUNT
   EOF
   

   項目	説明
   name	VM が属しているワークロードの名前。
   namespace	ワークロードが属している名前空間。
   app.kubernetes.io/name	Kubernetes アプリケーションの推奨ラベル。VM ワークロードに独自のラベルを使用できます。
   app.kubernetes.io/version	Kubernetes アプリケーションの推奨ラベル。VM ワークロードに独自のラベルを使用できます。
   serviceAccount	VM とプロジェクトで使用されるサービス アカウント ID。SPFFE 形式のワークロードの ID の一部として使用されます。詳しくは、サービス アカウントをご覧ください。
   security.cloud.google.com/IdentityProvider	VM が使用する ID プロバイダ。クラスタにすでに登録されている必要があります。Compute Engine VM の場合は、google に設定します。IdentityProvider は、VM の認証情報を認証する方法と、VM のサービス アカウントを抽出する場所をコントロール プレーンに指示します。

5. --mesh フラグを指定して gcloud beta compute instance-templates create コマンドを実行し、Anthos Service Mesh Compute Engine インスタンス用のインスタンス テンプレートを作成します。

   gcloud は、クラスタの前提条件の確認、Anthos Service Mesh の VM ラベルの追加、サービス プロキシ エージェントのカスタム メタデータ構成の生成、新しいインスタンス テンプレートの作成を行います。

   インスタンス テンプレートにネットワーク接続を必要とする起動スクリプトが含まれている場合、一時的なネットワーク接続の問題についてスクリプトを復元できるようにする必要があります。一時的なネットワーク障害に対する復元力を向上させる方法の例については、デモ アプリケーションをご覧ください。

   インスタンス テンプレート作成の詳細については、インスタンス テンプレートの作成をご覧ください。

   gcloud beta compute instance-templates create \
   ASM_INSTANCE_TEMPLATE \
   --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
   --project PROJECT_ID
   

6. 作成する MIG ごとに、次の環境変数を設定します。

   • INSTANCE_GROUP_NAME は、作成する Compute Engine インスタンス グループの名前です。
   • ASM_INSTANCE_TEMPLATE は、作成されるインスタンス テンプレートの名前です。Compute Engine インスタンス テンプレート名にアンダースコアは使用できません。
   • INSTANCE_GROUP_ZONE は、作成する Compute Engine インスタンス グループのゾーンです。
   • PROJECT_ID は、クラスタが作成されたプロジェクトの ID です。
   • SIZE は、作成するインスタンス グループのサイズです。インスタンス グループの作成後に変更できます。
   • WORKLOAD_NAME は、VM が属するワークロードの名前です。
   • WORKLOAD_NAMESPACE は、ワークロードの名前空間です。

7. 前の手順で作成した変数を使用して、VM ワークロードのマネージド インスタンス グループを作成します。

   gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
   --template ASM_INSTANCE_TEMPLATE \
   --zone=INSTANCE_GROUP_ZONE \
   --project=PROJECT_ID \
   --size=SIZE
   

   Compute Engine インスタンスのワークロード数をゾーンまたはリージョンの MIG サイズのゼロ以上にスケールアウトするには、インスタンスのグループの自動スケーリングをご覧ください。グループの作成の詳細については、gcloud compute instance-groups managed create をご覧ください。

   インスタンスが起動すると、クラスタの Anthos Service Mesh コントロール プレーンで自動的に認証され、各 VM はコントロール プレーンによって WorkloadEntry として登録されます。

8. MIG 内の VM インスタンスが起動すると、次のコマンドを使用して、ワークロードの名前空間に登録されている VM を表示できます。

   kubectl get workloadentry -n WORKLOAD_NAMESPACE
   

   注: WorkloadGroup または IdentityProvider カスタム リソースが削除されると、VM はメッシュと通信できなくなります。

9. 先に追加した VM ワークロードを公開する Kubernetes Service を追加します。正しいトラフィック ルーティングを行うために、上で登録した VM WorkloadGroup に対応するラベルがサービスに選択されていることを確認してください。

   次の例では、名前空間 WORKLOAD_NAMESPACE に WORKLOAD_NAME という名前の Kubernetes Service を作成し、VM ワークロードを app.kubernetes.io/name: WORKLOAD_NAME というラベルで HTTP ポート 80 に公開します。

   kubectl apply -f - << EOF
   apiVersion: v1
   kind: Service
   metadata:
     name: WORKLOAD_NAME
     namespace: WORKLOAD_NAMESPACE
     labels:
       asm_resource_type: VM
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app.kubernetes.io/name: WORKLOAD_NAME
   EOF
   

   Kubernetes Service を作成する方法の詳細については、https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service をご覧ください。

10. VM でサンプル アプリケーションを使用するには、サンプル アプリケーションをデプロイするをご覧ください。

クラスタ内コントロール プレーンのアップグレード後にワークロードを再デプロイする

前のセクションで Anthos Service Mesh をアップグレードし、クラスタで実行されているワークロードがある場合は、それらを新しいコントロール プレーンに切り替えます。

VM ワークロードの場合は、新しいインスタンス テンプレートを作成し、MIG 内の VM に対してローリング アップデートを実施します。

1. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

   kubectl -n istio-system get pods -l app=istiod --show-labels
   

   このコマンドからの出力は、次のようになります。移行による出力は、アップグレードとは少し異なります。次の出力例は、移行によるものです。

   NAME                                         READY   STATUS    RESTARTS   AGE   LABELS
   istiod-7744bc8dd7-qhlss                      1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
   istiod-asm-1106-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=85d86774f7
   istiod-asm-1106-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=85d86774f7

   1. 出力の LABELS 列の下で、接頭辞 istio.io/rev= に続く、新しいバージョンの istiod リビジョン ラベルの値をメモします。この例での値は asm-1106-2 です。

   2. 古い istiod バージョンのリビジョン ラベルの値にも注意してください。これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンの istiod を削除するために必要です。この出力例では、istiod の古いバージョンのリビジョン ラベルの値は default です。

2. リビジョン ラベルを名前空間に追加し、istio-injection ラベルを削除します（ある場合）。次のコマンドで、REVISION を istiod の新しいリビジョンと一致する値に変更します。

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   出力に "istio-injection not found" が表示された場合は、無視してかまいません。これは、以前、名前空間に istio-injection ラベルが付加されていなかったことを意味します。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

3. gcloud を使用して、新しいインスタンス テンプレートを作成します。同じワークロードにインスタンス テンプレートがある場合は、必ず同じ構成を含めます。

   gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
   --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
   --project PROJECT_ID
   

4. 既存の MIG に対してワークロードのローリング アップデートを実行します。

   詳細については、基本的なローリング アップデートの開始をご覧ください。

   gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
   --version=template=NEW_ASM_INSTANCE_TEMPLATE \
   --zone=INSTANCE_GROUP_ZONE
   

5. VM ワークロードをテストして、想定どおりに動作することを確認します。

VM アプリケーションのアップグレード

WorkloadGroup やインスタンス テンプレート構成の変更を含め、アプリケーションを更新した場合は、新しいインスタンス テンプレートで VM ワークロードの MIG を更新する必要があります。

WorkloadGroup の変更が適用されるか、新しいソース インスタンス テンプレートが作成されたときに、Anthos Service Mesh の新しいインスタンス テンプレートを作成し、MIG 内の VM に対してローリング アップデートを実行します。

1. gcloud を使用して、新しいインスタンス テンプレートを作成します。

   gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
   --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
   --project PROJECT_ID
   

2. 既存の MIG に対してワークロードのローリング アップデートを実行します。MIG ローリング アップデートの利用方法の詳細については、基本的なローリング アップデートの開始をご覧ください。

   gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
   --version=template=NEW_ASM_INSTANCE_TEMPLATE \
   --zone=INSTANCE_GROUP_ZONE
   

3. VM ワークロードをテストして、想定どおりに動作することを確認します。

サンプル アプリケーションをデプロイする

新しいメッシュ構成が正常に機能することを示すには、Bookinfo サンプル アプリケーションをインストールします。この例では、VM 上で MySQL データベースを実行して、レーティング サービスがデータベースから評価値を読み取ります。

クラスタに Bookinfo をインストールする

各サービスと一緒に挿入されたサイドカー プロキシと BookInfo アプリケーションのサービスをデプロイするには、次の操作を行います。BookInfo アプリケーションは、default Namespace にデプロイされます。

1. Anthos Service Mesh をインストールした PC のコマンドラインで、スクリプトのダウンロードの手順で作成した Anthos Service Mesh インストール ディレクトリのルートに移動します。

2. 自動サイドカー インジェクションを有効にするには、Anthos Service Mesh コントロール プレーンの種類に応じて手順を選択します。

   次のコマンドを使用して、istiod のラベルを見つけます。このラベルには、後のステップで使用するリビジョン ラベルの値が含まれます。

   kubectl -n istio-system get pods -l app=istiod --show-labels
   

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

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
   

   出力の LABELS 列で、接頭辞 istio.io/rev= に続く istiod リビジョン ラベルの値をメモします。この例での値は asm-1106-2 です。

3. リビジョン ラベルを default 名前空間に適用します。

   次のコマンドで、REVISION は前の手順でメモした istiod リビジョン ラベルの値です。

   kubectl label namespace default istio-injection- istio.io/rev=REVISION --overwrite
   

   出力内のメッセージ "istio-injection not found" は無視して構いません。これは、今までは名前空間に istio-injection ラベルが付いていなかったことを意味します。Anthos Service Mesh の新規インストールや新規デプロイでは、こうなって当然です。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

4. kubectl を使用してアプリケーションをデフォルトの名前空間にデプロイします。

   kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
   

5. 次のコマンドを実行して、アプリケーションが正しくデプロイされていることを確認します。

   kubectl get services
   

   予想される出力:

   NAME                       CLUSTER-IP   EXTERNAL-IP         PORT(S)              AGE
   details                    10.0.0.31    <none>        9080/TCP             6m
   kubernetes                 10.0.0.1     <none>        443/TCP              7d
   productpage                10.0.0.120   <none>        9080/TCP             6m
   ratings                    10.0.0.15    <none>        9080/TCP             6m
   reviews                    10.0.0.170   <none>        9080/TCP             6m

   および

   kubectl get pod
   

   予想される出力:

   NAME                                        READY     STATUS    RESTARTS   AGE
   details-v1-1520924117-48z17                 2/2       Running   0          6m
   productpage-v1-560495357-jk1lz              2/2       Running   0          6m
   ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
   reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
   reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
   reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

6. 最後に、アプリケーションの Ingress ゲートウェイ ルーティングを定義します。

   kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
   

   予想される出力:

   gateway.networking.istio.io/bookinfo-gateway created
   virtualservice.networking.istio.io/bookinfo created

7. プロダクト ページにアクセスできることを確認します。次のコマンドで、GATEWAY_NAMESPACE は Istio ゲートウェイの名前空間です。

   export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
   export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}"
   curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"
   

   予想される出力:

   <title>Simple Bookstore App</title>
   

Compute Engine インスタンスを作成して MySQL をインストールする

このステップでは、VM 上で実行される MySQL インスタンス用の Compute Engine インスタンス テンプレートを作成します。詳細な手順については、仮想マシンを使用した Bookinfo をご覧ください。

1. 起動スクリプトを作成して MySQL をインストールし、起動時にレーティング データベースを追加します。CentOS を使用している場合、mariadb-server の準備ができるまで、最長で 10 分かかります。

   Debian

   cat << "EOF" > init-mysql
   #!/bin/bash
   
   # Wait until Envoy is ready before installing mysql
   while true; do
     rt=$(curl -s 127.0.0.1:15000/ready)
     if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
       echo "envoy is ready"
       break
     fi
     sleep 1
   done
   
   # Wait until DNS is ready before installing mysql
   while true; do
     curl -I productpage.default.svc:9080
     if [[ $? -eq 0 ]]; then
       echo "dns is ready"
       break
     fi
     sleep 1
   done
   
   sudo apt-get update && sudo apt-get install -y mariadb-server
   
   sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf
   
   cat <<EOD | sudo mysql
   # Grant access to root
   GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
   
   # Grant root access to other IPs
   CREATE USER 'root'@'%' IDENTIFIED BY 'password';
   GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
   FLUSH PRIVILEGES;
   quit
   EOD
   
   sudo systemctl restart mysql
   
   curl -LO https://raw.githubusercontent.com/istio/istio/release-1.10/samples/bookinfo/src/mysql/mysqldb-init.sql
   
   mysql -u root -ppassword < mysqldb-init.sql
   EOF
   

   CentOS

   cat << "EOF" > init-mysql
   #!/bin/bash
   
   # Wait until Envoy is ready before installing mysql
   while true; do
     rt=$(curl -s 127.0.0.1:15000/ready)
     if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
       echo "envoy is ready"
       break
     fi
     sleep 1
   done
   
   # Wait until DNS is ready before installing mysql
   while true; do
     curl -I productpage.default.svc:9080
     if [[ $? -eq 0 ]]; then
       echo "dns is ready"
       break
     fi
     sleep 1
   done
   
   sudo yum update -y && sudo yum install -y mariadb-server
   
   # Wait until mysql is ready
   while true; do
     rt=$(which mysql)
     if [[ ! -z "${rt}" ]]; then
       echo "mysql is ready"
       break
     fi
     sleep 1
   done
   
   sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf
   
   sudo systemctl restart mariadb
   
   cat > grantaccess.sql << EOD
   
   GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
   
   CREATE USER 'root'@'%' IDENTIFIED BY 'password';
   GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
   FLUSH PRIVILEGES;
   EOD
   
   until sudo mysql < grantaccess.sql; do
      sleep 1
   done
   
   sudo systemctl restart mariadb
   
   curl -LO https://raw.githubusercontent.com/istio/istio/release-1.10/samples/bookinfo/src/mysql/mysqldb-init.sql
   
   mysql -u root -ppassword < mysqldb-init.sql
   EOF
   

2. MySQL ワークロードの WorkloadGroup を作成します。

   kubectl apply -f - << EOF
   apiVersion: networking.istio.io/v1alpha3
   kind: WorkloadGroup
   metadata:
     name: mysql
     namespace: default
   spec:
     metadata:
       labels:
         app.kubernetes.io/name: mysql
       annotations:
         security.cloud.google.com/IdentityProvider: google
     template:
       serviceAccount: WORKLOAD_SERVICE_ACCOUNT
   EOF
   

3. gcloud を使用して、メッシュ用のインスタンスを準備するための新しいインスタンス テンプレートを作成し、上で作成した起動スクリプトを挿入します。

   Debian

   gcloud beta compute instance-templates create asm-mysql-instance-template \
   --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
   --project PROJECT_ID \
   --metadata-from-file=startup-script=init-mysql \
   --image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB
   

   CentOS

   gcloud beta compute instance-templates create asm-mysql-instance-template \
   --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
   --project PROJECT_ID \
   --metadata-from-file=startup-script=init-mysql \
   --image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB
   

4. 新しく作成したインスタンス テンプレートを使用して、Compute Engine MIG を作成します。

   gcloud compute instance-groups managed create mysql-instance \
   --template asm-mysql-instance-template \
   --zone=us-central1-c \
   --project=PROJECT_ID \
   --size=1
   

サービスの作成

次のコマンドを使用して、MySQL サービス用の Kubernetes Service を作成します。

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: default
  labels:
    asm_resource_type: VM
spec:
  ports:
  - name: mysql
    port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app.kubernetes.io/name: mysql
EOF

Anthos UI ダッシュボードを使用する

新しく作成した VM ベースの Service を表示するには、左側のナビゲーション バーから [Anthos] > [Service Mesh] の順にクリックします。メッシュで実行されているサービスのテーブルが表示されます。追加したサービスがテーブルに表示され、VM の Type 値といくつかの上位レベルの指標も表示されます。VM ベースのサービスの他のテレメトリーを表示するには、サービス名をクリックします。これにより、サービスレベルのダッシュボードが表示されます。

Anthos UI ダッシュボードの使用方法についての詳細は、Cloud コンソールでの Anthos Service Mesh の探索をご覧ください。

注: 現在、GKE Enterprise UI ダッシュボードには HTTP 指標のみが表示されます。詳細については、プロトコルのサポートをご覧ください。

VM ワークロードへのトラフィックを管理する

VM との間のトラフィック フローは、ネットワーキング ルールを変更して制御できます。

新しいレーティング サービスへの（Pod から VM への）トラフィックを制御する

Bookinfo に別のレーティング サービスを作成して、上で作成した MySQL インスタンスをデータソースとして使用し、レビュー サービスが新しいレーティング サービスを使用することを強制するルーティング ルールを指定します。

1. MySQL インスタンスを使用する新しいレーティング サービスを作成します。

   kubectl apply -f - << EOF
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ratings-v2-mysql-vm
     labels:
       app: ratings
       version: v2-mysql-vm
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: ratings
         version: v2-mysql-vm
     template:
       metadata:
         labels:
           app: ratings
           version: v2-mysql-vm
       spec:
         serviceAccountName: bookinfo-ratings
         containers:
         - name: ratings
           image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2
           imagePullPolicy: IfNotPresent
           env:
             - name: DB_TYPE
               value: "mysql"
             - name: MYSQL_DB_HOST
               value: mysql.default.svc.cluster.local
             - name: MYSQL_DB_PORT
               value: "3306"
             - name: MYSQL_DB_USER
               value: root
             - name: MYSQL_DB_PASSWORD
               value: password
           ports:
           - containerPort: 9080
   EOF
   

2. ルーティング ルールの作成

   kubectl apply -f - << EOF
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: reviews
   spec:
     hosts:
     - reviews
     http:
     - route:
       - destination:
           host: reviews
           subset: v3
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: ratings
   spec:
     hosts:
     - ratings
     http:
     - route:
       - destination:
           host: ratings
           subset: v2-mysql-vm
   EOF
   

3. 作成したサービスの宛先ルールを適用します。

   kubectl apply -f - << EOF
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     name: reviews
   spec:
     host: reviews
     subsets:
     - name: v1
       labels:
         version: v1
     - name: v2
       labels:
         version: v2
     - name: v3
       labels:
         version: v3
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     name: ratings
   spec:
     host: ratings
     subsets:
     - name: v1
       labels:
         version: v1
     - name: v2
       labels:
         version: v2
     - name: v2-mysql
       labels:
         version: v2-mysql
     - name: v2-mysql-vm
       labels:
         version: v2-mysql-vm
   EOF
   

アプリケーションのデプロイの検証

BookInfo アプリケーションが機能しているかどうかを確認するには、Ingress ゲートウェイにトラフィックを送信する必要があります。

• Anthos Service Mesh を GKE にインストールした場合は、前の手順で作成した Ingress ゲートウェイの外部 IP アドレスを取得します。

  kubectl get svc istio-ingressgateway -n GATEWAY_NAMESPACE
  

  出力:

  NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
  istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

  この例では、Ingress サービスの IP アドレスは 35.239.7.64 です。

アプリケーションの実行

1. curl で BookInfo アプリが実行されていることを確認します。

   curl -I http://EXTERNAL_IP/productpage
   

   レスポンスに 200 が示されている場合、アプリケーションが Anthos Service Mesh と正しく連動しています。

2. BookInfo ウェブページを表示するには、ブラウザに次のアドレスを入力します。

   http://EXTERNAL_IP/productpage
   

3. Bookinfo アプリケーションのホームページで、Reviewer1 にはファイブスター、Reviewer2 にはフォースターが表示されていることを確認します。

VM ワークロードへのセキュリティの適用

VM ワークロードへのセキュリティの適用は、Kubernetes ワークロードのセキュリティ強化と同じです。詳細については、Istio セキュリティをご覧ください。

前の手順を完了すると、Compute Engine VM には Google 発行のワークロード証明書が追加されます。証明書の SubjectAlternativeName の値は、spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT の形式で VM の Anthos Workload Identity を示します。

詳細については、Workload Identity プールをご覧ください。

メッシュの mTLS の STRICT モードを有効にする

次の YAML を適用して、メッシュ全体に STRICT の mTLS を強制適用します。

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

サービス間トラフィックの認可

AuthorizationPolicy を使用して、Compute Engine VM 上のアプリケーションと、他のメッシュ ワークロード（GKE クラスタなど）間のアクセスを制御します。

注: すべての認可ポリシーで cluster.local を使用して Workload Identity プールを参照する必要があります。これにより、移行する場合や Workload Identity プールの形式が変更された場合に、メッシュの Workload Identity プールを簡単に更新できます。

例: Kubernetes ワークロードから Compute Engine VM へのアクセスを拒否する

次の認可ポリシーは、Kubernetes ワークロードの ratings が ratings MySQL サーバーを提供する Compute Engine VM ワークロードにアクセスすることを拒否します。

  kubectl apply -f - << EOF
  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    name: mysql-deny
    namespace: default
  spec:
    selector:
      matchLabels:
        app.kubernetes.io/name: mysql
    action: DENY
    rules:
    - from:
      - source:
          principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
  EOF

サンプルの AuthorizationPolicy を適用すると、プロダクト ページのブックレビュー セクションに「Ratings service is currently unavailable」のエラー メッセージが表示されます。

Cloud Monitoring エージェントのインストール

Cloud Monitoring エージェントをインストールして、VM インスタンスからシステム指標とアプリケーション指標を収集、モニタリングできます。これにより、エージェントの CPU やメモリ使用率など、主要な指標をモニタリングできます。

詳細については、Cloud Monitoring エージェントのドキュメントをご覧ください。

トラブルシューティング

トラブルシューティングのヒントについては、VM のトラブルシューティング サポートをご覧ください。