অ্যান্থোস সার্ভিস মেশ ওয়ার্কশপ: ল্যাব গাইড - জাপানিজ

1. আলফা ওয়ার্কশপ

ワークショップ কোডল্যাব へのリンク: bit.ly/asm-workshop-jp

2. 概要

アーキテクチャ図

9a033157f44308f3.png

このワークショップは、GCPでグローバルグローバルに分散されたサービスをクショップロヷスをプロダる方法を体験する、実践的なハンズオンですす。 Google Kubernetes ইঞ্জিন （GKE）と、セキュアな接続、可観測性、高度なトラフィック操作を実現するIstioサービスメ. " .

এজেন্ডা

TODO - চূড়ান্ত ব্রেকডাউন সহ আপডেট

前提条件

ワークショップを進める前に、下記の事項が必要となります:

  1. GCP組織リソース
  2. 請求先アカウントID (あなたがこのアカウントの請求先アカウント管理カウント管理者であタ
  3. 組織レベルに対してのঅর্গানাইজেশন অ্যাডমিনিস্ট্রেটর IAMロール

3. インフラストラクチャセットアップ - 管理者用ワークフロー

ワークショップ作成スクリプトの説明

bootstrap_workshop.shというスクリプトを使用して、ワークショップの初期環境を構築、トアップできます.

ワークショップ作成スクリプトは下記の情報が必要です:

  • 組織名(উদাহরণ। yourcompany.com )- これはあなたがワークショップ環境を作成する組織のすす
  • 請求先アカウントID (উদাঃ। 12345-12345-12345 ) - このIDがワークショッププで作成されウプで作成求先として使われます.
  • ワークショップ番号(例। 01 ) - 2桁の数字।れらを個別に管理したい場合に使用されますワークショップ番号は〭にも使用されます。 個別のワークショップ番号を使用すると、毎回一意しやすくなります.用されます。 日付とワークショップ番号の組み合わせにより、一意のプロジェクトIDが提供।
  • ユーザー の 開始 番号(例1番号が10となります
  • ユーザーの終了番号(例। 10 ) - ,の終了番号が10となります.号と終了番号は同じです。これにより、単一の環境が構築されます.
  • 管理用 GCS バケット(উদাঃ। my-gcs-bucket-name ) -に使用されます。その情報はcleanup_workshop.shプト中に作成されたすべてのリソースを適切に削除するために使われます।成する管理者は、このバケットに対する読み取り/書き込み権限が必要।

ワークショップ作成スクリプトは上記の値を使用し、 setup-terraform-admin-project.shスクリププースクリプトとして機能します.します.

ワークショップの作成に必要な管理者権限

このワークショップには2種類のユーザMY_USERがいますす.1および削除するADMIN_USER 、2番目はMY_USERで、ワークショップの手順を実行しまな聪すスのみにএডমিন_ইউজার,プを作成する場合、 ADMIN_USERとADMIN_USER MY_USER同じとなりますあなたが複数学生のたたを作成するインストラクターである場合 , ADMIN_USERとMY_USERは異なります৷

ADMIN_USERには次の組織レベルの権限が必要です:

  • -
  • ,ェクト内のすべてのリソースを含む単一のフォルダを取得します।
  • 組織の管理者
  • プロジェクト作成者- 組織内にプロジェクトを作成する権限।
  • プロジェクトの削除- 組織内のプロジェクトを削除する権限।
  • প্রকল্প IAM 管理者- 組織内のすべてのプロジェクトに IAM のルールを作成する権限।

ADMIN_USER要があります.

ワークショップを実行するユーザースキーマと権限

MY_USERー命名ルールに従う必要がありますああります.ザーの終了番号を指定しますこれらの番号は、次のようにユーザー名を作成するために使用:

  • user<3桁のユーザー番号>@<組織名>

、 、 、 、 、 、 という で 、 ユーザー の 開始 番号 1 および ユーザー ユーザー 終了 番号 3 で ワーク ショップ 作成 スクリプト を 実行 する と 、 に に 名 名 ワーク ショップ 環境 環境 環境 が。。。。。。。。。。。。。。

  • user001@yourcompany.com
  • user002@yourcompany.com
  • user003@yourcompany.com

これら ユーザー ユーザー 名 に 、 、 সেটআপ_টরফর্ম_এডমিন_প্রজেক্ট.শ スクリプト で 作成 さ れ た の 所有 者 ロール ロール が ワーク ワーク ワーク ワーク は は 、 は は は は は は は は は は は は は は は は は は は とき とき とき とき ときとき とき とき とき とき とき ときで複数のユーザーを一度に追加する方法を参照してください.

ワークショップで必要なツール群

このワークショップはক্লাউড শেল から実行されることを想定しています.ークショップで必要となります.

ワークショップのセットアップ (単一ユーザーセットアップ)

  1. ক্লাউড শেল を開き、以降の作業を Cloud Shell 上で実行します。 ক্লাউড শেল .

ক্লাউড শেল

  1. 想定している管理者ユーザーで gcloud にログインしていることを確認します.
gcloud config list
  1. WORKDIR
mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
  1. ワークショップに使用する組織名、請求アカウントআইডি আমি
gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
  1. bootstrap_workshop.shスクリプトを実行します。
cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin

bootstrap_workshop.shダ内に、 টেরাফর্ম必要な残りのGCPリソースを作成するために使用されます。 terraform管理プロジェクトで必要なAPIを有効なAPIを有効にしますdiforを適用します. ক্লাউড বিল্ড Google ক্লাউড স্টোরেজてのGCPリソースのTerraform স্টেটসを保存します.

টেরাফর্ম 管理プロジェクトでCloud Buildタスクを表示するには、Terraform管理しロジェクトID.ワークショップ作成スクリプトで指定された管理用GCSーに対してワークショップ作成スクリプトスクリプトを実行する場合、すべてててリププロジェククトててててジェククトまぱジェクトIDはCS .

  1. 管理用GCSバケットからworkshop.txtファイルを取得して、terraformプロジェクトIDを叁得。 
export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .

ワークショップのセットアップ (複数ユーザーセットアップ)

  1. ক্লাউড শেল を開き、以降の作業を Cloud Shell 上で実行します。 ক্লাউড শেল .

ক্লাউড শেল

  1. 想定している管理者ユーザーで gcloud にログインしていることを確認します.
gcloud config list
  1. ওয়ার্কডাইর
mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
  1. ワークショップに使用する組織名、請求アカウントআইডি আমি
gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
  1. bootstrap_workshop.shスクリプトを実行します。
cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}
  1. 管理用GCSバケットからworkshop.txtファイルを取得して、terraformプロジェクトIDを叁得。 
export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .

4. インフラストラクチャ セットアップ - ユーザーワークフロー

所要時間: 1時間

目標: インフラストラクチャとIstioのインストールを確認する

  • ワークショップで利用するツールをインストール
  • ワークショップ用リポジトリをクローン
  • Infrastructure
  • k8s-repoのインストールを確認
  • Istioのインストールを確認

ユーザー情報の取得

ワークショップをセットアップする管理者は、ユーザー名とパスワー名とパスワーる提供する必要がありますのすべてのユーザーのプロジェクトには、 user001@yourcompany.com @yourcompany.レフィックスとして追加され、terraform管理プロジェクトID user001-200131-01-tf-abcdeできます.

ワークショップで必要なツール群

このワークショップはক্লাউড শেল から実行されることを想定しています.ークショップで必要となります.

টেরাফর্ম 管理プロジェクトへのアクセス

bootstrap_workshop.shダ内に、 টেরাফর্ম必要な残りのGCPリソースを作成するために使用されます. setup-terraform-admin-project.shします. ক্লাউড বিল্ডはTerraform পরিকল্পনাを適用するために使用されます。 ক্লাউড বিল্ড , আমিバケットに構成されます.

টেরাফর্ম 管理プロジェクトでCloud Buildタスクを表示するには、Terraform管理しロジェクトID.ワークショップ作成スクリプトで指定された管理用GCSーに対してワークショップ作成スクリプトスクリプトを実行する場合、すべてててリププロジェククトててててジェククトまぱジェクトIDはCS .

  1. ক্লাউড শেল を開き、以降の作業を Cloud Shell 上で実行します。 ক্লাউড শেল .

ক্লাউড শেল

  1. কাস্টমাইজ করুন を$HOME/binにインストールし（未インストールの場合）、 $HOME/binを $PATH に加えます.
mkdir -p ${HOME}/bin
cd bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd ${HOME}
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:${HOME}/bin" >> ~/.bashrc
  1. pv をインストールし、セッション上で設定を永続化するためにそれを.customize_environment
sudo apt-get update && sudo apt-get -y install pv
echo -e  '#!/bin/sh' >> $HOME/.customize_environment
echo -e "apt-get update" >> $HOME/.customize_environment
echo -e "apt-get -y install pv" >> $HOME/.customize_environment
  1. 想定しているユーザーで gcloud にログインしていることを確認します।
gcloud config list
  1. ওয়ার্কডাইর
mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
cd asm
  1. Terraform 管理プロジェクト ID を下記のコマンドで取得します。:
export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
  1. ワークショップに関連するすべてのリソース情報は、terraform 管理プロジェされているvars.shファイルに変数として保存されていますされていまするvars.shファイルに変数とれています得します.
mkdir vars
gsutil cp gs://${TF_ADMIN}/vars/vars.sh ./vars/vars.sh
echo "export WORKDIR=${WORKDIR}" >> ./vars/vars.sh
  1. 表示されたリンクをクリックして、Terraform 管理プロジェクトのページをリッククトのページを.
source ./vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
  1. ক্লাউড বিল্ডページ が 表示 さ れ た ので ので 、 左側 ナビゲーション から履歴 履歴リンク クリック し 、 最新 の ビルド を クリック し 、 、 を の の の の スクリプト 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、作成されます.上記のアーキテクチャ図も参考になります.
  • 組織内の4つのGCPプロジェクト。
  • 1 つのプロジェクトは、共有VPCが設定されているnetwork host projectは作成されません.
  • 1つのプロジェクトは、IstioコントロールプレーンのGKEクラスタに使用されるops project ।
  • それ以外の2つのプロジェクトは、それぞれのサービスに取り組んスに取り組んでいる2を表しています.
  • 3つのops 、 dev1およびdev2プロジェクトのそれぞれで、2つのGKEクラスターが作成。
  • Kubernetesのマニフェストファイル用の6つのフォルダを含むk8s-repoという名前のCSRリポGKE クラスタごとに1つのフォルダがあります。をクラスタにデプロイするために使用されます.
  • ক্লাউড বিল্ডトリガーは、 k8s-repoれのフォルダからGKEクラスタにデプロイします।
  1. টেরাফর্ম表示されたリンクをクリックして、 opsプロジェクトのCloud Buildページを開きます.
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

インストールの確認

  1. すべてのクラスタを管理するためにkubeconfigファイルを作成します。 下記のスク
./scripts/setup-gke-vars-kubeconfig.sh

このスクリプトは新しい kubeconfig ファイルをkubemeshという名前でgkeフォルダに作我

  1. KUBECONFIG変数を新しい kubeconfig ファイルに変更します.
source ./vars/vars.sh
export KUBECONFIG=`pwd`/gke/kubemesh
  1. var.sh を .bashrc に追加し、Cloud Shell が再起動した際に常に読み込まれるようにししまま
echo "source ${WORKDIR}/asm/vars/vars.sh" >> ~/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> ~/.bashrc
  1. クラスタのコンテキストを取得します.6つのクラスタが見えるはずです. 
kubectl config view -ojson | jq -r '.clusters[].name'
 

    `出力結果（コピーしないでください）`

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

Istio のインストール確認

  1. すべての Pod が実行され、ジョブが完了したことを確認して、Istioが両方のクトールされていることを確認します. 
kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `出力結果（コピーしないでください）`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-z9f98                  1/1     Running   0          6m21s
istio-citadel-568747d88-qdw64             1/1     Running   0          6m26s
istio-egressgateway-8f454cf58-ckw7n       1/1     Running   0          6m25s
istio-galley-6b9495645d-m996v             2/2     Running   0          6m25s
istio-ingressgateway-5df799fdbd-8nqhj     1/1     Running   0          2m57s
istio-pilot-67fd786f65-nwmcb              2/2     Running   0          6m24s
istio-policy-74cf89cb66-4wrpl             2/2     Running   1          6m25s
istio-sidecar-injector-759bf6b4bc-mw4vf   1/1     Running   0          6m25s
istio-telemetry-77b6dfb4ff-zqxzz          2/2     Running   1          6m24s
istio-tracing-cd67ddf8-n4d7k              1/1     Running   0          6m25s
istiocoredns-5f7546c6f4-g7b5c             2/2     Running   0          6m39s
kiali-7964898d8c-5twln                    1/1     Running   0          6m23s
prometheus-586d4445c7-xhn8d               1/1     Running   0          6m25s

    `出力結果（コピーしないでください）`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m
  1. Istio が 両方 の の の の クラスタdev1クラスター に インストール インストール れ て いる こと こと を 確認 し て ください。。。。。 クラスター は 、 、 、 、 、 実行 いる れ 実行 実行 実行 コントローdev1さ さ さ さ れ ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます।共有します.
kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
  1. Istioが両方のdev2クラスタにインストdev2ルされていることを確認してくださいしてください. 、sidecar-ইঞ্জেক্টর、corednのみが実行されています。 ops-2共有します. 
kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `出力結果（コピーしないでください）`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

共有コントロールプレーンのサービスディスカバリの確認

  1. オプションで、গোপন がデプロイされていることを確認します। 
kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
 

    `出力結果（コピーしないでください）`

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

このワークショップでは、すべてのGKEクラスタが作成される単一の共有VPCを使用します。クラスタ全体でサービスを検出するには、opsクラスターで Secret として作成されたkubeconfigファイル（各アプリケーションクラスタ用）を使用します.পাইলট は、これらの সিক্রেটを介して認証された）を照会することにより、サービスを検出します丙. গোপনীয় অপ্সは、opsクラスター内のPilotが他のすべてのクラスターのKube APIサーバーにアクセスできることが必要です。 PilotがKube APIサーバーに到達できない場合、リモートサービスをServiceEntriesとして手動で追加します。 ServiceEntriesは、サービスレジストリのDNSエントリとসার্ভিস এন্ট্রিসビスを定義します。 詳細については、 Istio মাল্টিক্লাস্টার

5. অবকাঠামো リポジトリの説明

অবকাঠামো ক্লাউড বিল্ড

ワークショップのGCPリソースは、 Cloud BuildとInfrastructure CSRリポジトリを使用して構築されます。ローカル端末からワークショップ作成スクリプト（ scripts/bootstrap_workshop.shにあります）を実行します。ワークショップ作成スクリプトは、GCPフォルダটেরাফর্ম 管理プロジェクト、およびCloud Buildサービスアカウントの適切カウント適切なIAM raform管理プロジェクトは、Terraform স্টেটস、ログ、およびそのその他スクリプトを保存すす.そこにはinfrastructureとk8s_repoのCSRリポジトリが含まれています。 টেরাফর্ম 管理プロジェクトには、他のワークショップリソースは組み込理プロジェクトのক্লাউড বিল্ডサービスアカウントは、ワークショップのリソースを構築するために使用されます।

Infrastructure cloudbuild.yamlすしんします.これらのツールには、gcloud SDK、terraform、およびpython、git、jqなどの他のユーティリティすゃゃ゠゠まが含まれーイメージは、 terraform planを実行し、各リソースにapplyます。 各リソースの টেরাফর্মフォルダーにあります（詳細は次のセクションををク照）।成される方法に従って構築されます（たとえば、プロジェクトでリソにGCPプロジェクトが構築されます)詳細については、 cloudbuild.yamlファイルを確認してください.

