Anthos सर्विस मेश वर्कशॉप: लैब गाइड - जैपनीज़

1. ऐल्फ़ा वर्कशॉप

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

2. 概要

アーキテクチャ図

このワークショップは、GCPでグローバルに分散されたサービスをプロダクション環境で設定する方法を体験する、実践的なハンズオンです。使用する主なテクノロジーは、コンピューティング用の Google Kubernetes Engine（GKE）と、セキュアな接続、可観測性、高度なトラフィック操作を実現する Istioサービスメッシュです。この वर्कशॉप में इस्तेमाल की जाने वाली सभी प्रैक्टिस और टूल, असल में प्रोडक्शन में इस्तेमाल किए जाने वाले टूल और प्रैक्टिस ही हैं.

एजेंडा

TODO - update with final breakdown

前提条件

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

GCP組織リソース
請求先アカウントID (あなたがこのアカウントの請求先アカウント管理者である必要があります)
組織レベルに対しての Organization Administrator IAMロール

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

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

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

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

組織名 (例. yourcompany.com)- これはあなたがワークショップ環境を作成する組織の名称です。
請求先アカウントID (例. 12345-12345-12345) - このIDがワークショップで作成される全てのリソースの請求先として使われます。
ワークショップ番号 (例. 01) - 2桁の数字。इसका इस्तेमाल तब किया जाता है, जब एक दिन में कई वर्कशॉप आयोजित की जाती हैं और उन्हें अलग-अलग मैनेज करना होता है.ワークショップ番号は、プロジェクトIDの命名にも使用されます。個別のワークショップ番号を使用すると、毎回一意のプロジェクトIDを取得しやすくなります。ワークショップ番号に加えて、現在の日付（YYMMDD形式）もプロジェクトIDに使用されます。日付とワークショップ番号の組み合わせにより、यूनिक प्रोजेक्ट आईडी दिया जाता है.
ユーザーの開始番号 (例. 1) - この番号は、ワークショップの最初のユーザー番号を表します。たとえば、10人のユーザー向けのワークショップを作成する場合、ユーザーの開始番号が1、ユーザーの終了番号が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 は、すべてのユーザー設定にアクセスできます。自分で इस सेटअपを作成する場合、ADMIN_USER とMY_USER は同じとなります。अगर आपको कई छात्रों के लिए यह वर्कशॉप बनानी है, तो ADMIN_USER और MY_USER अलग-अलग होंगे.

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

オーナー - 組織内のすべてのプロジェクトに対するプロジェクトオーナーの権限。
フォルダ管理者 - 組織内のフォルダを作成および削除する機能。すべてのユーザーは、プロジェクト内のすべてのリソースを含む単一のフォルダを取得します。
組織の管理者
プロジェクト作成者 - 組織内にプロジェクトを作成する権限。
プロジェクトの削除 - 組織内のプロジェクトを削除する権限。
プロジェクト IAM 管理者 - 組織内のすべてのプロジェクトに IAM のルールを作成する権限。

इनके अलावा, ADMIN_USER के पास वर्कशॉप में इस्तेमाल किए जाने वाले बिलिंग खाते का आईडी होना चाहिए और वह बिलिंग खाते का एडमिन भी होना चाहिए.

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

संगठन के अन्य उपयोगकर्ताओं के लिए यह वर्कशॉप बनाने पर, आपको MY_USER के लिए तय किए गए उपयोगकर्ता के नाम रखने के नियमों का पालन करना होगा. bootstrap_workshop.shスクリプトの実行中に、ユーザーの開始番号とユーザーの終了番号を指定します。इन नंबरों का इस्तेमाल, उपयोगकर्ता नाम बनाने के लिए इस तरह किया जाता है::

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

たとえば、yourcompany.comという組織で、ユーザーの開始番号1およびユーザーの終了番号3でワークショップ作成スクリプトを実行すると、次に示すユーザー名のワークショップ環境が作成されます。:

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

これらのユーザー名には、setup_terraform_admin_project.shスクリプトで作成された特定のプロジェクトのプロジェクト所有者ロールが割り当てられます。ワークショップ作成スクリプト का इस्तेमाल करते समय, आपको इस उपयोगकर्ता命名スキーマ का पालन करना होगा. 詳しくは、G Suite で複数のユーザーを一度に追加する方法をご覧ください。

ワークショップで इस्तेमाल किए जाने वाले टूल

このワークショップは Cloud Shell から実行されることを想定しています。ワークショップでは、以下に示すツール群が必要となります。

