Семинар Anthos Service Mesh: Лабораторное руководство – японский

1. АЛЬФА-СЕМИНАР

注意: これは、アルファ版のワークショップであり、インストラクター主導のクラスルームトレーニングを目的としています。

ワークショップ codelab, версия: bit.ly/asm-workshop-jp

2. 概要

アーキテクチャ図

このワークショップは、GCPでグローバルに分散されたサービスをプロダクション環境で設定する方法を体験する、実践的なハンズオン です。使用する主なテクノロジーは、コンピューティング用のGoogle Kubernetes Engine (GKE)と、セキュアな接続、可観測性、高度なトラフィック操作を実現するIstioサービスメッシュです。このワークショップで使用されるすべてのプラクティスとツールは、実際に本番で使用するものと同じです。

Повестка дня

TODO – обновление с окончательной разбивкой

前提条件

Например:

1. GCP 組織リソース
2. 請求先アカウントID (あなたがこのアカウントの請求先アカウント管理者である必要があります)
3. 組織レベルに対してのАдминистратор организации IAMロール

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

本セクションでの作業は、ワークショップの管理者が実施します。

もしあなたがワークショップの参加者だった場合、次のセクションへ進んでください:インフラストラクチャ セットアップ - ユーザーワークフロー

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

bootstrap_workshop.sh ).リプトを使用して、自分用に単一の環境をセ ットアップ、また複数のユーザー用に複数の環境もセットアップできます。

Например:

• 組織名(例. yourcompany.com ) - これはあなたがワークショップ環境を作成する組織の名称です。
• 請求先アカウントID (例. 12345-12345-12345 ) - このIDがワークショップで作成される全てのリソースの請求先として使われます。
• ワークショップ番号(例. 01 ) - 2桁の数字。これは、1日に複数のワークショップを行っておりID: IDの命名にも使用されます。個別のワークショップ番号を使用すると、毎回一意のプロジェクトIDを取得しやすくなります。ワークショップ番号に加えて、現在の日付（YYMMDD形式）もプロジェクトIDに使用されます。日付とワークショップ番号の組み合わせにより、一意のプロジェクトIDが提供されます。
• ユーザーの開始番号(例1 ) - この番号は、ワークショップの最初のユーザー番号を表します。たとえば、10人のユーザー向けのワークシ ョップを作成する場合、ユーザーの開始番号が1 、ユーザーの終了番号が10となります
• ユーザー の 終了 番号(例. 10 ) - この は は 、 ワーク の 最後 の ユーザー 番号 を 表し ます。 、 10 人 ユーザー 向け の ショップ を する する 場合 ユーザー の 開始 が 1 ユーザー 終了 作成 する 、 の 開始 が が 、 終了 終了番号が10となります。単一の環境（たとえば自分用）を構築している場合は、ユーザー開始番号と終了番号は同じです。これにより、単一の環境が構築されます。

日付とワークショップ番号に加えて、開始および終了ユーザー番号もプロジェクトIDに組み込まれます。ユーザーID（ワークショップを実行するユーザー用）は、ユーザー開始番号とユーザー終了番号から取得されます。ユーザーIDは、ワークショップを実行するユーザースキーマと権限というセクションで説明されています。

