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

はじめに

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 における Deployment のようなものです。
  • そのうえで、ServiceWorkloadGroup を選択して、Pod と同様の方法で、ASM にトラフィックを VM インスタンスへ転送させます。これにより、メッシュ内で VM が他のワークロードと同じように動作できます。

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

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 の違いをご覧ください。

前提条件

始める前に、次の前提事項を確認してください。

クラスタ

このページでは、手順の一部として Anthos Service Mesh をインストールする選択肢と、Anthos Service Mesh がすでにインストールされているクラスタを更新する選択肢について説明します。いずれの場合も、これらの手順では、Anthos Service Mesh 1.9 以降と、次の要件を満たすクラスタが必要です。また、Anthos Service Mesh の VM サポートでは、別の要件もあります。

  • コントロール プレーンは、制御するクラスタにインストールされている必要があります。Google が管理するコントロール プレーンはサポートされていません。詳細については、Google が管理するコントロール プレーンをご覧ください。
  • 認証局には、Mesh CA を使用します。
  • テレメトリーには、Stackdriver を使用します。
  • Canonical Service のデプロイを有効にします。これは、Anthos Service Mesh のインストール プロセスで自動的に有効にされるものです。

クラスタは、フリートに登録されている必要があります。ただし、まだ登録していない場合でも、VM インストール プロセスを使用して指定のプロジェクトで登録できます。

GKE Enterprise サブスクライバーの場合は、GKE Enterprise API を有効にします。

API の有効化

CLI ツール

インストール プロセスには、次のツールが必要です。Google Cloud Shell を使用する場合は、これらのツールはすでにインストールされています。

  • gcloud
  • kubectl
  • kpt
  • curl
  • jq
  • awk
  • printf
  • tr
  • grep
  • tail

スクリプトのダウンロード

このセクションでは、VM オンボーディング用のスクリプトをダウンロードする方法について説明します。

  1. Anthos Service Mesh 1.9.8 の VM スクリプトを、現在の作業ディレクトリにダウンロードします。

    curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm
    
  2. 現在の作業ディレクトリにファイルの SHA-256 をダウンロードします。

    curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9.sha256 > asm_vm.sha256
    
  3. 両方のファイルを同じディレクトリに置いて、ダウンロードを検証します。

    sha256sum -c --ignore-missing asm_vm.sha256
    

    検証が成功すると、コマンドは asm_vm: OK を出力します。

    互換性を維持するため、asm_vm.sha256 にはチェックサムを 2 回含めて、スクリプトのすべてのバージョンの名前を asm_vm に変更できるようにします。--ignore-missing が存在しないというエラーが表示された場合は、--ignore-missing フラグを指定せずに上記のコマンドを再実行します。

  4. スクリプトを実行可能にします。

    chmod +x asm_vm
    

スタートガイド

このセクションでは、Compute Engine インスタンスを Anthos Service Mesh に追加する手順について説明します。

環境の設定

  1. 以降の手順の一部では、クラスタに直接変更を加える必要があるため、gcloud を使用して kubectl ツールが指定したクラスタを指すように構成します。

    gcloud container clusters get-credentials CLUSTER_NAME --zone CLUSTER_LOCATION --project PROJECT_ID
    

クラスタの準備

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

クラスタに Anthos Service Mesh 1.9 以降がすでにインストールされているかどうかに応じて、次の手順を選択します。

インストールされていません

次の例は、クラスタに Anthos Service Mesh 1.9 以降がインストールされていない場合に、vm オプションと hub-meshca オプションを追加して、GKE のインストール、移行、アップグレードで説明されている通常の Anthos Service Mesh のインストール手順を変更する方法を示しています。また、次の例で使用している install_asm スクリプトをダウンロードする方法についても説明しています。

install_asm スクリプトをダウンロードすると、--option hub-meshca--option vm--enable_all フラグを含めることで、クラスタに Anthos Service Mesh をインストールできます。詳細については、フリートで Mesh CA を有効にするイネーブルメント フラグをご覧ください。

./install_asm --project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install --option vm --option hub-meshca \
--enable_all

インストール済み