gcloud (ver >= 270)
kubectl
sed (यह Mac OS के बजाय Cloud Shell / Linux के sed पर काम करता है)
git (最新版を使っていることを確認してください)
sudo apt update
sudo apt install git
jq
envsubst
kustomize

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

Cloud Shell を開き、以降の作業を Cloud Shell 上で実行します。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、ワークショップ番号、管理用GCSバケットを定義します。ऊपर दिए गए सेक्शन में, वर्कशॉप को सेट अप करने के लिए ज़रूरी अनुमतियां देखें.

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スクリプトが完了すると、組織内のユーザーごとにGCPフォルダが作成されます。フォルダ内に、 terraform管理プロジェクトが作成されます。 terraform 管理プロジェクトは、このワークショップに必要な残りのGCPリソースを作成するために使用されます。 terraform管理プロジェクトで必要なAPIを有効にします。 Cloud Buildを使用してTerraform planを適用します。 Cloud Buildサービスアカウント को सही IAM रोल असाइन करें, ताकि वह GCP में संसाधन बना सके.最後に、 Google Cloud Storage（GCS）バケットでリモートバックエンドを構成して、すべてのGCPリソースの Terraform statesを保存します。

terraform管理プロジェクトでCloud Buildタスクを表示するには、terraform管理プロジェクトIDが必要です。これは、ワークショップ作成スクリプトで指定された管理用GCSバケットに保存されます。複数のユーザーに対してワークショップ作成スクリプトを実行する場合、すべてのterraform管理プロジェクトIDはGCSバケットにあります。

管理用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 .

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

Cloud Shell を開き、以降の作業を Cloud Shell 上で実行します。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、ワークショップ番号、管理用GCSバケットを定義します。ऊपर दिए गए सेक्शन में, वर्कशॉप को सेट अप करने के लिए ज़रूरी अनुमतियां देखें.

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プロジェクト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などのユーザー名がプレフィックスとして追加され、terraform管理プロジェクトIDはuser001-200131-01-tf-abcdeのようになります。हर उपयोगकर्ता के पास, सिर्फ़ अपने वर्कशॉप एनवायरमेंट का ऐक्सेस होता है.

ワークショップで इस्तेमाल किए जाने वाले टूल

このワークショップは Cloud Shell から実行されることを想定しています。ワークショップでは、以下に示すツール群が必要となります。

gcloud (ver >= 270)
kubectl
sed (यह Mac OS के बजाय Cloud Shell / Linux के sed पर काम करता है)
git (最新版を使っていることを確認してください)
sudo apt update
sudo apt install git
jq
envsubst
kustomize
pv

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

bootstrap_workshop.shスクリプトが完了すると、組織内のユーザーごとにGCPフォルダが作成されます。フォルダ内に、 terraform管理プロジェクトが作成されます。 terraform 管理プロジェクトは、このワークショップに必要な残りのGCPリソースを作成するために使用されます。 setup-terraform-admin-project.shスクリプトは、terraform管理プロジェクトで必要なAPIを有効にします。 Cloud BuildはTerraform planを適用するために使用されます。スクリプトを使用して、 Cloud Buildサービスアカウントに適切なIAMロールを付与し、GCPでリソースを作成できるようにします。最後に、すべてのGCPリソースの Terraform stateを保存するために、リモートバックエンドが Google Cloud Storage（GCS）バケットに構成されます。

Cloud Shell を開き、以降の作業を Cloud Shell 上で実行します。Cloud Shell を開くには下記のリンクをクリックしてください。

CLOUD SHELL

kustomize を $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

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

想定しているユーザーで 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 管理プロジェクトのGCSバケットに保存されているvars.shファイルに変数として保存されています。 terraform管理プロジェクトのvars.shファイルを取得します。

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}"

Cloud Buildページが表示されたので、左側のナビゲーションから履歴リンクをクリックし、最新のビルドをクリックして、最初のTerraformの適用の詳細を表示します。次のリソース, Terraformスクリプトの一部として作成されます。上記のアーキテクチャ図も参考になります。

संगठन के चार GCP प्रोजेक्ट.各プロジェクトは提供された請求アカウントIDに紐付いています。
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つのフォルダがあります。このリポジトリは、GitOps形式でKubernetesのマニフェストをクラスタにデプロイするために使用されます。
Cloud Buildトリガーは、k8s-repo のmasterブランチへのコミットがあるたびに作成され、KubernetesのマニフェストをそれぞれのフォルダからGKEクラスタにデプロイします。