• 管理用 GCS バケット(例.my 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 использует функцию ADMIN_USER:

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

Используйте ADMIN_USER , используйте ADMIN_USER.る必要があります。

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

組織内のユーザー（自分以外）向けにこのワークショップを作成する場合は、 MY_USERの特定のЗагрузите bootstrap_workshop.sh.番号とユーザーの終了番号を指定します。これらの番号は、次のようにユーザー名を作成するために使用されます。:

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

Посетите сайт yourcompany.com.ショップ作成スクリプトを実行すると、次に 示すユーザー名のワークショップ環境が作成されます。:

• [e-mail]
• [e-mail]
• [e-mail]

Загрузите файл setup_terraform_admin_project.sh, создайте файл setup_terraform_admin_project.sh.ェクト所有者ロールが割り当てられます。ワ ークショップ作成スクリプトを使用するときはИспользуйте GSuite .で複数のユーザーを一度に追加する方法を参照してください。

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

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

• gcloud (версия >= 270)
• кубектл
• sed (Mac OSではなくCloud Shell / Linuxのsedで動作します)
• git (最新版を使っていることを確認してください)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• настроить

kustomizeを すべて の ツール は 、 デフォルト で で に に 済み です。。 の が インストール さ れ て い ない は 上記 リンク で さ れ れ て て て に 、 バイナリ バイナリ に に に バイナリ バイナリ 、 、 に ファイル 、をCloud Shellでkustomizeコマンドを実行して確認します。

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

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

ОБЛАЧНАЯ ОБОЛОЧКА

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

gcloud config list

3. WORKDIR （作業用フォルダ）を作成し、ワークショップリポジトリをクローンします。

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

4. GCS, GCS, ID, ID, 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>

5. 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 Buildを使用してTerra сформировать планを適用します。 Cloud Buildサービスアカウントに適切なIAMロールを与えて、GCPでリソースを作成Облачное хранилище Google (GCS)てのGCPリソースのСостояния Терраформированияを保存します。

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

6. Файл 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 .

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

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

ОБЛАЧНАЯ ОБОЛОЧКА

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

gcloud config list

9. WORKDIR（作業用フォルダ）を作成し、ワークショップリポジトリをクローンします。

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

10. GCS, GCS, ID, ID, 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>

11. 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}

12. Файл 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時間

ワークショップを実行するユーザーはここから始めます。 ChromeまたはFirefoxのシークレット（ INCOGNITO ）ウィンドウで手順を実行してください。

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

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

ユーザー情報の取得

ワーク ショップ セットアップ する 管理 者 は 、 ユーザー 名 と パスワード 情報 ユーザー に 提供 必要 必要 が ます。 すべて の の プロジェクト に 、 、 必要 が ます。 すべて ユーザー の プロジェクト は 、 、 、 、 、 、 、 [e-mail] 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 れ れ れ れ れ れ さ 追加はuser001-200131-01-tf-abcdeのようになります。各ユーザーは、自分のワークショップ環境にのみアクセスできます。

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

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

kustomizeとpvを除くすべてのツールは、デフォルトでCloud Shellにインストール済みです。 その2ツールのインストール方法は下記に記載されています。

• gcloud (версия >= 270)
• кубектл
• sed (Mac OSではなくCloud Shell / Linuxのsedで動作します)
• git (最新版を使っていることを確認してください)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• настроить
• пв

терраформ 管理プロジェクトへのアクセス

bootstrap_workshop.sh).ルダ内に、 terraform管理プロジェクトが作成されます。 terraform 管理プロジェクトは、このワークショップに必要な残りのGCPリソースを作成Используйте setup-terraform-admin-project.sh, используйте API-интерфейс terraform.します。 Cloud BuildはПлан терраформированияを適用するために使用されます。スクリプトを使用して、 Cloud Build サービスに 適切 な な ロール ロール 付与 し し 、 、 で リソース を できる よう よう に ます。 最後 に すべて の の リソース の の に し。 最後 に すべて の の リソース のの （を する ため に 、 リモート バック が （（（を する ため 、 リモート エンド エンド （（を 保存 ため に リモート リモート バック エンド エンド エンド リモート バック リモート リモート リモート バック バック バック リモート リモート リモート リモート リモート リモート リモート リモート リモートバケットに構成されます。

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

このワークショップは Cloud Shell と Cloud Console 上で実行することを想定しています。別のユーザー名とパスワードでログインするために、以降のステップをシークレット（ INCOGNITO ）ウィンドウで実行します。

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

ОБЛАЧНАЯ ОБОЛОЧКА

2. настроить を$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
 

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

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

gcloud config list
 

5. WORKDIR（作業用フォルダ）を作成し、ワークショップリポジトリをクローンします。

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

6. Идентификатор Terraform 管理プロジェクト を下記のコマンドで取得します。:

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

7. ワークショップに関連するすべてのリソース情報は、терраформирование存されている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
 