ক্লাউড বিল্ড は、 infrastructure対して行われた変更は、 কোড হিসেবে অবকাঠামোクショップの状態は常にこのリポジトリに保存されます.

フォルダ構造 - チーム、環境、そしてリソース

ইনফ্রাস্ট্রাকচার,フォルダとサブフォルダに構造化されていますすすすリソースを所有するチームを表します. フォルダの次のレイヤーは、チームの特定の環境（のたとえば、dev、stage、prod）を表します।は、特定のリソース（たとえば、host_project、gke_clustersなど）を表しますします。 必要なススa formファイルは、リソースフォルダー内に存在します.

434fc1769bb49b8c.png

このワークショップでは、次の4種類のチームが出てきます.:

  1. অবকাঠামো - クラウドを管理するのインフラストラクチャチームを表しーーすす. 他のすべスを作成する責任があります。リソースにはTerraform 管理プロジェクトを使用ラクチャリポジトリ自体は、Terraform রাষ্ট্র ファイル（以下で説明）にあります.”よって作成されます（詳細については、モジュール0-インフラストラゃク理者用ワークフローを参照)।
  2. নেটওয়ার্ক - ネットワークチームを表します。 ভিপিসিースを所有しています.
  3. host project - 共有VPCのホストプロジェクトを表します.
  4. shared VPC - 共有 VPC、サブネット、セカンダリIP範囲、ルーティング情報、ファイアアします.
  5. ops - 運用 / DevOpsチームを表します。彼らは次のリソースを所有しています.
  6. ops project - すべてのopsリソースのためのプロジェクトを表します।
  7. gke clusters - リージョンごとのops GKEクラスタ。またIstioコントロールプレーンは、各ops জিকেইルされます.
  8. k8s-repo - すべてのGKEクラスタのGKEマニフェストを含むCSRリポジトリ।
  9. অ্যাপস - アプリケーションチームを表app2ます。 このワークショップは、 app1ションします。彼らは次のリソースを所有しています.
  10. app projects - すべてのアプリチームが個別のプロジェクトセットを持ちます।トごとに請求とIAMを制御できます।
  11. gke clusters - これらは、アプリケーションコンテナ/ Pod が実行されるらは、ケーシ.
  12. gce instances - オプションで、GCEインスタンスで実行されるアプリケーションこがある堁吿。ワークショップでは、অ্যাপ 1ます.

このワークショップでは、同じアプリ（Hipster ショップアプリ）を app1 と app2।

プロバイダ、State、出力 - バックエンド、共有 রাষ্ট্র

googleおよびgoogle-betaプロバイダー はgcp/[environment]/gcp/provider.tf provider.tfます。。。 、 すべて すべて れ て て ます ます に に 個別 する 個別 個別 個別 個別 個別 個別 を を の の の リソース リソース リソース 各 リソース各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各代わりに、1か所でプロバイダを管理できます.

すべてのリソースには、リソースのtfstateファイルのすゾるbackend.tfす.このbackend.tfファイルは、スクリプト（ scripts/setup_terraform_admin_projectにある）を使用してレtemplates/backend.tf_tmplにある）から生成され、それぞれのリソースフォルダに配置されますに配置されイル置き場として使われます. জিসিএসべて、terraform管理プロジェクトにあります.

相互依存する値を持つリソースには、 output.tfファイルが含まれます必要リソースのバックエンドで定義された tfstateクラスタを作成するには、プロジェクトIDを知る必要があります।スのterraform_remote_stateデータソースを介して使用できる tfstate ファイルに output.tf を介しし

