以前の Service Mesh バージョン v1.19 のドキュメントを表示しています。

利用可能なバージョン

Cloud Service Mesh
1.24 アーカイブ
 1.23 アーカイブ
 1.22 アーカイブ
 1.21 アーカイブ
 1.20 アーカイブ
 1.19 アーカイブ
 1.18 アーカイブ

Cloud Service Mesh と gcloud CLI を使用して GKE クラスタを作成する

このチュートリアルでは、Google Kubernetes Engine（GKE）Fleet API を使用して、新しい GKE パブリッククラスタでマネージド Cloud Service Mesh をプロビジョニングします。このチュートリアルでは、次の手順について説明します。

Google Cloud プロジェクトを構成する。
Cloud Service Mesh で必要な最小数の vCPU で GKE クラスタを作成する。
プロジェクトのフリートに GKE クラスタを登録する。
Fleet API を使用してクラスタにマネージド Cloud Service Mesh をプロビジョニングする。
Ingress ゲートウェイをデプロイしてアプリケーションを公開する。
サンプルアプリケーションをデプロイして、 Google Cloud コンソールの Cloud Service Mesh ダッシュボードにテレメトリーデータを表示できるようにする。
サンプルアプリケーションを公開してアクセスする。

Fleet API

このガイドは、GKE クラスタおよび一緒に管理できる他のリソースの論理グループであるフリートに精通していることを前提としています。フリートは GKE の概念であり、Kubernetes の概念ではありません。クラスタをフリートに登録すると、gcloud container fleet mesh update コマンドを使用して、そのクラスタにマネージド Cloud Service Mesh をプロビジョニングできます。このチュートリアルを始める際に有効にする Fleet API（gkehub.googleapis.com）により、フリートの使用が有効になります。

費用

このドキュメントでは、課金対象である次の Google Cloudコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新規の Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このクイックスタートの終了後、クラスタを削除するとそれ以上の請求が発生しなくなります。詳細については、クリーンアップをご覧ください。

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the GKE, Fleet (GKE Hub), and Cloud Service Mesh APIs.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the GKE, Fleet (GKE Hub), and Cloud Service Mesh APIs.

Enable the APIs

プロジェクト ID をメモします。
ヒント: をクリックして、プレースホルダ PROJECT_ID にプロジェクト ID を入力します。
このチュートリアルで使用する gcloud コマンドの一部では、プロジェクト ID が必要になります。このドキュメントページを終了したり、別のページに移動しない限り、このページでは、プロジェクト ID を必要とする各コマンドのプロジェクト ID のプレースホルダが更新されます。プレースホルダを使用しているので、コマンドをコピーしてコマンドラインに簡単に貼り付けることができます。リンクを開く場合は、プレースホルダの値を保持するために、新しいタブを開いてください。

必要なツールをインストールする

このツールは、Cloud Shell またはローカルマシンで実行できます。Cloud Shell で必要なすべてのツールがプリインストールされます。

Cloud Shell

Cloud Shell は、Debian ベースの Linux オペレーティングシステムを実行している g1-small Compute Engine 仮想マシン（VM）をプロビジョニングします。Cloud Shell を使用する利点は次のとおりです。

Cloud Shell には、gcloud、kubectl、git、必要な他のコマンドラインツールが含まれています。
Cloud Shell の $HOME ディレクトリには 5 GB の永続ストレージスペースがあります。
テキストエディタを選択できます。
- コードエディタ。Cloud Shell ウィンドウの上部にあるをクリックしてアクセスします。
- Emacs、Vim、Nano。Cloud Shell のコマンドラインからアクセスします。

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

ローカル PC

次のツールがインストールされていることを確認してください。
Google Cloud CLI で認証します。
```
gcloud auth login --project PROJECT_ID
```
コンポーネントを更新します。
```
gcloud components update
```

GKE クラスタを作成する

次のコマンドを実行して、Cloud Service Mesh に必要な最小数の vCPU でクラスタを作成します。コマンドのプレースホルダを次の情報に置き換えます。

CLUSTER_NAME: クラスタの名前。名前には、小文字の英数字と - のみを使用できます。先頭には英字、末尾には英数字を使用し、40 文字以下にする必要があります。
PROJECT_ID: クラスタが作成されるプロジェクト ID。
CLUSTER_LOCATION: クラスタのゾーン（us-central1-a など）。

