این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

کارگاه مش سرویس Anthos: راهنمای آزمایشگاه - ژاپنی

1. کارگاه آلفا

ワークショップ Codelab へのリンク: bit.ly/asm-workshop-jp

2. 概要

アーキテクチャ図

GCP定する方法を体験する、実践的なハンズオンです.ーティング用のGoogle Kubernetes Engine （GKE）と、セキュアな接続、可観測性、高度なトラフィック操作を実現するایستیوークショップで使用されるすべてのプラ.と同じです.

دستور کار

TODO - به روز رسانی با تجزیه نهایی

前提条件

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

GCP組織リソース
شناسه شناسه (あなたがこのアカウントの請求先アカウント IDます)
組織レベルに対してのسازمان IAMロール

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

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

bootstrap_workshop.shというスクリプトを使用して、ワークショップ».リプトを使用して、自分用に単一の環境をセットアップ、また複数境もセットアップできます.

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

組織名(به عنوان مثال. yourcompany.com )-
請求先アカウントID (مثلا 12345-12345-12345 ) - IDの請求先として使われます.
ワークショップ番号(مثلا. 01 ) - شناسه شناسه.の命名にも使用されます。個別のワークショップ番号を使用すると、毎回一ID取得しやすくなります.クトIDに使用されます。日付とワークショップ番号の組み合わせに.
ユーザーの開始番号(مثلا. 1 ) - 。たとえば、10 کارکردن 、ユーザーの終了番号が10となります
ユーザーの終了番号(例. 10 ) - この番号は、ワークショップの最後のユーザー番号を表します。たとえば、10人のユーザー向けのワークショップを作成する場合、ユーザーの開始番号が1、ユーザーの終了番号が10となります。単一の環境（たとえば自分用）を構築している叴始番号と終了番号は同じです。これにより、単一の環境が構築されすす

管理用 GCS バケット(例. my-gcs-bucket-name ) - このGCSバケットは、ワークショップ関連の情報を保存するために使用されます。その情報はcleanup_workshop.shスクリプトによって使用され、ワークショップ作成スクリプト中に作成されたすべてのリソースを適切に削除するために使われます作成する管理者は、このバケットに対する読み取り/書き込み権限が必

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

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

このワークショップには2種類のユーザーがいます。1つめがこのワークショップのリソースを作成および削除するADMIN_USER 、2番目はMY_USERで、ワークショップの手順を実行します。 MY_USERは、自身のリソースのみにアクセスできます。 ADMIN_USERは、すMY_USER . ADMIN_USERワークショップを作成するインストラクターである場合、 ADMIN_USERとMY_USERは異なります。

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

オーナー- 組織内のすべてのプロジェクトに対するプロジェェクトオーナ
フォルダ管理者- 組織内のフォルダを作成および削除する機能。すべてロジェクト内のすべてのリソース.
組織の管理者
プロジェクト作成者- 組織内にプロジェクトを作成する権限。
プロジェクトの削除- 組織内のプロジェクトを削除する権限。
پروژه IAM 管理者- 組織内のすべてのプロジェクトに IAM のルールを作成する権關

これらに加えて、 ADMIN_USERはワークショップ».ある必要があります。

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

組織内のユーザー（自分以外）向けにこのワークショMY_USERプを作成するプを作成するユーザー命名ルールに従う必要があります。 bootstrap_workshop.shスクリプトの実番号とユーザーの終了番号をمن

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

شرکت شما.com.com. . :

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

これらのユーザー名には、setup_terraform_admin_project.shスクリプトで作成されーージェクト所有者ロールが割り当てられます.。は、この.で複数のユーザーを一度に追加する方法を参照してください。

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

このワークショップは Cloud Shellワークショップで必要となります.

gcloud (ver >= 270)
کوبکتل
sed (سیستم عامل مکではなくCloud Shell / Linuxのsedで動作します)
git (最新版を使っていることを確認してください)
sudo apt update
sudo apt install git
jq
envsubst
سفارشی کردن

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

پوسته ابری を開き、以降の作業を Cloud Shell 上で実行します。Cloud Shellてください.

پوسته ابری

想定している管理者ユーザーで gcloud にログインしてい.

gcloud config list

WORKDIR （作業用フォルダ)

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm

ワークショップに使用する組織名、請求アカウントIDットを定義します。上記のセクションでワークショップのぃトア..

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>

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スクリプトが完了すると、組織内のユーザーごとにォォフォルダがルダ内に、 terraform管理プロジェクトが作成されます。 terraformップに必要な残りのGCPリソースを作成するために使用されます。 terraform管理プロジェクトで必要なAPIを有効にすCloud طرح خطاを適用します。 کلود بیلدできるようにします。最後に、 Google Cloud Storage（GCS）.すべてのGCPリソースのTerraform Statesを保存します.

terraform管理プロジェクトでCloud Buildタスクを表示するは、terraform管理プロジェクチ、ワークショップ作成スクリプトで指定された管理用GCSバケットに保ユーザーに対してワークショップ作成شناسه شناسه شما ..

管理用GCSバケットからworkshop.txtファイルを取得して、terraformプロジェクトかを取得

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .

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

پوسته ابری を開き、以降の作業を Cloud Shell 上で実行します。Cloud Shellてください.

پوسته ابری

想定している管理者ユーザーで gcloud にログインしてい.

gcloud config list

WORKDIR（作業用フォルダ)

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm

ワークショップに使用する組織名、請求アカウントIDットを定義します。上記のセクションでワークショップのぃトア..

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>

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}

