概要

Cloud Service Mesh は、サービス間通信を管理された状態に保ち、そのオブザーバビリティと安全性を確保するアーキテクチャです。これにより、選択したインフラストラクチャ上に多くのマイクロサービスで構成される堅牢なエンタープライズ アプリケーションを簡単に作成できます。Cloud Service Mesh は、モニタリング、ネットワーキング、セキュリティなど、サービスを実行するための一般的な要件を整合性のある強力なツールで管理します。このため、サービス デベロッパーやオペレーターは、ユーザー向けの優れたアプリケーションの構築と管理に専念しやすくなります。

Cloud Service Mesh のトラフィック管理モデルは、次の 2 つのコンポーネントに依存しています。

• コントロール プレーン: トラフィックをルーティングしてポリシーを適用するように Envoy プロキシを管理、構成します。
• データプレーン: Envoy プロキシによってランタイム時に実行される、マイクロサービス間のすべてのネットワーク通信を処理します。

これらのコンポーネントにより、次のようなメッシュのトラフィック管理機能が有効になります。

• サービス ディスカバリ
• ロード バランシング
• トラフィックのルーティングと制御

目標

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

• Istio ゲートウェイを構成して使用する
• 利用可能なすべてのバージョンに対して、デフォルトの宛先ルールを適用する
• 仮想サービスを適用して、デフォルトで 1 つのバージョンにのみルーティングする
• ユーザー ID に基づいてサービスの特定のバージョンにルーティングする
• マイクロサービスのバージョン間でトラフィックを段階的にシフトする
• Cloud Service Mesh ダッシュボードを使用して、複数のバージョンへのルーティングを確認する
• 再試行、サーキット ブレーカー、タイムアウトなど、ネットワーキングに関するベスト プラクティスの設定を行う

設定と要件

このタスクでは、ラボの初期化手順を行います。

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

1. シークレット ウィンドウを使用して Google Skills にログインします。

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

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

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

5. [Google コンソールを開く] をクリックします。

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 の概要ガイド をご覧ください。

タスク 1. トラフィック管理の使用例を確認する

さまざまな構成オプションを使用して、さまざまなトラフィック管理機能を有効にできます。

例: トラフィック分割

トラフィックを 1 つのサービスの複数のバージョンにルーティングします。

例: タイムアウト

タイムアウト（Istio でリクエストに対するレスポンスを待つ時間）を設定します。 HTTP リクエストのタイムアウトは 15 秒ですが、オーバーライドできます。

例: 再試行

再試行とは、操作が失敗した場合に操作を繰り返し実行することです。 再試行の最大回数（デフォルトのタイムアウト期間内またはオーバーライドしたタイムアウト期間内に操作を試行できる回数）を調整します。

例: フォールト インジェクション: 遅延の挿入

フォールト インジェクションは、システムにエラーを発生させ、システムがエラー状態に耐えて回復できるかどうかを検証するテスト方法です。

この例では、「v1」バージョンの評価マイクロサービスへのリクエストの 10% で 5 秒の遅延が発生します。

例: フォールト インジェクション: 中断の挿入

上の例は、ratings サービス「v1」へのリクエストの 10% に対して HTTP 400 エラーコードを返します。

例: 条件付きルーティング: ソースラベルに基づく

ルールにより、このルーティングが reviews サービスのバージョン v2 を実装するワークロード（Pod）からの呼び出しにのみ適用されることを示すことができます。

例: 条件付きルーティング: リクエスト ヘッダーに基づく

上記のルールは、「end-user」のカスタム ヘッダーに文字列「atharvak」が含まれている受信リクエストにのみ適用されます。

タスク 2. ラボの設定を完了する

このラボ環境の一部分はすでに構成されています。

• gke という名前の GKE クラスタが作成済みです。
• Cloud Service Mesh がインストール済みです。
• Bookinfo マルチサービス サンプル アプリケーションがデプロイ済みです。

kubectl のクラスタ アクセスを構成する

1. Zone 環境変数を設定します。

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

2. Cloud Shell で、クラスタ名の環境変数を設定します。

   export CLUSTER_NAME=gke

3. 次を実行して、kubectl コマンドライン アクセスを構成します。

   export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT

   プロンプトが表示されたら、[承認] ボタンをクリックします。

クラスタと Cloud Service Mesh のインストールを確認する

