Anthos Service Mesh 1.9 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

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 のようなものです。
そのうえで、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 サービスを作成することもできます。

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 オンボーディング用のスクリプトをダウンロードする方法について説明します。

Anthos Service Mesh 1.9.8 の VM スクリプトを、現在の作業ディレクトリにダウンロードします。
```
curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm
```
現在の作業ディレクトリにファイルの SHA-256 をダウンロードします。
```
curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9.sha256 > asm_vm.sha256
```
両方のファイルを同じディレクトリに置いて、ダウンロードを検証します。
```
sha256sum -c --ignore-missing asm_vm.sha256
```
検証が成功すると、コマンドは asm_vm: OK を出力します。

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

スタートガイド

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

環境の設定

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

注: クラスタがリージョンクラスタの場合は、--zone ではなく --region を使用します。
```
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

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

VM 自動登録を有効化: PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION 変数を true に設定することで有効になります。VM 自動登録が有効になると、新しい VM インスタンスは WorkloadGroup に登録され、新しい WorkloadEntry CR が作成されて、VM にトラフィックが転送されるようになります。デフォルトでは、install_asm を使用してインストールされたすべての Anthos Service Mesh 1.9 以降のコントロールプレーンで VM 自動登録が有効にされます。
Expansion ゲートウェイのインストール: このゲートウェイは、eastwest ゲートウェイという名前で、Anthos Service Mesh 構成ファイルパッケージに定義されています。また、このインストールにより、コントロールプレーンが VM に公開されます。
IdentityProvider CRD のインストールと Google IdentityProvider CR の登録を行い、VM が Anthos Service Mesh コントロールプレーンを認証して、他のサービスメッシュと安全に通信できるようにします。
install_asm スクリプトで --enable_all または --enable_registration を使用する場合は、クラスタをフリートに登録し、Workload Identity を有効にします。
フリート内で Service Mesh 機能を有効にします。この機能により、VM がメッシュと安全に通信するために必要なポリシーが管理されます。

VM の追加

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

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

続く手順で使用する環境変数を設定します。これらの変数は、VM ワークロードごとに設定します。
- WORKLOAD_NAME は、VM が属しているワークロードの名前です。小文字の英数字で構成される DNS-1123 準拠のサブドメインを指定する必要があります。
- WORKLOAD_VERSION は、VM が属しているワークロードのバージョンです。省略可。
- WORKLOAD_SERVICE_ACCOUNT は、VM が実行されるサービスの GCP サービスアカウントです。
- WORKLOAD_NAMESPACE は、ワークロードの名前空間です。
- ASM_INSTANCE_TEMPLATE は、作成されるインスタンステンプレートの名前です。Compute Engine インスタンステンプレート名にアンダースコアは使用できません。
- SOURCE_INSTANCE_TEMPLATE は、生成されたテンプレートに基づくテンプレート名です。省略可。
VM ワークロードの Namespace をまだ作成していない場合は作成します。
```
kubectl create ns WORKLOAD_NAMESPACE
```
コントロールプレーンのリビジョンで Namespace にラベルを付けます。次の例で REVISION と示されているコントロールプレーンのリビジョンを見つける方法の例については、ワークロードのデプロイと再デプロイをご覧ください。
```
kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```

登録する 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 のサービスアカウントを抽出する場所をコントロールプレーンに指示します。

次のオプションとフラグを使用して 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`	オプション、フラグ、終了を説明するヘルプメッセージを表示します。

作成する 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 は、ワークロードの名前空間です。
前の手順で作成した変数を使用して、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 として登録されます。
MIG 内の VM インスタンスが起動すると、次のコマンドを使用して、ワークロードの名前空間に登録されている VM を表示できます。
```
   kubectl get workloadentry -n WORKLOAD_NAMESPACE
```
注: WorkloadGroup または IdentityProvider カスタムリソースが削除されると、VM はメッシュと通信できなくなります。
先に追加した 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 をご覧ください。
VM でサンプルアプリケーションを使用するには、サンプルアプリケーションをデプロイするをご覧ください。

Anthos Service Mesh コントロールプレーンのアップグレード

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

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

次のコマンドを使用して、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 です。
リビジョンラベルを名前空間に追加し、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 ラベルの削除が含まれています。
asm_vm スクリプトを使用して、新しいインスタンステンプレートを作成します。新しいインスタンステンプレート名を使用し、同じワークロードに対するソースインスタンステンプレートがある場合は、それも含めてください。

注: --source_instance_template フラグは省略できます。ソーステンプレートがある場合は、フラグ指定します。ソーステンプレートがない場合、フラグは含めないでください。
```
./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
```
既存の MIG に対してワークロードのローリングアップデートを実行します。

詳細については、基本的なローリングアップデートの開始をご覧ください。
```
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE
```
VM ワークロードをテストして、想定どおりに動作することを確認します。

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

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

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

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
```
既存の MIG に対してワークロードのローリングアップデートを実行します。MIG ローリングアップデートの利用方法の詳細については、基本的なローリングアップデートの開始をご覧ください。
```
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE
```
VM ワークロードをテストして、想定どおりに動作することを確認します。

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

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

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

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

Anthos Service Mesh をインストールした PC のコマンドラインで、スクリプトのダウンロードの手順で作成した Anthos Service Mesh インストールディレクトリのルートに移動します。
自動サイドカーインジェクションを有効にするには、次のコマンドを使用して、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 です。
リビジョンラベルを 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 ラベルの削除が含まれています。
kubectl を使用してアプリケーションをデフォルトの名前空間にデプロイします。
```
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
```

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

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

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

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

予想される出力:

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

プロダクトページにアクセスできることを確認します。

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

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

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

上述の 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

新しく作成したインスタンステンプレートを使用して、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 サービスを作成します。

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

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

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

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

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

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

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

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

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

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

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 です。

アプリケーションの実行

curl で BookInfo アプリが実行されていることを確認します。
```
curl -I http://EXTERNAL_IP/productpage
```
レスポンスに 200 が示されている場合、アプリケーションが Anthos Service Mesh と正しく連動しています。
BookInfo ウェブページを表示するには、ブラウザに次のアドレスを入力します。
```
http://EXTERNAL_IP/productpage
```
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 ワークロードの 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 のトラブルシューティングサポートをご覧ください。

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

はじめに

仕組み

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

制限事項

前提条件

クラスタ

CLI ツール

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

スタートガイド

環境の設定

クラスタの準備

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

インストール済み

VM の追加

Anthos Service Mesh コントロール プレーンのアップグレード

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

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

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

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

Debian

CentOS

サービスの作成

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

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

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

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

アプリケーションの実行

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

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

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

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

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

トラブルシューティング

Anthos Service Mesh コントロールプレーンのアップグレード

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

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