管理用GCSバケットからworkshop.txtファイルを取得して、terraformプロジェクトかを取得

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 . شناسه شناسهはuser001-200131-01-tf-abcdeのようになります。各ユーザーは、自分のワ.クセスできます

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

このワークショップは Cloud Shellワークショップで必要となります.

gcloud (ver >= 270)
کوبکتل
sed (سیستم عامل مکではなくCloud Shell / Linuxのsedで動作します)
git (最新版を使っていることを確認してください)
sudo apt update
sudo apt install git
jq
envsubst
سفارشی کردن
pv

terraform管理プロジェクトへのアクセス

bootstrap_workshop.shスクリプトが完了すると、組織内のユーザーごとにォォフォルダがルダ内に、 terraform管理プロジェクトが作成されます。 terraformップに必要な残りのGCPリソースを作成するために使用されます。 setup-terraform-admin-project.shにします. Cloud BuildはTerraform Plan cloud build サービスアカウントに適切なな iam ロールを付与し、、、リソースを作成できるようようにしますに、、すべてのののののののの حالت teraformをを保存するに、リモートバックバックエンドエンドががgoogle google cloud） gcs） gcs） gcs） gcs） gcsバケットに構成されます.

پوسته ابری を開き、以降の作業を Cloud Shell 上で実行します。Cloud Shellてください.

پوسته ابری

شخصی سازی を$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

پی وی پی .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

想定しているユーザーで gcloud にログインしていることを確認します。

gcloud config list

WORKDIR（作業用フォルダ)

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
cd asm

Terraform 管理プロジェクト ID を下記のコマンドで取得します。:

export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN

ワークショップに関連するすべてのリソース情報は、terraform 管バ保存されているvars.shファイルに変数として保存されていますす。 terraform管理ギs.イルを取得します.

mkdir vars
gsutil cp gs://${TF_ADMIN}/vars/vars.sh ./vars/vars.sh
echo "export WORKDIR=${WORKDIR}" >> ./vars/vars.sh

表示されたリンクをクリックして、Terraform 管理プロジェクトのCloud Buildペーク

source ./vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"

کلود بیلدのビルドをクリッ.リプトの一部として作成されます。上記のアーキテクチャ図も参考になります。

組織内の4つのGCPプロジェクト。各プロジェクトは提供された請求アカ..
1つのプロジェクnetwork host projectースは作成されません.
1 ops project IstioコントロールプレーンのGKE.
それ以外の2つのプロジェクトは、それぞれの.チームを表しています.
3 dev2 dev1 ops
Kubernetesのマニフェストファイル用の6つのフォルダを含むk8s-repoという名剃されます.マニフェストをクラスタにデプロイするために使用されます.
ساخت ابرトをそれぞれのフォルダからGKEクラスタk8s-repoデプロイします。

ترافورم 。表示されたリンクをクリックして、 ops

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

インストールの確認

すべてのクラスタを管理するためにkubeconfig . ..

./scripts/setup-gke-vars-kubeconfig.sh

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

KUBECONFIG変数を新しい kubeconfig ファイルに変更します。

source ./vars/vars.sh
export KUBECONFIG=`pwd`/gke/kubemesh

var.sh を .bashrc に追加し、Cloud Shell が再起動した際に常に読み込まれるよう、すす

echo "source ${WORKDIR}/asm/vars/vars.sh" >> ~/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> ~/.bashrc

クラスタのコンテキストを取得します。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

ایستیو のインストール確認

پودンストールされていることを確認します.

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

Istioが両方のdev1クラスターにインストールされていることを確認してください。 dev1クラスターでは、Citadel、sidecar-injector、corednのみが実行されています。 ops-1クラスターで実行されているIstioのコントロールプレーンを共有します.

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system

Istioが両方のdev2クラスタにインストールされていることを確認してください。 dev2クラスタでは、Citadel、sidecar-injector、corednのみが実行されています。 ops-2クラスタで実行されているIstioのコントロールプレーンを共有します.

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

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

オプションで、راز

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クラス. راز .アプリケーションクラスタ用）を使用します。خلبان は、これらの Secret راز 記の رازスタがkubeconfig راز で作成された رازす。 Opsクラスターは、Secretとしてkubeconfig.れには、opsクラスターپایلوت PIサーバーに到達できない場合、リモートサービス.サービスレジストリのDNSエントリと考えることができ.ービスを定義します。詳細につい.

5. زیرساخت リポジトリの説明

ساخت ابر زیرساخت

ワークショップのGCPリソースは、 Cloud BuildとInfrastructure .端末からワークシscripts/bootstrap_workshop.sh .ップ作成スクリプトは、GCPフォルダ"ترافورم " Terraform管理プロジェクトは、 Terraform States、ログ、およびその他のスクリトは、されます。そこにはinfrastructureとk8s_repoのCSRリポジトリが含まれています。これらのリポジトリについては、次のセクションで詳しく説明します。 terraform管理プロジェクトには、他のワークショップリソースは組み込まれていません。 terraform管理プロジェクトのCloud Buildサービスアカウントは、ワークショップのリソース.

Infrastructureます. cloudbuild.yamlします。これらのツールには、gcloud SDK、terraform、およびpython、git、jqなどの他のユーティリティが含まれます。カスタムビルダーイメージは、 terraform planを実行し、各リソースにapplyします。各リソースの terraform ファイルは個別のフォルダーにあります（詳細は次のセクショ.常作成される方法に従って構築されます（たとえば.る前にGCPプロジェクトが構築されます）。詳細については、 cloudbuild.yamlファイルを確認してください.