4. クラスタが稼働していることを確認します。

   gcloud container clusters list

   出力:

   NAME: gke LOCATION: {{{ project_0.default_zone| "Zone" }}} MASTER_VERSION: 1.24.8-gke.2000 MASTER_IP: 35.222.150.207 MACHINE_TYPE: e2-standard-4 NODE_VERSION: 1.24.8-gke.2000 NUM_NODES: 2 STATUS: RUNNING

5. Cloud Service Mesh コントロール プレーン用の Kubernetes Pod がデプロイされていることを確認します。

   kubectl get pods -n asm-ingress

出力:

NAME READY STATUS RESTARTS AGE istio-ingressgateway-69fc5475fd-4wglw 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-stb7x 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-vkxp4 1/1 Running 0 22m

Pod のステータスが Running または Completed になっているはずです。

6. Cloud Service Mesh コントロール プレーンに対応する Kubernetes サービスがデプロイされていることを確認します。

   kubectl get service -n asm-ingress

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 34.118.232.124 34.75.207.190 15021:32645/TCP,80:31091/TCP,443:32092/TCP 30m

Bookinfo のデプロイを確認する

8. アプリケーションが正しくデプロイされていることを確認します。

   kubectl get pods

   出力:

   NAME READY STATUS details-v1-1520924117-48z17 2/2 Running productpage-v1-560495357-jk1lz 2/2 Running ratings-v1-734492171-rnr5l 2/2 Running reviews-v1-874083890-f0qf0 2/2 Running reviews-v2-1343845940-b34q5 2/2 Running reviews-v3-1813607990-8ch52 2/2 Running 注: 各 Pod にコンテナが 2 つあることに注目してください。 これは、アプリケーション コンテナと Istio サイドカー プロキシです。

9. 実行中のアプリケーション サービスを確認します。

   kubectl get services

   出力:

   NAME TYPE CLUSTER-IP EXTERNAL-IP ... details ClusterIP 10.7.248.49 kubernetes ClusterIP 10.7.240.1 productpage ClusterIP 10.7.248.22 ratings ClusterIP 10.7.247.26 reviews ClusterIP 10.7.246.22

タスク 3. ゲートウェイをインストールして Ingress を有効にする

Kubernetes 環境では、Kubernetes Ingress Resource を使用して、クラスタの外部に公開する必要のあるサービスを指定します。しかし、Cloud Service Mesh ではゲートウェイ リソースを使用するほうがよいでしょう。この方法なら Kubernetes や他の環境でも機能します。ゲートウェイを使用すると、クラスタに到着するトラフィックに対して、モニタリング、mTLS、高度なルーティング機能ルールなどのメッシュ機能を適用できます。

ゲートウェイは、L4～L6 の仕様を L7 から分離することにより、Kubernetes Ingress の欠点を克服しています。ゲートウェイでは、L4～L6 の機能（公開するポートや使用するプロトコルなど）を構成します。そして、サービス オーナーが VirtualService をバインドすることで、L7 のトラフィック ルーティング オプション（パス、ヘッダー、重みなどに基づくルーティングなど）を構成します。

ゲートウェイのデプロイには、共有と専用の 2 つのオプションがあります。共有ゲートウェイの場合は、複数のアプリケーション（複数の名前空間に存在する場合もある）で 1 つの集中型ゲートウェイを使用します。次の例の ingress 名前空間のゲートウェイは、ルートの所有権を複数のアプリケーションの名前空間に委任していますが、TLS 構成のコントロールは保持しています。このオプションは、共有の TLS 証明書または共有のインフラストラクチャを使用する場合に有効です。このラボでは、このオプションを使用します。

専用ゲートウェイの場合は、アプリケーションの名前空間ごとに専用ゲートウェイがあるため、単一の名前空間に対して完全なコントロールと所有権を保持します。このオプションは、セキュリティやパフォーマンスのためにアプリケーションを分離する必要がある場合に適しています。

クラスタに Ingress ゲートウェイをインストールする

1. ゲートウェイ用の名前空間を作成します。

   kubectl create namespace ingress