gcloud container clusters create CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION \
    --machine-type=e2-standard-4 \
    --num-nodes=2 \
    --workload-pool=PROJECT_ID.svc.id.goog

クラスタの作成には数分かかります。クラスタの作成中、gcloud コマンドから次の内容が出力されます。

Creating cluster CLUSTER_NAME in CLUSTER_LOCATION...working...

作成に成功すると、次のような出力が表示されます。

Creating cluster CLUSTER_NAME in CLUSTER_LOCATION...done.
Created [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/CLUSTER_LOCATION/clusters/CLUSTER_NAME].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/CLUSTER_LOCATION/CLUSTER_NAME?project=PROJECT_ID
kubeconfig entry generated for CLUSTER_NAME.
NAME: CLUSTER_NAME
LOCATION: CLUSTER_LOCATION
MASTER_VERSION: 1.20.10-gke.1600
MASTER_IP: 198.51.100.1
MACHINE_TYPE: e2-standard-4
NODE_VERSION: 1.20.10-gke.1600
NUM_NODES: 2
STATUS: RUNNING

クラスタとのやり取りに必要な認証情報を取得します。

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

予想される出力:

Fetching cluster endpoint and auth data.
kubeconfig entry generated for CLUSTER_NAME.

kubectl の現在のコンテキストをクラスタに設定します。
```
kubectl config set-context CLUSTER_NAME
```
予想される出力:
```
Context "CLUSTER_NAME" created.
```

ヒント: 今後のシェル環境を簡単に設定できるように、クラスタ名、クラスタのロケーション、プロジェクト ID を格納する環境変数を作成し、新しいシェルの起動時に source するシンプルなシェルスクリプトに追加できます。Cloud Shell を使用している場合、非アクティブな状態が 20 分以上継続すると切断されるため、シェルスクリプトの追加や .bashrc のカスタマイズは特に有効です。また、kubeconfig ファイルが正しいクラスタを参照するように、

gcloud container clusters
get-credentials

コマンドを追加することもできます。

Cloud Service Mesh をプロビジョニングする

クラスタを作成してからこのページを閉じていない場合、プレースホルダには、gcloud container clusters create コマンドに入力した値が設定されています。

ヒント: クラスタの名前とロケーションを取得する必要がある場合は、gcloud container clusters list --project PROJECT_ID を実行します。

プロジェクトのフリートで Cloud Service Mesh を有効にします。

gcloud container fleet mesh enable --project PROJECT_ID

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

Waiting for Feature Service Mesh to be created...done.

プロジェクトのフリートにクラスタを登録します。

gcloud container fleet memberships register CLUSTER_NAME-membership \
  --gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME \
  --enable-workload-identity \
  --project PROJECT_ID

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

 Waiting for membership to be created...done.
 Finished registering to the Fleet.

Fleet API を使用して、クラスタにマネージド Cloud Service Mesh をプロビジョニングします。
```
gcloud container fleet mesh update \
  --management automatic \
  --memberships CLUSTER_NAME-membership \
  --project PROJECT_ID
```
出力は次のようになります。
```
Waiting for Feature Service Mesh to be updated...done.
```
注: マネージド Cloud Service Mesh は、サービスメッシュのアップグレード、スケーリング、保護に関連する多くの手動メンテナンスを処理します。マネージド Cloud Service Mesh の詳細をご覧ください。

クラスタでマネージド Cloud Service Mesh が有効になり、使用可能な状態になっていることを確認します。

gcloud container fleet mesh describe --project PROJECT_ID

Cloud Service Mesh がプロビジョニングされ、クラスタで使用可能な状態になるまでに 10 分ほどかかることがあります。controlPlaneManagement.state: DISABLED または controlPlaneManagement.state: PROVISIONING が表示された場合は、controlPlaneManagement.state: ACTIVE が表示されるまで、数分ごとに前のコマンドを再実行する必要があります。

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

createTime: '2022-07-06T01:05:39.110120474Z'
membershipSpecs:
  projects/123456789123/locations/global/memberships/your-cluster-membership:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/123456789123/locations/global/memberships/your-cluster-membership:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
      updateTime: '2022-07-06T01:19:24.243993678Z'
name: projects/your-project-id/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
state:
  state: {}