shared_state_[resource_name].tfファイルは、リソースのtfstateファイルを指すterraform_remote_stateデータタソースです. ops_gke করা_স্টেট। ,スフォルダには、 ops_projectおよびshared_vpcの শেয়ারড_স্টেট ファイル あり ます これ 、 、 、 、 で で で クラスタ を 作成 する は プロジェクト プロジェクト プロジェクト プロジェクト と 詳細 だ から から です です。 です です です です です です です です 、 、 、 、 スクリプト スクリプト 、 、 スクリプト スクリプト スクリプト スクリプト スクリプト スクリプト スクリプト スクリプト スクリプト スクリプト スscripts/setup_terraform_admin_projectスクリプトテンプレート( templates/shared_state.tf_tmplにある）から生成されます。すべてのリソースの shared_state ファイgcp/[environment]/shared_statesォルダーに配置されます。 必要なshared_state ファイルは、それぞれリースクリンクされています.すべてのশেয়ারড_স্টেটにsymリンクすると、すべての状態ファイルを1か所で簡単に管理できます।

変数

すべてのリソースの値は環の境変数として保存されます。ケットにあるvars.shというファイルに（エクスポートステートメントとし.には、組織ID、請求先アカウント 、 プロジェクト আইডি 、 Gke クラスタ の の 詳細 など が 含ま れ ます。。 の 端末 から から からvars.shを し し て 入手 入手 し セットアップ の 値 値 を 取得 でき ます。。。。。。。。。。。。。。。。。。。。。。

টেরফর্ম 変数 は 、 TF_VAR_[variable name]としてvars.shに 保存 保存 さ ます。 これら の の は 、 それぞれ の リソース に に に する 生成variables.tfvarsる する する ファvariables.tfvarsル ファイル の の の の に に すべて に に ます変数 と 値 が 含ま れ れ て て い。 variables.tfvarsファイル 、 スクリプト （ scripts/setup_terraform_admin_projectト 使用 生成 生成 生成 生成 から から から から から から から から から から から

কে 8 এস リポジトリ の 説明

k8s_repoは、terraform管理プロジェクトにあるCSRリポジトリ（infrastructureリポジトリとは別）で、GKEマニフェストをすべてのGKEクラスタに保存および適用するために使用されます。 k8s_repoは、インフラストラクチャCloud Buildによって作成されます（詳細について は 前 前 の セクション を 参照））。 の インフラストラクチャ インフラストラクチャ ক্লাউড বিল্ড プロセス 中 に 、 合計 6 つ の গেকে クラスタ が が さ れ ます。 （名 クラスタ クラスタ クk8s_repoタ クラスタ フォルダ フォルダ フォルダ フォルダ ます ます ます れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れ れする 名前） は 、 それぞれ の リソース リソース マニフェスト ファイル 含む 含む gke クラスター クラスター に し て い ます。 インフラストラクチャ の 構築 と 同様 同様 、 、 と 、 する に クk8s_repo適用 適用 クラスタ 適用 クラスタ 適用 クラスタ クラスタ 適用 クラスタ 適用 適用 の 適用 の の の の の の の の の の の のされます。 Cloud Buildは、 k8s_repoリポジトリへのコミットがあるたびにトリガーされます。インフラストラクチャと同様に、すべてのKubernetesマニフェストはコードとしてk8s_repoリポジトリに保存され、各GKEクラスターの状態は常にそれぞれのフォルダーに保存 さ れ ます。

初期 インフラストラクチャ 構築 の 一部 とし て 、 k8s_repoが 作成 作成 さ 、 ইস্টিও が すべて すべて の に インストール インストール さ れ れ ます ます ます ます ます ます ます ます ます ます ます ます ます ます

プロジェクト, gke クラスター, そして নেমস্পেস

この ショップ の リソース は 、 、 さまざま জিসিপি プロジェクト に 分かれ て い ます。 プロジェクト は 、 会社 組織 組織 （または が ます ます ます 内 組織 組織 する リソース リソース を リソース リソース リソース リソース リソース リソース を リソース リソース を リソース リソース リソース リソース リソース リソース リソース リソース リソース を リソース リソース リソース リソース リソース リソース リソース リソース リソース を リソース を、 な な gcp プロジェクト を 使用 し ます。 個別 の プロジェクト を を する と 、 iam アクセス アクセス の 個別 の セット 作成 を 管理 管理 管理 管理 管理 で レベル レベル プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト プロジェクト も も も も も も も も も も も も も も も も も も も も も も も

この ワーク ショップ に は 、 それぞれ それぞれ 個別 の プロジェクト を 持つ 5 つの チーム が 出 て き ます ます。

  1. Gcp リソース を 構築 するインフラストラクチャ チーム チーム 、 、 、 、 、 、 、 し。。彼ら は 、 、 、 、 、 、 、 、 （（（呼ば れる）） として インフラストラクチャ を を を を 管理 管理 管理 管理 管理 し すべてinfrastructureの の の の の の の の の の の の の の の の の の の の の の জিসিপি の জিসিপি で জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি の জিসিপি রাজ্য 情報 を 保存 し ます。 これら これら は 、 、 、 、 、 、 および および および および および জিসিএস バケット へ の の を 制御 制御 し ます。。
  2. 有 有 ভিপিসি を 構築 するネットワーク ネットワーク チーム、 hostプロジェクトを 使用 し し。 この プロジェクト に は 、 ভিপিসি 、 サブ ネット 、 ルート 、 ファイアウォール て て い い い い い い ます ます ます を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を を。 すべて の プロジェクト は 、 ネットワーク ネットワーク に この 単一 の 共 有 ভিপিসি を 使用 し て て い ます。
  3. Gke クラスター と asm / istio コントロール プレーン プレーン をする する する する する する する する するは 、 、 、 、 、 、 、。。。。 の の し ます ます ます します。 opsラットフォーム プラットフォーム プラットフォーム の の し し し し し 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化 強化と スケール 管理 管理 する 責任 が あり あり ます。 この ショップ ショップ で で は 、 をk8s_repoを を を する する する する する メソッド し ます。。。。 （（（存在 し 存在 存在 ます 存在 存在 存在 ます 存在 存在 ます 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在 存在
  4. 最後 に 、 アプリケーション を する するdev1 および dev2 チーム（2 つ の 開発 チーム を 表す） は は 独自 の の 使用 し 、 、 、 、 は は これら これら。。 dev2す です ですdev1サービス です サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス サービス管理 プラットフォーム 上 に 構築 さ れ れ ます。 （（মোতায়েন 、 পরিষেবা など） はk8s_repoに プッシュ さ れ 適切 な クラスター この この この この この に と プラクティス ベスト ベスト ベスト ベスト ベスト の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の注意 し て。 ক্লাউড বিল্ড を 使用 し し 、 Gke クラスター クラスター の の の の の の の の を 自動 化 し し。 実際 の 運用 シナリオ で 、 な な に に に ます ます に に に に に に に を を を を を アプリケーション を を を アプリケーション アプリケーション を アプリケーション アプリケーション アプリケーション て アプリケーション て て を て アプリケーション アプリケーション を を アプリケーション を アプリケーション アプリケーション を を を アプリケーション アプリケーション.

この ワーク ショップ に は 2 種類 の Gke クラスター が あり あり ます ます ます

  1. অপ্স クラスター- অপ্স チーム が ডিভোপস の ツール ツール 実行 する ため に 使用 使用 し。。 この ワーク ショップ ショップ は 、 এএসএম / ইস্টিও コントロール プレーン を 実行 し て サービス を 管理 管理 し し。。。。。。。。。。。。。。。。
  2. アプリケーション (অ্যাপ্লিকেশন) クラスター- 開発 開発 が アプリケーション アプリケーション を する ため に に 使用 し。。 この ワーク ショップ で は 、 হিপস্টার ショップ アプリ に に 使用 さ れ ます。。。 れ れ ます。。。 れ れ ます。。

অপ্স / অ্যাডমিন ツール を アプリケーション を 実行 する する クラスター から する と 、 、 各 リソース の ライフ サイクル を 個別 管理 管理 でき。 つ 、 を を を も も に に 異なる プロジェクト する する する する 関連 関連 関連 関連 する する 関連 する 関連 関連 関連 関連 関連 関連 関連 関連 関連 関連 関連 関連。 これ により 、 iam 権限 も 管理 し やすく なり ます ます ます ます

合計6つのGKEクラスターがでてきます。 opsプロジェクトでは、2つのリージョナルopsクラスターが作成されます。 ASM / Istioコントロールプレーンは、両方のopsクラスターにインストールされます。各opsクラスターは異なるリージョンにあります。さらに、 4 つの ゾーン クラスター が が あり ます。 これら は 個別 の プロジェクト プロジェクト 作成 さ さ ます。 この この ショップ は 、 の の 開発 開発 開発 の 開発 つ に プロジェクト プロジェクト に プロジェクト に に プロジェクト プロジェクト プロジェクト プロジェクト 各 プロジェクト プロジェクト 各 プロジェクト 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各 各ます。 アプリ クラスター は 、 異なる ゾーン ゾーン の ゾーン です です。 4 つ の アプリ クラスター は 、 2 つの リージョン と 4 つの ゾーン に ます ます これ これ リージョン ゾーン の の 冗長 冗長 性 性 ます ます。。。。。。。。。。。。。 ます ます。

この ワーク で で さ れる れる アプリケーション である হিপস্টার ショップ アプリ は 、 4 つ の アプリ クラスター すべて に さ さ れ ます 各 サービス は は 、 アプリ クラスター ショップ ショップ ショップ ショップ し し し し し し し し し し し し し し 存在 し 存在 存在 存在 に 存在 存在 に に 存在 存在 存在 に 存在 存在 存在 存在 存在 存在 存在 存在 し し し し し し し 存在 し し しPod）は、opsクラスターには展開されません。ただし、すべてのマイクロサービスのnamespaceとサービスリソースもopsクラスターに作成されます。ASM / Istioコントロールプレーンは、サービスディスカバリにKubernetesサービスレジストリを使用します。 （অপ্স クラスター に） サービス が が ない 場合 、 アプリ クラスター で 実行 実行 さ て いる 各 サービス の の の の の の 手動 手動 手動 作成 する 必要 が が ます ます。。。 あり ます。。。。 あり ます。。。。 あり ます ます。

この ワーク で で は 10 層 の の マイクロ アプリケーション を デプロイ デプロイ し ます。 この アプリケーション は 、 「「 「呼ば れる れる で ユーザーユーザー する 、 、 する する する 、 する する する し 追加 追加 追加 追加 に 追加 追加 カート カート カート カート カート カート カート カート カート て て て て て て て て て カート カート カート カート カート カート カート カート カート カートでき ます。

কুবারনেটস マニフェスト と k8s_repo

k8s_repoを 使用 し て 、 すべて の Gke クラスター に কুবারনেটস リソース を 追加 し ます。 これ を 行う に 、 、 マニフェスト 、 、 へ へ へ u u u u u u すべて 、 、 、。。。 ます ます ます し し し し し し し し し しk8s_repoし し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し しk8s_repoし し し し し し し し し し し し し ます し し ます ます ます し ます し ます し ます ます し ます し ます し ます ます し し ます ます ますに デプロイ する ক্লাউড বিল্ড ジョブ を トリガー し し ます 各 クラスター の マニフェスト マニフェスト は クラスター 名 名 と 同じ 名前 別 別 の フォルダー フォルダー に あり ます ます ます ます ます ます ます ます

6 つの クラスター 名 は 下記 に なり ます ます:

  1. GKE-ASM-1-R1-PROD-リージョン 1 に に リージョナル অপ্স クラスター
  2. GKE-ASM-2-R2-PROD-リージョン 2 に ある リージョナル অপ্স クラスター
  3. Gke-1-apps-r1a-prod-リージョン 1 の ゾーン a に ある アプリ クラスター
  4. Gke-2-apps-r1b-prod-リージョン 1 の ゾーン b に ある アプリ クラスター クラスター
  5. Gke-3-apps-r2a-prod-リージョン 2 の ゾーン a に ある アプリ クラスター
  6. Gke-4-apps-r2b-prod-リージョン 2 の ゾーン b に ある アプリ クラスター クラスター

k8s_repoに は 、 これら の クラスター クラスター に する フォルダー が が あり ます。 これら フォルダー フォルダー に さ れ た 、 対応 れ れ れ れ さ 、 管理 、 は は は は マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェスト マニフェストの メインフォルダー 内） に さ さ れ ます。。 ワーク ショップ で で はকাস্টমাইজを 使用 使用 し 、 デプロイ さ れる を 追跡 は し は 詳細 て て し し し て し し 参照 参照 参照 参照 参照 参照 参照 参照 を を を を を を を を を を を を を を を を を を を を を を

6. サンプル アプリ を デプロイ する

目標: হিপস্টার ショップ アプリ を অ্যাপ্লিকেশন クラスター に デプロイ する

  • k8s-repoポジトリ を クローン
  • হিপস্টার ショップ の マニフェスト マニフェスト 全て の অ্যাপ্লিকেশন クラスター に コピー
  • হিপস্টার ショップ アプリ の の に পরিষেবাগুলি を অপ্স クラスター に 作成
  • グローバル の 接続 性 を テスト する ため ため ため ため ため ため ため たloadgeneratorを を を クラスター に セットアップ セットアップ
  • হিপস্টার ショップ アプリ へ の セキュア な な 接続 を 確認

অপ্স プロジェクト の リポジトリ を クローン

の の の の の 構築 の 一部 一部 とし 、 k8s-repoは অপ্স プロジェクト で 既に 既に 作成 済み です。。。。。。。。。。。。。

  1. ওয়ার্কডির の 下 に 、 リポジトリ 用 の の フォルダ を 作成 作成 し ます。:
mkdir ${WORKDIR}/k8s-repo
cd ${WORKDIR}/k8s-repo
  1. গিট リポジトリ として 初期 化 し 、 リモート リモート の リポジトリ 追加 、 、 মাস্টার ブランチ を পুল し ます ます ます:
git init && git remote add origin \
 https://source.developers.google.com/p/${TF_VAR_ops_project_name}/r/k8s-repo
  1. গিট の ローカル 設定 を 行い ます ます。。 
git config --local user.email ${MY_USER}
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

マニフェスト の コピー 、 コミット 、 そして そして プッシュ

  1. হিপস্টার শপ マニフェスト を すべて の クラスター の ソースリポジトリ に コピー し し ます。。
cd ${WORKDIR}/asm
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/.
  1. হিপস্টার ショップ は 、 、 、 、 、 、 アプリケーション に 展開 さ さ れ ます。。。。。。。。 は は は 、 、 、 、 、 、 、 プレーン で のみ 使用 さ れ ます ます。。 クラスター から から から から から から ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ ショップ 、 ショップ ショップ ショップ ショップ ショップ ショップ 、 ショップ ショップ の ショップ 、 の 、 、 、 、 、 、 、 、 、 、 、 、
rm -rf ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/deployments
rm -rf ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/deployments
rm -rf ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/podsecuritypolicies
rm -rf ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/podsecuritypolicies
rm -rf ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/rbac
rm -rf ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/rbac
  1. 1 つ の দেব クラスター 以外 の すべて から から から から rbac および পডসিকিউরিটিপলিসি を 削除 削除 ます。。。 マルチ マルチ クラスター クラスター 展開用 た た もの もの もの もの もの もの もの もの ではなく ではなく ではなく ではなく ではなく ではなく 、 、 ではなく ではなく ではなく ではなく ではなく ではなく 、 、 、 、 、 、 の の の の の の の の の の の の の の の の の の の を の の の の を の の の の を の を の を 実行 を を を 実行 実行 し こと こと こと し し し し こと し こと し し し し し し し し し こと こと し し し して カート 情報 に 矛盾 が 生じ 生じ てしまい ます。
rm ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/deployments/app-cart-service.yaml
rm ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/podsecuritypolicies/cart-psp.yaml
rm ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/cart-rbac.yaml

rm ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/deployments/app-cart-service.yaml
rm ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/podsecuritypolicies/cart-psp.yaml
rm ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/cart-rbac.yaml

rm ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/deployments/app-cart-service.yaml
rm ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/podsecuritypolicies/cart-psp.yaml
rm ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/cart-rbac.yaml
  1. の の দেব クラスター のみ のみ 、 কার্টসার্ভিস ডিপ্লোয়মেন্ট 、 আরবিএসি 、 および পডসিকিউরিটিপলিসি を কাস্টমাইজেশন.ওয়ামল に 追加 追加 し。。。。。。。。。。。。。
cd ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
  1. ওপিএস クラスター の কাস্টমাইজেশন.ইএএমএল から পডসিকিউরিটিপোলিস 、 মোতায়েন 、 আরবিএসি ディレクトリ を 削除 削除 し。。。。。。。。
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d'  -e '/- rbac\//d' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d'  -e '/- rbac\//d' ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/kustomization.yaml
  1. আরবিএসি マニフェスト の প্রকল্প_আইডি を 置き換え ます。。
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g'  ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g'  ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g'  ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g'  ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  1. ইঙ্গ্রেসগেটওয়ে および ভার্চুয়াল সার্ভিস マニフェスト を অপ্স クラスター の ソースリポジトリ に コピー し ます。。
cp -r k8s_manifests/prod/app-ingress/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-ingress/
cp -r k8s_manifests/prod/app-ingress/* ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-ingress/
  1. কনফিগারেশন সংযোগকারী リソース を 各 プロジェクト の クラスター の 1 つに コピー し ます ます。。。。
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-cnrm/
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app-cnrm/
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app-cnrm/
  1. কনফিগারেশন সংযোগকারী マニフェスト の প্রকল্প_আইডি を 置き換え ます。。
sed -i 's/${PROJECT_ID}/'${TF_VAR_ops_project_name}'/g' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-cnrm/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g'  ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app-cnrm/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g'  ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app-cnrm/*
  1. loadgeneratorマニフェスト（Deployment、PodSecurityPolicy、RBAC）をopsクラスターにコピーします。 Hipsterショップアプリは、グローバルなGoogle Cloud Load Balancer（GCLB）を使用して公開されます。 GCLBはクライアントトラフィック（ frontend宛て）を受信し、 の 最も 近い インスタンス に 送信 送信 し。。。。。 両方 の の の のloadgeneratorの の と 、 、 অপ্স クラスター で 実行 実行 さ れ て て いる の の 負荷 負荷 負荷 負荷 ます ます れ れ れ れ れ れ れ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ さ説明 し ます。
cp -r k8s_manifests/prod/app-loadgenerator/. ../k8s-repo/gke-asm-1-r1-prod/app-loadgenerator/.
cp -r k8s_manifests/prod/app-loadgenerator/. ../k8s-repo/gke-asm-2-r2-prod/app-loadgenerator/.
  1. 両方 の の の のloadgeneratorラスター の の の の の の の の の の プロジェクト আইডি を 置き換え ます。。
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/loadgenerator-rbac.yaml

sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-loadgenerator/loadgenerator-rbac.yaml
  1. 両方 の の の の クラスター のloadgeneratorリソース を কাস্টমাইজেশন.ইএএমএল に 追加 し ます。。。。。。。。。。。。
cd ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd ../../${OPS_GKE_2_CLUSTER}/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
  1. k8s-repoに コミット し ます。。
cd ${WORKDIR}/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master
  1. ロール アウト が 完了 する の を を 待ち ます。 
../asm/scripts/stream_logs.sh $TF_VAR_ops_project_name

アプリケーション の 展開 を 確認 する

  1. カート を 除い た すべて すべて アプリケーション アプリケーション নেমস্পেস の পড が 、 、 の দেব クラスター で 実行 状態 （状態 状態 状態 である である こと こと を 確認 確認 し ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます
for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context ${DEV1_GKE_1} get pods -n ${ns};
  kubectl --context ${DEV1_GKE_2} get pods -n ${ns};
  kubectl --context ${DEV2_GKE_1} get pods -n ${ns};
  kubectl --context ${DEV2_GKE_2} get pods -n ${ns};
done;

出力結果（コピーしないでください）

NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-pvc6s   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-xlkl9   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-zdjkg   2/2     Running   0          115s
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-l748q   2/2     Running   0          82s

NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-gk92n   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-rvzk9   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-mt925   2/2     Running   0          117s
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-klqn7   2/2     Running   0          84s

NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-kkq7d   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-lwskf   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-zz7xs   2/2     Running   0          118s
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-2vtw5   2/2     Running   0          85s

NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-df8ml   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-bdcvg   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-jqf28   2/2     Running   0          117s
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-95x2m   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-q5g9p   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-n6lp8   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-gf9xl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-v7cbr   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-2ltrk   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-dqd55   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-jghcl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-kkspz   2/2     Running   0          87s

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s
  1. কার্ট নেমস্পেস の পড が 、 最初 の দেব クラスター で のみ 実行 実行 （状態 状態 状態） である こと を を 確認 し ます。。。。。。。。。。。。。。。。。
kubectl --context ${DEV1_GKE_1} get pods -n cart;

出力結果（コピーしないでください）

NAME                           READY   STATUS    RESTARTS   AGE
cartservice-659c9749b4-vqnrd   2/2     Running   0          17m

হিপস্টার ショップ アプリケーション へ へ アクセス

グローバル 負荷 分散

これ で 4 つ の アプリ クラスター クラスター に হিপস্টার শপ アプリ が 展開 展開 れ まし た。 これら の は は 、 つの と クライアント クライアント クライアント クライアント クライアント に に アプリ アプリ ショップ アプリ ショップ ショップ ショップ ショップ ショップ し ショップ ショップ ショップ ショップfrontendョップ し し て て し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し し て し て て し し し し し し し し て てfrontendサービス は 、 4 つ の アプリ クラスター すべて で 実行 さ さ れ ます。 গুগল ক্লাউড লোড ব্যালেন্সার （ জিসিএলবি ） を 使用 し 、 、 、 の 4 つの インスfrontendンス すべて クライアント トラフィック トラフィック を 取得 取得 し ます。。 を 取得 し し ます。。。 取得 取得 し ます。。。

Istio ingress ゲートウェイは は は は のみ のみ さ れ 、 リージョン リージョン 内 2 つの ゾーン アプリケーション クラスター に対する リージョナル ロード バランサー として 機能 し ます。 エンド エンド エンド エンド サービス サービス つつ て て て つ て つ つ つ つ つ つ つ つ つ つ つ つ実行） を 使用 し し。。 ইস্টিও ইনগ্রেস ゲートウェイ は 、 জিসিএলবি から クライアント トラフィック を 受信 し 、 クライアント トラフィック を アプリケーション クラスター で 実行 さ れ て いる フロント পড に 送信 送信 し ます。。。。 ます。。。。 ます。。。。。。。。。。。。。

4C618DF35CB928EE.PNG

また 、 istio incres

Gke অটোনগ コントローラー

ইস্টিও ইনগ্রেস ゲートウェイ কুবারনেটস সার্ভিস は 、ネットワーク エンド ポイント （（（（ （を を し て 、 জিসিএলবি の バック エンド として 自身 登録 し ます。。 、 、 分散 が が が が が が が が 分散 が 分散 負荷 負荷 分散 分散 分散 分散 負荷 分散 負荷 負荷 負荷 負荷 が が 負荷 負荷 負荷 分散 が が が が が が が が が が 分散 が 分散 が が 分散 分散 が が が が 分散 が 分散 が が が が が が が が が が が が が が が が が が が が が 分散 が が が が が が が は 分散 が が が が が が が が が が が 分散 分散 が は が が は は が は が が は が が はの 特別アノテーション アノテーションを 使っ て 作成 作成 さ れる 、 、 、 、 コントローラー に 自身 を 登録 でき ます。。。。。。。 特別 な な な で で 、 、 化 し し し し し し し し エンド エンド エンド エンド エンド バック を バックを を を バック それら それら それら それら それら それら て それら それら て それら それら て て て それら て て それら て て て それら て て それら それら て て それら それら て それら て それら それら て それら て それら割り当て ます。 istio イングレス ゲートウェイ を 含む istio コントロール プレーン は 、 、 、 、 、 イニシャル イン フラストラクチャ で 展開 さ れ ます。。。。。。。。。。 、 、 、 、 、 、 インフラストラクチャ イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル イニシャル 一部 一部 一部 一部 として として として として として 行わ 行わ れ れ れ ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます

ক্লাউড এন্ডপয়েন্টস と マネージド 証明 書 を 使っ 使っ セキュア な ইনগ্রেস

জিসিপি マネージド 証明 書は 、 frontend জিসিএলবি サービス へ の クライアント トラフィック トラフィック を する ため に 使用 さ ます。。 জিসিএলবি は は グローバfrontendグローバル を を れ れ 使用 使用 使用 し し し し し し し し し し し 、 さ さ さ さ さ証明 書 の ドメイン としてক্লাউড এন্ডপয়েন্টসを 使用 使用 ます。 または 、 、 、 、 、 と と dns 名 を 使用 し て て জিসিপি マネージド 証明 書 書 を 作成 でき ますfrontend書 を 作成 でき ます。。。。

  1. হিপস্টার ショップ に アクセス する ため に に 、 下記 コマンド コマンド で 出力 さ れる リンク を クリック し し ます。
echo "https://frontend.endpoints.${TF_VAR_ops_project_name}.cloud.goog"
  1. Chrome タブ の url バー の ロック 記号 を を し て 、 証明書 証明書 が である こと こと を 確認 でき ます。。。。。

6C403A63CAA06C84.png

グローバル 負荷 分散 の 確認

アプリケーション 展開 の 一部 とし 、 、 জিসিএলবি হিপস্টার ショップ の ক্লাউড এন্ডপয়েন্টস リンク へ テスト トラフィック を 生成 する する の の クラスター に 負荷 生成 機能 機能 機能 た た た た た た ゲートウェイ。。 送信 送信 に に に に に 両方 両方 両方 、 、 、 、 、 、 し 、 、 、 、 、 、 、 受信 受信 、 受信 、 受信 受信 受信 受信 受信 受信 、 、 受信 受信 受信 受信 受信 受信 受信 受信 受信 、 、 、 受信 受信 、 、 、 受信 、て いる こと を 確認 し ます ます。

  1. হিপস্টার ショップ জিসিএলবি が 作成 さ れ れ いる いる いる いる いる いる のজিসিএলবি> মনিটরিংリンク を 取得 し し ます。
echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=${TF_VAR_ops_project_name}&cloudshell=false&tab=monitoring&duration=PT1H"
  1. 以下 に 示す よう に 、 、 、 、 、 、 、 ドロップ ダウンメニュー からসমস্ত ব্যাকেন্ডからআইটিও-ইনগ্রেসগেটওয়েに 変更 し し ます。

6697c9eb67998d27.png

  1. の のistio-ingressgatewaysに 向かう トラフィック を 確認 し し て ください。

ff8126e44cfd7f5e.png

istio-ingressgatewayごとに3つのNEGが作成されます。 opsクラスターはリージョナルクラスターであるため、リージョン内の各ゾーンに対して1つのNEGが作成されます。ただし、 istio-ingressgateway Podは、リージョンごとに単一 の ゾーン で 実行 さ れ れ ます。 ここ で は 、 istio-ingressgateway

負荷 生成 機能 は 、 、 の の の クラスター で さ れ 、 、 2 つの リージョン から の クライアント トラフィック トラフィック を し ます ます クラスターリージョン 1 で で 生成 生成 さ 、 負荷 、 リージョン リージョン リージョン の の の ます れ れ れistio-ingressgatewayさクラスターリージョン 2 で 生成 さ れ た 負荷 負荷 は 、 、 1 のistio-ingressgatewayに 送信 さ さ れ ます。。。。。。。。。。。

7. স্ট্যাকড্রাইভার による 可 観測性

目標: Istio の テレメトリ データ を স্ট্যাকড্রাইভার に 連携 し 、 確認 する

  • istio-telemetryリソース を インストール
  • Istio পরিষেবা の ダッシュ ダッシュ を 作成/更新
  • コンテナ の ログ を 表示
  • স্ট্যাকড্রাইভার で 分散 トレーシング 情報 を を 表示

Istio の 主要 な 機能 の 1 つ は 、 、 の 可 観測性 （（（（（（（は は 、 機能 機能 入っ い て て て トラフィック する 出入り する を コンテナ を コンテナ コンテナ コンテナ コンテナ コンテナ コンテナ コンテナ コンテナ の の の の コンテナ の の コンテナ コンテナ の の コンテナ の の の の の コンテナ の の コンテナ コンテナ の の観察 し、 顧客 に サービス を 提供 提供 できる こと を 意味 し ます ます。 観察 は 、 メトリック メトリック 、 、 および トレース と いくつ か の 異なる の 形 取り ます ます ます ます ます ます ます ます ます

また 、 হিপস্টার ショップ に 組み込ま れ て て いる 生成 機能 を を 利用 し ます。 観測 性 は 、 の ない で し ため ため ため ため する 負荷 を を 動作 動作 動作 その その 動作 その その その その その その その その その その その その その その その その その その 、 その その その その その 、 、 、 その生成 は すでに 実行 さ れ て いる いる ので 、 に に 確認 可能 です。

  1. Istio を স্ট্যাকড্রাইভার の 構成 ファイル に インストール し ます。。
cd ${WORKDIR}/k8s-repo

cd gke-asm-1-r1-prod/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd ../../gke-asm-2-r2-prod/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
  1. কে 8 এস-রেপো に コミット し ます。。
cd ../../
git add . && git commit -am "Install istio to stackdriver configuration"
git push
  1. ロール アウト が 完了 する の を を 待ち ます。
../asm/scripts/stream_logs.sh $TF_VAR_ops_project_name
  1. ইস্টিও → স্ট্যাকড্রাইভার の 連携 を 確認 確認 ます。 স্ট্যাকড্রাইভার হ্যান্ডলার সিআরডি を 取得 し ます。。
kubectl --context ${OPS_GKE_1} get handler -n istio-system

出力 に は 、 স্ট্যাকড্রাইভার という の の হ্যান্ডলার が 表示 さ れる れる です です:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s

Istio の メトリックス が স্ট্যাকড্রাইভার に エクスポート さ れ て いる こと こと を 確認 ます。 この この コマンド から 出力 さ れる リンク を クリック し し ます ます。。。。。。。

echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=${TF_VAR_ops_project_name}"

ওপিএস プロジェクト に ちなん で 命名 さ れ れ た 新しい スペース スペース を 作成 する よう に 求め られる ので 、 [ঠিক আছে] を 選択 し ます。 新しい 新しい さ さ さ れ

メトリクスエクスプローラー で 、 [レコード タイプ] を クリック クリック し 、 istio 」と と 入力 ます。。「 「「 「リソー スタイプ に「 「「 「「 あり あり が あり あり あり あり メッシュ メトリック メッシュ メッシュ メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリックいる こと を 示し て い ます ます。

（以下 の 行 を 表示 する する 場合 は 、 、 、 、 、 、 、 、 グループ 化 化 する 必要 が あり あり。。）））

B9B59432EE68E695.png

ダッシュ ボード で メトリクス を 可視 化 する する:

が が স্ট্যাকড্রাইভার এপিএম システム に ある ので 、 それら を 視覚 化 する する が 必要 です。 この この で は 、 メトリクス の 4 つ の のし し し インストール インストール インストール を ボード ボード を ボード ダッシュ ダッシュ ダッシュ ダッシュ の の の の の の の 済み の の 済み 済み 済み 済み 済み 済み 済み 済み の の 済み 済み 済み 済み 済み 済み の 済み 済み 済み の 済み の の の の の 済み の の1 秒 あたり の リクエスト 数）） 、レイテンシ（この 場合 、 99 パーセンタイル パーセンタイル 50 パーセンタイル） 、エラー（この 例 で ははを 除外 し て て い ます）））。。。。。。。。。。。。。。。。。。。

আইএসটিও の プロキシ は いくつ か の を 提供 し ます が が これらは使い 始める の に た た セット です （完全 な リスト は です）） 各 各 は は 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 আল など の フィルタリングや 集計 に 使用 できる ラベル の セット セット が ある に に 注意 し て ください ください ください ください

  1. 次 、 あらかじめ 用意 さ さ れ て いる いるダッシュ ボードを 追加 追加 し ましょ う。。 し ます これ で 生成 生成 する する 化 化 化 自動 自動 自動 自動 自動 自動 自動 の の の の なんらか の なんらか。。。。。。。。。 ん ん ん ん ん ん ん ん ん、 ওয়েব ইউআই で ダッシュ ボード を 手動 手動 で 作成 ます。。 これ により 、 すぐ に 使い 始め 始め られ ます。。。。。
cd ${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g'  services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/${TF_VAR_ops_project_name}/dashboards \
 -d @services-dashboard.json
  1. 以下 の 出力 さ れ た リンク リンク に 移動 し て 、 新しく 追加 追加 さ た ダッシュ ボード ボード を 表示 し ます ます。。。。
echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=${TF_VAR_ops_project_name}"

Ux を 使用 し て ダッシュ ボード を を その 場 で 編集 する こと も も ます が 、 今回 の ケース で は 、 し すばやく 追加 すばやく すばやく を 、 の ボード ダッシュ ボード ダッシュ 、 、 、 、 は は は は は は は は は は は は は は は は は は は は は は は は は は は は は は は は編集 内容 を 適用 し て から 、 、 、 、 、 、 使用 使用 し て プッシュ する 必要 が が あり ます。。。。

  1. モニタリング এপিআই を 使い 、 既存 の ダッシュ ダッシュ ボード を 取得 でき ます。 追加 し た ばかり の ダッシュ ボード を 取得 し し ます。
curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/${TF_VAR_ops_project_name}/dashboards/servicesdash > sd-services-dashboard.json
  1. 新しい グラフ の ： （50 তম ％ আইল ল্যাটেন্সি） ： [ এপিআই রেফারেন্স] これ 、 新しい グラフ グラフ ウィジェット 追加 でき でき。 ピア ピア さ さチェックイン チェックイン チェックイン 管理 管理 管理 管理 管理 管理追加 する ウィジェット は 、 50 ％ の の 待機 （（（（（（（（の 中央 値 を 示し 示し て い ます。

取得 し た ばかり の ダッシュ ボード を を 編集 し て 、 新しい 節 節 追加 し て み み て ください:

jq --argjson newChart "$(<new-chart.json)" '.gridLayout.widgets += [$newChart]' sd-services-dashboard.json > patched-services-dashboard.json
  1. の の সার্ভিসেসড্যাশবোর্ড を 更新 し ます:
curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/${TF_VAR_ops_project_name}/dashboards/servicesdash \
 -d @patched-services-dashboard.json
  1. 次 の 出力 さ れ た リンク に に 移動 し て 、 更新 さ さ た ダッシュ ボード を を 表示 し ます ます ます
echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=${TF_VAR_ops_project_name}"
  1. 簡単 な ログ 分析 を 行い ます ます。

Istio は 、 すべて の インメッシュ ネットワークトラフィック ネットワークトラフィック の構造 ログ ログの セット を を 提供 、 それら それら を アップロード アップロード つ つ クロス 、 、 、 は 、 は は は は は は は は に に に に ログ ログ ログ ログ ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます ます し ます し し し し し し し し し し し ます、 、 সংযোগ_আইডি など の サービス レベル の メタ データ が 追加 さ さ れ ます ます

ログエントリ の 例 （この この 、 、 、 、 の の の の の の は 次 の よう に なり ます （（整形 済み）））:

  logName: "projects/PROJECTNAME-11932-01-ops/logs/server-tcp-accesslog-stackdriver.instance.istio-system" 
labels: {
  connection_id: "fbb46826-96fd-476c-ac98-68a9bd6e585d-1517191"   
  destination_app: "redis-cart"   
  destination_ip: "10.16.1.7"   
  destination_name: "redis-cart-6448dcbdcc-cj52v"   
  destination_namespace: "cart"   
  destination_owner: "kubernetes://apis/apps/v1/namespaces/cart/deployments/redis-cart"   
  destination_workload: "redis-cart"   
  source_ip: "10.16.2.8"   
  total_received_bytes: "539"   
  total_sent_bytes: "569" 
...  
 }

ここ で ログ を 表示 し ます。。:

echo "https://console.cloud.google.com/logs/viewer?cloudshell=false&project=${TF_VAR_ops_project_name}"

Istio の コントロール プレーン ログ を 表示 表示 する に は リソース リソース リソース リソース リソース> কুবারনেটস コンテナー を 選択 選択 し "পাইলট"-で 検索 し し。。。

6F93B2AEC6C4F520.png

ここ で は 、 各 サンプル アプリ サービス サービス の プロキシ 設定 を を プッシュ プッシュ プッシュ istio コントロール プレーン を 見る 見ることができ。。

Istio の ログ を 超え て 、 、 コンテナログ だけでなく 、 インフラストラクチャ または または 他 জিসিপি サービスログ も すべて 同じ インターフェイス で 見つける ことができ ます。。。。サンプル サンプル を を 次 に に。 ログビューア ログビューア で で は 、 から メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリック メトリックを 作成 こと こと も でき ます （たとえば たとえば 、 文字 列 に に 一致 する すべて の エラー を カウント する 」）。 ダッシュ ボード として として でき でき の の の の の の の の 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、ストリーミング する こと も でき でき ます。

হিপস্টার ショップ 用 の いくつ か の の サンプル フィルター を 示し ます:

resource.type="k8s_container" labels.destination_app=" productcatalogservice "

resource.type="k8s_container" resource.labels.namespace_name=" cart "

  1. 分散 トレーシング を 確認 し し ます。

分散 を 使用 し て いる いる ため 、 デバッグ デバッグ は 新しい ツール である 分散 トレース が 必要 です。 ツール ツール を 使用 、 相互 作用 作用 相互 作用 相互 相互 相互 作用 作用 情報 作用 情報 情報 情報 情報 統計イベント の 検出 など） を 見つけ たり たり 、 生 の サンプル トレース を 見 て 、 実際 に 何 が 起こっ て いる の の か 調べ たり たり する ことができ ます。。。。 ことができ ます。。।

タイム に は は 最終 的 的 に エンド ユーザー ユーザー 応答 する まで の の すべて の リクエスト が 時 系列 に 表示 さ ます。 から から グラフ グラフ によって 時間 時間 の の の の の の の まで の の まで まで の リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト リクエスト。 ドット が 高く なる ほど 、 ユーザー ユーザー エクスペリエンス が なり なり ます （そして 不幸 に なり ます！！））

ドット クリック する と 、 その その 特定 の リクエスト の 詳細 な ウォーター フォール ビュー を 見つける ことができ ます。 の 詳細 の の だけでなく）） 見つける 見つける 理解 理解 を 相互 相互 の の の の の の の 間 の の の の の の の の の 間 間 間 間 間 間 間 間 間 間 間 間する ため に 、 特に サービス 間 の の まれ で は ある 良く ない 相互 作用 を 探し出す 場合 に に 不可欠 です。。。。

ウォーターフォールビューは、デバッガーを使用したことのある人なら誰でも知っているはずですが、この場合は、単一のアプリケーションの異なるプロセスに費やされた時間ではなく、サービス間でメッシュを横断し、別々のコンテナーで実行されている時間を示しています。

ここでトレースを見つけることができます。:

echo "https://console.cloud.google.com/traces/overview?cloudshell=false&project=${TF_VAR_ops_project_name}"

ツールのスクリーンショットの例:

5ee238836dc9047f.png

  1. クラスター内の可観測ツールを公開します。

PrometheuとGrafanaは、opsクラスターのIstioコントロールプレーンの一部として展開されるオープンソースの可観測性ツールです。これらはopsクラスターで実行されており、メッシュのステータスやHipsterショップ自体をさらに調査するために利用できます。

これらのツールを表示するには、Cloud Shellから次のコマンドを実行するだけです（見るべきものがあまり無いため、Prometheusはスキップします）:

kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null &

次に、公開されたサービス（3000）をCloud Shell Webプレビュータブで開きます。

Grafanaは、Stackdriverのカスタムダッシュボードに似たメトリックダッシュボードシステムです。 Istioのインストールには、特定のIstioメッシュで実行されているサービスとワークロードのメトリック、およびIsito Control Plane自体のヘルスを表示するために使用できるいくつかのビルド済みダッシュボードが付属しています。

8. 相互TLS認証

目標: マイクロサービス間でセキュアな接続を設定する(認証)

  • メッシュ全体でmTLSを有効化
  • 調査ログを使いmTLSを確認

アプリがインストールされ、可観測性が確保できたので、サービス間の接続の保護し、機能し続けることを確認します。

たとえば、Kialiダッシュボードで、サービスがmTLSを使用していないことを確認できます（"ロック"アイコンなし）。しかし、トラフィックは流れており、システムは正常に動作しています。 StackDriver ゴールデンメトリクスダッシュボードは、全体的としてシステムが機能しているという安心感を与えてくれます。

  1. opsクラスターのMeshPolicyを確認します。注. mTLSは永続的であり、暗号化されたトラフィックと非mTLSトラフィックの両方を許可します。 
kubectl --context ${OPS_GKE_1} get MeshPolicy -o yaml
kubectl --context ${OPS_GKE_2} get MeshPolicy -o yaml
 

    `出力結果（コピーしないでください）`

  spec:
    peers:
    - mtls:
        mode: PERMISSIVE
  1. mTLSをオンにします。 Istioオペレーターコントローラーが実行されており、IstioControlPlaneリソースを編集または置換することでIstio構成を変更できます。コントローラーは変更を検出し、それに応じてIstioインストール状態を更新することで対応します。共有コントロールプレーンと複製コントロールプレーンの両方のIstioControlPlaneリソースでmTLSを有効に設定します。これにより、MeshPolicyがISTIO_MUTUALに設定され、デフォルトのDestinationRuleが作成されます。
cd ${WORKDIR}/asm
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${OPS_GKE_1_CLUSTER}/istio-controlplane/istio-replicated-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${OPS_GKE_2_CLUSTER}/istio-controlplane/istio-replicated-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV1_GKE_1_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV1_GKE_2_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV2_GKE_1_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV2_GKE_2_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml
  1. k8s-repo にコミットします。
cd ${WORKDIR}/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
  1. ロールアウトが完了するのを待ちます。 
${WORKDIR}/asm/scripts/stream_logs.sh $TF_VAR_ops_project_name

mTLSの動作確認

  1. opsクラスターでMeshPolicyをもう一度確認します。注. 非暗号トラフィックは許可されず、mTLSトラフィックのみを許可します。
kubectl --context ${OPS_GKE_1} get MeshPolicy -o json | jq .items[].spec
kubectl --context ${OPS_GKE_2} get MeshPolicy -o json | jq .items[].spec

出力結果（コピーしないでください）:

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}
  1. Istioオペレーターコントローラーによって作成されたDestinationRuleを確認します。
kubectl --context ${OPS_GKE_1} get DestinationRule default -n istio-system -o yaml
kubectl --context ${OPS_GKE_2} get DestinationRule default -n istio-system -o yaml

出力結果（コピーしないでください）:

  apiVersion: networking.istio.io/v1alpha3
  kind: DestinationRule
  metadata:  
    name: default
    namespace: istio-system
  spec:
    host: '*.local'
    trafficPolicy:
      tls:
        mode: ISTIO_MUTUAL

また、ログからHTTPからHTTPSへの移行を確認できます。 UIのログからこの特定のフィールドを公開するには、ログエントリを1つクリックしてから、表示したいフィールドの値をクリックします。この場合、「プロトコル」の横にある「http」をクリックします。:

d92e0c88cd5b2132.png

これにより、mTLSの有効化を確認する良い方法が得られます。:

ea3d0240fa6fed81.png

また、ログエントリをメトリックに変換し、時系列のグラフを表示することもできます。:

TODO(smcghee)

9. カナリアデプロイメント

目標: frontendサービスの新バージョンをロールアウトする

  • Frontend-v2 (次のプロダクションバージョン)サービスを1リージョンにロールアウト
  • DestinationRulesとVirtualServicesを使い徐々にトラフィックをfrontend-v2に転送
  • k8s-repoに複数のコミットを行い、GitOpsデプロイパイプラインを確認

カナリアデプロイメントは、新しいサービスの段階的なロールアウト手法です。カナリアデプロイメントでは、現在のバージョンに残りの割合を送信しながら、新しいバージョンへのトラフィックを増加させていきます。一般的なパターンは、トラフィック分割の各段階でカナリア分析を実行し、新しいバージョンの「ゴールデンシグナル」（レイテンシ、エラー率、飽和）をベースラインと比較することです。これにより、サービス停止を防ぎ、トラフィック分割のあらゆる段階で新しい"v2"サービスの安定性を確保できます。

このセクションでは、Cloud BuildおよびIstioのトラフィックポリシーを使用して、 frontendサービスで新しいバージョンの基本的なカナリアデプロイメントを作成する方法を学習します。

まず、**DEV1リージョン（us-west1）**でカナリアパイプラインを実行し、そのリージョンの両方のクラスターでfrontend v2を展開します。次に、**DEV2リージョン（us-central）**でカナリアパイプラインを実行し、そのリージョンの両方のクラスターにv2を展開します。リージョンごとにパイプラインを順番に実行することは、すべてのリージョンで並列に実行するのではなく、不適切な構成またはv2アプリ自体のバグによって引き起こされるグローバルな停止を回避するのに役立ちます。

注：両方のリージョンでカナリアパイプラインを手動でトリガーしますが、実稼働環境では、たとえばレジストリにプッシュされた新しいDockerイメージタグに基づいて、自動トリガーを使用します。

  1. Cloud Shellから、カナリアディレクトリに移動します。:
CANARY_DIR="${WORKDIR}/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="${WORKDIR}/k8s-repo"
  1. repo_setup.shスクリプトを実行して、ベースラインマニフェストをk8s-repoにコピーします。
cd $CANARY_DIR
./repo-setup.sh

次のマニフェストがコピーされます。:

  • frontend-v2 deployment
  • frontend-v1パッチ ("v1"ラベルと"/ version"エンドポイントを持つコンテナイメージを含める)
  • respy , HTTP応答の分布を書き出し、カナリアデプロイメントをリアルタイムで視覚化するのに役立つ小さなPod。
  • frontend Istio DestinationRule - "バージョン"デプロイメントラベルに基づいて、frontend Kubernetesサービスを2つのサブセット、v1とv2に分割します
  • frontend Istio VirtualService - トラフィックの100％をfrontend v1にルーティングします。これにより、Kubernetesサービスのデフォルトのラウンドロビン動作が上書きされ、すべてのDev1リージョントラフィックの50％がfrontend v2に直ちに送信されます。
  1. 変更内容をk8s_repoにコミットします。 :
cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
cd $CANARY_DIR
  1. Ops1プロジェクトのコンソールでCloud Buildに移動します。 Cloud Buildパイプラインが完了するまで待ってから、両方のDEV1クラスターのfrontend namespaceでPodを取得します。以下が表示されるはずです。:
watch -n 1 kubectl --context ${DEV1_GKE_1} get pods -n frontend

出力結果（コピーしないでください）

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s
  1. 別のCloud Shellセッションを開きます。 DEV1_GKE_1で実行されている新しいRespy Podに入ります。
RESPY_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n frontend | grep respy | awk '{ print $1 }')
kubectl --context ${DEV1_GKE_1} exec -n frontend -it $RESPY_POD -c respy /bin/sh
  1. watchコマンドを実行して、frontendサービスのHTTP応答の分布を確認します。すべてのトラフィックは、新しいVirtualServiceで定義されたfrontend v1 deploymentに向かうことがわかります。
watch -n 1 ./respy --u http://frontend:80/version --c 10 --n 500

出力結果（コピーしないでください）

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+
  1. 前のCloud Shellセッションに戻り、Dev2リージョンでカナリアパイプラインを実行します。 VirtualServiceのfrontend v2トラフィックの割合を更新するスクリプトを提供します（重みを20％、50％、80％、100％に更新します）。それぞれの更新の間で、スクリプトはCloud Buildパイプラインが完了するのを待ちます。 Dev1リージョンのカナリアデプロイメントスクリプトを実行します。注-このスクリプトの完了には約10分かかります。
cd ${CANARY_DIR}
K8S_REPO=${K8S_REPO} CANARY_DIR=${CANARY_DIR} OPS_DIR=${OPS_GKE_1_CLUSTER} OPS_CONTEXT=${OPS_GKE_1} ./auto-canary.sh

このスクリプトを実行中に、respyコマンドを実行している2番目のCloud Shellセッションに移動して、トラフィックの分割をリアルタイムで確認できます。たとえば、20％のときには次のようになります：

出力結果（コピーしないでください）

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+
  1. frontend v2のDev1ロールアウトが完了すると、スクリプトの最後に成功メッセージが表示されます。
    出力結果（コピーしないでください） 

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod
  1. そして、Dev1 Podからのすべてのfrontendトラフィックはfrontend v2に向いていなければなりません。:
    出力結果（コピーしないでください） 

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+
  1. **Cloud Source Repos > k8s_repoに移動します。**トラフィックの割合ごとに個別のコミットが表示され、最新のコミットがリストの一番上に表示されます。:

b87b85f52fd2ff0f.png

  1. Dev1でrespy Podを終了します。次に、Dev2リージョンで実行されているrespy Podに入ります。
RESPY_POD=$(kubectl --context ${DEV2_GKE_1} get pod -n frontend | grep respy | awk '{ print $1 }')
kubectl --context ${DEV2_GKE_1} exec -n frontend -it $RESPY_POD -c respy /bin/sh
  1. respyコマンドを再度実行します。:
watch -n 1 ./respy --u http://frontend:80/version --c 10 --n 500

出力結果（コピーしないでください）

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

*Dev2リージョンは、v1ではまだ"ロック"されていることに注意してください。*これは、ベースラインのrepo_setupスクリプトで、VirtualServiceをプッシュして、すべてのトラフィックを明示的にv1に送信したためです。このようにして、Dev1でリージョンのカナリアを安全に実行し、新しいバージョンをグローバルに展開する前にそれが正常に実行されたことを確認できました。

  1. Dev2リージョンで自動カナリアスクリプトを実行します。
K8S_REPO=${K8S_REPO} CANARY_DIR=${CANARY_DIR} OPS_DIR=${OPS_GKE_2_CLUSTER} OPS_CONTEXT=${OPS_GKE_2} ./auto-canary.sh
  1. Dev2のRespy Podから、Dev2 Podからのトラフィックがfrontend v1からv2に徐々に移動するのを見てください。スクリプトが完了すると、次のように表示されます。:

出力結果（コピーしないでください）

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

このセクションでは、リージョンのカナリアデプロイメントにIstioを使用する方法を紹介しました。本番環境では、手動のスクリプトの代わりに、コンテナレジストリにプッシュされた新しいタグ付きコンテナイメージなどのトリガーを使用して、このカナリアスクリプトをCloud Buildパイプラインとして自動的にトリガーできます。また、各ステップの間にカナリア分析を追加して、トラフィックを送信する前に、事前定義された安全なしきい値に対してv2のレイテンシとエラー率を分析することもできます。

10. 認可ポリシー

目標: マイクロサービス間でRBACをセットアップする (認可)

  • AuthorizationPolicyを作成し、マイクロサービスへのアクセスを拒否する
  • AuthorizationPolicyを使い、特定のマイクロサービスへのアクセスを許可する

1か所で実行される可能性のあるモノリシックアプリケーションとは異なり、グローバルに分散したマイクロサービスアプリは、ネットワークの境界を越えて呼び出しを行います。つまり、アプリケーションへのエントリポイントが増え、悪意のある攻撃を受ける機会が増えます。また、Kubernetes Podには一時的なIPアドレスがあるため、従来のIPアドレスベースのファイアウォールルールは、ワークロード間のアクセスを保護するには不十分です。マイクロサービスアーキテクチャでは、セキュリティへの新しいアプローチが必要です。サービスアカウントなどのKubernetesセキュリティビルディングブロックに基づいて、Istioはアプリケーションに柔軟なセキュリティポリシーのセットを提供します。

Istioポリシーは、認証と認可の両方を対象としています。認証はIDを検証し（このサーバーは本人であると言っていますか？）、認可は権限を検証します（このクライアントは許可されていますか？）。モジュール1（MeshPolicy）の相互TLSセクションでIstio認証について説明しました。このセクションでは、Istio認可ポリシーを使用して、アプリケーションワークロードの1つであるcurrencyserviceへのアクセスを制御する方法を学習します。

最初に、4つのDevクラスターすべてにAuthorizationPolicyをデプロイし、currencyserviceへのすべてのアクセスを遮断し、frontendでエラーをトリガーします。次に、frontendサービスのみがcurrencyserviceにアクセスできるようにします。

  1. 認可のサンプルディレクトリに移動します。
export AUTHZ_DIR="${WORKDIR}/asm/k8s_manifests/prod/app-authorization"
export K8S_REPO="${WORKDIR}/k8s-repo"

cd $AUTHZ_DIR
  1. currency-deny-all.yamlの内容を見てみます。このポリシーは、Deploymentラベルセレクターを使用して、currencyserviceへのアクセスを制限します。 specフィールドがないことに注意してください-これは、このポリシーが選択したサービスへのすべてのアクセスを拒否することを意味します。
cat currency-deny-all.yaml

出力結果（コピーしないでください）

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  1. 両方のリージョンのopsクラスターのcurrencyポリシーをk8s-repoにコピーします。
mkdir -p ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/
sed -i '/  - app-ingress\//a\ \ - app-authorization\/' ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/kustomization.yaml
cp currency-deny-all.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/; kustomize create --autodetect
cd $AUTHZ_DIR 

mkdir -p ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/
sed -i '/  - app-ingress\//a\ \ - app-authorization\/' ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/kustomization.yaml
cp currency-deny-all.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/; kustomize create --autodetect
  1. 変更をプッシュします。
cd $K8S_REPO 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push
cd $AUTHZ_DIR
  1. ブラウザでHipsterショップアプリのfrontendにアクセスしてみてください:
echo "https://frontend.endpoints.${TF_VAR_ops_project_name}.cloud.goog"

currencyserviceから認可エラーが表示されるはずです:

f120f3d30d6ee9f.png

  1. currencyサービスがこのAuthorizationPolicyをどのように適用しているかを調べてみましょう。最初に、ブロックされた認可呼び出しはデフォルトでは記録されないため、currency PodのいずれかのEnvoyプロキシでトレースレベルのログを有効にします。
CURRENCY_POD=$(kubectl --context ${DEV1_GKE_2} get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context ${DEV1_GKE_2} exec -it $CURRENCY_POD -n currency -c istio-proxy /bin/sh 
curl -X POST "http://localhost:15000/logging?level=trace"; exit
  1. currencyサービスのサイドカープロキシからRBAC（認可）ログを取得します。 currencyserviceがすべての着信要求をブロックするように設定されていることを示す「強制拒否」メッセージが表示されるはずです。
kubectl --context ${DEV1_GKE_2} logs -n currency $CURRENCY_POD -c istio-proxy | grep -m 3 rbac

出力結果（コピーしないでください）

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied
  1. 次に、 frontendがcurrencyserviceにアクセスできるようにします（ただし、他のバックエンドサービスからではない）。 currency-allow-frontend.yamlを開き、その内容を調べます。次のルールを追加したことに確認してください。:
cat currency-allow-frontend.yaml

出力結果（コピーしないでください）

rules:
 - from:
   - source:
       principals: ["cluster.local/ns/frontend/sa/frontend"]

ここでは、特定のsource.principal （クライアント）をホワイトリストに登録して、currencyサービスにアクセスしています。このsource.principalは、Kubernetesサービスアカウントによって定義されます。この場合、ホワイトリストに登録するサービスアカウントは、frontend namespaceのfrontendサービスアカウントです。

注：Istio AuthorizationPoliciesでKubernetesサービスアカウントを使用する場合、モジュール1で行ったように、最初にクラスター全体の相互TLSを有効にする必要があります。これは、サービスアカウントの資格情報がリクエストにマウントされるようにするためです。

  1. 更新されたcurrencyポリシーをコピーします。
cp $AUTHZ_DIR/currency-allow-frontend.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cp $AUTHZ_DIR/currency-allow-frontend.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml
  1. 更新をプッシュします。
cd $K8S_REPO 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
cd $AUTHZ_DIR
  1. Cloud Buildの完了を待ちます。
  2. Hipsterショップアプリのfrontendを再度開きます。今回は、ホームページにエラーが表示されないはずです。これは、frontendが現在のサービスにアクセスすることを明示的に許可しているためです。
  3. 次に、カートにアイテムを追加し、"place order"をクリックして、チェックアウトを実行してください。今回は、currencyサービスから価格変換エラーが表示されるはずです。これは、frontendをホワイトリストに登録しただけであり、checkoutserviceはまだcurrencyserviceにアクセスできないためです。

7e30813d693675fe.png

  1. 最後に、別のルールをcurrencyservice AuthorizationPolicyに追加して、 checkoutサービスがcurrency serviceにアクセスできるようにします。frontendとcheckoutの2つのサービスからのcurrency serviceのアクセスのみを開放していることに注意してください。他のバックエンドサービスは引き続きブロックされます。
  2. currency-allow-frontend-checkout.yamlを開き、その内容を見てみます。ルールのリストは論理ORとして機能することに注意してください。currency serviceは、これら2つのサービスアカウントのいずれかを持つワークロードからの要求のみを受け入れます。
cat currency-allow-frontend-checkout.yaml

出力結果（コピーしないでください）

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]
  1. 最終的な認可ポリシーをk8s-repoにコピーします。
cp $AUTHZ_DIR/currency-allow-frontend-checkout.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cp $AUTHZ_DIR/currency-allow-frontend-checkout.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml
  1. 更新をプッシュします。
cd $K8S_REPO 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
  1. Cloud Build の完了を待ちます。
  2. チェックアウトを実行してみてください。正常に動作するはずです。

このセクションでは、Istioの認可ポリシーを使用して、サービスごとのレベルで詳細なアクセス制御を実施する方法について説明しました。実稼働環境では、サービスごとに1つのAuthorizationPolicyを作成し、（たとえば） allow-allポリシーを使用して、同じネームスペース内のすべてのワークロードが相互にアクセスできるようにします。

11. インフラストラクチャのスケーリング

目標: 新しいリージョン、プロジェクト、クラスターを追加しインフラストラクチャをスケールする

  • infrastructureリポジトリをクローン
  • 新しいリソースを作成するため、terraformファイルを更新
  • 新しいリージョンに2つのサブネット (1つがopsプロジェクト用、もう一つが新しいプロジェクト用)
  • 新しいリージョンに新しいopsクラスター (新しいサブネット内に)
  • 新しいリージョンに新しいIstioコントロールプレーン
  • 新しいリージョンの新しいプロジェクトに2つのappsクラスター
  • infrastructureリポジトリにコミット
  • セットアップを確認

プラットフォームをスケールするには、いくつかの方法があります。既存のクラスターにノードを追加することにより、さらに計算リソースを追加できます。リージョン内にさらにクラスターを追加できます。または、プラットフォームにさらにリージョンを追加できます。プラットフォームのどの側面を拡張するかの決定は、要件に依存します。たとえば、リージョン内の3つのゾーンすべてにクラスターがある場合、おそらく既存のクラスターにノード（またはノードプール）を追加すれば十分です。ただし、1つのリージョンの3つのゾーンのうち2つにクラスターがある場合、3番目のゾーンに新しいクラスターを追加すると、スケーリングと追加のフォールトドメイン（つまり、新しいゾーン）が得られます。リージョンに新しいクラスターを追加するもう1つの理由は、規制またはコンプライアンスの理由（PCI、PII情報を格納するデータベースクラスターなど）のために、単一のテナントクラスターを作成する必要がある場合があります。ビジネスとサービスが拡大するにつれて、クライアントにより近くでサービスを提供するために新しいリージョンを追加することが避けられなくなります。

現在のプラットフォームは、2つのリージョンと、リージョンごとに2つのゾーンのクラスターで構成されています。プラットフォームのスケーリングは、次の2つの方法で考えることができます。:

  • 垂直- リージョンにより多くのコンピューティングを追加します。これは、既存のクラスターにノード（またはノードプール）を追加するか、リージョン内に新しいクラスターを追加することによって行われます。これは、 infrastructureリポジトリを介して行われます。最も簡単な方法は、既存のクラスターにノードを追加することです。追加の構成は必要ありません。新しいクラスターを追加するには、追加のサブネット（およびセカンダリーレンジ）、適切なファイアウォールルールの追加、新しいクラスターのリージョンASM / Istioサービスメッシュコントロールプレーンへの追加、アプリケーションリソースの新しいクラスターへのデプロイが必要になる場合があります。
  • 水平- さらにリージョンを追加します。現在のプラットフォームは、リージョンのテンプレートを提供します。 ASM / Istioコントロールが常駐するリージョナルopsクラスターと、アプリケーションリソースがデプロイされる2つ（またはそれ以上）のゾーンアプリケーションクラスターで構成されます。

このワークショップでは、垂直ユースケースのステップも含まれるため、プラットフォームを"水平"にスケーリングします。プラットフォームに水平に新しいリージョン（r3）を追加してプラットフォームをスケーリングするには、次のリソースを追加する必要があります。:

  1. 新しいオペレーションとアプリケーションクラスター用にリージョンr3の共有VPCにホストプロジェクトのサブネット
  2. ASM / Istioコントロールプレーンが存在するリージョンr3のリージョナルopsクラスター
  3. リージョンr3の2つのゾーンにある2つのゾーンアプリケーションクラスター
  4. k8s-repoへの更新:
  5. ASM / Istioコントロールプレーンリソースをリージョンr3のopsクラスターにデプロイ
  6. ASM / Istio共有コントロールプレーンリソースをリージョンr3のアプリクラスターにデプロイ
  7. 新しいプロジェクトを作成する必要はありませんが、ワークショップの手順では、プラットフォームに新しいチームを追加するユースケースをカバーする新しいプロジェクトdev3を追加する方法を示します。

infrastructureリポジトリは、上記の新しいリソースを追加するために使用されます。

  1. Cloud Shellで、WORKDIRに移動し、 infrastructureリポジトリのクローンを作成します。
cd ${WORKDIR}
mkdir -p ${WORKDIR}/infra-repo
cd ${WORKDIR}/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure

git config --local user.email ${MY_USER} && git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master
  1. asm（メインワークショップ）リポジトリからadd-projブランチをチェックアウトします。 add-projブランチには、このセクションの変更内容が含まれています。
cd ${WORKDIR}/asm
git checkout add-proj
cd ${WORKDIR}
  1. メインワークショップのadd-projブランチからinfrastructureリポジトリに新しいリソースと変更されたリソースをコピーします。
cp -r asm/infrastructure/apps/prod/app3 ./infra-repo/apps/prod/.
cp -r asm/infrastructure/cloudbuild.yaml ./infra-repo/cloudbuild.yaml
cp -r asm/infrastructure/network/prod/shared_vpc/main.tf ./infra-repo/network/prod/shared_vpc/main.tf
cp -r asm/infrastructure/network/prod/shared_vpc/variables.tf ./infra-repo/network/prod/shared_vpc/variables.tf
cp -r asm/infrastructure/ops/prod/cloudbuild/config/cloudbuild.tpl.yaml ./infra-repo/ops/prod/cloudbuild/config/cloudbuild.tpl.yaml
cp -r asm/infrastructure/ops/prod/cloudbuild/main.tf ./infra-repo/ops/prod/cloudbuild/main.tf
cp -r asm/infrastructure/ops/prod/cloudbuild/shared_state_app3_project.tf ./infra-repo/ops/prod/cloudbuild/shared_state_app3_project.tf
cp -r asm/infrastructure/ops/prod/cloudbuild/shared_state_app3_gke.tf ./infra-repo/ops/prod/cloudbuild/shared_state_app3_gke.tf
cp -r asm/infrastructure/ops/prod/k8s_repo/build_repo.sh ./infra-repo/ops/prod/k8s_repo/build_repo.sh
cp -r asm/infrastructure/ops/prod/k8s_repo/config/make_multi_cluster_config.sh ./infra-repo/ops/prod/k8s_repo/config/make_multi_cluster_config.sh
cp -r asm/infrastructure/ops/prod/k8s_repo/main.tf ./infra-repo/ops/prod/k8s_repo/main.tf
cp -r asm/infrastructure/ops/prod/k8s_repo/shared_state_app3_project.tf ./infra-repo/ops/prod/k8s_repo/shared_state_app3_project.tf
cp -r asm/infrastructure/ops/prod/k8s_repo/shared_state_app3_gke.tf ./infra-repo/ops/prod/k8s_repo/shared_state_app3_gke.tf
cp -r asm/infrastructure/ops/prod/ops_gke/main.tf ./infra-repo/ops/prod/ops_gke/main.tf
cp -r asm/infrastructure/ops/prod/ops_gke/outputs.tf ./infra-repo/ops/prod/ops_gke/outputs.tf
cp -r asm/infrastructure/ops/prod/ops_gke/variables.tf ./infra-repo/ops/prod/ops_gke/variables.tf
cp -r asm/infrastructure/ops/prod/ops_project/main.tf ./infra-repo/ops/prod/ops_project/main.tf
  1. add-project.shスクリプトを実行します。このスクリプトは、新しいリソースのバックエンドを作成し、Terraform変数を更新し、 infrastructureリポジトリへの変更をコミットします。
./asm/scripts/add-project.sh
  1. コミットにより、 infrastructureリポジトリがトリガーされ、新しいリソースでインフラストラクチャがデプロイされます。次のリンクの出力をクリックし、上部の最新ビルドに移動して、Cloud Buildの進行状況を表示します。
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"

Infrastructure Cloud Buildの最後のステップでは、 k8s-repoに新しいKubernetesリソースが作成されます。これにより、 k8s-repo （opsプロジェクト内）でCloud Buildがトリガーされます。新しいKubernetesリソースは、前の手順で追加された3つの新しいクラスター用です。 ASM / Istioコントロールプレーンおよび共有コントロールプレーンリソースは、 k8s-repo Cloud Buildを使用して新しいクラスターに追加されます。

  1. infrastructure Cloud Buildが正常に終了したら、次の出力されたリンクをクリックして、実行されたk8s-repoの最新のCloud Buildに移動します。
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  1. 次のスクリプトを実行して、新しいクラスターをvarsおよびkubeconfigファイルに追加します。
chmod +x ./asm/scripts/setup-gke-vars-kubeconfig-add-proj.sh
./asm/scripts/setup-gke-vars-kubeconfig-add-proj.sh
  1. KUBECONFIG変数を変更して、新しいkubeconfigファイルを指すようにします。
source ${WORKDIR}/asm/vars/vars.sh
export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh
  1. クラスターコンテキストを一覧表示します。 8つのクラスターが表示されるはずです。 
kubectl config view -ojson | jq -r '.clusters[].name'
 

    `出力結果（コピーしないでください）`

gke_user001-200204-05-dev1-49tqc4_us-west1-a_gke-1-apps-r1a-prod
gke_user001-200204-05-dev1-49tqc4_us-west1-b_gke-2-apps-r1b-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-a_gke-3-apps-r2a-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-b_gke-4-apps-r2b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-b_gke-5-apps-r3b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-c_gke-6-apps-r3c-prod
gke_user001-200204-05-ops-49tqc4_us-central1_gke-asm-2-r2-prod
gke_user001-200204-05-ops-49tqc4_us-east1_gke-asm-3-r3-prod
gke_user001-200204-05-ops-49tqc4_us-west1_gke-asm-1-r1-prod

Istioインストールの確認

  1. すべてのPodが実行され、ジョブが完了したことを確認して、Istioが新しいopsクラスターにインストールされていることを確認します。 
kubectl --context ${OPS_GKE_3} get pods -n istio-system
 

    `出力結果（コピーしないでください）`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m
  1. Istioが両方のdev3クラスターにインストールされていることを確認してください。 dev3クラスターで実行されるのは、Citadel、sidecar-injector、corednのみです。 ops-3クラスターで実行されているIstioコントロールプレーンを共有します。 
kubectl --context ${DEV3_GKE_1} get pods -n istio-system
kubectl --context ${DEV3_GKE_2} get pods -n istio-system
 

    `出力結果（コピーしないでください）`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

共有コントロールプレーンのサービスディスカバリを確認

  1. オプションで、6つのアプリケーションクラスターのすべてのopsクラスターにSecretがデプロイされていることを確認します。 
kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_3} get secrets -l istio/multiCluster=true -n istio-system
 

    `出力結果（コピーしないでください）`

NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      14h
gke-2-apps-r1b-prod   Opaque   1      14h
gke-3-apps-r2a-prod   Opaque   1      14h
gke-4-apps-r2b-prod   Opaque   1      14h
gke-5-apps-r3b-prod   Opaque   1      5h12m
gke-6-apps-r3c-prod   Opaque   1      5h12m

12. サーキットブレーカー

目標: サーキットブレーカーをshippingサービスに実装

  • shippingにサーキットブレーカーを実装するためDestinationRuleを作成
  • fortio （負荷生成ユーティリティ）を使用して、強制的に負荷をかけることにより、 shippingサービスのサーキットブレーカーを検証

Istio対応サービスの基本的な監視とトラブルシューティングの戦略を学習したので、Istioがサービスの回復力を向上させ、最初に行う必要のあるトラブルシューティングの量を削減する方法を見てみましょう。

マイクロサービスアーキテクチャは、1つのサービスの障害がその依存関係とその依存関係の依存関係に伝播し、エンドユーザーに影響を与える可能性のある「リップル効果」障害を引き起こすカスケード障害のリスクをもたらします。 Istioは、サービスを分離するのに役立つサーキットブレーカートラフィックポリシーを提供し、ダウンストリーム（クライアント側）サービスが障害のあるサービスを待機するのを防ぎ、アップストリーム（サーバー側）サービスがダウンストリームトラフィックの突然の大量アクセスから保護されます。全体的に、サーキットブレーカーを使用すると、1つのバックエンドサービスがハングしているためにすべてのサービスがSLOに失敗することを回避できます。

サーキットブレーカーパターンは、電気が流れすぎたときに"回路が落ち"て過負荷からデバイスを保護できる電気スイッチにちなんで命名されています。 Istioのセットアップでは、これはEnvoyがサーキットブレーカーであり、サービスに対する保留中のリクエストの数を追跡することを意味します。このデフォルトの"閉じた"状態では、リクエストはEnvoyが中断せずにプロキシします。

ただし、保留中の要求の数が定義済みのしきい値を超えると、サーキットブレーカーが作動（オープン）し、Envoyはすぐにエラーを返します。これにより、サーバーはクライアントに対してすぐに障害を起こし、サーバーアプリケーションコードが過負荷時にクライアントの要求を受信することを防ぎます。

次に、定義されたタイムアウトの後、Envoyはハーフオープン状態に移行します。サーバーは試用的な方法でリクエストの受信を再開できます。リクエストに正常に応答できる場合、サーキットブレーカーは再び閉じ、サーバーへのリクエストが開始され、再び流れ始めます。

この図は、Istioサーキットブレーカーパターンをまとめたものです。青い長方形はEnvoyを表し、青い丸はクライアントを表し、白い丸はサーバーコンテナを表します。

2127a0a172ff4802.png

IstioのDestinationRulesを使用して、サーキットブレーカーポリシーを定義できます。このセクションでは、次のポリシーを適用して、shippingサービスにサーキットブレーカーを適用します。:

出力結果（コピーしないでください）

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

ここで注意すべき2つのDestinationRuleフィールドがあります。 ** connectionPool **は、このサービスが許可する接続の数を定義します。 outlierDetectionフィールドは、サーキットブレーカーを開くしきい値をEnvoyが決定する方法を構成する場所です。ここでは、毎秒（間隔）、Envoyはサーバーコンテナーから受信したエラーの数をカウントします。 ** consecutiveErrors **しきい値を超えると、Envoyサーキットブレーカーが開き、productcatalog Podの100％が10秒間新しいクライアント要求から保護されます。 Envoyサーキットブレーカーが開いている（アクティブになっている）場合、クライアントは503（Service Unavailable）エラーを受け取ります。これを実際に見てみましょう。

  1. サーキットブレーカーディレクトリに移動します。
export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm"
  1. 両方のOpsクラスターでshipping serviceのDestinationRuleを更新します。
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
  1. Fortio負荷生成PodをDev1リージョンのGKE_1クラスターにコピーします。これは、shippingserviceのサーキットブレーカーを"作動"させるために使用するクライアントPodです。
cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml
  1. 変更をコミットします。
cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
  1. Cloud Buildの完了を待ちます。
  2. Cloud Shellに戻り、fortio Podを使用して、gRPCトラフィックを1つの同時接続でshippingServiceに送信します。（合計1000リクエスト） connectionPool設定をまだ超えていないため、サーキットブレーカーは作動しません。
FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 1 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051

出力結果（コピーしないでください）

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps
  1. ここでfortioを再度実行し、同時接続数を2に増やしますが、リクエストの総数は一定に保ちます。サーキットブレーカーが作動したため、リクエストの最大3分の2が"オーバーフロー"エラーを返します。定義したポリシーでは、1秒間隔で許可される同時接続は1つのみです。
kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051

出力結果（コピーしないでください）

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps
  1. Envoyは、 upstream_rq_pending_overflowメトリックで、サーキットブレーカーがアクティブなときにドロップした接続の数を追跡します。これをfortio Podで見つけましょう。:
kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending

出力結果（コピーしないでください）

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433
  1. 両方のリージョンからサーキットブレーカーポリシーを削除してクリーンアップします。
kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master

このセクションでは、サービスに単一のサーキットブレーカーポリシーを設定する方法を示しました。ベストプラクティスは、ハングする可能性のあるアップストリーム（バックエンド）サービスにサーキットブレーカーを設定することです。 Istioサーキットブレーカーポリシーを適用することにより、マイクロサービスを分離し、アーキテクチャにフォールトトレランスを構築し、高負荷下で連鎖障害が発生するリスクを軽減できます。

13. フォールトインジェクション（Fault Injection）

目標: （本番環境にプッシュされる前に）意図的に遅延を発生させることにより、recommendationサービスの回復力をテストする

  • recommendationサービスのVirtualServiceを作成し5秒の遅延を発生させる
  • fortio負荷発生ツールで遅延をテスト
  • VirtualServiceから遅延を取り除き、確認

サービスにサーキットブレーカーポリシーを追加することは、運用中のサービスに対する回復力を構築する1つの方法です。しかし、サーキットブレーカーは障害（潜在的にユーザー側のエラー）をもたらし、これは理想的ではありません。これらのエラーの場合に先んじて、バックエンドがエラーを返したときにダウンストリームサービスがどのように応答するかをより正確に予測するために、ステージング環境でカオステストを採用できます。カオステストは、システム内の弱点を分析し、フォールトトレランスを向上させるために、意図的にサービスを中断する方法です。カオステストを使用して、たとえば、キャッシュされた結果をフロントエンドに表示することにより、バックエンドに障害が発生した場合のユーザー向けエラーを軽減する方法を特定することもできます。

Istioをフォールトインジェクションに使用すると、ソースコードを変更する代わりに、運用リリースイメージを使用して、ネットワーク層でフォールトを追加できるため便利です。本番環境では、本格的なカオステストツールを使用して、ネットワークレイヤーに加えてKubernetes / computeレイヤーで復元力をテストできます。

VirtualServiceに"fault"フィールドを適用することにより、Istioをカオステストに使用できます。 Istioは、2種類のフォールトをサポートしています。遅延フォールト（タイムアウトを挿入）とアボートフォールト（HTTPエラーを挿入）です。この例では、 5秒の遅延エラーをrecommendation serviceに挿入します。ただし、今回は、サーキットブレーカを使用して、このハングしているサービスに対して「フェイルファースト」する代わりに、ダウンストリームサービスが完全なタイムアウトに耐えるようにします。

  1. フォールトインジェクションディレクトリに移動します。
export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
  1. k8s_manifests / prod / istio-networking / app-recommendation-vs-fault.yamlを開いてその内容を検査します。 Istioには、リクエストのパーセンテージにフォールトを挿入するオプションがあることに注意してください。ここでは、すべてのrecommendationserviceリクエストにタイムアウトを挿入します。

出力結果（コピーしないでください）

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s
  1. VirtualServiceをk8s_repoにコピーします。グローバルに障害を挿入するため両方のリージョンに設定を行います。
cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml
  1. 変更をプッシュします。
cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
  1. Cloud Buildの完了を待ちます。
  2. サーキットブレーカーセクションでデプロイされたfortio Podに入り、いくつかのトラフィックをrecommendationserviceに送信します。 
FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

    fortioコマンドが完了すると、応答に平均5秒かかっていることが表示されます。

出力結果（コピーしないでください）

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055
  1. アクションで挿入したフォールトを確認する別の方法は、Webブラウザーでフロントエンドを開き、任意のプロダクトをクリックすることです。製品ページは、ページの下部に表示されるrecommend情報を取得するため、ロードにさらに5秒かかります。
  2. 両方のOpsクラスターからフォールトインジェクションサービスを削除してクリーンアップします。
kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml
  1. 変更をプッシュします。 
cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM

14. Istioコントロールプレーンの監視

ASMは、Pilot、Mixer、Galley、Citadelの4つの重要なコントロールプレーンコンポーネントをインストールします。それぞれが関連する監視メトリックをPrometheusに送信します。ASMにはGrafanaダッシュボードが付属しており、オペレータはこの監視データを視覚化し、コントロールプレーンの健全性とパフォーマンスを評価できます。

ダッシュボードを表示する

  1. Istioと共にインストールされたGrafanaサービスをポートフォワードします。
kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3001:3000 >> /dev/null
  1. Grafanaをブラウザから開きます。
  2. Cloud Shellウィンドウの右上隅にある"Webプレビュー"アイコンをクリックします
  3. ポート3000で プレビュー をクリックします（注：ポートが3000ではない場合、ポートの変更をクリックしてポート3000を選択します）
  4. これにより、ブラウザに次のようなURLのタブが開きます " BASE_URL/?orgId=1&authuser=0&environment_id=default "
  5. 利用可能なダッシュボードを表示します
  6. URLを次のように変更します" BASE_URL/dashboard "
  7. "istio"フォルダーをクリックし、利用可能なダッシュボードを表示します
  8. それらのダッシュボードのいずれかをクリックして、そのコンポーネントのパフォーマンスを表示します。次のセクションでは、各コンポーネントの重要な指標を見ていきます

Pilotの監視

Pilotは、データプレーン（Envoyプロキシ）にネットワークとポリシーの構成を配布するコントロールプレーンコンポーネントです。Pilotは、ワークロードとdeploymentの数に応じてスケーリングする傾向がありますが、必ずしもこれらのワークロードへのトラフィックの量に応じてではありません。正常ではないPilotは次のようになり得ます:

  • 必要以上のリソースを消費します (CPU と/または RAM)
  • 更新された構成情報をEnvoyにプッシュする際に遅延が生じます

注：Pilotがダウンしている、または遅延がある場合でもワークロードは引き続きトラフィックを処理し続けます。

  1. ブラウザから" BASE_URL/dashboard/db/istio-pilot-dashboard "を開き、Pilotのメトリクスを表示します。

重要な監視メトリクス

リソース使用量

Istioのパフォーマンスとスケーラビリティのページを使用可能な使用数のガイダンスとして使用してください。これよりも大幅に多くのリソースを使用している場合は、GCPサポートにお問い合わせください。

5f1969f8e2c8b137.png

Pilotのプッシュ情報

このセクションでは、EnvoyプロキシへのPilotの設定プッシュを監視します。

  • Pilot Pushesは、プッシュされる設定のタイプを示します。
  • ADS Monitoringは、システム内のVirtual Services、サービス、および接続されたエンドポイントの数を示します。
  • 既知のエンドポイントを持たないクラスターは、設定されているが実行中のインスタンスを持たないエンドポイントを表示します（* .googleapis.comなどの外部サービスを示す場合があります）。
  • Pilot Errorsは、時間の経過とともに発生したエラーの数を示します。
  • Conflictsは、リスナーの構成があいまいな競合の数を示します。

エラーまたはConflictsがある場合、1つ以上のサービスの構成が正しくないか、一貫性がありません。詳細については、データプレーンのトラブルシューティングを参照してください。

Envoy情報

このセクションには、コントロールプレーンに接続するEnvoyプロキシに関する情報が含まれています。繰り返しXDS接続エラーが発生する場合は、GCPサポートにお問い合わせください。

Mixerの監視

Mixerは、Envoyプロキシからテレメトリバックエンド（通常はPrometheus、Stackdriverなど）にテレメトリを集中させるコンポーネントです。この容量では、データプレーンにはありません。 2つの異なるサービス名（istio-telemetryとistio-policy）でデプロイされた2つのKubernetes Jobs（Mixerと呼ばれる）としてデプロイされます。

Mixerを使用して、ポリシーシステムと統合することもできます。この能力では、Mixerはデータプレーンに影響を与えます。これは、サービスへのアクセスのブロックに失敗したポリシーがMixerにチェックするためです.

Mixerは、トラフィックの量に応じてスケーリングする傾向があります。

  1. ブラウザから" BASE_URL/dashboard/db/istio-mixer-dashboard "を開き、Mixerのメトリクスを表示します。

重要な監視メトリクス

リソース使用量

Istioのパフォーマンスとスケーラビリティのページを使用可能な使用数のガイダンスとして使用してください。これよりも大幅に多くのリソースを使用している場合は、GCPサポートにお問い合わせください。

87ed83238f9addd8.png

Mixer概要

  • **応答時間（Response Duration）**は重要な指標です。 Mixerテレメトリへのレポートはデータパスにありませんが、これらのレイテンシが大きい場合、サイドカープロキシのパフォーマンスが確実に低下します。 90パーセンタイルは1桁のミリ秒単位であり、99パーセンタイルは100ミリ秒未満であると予想する必要があります。

e07bdf5fde4bfe87.png

  • Adapter Dispatch Durationは、Mixerがアダプターを呼び出す際に発生するレイテンシーを示します（テレメトリーおよびロギングシステムに情報を送信するために使用されます）。ここでの待ち時間が長いと、メッシュのパフォーマンスに絶対的な影響があります。繰り返しますが、p90のレイテンシは10ミリ秒未満である必要があります。

1c2ee56202b32bd9.png

Galleyの監視

Galleyは、Istioの構成の検証、取り込み、処理、および配布を行うコンポーネントです。設定をKubernetes APIサーバーからPilotに伝えます。 Pilotと同様に、システム内のサービスとエンドポイントの数に応じてスケーリングする傾向があります。

  1. ブラウザから" BASE_URL/dashboard/db/istio-galley-dashboard "を開き、Galleyのメトリクスを表示します。

重要な監視メトリクス

リソース検証

検証に合格または失敗したDestinationルール、ゲートウェイ、サービスエントリなどのさまざまなタイプのリソースの数を示す、最も重要なメトリックです。

接続されたクライアント

Galleyに接続されているクライアントの数を示します。通常、これは3（Pilot、istio-telemetry、istio-policy）であり、これらのコンポーネントのスケーリングに合わせてスケーリングされます。

15. Istioのトラブルシューティング

データプレーンのトラブルシューティング

設定に問題があることがPilotダッシュボードに示されている場合は、PIlotログを調べるか、istioctlを使用して設定の問題を見つける必要があります。

Pilotログを調べるには、kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discoveryのようなコマンドを実行ます。実際にはistio-pilot -...をトラブルシューティングするPilotインスタンスのPod識別子に置き換えます。

結果のログで、プッシュステータスメッセージを検索します。例えば:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

プッシュステータスは、構成をEnvoyプロキシにプッシュしようとしたときに発生した問題を示します。この場合、重複したアップストリーム宛先を示すいくつかの「クラスターの重複」メッセージが表示されています。

問題の診断に関するサポートについては、Google Cloudサポートにお問い合わせください。

設定エラーの発見

istioctlを使用して構成を分析するには、 istioctl experimental analyze -k --context $ OPS_GKE_1を実行します。これにより、システムの構成の分析が実行され、提案された変更とともに問題が示されます。このコマンドが検出できる構成エラーの完全なリストについては、ドキュメントを参照してください。

16. クリーンアップ

管理者はcleanup_workshop.shスクリプトを実行して、bootstrap_workshop.shスクリプトによって作成されたリソースを削除します。クリーンアップスクリプトを実行するには、次の情報が必要です。

  • 組織名 - 例. yourcompany.com
  • ワークショップID - YYMMDD-NN **形式。**例. 200131-01
  • 管理用GCSバケット - ワークショップ作成スクリプトで定義
  1. Cloud Shellを開き、その中で以下のすべてのアクションを実行します。下のリンクをクリックしてください。

CLOUD SHELL

  1. 想定している管理者ユーザーでgcloudにログインしていることを確認します。
gcloud config list
  1. asmフォルダーに移動します。
cd ${WORKDIR}/asm
  1. 削除する組織名とワークショップIDを定義します。
export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
  1. 次のようにクリーンアップスクリプトを実行します。 
./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}