2. ゲートウェイの名前空間に、自動インジェクション用のリビジョン ラベルを付けます。

   kubectl label namespace ingress istio.io/rev=asm-managed --overwrite

   リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたプロキシを特定のコントロール プレーン リビジョンに関連付けます。

   出力の「istio-injection not found」のメッセージは無視してかまいません。これは、今まで名前空間に istio-injection ラベルが付いていなかったことを意味します。サービス メッシュの新規インストールや新規デプロイでは、これは想定される状態です。

   名前空間に istio-injection ラベルとリビジョン ラベルの両方があると自動インジェクションが失敗するため、サービス メッシュ ドキュメント内のすべての kubectl label コマンドは、istio-injection ラベルを削除するようになっています。

3. ゲートウェイ構成ファイルをダウンロードして適用します。これらのファイルには、クラスタ外から到着するリクエストを最初に受信する Pod と Service が指定されています。

cat <<'EOF' > ingress.yaml apiVersion: v1 kind: ServiceAccount metadata: name: istio-ingressgateway namespace: ingress --- apiVersion: v1 kind: Service metadata: name: istio-ingressgateway namespace: ingress labels: app: istio-ingressgateway istio: ingressgateway spec: ports: # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks - name: status-port port: 15021 protocol: TCP targetPort: 15021 # Any ports exposed in Gateway resources should be exposed here. - name: http2 port: 80 - name: https port: 443 selector: istio: ingressgateway app: istio-ingressgateway type: LoadBalancer --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: istio-ingressgateway namespace: ingress rules: - apiGroups: - "" resources: - secrets verbs: - get - watch - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: istio-ingressgateway namespace: ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: istio-ingressgateway subjects: - kind: ServiceAccount name: istio-ingressgateway --- apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: istio-ingressgateway namespace: ingress spec: maxUnavailable: 1 selector: matchLabels: istio: ingressgateway app: istio-ingressgateway --- apiVersion: apps/v1 kind: Deployment metadata: name: istio-ingressgateway namespace: ingress spec: replicas: 1 selector: matchLabels: app: istio-ingressgateway istio: ingressgateway template: metadata: annotations: # This is required to inject the gateway with the # required configuration. inject.istio.io/templates: gateway labels: app: istio-ingressgateway istio: ingressgateway spec: containers: - name: istio-proxy image: auto # The image will automatically update each time the pod starts. serviceAccountName: istio-ingressgateway --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: istio-ingressgateway namespace: ingress spec: maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 minReplicas: 3 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway EOF kubectl apply -n ingress -f ingress.yaml

4. Deployment を作成したら、新しいサービスが正常に動作していることを確認します。

   kubectl get pod,service -n ingress

   リソースは LoadBalancer です。この Ingress ゲートウェイは、GCP の外部 TCP ロード バランサを使用します。

5. ゲートウェイをデプロイして、使用するポートとプロトコルを指定します。この場合、ゲートウェイにより、ポート 80 経由の HTTP トラフィックが有効になります。

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway namespace: ingress spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" EOF

   ゲートウェイのリソースは、ゲートウェイのデプロイメントと同じ名前空間に配置する必要があります。

6. 先ほど作成したゲートウェイの Pod と Service から BookInfo アプリケーションにトラフィックをルーティングする VirtualService をデプロイします。

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - "*" gateways: - ingress/bookinfo-gateway http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080 EOF

   VirtualService リソースは、アプリケーションと同じ名前空間に配置する必要があります。productpage サービスをデフォルトの宛先として設定していることに注目してください。

7. ゲートウェイと VirtualService が作成されたこと、その VirtualService がそのゲートウェイを指し示していることを確認します。

   kubectl get gateway,virtualservice

8. この外部 IP を Cloud Shell 環境に保存します。

   export GATEWAY_URL=$(kubectl get svc -n ingress istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}') echo The gateway address is $GATEWAY_URL

注: ゲートウェイ アドレスが空の場合は、1～2 分待ってからもう一度最後のコマンドを実行してください。$GATEWAY_URL 変数にアドレスが設定されるまで、この操作を繰り返してください。

バックグラウンド トラフィックを生成する

アプリケーションに対してバックグラウンド トラフィックを生成します。これにより、サービス メッシュ ダッシュボードを確認すると興味深いデータが表示されます。

1. Cloud Shell で、負荷生成ツールである siege をインストールします。

   sudo apt install siege

2. siege を使用して、サービスに対してトラフィックを作成します。

   siege http://${GATEWAY_URL}/productpage