8. 表示されたリンクをクリックして、Terraform 管理プロジェクトのCloud Buildページを開きます。

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

9. Cloud Build – это облачная сборка.ビルドをクリックして、最初のTerraformの適用の詳細を表示します。次のリソースは、Terraformスクリプトの一部として作成されます。上記のアーキテクチャ図も参考になります。

• 組織内の4つのGCPプロジェクト。各プロジェクトは提供された請求アカウントIDに紐付いています。
• 1. Сетевой хост 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のスクリプトの実行には 40-50 分かかります。

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

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

注:このビルドは、Istioのインストールを確認する前に完了している必要があります。

インストールの確認

11. すべてのクラスタを管理するためにkubeconfigファイルを作成します。下記のスクリプトを実行します。

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

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

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

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

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

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

14. クラスタのコンテキストを取得します。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 のインストール確認

15. すべての Pod が実行され、ジョブが完了したことを確認して、Istioが両方のクラスターにインストールされていることを確認します。

kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

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

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

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

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m

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

17. Istioが両方のdev2クラスタにインストールされていることを確認してください。 dev2クラスタでは、Цитадель、коляска-инжектор、кореднのみが実行されています。 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

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

18. オプションで、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クラスタが作成される単一の共有VPCを使用します。クラスタ全体でサービスを検出するには、opsクラスターで Secret として作成されたkubeconfigファイル（各アプリケーションクラスタ用）を使用します。Pilot は、これらの Secret を使用して、アプリケーションクラスタの Kube API サーバー（上記の Secret を介して認証された）を照会することにより、サービスを検出します。両方のopsクラスタがkubeconfigで作成された Secret を使用して、すべてのアプリクラスタに対して認証できることがわかります。 Операцииクラスターは、Secretとしてkubeconfigファイルを使用してサービスを自動的に検出できます。これには、упсクラスターИспользуйте Pilot, API Kube, Pilot, Kube API.ーバーに到達できない場合、リモートサービスをServiceEntriesとして手動で追加します。 ServiceEntriesは、サービスレジストリのDNSエントリと考えることができます。 ServiceEntriesは、完全修飾DNS名（ FQDN ）と到達可能なIPアドレスを使用してサービスを定義します。詳細については、 Istio Multiclusterのドキュメントを参照してください。

5. инфраструктура リポジトリの説明

Создание облачной инфраструктуры

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

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

Создание облачной infrastructure (Cloud Build). Инфраструктура как код (IaC)クショップの状態は常にこのリポジトリに保存されます。

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

