概要

このラボでは、Google Kubernetes Engine に Cloud Service Mesh（CSM）をインストールする方法を学びます。Cloud Service Mesh は、トップクラスのオープンソース サービス メッシュである Istio をベースとしたマネージド サービスです。

サービス メッシュは、マイクロサービスの接続、保護、管理を行うためのフレームワークを提供します。これにより、サービスコードを変更しなくても、高度なロード バランシング機能、サービス間の認証、モニタリングなどの機能を備えたネットワーキング レイヤを Kubernetes で利用できるようになります。

Cloud Service Mesh は、信頼性の高い安全なサービスを一元的にモニタリングおよび管理するための充実した機能とツールを備えています。このラボでは、次の機能の使用方法についても学びます。

• メッシュの GKE クラスタ内の HTTP(S) トラフィックに関して、サービスの指標とログが自動的に Google Cloud に取り込まれる。
• 事前構成されたサービス ダッシュボードで、サービスを理解するための必要な情報を確認できる。
• 詳細なテレメトリーで指標とログを詳しく分析し、さまざまな属性に基づきデータをフィルタ、スライスできる。
• サービス同士の関係が可視化されるため、サービスの接続関係、依存関係を理解するのに役立つ。
• サービスレベル目標（SLO）によって、サービスの状態についての分析情報を得られる。サービスの状態に関する独自の基準を使用して SLO とアラートを簡単に定義できる。

豊富な機能を備えた Cloud Service Mesh を利用することで、Istio ベースのサービス メッシュを GKE Enterprise クラスタ上に簡単に実装できます。

目標

このラボでは、次のタスクの実行方法について学びます。

• Cloud Service Mesh をインストールし、トレースを有効にして、バックエンドとして Cloud Trace を使用するように構成する。
• Istio 対応のマルチサービス アプリケーションである Bookinfo をデプロイする。
• Istio Ingress Gateway を使用して外部アクセスを有効にする。
• Bookinfo アプリケーションを使用する。
• Google Cloud 内の Cloud Trace の機能を使用して、サービス パフォーマンスを評価する。
• サービスレベル目標（SLO）を作成してモニタリングする。
• Cloud Service Mesh のダッシュボードを利用して、サービスのパフォーマンスを把握する。

設定と要件

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. Qwiklabs にシークレット ウィンドウでログインします。

2. ラボのアクセス時間（例: 1:15:00）に注意し、時間内に完了できるようにしてください。
   一時停止機能はありません。必要な場合はやり直せますが、最初からになります。

3. 準備ができたら、[ラボを開始] をクリックします。

4. ラボの認証情報（ユーザー名とパスワード）をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。

5. [Google Console を開く] をクリックします。

6. [別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
   他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。

7. 利用規約に同意し、再設定用のリソースページをスキップします。

最初のログイン手順を完了すると、プロジェクト ダッシュボードが表示されます。

8. [プロジェクトを選択] をクリックして GCP プロジェクト ID をハイライト表示したら、[開く] をクリックしてプロジェクトを選択します。

Google Cloud Shell の有効化

Google Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: gcloud ドキュメントの全文については、 gcloud CLI の概要ガイド をご覧ください。 注: ラボ環境の一部は構成済みです。gke という名前の GKE クラスタがすでに作成され、登録されています。

タスク 1. Cloud Service Mesh をインストールしてトレースを有効にする

gke という名前の Google Kubernetes Engine（GKE）クラスタがすでに作成され、登録されています。このクラスタに Cloud Service Mesh をインストールし、標準の構成をオーバーライドして、オプションのトレース コンポーネントを有効にします。

kubectl のクラスタ アクセスを構成してクラスタを検証する

スクリプトで使用する環境変数を設定するために、Cloud Shell で次のコマンドを実行します。

1. 名前の環境変数を設定します。

   CLUSTER_NAME=gke

2. ゾーンとリージョンの環境変数を設定します。

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}} CLUSTER_REGION={{{ project_0.default_region| "Region added at lab start" }}}

3. プロジェクト ID の環境変数を設定します。

   PROJECT_ID={{{ project_0.project_id | "PROJECT ID added at lab start" }}}