terraform 管理プロジェクトでビルドが完了すると、opsプロジェクトで別のビルドが開始されます。表示されたリンクをクリックして、ops プロジェクトのCloud Buildページを開きます。

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

Istio のインストール確認

確認 करें कि सभी पॉड चल रहे हों और जॉब पूरा हो गया हो. साथ ही, यह भी देखें कि दोनों क्लस्टर में 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

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

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

オプションで、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

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

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 クラスタ के लिए एक ही शेयर किए गए वीपीसी का इस्तेमाल किया जाता है.クラスタ全体でサービスを検出するには、opsクラスタで Secret として作成された kubeconfigファイル（各アプリケーションクラスタ用）を使用します。Pilot は、これらの Secret を使用して、アプリケーションクラスタの Kube API サーバー（上記の Secret を介して認証された）を照会することにより、サービスを検出します。両方のopsクラスタがkubeconfigで作成された Secret を使用して、すべてのアプリクラスタに対して認証できることがわかります。 Opsクラスターは、Secretとしてkubeconfigファイルを使用してサービスを自動的に検出できます。これには、opsクラスタ内のPilotが他のすべてのクラスタのKube APIサーバーにアクセスできることが必要です。 Pilot が Kube API サーバー तक नहीं पहुंच पाता है, तोリモートサービス को ServiceEntries के तौर पर मैन्युअल तरीके से जोड़ें. ServiceEntries को, सेवा रजिस्ट्री की डीएनएस एंट्री माना जा सकता है. ServiceEntriesは、完全修飾DNS名（ FQDN）と到達可能なIPアドレスを使用してサービスを定義します。詳細については、 Istio Multiclusterのドキュメントを参照してください。

5. infrastructure リポジトリの説明

इन्फ़्रास्ट्रक्चर क्लाउड बिल्ड

ワークショップのGCPリソースは、 Cloud Buildと Infrastructure CSRリポジトリを使用して構築されます。ローカル端末からワークショップ作成スクリプト（scripts/bootstrap_workshop.shにあります）を実行します。ワークショップ作成スクリプトは, GCP フォルダ, Terraform 管理プロジェクト, および Cloud Build サービスアカウントの適切な IAM アクセス許可を作成します.Terraform管理プロジェクトは、Terraform states、ログ、およびその他のスクリプトを保存するために使用されます。そこには infrastructure とk8s_repo のCSRリポジトリが含まれています。これらのリポジトリについては、次のセクションで詳しく説明します。 terraform管理プロジェクトには、他のワークショップリソースは組み込まれていません。 terraform管理プロジェクトのCloud Buildサービスアカウントは、ワークショップのリソースを構築するために使用されます。

Infrastructure フォルダにある cloudbuild.yaml फ़ाइल का इस्तेमाल, वर्कशॉप के GCP संसाधन बनाने के लिए किया जाता है. GCPリソースの作成に必要なすべてのツールを使用して、カスタムビルダーイメージを作成します。これらのツールには、gcloud SDK、terraform、およびpython、git、jqなどの他のユーティリティが含まれます。カスタムビルダーイメージは、terraform plan を実行し、各リソースに apply します。हर संसाधन का Terraform फ़ाइल अलग-अलग फ़ोल्डर में मौजूद है. ज़्यादा जानकारी के लिए, अगला सेक्शन देखें.リソースは、一度に1つずつ、通常作成される方法に従って構築されます（たとえば、プロジェクトでリソースが作成される前にGCPプロジェクトが構築されます）。詳細については、 cloudbuild.yaml ファイルを確認してください。

Cloud Buildは、infrastructure リポジトリへのコミットがあるたびにトリガーされます。インフラストラクチャに対して किए गए बदलाव, Infrastructure as Code（IaC）として保存され、リポジトリにコミットされます。ワークショップの状態は常にこのリポジトリに保存されます。

फ़ोल्डर स्ट्रक्चर - टीम, एनवायरमेंट, और संसाधन

Infrastructure リポジトリは、ワークショップのGCPインフラストラクチャリソースをセットアップします。フォルダとサブフォルダに構造化されています。リポジトリ内のベースフォルダは、特定のGCPリソースを所有するチームを表します。フォルダの次のレイヤーは、チームの特定の環境（たとえば、dev、stage、prod）を表します。環境内の फ़ोल्डर की अगली लेयर, किसी खास संसाधन (जैसे, host_project, gke_clusters वगैरह) को दिखाती है.必要なスクリプトと terraform ファイルは、リソースフォルダー内に存在します。

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