お使いのクラスタに Anthos Service Mesh 1.9 以降がすでにインストールされていて、フリートが有効な Mesh CA がある場合は、Anthos Service Mesh コントロール プレーンを更新して、VM ベースのワークロードをサポートします。また、このスクリプトにより、クラスタ内の Anthos Service Mesh のインストールが VM ワークロードに対して準備ができているかどうかを確認できます。具体的には、prepare_cluster サブコマンドを使用して Anthos Service Mesh 1.9 以降のすべてのリビジョンを更新し、VM ワークロードに対する準備を整えます。

Anthos Service Mesh 1.9 以降のインストール環境でフリートでの Mesh CA が有効でない場合は、install_asm スクリプトで --option hub-meshca フラグと --option vm フラグを使用して、Anthos Service Mesh 1.9 以降を再インストールまたはアップグレードします。

./asm_vm prepare_cluster \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION

前の手順では、次の操作が行われます。

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

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

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

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

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

VM の追加

このセクションでは、asm_vm スクリプトを使用して作成したインスタンス テンプレートに基づいて、Compute Engine インスタンスをメッシュに追加します。このスクリプトは、サービス プロキシ エージェントに必要な構成のみを生成します。インスタンス テンプレートにさらに構成を含めるには、ソース インスタンス テンプレートを作成し、それをスクリプトに追加します。

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

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

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

    kubectl create ns WORKLOAD_NAMESPACE
    
  3. コントロール プレーンのリビジョンで Namespace にラベルを付けます。次の例で 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. 次のオプションとフラグを使用して asm_vm スクリプトを実行し、Anthos Service Mesh Compute Engine インスタンスのインスタンス テンプレートを作成します。

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

    スクリプトの元になる既存のインスタンス テンプレートがある場合は、--source_instance_template オプションを指定できます。デフォルト以外の VM を Anthos Service Mesh に追加するには、目的の OS ディストリビューションを含むインスタンス テンプレートを作成し、そのテンプレートを asm_vm スクリプトの --source_instance_template フラグの値として使用します。既存のインスタンス テンプレートにネットワーク接続を必要とする起動スクリプトが含まれている場合、一時的なネットワーク接続の問題についてスクリプトを復元できるようにする必要があります。一時的なネットワーク障害に対する復元力を向上させる方法の例については、デモ アプリケーションをご覧ください。

    ./asm_vm create_gce_instance_template \
    ASM_INSTANCE_TEMPLATE \
    --project_id PROJECT_ID \
    --cluster_location CLUSTER_LOCATION \
    --cluster_name CLUSTER_NAME \
    --workload_name WORKLOAD_NAME \
    --workload_namespace WORKLOAD_NAMESPACE \
    --source_instance_template SOURCE_INSTANCE_TEMPLATE
    

    オプション

    オプション 説明
    -p|--project_id PROJECT_ID クラスタが作成されたプロジェクト ID。
    -n|--cluster_name CLUSTER_NAME クラスタの名前。
    -l|--cluster_location CLUSTER_LOCATION クラスタが作成されたゾーン(シングルゾーン クラスタの場合)またはリージョン(リージョン クラスタの場合)のいずれか。
    -w|--workload_name WORKLOAD_NAME Compute Engine インスタンスが表すワークロードの名前。
    --workload_namespace WORKLOAD_NAMESPACE 省略可。ワークロードの名前空間。デフォルトは「default」です。
    -s|--source_instance_template SOURCE_INSTANCE_TEMPLATE_NAME 省略可。Anthos Service Mesh Compute Engine インスタンス テンプレートのベースとして使用する既存のインスタンス テンプレート。指定しない場合、デフォルト値のインスタンス テンプレートが作成されます。

    フラグ

    フラグ 説明
    -v|--verbose 実行前および実行後にコマンドを出力します。
    --dry_run コマンドを出力しますが、実行しません。
    --only_validate 検証を実行しますが、新しい Compute Engine インスタンス テンプレートは作成しません。
    -h|--help オプション、フラグ、終了を説明するヘルプ メッセージを表示します。
  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
    
  9. 先に追加した VM ワークロードを公開する Kubernetes Service を追加します。正しいトラフィック ルーティングを行うために、上で登録した VM WorkloadGroup に対応するラベルがサービスに選択されていることを確認してください。

    次の例では、名前空間 WORKLOAD_NAMESPACEWORKLOAD_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 コントロール プレーンのアップグレード