BookInfo アプリケーションにアクセスする

1. Cloud Shell のメニューバーで、[+] アイコンをクリックして、別のタブを開きます。

2. Zone 環境変数を設定します。

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

3. 新しい Cloud Shell タブを初期化します。

   export CLUSTER_NAME=gke export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT export GATEWAY_URL=$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ingress)

4. クラスタ内の Pod（ratings など）から curl リクエストを送信して、Bookinfo アプリケーションが応答することを確認します。

   kubectl exec -it \ $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') \ -c ratings -- curl productpage:9080/productpage \ | grep -o "<title>.*</title>"

   出力:

   <title>Simple Bookstore App</title>

5. 以前に保存した外部 IP を使用して、Bookinfo アプリがクラスタの外部から送信された curl リクエストに応答していることを確認します。

   curl -I http://${GATEWAY_URL}/productpage

   出力:

   HTTP/1.1 200 OK content-type: text/html; charset=utf-8 content-length: 5293 server: istio-envoy date: Wed, 01 Feb 2023 13:28:58 GMT x-envoy-upstream-service-time: 27

6. ブラウザで Bookinfo アプリケーションを開きます。Cloud Shell で次のコマンドを実行して、完全な URL を取得します。

   echo http://${GATEWAY_URL}/productpage

これで完了です。Bookinfo の productpage サービスの HTTP エンドポイントが外部トラフィックに公開されました。ゲートウェイ構成リソースを使用すると、サービス メッシュで外部トラフィックを受信できるようになり、エッジ サービスでトラフィック管理とポリシー関連の機能を利用できるようになります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ゲートウェイをインストールして Ingress を有効にする。

タスク 4. サービス メッシュ ダッシュボードを使用して、複数のバージョンへのルーティングを確認する

サービス メッシュ ダッシュボードでデータを確認する際には、いくつかの点に注意する必要があります。

1 つ目は、ほとんどのページでデータが表示されるようになるまで 1〜2 分かかるという点です。つまり、ページにアクセスしても、1〜2 分間は期待するデータが表示されない場合があります。確認したいデータが表示されない場合は、1 分ほど待ってからページを更新してください。

トポロジのページでも、データが初めて表示されるまで大幅な遅延が生じます。最初のデータセットが表示されるまでに 5 分以上かかる場合があります。データが存在しないというメッセージが表示された場合は、しばらく待ってからページを更新し、もう一度トポロジビューにアクセスしてください。

前述のとおり、待つことと、ページを更新することがポイントです。実際のところ、データの受信が遅延するだけでなく、多くの場合、ページを更新しない限りデータが表示されません。このため、データがあるはずなのに表示されない場合は、必ずブラウザでページを更新してください。

テーブルビューでルーティング情報を表示する

1. ナビゲーション メニューで、[Kubernetes Engine] > [機能] > [サービス メッシュ] を選択します。

   

注: トポロジビューが表示されない場合は、ブラウザ ウィンドウを更新してください。

2. productpage サービスをクリックし、左側の [連携サービス] を選択します。

3. [送信] タブを選択し、2 つのサービスが productpage Pod から呼び出されていることを確認します。

4. reviews サービスをクリックします。

   

5. サービス統計を確認し、左側のメニューで [インフラストラクチャ] のリンクを選択します。

さまざまなバージョンの reviews ロジックを実行している複数のポッドが、reviews サービスに送信されたトラフィックを受信していることを確認できます。

6. 左側のメニューで [トラフィック] をクリックし、トラフィック分散の別のビューを表示します。

   

   異なるバージョンのアプリケーション ロジックを実行している 3 つのバックエンド Pod の間で、トラフィックが比較的均等に分散されていることを確認できます。

トポロジビューでルーティング情報を表示する

1. 左上のサービス メッシュのロゴをクリックして、ダッシュボードのメインページに戻ります。

注: グラフに表示するデータがないというエラー メッセージが表示された場合や、あるべきトラフィックが表示されない場合は、1～2 分待ってからもう一度試してみてください。

2. メッシュグラフを再配置することにより、以下を見やすく表示できます。

   • productpage デプロイ行きの productpage サービス
   • reviews サービス行きの productpage デプロイ
   • 3 つのバージョンの reviews 行きの reviews サービス

   

3. reviews サービスノードをクリックし、各バックエンド バージョンの相対 QPS を表示します。

   