infrastructure - クラウドを管理するインフラストラクチャチームを表します。他のすべてのチームのGCPリソースを作成する責任があります。リソースにはTerraform管理プロジェクトを使用します。インフラストラクチャリポジトリ自体は、Terraform state ファイル（以下で説明）にあります。これらのリソースは、ワークショップ作成プロセス中にbashスクリプトによって作成されます（詳細については、モジュール0-インフラストラクチャセットアップ - 管理者用ワークフローを参照）。
network - ネットワークチームを表します。 VPCとネットワークリソースを担当します。彼らは次のGCPリソースを所有しています。
host project - 共有VPCのホストプロジェクトを表します。
shared VPC - 共有VPC、サブネット、セカンダリIP範囲、ルーティング情報、ファイアウォールルールを表します。
ops - 運用 / DevOpsチームを表します。彼らは次のリソースを所有しています。
ops project - すべてのopsリソースのためのプロジェクトを表します。
gke clusters - リージョンごとのops GKEクラスタ。Istio कंट्रोल प्लैन, हर GKE क्लस्टर में इंस्टॉल किया जाता है.
k8s-repo - すべてのGKEクラスタのGKEマニフェストを含むCSRリポジトリ。
apps - アプリケーションチームを表します。このワークショップでは、app1 と app2 の2つのチームをシミュレーションします。彼らは次のリソースを所有しています。
app projects - すべてのアプリチームが個別のプロジェクトセットを持ちます。これにより、プロジェクトごとに請求とIAMを制御できます。
gke clusters - これらは、アプリケーションコンテナ/ Pod が実行されるアプリケーション用クラスタです。
gce instances - オプションで、GCEインスタンスで実行されるアプリケーションがある場合に使用します。このワークショップでは、app1 に、アプリケーションの一部が実行されるいくつかのGCEインスタンスがあります。

このワークショップでは、同じアプリ（Hipster ショップアプリ）を app1 と app2 の両方で使用します。

プロバイダ、state、出力 - バックエンド、共有 state

google および google-beta प्रोफ़ाइलें gcp/[environment]/gcp/provider.tf में मौजूद हैं. provider.tf ファイルは、すべてのリソースフォルダでシンボリックリンクされています。इससे, हर संसाधन के लिए अलग-अलग प्रोवाइडर को मैनेज करने के बजाय, एक ही जगह से सभी प्रोवाइडर को मैनेज किया जा सकता है.

すべてのリソースには、リソースの tfstate ファイルの場所を定義する backend.tf ファイルが含まれています。この backend.tf ファイルは、スクリプト（scripts/setup_terraform_admin_project にある）を使用してテンプレート（templates/backend.tf_tmpl にある）から生成され、それぞれのリソースフォルダに配置されます。 GCSバケットがファイル置き場として使われます。 GCSバケットフォルダ名はリソース名と一致します。リソースはすべて、terraform管理プロジェクトにあります。

output.tf फ़ाइल में, एक-दूसरे पर निर्भर करने वाली वैल्यू वाले संसाधन शामिल होते हैं.必要な出力値は、その特定のリソースのバックエンドで定義された tfstate ファイルに保存されます。たとえば、プロジェクトにGKEクラスタを作成するには、プロジェクトIDを知る必要があります。プロジェクトIDは、GKEクラスタリソースの terraform_remote_state データソースを介して使用できる tfstate ファイルに output.tf を介して出力されます。

shared_stateファイル, リソースのtfstateファイルを指す terraform_remote_state データソースです。shared_state_[resource_name].tf ファイルは、他のリソースからの出力を必要とするリソースフォルダに存在します。उदाहरण के लिए, ops_gke リソースフォルダには、ops_project および shared_vpc リソースの shared_state ファイルがあります。これは、opsプロジェクトでGKEクラスタを作成するにはプロジェクトIDとVPCの詳細が必要だからです。 shared_state फ़ाइल, स्क्रिप्ट（scripts/setup_terraform_admin_project में मौजूद） का इस्तेमाल करके टेंप्लेट（templates/shared_state.tf_tmpl में मौजूद） से जनरेट की जाती है.すべてのリソースの shared_state ファイルは、gcp/[environment]/shared_states フォルダーに配置されます。必要なshared_state ファイルは、それぞれのリソースフォルダーでシンボリックリンクされています。すべてのshared_stateファイルを1つのフォルダーに配置し、それらを適切なリソースフォルダーにsymリンクすると、すべての状態ファイルを1か所で簡単に管理できます。

変数

すべてのリソースの値は環境変数として保存されます。これらの変数は, terraform adminプロジェクトの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が作成され、Istio がすべてのクラスターにインストールされます