Anthos Service Mesh の最新バージョンへのアップグレードの手順に沿って、Anthos Service Mesh コントロール プレーンを新しいバージョンにアップグレードします。新しいバージョンの Anthos Service Mesh コントロール プレーンをインストールした後は、ワークロードのデプロイと再デプロイの手順に沿って Kubernetes ワークロードを再デプロイします。

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-198-6-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
    istiod-asm-198-6-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
    1. 出力の LABELS 列の下で、接頭辞 istio.io/rev= に続く、新しいバージョンの istiod リビジョン ラベルの値をメモします。この例での値は asm-198-6 です。

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

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

    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. asm_vm スクリプトを使用して、新しいインスタンス テンプレートを作成します。新しいインスタンス テンプレート名を使用し、同じワークロードに対するソース インスタンス テンプレートがある場合は、それも含めてください。

    ./asm_vm create_gce_instance_template \
    NEW_ASM_INSTANCE_TEMPLATE \
    --project_id PROJECT_ID \
    --cluster_location CLUSTER_LOCATION \
    --cluster_name CLUSTER_NAME \
    --workload_name WORKLOAD_NAME \
    --workload_namespace WORKLOAD_NAMESPACE \
    --source_instance_template SOURCE_INSTANCE_TEMPLATE
    
  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. asm_vm スクリプトを使用して、新しいインスタンス テンプレートを作成します。アプリケーションの更新のためにインスタンス テンプレートを作成した場合は、新しいインスタンス テンプレート名を使用し、新しいソース インスタンス テンプレートを含めてください。

    ./asm_vm create_gce_instance_template \
    NEW_ASM_INSTANCE_TEMPLATE \
    --project_id PROJECT_ID \
    --cluster_location CLUSTER_LOCATION \
    --cluster_name CLUSTER_NAME \
    --workload_name WORKLOAD_NAME \
    --workload_namespace WORKLOAD_NAMESPACE \
    --source_instance_template NEW_SOURCE_INSTANCE_TEMPLATE
    
  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. 自動サイドカー インジェクションを有効にするには、次のコマンドを使用して、istiod のラベルを検出します。これには、後のステップで使用するリビジョン ラベルの値が含まれます。

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

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

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

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

  3. リビジョン ラベルを default Namespace に適用します。次のコマンドにおいて、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. プロダクト ページにアクセスできることを確認します。

    export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    export INGRESS_PORT=$(kubectl -n istio-system 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 をインストールする起動スクリプトを含む Compute Engine インスタンス テンプレートを作成し、起動時にレーティング データベースを追加します。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
    
    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.9/samples/bookinfo/src/mysql/mysqldb-init.sql
    
    mysql -u root -ppassword < mysqldb-init.sql
    EOF
    
    gcloud compute \
    --project=PROJECT_ID \
    instance-templates create mysql-instance-template \
    --machine-type=e2-medium \
    --metadata-from-file=startup-script=init-mysql \
    --image=debian-10-buster-v20201014 \
    --image-project=debian-cloud \
    --boot-disk-size=10GB
    

    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
    
    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.9/samples/bookinfo/src/mysql/mysqldb-init.sql
    
    mysql -u root -ppassword < mysqldb-init.sql
    EOF
    
    gcloud compute \
    --project=PROJECT_ID \
    instance-templates create mysql-instance-template \
    --machine-type=e2-medium \
    --metadata-from-file=startup-script=init-mysql \
    --image-project=centos-cloud \
    --image-family=centos-8 \
    --boot-disk-size=30GB
    
  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. 上述の VM スクリプトを使用して新しいインスタンス テンプレートを作成し、メッシュ用のインスタンスを準備します。

    ./asm_vm create_gce_instance_template \
    asm-mysql-instance-template \
    --project_id PROJECT_ID \
    --cluster_location CLUSTER_LOCATION \
    --cluster_name CLUSTER_NAME \
    --workload_name mysql \
    --source_instance_template mysql-instance-template
    
  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 サービスを作成します。

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

    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] の順にクリックします。メッシュで実行されているサービスのテーブルが表示されます。追加したサービスは、テーブルに表示され、VMType 値といくつかの上位レベルの指標がついています。VM ベースのサービスの他のテレメトリーを表示するには、サービス名をクリックします。これにより、サービスレベルのダッシュボードが表示されます。

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

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 istio-system
    

    出力:

    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 クラスタなど)間のアクセスを制御します。

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

次の認可ポリシーは、Kubernetes ワークロードの ratingsratings 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 のトラブルシューティング サポートをご覧ください。