4. プロジェクト番号の環境変数を設定します。

   PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} \ --format="value(projectNumber)")

5. フリート プロジェクト ID の環境変数を設定します。

   FLEET_PROJECT_ID="${PROJECT_ID}"

6. IDNS の環境変数を設定します。

   IDNS="${PROJECT_ID}.svc.id.goog"

7. 出力ディレクトリを設定します。

   DIR_PATH=.

8. 環境変数が正しく設定されていることを確認します。

   printf '\nCLUSTER_NAME:'$CLUSTER_NAME'\nCLUSTER_ZONE:'$CLUSTER_ZONE'\nPROJECT_ID:'$PROJECT_ID'\nPROJECT_NUMBER:'$PROJECT_NUMBER'\nFLEET PROJECT_ID:'$FLEET_PROJECT_ID'\nIDNS:'$IDNS'\nDIR_PATH:'$DIR_PATH'\n'

   出力:

   CLUSTER_NAME:gke CLUSTER_ZONE:{{{ project_0.default_zone| "Zone" }}} PROJECT_ID:{{{ project_0.project_id | "PROJECT ID" }}} PROJECT_NUMBER:946429310725 FLEET PROJECT_ID:{{{ project_0.project_id | "PROJECT ID" }}} IDNS:{{{ project_0.project_id | "PROJECT ID" }}}.svc.id.goog DIR_PATH:.

9. GKE クラスタを管理するように kubectl を構成します。

   gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $PROJECT_ID

10. kubectl の構成を確認します。

    kubectl config view

出力:

apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://34.67.123.27 name: gke_qwiklabs-gcp-04-6163e6198bad_{{{ project_0.default_zone }}}_gke contexts: - context: cluster: gke_qwiklabs-gcp-04-6163e6198bad_{{{ project_0.default_zone }}}_gke user: gke_qwiklabs-gcp-04-6163e6198bad_{{{ project_0.default_zone }}}_gke name: gke current-context: gke kind: Config preferences: {} users: - name: gke_qwiklabs-gcp-04-6163e6198bad_{{{ project_0.default_zone }}}_gke user: auth-provider: config: cmd-args: config config-helper --format=json cmd-path: /usr/lib/google-cloud-sdk/bin/gcloud expiry-key: '{.credential.token_expiry}' token-key: '{.credential.access_token}' name: gcp

11. クラスタが実行されていることを確認します。

gcloud container clusters list

出力:

NAME: gke LOCATION: {{{ project_0.default_zone }}} MASTER_VERSION: 1.24.8-gke.2000 MASTER_IP: 35.192.65.244 MACHINE_TYPE: e2-standard-2 NODE_VERSION: 1.24.8-gke.2000 NUM_NODES: 3 STATUS: RUNNING 注:

GKE の通常のリリース チャンネルを使用してクラスタをインストールしているため、インストールで使用されているマスター バージョンが異なる場合があります。

GKE Enterprise を有効にする

12. コマンドラインから GKE Enterprise を有効にします。これにより、フリート（GKE Hub）API も自動的に有効になります。

gcloud services enable --project="${PROJECT_ID}" \ anthos.googleapis.com

13. gke という名前の GKE クラスタをプロジェクトのフリートに登録します。

gcloud container clusters update gke --enable-fleet --region "${CLUSTER_ZONE}"

14. クラスタがフリートに問題なく登録されたことを確認します。

gcloud container fleet memberships list --project "${PROJECT_ID}"

Cloud Service Mesh をインストールする

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

gcloud container fleet mesh enable --project "${PROJECT_ID}"

16. Cloud Service Mesh コントロール プレーンの自動管理を有効にします。

gcloud container fleet mesh update \ --management automatic \ --memberships gke \ --project "${PROJECT_ID}" \ --location "$CLUSTER_REGION"

17. コントロール プレーンが管理されていることを確認します。

gcloud container fleet mesh describe --project "${PROJECT_ID}"

controlPlaneManagement の状態が PROVISIONING から REVISION_READY に変わるまで待ちます。これには数分かかることがあります。

出力:

createTime: '2024-10-09T08:36:54.101719145Z' membershipSpecs: projects/251431549018/locations/us-east1/memberships/gke: mesh: management: MANAGEMENT_AUTOMATIC membershipStates: projects/251431549018/locations/us-east1/memberships/gke: servicemesh: conditions: - code: VPCSC_GA_SUPPORTED details: This control plane supports VPC-SC GA. documentationLink: http://cloud.google.com/service-mesh/docs/managed/vpc-sc severity: INFO controlPlaneManagement: details: - code: REVISION_READY details: 'Ready: asm-managed' implementation: TRAFFIC_DIRECTOR state: ACTIVE dataPlaneManagement: details: - code: MANAGED_CONTROL_PLANE_REQUIRED details: Requires active managed control plane. state: FAILED_PRECONDITION state: code: OK description: 'Revision ready for use: asm-managed.' updateTime: '2024-10-09T08:46:33.932321311Z' name: projects/qwiklabs-gcp-04-e66a83de81ad/locations/global/features/servicemesh resourceState: state: ACTIVE spec: {} updateTime: '2024-10-09T08:38:23.722727135Z'

18. Cloud Service Mesh を有効にして、テレメトリーを Cloud Trace に送信します。

cat <<EOF | kubectl apply -n istio-system -f - apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: enable-cloud-trace namespace: istio-system spec: tracing: - providers: - name: stackdriver EOF

19. kubectl get configmap で、構成マップが有効になっていることを確認します。

出力:

NAME DATA AGE kube-root-ca.crt 1 48m

お疲れさまでした

これで、GKE クラスタに Cloud Service Mesh がインストールされました。Kubernetes の指標は Cloud Monitoring に、ログは Cloud Logging に記録されます。また、分散トレース情報は Cloud Trace に送信されます。

タスク 2. クラスタにマイクロサービスのデモ アプリケーションをインストールする

Online Boutique はクラウドネイティブ マイクロサービスのデモ アプリケーションであり、10 階層のマイクロサービス アプリケーションで構成されています。ユーザーは、このウェブベース e コマースアプリを使用して、商品の閲覧、カートへの追加、購入を行うことができます。

このアプリケーションは、Google が Kubernetes / GKE、Istio / ASM、Google のオペレーション スイート、gRPC、OpenCensus などのテクノロジーの使用方法を説明する際に使用しているもので、任意の Kubernetes クラスタ（ローカル クラスタなど）と Google Kubernetes Engine で動作します。構成はほとんど必要なく、簡単にデプロイできます。

このアプリケーションの詳細については、GitHub リポジトリをご覧ください。

メッシュ データプレーンを構成する

1. Istio サイドカー インジェクションを有効にします。

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

   出力:

   namespace/default labeled

2. Google 側でデータプレーンを管理してサイドカー プロキシが自動的に更新されるようにするには、Namespace にアノテーションを付けます。

   kubectl annotate --overwrite namespace default \ mesh.cloud.google.com/proxy='{"managed":"true"}'

   出力:

   namespace/default annotated

GKE クラスタに Online Boutique アプリケーションをインストールする

1. アプリケーションをデプロイします。

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml kubectl patch deployments/productcatalogservice -p '{"spec":{"template":{"metadata":{"labels":{"version":"v1"}}}}}'

2. クラスタ外からアプリケーションにアクセスできるよう、Ingress Gateway をインストールします。

   git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages kubectl apply -f anthos-service-mesh-packages/samples/gateways/istio-ingressgateway

3. 必要なカスタム リソース定義をインストールします。

   kubectl apply -k "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.0" kubectl kustomize "https://github.com/GoogleCloudPlatform/gke-networking-recipes.git/gateway-api/config/mesh/crd" | kubectl apply -f -

4. Gateway を構成します。

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/istio-manifests.yaml

5. Kubernetes に戻り、[ワークロード] をクリックします。続けて [ネットワーキング] で [Gateway、Service、Ingress] ページをクリックして、新しい Deployment と Service が GKE クラスタに作成されていることを確認します。

   注: 各ページをクラスタ、オブジェクト タイプ、Namespace でフィルタリングして、提示された情報を解析しやすくすることができます。