Инфраструктураす。フォルダとサブフォルダに構造化されて います。リポジトリ内のベースフォルダべ、牉定のGCPリソースを所有するチームを表します。フォルダの次のレイヤーは、チームの特定の環境（たとえば、dev、stage、prod）を表します。環境内のフォルダーの次のレイヤーは、特定のリソース(たとえば、host_project、gke_clustersなど）を表します。必要なスクリプトと terra формаファイルは、リソースフォルダー内に存在します。

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

1. инфраструктура - クラウドを管理するインフラストラクチャチームを表します。他のすべてのチームのGCPリソースを作成する責任があります。リソースにはTerraform管理プロジェクトを使用します。インフラストラクチャリポジトリ自体は、Терраформированное состояние ファイル（以下で 説明） に ます。 これら の リソース は 、 ワーク ショップ 作成 プロセス に に スクリプト によって 作成 さ れ ます （について は モジュール 0- インフラストラクチャ - 管理者 用 フロー を 参照。
2. сеть — ネットワークチームを表します。 VPCとネットワークリソースを担当します。彼らは次のGCPリソースを所有しています。
3. host project — 共有VPCのホストプロジェクトを表します。
4. shared VPC — 共有VPC、サブネット、セカンダリIP範囲、ルーティング情報、ファイアウォールルールを表します。
5. ops — 運用 / DevOpsチームを表します。彼らは次のリソースを所有しています。
6. ops project — すべてのopsリソースのためのプロジェクトを表します。
7. gke clusters — リージョンごとのops GKEクラスタ。またIstioコントロールプレーンは、各ops GKEクラスタにインストールされます。
8. k8s-repo - すべてのGKEクラスタのGKEマニフェストを含むCSRリポジトリ。
9. приложения - アプリケーションチームを表します。このワークショップは、 app1とapp2の2つのチームをシミュレーションします。彼らは次のリソースを所有しています。
10. app projects - すべてのアプリチームが個別のプロジェクトセットを持ちます。これにより、プロジェクトごとに請求とIAMを制御できます。
11. gke clusters — これらは、アプリケーションコンテナ/ Pod が実行されるアプリケーション用クラスタです。
12. gce instances - オプション 、 、 インスタンス で 実行 れる アプリケーション が ある 場合 に 使用 ます。 この ワーク ショップ で は 、 app1 に アプリケーション の が 実行 さ れる か の の インスタンス が ます 一部 実行 さ いくつ の の インスタンス が ます。。 れる いくつ の の インスタンス

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

プロバイダ、state、出力 - バックエンド、共有 государство

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

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

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

shared_stateファイルは、リソースのtfstateファイルを指すterraform_remote_stateデータソースです。shared_state_ shared_state_[resource_name].tfファイルは、他のリソースからの出力を必要とするリソースフォルダに存在します。たとえば、 ops_gkeリソースフォルダには、 ops_projectおよびshared_vpcリソース の shared_state ファイル あり ます。 これ は 、 ops プロジェクト で で クラスタ を する に は プロジェクト プロジェクト と vpc の が 必要 だ から です。。。 プロジェクト ファイル 、 （だ に に に に に に に に （（（（、 、 、 、 、 、 、 、 、 、 が が が が が が が が が が が が がテscripts/setup_terraform_admin_projectプレート（ templates/shared_state.tf_tmplに ある） から 生成 れ ます。 すべて の リソース の shared_state ファイル は 、 gcp/[environment]/shared_statesフォルダー に に 、 は は は は は ファイル ファイル は ファイル ファイル ファイル ファイル ファイル ファイル ファイル な ファイル ファイル はます。すべての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 リポジトリ （（（（リポジトリ は 別 別） で 、 マニフェスト マニフェスト すべて の クラスタ に および 適用 する ため 使用 さ れ ます ます。 は は 、 は 、 は 、 、 、 、 は は 、 れ れ。 れ れ 、。 インフラストラクチャ 作成。。。。。。。。 インフラストラクチャ インフラストラクチャ インフラストラクチャ インフラストラクチャ インフラストラk8s_repoインフラストラクチャ インフラストラクチャ インフラストラクチャ インフラストラクチャについて は 、 の セクション を 参照））。 最初 の インフラストラクチャ インフラストラクチャ インフラストラクチャ プk8s_repoセス に 、 合計 6 つ の の クラスタ が 作成 れ ます。。 合計 6 つ の の クラスタ が さ れ ます。。 合計 合計 つ の の クラスタ が さ れ ます。。 合計 つ の の クラスタ が 作成 さ ます。。 、 合計 の は 、 、 フォルダー が さ さ れ （（、 、 、 、 、 、 名 名 名 名 名 名 名 名 名 名すk8s_repo )さ れ ます。 Cloud Build は 、 、 、 さ さ れ。 k8s_repoンフラストラクチャ と に 、 の に トリガー さ れ。 インフラストラクチャ と 同様 、 すべて の トリガー さ れ ます インフラストラクチャ と 同様 、 すべて の トリガー さ れ ます。 と 同様 に すべて の トリガー さ れ ます。 インフラストラクチャ 同様 に すべて の の さ れ ます。 インフラストラクチャ 同様 に すべて の の トリk8s_repoます て て と 同様 、 すべて の マニフェスト は コード とし て て て て て て とし クラスター れ れ れ れ 、 さ れ れ に れ に 保存 各 に 保存 各 に に れ れ に に に 保存 保存 れ 各 各 の保存 さ ます。。

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

プロジェクト, gke クラスター, そして пространство имен

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

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