updateTime: '2022-07-06T01:19:27.475885687Z'

サンプルコードをダウンロードする

このチュートリアルで使用するサンプルコードを含む git リポジトリのクローンを作成します。

   git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

このチュートリアルの以降のセクションでは、DIR_PATH 変数を使用します。クローンを作成した anthos-service-mesh-packages リポジトリのパス（例: ./anthos-service-mesh-packages）にこの変数を設定します。

Ingress ゲートウェイをデプロイする

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

Ingress ゲートウェイの名前空間をまだ作成していない場合は作成します。ゲートウェイはユーザーワークロードであり、コントロールプレーンの名前空間にデプロイすることはおすすめしません。GATEWAY_NAMESPACE は、名前空間の名前に置き換えます。
```
kubectl create namespace GATEWAY_NAMESPACE
```
予想される出力:
```
namespace/GATEWAY_NAMESPACE created
```
ゲートウェイで自動挿入を有効にします。必要な手順は、ゲートウェイの Namespace でデフォルトのインジェクションラベル（例: istio-injection=enabled）とリビジョンラベルのどちらを使用するかによって異なります。デフォルトのリビジョンタグとリビジョンラベルは、サイドカーインジェクタ Webhook によって使用され、挿入されたプロキシを特定のコントロールプレーンのリビジョンに関連付けます。
デフォルトのインジェクションラベル
注: デフォルトのタグリビジョンを使用してゲートウェイでの自動挿入を有効にした場合は、--output_dir で指定したディレクトリにデフォルトタグが存在することと、新しくインストールされたリビジョンを参照していることを確認します。コマンド istioctl tag list を実行します。
デフォルトのインジェクションラベルを名前空間に適用します。
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection=enabled istio.io/rev-
```
リビジョンラベル
1. 次のコマンドを使用して、istiod のリビジョンラベルを探します。
  kubectl get deploy -n istio-system -l app=istiod -o \ "jsonpath={.items[*].metadata.labels['istio\.io/rev']}{'\n'}"
  このコマンドは、Cloud Service Mesh バージョンに対応するリビジョンラベル（asm-11910-9 など）を出力します。
2. リビジョンラベルを Namespace に適用します。次のコマンドで、REVISION は前の手順でメモした istiod リビジョンラベルの値です。
  kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev=REVISION --overwrite
  予想される出力:
  namespace/GATEWAY_NAMESPACE labeled
出力中のメッセージ "istio.io/rev" not found は無視します。このメッセージは、今まで Namespace に istio.io/rev ラベルが付いていなかったことを意味しており、Cloud Service Mesh の新規インストールや新規デプロイでは想定される状態です。Namespace に istio.io/rev と istio-injection の両方のラベルがあると自動挿入が失敗するため、Cloud Service Mesh ドキュメント内のすべての kubectl label コマンドで両方のラベルを明示的に指定します。

ゲートウェイの Namespace にラベルが付いていないと、ゲートウェイが auto イメージを pull するときに istio-ingressgateway Pod が ImagePullBackOff エラーで失敗します。このイメージは Webhook で置き換える必要があります。
anthos-service-mesh-packages リポジトリからサンプルの Ingress ゲートウェイ .yaml 構成ファイルをダウンロードします。

サンプルの Ingress ゲートウェイ .yaml 構成をそのまま適用するか、必要に応じて変更します。

kubectl apply -n GATEWAY_NAMESPACE \
  -f CONFIG_PATH/istio-ingressgateway

予想される出力:

deployment.apps/istio-ingressgateway created
poddisruptionbudget.policy/istio-ingressgateway created
horizontalpodautoscaler.autoscaling/istio-ingressgateway created
role.rbac.authorization.k8s.io/istio-ingressgateway created
rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
service/istio-ingressgateway created
serviceaccount/istio-ingressgateway created

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

Online Boutique のサンプルをデプロイする

anthos-service-mesh-packages リポジトリの Online Boutique サンプルアプリケーションは、microservices-demo リポジトリの元のマニフェストセットから変更されています。ベストプラクティスに従い、各サービスは、一意のサービスアカウントを持つ個別の名前空間にデプロイします。

アプリケーションの名前空間を作成します。

kubectl apply -f \
  DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces

予想される出力:

namespace/ad created
namespace/cart created
namespace/checkout created
namespace/currency created
namespace/email created
namespace/frontend created
namespace/loadgenerator created
namespace/payment created
namespace/product-catalog created
namespace/recommendation created
namespace/shipping created

自動サイドカーインジェクション（自動挿入）を有効にします。必要なコマンドは、デフォルトのインジェクションラベル（istio-injection=enabled など）を使用するか、Ingress ゲートウェイ Namespace にアノテーションを付けるのに使用したリビジョンラベルを使用するかによって異なります。

デフォルトのインジェクションラベル

デフォルトのインジェクションラベルを Namespace に適用します。次のコマンドで、GATEWAY_NAMESPACE は、Ingress ゲートウェイ名前空間にアノテーションを付ける際に使用した値です。

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns istio-injection=enabled istio.io/rev-
done;

予想される出力:

namespace/ad labeled
namespace/cart labeled
namespace/checkout labeled
namespace/currency labeled
namespace/email labeled
namespace/frontend labeled
namespace/loadgenerator labeled
namespace/payment labeled
namespace/product-catalog labeled
namespace/recommendation labeled
namespace/shipping labeled

リビジョンラベル

アプリケーションの名前空間にリビジョンラベルを適用します。次のコマンドで、REVISION は、Ingress ゲートウェイ Namespace にアノテーションを付ける際に使用した値です。

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns istio.io/rev=REVISION --overwrite
done;

予想される出力:

namespace/ad labeled
namespace/cart labeled
namespace/checkout labeled
namespace/currency labeled
namespace/email labeled
namespace/frontend labeled
namespace/loadgenerator labeled
namespace/payment labeled
namespace/product-catalog labeled
namespace/recommendation labeled
namespace/shipping labeled

サンプルアプリケーションをクラスタにデプロイします。

サービスアカウントとデプロイを作成します。

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments

予想される出力:

serviceaccount/ad created
deployment.apps/adservice created
serviceaccount/cart created
deployment.apps/cartservice created
serviceaccount/checkout created
deployment.apps/checkoutservice created
serviceaccount/currency created
deployment.apps/currencyservice created
serviceaccount/email created
deployment.apps/emailservice created
serviceaccount/frontend created
deployment.apps/frontend created
serviceaccount/loadgenerator created
deployment.apps/loadgenerator created
serviceaccount/payment created
deployment.apps/paymentservice created
serviceaccount/product-catalog created
deployment.apps/productcatalogservice created
serviceaccount/recommendation created
deployment.apps/recommendationservice created
serviceaccount/shipping created
deployment.apps/shippingservice created

サービスを作成します。

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/services

予想される出力:

service/adservice created
service/cartservice created
service/checkoutservice created
service/currencyservice created
service/emailservice created
service/frontend created
service/frontend-external created
service/paymentservice created
service/productcatalogservice created
service/recommendationservice created
service/shippingservice created

サービスエントリを作成します。

kubectl apply -f \
 DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml

予想される出力:

serviceentry.networking.istio.io/allow-egress-googleapis created
serviceentry.networking.istio.io/allow-egress-google-metadata created

アプリケーションの公開とアクセス

アプリケーションを公開するには、いくつかの方法があります。このガイドでは、上記でデプロイした Ingress ゲートウェイを使用します。Online Boutique アプリケーションを公開するその他の方法については、Online Boutique サンプルアプリケーションのデプロイガイドのアプリケーションの公開とアクセスのセクションをご覧ください。

フロントエンドサービス用の Gateway と VirtualService をデプロイします

kubectl apply -f \
    DIR_PATH/samples/online-boutique/istio-manifests/frontend-gateway.yaml

予想される出力:

gateway.networking.istio.io/frontend-gateway created
virtualservice.networking.istio.io/frontend-ingress created

Ingress ゲートウェイの外部 IP アドレスを取得します。プレースホルダは、次の情報に置き換えます。
- GATEWAY_SERVICE_NAME: Ingress ゲートウェイサービスの名前。変更せずにサンプルゲートウェイをデプロイした場合は、istio-ingressgateway になります。
- GATEWAY_NAMESPACE: Ingress ゲートウェイをデプロイした名前空間。
```
kubectl get service GATEWAY_SERVICE_NAME \
    -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 です。