タスク 5. 利用可能なすべてのバージョンに対して、デフォルトの宛先ルールを適用する

このタスクでは、サブセットと呼ばれる使用可能なすべてのバージョンを宛先ルールで定義します。

1. GitHub にある構成を確認します。この構成では、4 つの DestinationRule リソース（サービスごとに 1 つ）を定義しています。

2. Cloud Shell で次のコマンドを実行して構成を適用します。

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' destination-rule-all.yaml kubectl apply -f destination-rule-all.yaml

   出力:

   destinationrule.networking.istio.io/productpage created destinationrule.networking.istio.io/reviews created destinationrule.networking.istio.io/ratings created destinationrule.networking.istio.io/details created

3. 4 つの DestinationRule リソースが定義されていることを確認します。

   kubectl get destinationrules

   出力:

   NAME HOST AGE details details 1m productpage productpage 1m ratings ratings 1m reviews reviews 1m

4. 宛先ルールの詳細を確認します。

   kubectl get destinationrules -o yaml

   subsets は DestinationRule の spec で定義されています。

5. 1～2 分待ってから、サービス メッシュ ダッシュボードに戻ります。

6. テーブルビューとトポロジビューの両方を調べて、トラフィックが引き続き 3 つのバックエンド バージョンに均等に分散されていることを確認します。[タイムラインを表示] をクリックして、グラフに表示する期間を調整できます。これにより、関心のあるデータに的を絞って簡単に参照できます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 宛先ルールを適用する。

タスク 6. 仮想サービスを適用して、デフォルトで 1 つのバージョンにのみルーティングする

このタスクでは、各サービスに仮想サービスを適用して、すべてのトラフィックをサービス ワークロードの v1 にルーティングします。

1. GitHub にある構成を確認します。この構成では、4 つの VirtualService リソース（サービスごとに 1 つ）を定義しています。

2. Cloud Shell で次のコマンドを実行して構成を適用します。

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-all-v1.yaml kubectl apply -f virtual-service-all-v1.yaml

   出力:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

   構成の伝播では結果整合性が保たれるため、仮想サービスが有効になるまで数秒かかることがあります。

3. 4 つのルートの VirtualService リソースが定義されていることを確認します。

   kubectl get virtualservices

   出力:

   NAME GATEWAYS HOSTS AGE bookinfo ["ingress/bookinfo-gateway"] ["*"] 19m details ["details"] 6s productpage ["productpage"] 7s ratings ["ratings"] 6s reviews ["reviews"] 7s

4. Cloud Shell で、Ingress ゲートウェイの外部 IP アドレスを取得します。

   echo $GATEWAY_URL

5. Bookinfo UI を使用して、新しいルーティング構成をテストします。

   • ブラウザで Bookinfo サイトを開きます。URL は http://[GATEWAY_URL]/productpage です。[GATEWAY_URL] の部分は Ingress の外部 IP アドレスで置き換えてください。

   • ページを数回更新して、複数のリクエストを発行します。

   何度更新しても、ページの [Book Reviews] の部分に評価の星は表示されません。これは、reviews サービスのすべてのトラフィックを reviews:v1 のバージョンにルーティングするようにメッシュを構成し、このバージョンのサービスは評価サービスにアクセスしないためです。

6. 1～2 分待ってから、ナビゲーション メニュー > [Kubernetes Engine] > [サービス メッシュ] > [reviews] > [インフラストラクチャ] に移動して、サービス メッシュ ダッシュボードをもう一度表示します。

7. [タイムラインを表示] を選択して、チャートの最後の 5 分間のトラフィックに焦点を当てます。均等に分散されていたトラフィックが、バージョン 1 のワークロードに 100％ ルーティングされるようになったことがわかります。

   

   [トラフィック] タブまたはトポロジビューを表示して、新しいトラフィック分布を確認することもできます。ただし、どちらもデータの表示が数分遅れます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 仮想サービスを適用する。

タスク 7. ユーザー ID に基づいてサービスの特定のバージョンにルーティングする

このタスクでは、特定のユーザーからのすべてのトラフィックが特定のサービス バージョンにルーティングされるようにルート構成を変更します。この場合、ユーザー jason からのすべてのトラフィックは、サービス reviews:v2（評価機能のあるバージョン）にルーティングされます。