6. コンソールと UI を使用し、数分をかけてデモ アプリケーションの詳細を確認します。

   注: ワークロードが OK ステータスを示している場合は、（いずれかのクラスタの）frontend-external Service に関連付けられている IP アドレスを使用して、次のどちらかを行います。
   • コンソールの [Service と Ingress] ページを確認する。
   • Cloud Shell を使用してクラスタを確認する。

7. Cloud Shell を使用して Deployment を表示します。

   kubectl get deployments

   出力:

   NAME READY UP-TO-DATE AVAILABLE AGE adservice 1/1 1 1 2m39s cartservice 1/1 1 1 2m41s checkoutservice 1/1 1 1 2m44s currencyservice 1/1 1 1 2m40s emailservice 1/1 1 1 2m45s frontend 1/1 1 1 2m43s istio-ingressgateway 3/3 3 3 2m24s loadgenerator 1/1 1 1 2m41s paymentservice 1/1 1 1 2m42s productcatalogservice 1/1 1 1 2m42s recommendationservice 1/1 1 1 2m43s redis-cart 1/1 1 1 2m39s shippingservice 1/1 1 1 2m40s

8. Cloud Shell を使用して Service を表示します。

   kubectl get services

   出力:

   NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE adservice ClusterIP 10.28.7.144 9555/TCP 7m37s cartservice ClusterIP 10.28.12.9 7070/TCP 7m40s checkoutservice ClusterIP 10.28.15.239 5050/TCP 7m42s currencyservice ClusterIP 10.28.14.145 7000/TCP 7m39s emailservice ClusterIP 10.28.11.181 5000/TCP 7m43s frontend ClusterIP 10.28.1.40 80/TCP 7m41s frontend-external LoadBalancer 10.28.15.84 34.66.85.60 80:31445/TCP 7m41s istio-ingressgateway LoadBalancer 10.28.0.95 34.68.255.184 15021:30153/TCP,80:31266/TCP,443:30286/TCP 7m22s kubernetes ClusterIP 10.28.0.1 443/TCP 62m paymentservice ClusterIP 10.28.1.138 50051/TCP 7m41s productcatalogservice ClusterIP 10.28.8.22 3550/TCP 7m40s recommendationservice ClusterIP 10.28.0.104 8080/TCP 7m42s redis-cart ClusterIP 10.28.5.71 6379/TCP 7m38s shippingservice ClusterIP 10.28.5.69 50051/TCP 7m39s

9. 新しいタブを開き、frontend-external Service の IP アドレスを入力します。

10. さまざまなページをクリックして、アプリケーションの概要を把握します。

タスク 3. Google Cloud のオペレーション スイートの機能を確認する

GKE クラスタまたは Anthos クラスタをインストールするときに、クラスタのログと指標を収集して Cloud Logging と Cloud Monitoring に転送するように設定できます。これにより、クラスタ、ノード、Pod、さらにはクラスタ内のコンテナについて明確に把握できるようになります。ただし、GKE と Anthos はマイクロサービス間の通信をモニタリングしません。

Cloud Service Mesh では、すべてのリクエストが Envoy プロキシを経由するため、マイクロサービスのテレメトリー情報を収集して検査できます。Envoy プロキシ拡張機能は、そのテレメトリーを Google Cloud に送信し、Google Cloud で検査できるようにします。Cloud Trace のダッシュボードを使用して、リクエストとそのレイテンシを調査し、リクエストに関与するすべてのサービスの内訳を取得します。

1. Google Cloud コンソールのナビゲーション メニューで [トレース] をクリックします。

   トレースのグラフには、デモ アプリケーション内で行われたサービス リクエストが表示されます。

2. グラフの上の方に表示されている（全体的なリクエスト時間が長いことを表す）点をクリックします。

• そのリクエストにはどのくらい時間がかかりましたか？
• そのリクエストはいつ発生しましたか？
• どのサービスが呼び出されましたか？
• そのリクエストの実行中に呼び出された他のサービスは何ですか？
• そのリクエストの処理に最も時間がかかった場所はどこですか？

トレース情報の確認の詳細については、Cloud Trace のドキュメントをご覧ください。

タスク 4. レイテンシの高いカナリア リリースをデプロイする

このタスクでは、高レイテンシにつながる問題があるサービスの新しいバージョンをデプロイします。以降の手順では、オブザーバビリティ ツールを使用して診断と解決を行います。