ブラウザでアプリケーションに移動して、インストールを確認します。
```
http://EXTERNAL_IP/
```

サービスメッシュダッシュボードを表示する

サイドカープロキシが挿入されたクラスタにワークロードをデプロイすると、 Google Cloud コンソールの Cloud Service Mesh ページで、Cloud Service Mesh が提供するすべてのオブザーバビリティ機能を確認できます。ワークロードをデプロイした後、Google Cloud コンソールにテレメトリーデータが表示されるまでに 1～2 分ほどかかります。

Google Cloud コンソールでの Cloud Service Mesh へのアクセスは、Identity and Access Management（IAM）によって制御されます。Cloud Service Mesh のページにアクセスするには、プロジェクトオーナーがユーザーに対してプロジェクト編集者または閲覧者のロール、またはより限定的なロール（ Google Cloud コンソールでの Cloud Service Mesh に対するアクセスを制御するを参照）を付与する必要があります。

Google Cloud コンソールで、[Cloud Service Mesh] に移動します。

[Cloud Service Mesh] に移動する
メニューバーのプルダウンリストから Google Cloud プロジェクトを選択します。
複数のサービスメッシュがある場合は、[サービスメッシュ] プルダウンリストからメッシュを選択します。

詳細については、 Google Cloud コンソールでの Cloud Service Mesh の確認をご覧ください。