Cloud Buildは、 infrastructure هاに対して行われた変更は、 زیرساخت به عنوان کد (IAC)ワークショップの状態は常にこのリポジトリに保存されます.

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

زیرساخت リポジトリは、ワークショッ.ます。フォルダとサブフォルダに構造化されていま. GCPは、チームの特定の環境（たとえば、dev、stage、prod）を表します。環境内のフォルダーの次のレイヤーは、特定のリソース（たとえば、host_project、gke_clustersなど）を表します。必要なスクリプトと terraformファイルは、リソースフォルダー内に存在します.

この.

زیرساخت - زیرساخت -リソースを作成する責任があります。リソースにはترافورمンフラストラクチャリポジトリ自体は、Terraform State ファイル（以下で説明）にあります。これらのリソースは、ワークショップ作成プロセス中にbashスクリプトによって作成されます（詳細については、モジュール0-インフラストラクチャセットアップ - 管理者用ワークフローを参照）。
شبکه - ネットワークチームを表します.リソースを所有しています.
host project - 共有VPCのホストプロジェクトを表します。
shared VPCルを表します.
ops - 運用 / DevOpsチームを表します。彼らは次のリソースを所有しています。
ops project - すべてのopsリソースのためのプロジェクトを表します。
gke clustersカプレーンは、ンストールされます.
k8s-repo - すべてのGKEクラスタのGKEマニフェストを含むCSRリポジトリ。
برنامه ها - app1 1.2ュレーションします。彼らは次のapp2 .
app projects برنامه -ェクトごとに請求とIAMを制御できます.
gke clustersナ/ Pod. ..
gce instances - オプションで、GCEインスタンスで実行されるアプリケーションがある場合に使用します。このワークショップでは、app1 に、アプリケーションの一部が実行されるいくつかのGCEインスタンスがあります。

このワークショップでは、同じアプリ（Hipster. .

ایالت プロバイダ、 ایالت

googleおよびgoogle-betaプロバイダーはgcp/[environment]/gcp/provider.tfにありますり ارائه provider.tf .フォルダでシンボリックリンクされています。これにより、各リソに管理する代わりに、1か所でプロバイダを管理できます

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

相互依存する値を持つリソースには、 output.tfファイルが含まれます。必要な出力値は、その特定のリソースのバックエンドで定義された tfstate ファイルに保存されます。たとえば、プロジェクトにGKEクラスタを作成するには、プロジェクトID.スのterraform_remote_stateデータソースを介して使用できる tfstate ファイルにに خروجی.tf

shared_state_[resource_name].tfファイルは、リルは、他のリソースからの出力を必要とするterraform_remote_stateソースフォルダに存ops_gkeリソースフォルダには、 ops_projectおよびshared_vpcリソースの shared_state ファイルがあります。これは、opsプロジェクトでGKEクラスタを作成するにはプロジェクトIDとVPCの詳細が必要だからです。 shared_stateファイルは、スクリプト（ scripts/setup_terraform_admin_projectにある）を使用してテンプレート（ templates/shared_state.tf_tmplにある）から生成されます。すべてのリソースのgcp/[environment]/shared_statesフォルダーに配置されます。必要なshared_state ファイルは.ンボリックリンクされています。すべてのshared_stateファイルを1つのフォルダ.ダーにsymリンクすると、すべての状態ファイル.

変数

فرم تبلیغاتیのGCSバケットにあるvars.shというファイルにす。これには、組織ID、請求先アカウント、プロジェクトID、GKEクラスタの詳細などが含まれます。任意の端末からvars.shをダウンロードして入手し、セットアップの値を取得できます。

Terraform変数は、 TF_VAR_[variable name]としてvars.shに保存されます。これらの変数は、それぞれのリソースフォルダにvariables.tfvarsファイルを生成するために使用されます。 variables.tfvarsファイルには、すべての変数とその値が含まれています。 variables.tfvarsファイルは、スクリプト（ scripts/setup_terraform_admin_projectにあります）を使用して、同じフォルダ内のテンプレートファイルから生成されます。

k8s リポジトリの説明

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

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

プロジェクト، GKEクラスター، そしてنام فضای

このワークショップのリソースは、さまざまなGCPプロジェクトに分かれています。プロジェクトは、会社の組織（またはチーム）構造と一致する必要があります。さまざまなプロジェクト / 製品 / リソースを担当するチーム（組織内）は、さまざまなGCPプロジェクトを使用します。個別のプロジェクトを作成すると、IAMアクセス許可の個別のセットを作成し、プロジェクトレベルで請求を管理できます。さらに、クォータもプロジェクトレベルで管理されます。

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