プロジェクト, GKEクラスター, そしてnamespace

このワークショップのリソースは、さまざまなGCPプロジェクトに分かれています。प्रोजेक्ट, कंपनी के संगठन (या टीम) के स्ट्रक्चर के मुताबिक होने चाहिए.अलग-अलग प्रोजेक्ट / प्रॉडक्ट / संसाधन मैनेज करने वाली टीमें (संगठन के अंदर) अलग-अलग GCP प्रोजेक्ट का इस्तेमाल करती हैं.अलग-अलग प्रोजेक्ट बनाने पर, IAM की अनुमतियों का अलग-अलग सेट बनाया जा सकता है. साथ ही, प्रोजेक्ट लेवल पर बिलिंग को मैनेज किया जा सकता है.さらに、クォータもプロジェクトレベルで管理されます。

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

GCPリソースを構築するインフラストラクチャチームは、Terraform管理プロジェクトを使用します。彼らは、CSRリポジトリ（infrastructure と呼ばれる）のコードとしてインフラストラクチャを管理し、GCSバケットのGCPで構築されたリソースに関するすべてのTerraform state情報を保存します。これらは、CSRリポジトリおよびTerraform state の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のツールを実行するために使用します。このワークショップでは、ASM / Istioコントロールプレーンを実行してサービスメッシュを管理します。
アプリケーション (apps) クラスター - 開発チームがアプリケーションを実行するために使用します。इस वर्कショップ में, इसका इस्तेमाल 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クラスターには展開されません。हालांकि, सभी माइक्रोसेवाओं के नेमस्पेस और सेवा संसाधन भी 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ジョブをトリガーします。各クラスタのマニフェストは、クラスタ名と同じ名前の別のフォルダにあります。

छह क्लासटर के नाम यहां दिए गए हैं:

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ショップアプリをappsクラスターにデプロイする

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

ops プロジェクトのリポジトリをクローン

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

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

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

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

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 Shopマニフェストをすべてのクラスタのソースリポジトリにコピーします。

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 ショップのデプロイメント、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 deployment、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、deployment、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およびVirtualServiceマニフェストをopsクラスターのソースリポジトリにコピーします。

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/

Config Connectorリソースを各プロジェクトのクラスタの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/

Config Connectorマニフェストの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 Shop ऐप्लिकेशन को, ग्लोबल 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が、すべてのdevクラスターで実行状態（Running）であることを確認します。

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

cart namespaceのPodが、最初のdevクラスターでのみ実行状態（Running）であることを確認します。

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

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

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

Hipsterショップアプリケーションへのアクセス

グローバル負荷分散

これで、4つのアプリクラスタすべてにHipster Shopアプリが展開されました。これらのクラスター, 2つのリージョンと4つのゾーンにあります。क्लाइंट, frontendसेवा को ऐक्सेस करके Hipster Shop ऐप्लिकेशन को ऐक्सेस कर सकते हैं.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の一部として行われます。

Cloud Endpointsとマネージド証明書を使ったセキュアなIngress

GCPマネージド証明書は、frontend GCLBサービスへのクライアントトラフィックを保護するために使用されます。 GCLBは、グローバルfrontendサービスにマネージド証明書を使用し、SSLはGCLBで終端されます。このワークショップでは、マネージド証明書のドメインとして Cloud Endpointsを使用します。इसके अलावा, frontend के डोमेन और डीएनएस नाम का इस्तेमाल करके, GCP मैनेज किए गए सर्टिफ़िकेट बनाए जा सकते हैं.

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

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

Chrome タブ के यूआरएल बार में मौजूद लॉक आइकॉन पर क्लिक करके, यह देखा जा सकता है कि सर्टिफ़िकेट मान्य है या नहीं.

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

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

HipsterShopGCLB के लिए बनाए गए ops प्रोजेक्ट में, GCLB > Monitoring लिंक पर जाएं.

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つのNEGが作成されます。 opsクラスターはリージョナルクラスターであるため、リージョン内の各ゾーンに対して1つのNEGが作成されます。ただし、istio-ingressgatewayPodは、リージョンごとに単一のゾーンで実行されます。ここでは、istio-ingressgatewayPodに向かうトラフィックが表示されます。

負荷生成機能は、両方のopsクラスターで実行され、2つのリージョンからのクライアントトラフィックをシミュレーションします。opsクラスターリーजन 1 में जनरेट हुआ लोड, रीजन 2 के istio-ingressgateway को भेजा जाता है.इसी तरह, ops क्लस्टर के दूसरे रीज़न में जनरेट हुआ लोड, पहले रीज़न के istio-ingressgateway को भेजा जाता है.