1. Cloud Shell で、このタスクに必要な構成ファイルを含むリポジトリのクローンを作成します。

   git clone https://github.com/GoogleCloudPlatform/istio-samples.git \ ~/istio-samples

2. gke クラスタに新しい宛先ルールを作成します。

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/destinationrule.yaml

3. gke クラスタに新しい商品カタログを作成します。

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/productcatalog-v2.yaml

4. gke クラスタにトラフィック分割を作成します。

   kubectl apply -f ~/istio-samples/istio-canary-gke/canary/vs-split-traffic.yaml 注: 次のものが作成されます。
   • サービス バージョン間のリクエストのルーティングを設定する DestinationRule
   • レイテンシの高い商品カタログ サービスの新しいデプロイ
   • 商品カタログのトラフィックの 75% を v1 に、25% を v2 に分割する VirtualService
   Cloud Shell エディタで各構成ファイルを開くと、新しいリソースそれぞれの定義をより深く理解できます。

タスク 5. サービスレベル目標を定義する

Cloud Service Mesh を使用していない場合は、Service Monitoring API を使用して SLO を定義できます。Cloud Service Mesh を使用している場合、gke クラスタと同様に、Cloud Service Mesh のダッシュボードで SLO の定義とモニタリングを行えます。

1. Google Cloud コンソールのナビゲーション メニューで [Kubernetes Engine] をクリックして GKE のダッシュボードを開きます。

   フリートにクラスタが 1 つ登録されています。

2. サイドパネルの [機能] で [サービス メッシュ] をクリックして、Cloud Service Mesh のダッシュボードに移動します。

   SLO 情報を含むサービス パフォーマンスの概要が表示されます。商品カタログ サービス向けに新しい SLO を定義します。

3. [サービス] リストで、「productcatalogservice」をクリックします。

4. メニューペインで [健全性] をクリックします。

5. [+SLO を作成] をクリックします。

6. [SLI の設定] スライドアウトの [指標] で [レイテンシ] を選択します。

7. 評価方法として [リクエスト ベース] を選択します。

8. [続行] をクリックします。

9. [レイテンシのしきい値] を「1000」に設定し、[続行] をクリックします。

10. [期間の種類] を [カレンダー] に設定します。

11. [期間の長さ] を [1 暦日] に設定します。

    注: 99% の可用性の意味は、対象となる期間が 1 日の場合と 1 か月の場合では異なります。前者の SLO では、連続するダウンタイムが 14 分（24 時間 × 1%）を超えることは許可されませんが、後者の SLO では、連続するダウンタイムがおよそ 7 時間（30 日 × 1%）まで許容されます。

12. [パフォーマンス目標] を「99.5%」に設定します。

    [プレビュー] グラフには、実際の過去のデータと比較した目標の状態が表示されます。

13. [続行] をクリックします。

14. 「表示名: 99.5% - レイテンシ - 1 暦日」となっていることを確認します。

    これは、必要に応じて調整できます。

    自動生成された JSON ドキュメントも表示されます。代わりに API を使用して、今後の SLO の作成を自動化することもできます。

15. SLO を作成するには、[+SLO を作成] をクリックします。

タスク 6. 問題を診断する

サービス指標を使用して問題のある場所を確認する

1. SLO リストで SLO のエントリをクリックします。

   開かれた状態のビューが表示されます。SLO を見ると、おそらくすでにエラー バジェットの範囲を超えているはずです。そうでない場合は、3～5 分ほど待ってからページを更新してください。このサービスに対するリクエストの多くがレイテンシの高い新しいバックエンドに到達するため、いずれエラー バジェットの上限に達します。

2. メニューペインで [指標] をクリックします。

   [指標] ビューの [レイテンシ] セクションまでスクロールすると、数分前、つまりサービスのカナリア バージョンをデプロイした時間からサービス レイテンシが増加したことを確認できます。

3. [データの内訳基準] プルダウンから [ソースサービス] を選択します。

   レイテンシが高く、SLO を満たすことができない根本的な原因となっている Pod はどれでしょうか？

