このページでは、Compute Engine VM を Google Kubernetes Engine(GKE)の Anthos Service Mesh に追加する方法について説明します。このページでは、VM を追加するクラスタを準備するオプションを使用して、Anthos Service Mesh 1.11.8 をインストールする方法について説明します。
Anthos Service Mesh 1.9 or a 1.10 patch release がすでにインストールされている場合は、このページで説明するように、VM の追加に必要なオプションを使用して、Anthos Service Mesh 1.11.8 にアップグレードします。
Anthos Service Mesh 1.9 を使用しており、アップグレードを行わない場合は、Anthos Service Mesh 1.9 ガイドで VM を Anthos Service Mesh 1.9 に追加する手順をご覧ください。
以前のバージョンの Anthos Service Mesh を使用している場合は、まず Anthos Service Mesh を 1.9 以降にアップグレードする必要があります。
このページでは、クラスタ内コントロール プレーンまたは Google マネージド コントロール プレーンをインストールするためのコマンドラインについて説明します。
はじめに
Anthos Service Mesh を使用すると、マネージド インスタンス グループ(MIG)で実行されているサービスを、メッシュ内の Google Kubernetes Engine(GKE)クラスタで実行されているサービスと併せて管理、監視、保護できます。これにより、メッシュ内で Compute Engine インスタンスを使用して次のことができるようになります。
- トラフィックを管理する。
- mTLS を適用する。
- サービス トラフィックにアクセス制御を適用する。
- Google Cloud サービスに安全にアクセスする。
- 指標、ロギング、トレースデータを収集する。
- Google Cloud コンソールを使用してサービスをモニタリングする。
これにより、コンテナ化に適さない、またはコンテナ化の準備ができていない以前のアプリケーションが、Anthos Service Mesh の機能を活用でき、ワークロードを残りのサービスと統合できるようになります。
仕組み
Anthos Service Mesh には、仮想マシンのワークロードを表す 2 つの関連するカスタム リソース定義(CRD)があります。
WorkloadGroup
は、共通のプロパティを共有する仮想マシン ワークロードの論理グループを表します。これは、Kubernetes における Deployment のようなものです。WorkloadEntry
は、仮想マシンのワークロードの単一のインスタンスを表します。これは、Kubernetes における Pod のようなものです。- そのうえで、
Service
はWorkloadGroup
を選択して、Pod
への転送と同様の方法で、Anthos Service Mesh がトラフィックを 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 は、同一ネットワークで同一プロジェクト内にあり、単一のネットワーク インターフェースを使用しなければなりません。
- この機能は Anthos のサブスクリプションがなくても使用できますが、Google Cloud Console の UI 要素や機能の中には Anthos のサブスクライバーのみが使用できるものがあります。サブスクライバーと非サブスクライバーが使用できる機能については、Anthos と Anthos Service Mesh の UI の違いをご覧ください。
- Google マネージドのコントロール プレーンとデータプレーンの両方をクラスタにデプロイできますが、VM 上のプロキシは Google マネージド データプレーンによって管理されません。
前提条件
始める前に:
前提条件で、Cloud プロジェクト、Anthos ライセンス、一般的な要件を確認します。
クラスタ要件
続行する前に、クラスタが GKE の要件を満たしていることを確認してください。さらに、Anthos Service Mesh VM のサポートには、以下のことが必要です。
- Anthos Service Mesh をインストールするときに、Mesh CA を認証局(CA)として指定する。
- テレメトリー用に Stackdriver をオーバーライドしない。Anthos Service Mesh をインストールすると、デフォルトで Stackdriver が構成されます。
- クラスタがフリートに登録されている。クラスタが登録されていない場合は、VM のインストール プロセスにより、指定のプロジェクトにクラスタが登録されます。
始める
使ってみるの手順に沿って、以下を行ってください。
Anthos Service Mesh がインストールされていない場合は、次のセクションに進みます。Anthos Service Mesh がすでにインストールされている場合は、既存のインストールの手順を行います。
新規インストール
Anthos Service Mesh 1.11 のコントロール プレーンを準備することで、VM 用の Anthos Service Mesh クラスタをセットアップします。クラスタにインストールする 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 を追加してください。
マネージド サービス メッシュ
次のコマンドを使用して、VM を追加するコントロール プレーンを準備する --option vm
を使用して、Anthos Service Mesh の Google マネージド コントロール プレーンをデプロイします。その他の利用可能なオプションの詳細については、Google マネージド コントロール プレーンを適用するをご覧ください。マネージド Anthos Service Mesh のドキュメントでは、asmcli install
ではなく install_asm
スクリプトを使用していますが、どちらのインストール スクリプトでも同じオプションを指定します。
./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 \
--managed
--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 を追加するクラスタを準備します。--managed
: Google マネージド コントロール プレーンをデプロイします。
既存のインストール
クラスタに Anthos Service Mesh がすでにインストールされている場合は、次の手順を行います。
まだ行っていない場合は、クラスタをフリートに登録します。
次のコマンドを実行して、Anthos Service Mesh のインストールされている環境が VM ワークロードに対応できるよう準備して確認します。クラスタ内と Google マネージドの両方のコントロール プレーンに同じコマンドを実行します。
./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.
このコマンドは、次のことを行います。
クラスタ内
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 自動登録がデフォルトで有効になります。Expansion ゲートウェイのインストール: このゲートウェイは、
eastwest
ゲートウェイという名前で、Anthos Service Mesh 構成ファイル パッケージに定義されています。また、このインストールにより、コントロール プレーンが VM に公開されます。IdentityProvider
CRD のインストールと GoogleIdentityProvider
CR の登録を行い、VM が Anthos Service Mesh コントロール プレーンを認証して、他のサービス メッシュと安全に通信できるようにします。asmcli
スクリプトで--enable_all
または--enable_registration
を使用する場合は、クラスタをフリートに登録し、Workload Identity を有効にします。フリート内で
Service Mesh
機能を有効にします。この機能により、VM がメッシュと安全に通信するために必要なポリシーが管理されます。
マネージド サービス メッシュ
VM の自動登録を有効にする: すべての Anthos Service Mesh の Google マネージド コントロール プレーンでは、VM の自動登録がデフォルトで有効になります。
IdentityProvider
CRD のインストールと GoogleIdentityProvider
CR の登録を行い、VM が Anthos Service Mesh の Google マネージド コントロール プレーンを認証して、他のサービス メッシュと安全に通信できるようにします。asmcli
スクリプトで--enable_all
または--enable_registration
を使用する場合は、クラスタをフリートに登録し、Workload Identity を有効にします。フリート内で
Service Mesh
機能を有効にします。この機能により、VM がメッシュと安全に通信するために必要なポリシーが管理されます。
Ingress ゲートウェイをインストールする
Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。
Ingress ゲートウェイの名前空間をまだ作成していない場合は作成します。ゲートウェイはユーザー ワークロードであり、コントロール プレーンの名前空間にデプロイすることはおすすめしません。
GATEWAY_NAMESPACE
は、名前空間の名前に置き換えます。kubectl create namespace GATEWAY_NAMESPACE
ゲートウェイの名前空間にリビジョン ラベルを適用することで、ゲートウェイで自動インジェクションを有効にします。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたプロキシを特定のコントロール プレーン リビジョンに関連付けます。使用するリビジョン ラベルは、マネージド Anthos Service Mesh をデプロイしたか、クラスタ内コントロール プレーンをデプロイしたかによって異なります。
クラスタ内
次のコマンドを使用して、
istiod
のリビジョン ラベルを探します。kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
リビジョン ラベルを名前空間に適用します。次のコマンドで、
REVISION
は前の手順でメモしたistiod
リビジョン ラベルの値です。kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION --overwrite
マネージド サービス メッシュ
asm-managed
リビジョン ラベルを名前空間に適用します。kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=asm-managed --overwrite
このラベルは、Anthos Service Mesh バージョンの現在のマネージド Anthos Service Mesh のリリース チャンネルに対応します。
出力中のメッセージ
"istio-injection not found"
は無視します。これは、今までは名前空間にistio-injection
ラベルが付いていなかったことを意味します。Anthos Service Mesh の新規インストールや新規デプロイでは、こうなって当然です。名前空間にistio-injection
とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべてのkubectl label
コマンドにはistio-injection
ラベルの削除が含まれています。samples/gateways/istio-ingressgateway/
ディレクトリにある Ingress ゲートウェイ構成のサンプルをそのままデプロイするか、必要に応じて変更します。kubectl apply -n GATEWAY_NAMESPACE \ -f DIR_PATH/samples/gateways/istio-ingressgateway
ゲートウェイのベスト プラクティスの詳細を確認してください。
VM の追加
このセクションでは、gcloud
で作成したインスタンス テンプレートに基づいて、Compute Engine インスタンスをメッシュに追加します。gcloud
は、サービス プロキシ エージェントに必要な構成のみを生成します。インスタンス テンプレートに構成を追加するには、gcloud
リファレンス ガイドをご覧ください。
VM をメッシュに追加する手順は次のとおりです。
続く手順で使用する環境変数を設定します。これらの変数は、VM ワークロードごとに設定します。
- WORKLOAD_NAME は、VM が属しているワークロードの名前です。小文字の英数字で構成される DNS-1123 準拠のサブドメインを指定する必要があります。
- WORKLOAD_VERSION は、VM が属しているワークロードのバージョンです。省略可。
- WORKLOAD_SERVICE_ACCOUNT は、VM が実行されるサービスの GCP サービス アカウントです。
- WORKLOAD_NAMESPACE は、ワークロードの名前空間です。
- ASM_INSTANCE_TEMPLATE は、作成されるインスタンス テンプレートの名前です。Compute Engine インスタンス テンプレート名にアンダースコアは使用できません。
VM ワークロードの Namespace をまだ作成していない場合は作成します。
kubectl create ns WORKLOAD_NAMESPACE
コントロール プレーンのリビジョンで名前空間にラベルを付けます。
クラスタ内
次の例で REVISION と示されているコントロール プレーンのリビジョンを見つける方法の例については、ワークロードのデプロイと再デプロイをご覧ください。
kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
マネージド サービス メッシュ
次の例のリビジョン
asm-managed
の設定方法については、アプリケーションのデプロイをご覧ください。kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=asm-managed --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 のサービス アカウントを抽出する場所をコントロール プレーンに指示します。--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
作成する 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
先に追加した 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 をアップグレードし、クラスタで実行されているワークロードがある場合は、それらを新しいコントロール プレーンに切り替えます。
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-1118-4-85d86774f7-flrt2 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7 istiod-asm-1118-4-85d86774f7-tcwtn 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7
出力の
LABELS
列の下で、接頭辞istio.io/rev=
に続く、新しいバージョンのistiod
リビジョン ラベルの値をメモします。この例での値はasm-1118-4
です。古い
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
ラベルの削除が含まれています。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
既存の 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 に対してローリング アップデートを実行します。
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
既存の 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 インストール ディレクトリのルートに移動します。
自動サイドカー インジェクションを有効にするには、Anthos Service Mesh コントロール プレーンの種類に応じて手順を選択します。
クラスタ内
次のコマンドを使用して、
istiod
のラベルを見つけます。このラベルには、後のステップで使用するリビジョン ラベルの値が含まれます。kubectl -n istio-system get pods -l app=istiod --show-labels
出力は次のようになります。
NAME READY STATUS RESTARTS AGE LABELS istiod-asm-1118-4-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586 istiod-asm-1118-4-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586
出力の
LABELS
列で、接頭辞istio.io/rev=
に続くistiod
リビジョン ラベルの値をメモします。この例での値はasm-1118-4
です。マネージド サービス メッシュ
asm-managed
リビジョンを使用して VM を追加します。リビジョン ラベルを
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
ラベルの削除が含まれています。マネージド サービス メッシュ
kubectl label namespace default istio-injection- istio.io/rev=asm-managed --overwrite
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
プロダクト ページにアクセスできることを確認します。次のコマンドで、
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 をご覧ください。
起動スクリプトを作成して 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.11/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.11/samples/bookinfo/src/mysql/mysqldb-init.sql mysql -u root -ppassword < mysqldb-init.sql EOF
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
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
新しく作成したインスタンス テンプレートを使用して、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 Console での 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 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
です。
アプリケーションの実行
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 のトラブルシューティング サポートをご覧ください。