7. Stackdriverによる可観測性

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

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

Istio की मुख्य सुविधाओं में से एक, बिल्ट-इन ऑब्ज़र्वेबिलिटी ("o11y") है.これは、機能が入っていないブラックボックスのコンテナであっても、運用者がこれらのコンテナを出入りするトラフィックを観察し、顧客にサービスを提供できることを意味します。この観察は、メトリック、ログ、およびトレースといういくつかの異なる方法の形を取ります。

また、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に流れていることを示しています。

（以下の行を表示する場合は、destination_service_nameで ग्रुप化 करना होगा.）

ダッシュボードで指標を可視化する:

メトリックがStackdriver APMシステムにあるので、それらを視覚化する方法が必要です。このセクションでは、メトリクスの4つの" ゴールデンシグナル"のうち3つを表示するビルド済みのダッシュボードをインストールします。ट्रैफ़िक (प्रति सेकंड अनुरोधों की संख्या), लेटेंसी (इस मामले में, 99वें और 50वें पर्सेंटाइल), गड़बड़ी (इस उदाहरण में सैचुरेशन को शामिल नहीं किया गया है).

IstioのEnvoyプロキシはいくつかのメトリックを提供しますが、これらは使い始めるのに適したセットです。（पूरी सूची यहां दी गई है）。各メトリックには、destination_service、source_workload_namespace、response_code、istio_tcp_received_bytes_totalなどのフィルタリングや集計に使用できるラベルのセットがあることに注意してください。

次に、あらかじめ用意されているメトリックダッシュボードを追加しましょう。 Dashboard APIを直接使用します。API呼び出しを手動で生成する場合、通常行いません。なんらかの自動化システムの一部であるか、Web 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% की इंतज़ार अवधि (लेटेंसी की मीडियन वैल्यू) दिखाता है.

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

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

既存のservicesdashboardを更新します:

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などのサービスレベルのメタデータが追加されます。

ログエントリの例（この場合、Envoyプロキシの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コンテナーを選択し、"Pilot"-で検索します。

ここでは, हर सैंपल ऐप्लिकेशन सेवा के लिए प्रॉक्सी सेटिंग को पुश करने वाले Istio कंट्रोल प्लैन को देखा जा सकता है. "CDS"、"LDS"、および"RDS"は異なるEnvoy APIを表します（詳細情報）。

Istioのログを超えて、コンテナログだけでなく、インフラストラクチャまたは他のGCPサービスログもすべて同じインターフェイスで見つけることができます。 GKEのサンプルログクエリを次に示します。ログビューア में, लॉग से मेट्रिक भी बनाई जा सकती हैं. उदाहरण के लिए, "स्ट्रिंग से मेल खाने वाली सभी गड़बड़ियों को गिनें".इन्हें डैशबोर्ड में या सूचनाओं के हिस्से के तौर पर इस्तेमाल किया जा सकता है.ログは、BigQueryなどの他の分析ツールにストリーミングすることもできます。

यहां हिपスターショップ के लिए कुछ सैंपल फ़िल्टर दिए गए हैं:

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

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

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

分散 सिस्टम का इस्तेमाल किया जा रहा है. इसलिए, डीबग करने के लिए, डिस्ट्रिब्यूटेड ट्रेसिंग नाम के नए टूल की ज़रूरत होती है.このツールを使用すると、サービスがどのように相互作用しているのかに関する統計情報（下の図の異常な低速イベントの検出など）を見つけたり、生のサンプルトレースを見て、実際に何が起こっているのかを調べたりすることができます。

タイムラインビュー में, एंड यूज़र को जवाब देने तक के सभी अनुरोध, समय के क्रम में दिखते हैं.यह ग्राफ़, इंतज़ार के समय या शुरुआती अनुरोध से लेकर 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 हमेशा चालू रहता है. यह एन्क्रिप्ट (सुरक्षित) किए गए और नॉन-एमटीएलएस ट्रैफ़िक, दोनों को अनुमति देता है.

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