GCPリソースを構築するインフラストラクチャチームは、Terraform管理プロジェクトを使用します。彼らは、CSRリポジトリ（ infrastructureと呼ばれる）のコードとしてインフラストラクチャを管理し、GCSバケットのGCPで構築されたリソースに関するすべてのTerraform حالت 情報を保存します。これらは、、、 csr リポジトリおよびおよび حالت terraform の gcs バケットへのアクセスを制御します。。。。。。。。。。。。。。。。。。。。。。。。
共有VPCを構築するネットワークチームは、 hostプロジェクトを使用します。このプロジェクトには、VPC、サブネット、ルート、ファイアウォールルールが含まれています。共有VPCを使用すると、GCPリソースのネットワークを一元管理できます。すべてのプロジェクトは、ネットワークにこの単一の共有 vpc を使用しています。。。。。。。。。。。。。。。。。。。。。。。
GKEクラスターとASM / Istioコントロールプレーンを構築するops / platformチームは、 opsプロジェクトを使用します。 GKEクラスターとサービスメッシュのライフサイクルを管理します。これらは、クラスターを強化し、Kubernetesプラットフォームの復元力とスケールを管理する責任があります。このワークショップでは、リソースをKubernetesにデプロイするGitOpsメソッドを使用します。 CSRリポジトリ（ k8s_repoと呼ばれる）がopsプロジェクトに存在します。
最後に、アプリケーションを構築するdev1およびdev2チーム（2つの開発チームを表す）は、独自のdev1およびdev2プロジェクトを使用します。これらは、顧客に提供するアプリケーションとサービスです。これらは、運用チームが管理するプラットフォーム上に構築されます。リソース（deployment、service など）はk8s_repoにプッシュされ、適切なクラスターに展開されます。このワークショップは CI / CD のベストプラクティスとツールに焦点を合わせていないことに注意してください。 Cloud Build を使用して、GKEクラスターへのKubernetesリソースの展開を自動化します。実際の運用シナリオでは、適切な CI / CD ソリューションを使用して、アプリケーションをGKEクラスターに展開します.

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

ops クラスター- ops チームが devops のツールを実行するために使用します。このワークショップで、、、、、、コントロールプレーンを実行してサービスメッシュメッシュをを管理管理ます。。。
アプリケーション (برنامه ها) クラスター- 開発チームがアプリケーションを実行するために使用します。このワークショップは、、 hipster ショップアプリに使用されます。。

ops / adminツールをアプリケーションを実行するクラスターから分離すると、各リソースのライフサイクルを個別に管理できます。 2つのタイプのクラスターは、それらを使用するチーム / 製品に関連する異なるプロジェクトにも存在します。これにより、 iam 権限も管理しやすくなります。。

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

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

このワークショップでは、10層のマイクロサービスアプリケーションをデプロイします。このアプリケーションは、「 Hipster Shop 」と呼ばれるWebベースのeコマースアプリで、ユーザーはアイテムを参照してカートに追加し、購入することができます。

kubernetes マニフェストと k8s_repo

k8s_repoを使用して、すべてのGKEクラスターにKubernetesリソースを追加します。これを行うには、Kubernetesマニフェストをコピーし、 k8s_repoにコミットします。 k8s_repoへのすべてのコミットは、Kubernetesマニフェストをそれぞれのクラスターにデプロイする cloud build ジョブをトリガーします。各クラスターのマニフェストは、クラスター名と同じ名前の別のフォルダーにあります。。

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

GKE-ASM-1-R1-PROD-リージョン 1 にあるリージョナル ops クラスター
GKE-ASM-2-R2-PROD-リージョン 2 にあるリージョナル ops クラスター
GKE-1-APPS-R1a-Prod-リージョン 1 のゾーン A にあるアプリクラスター
GKE-2-APPS-R1B-PROD-リージョン 1 のゾーン B にあるアプリクラスタークラスター
GKE-3-APPS-R2A-Prod-リージョン 2 のゾーン A にあるアプリクラスター
GKE-4-APPS-R2B-PROD-リージョン 2 のゾーン B にあるアプリクラスタークラスター

k8s_repoには、これらのクラスターに対応するフォルダーがあります。これらのフォルダーに配置されたマニフェストは、対応するGKEクラスターに適用されます。各クラスターのマニフェストは、管理を容易にするためにサブフォルダー（クラスターのメインフォルダー内）に配置されます。このワークショップでは、 Kustomizeを使用して、デプロイされるリソースを追跡します。詳細については、Kustomizeの公式ドキュメントを参照してください。

6. サンプルアプリをするする

目標: hipster ショップアプリを برنامه ها クラスターにデプロイするする

k8s-repoリポジトリをクローン
hipster ショップのマニフェストを全ての برنامه ها クラスターにコピーコピー
hipster ショップアプリのために services を ops クラスターに作成作成
グローバルの接続性をテストするためloadgeneratorを ops クラスターにセットアップ
hipster ショップアプリへのセキュアな接続を確認確認

عملیات プロジェクトのリポジトリを.

最初の terraform インフラストラクチャ構築の一部として、、 k8s-repoは ops プロジェクトで既に作成済み。。。。。。。。。。。。。。。。。。。。。。。

workdir の下に、リポジトリ用の空フォルダを作成し。。:

mkdir ${WORKDIR}/k8s-repo
cd ${WORKDIR}/k8s-repo

git リポジトリとして初期化し、リモートのリポジトリとして追加、 master ブランチををしします:

git init && git remote add origin \
 https://source.developers.google.com/p/${TF_VAR_ops_project_name}/r/k8s-repo

git のローカル設定を行います。。

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

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

فروشگاه hipster マニフェストをすべてのクラスターのソースリポジトリにコピーします。。

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/.

Hipsterショップは、opsクラスターではなく、アプリケーションクラスターに展開されます。 opsクラスターは、ASM / Istioコントロールプレーンでのみ使用されます。 opsクラスターからHipsterショップのdeployment、PodSecurityPolicyおよびRBACマニフェストを削除します。

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つのdevクラスター以外のすべてからcartservice deployment、RBACおよびPodSecurityPolicyを削除します。 Hipsterショップはマルチクラスター展開用に構築されたものではなく、4つのdeploymentすべてを実行し続けることで、アクセスしたdeploymentに応じてカート情報に矛盾が生じてしまいます。

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