注: Istio には、ユーザー ID を理解するための特別な機能は組み込まれていません。この例では、productpage サービスで、エンドユーザーのカスタム ヘッダーが reviews サービスへの送信 HTTP リクエストに追加されているため、特定のユーザーを判別することができるのです。

1. GitHub にある構成を確認します。この構成では、1 つの VirtualService リソースを定義しています。

2. Cloud Shell で次のコマンドを実行して構成を適用します。

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-test-v2.yaml kubectl apply -f virtual-service-reviews-test-v2.yaml

   出力:

   virtualservice.networking.istio.io/reviews configured

3. ルールが作成されたことを確認します。

   kubectl get virtualservice reviews

   出力:

   NAME GATEWAYS HOSTS AGE reviews ["reviews"] 35m

4. Bookinfo UI を使用して、新しいルーティング構成をテストします。

   • Bookinfo アプリケーションの /productpage を再度参照します。

   • 今回は、[Sign in] をクリックし、ユーザー名として jason を使用します。パスワードは何でも構いません。

   • UI に評価サービスの星が表示されています。

   ログアウトして、他のユーザーとしてログインしてみることができます。レビュー付きの星は表示されなくなります。

新しいトラフィック ルーティングの影響をよりわかりやすく視覚化するために、サービスへの認証済みリクエストの新しいバックグラウンド ロードを作成できます。

5. 新しい siege セッションを開始し、最初のトラフィックの 20% 分だけトラフィックを生成します。なお、すべてのリクエストは jason として認証されます。

   curl -c cookies.txt -F "username=jason" -L -X \ POST http://$GATEWAY_URL/login cookie_info=$(grep -Eo "session.*" ./cookies.txt) cookie_name=$(echo $cookie_info | cut -d' ' -f1) cookie_value=$(echo $cookie_info | cut -d' ' -f2) siege -c 5 http://$GATEWAY_URL/productpage \ --header "Cookie: $cookie_name=$cookie_value"

6. 1～2 分待ってから、インフラストラクチャ テレメトリーを表示するページを更新し、現在のデータを表示するようにタイムラインを調整してから、サービス メッシュ ダッシュボードを確認します。過去数分間のリクエストの約 85% は未認証であるため、バージョン 1 に送られています。約 15% のリクエストは jason として行われているため、バージョン 2 に送られています。

7. Cloud Shell で Ctrl+C キーを押し、Siege セッションをキャンセルします。

8. アプリケーション仮想サービスを削除して、このタスクをクリーンアップします。

   kubectl delete -f virtual-service-all-v1.yaml

   出力:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

9. 1～2 分待ってから、サービス メッシュ ダッシュボードを更新し、現在のデータを表示するようにタイムラインを調整して、トラフィックがバージョン間で均等に分散されるようになったことを確認します。

   

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ユーザー別のルーティングの構成。

タスク 8. マイクロサービスのバージョン間でトラフィックを段階的にシフトする

このタスクでは、マイクロサービスのあるバージョンから別のバージョンにトラフィックを段階的に移行します。たとえば、このアプローチを使用することにより、古いバージョンから新しいバージョンにトラフィックを移行できます。

トラフィックの 50% を reviews:v1 に、残りの 50% を reviews:v3 に送信します。次に、トラフィックの 100% を reviews:v3 に送信して、移行を完了します。

サービス メッシュでは、一定の割合のトラフィックを特定のサービスにルーティングする一連のルールを構成することにより、この目標を達成できます。

1. Cloud Shell で、すべてのトラフィックを各サービスの v1 バージョンにルーティングします。

   kubectl apply -f virtual-service-all-v1.yaml

   出力:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Bookinfo アプリケーションの /productpage を再度参照し、星付きのレビューが表示されないことを確認します。すべてのトラフィックが v1 バックエンドにルーティングされています。

3. 1 分待ってから、サービス メッシュ ダッシュボードを更新し、現在のデータを表示するようにタイムラインを調整して、すべてのトラフィックが v1 バックエンドにルーティングされていることを確認します。

4. トラフィックの 50% を reviews:v1 から reviews:v3 に転送します。

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-50-v3.yaml kubectl apply -f virtual-service-reviews-50-v3.yaml

   出力:

   virtualservice.networking.istio.io/reviews configured

5. Bookinfo アプリケーションの /productpage を再度参照します。