また、ログから एचटीटीपी से एचटीटीपीएस पर माइग्रेट करने की पुष्टि की जा सकती है. यूआईのログからこの特定のフィールドを公開するには、ログエントリを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 डिप्लॉयमेंट
frontend-v1 पैच ("v1" लेबल और"/ version" एंडपॉइंट वाली कंटेनर इमेज शामिल करें)
respy は、HTTP レスポンスの分布を書き出し、カナリアデプロイメントをリアルタイムで視覚化するのに役立つ小さな Pod です。
frontend Istio DestinationRule - "version" デप्लॉयमेंटラベルに基づいて、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 से आने वाला सभी फ़्रंटएंड ट्रैफ़िक, फ़्रंटएंड 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 से आने वाले ट्रैफ़िक को देखें. यह ट्रैफ़िक, फ़्रंटएंड 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アドレスベースのファイアウォールルールは、ワークロード間のアクセスを保護するには不十分です。माइक्रोसर्विसेज आर्किटेक्चर में, सुरक्षा के लिए नए तरीके अपनाने की ज़रूरत होती है. Istioは、サービスアカウントなどのKubernetesセキュリティビルディングブロックに基づいて、アプリケーションに柔軟なセキュリティポリシーのセットを提供します。

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

最初に、4つの Dev क्लस्टरすべてに AuthorizationPolicy को डिप्लॉय करें. इससे currencyserviceへの सभी ऐक्सेस ब्लॉक हो जाएंगे और फ़्रंटएंड में गड़बड़ी ट्रिगर हो जाएगी.次に、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サービスアカウントによって定義されます。इस मामले में, व्हाइटलिस्ट में शामिल किया जाने वाला सेवाアカウント, फ़्रंटएंड नेमस्पेस का फ़्रंटएंड सेवा खाता होता है.

注：Istio AuthorizationPoliciesでKubernetesサービスアカウントを使用する場合、モジュール1で行ったように、最初にクラスター全体の相互TLSを有効にする必要があります。यह इसलिए है, ताकि सेवा खाते की क्रेडेंशियल को अनुरोध में माउंट किया जा सके.

मुद्रा से जुड़ी नई नीति को कॉपी करें.

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サービスから価格変換エラーが表示されるはずです。यह इसलिए है, क्योंकि आपने सिर्फ़ फ़्रंटएंड को अनुमति दी है. 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ファイルを更新
नए क्षेत्र में दो सबनेट (एक ops प्रोजेक्ट के लिए और दूसरा नए प्रोजेक्ट के लिए)
新しいリージョンに新しいopsクラスター (新しいサブネット内に)
新しいリージョンに新しいIstioコントロールプレーン
新しいリージョンの新しいプロジェクトに2つのappsクラスター
infrastructureリポジトリにコミット
セットアップを確認

プラットフォームをスケールするには、いくつかの方法があります。既存 के क्लस्टर में नोड जोड़कर, ज़्यादा कंप्यूटिंग संसाधन जोड़े जा सकते हैं.リージョン内にさらにクラスターを追加できます。または、プラットフォームにさらにリージョンを追加できます。プラットフォームのどの पहलू को बढ़ाया जाए, यह तय करना आपकी ज़रूरतों पर निर्भर करता है.उदाहरण के लिए, अगर किसी क्षेत्र के सभी तीन ज़ोन में क्लस्टर मौजूद हैं, तो शायद आपको मौजूदा क्लस्टर में नोड (या नोड पूल) जोड़ने की ज़रूरत होगी.ただし、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

クラスタリングのコンテキストを一覧表示します。 आपको आठ क्लस्टर दिखेंगे.

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は、サービスを分離するのに役立つサーキットブレーカートラフィックポリシーを提供します。これにより、ダウンストリーム（クライアント側）サービスが障害のあるサービスを待機するのを防ぎ、アップストリーム（サーバー側）サービスがダウンストリームトラフィックの突然の大量アクセスから保護されます。कुल मिलाकर, सर्किट ब्रेकर का इस्तेमाल करने से, एक बैकएंड सेवा के हैंग होने की वजह से सभी सेवाओं के SLO में फ़ेल होने से बचा जा सकता है.

サーキットブレーカーパターンは、電気が流れすぎたときに"回路が落ち"て過負荷からデバイスを保護できる電気スイッチにちなんで命名されています。 Istioのセットアップでは、これはEnvoyがサーキットブレーカーであり、サービスに対する保留中のリクエストの数を ट्रैक करने का मतलब है.この डिफ़ॉल्टの"閉じた"状態では、リクエストはEnvoyが中断せずにプロキシします。

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

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

この図は、Istioサーキットブレーカーパターンをまとめたものです。青い आयत Envoy को दिखाता है, नीला वृत्त क्लाइंट को दिखाता है, और सफेद वृत्त सर्वर कंटेनर को दिखाता है.