4. サービス メッシュのページに戻るには、メニューペインで [サービス メッシュ] をクリックします。

   1 つの SLO がエラー バジェット超過としてフラグ設定され、[サービス] リストで問題のあるサービスの横に警告インジケーターが表示されています。

   注: ここでは 1 つのサービスに対して 1 つの SLO のみを定義しましたが、実際の本番環境では、多くの場合サービスごとに複数の SLO が設定されます。
   また、ここでは SLO のアラート ポリシーを定義していません。通常であれば、エラー バジェットが予想よりも速く上限に達しそうな場合には Cloud Monitoring でアラートが通知されるよう設定します。

遅延が発生している場所を Cloud Trace で把握する

1. Google Cloud コンソールのナビゲーション メニューで [トレース] > [Trace エクスプローラ] をクリックします。

2. グラフの約 3,000 ミリ秒のところに表示されている点をクリックします。この点は、商品カタログ サービスに対するリクエストの 1 つを表しています。

   すべての時間がカタログ サービス自体で費やされているように見えます。他のサービスの呼び出しも行われていますが、すべてが非常に迅速に応答しているので、商品カタログ サービス内のいずれかの処理に時間がかかっていると思われます。

   注: Cloud Service Mesh は、メッシュ内のネットワーク呼び出しに関する情報を自動的に収集し、これらの呼び出しに費やされた時間を記録するトレースデータを提供します。この機能は便利であることに加えて、デベロッパーによる追加の作業も不要です。
   ただし、ワークロード（この場合は商品カタログ サービス Pod）内で時間がどのように費やされているかは、Istio では計測されません。こうした詳細情報を取得するには、デベロッパーがサービス自体に計測ロジックを追加する必要があります。

タスク 7. リリースをロールバックして改善されるか確かめる

1. Cloud Shell で、宛先ルールのカナリア リリースをロールバックします。

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/destinationrule.yaml

2. Cloud Shell で、商品カタログのカナリア リリースをロールバックします。

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/productcatalog-v2.yaml

3. Cloud Shell で、トラフィック分割のカナリア リリースをロールバックします。

   kubectl delete -f ~/istio-samples/istio-canary-gke/canary/vs-split-traffic.yaml

4. Google Cloud コンソールのナビゲーション メニューで [Anthos] > [サービス メッシュ] をクリックします。

5. 「productcatalogservice」をクリックし、メニューペインで [健全性] をクリックします。

   現在の準拠率を確認します。

6. [指標] をクリックします。

   レイテンシのグラフの時系列データを確認すると、ワークロードの不適切なバージョンをロールバックした時点でレイテンシが低下したことがわかります。

7. [健全性] ページに戻ります。

8. 現在の準拠率の指標を、先ほど確認した指標と比較します。高レイテンシのリクエストがなくなったという事実を反映し、現在の値の方が高くなっているはずです。

タスク 8. Cloud Service Mesh のダッシュボードでメッシュを可視化する

1. ナビゲーション メニューで [Kubernetes Engine] > [サービス メッシュ] をクリックします。

2. 右側に [トポロジ] が表示されます。

   サービス メッシュを表すグラフが表示されます。

   

   このようなトポロジのグラフ全体が表示されない場合は、トポロジのデータがすべて収集されていない可能性があります。このデータがグラフに反映されるまでに 10 分以上かかることがあります。次のセクションに進み、後で戻ってグラフを確認できます。

3. フロントエンド ワークロード ノードをクリックし、そのワークロードによって呼び出されるサービスを確認します。

   

数分かけてさらに詳しく調べ、アプリケーションのアーキテクチャをより深く理解してください。ノードの再配置、ワークロードを構成する Deployment と Pod のドリルダウン表示、期間の変更などを行うことができます。

これで完了です。Google Cloud のオペレーション スイートのツールを使用して、GKE Enterprise クラスタにおけるサービスのパフォーマンスの評価、トラブルシューティング、改善を行いました。

まとめ

このラボでは、Google Cloud のオペレーション スイートを使用したロギング、モニタリング、トレースについて学習しました。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2026 Google LLC All rights reserved. Google および Google のロゴは、Google LLC の商標です。その他すべての社名および製品名は、それぞれ該当する企業の商標である可能性があります。