6. 表示を更新して、複数のリクエストを発行します。

   v1 の星なしのレビューと、ratings サービスにアクセスする v3 の赤色の星付きのレビューが、ほぼ均等に表示されることがわかります。

7. 1 分待ってからページを更新し、現在のデータが表示されるようにタイムラインを調整し、サービス メッシュ ダッシュボードで reviews サービスへのトラフィックが v1 と v3 の間で半々に分割されていることを確認します。

   

8. トラフィックの残りの 50% を reviews:v3 に転送します。

9. reviews:v3 のサービスが安定していると判断した場合、この仮想サービスを適用して、トラフィックの 100% を reviews:v3 にルーティングします。

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking//virtual-service-reviews-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-v3.yaml kubectl apply -f virtual-service-reviews-v3.yaml

   出力:

   virtualservice.networking.istio.io/reviews configured

10. Bookinfo UI を使用して、新しいルーティング構成をテストします。

11. Bookinfo アプリケーションの /productpage を再度参照します。

12. /productpage を更新すると、レビューごとに赤色の星の評価が付いた書評が必ず表示されます。

13. 1 分待ってからページを更新します。サービス メッシュ ダッシュボードで、reviews サービスへのすべてのトラフィックが v3 に送られていることを確認します。

    

14. アプリケーション仮想サービスを削除して、この演習をクリーンアップします。

    kubectl delete -f virtual-service-all-v1.yaml

    出力:

    virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

このタスクでは、サービス メッシュの重み付けルーティング機能を使用して、reviews サービスの古いバージョンから新しいバージョンにトラフィックを移行しました。これは、コンテナ オーケストレーション プラットフォームのデプロイ機能（インスタンス スケーリングを使用してトラフィックを管理）を使用してバージョンを移行する場合とは大きく異なります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 トラフィックを v1 から v3 に移行する。

タスク 9. タイムアウトを追加して、サービスの応答を無期限に待機しないようにする

HTTP リクエストのタイムアウトは、ルートルールの timeout フィールドを使用して指定できます。デフォルトでは、リクエストのタイムアウトは無効になっていますが、このタスクでは reviews サービスのタイムアウトをオーバーライドして 1 秒に設定します。また、この効果を確認するために、ratings サービスへの呼び出しに対して人為的に 2 秒の遅延を挿入します。まず、遅延を挿入します。

1. Cloud Shell で、すべてのトラフィックを各サービスの v1 バージョンにルーティングします。

   kubectl apply -f virtual-service-all-v1.yaml

   出力:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. リクエストを reviews サービスの v2（ratings サービスを呼び出すバージョン）にルーティングします。

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 EOF

3. ratings サービスへの呼び出しに 2 秒の遅延を追加します。

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: delay: percent: 100 fixedDelay: 2s route: - destination: host: ratings subset: v1 EOF

4. ブラウザで Bookinfo の URL http://$GATEWAY_URL/productpage を開きます。Bookinfo アプリケーションは正常に動作するものの（評価の星が表示される）、ページを更新するたびに 2 秒の遅延が発生するはずです（Bookinfo アプリケーションが正常に動作しない場合は、遅延を 1 秒に変更してもう一度お試しください）。

5. reviews の指標に移動して、レイテンシが 2 秒に急増していることを確認します（遅延を 1 秒に変更した場合は、レイテンシが 1 秒に急増します）。

   

6. 次に、reviews サービスへの呼び出しに 0.5 秒のリクエスト タイムアウトを追加します。

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 timeout: 0.5s EOF

7. Bookinfo ウェブページを更新します。

2 秒ではなく約 1 秒で戻り、レビューが表示されなくなります。

注: タイムアウトを 0.5 秒に構成したのに、レスポンスに 1 秒かかる理由は、productpage サービスに再試行がハードコードされているためです。そのため、レスポンスを返す前に、reviews サービスを 2 回呼び出してタイムアウトしています。再試行の設定を変更する場合は、次のコマンドを実行して VirtualService を構成します。 kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: productpage spec: hosts: - productpage http: - route: - destination: host: productpage subset: v1 retries: attempts: 1 perTryTimeout: 2s EOF

8. アプリケーション仮想サービスを削除して、この演習をクリーンアップします。

   kubectl delete -f virtual-service-all-v1.yaml

   出力:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