IstioのDestinationRulesを使用して、サーキットブレーカーポリシーを定義できます。इस सेक्शन में, शिपिंग सेवा पर सर्किट ब्रेकर लागू करने के लिए, इन नीतियों का पालन किया जाता है::

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

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

ここでは、DestinationRuleの2つのフィールドに注意する必要があります。 **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

アクション से इंसर्ट किए गए फ़ॉल्ट की जांच करने का दूसरा तरीका यह है कि वेब ब्राउज़र में फ़्रंटएंड खोलें और किसी भी प्रॉडक्ट पर क्लिक करें.製品ページは、ページの下部に表示されるおすすめ情報を取得するため、ロードにさらに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を選択します）
इससे ब्राउज़र में, इस तरह के यूआरएल वाला टैब खुलता है " BASE_URL/?orgId=1&authuser=0&environment_id=default"
利用可能なダッシュボードを表示します
URLを次のように変更します" BASE_URL/dashboard"
"istio" फ़ोल्डर पर क्लिक करें. इससे उपलब्ध डैशबोर्ड दिखेंगे
उन डैशबोर्डのいずれかをクリックして、そのコンポーネントのパフォーマンスを表示します。次のセクションでは、各コンポーネントの重要な指標を見ていきます

Pilotの監視

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

ज़रूरत से ज़्यादा संसाधनों का इस्तेमाल करता है (सीपीयू और/या रैम)
更新された構成情報をEnvoyにプッシュする際に遅延が生じます

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

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

निगरानी के लिए अहम मेट्रिक

リソース使用量

Istioのパフォーマンスとスケーラビリティのページを使用可能な使用数のガイダンスとして使用してください。अगर इससे ज़्यादा रिसॉर्स इस्तेमाल किए जा रहे हैं, तो GCP सहायताチーム से संपर्क करें.

Pilotのプッシュ情報

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

Pilot Pushesは、プッシュされる設定のタイプを示します。
ADS Monitoringは、システム内のVirtual Services、サービス、および接続されたエンドポイントの数を示します。
既知のエンドポイントを持たないクラスターは、設定されているが実行中のインスタンスを持たないエンドポイントを表示します（* .googleapis.comなどの外部サービスを示す場合があります）。
पायलट से जुड़ी गड़बड़ियां, समय के साथ हुई गड़बड़ियों की संख्या दिखाती हैं.
Conflicts は、リスナーの構成があいまいな競合の数を示します。

अगर कोई गड़बड़ी या टकराव है, तो इसका मतलब है कि एक या उससे ज़्यादा सेवाओं का कॉन्फ़िगरेशन सही नहीं है या उनमें एकरूपता नहीं है.詳細については、データプレーンのトラブルシューティングを参照してください。

Envoy情報

このセクションには、コントロールプレーンに接続するEnvoyプロキシに関する情報が含まれています。अगर XDS कनेक्शन से जुड़ी गड़बड़ी बार-बार होती है, तो GCP की सहायता टीम से संपर्क करें.

Mixerの監視

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のインストールを確認する

ユーザー情報の取得

ワークショップで इस्तेमाल किए जाने वाले टूल

インストールの確認

Istio のインストール確認

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

5. infrastructure リポジトリの説明

इन्फ़्रास्ट्रक्चर क्लाउड बिल्ड

फ़ोल्डर स्ट्रक्चर - टीम, एनवायरमेंट, और संसाधन

プロバイダ、state、出力 - バックエンド、共有 state

変数

K8s リポジトリの説明

プロジェクト, GKEクラスター, そしてnamespace

Kubernetes मैनिफ़ेस्ट और k8s_repo

6. サンプル ऐप्लिकेशन को डिप्लॉय करना

目標: Hipsterショップアプリをappsクラスターにデプロイする

ops プロジェクトのリポジトリをクローン

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

ऐप्लिकेशन के डिप्लॉयमेंट की पुष्टि करना

Hipsterショップアプリケーションへのアクセス

グローバル負荷分散

GKE Autoneg コントローラー

Cloud Endpointsとマネージド証明書を使ったセキュアなIngress

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

7. Stackdriverによる可観測性

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

8. 相互TLS認証

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

mTLSの動作確認

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

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

10. 認可ポリシー

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

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

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

Istioインストールの確認

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

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

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

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

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

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

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

Pilotの監視

निगरानी के लिए अहम मेट्रिक

Mixerの監視

निगरानी के लिए अहम मेट्रिक

Galley की निगरानी करना

निगरानी के लिए अहम मेट्रिक

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

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

設定エラーの発見

16. クリーンアップ

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