1. Gcp リソース 構築 するインフラストラクチャ チームは 、 、 、 、 、 管理 プロジェクト を し ます。 彼ら は 、 、 、 リポジトinfrastructureリポジトリ し 、 、 、 、 、 、 、 、 、 、 、 、 、 、 し し バケット れ れ れ れ れ れ れ れ に に れ れ れ に れ れ れ れ に れ れГосударство 情報 保存 し ます。 これら は 、 CSR リポジトリ および Terraform State の gcs バケット の アクセス を 制御 し ます。。。。。
2. 共 有 vpc を するネットワーク チームは 、 、 、 hostロジェクトを 使用 ます。 この プロジェクト に は 、 、 、 、 サブ 、 ルート 、 ルール 含ま れ れ て い。 共 共 vpc 有 、 、 、 の 使用 、 の 、 ます リソース 使用 の 、 リソース 使用 の 使用 の 使用 リソース の を リソース リソース の。 すべて の は 、 ネットワーク に この 単一 の 共 有 vpc を し て い ます。。。。
3. Gke クラスター と asm / istio コントロール を 構築 する するops / platform チーム、 、 opsロジェクトを 使用 し ます。。 クラスター と メッシュ の ライフ を し ます ます。 は 、 クラスター を 強化 し プラットフォーム の。。 これら これら 復元 力 の 復元 のと スケール 管理 する 責任 が あり ます。 この ワーク ショップ で は リソース を を を に に する する メソッド 使用 し ます。 CSR リポジトリ （（（（（し し し し しk8s_repo存在 し 存在 存在 存在 存在 存在
4. 最後 に 、 を 構築 する するdev1 および dev2 チーム(2 つ 開発 チーム を 表す）） は 、 独自 のdev1およびdev2プロジェクト使用 し。 これら は 、 顧客 提供 する アプリケーション と サービス です 、 は 、 顧客 顧客 に に に です が 、 、 、 、 顧客 、管理 する 上 に 構築 さ れ ます。 リソース (развертывание 、 Сервис など） は は は さ れ ます。 この ショップ は は は はk8s_repoール に に に 合わせ に に ツール に 焦点 に て に 焦点 に い に に て 焦点注意 し ください。。 Облачная сборка 。

この ワーク に は 2 種類 の gke クラスター が ます ます。

1. Ops クラスター- Ops チーム が DevOps の を 実行 する ため ため 使用 し ます。 この ワーク ショップ で は 、 asm / istio コントロール を し て メッシュ を 管理 し ます。。。。。。 ます ます し し し し し し
2. アプリケーション (Apps) クラスター- 開発 チーム が を を 実行 する ため に し ます。 この ワーク ショップ は 、 Hipster ショップ に 使用 さ ます。。

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

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

この ワーク ショップ 使用 さ れる アプリケーション である である である である ショップ アプリ 、 、 4 つ アプリ クラスター すべて に 展開 展開 さ ます。 各 サービス は すべて の アプリ クラスター クラスター 個別 の 空間 に 存在 し。 ショップ アプリ の 個別 名前 空間 に し ます。 アプリ の （（（（（（（（（（（ Pod） は 、 Ops クラスター は 展開 さ さ れ ません。 、 すべて の マイクロ の の の と と リソース も クラスター に 作成 れ ます。。。 レジ レジ レジ ストリ ストリ ストリ ストリ ストリ ストリ ストリ ストリ ストリ ストリ レジ ストリ ストリ ストリ サービス ストリ レジ ストリ ストリ ストリ ストリ ストリ ストリ ストリ ストリ（OPS クラスター） サービス が ない 場合 、 アプリ クラスター で 実行 さ れ いる 各 サービス の の の を 手動 で する 必要 が ます。。

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

Kubernetes マニフェスト と k8s_repo

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

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

1. GKE-ASM-1-R1-PROD-リージョン 1 に ある リージョナル OPS クラスター
2. GKE-ASM-2-R2-PROD-リージョン 2 に ある リージョナル OPS クラスター
3. gke-1-apps-r1a-prod-リージョン 1 の ゾーン a に ある アプリ クラスター クラスター クラスター クラスター クラスター
4. gke-2-apps-r1b-prod-リージョン 1 の ゾーン b に ある アプリ クラスター クラスター クラスター クラスター クラスター クラスター
5. GKE-3-APPS-R2A-PROD-リージョン 2 の ゾーン a に ある アプリ クラスター クラスター クラスター クラスター
6. GKE-4-APPS-R2B-PROD-リージョン 2 の ゾーン B に ある アプリ クラスター

k8s_repoに 、 これら の クラスター に 対応 する フォルダー が あり。 これら の フォルダー に に さ れ た は 、 対応 する の に 適用 さ れ ます。 各 の マニフェスト を 容易 に に 容易 に 容易 （に 容易 に に は にの メインフォルダー)

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

目標: Hipster ショップ を を Приложения クラスター に デプロイ する する する する する

• k8s-repoポジトリ クローン クローン クローン
• Хипстер ショップ マニフェスト を 全て の の の クラスター に コピー コピー コピー コピー コピー コピー
• Хипстер ショップ アプリ ため に に Службы を Ops クラスター に 作成 作成
• グローバル の 接続 を テスト する ため ためloadgeneratorを Ops クラスター に セットアップ
• Хипстер ショップ アプリ の セキュア な 接続 を 確認 確認 確認

Ops プロジェクト の を クローン クローン

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

1. Workdir の に 、 リポジトリ 用 の 空 フォルダ を 作成 し。:

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

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

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

 

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

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

4. Хипстерский магазин マニフェスト すべて の クラスター の ソースリポジトリ に コピー し ます。。。。

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

5. Hipster ショップ 、 、 クラスター ではなく 、 アプリケーション クラスター に 展開 さ れ ます。 クラスター は 、 、 asm / istio コントロール で のみ 使用 さ ます。。 、 クラスター から Hipster ショップ の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の の ショップ の ショップ ショップ 、 削除 削除 削除 マニフェスト マニフェスト マニフェスト 削除 削除 削除 削除 削除 削除 削除 削除 を 削除 削除 削除 削除 削除 削除 を 削除 削除

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
 

6. 1 つ の dev クラスター 以外 すべて から から から から 、。。。 は クラスター に さ れ れ た もの 、 4 つ の 続ける こと こと 続ける こと こと こと 続ける こと こと こと こと こと 続ける こと 続ける こと 続ける し して カート に 矛盾 が 生じ てしまい ます。。

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
 

7. 最初 の dev クラスター のみ 、 、 Развертывание расщепления 、 rbac 、 および および および および および および および。。。。。。。。。。。。。。。。 ます

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
 

8. OPS クラスター の Кустомизация. Ямль

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
 

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

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

11. Конфигурационный разъем リソース 各 プロジェクト の クラスター の 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/
 

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

13. loadgenerator нагрузки マニフェスト (развертывание 、 PodsecurityPolicy 、 rbac） を クラスター に コピー し ます。 Hipster ショップ アプリ 、 グローバル な Google Cloud Load Balancer （gclb） を を を （（（）））））） frontend ））））））））））））））））））））））））））））））））））））））） 、 サーloadgeneratorス 最も 近い インスタンス に 送信 し ます。。。 を を の の クラスター に 配置 する と 、 クラスター で 実行 さ て いる の の する と ゲートウェイ ゲートウェイ の は は について について は について は について は について は について 分散 について 分散 は 分散説明 し ます。

cp -r k8s_manifests/prod/app-loadgenerator/. ../k8s-repo/gke-asm-1-r1-prod/app-loadgenerator/.
cp -r k8s_manifests/prod/app-loadgenerator/. ../k8s-repo/gke-asm-2-r2-prod/app-loadgenerator/.
 

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

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

16. k8s-repoに し ます。。。。。

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

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

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

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

18. カート を 除い た の アプリケーション アプリケーション Пространство имен

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

19. Пространство имен телеги の Pod が 最初 最初 の dev クラスター で 実行 実行 状態 （（） こと を 確認 し ます。。。。。。

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ービス に アクセス し て に に ます は は は ます ます ます ます ます ます ます ます ますfrontendサービス は 、 4 つ の アプリ クラスター すべて で 実行 さ れ ます。。。。。。。 frontendス サービス サービス サービス の 4 つの インスタンスに クライアント トラフィック 取得 し ます。。 の 4 つの すべて クライアント トラフィック 取得 し ます ます

ISTIO INGRESS ゲートウェイは クラスター で のみ 実行 さ れ 、 リージョン の の 2 つの アプリケーション クラスター に対する リージョナル リージョナル ロード として 機能 ます。。 は 、 グローバル フロント エンド サービス へバック バックとし とし の ゲートウェイ ゲートウェイ （（（（（（（（（（（（（（（（（ゲートウェイ （つ ゲートウェイ ゲートウェイ （実行） を し ます。。。。 ゲートウェイ は 、 、 gclb から トラフィック を 受信 し 、 クライアント トラフィック を クラスター で 実行 れ て フロント

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

GKE Autoneg コントローラー

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

Облачные конечные точкиとマネージド証明書を使ったセキュアなIngress

Gcp マネージド 書は 、 、 、 、 frontend 、 、 サービス へ の クライアント トラフィック 保護 する ため に 使用 さ れ れ ます。 gclb は グローバルfrontendル サービス マネージド 証明 書 を 使用 し ssl は は。 ショップ ショップ。。。。 ショップ ます ショップ ます。 ます この ます この ショップ証明 書 の として としてКонечные точки облакаを し ます。 または 、 、 、 frontendドメイン と dns 名 使用 し て 、 gcp マネージド 書 を 作成 ます。。。。。。。。。

20. Хипстер ショップ アクセス する ため に 、 下記 の コマンド で 出力 れる リンク を クリック し ます。。。

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

21. Chrome タブ の url バー ロック 記号 を クリック し て 、 証明書 が 有効 である を 確認 確認 でき。。

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

アプリケーション 展開 の とし て 、 、 gclb Hipster ショップ の の の リンク へ テスト を 生成 生成 する 両方 の クラスター クラスター 、 負荷 機能 が 展開 する まし まし た。 クラスター を を 、 の の ゲートウェイ ゲートウェイ ゲートウェイ ゲートウェイ ゲートウェイ ゲートウェイ ゲートウェイ ゲートウェイ ゲートウェイ の ゲートウェイ ゲートウェイ の ゲートウェイ の の し の し し の し の の し ゲートウェイ し し の ゲートウェイ ゲートウェイて いる を 確認 し ます。。。。

22. Хипстер ショップ 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"
 

23. 以下 に 示す よう 、 、 Backend ドロップ ダウンメニュー からВсе бэкэндыからistio-ingressgatewayに 変更 ます ます。。。。。。。

24. 両方 のistio-ingressgatewaysに 向かう を 確認 し て ください。。。。。。。。。。

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

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

7. Stackdriver による 可 観測性

目標: istio の データ を を を に 連携 し 、 確認 する する する する する する する

• istio-telemetryリソース インストール インストール
• Службы ISTIO の ボード を/更新 更新 更新
• コンテナ の を 表示 表示
• Stackdriver で トレーシング 情報 を 表示 表示 表示

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

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

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

26. k8s-repo に し ます。。。。。

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

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

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

28. Istio → Stackdriver の 連携 を し ます。 。stackdriver обработчик Crd を し ます。。。。。

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

出力 に は 、 Stackdriver という の の の が 表示 さ れる はず です:

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] を 選択 ます。 新しい 新しい の プロンプト 表示 さ れ たら ダイアログ を ます ます について プロンプト 表示 さ れ ダイアログ を 閉じ ます。。 プロンプト れ たら ダイアログ を ます

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

（の 行 を 表示 する 場合 は 、 destination_service_name で 化 する 必要 が あり ます。））

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

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

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

29. 次 に あらかじめ 用意 さ れ て いる メトリック ダッシュ ボードを 追加 ましょ う。。 て 直接 使用 ます。 は 、 、 呼び出し を で 生成 する する 場合 通常 行い ませ ん 化 システム する する する する する する する する する する である、 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 

30. 以下 の さ れ た リンク に 移動 し て 、 新しく さ れ た ダッシュ ボード を 表示 し ます。。。。。

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

Ux を し て ダッシュ ボード を その 場 で 編集 する も でき ます が 、 今回 の ケース で は 、 を を し て グラフ すばやく 追加 し し ます。 ため に は の バージョン し し し し し し し し し編集 内容 を し て から 、 、 http Patch メソッド を し て プッシュ する 必要 が あり ます。。

31. モニタリング 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
 

32. 新しい グラフ の 追加 ： (50th ％ ％ ％）） ： [ API -ссылка ] これ 、 新しい グラフ ウィジェット を コード で ダッシュ ボード に でき ます この 変更 は 、 ピア によって さ れ 、 バージョン 管理 チェックイン れ ピア ピア によって によって によって ます れ れ れ さ れ。追加 する ウィジェット 、 、 50 ％ の 待機 時間 (задержка の 中央 値） を て い ます。。。。。

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

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

33. 既存 の 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
 

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

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

35. 簡単 な 分析 を 行い ます。。。。

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

ログエントリ の 例 （場合 、 、 Engine プロキシ の occesslog) は の よう に なり ます ます （整形 済み）。:

  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 コンテナー 選択 し 、 "Пилот"-で 検索 し ます。

ここ で 、 各 サンプル アプリ サービス の プロキシ 設定 を プッシュ する する コントロール プレーン を 見る ことができ。。 "cds" 、 "lds" 、 および "rds" は 異なる api を 表し （ （情報）。。。。。

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

Хипстер ショップ の いくつ か の サンプル フィルター を 示し ます:

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

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

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

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

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

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

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

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

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

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

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

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 ゴールデンメトリクスダッシュボードは、全体的としてシステムが機能しているという安心感を与えてくれます。

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

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

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

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

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

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

mTLSの動作確認

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

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

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

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

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

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

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

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

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

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

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

51. frontend v2のDev1ロールアウトが完了すると、スクリプトの最後に成功メッセージが表示されます。

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

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

52. そして、Dev1 Podからのすべてのfrontendトラフィックはfrontend v2に向いていなければなりません。:

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

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

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

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

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

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

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

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

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

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

cd $AUTHZ_DIR
 

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

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

61. 変更をプッシュします。

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

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

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

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

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

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

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

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

67. 更新をプッシュします。

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

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

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

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

74. 更新をプッシュします。

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

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

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

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

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

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

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

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

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

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

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

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

1. Cloud Shellで、WORKDIRに移動し、 infrastructureリポジトリのクローンを作成します。

cd ${WORKDIR}
mkdir -p ${WORKDIR}/infra-repo
cd ${WORKDIR}/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure

git config --local user.email ${MY_USER} && git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master
 

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

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

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

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

./asm/scripts/add-project.sh
 

5. コミットにより、 infrastructureリポジトリがトリガーされ、新しいリソースでインフラストラクチャがデプロイされます。次のリンクの出力をクリックし、上部の最新ビルドに移動して、Cloud Buildの進行状況を表示します。

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

この手順を完了するには25〜30分かかります。コーヒーブレイクにちょうど良い時間です。

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

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

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

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

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

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

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

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

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

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

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

12. オプションで、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）エラーを受け取ります。これを実際に見てみましょう。

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

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

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

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

80. 変更をコミットします。

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

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

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

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

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

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

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

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

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

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

89. 変更をプッシュします。

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

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

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

94. 変更をプッシュします。

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

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

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

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

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

Pilotの監視

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

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

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

98. ブラウザから" 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の監視

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

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

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

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

重要な監視メトリクス

リソース使用量

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

Mixer概要

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

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

Galleyの監視

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

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

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

CLOUD SHELL

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

gcloud config list
 

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

cd ${WORKDIR}/asm
 

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

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

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

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