このタスクでは、Istio を使用して、reviews マイクロサービスへの呼び出しのリクエスト タイムアウトを 0.5 秒に設定しました。デフォルトでは、リクエスト タイムアウトは無効になっています。reviews サービスはリクエストの処理時に ratings サービスを呼び出すので、Istio を使用して ratings　の呼び出しに 2 秒の遅延を挿入し、reviews サービスが完了するまでに 0.5 秒以上かかるようにして、タイムアウトの動作を確認できるようにしました。

レビューが表示される代わりに、Bookinfo の商品ページ（このページが reviews サービスを呼び出してページにデータを入力します）に「Sorry, product reviews are currently unavailable for this book」（申し訳ございませんが、この書籍のレビューは現在ご利用いただけません）というメッセージが表示されることが確認できました。これは、reviews サービスからタイムアウト エラーを受け取った結果です。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ratings サービスのタイムアウトを追加する。

タスク 10. サーキット ブレーカーを追加してマイクロサービスの復元力を高める

このタスクでは、接続、リクエスト、外れ値検出のサーキット ブレーカーを構成する方法について説明します。

サーキット ブレーカーは、復元力のあるマイクロサービス アプリケーションを作成するための重要な手法です。サーキット ブレーカーを使用すると、障害、レイテンシの急増、ネットワーク異常によるその他の望ましくない効果の影響を抑えることのできるアプリケーションを作成できます。

このタスクでは、サーキット ブレーカー ルールを構成し、サーキット ブレーカーを意図的に発動させて構成をテストします。

1. Cloud Shell で、すべてのトラフィックを各サービスの v1 バージョンにルーティングします。

   kubectl apply -f virtual-service-all-v1.yaml

   出力:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. productpage サービスを呼び出すときにサーキット ブレーカー設定を適用する宛先ルールを作成します。

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: productpage spec: host: productpage subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutive5xxErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100 EOF

3. Cloud Shell で、最初のタブに移動し、Ctrl+C キーを実行して siege を停止します。

4. productpage サービスにトラフィックを送信するクライアントを作成します。

このクライアントは、fortio という名前のシンプルな負荷テスト用クライアントです。fortio を使用すると、送信 HTTP 呼び出しの接続数、同時実行数、遅延を制御できます。このクライアントを使用して、DestinationRule で設定したサーキット ブレーカー ポリシーを発動させます。

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/httpbin/sample-client/fortio-deploy.yaml

5. クライアントの Pod にログインし、fortio ツールを使用して productpage を呼び出します。1 回だけ呼び出すことを示すために curl を渡します。

   export FORTIO_POD=$(kubectl get pods -lapp=fortio -o 'jsonpath={.items[0].metadata.name}') kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio curl -quiet http://${GATEWAY_URL}/productpage

6. 2 つの同時接続（-c 2）でサービスを呼び出し、20 個のリクエスト（-n 20）を送信します。

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://${GATEWAY_URL}/productpage

   興味深いことに、ほとんどすべてのリクエストが成功します。maxConnections: 1 と http1MaxPendingRequests: 1 であるのに、興味深い結果です。これらのルールは、同時接続数と同時リクエスト数が 1 を超えたら、istio-proxy がそれ以降のリクエストと接続に対してサーキットを遮断し、エラーが返されることを意味します。

   しかし、istio-proxy には多少の余裕があるようです。

   Code 200 : 17 (85.0 %) Code 503 : 3 (15.0 %)

7. 同時接続数を 3 に増やします。

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://${GATEWAY_URL}/productpage

   これで、サーキット ブレーカーが期待どおりに動作するようになります。リクエストの 36.7% のみが成功し、残りはサーキット ブレーカーによってトラップされました。

   Code 200 : 11 (36.7 %) Code 503 : 19 (63.3 %)

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 サーキット ブレーカーを追加する。

確認

このラボでは、目的に応じてトラフィックを管理およびルーティングする、さまざまな方法について学びました。また、レイヤ 7、アプリケーション レイヤ、リクエスト ヘッダーによるルーティングなど、目的に応じてトラフィックのシフトを調整および表示する方法についても学びました。

次のステップ

• Istio のトラフィック管理についてのページをご覧ください。
• Istio を使用したカナリア デプロイについてのページをご覧ください。

ラボを終了する

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

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

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

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

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

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

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