最初の dev クラスターのみで、 استقرار cartservice 、 rbac 、および podsecurityPolicy を kustomization.yaml に追加します。。。。。。。。。。。。。。。。。。。。

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

ops クラスターの kustomization.yaml から podsecurityPolicies 、 استقرار 、 rbac ディレクトリを削除します。。。。。。。。。。。。。。。。。。。。。

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

rbac マニフェストの project_id を置き換えます。。

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/*

Ingressgateway および مجازی マニフェストををクラスターのソースリポジトリにコピーコピーます。。。。。。。。。。。。

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 つにコピーします。

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/

اتصال پیکربندی マニフェストの project_id を置き換えます。。

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/*

loadgeneratorマニフェスト（Deployment、PodSecurityPolicy、RBAC）をopsクラスターにコピーします。 Hipsterショップアプリは、グローバルなGoogle Cloud Load Balancer（GCLB）を使用して公開されます。 GCLBはクライアントトラフィック（ frontend宛て）を受信し、サービスの最も近いインスタンスに送信します。 loadgeneratorを両方のopsクラスターに配置すると、opsクラスターで実行されている両方のIstio Ingressゲートウェイにトラフィックが送信されます。負荷分散については、次のセクションで詳しく説明します。

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/.

両方の ops クラスターのloadgeneratorマニフェストの ops プロジェクト id を置き換えます。。

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

両方の ops クラスターのloadgeneratorリソースを kustomization.yaml に追加します。。。

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

k8s-repoにコミットします。

cd ${WORKDIR}/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master

ロールアウトが完了するのを待ちます。

../asm/scripts/stream_logs.sh $TF_VAR_ops_project_name

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

カートを除いたすべてのアプリケーション namespace の pod が、すべてのののクラスターで実行状態（（）であることを確認し。。。。。。。。。。。。。。。。。。。。。。。。。。。

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

فضای نام سبد خرید の pod が、最初のののクラスターでのみ実行（（（））であることを確認ます。。。。。。。。。。。。。。。。。。。。。。。。。。。。

kubectl --context ${DEV1_GKE_1} get pods -n cart;

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

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

هیپسترショッ.

グローバル負荷分散

これで、4つのアプリクラスターすべてにHipster Shopアプリが展開されました。これらのクラスターは、2つのリージョンと4つのゾーンにあります。クライアントは、 frontendサービスにアクセスしてHipsterショップアプリにアクセスできます。 frontendサービスは、4つのアプリクラスターすべてで実行されます。 Google Cloud Load Balancer（ GCLB ）を使用して、 frontendサービスの4つのインスタンスすべてにクライアントトラフィックを取得します。

Istio Ingressゲートウェイはopsクラスターでのみ実行され、リージョン内の2つのゾーンアプリケーションクラスターに対するリージョナルロードバランサーとして機能します。GCLBは、グローバルフロントエンドサービスへのバックエンドとして2つのIstio入力ゲートウェイ（2つのopsクラスターで実行）を使用します。 Istio Ingressゲートウェイは、GCLBからクライアントトラフィックを受信し、クライアントトラフィックをアプリケーションクラスターで実行されているフロントエンドPodに送信します。

また、 Istio Ingress ゲートウェイをアプリケーションクラスターに直接配置し、、 gclb がそれらをバックエンドとして使用することもできます。。。。。。。。。。。。。。。。。。。。。。。。

GKE Autoneg コントローラー

Istio IngressゲートウェイKubernetes Serviceは、ネットワークエンドポイントグループ（NEG）を使用して、GCLBのバックエンドとして自身を登録します。 NEGでは、GCLBを使用したコンテナネイティブの負荷分散が可能です。 NEGはKubernetesサービスの特別なアノテーションを使って作成されるため、NEGコントローラーに自身を登録できます。 Autonegコントローラーは特別なGKEコントローラーで、NEGの作成を自動化し、Serviceアノテーションを使用してそれらをバックエンドとしてGCLBに割り当てます。 Istioイングレスゲートウェイを含むIstioコントロールプレーンは、Terraform Cloud Buildのイニシャルインフラストラクチャで展開されます。 GCLBおよびAutonegの設定は、TerraformインフラストラクチャのイニシャルCloud Buildの一部として行われます。

نقاط پایانی ابر とマネージド証明書を使ったセキュアな Ingress

GCPマネージド証明書は、 frontend GCLBサービスへのクライアントトラフィックを保護するために使用されます。 GCLBは、グローバルfrontendサービスにマネージド証明書を使用し、SSLはGCLBで終端されます。このワークショップでは、マネージド証明書のドメインとしてCloud Endpointsを使用します。または、 frontendのドメインとDNS名を使用して、GCPマネージド証明書を作成できます。

hipster ショップにアクセスするために、下記のコマンドで出力されるリンクをクリックします。。

echo "https://frontend.endpoints.${TF_VAR_ops_project_name}.cloud.goog"

Chrome タブの url バーのロック記号をクリックしてて、が有効であるであることを確認でき。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

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

アプリケーション展開の一部として、GCLB HipsterショップのCloud Endpointsリンクへテストトラフィックを生成する両方のopsクラスターに、負荷生成機能が展開されました。 GCLBがトラフィックを受信し、両方のIstio Ingressゲートウェイに送信していることを確認します。。

hipster ショップ gclb が作成されている ops プロジェクトののgclb> نظارتリンクリンクをします。。。。。。。。。。。。。

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"

以下に示すように、、 backend ドロップダウンメニューからall backendsからistio-ingressgatewayに変更します。。。。。。。。。。。。。。。。。。。。。。

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

istio-ingressgatewayごとに 3 つののが作成されます。。クラスターはリージョナルistio-ingressgatewayタークラスターであるためリージョンの各各ゾーンゾーンゾーンに対してつつののがが作成作成さされただし、、、、、 stio-一のゾーンで実行されます。ここでは、 istio-ingressgateway pod に向かうトラフィックが表示されます。。。。。。。。。。。。。。。。。。。。。。。。。

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

7. stackdriver による可観測性

目標: istio のテレメトリデータを stackdriver に連携し、確認する

istio-telemetryリソースをインストール
خدمات istio のダッシュボードを作成作成/更新
コンテナのログ表示表示
stackdriver で分散トレーシング情報を表示表示

Istioの主要な機能の1つは、ビルトインの可観測性（"o11y"）です。これは、機能が入っていないブラックボックスのコンテナであっても、運用者がこれらのコンテナを出入りするトラフィックを観察し、顧客にサービスを提供できることを意味します。この観察は、メトリック、ログ、およびトレースといういくつか異なる方法方法のをを取り取り取り。。。取り。取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り取り a

また、Hipster ショップに組み込まれている負荷生成機能を利用します。観測性は、トラフィックのない静的システムではあまりうまく機能しないため、負荷の生成は、その動作を確認するのに役立ちます。負荷生成はすでに実行されているので、簡単に確認可能です。。

istio を stackdriver の構成ファイルにインストールします。。

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

k8s-repo にコミットします。

cd ../../
git add . && git commit -am "Install istio to stackdriver configuration"
git push

ロールアウトが完了するのを待ちます。

../asm/scripts/stream_logs.sh $TF_VAR_ops_project_name

Istio → StackDriver の連携を確認します。。stackdriver Handler CRD を取得します。。。。。。。。。。。。。。。

kubectl --context ${OPS_GKE_1} get handler -n istio-system

出力には、 stackdriver という名前の Handler が表示されるはずです:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s

istio のメトリックスが stackdriver にエクスポートされていることを確認します。このコマンドから出力されるリンクをクリックし。:

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

Opsプロジェクトにちなんで命名された新しいワークスペースを作成するように求められるので、[OK]を選択します。新しいUIについてのプロンプトが表示されたら、ダイアログを閉じます。

メトリクスエクスプローラーで、[レコードタイプ]をクリックし、「 istio 」と入力します。「Kubernetes Pod」リソースタイプには「Server Request Count」などのオプションがあります。これは、メトリックがメッシュからStackdriverに流れていることを示しています。。

（以下の行を表示する場合、、 مقصد_Service_name でグループ化する必要があります））））））））））））））））））））））））））

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

メトリックがStackdriver APMシステムにあるので、それらを視覚化する方法が必要です。このセクションでは、メトリクスの4つの"ゴールデンシグナル"のうち3つを表示するビルド済みのダッシュボードをインストールします。トラフィック（1秒あたりのリクエスト数）、レイテンシ（この場合、99パーセンタイルと50パーセンタイル）、エラー（この例では飽和を除外しています）。

IstioのEnvoyプロキシはいくつかのメトリックを提供しますが、これらは使い始めるのに適したセットです。（完全なリストはこちらです）。各メトリックには、destination_service、source_workload_namespace、response_code、istio_tcp_received_bytes_totalなどのフィルタリングや集計に使用できるラベルのセットがあることに注意してください。。

次に、あらかじめ用意されているメトリックダッシュボードを追加しましょう。 Dashboard APIを直接使用します。これは、API呼び出しを手動で生成する場合、通常行いません。なんらかの自動化システムの一部であるか、 وب ui でダッシュボードを手動で作成します。これにより、すぐに使い始められ。:

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

以下の出力されたリンクに移動しして新しく新しく追加さたたダッシュをを表示し。。。。。。。。。。。。。。。。。。

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=${TF_VAR_ops_project_name}"

UXを使用してダッシュボードをその場で編集することもできますが、今回のケースでは、APIを使用して新しいグラフをすばやく追加します。そのためには、ダッシュボードの最新バージョンを取得し、編集内容を適用してから、、 http patch メソッドを使用してプッシュする必要があり。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

モニタリング api を使い、既存のダッシュボードを取得できます。追加したばかりのダッシュボードを取得し。。:

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

新しいグラフの追加：（50th％ile latency）：[ API reference ] これで、新しいグラフウィジェットをコードでダッシュボードに追加できます。この変更は、ピアによってレビューされ、バージョン管理システムにチェックインされます。追加するウィジェットは、、 50 ％の待機時間（（Latence の中央値）を示しています。。。。。。。。。。。。。。。。。。。。。

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

jq --argjson newChart "$(<new-chart.json)" '.gridLayout.widgets += [$newChart]' sd-services-dashboard.json > patched-services-dashboard.json

既存の ServiceDashboard を更新します:

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

次の出力されたリンクに移動して、更新されたダッシュボードを表示ます:

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=${TF_VAR_ops_project_name}"

簡単なログ分析を行います。。

Istioは、すべてのインメッシュネットワークトラフィックの構造化ログのセットを提供し、それらをStackdriver Loggingにアップロードして、1つの強力なツールでクロスクラスター分析を可能にします。ログには、クラスター、コンテナー、アプリ、 Connection_id などのサービスレベルのメタデータが追加されます。

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

  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 のコントロールプレーンログを表示するには、リソース> kubernetes コンテナーを選択しし、、 "خلبان"-で検索します。。

ここでは、各サンプルアプリサービスのプロキシ設定をプッシュするIstioコントロールプレーンを見ることができます。 "CDS"、"LDS"、および"RDS"は異なるEnvoy APIを表します（詳細情報）。

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

hipster ショップ用のいくつかのサンプルフィルターをますます:

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

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

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

分散システムを使用しているため、デバッグには新しいツールである分散トレースが必要です。このツールを使用すると、サービスがどのように相互作用しているのかに関する統計情報（下の図の異常な低速イベントの検出など）を見つけたり、生のサンプルトレースを見て、実際に何が起こっているのかを調べたりすることができ。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 a

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

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

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

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

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

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

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

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プレビュータブで開きます。

https://ssh.cloud.google.com/devshell/proxy?authuser=0&port=3000&environment_id=default
(必ずCloud Shellと同じChromeのシークレットウィンドウでURLを開いてください)

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

8. 相互TLS認証

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

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

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

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

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

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

k8s-repo にコミットします。

cd ${WORKDIR}/k8s-repo
git add . && git commit -am "turn mTLS on"
git push

ロールアウトが完了するのを待ちます。

${WORKDIR}/asm/scripts/stream_logs.sh $TF_VAR_ops_project_name

mTLSの動作確認

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": {}
    }
  ]
}

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」をクリックします。:

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

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

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イメージタグに基づいて、自動トリガーを使用します。

Cloud Shellから、カナリアディレクトリに移動します。:

CANARY_DIR="${WORKDIR}/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="${WORKDIR}/k8s-repo"

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に直ちに送信されます。

変更内容をk8s_repoにコミットします。 :

cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
cd $CANARY_DIR

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

別の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

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%            |
|          |                   |
+----------+-------------------+

前の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%             |
|          |                   |
+----------+-------------------+

frontend v2のDev1ロールアウトが完了すると、スクリプトの最後に成功メッセージが表示されます。
```
出力結果（コピーしないでください） 
```

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod

そして、Dev1 Podからのすべてのfrontendトラフィックはfrontend v2に向いていなければなりません。:
```
出力結果（コピーしないでください） 
```

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

**Cloud Source Repos > k8s_repoに移動します。**トラフィックの割合ごとに個別のコミットが表示され、最新のコミットがリストの一番上に表示されます。:

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

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でリージョンのカナリアを安全に実行し、新しいバージョンをグローバルに展開する前にそれが正常に実行されたことを確認できました。

Dev2リージョンで自動カナリアスクリプトを実行します。

K8S_REPO=${K8S_REPO} CANARY_DIR=${CANARY_DIR} OPS_DIR=${OPS_GKE_2_CLUSTER} OPS_CONTEXT=${OPS_GKE_2} ./auto-canary.sh

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にアクセスできるようにします。

認可のサンプルディレクトリに移動します。

export AUTHZ_DIR="${WORKDIR}/asm/k8s_manifests/prod/app-authorization"
export K8S_REPO="${WORKDIR}/k8s-repo"

cd $AUTHZ_DIR

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

両方のリージョンの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

変更をプッシュします。

cd $K8S_REPO 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push
cd $AUTHZ_DIR

ブラウザでHipsterショップアプリのfrontendにアクセスしてみてください:

echo "https://frontend.endpoints.${TF_VAR_ops_project_name}.cloud.goog"

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

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

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

次に、 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を有効にする必要があります。これは、サービスアカウントの資格情報がリクエストにマウントされるようにするためです。

更新された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

更新をプッシュします。

cd $K8S_REPO 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
cd $AUTHZ_DIR

Cloud Buildの完了を待ちます。
Hipsterショップアプリのfrontendを再度開きます。今回は、ホームページにエラーが表示されないはずです。これは、frontendが現在のサービスにアクセスすることを明示的に許可しているためです。
次に、カートにアイテムを追加し、"place order"をクリックして、チェックアウトを実行してください。今回は、currencyサービスから価格変換エラーが表示されるはずです。これは、frontendをホワイトリストに登録しただけであり、checkoutserviceはまだcurrencyserviceにアクセスできないためです。

最後に、別のルールをcurrencyservice AuthorizationPolicyに追加して、 checkoutサービスがcurrency serviceにアクセスできるようにします。frontendとcheckoutの2つのサービスからのcurrency serviceのアクセスのみを開放していることに注意してください。他のバックエンドサービスは引き続きブロックされます。
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"]

最終的な認可ポリシーを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

更新をプッシュします。

cd $K8S_REPO 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push

Cloud Build の完了を待ちます。
チェックアウトを実行してみてください。正常に動作するはずです。

このセクションでは、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）を追加してプラットフォームをスケーリングするには、次のリソースを追加する必要があります。:

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

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

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

asm（メインワークショップ）リポジトリからadd-projブランチをチェックアウトします。 add-projブランチには、このセクションの変更内容が含まれています。

cd ${WORKDIR}/asm
git checkout add-proj
cd ${WORKDIR}

メインワークショップの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

add-project.shスクリプトを実行します。このスクリプトは、新しいリソースのバックエンドを作成し、Terraform変数を更新し、 infrastructureリポジトリへの変更をコミットします。

./asm/scripts/add-project.sh

コミットにより、 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を使用して新しいクラスターに追加されます。

infrastructure Cloud Buildが正常に終了したら、次の出力されたリンクをクリックして、実行されたk8s-repoの最新のCloud Buildに移動します。

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

次のスクリプトを実行して、新しいクラスターをvarsおよびkubeconfigファイルに追加します。

chmod +x ./asm/scripts/setup-gke-vars-kubeconfig-add-proj.sh
./asm/scripts/setup-gke-vars-kubeconfig-add-proj.sh

KUBECONFIG変数を変更して、新しいkubeconfigファイルを指すようにします。

source ${WORKDIR}/asm/vars/vars.sh
export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh

クラスターコンテキストを一覧表示します。 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インストールの確認

すべての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

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

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

オプションで、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を表し、青い丸はクライアントを表し、白い丸はサーバーコンテナを表します。

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）エラーを受け取ります。これを実際に見てみましょう。

サーキットブレーカーディレクトリに移動します。

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm"

両方の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

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

変更をコミットします。

cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM

Cloud Buildの完了を待ちます。
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

ここで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

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

両方のリージョンからサーキットブレーカーポリシーを削除してクリーンアップします。

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に挿入します。ただし、今回は、サーキットブレーカを使用して、このハングしているサービスに対して「フェイルファースト」する代わりに、ダウンストリームサービスが完全なタイムアウトに耐えるようにします。

フォールトインジェクションディレクトリに移動します。

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM

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

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

変更をプッシュします。

cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM

Cloud Buildの完了を待ちます。
サーキットブレーカーセクションでデプロイされた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

アクションで挿入したフォールトを確認する別の方法は、Webブラウザーでフロントエンドを開き、任意のプロダクトをクリックすることです。製品ページは、ページの下部に表示されるrecommend情報を取得するため、ロードにさらに5秒かかります。
両方の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

変更をプッシュします。

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ダッシュボードが付属しており、オペレータはこの監視データを視覚化し、コントロールプレーンの健全性とパフォーマンスを評価できます。

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

Istioと共にインストールされたGrafanaサービスをポートフォワードします。

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

Grafanaをブラウザから開きます。
Cloud Shellウィンドウの右上隅にある"Webプレビュー"アイコンをクリックします
ポート3000でプレビューをクリックします（注：ポートが3000ではない場合、ポートの変更をクリックしてポート3000を選択します）
これにより、ブラウザに次のようなURLのタブが開きます " BASE_URL/?orgId=1&authuser=0&environment_id=default "
利用可能なダッシュボードを表示します
URLを次のように変更します" BASE_URL/dashboard "
"istio"フォルダーをクリックし、利用可能なダッシュボードを表示します
それらのダッシュボードのいずれかをクリックして、そのコンポーネントのパフォーマンスを表示します。次のセクションでは、各コンポーネントの重要な指標を見ていきます

Pilotの監視

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

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

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

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

重要な監視メトリクス

リソース使用量

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

Pilotのプッシュ情報

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

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

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

Envoy情報

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

میکسرの監視

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

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

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

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

重要な監視メトリクス

リソース使用量

Mixer概要

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

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

Galleyの監視

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

ブラウザから" 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バケット - ワークショップ作成スクリプトで定義

Cloud Shellを開き、その中で以下のすべてのアクションを実行します。下のリンクをクリックしてください。

CLOUD SHELL

想定している管理者ユーザーでgcloudにログインしていることを確認します。

gcloud config list

asmフォルダーに移動します。

cd ${WORKDIR}/asm

削除する組織名とワークショップIDを定義します。

export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>

次のようにクリーンアップスクリプトを実行します。

./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}

کارگاه مش سرویس Anthos: راهنمای آزمایشگاه - ژاپنی

1. کارگاه آلفا

2. 概要

アーキテクチャ図

دستور کار

前提条件

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

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

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

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

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

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

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

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

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

ユーザー情報の取得

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

インストールの確認

ایستیو のインストール確認

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

5. زیرساخت リポジトリの説明

ساخت ابر زیرساخت

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

ایالت プロバイダ、 ایالت

変数

k8s リポジトリ の 説明

プロジェクト، GKEクラスター، そしてنام فضای

kubernetes マニフェスト と k8s_repo

6. サンプル アプリ を する する

目標: hipster ショップ アプリ を برنامه ها クラスター に デプロイ する する

عملیات プロジェクトのリポジトリを.

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

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

هیپسترショッ.

グローバル 負荷 分散

GKE Autoneg コントローラー

نقاط پایانی ابر と マネージド 証明 書 を 使っ た セキュア な Ingress

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

7. stackdriver による 可 観測性

目標: istio の テレメトリ データ を stackdriver に 連携 し 、 確認 する

8. 相互TLS認証

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

mTLSの動作確認

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

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

10. 認可ポリシー

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

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

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

Istioインストールの確認

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

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

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

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

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

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

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

Pilotの監視

重要な監視メトリクス

میکسرの監視

重要な監視メトリクス

Galleyの監視

重要な監視メトリクス

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

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

設定エラーの発見

16. クリーンアップ

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

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

k8s リポジトリの説明

kubernetes マニフェストと k8s_repo

6. サンプルアプリをするする

目標: hipster ショップアプリを برنامه ها クラスターにデプロイするする

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

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

グローバル負荷分散

نقاط پایانی ابر とマネージド証明書を使ったセキュアな Ingress

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

7. stackdriver による可観測性

目標: istio のテレメトリデータを stackdriver に連携し、確認する