クリーンアップ

クリーンアップの前に、相互 TLS の詳細を確認される場合は、Cloud Service Mesh の例: mTLS をご覧ください。

クラスタを維持して Online Boutique のサンプルを削除するには:

アプリケーションの名前空間を削除します。

kubectl delete -f DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces

予想される出力:

namespace "ad" deleted
namespace "cart" deleted
namespace "checkout" deleted
namespace "currency" deleted
namespace "email" deleted
namespace "frontend" deleted
namespace "loadgenerator" deleted
namespace "payment" deleted
namespace "product-catalog" deleted
namespace "recommendation" deleted
namespace "shipping" deleted

サービスエントリを削除します。

kubectl delete -f DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml

予想される出力:

serviceentry.networking.istio.io "allow-egress-googleapis" deleted
serviceentry.networking.istio.io "allow-egress-google-metadata" deleted

追加料金の発生を回避するには、クラスタを削除します。
1. 次のコマンドを実行します。
```
gcloud container clusters delete CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION
```
2. [Do you want to continue (Y/n)?] というプロンプトが表示されたら「y」と入力します。
  
  数分後、次の出力が表示されます。
```
Deleting cluster CLUSTER_NAME...done.
Deleted [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/CLUSTER_LOCATION/clusters/CLUSTER_NAME].
```

次のステップ

マネージド Cloud Service Mesh の詳細については、マネージド Cloud Service Mesh のプロビジョニングをご覧ください。
このチュートリアルで使用した gcloud CLI の簡単な概要については、gcloud コマンドをご覧ください。
Google Cloud コンソールで Cloud Service Mesh を確認する方法については、 Google Cloud コンソールでの Cloud Service Mesh の確認をご覧ください。
Cloud Trace、Distroless プロキシイメージ、エンドユーザー認証などの Cloud Service Mesh オプション機能については、マネージド Cloud Service Mesh でオプション機能を有効にするをご覧ください。
Cloud Service Mesh のセキュリティの詳細については、Cloud Service Mesh のセキュリティの概要と Cloud Service Mesh のセキュリティのベストプラクティスをご覧ください。
Cloud Service Mesh のテレメトリーの詳細については、オブザーバビリティの概要をご覧ください。

Cloud Service Mesh と gcloud CLI を使用して GKE クラスタを作成する

Fleet API

費用

始める前に

必要なツールをインストールする

Cloud Shell

ローカル PC

GKE クラスタを作成する

Cloud Service Mesh をプロビジョニングする

サンプルコードをダウンロードする

Ingress ゲートウェイをデプロイする

デフォルトのインジェクション ラベル

リビジョン ラベル

Online Boutique のサンプルをデプロイする

デフォルトのインジェクション ラベル

リビジョン ラベル

アプリケーションの公開とアクセス

サービス メッシュ ダッシュボードを表示する

クリーンアップ

次のステップ

デフォルトのインジェクションラベル

リビジョンラベル

デフォルトのインジェクションラベル

リビジョンラベル

サービスメッシュダッシュボードを表示する