סדנה ל-Anthos Service Mesh: מדריך Lab – יפנית

1. סדנת אלפא

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

2. 概要

アーキテクチャ図

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

הנושאים לדיון

TODO - update with final breakdown

前提条件

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

GCP組織リソース
請求先アカウントID（あなたがこのアカウントの請求先アカウント管理者である必要があります）
תפקיד IAM של אדמין הארגון ברמת הארגון

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

説明: スクリプトを作成してワークショップを生成する

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

כדי ליצור סדנה, צריך להזין את הפרטים הבאים:

שם הארגון (לדוגמה, yourcompany.com)- これはあなたがワークショップ環境を作成する組織の名称です。
請求先アカウントID (例. 12345-12345-12345) - このIDがワークショップで作成される全てのリソースの請求先として使われます。
ワークショップ番号 (例. 01) - 2桁の数字。これは、1日に複数のワークショップを行っており、それらを個別に管理したい場合に使用されます。ワークショップ番号は、プロジェクトIDの命名にも使用されます。個別のワークショップ番号を使用すると、毎回一意のプロジェクトIDを取得しやすくなります。ワークショップ番号に加えて、現在の日付（YYMMDD形式）もプロジェクトIDに使用されます。日付とワークショップ番号の組み合わせにより、一意のプロジェクト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 には次の組織レベルの権限が必要です:

בעלים – הרשאות בעלים של פרויקט לכל הפרויקטים בארגון.
מנהל תיקיות – היכולת ליצור ולמחוק תיקיות בארגון.すべてのユーザーは、プロジェクト内のすべてのリソースを含む単一のフォルダを取得します。
組織の管理者
יוצרי פרויקטים – הרשאה ליצור פרויקטים בארגון.
プロジェクトの削除 - 組織内のプロジェクトを削除する権限。
Project IAM 管理者 – 権限: 組織内のすべてのプロジェクトに IAM のルールを作成する。

さらに、ADMIN_USER はワークショップで使用される請求アカウントIDの請求管理者でもある必要があります。

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

組織内のユーザー（自分以外）向けにこのワークショップを作成する場合は、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 (גרסה >= 270)
‫kubectl
‫sed (פועל ב-Cloud Shell / Linux sed ולא ב-Mac OS)
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 (גרסה >= 270)
‫kubectl
‫sed (פועל ב-Cloud Shell / Linux sed ולא ב-Mac OS)
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:上記のアーキテクチャ図も参考になります。

組織内の4つのGCPプロジェクト。כל פרויקט מקושר למזהה חשבון לחיוב שסופק.
1つのプロジェクトは、共有VPCが設定されている network host projectです。このプロジェクトには、他のリソースは作成されません。
1つのプロジェクトは、IstioコントロールプレーンのGKEクラスタに使用される ops project です。
それ以外の2つのプロジェクトは、それぞれのサービスに取り組んでいる2つの異なる開発チームを表しています。
3つの ops、dev1 および dev2 プロジェクトのそれぞれで、2つのGKEクラスターが作成されます。
Kubernetesのマニフェストファイル用の6つのフォルダを含む k8s-repo という名前のCSRリポジトリが作成されます。 GKEクラスタごとに1つのフォルダがあります。このリポジトリは、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 のインストール確認

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

Istioが両方のdev1クラスターにインストールされていることを確認してください。dev1ב-cluster, רק 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クラスタが作成される単一の共有VPCを使用します。クラスター全体でサービスを検出するには、ops クラスターで Secret として作成された kubeconfig ファイル（各アプリケーションクラスター用）を使用します。Pilot は、これらの Secret を使用して、アプリケーションクラスタの Kube API サーバー（上記の Secret を介して認証された）を照会することにより、サービスを検出します。両方のopsクラスタがkubeconfigで作成された Secret を使用して、すべてのアプリクラスタに対して認証できることがわかります。 Opsクラスターは、Secretとしてkubeconfigファイルを使用してサービスを自動的に検出できます。これには、opsクラスター内のPilotが他のすべてのクラスターのKube APIサーバーにアクセスできることが必要です。 Pilot が Kube API サーバーに到達できない場合は、リモートサービスを ServiceEntries として手動で追加します。 ‫ServiceEntries は、DNS エントリ של רשומת שירות. ServiceEntriesは、完全修飾DNS名（ FQDN）と到達可能なIPアドレスを使用してサービスを定義します。詳しくは、Istio Multicluster のドキュメントをご覧ください。

‫5. תיאור של מאגר infrastructure

Infrastructure Cloud Build

ワークショップの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コントロールプレーンは、各ops GKEクラスタにインストールされます。
k8s-repo – リポジトリには、すべてのGKEクラスタのGKEマニフェストを含むCSRが含まれます。
‫apps – מייצג את צוות האפליקציות.このワークショップは、app1 と app2 の2つのチームをシミュレーションします。彼らは次のリソースを所有しています。
app projects - すべてのアプリチームが個別のプロジェクトセットを持ちます。これにより、プロジェクトごとに請求とIAMを制御できます。
‫gke clusters – これらは、アプリケーションコンテナ/ Pod が実行されるアプリケーション用クラスタです。
‫gce instances – אופציונלי, אם יש אפליקציה שפועלת במופע GCE.このワークショップでは、app1 に、アプリケーションの一部が実行されるいくつかのGCEインスタンスがあります。

בסדנה הזו, נשתמש באותה אפליקציה (אפליקציית Hipster Shop) גם ב-app1 וגם ב-app2.

プロバイダ、state、出力 - バックエンド、共有 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_[resource_name].tf הקובץ נמצא בתיקיית משאבים שדורשת פלט ממשאבים אחרים.たとえば、ops_gke リソースフォルダには、ops_project および shared_vpc リソースの shared_state ファイルがあります。これは、opsプロジェクトでGKEクラスタを作成するにはプロジェクトIDとVPCの詳細が必要だからです。 קובץ shared_state נוצר מתבנית (ב-templates/shared_state.tf_tmpl) באמצעות סקריפט (ב-scripts/setup_terraform_admin_project).すべてのリソースの shared_state ファイルは、gcp/[environment]/shared_states フォルダーに配置されます。קובץ shared_state הנדרש הוא קישור סמלי בכל תיקיית משאבים.すべてのshared_stateファイルを1つのフォルダーに配置し、それらを適切なリソースフォルダーにsymリンクすると、すべての状態ファイルを1か所で簡単に管理できます。

変数

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

Terraform variables are stored as TF_VAR_[variable name] in 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つのチームが出てきます。

インフラストラクチャチームは、Terraform管理プロジェクトを使用してGCPリソースを構築します。彼らは、CSRリポジトリ（infrastructure と呼ばれる）のコードとしてインフラストラクチャを管理し、GCSバケットのGCPで構築されたリソースに関するすべてのTerraform state情報を保存します。これらは、CSRリポジトリおよびTerraform state のGCSバケットへのアクセスを制御します。
ネットワークチームは、hostプロジェクトを使用して共有VPCを構築します。このプロジェクトには、VPC、サブネット、ルート、ファイアウォールルールが含まれています。共有VPCを使用すると、GCPリソースのネットワークを一元管理できます。すべてのプロジェクトは、ネットワークにこの単一の共有VPCを使用しています。
צוות ה-ops / platform משתמש בopsפרויקט כדי ליצור אשכול GKE ומישור בקרה של ASM / Istio. 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コントロールプレーンを実行してサービスメッシュを管理します。
קלאסטר של אפליקציות – צוותי פיתוח משתמשים בו כדי להריץ אפליקציות.このワークショップでは、Hipster ショップアプリに使用されます。

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

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

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

בסדנה הזו נראה איך פורסים אפליקציית מיקרו-שירותים בת 10 שכבות.このアプリケーションは、「 Hipster Shop」と呼ばれるウェブベースの eコマースアプリで、ユーザーはアイテムを参照してカートに追加し、購入することができます。

Kubernetes マニフェストと k8s_repo

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

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

‫gke-asm-1-r1-prod – リージョン1にあるリージョナルopsクラスター
‫gke-asm-2-r2-prod – אזור 2 מכיל אשכול אזורי של מחלקת ops
‪gke-1-apps-r1a-prod - リージョン1のゾーンaにあるアプリクラスター
‫gke-2-apps-r1b-prod – リージョン1のゾーンbにあるアプリクラスター
‫gke-3-apps-r2a-prod – кластер приложений в зоне a региона 2
‫gke-4-apps-r2b-prod – кластер приложений в зоне b региона 2

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ショップのdeployment、PodSecurityPolicyおよびRBACマニフェストを削除します。

rm -rf ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/deployments
rm -rf ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/deployments
rm -rf ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/podsecuritypolicies
rm -rf ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/podsecuritypolicies
rm -rf ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/rbac
rm -rf ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/rbac

‫1つのdevクラスター以外のすべてからcartservice deployment、RBACおよびPodSecurityPolicyを削除します。 Hipster Shop はマルチクラスター展開用に構築されたものではなく、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

最初の開発クラスターのみで、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/

Zastąp PROJECT_ID w pliku manifestu Config Connector.

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 네임스페이스의 Pod가 첫 번째 개발 클러스터에서만 실행 상태(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ショップアプリにアクセスできます。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のドメインとDNS名を使用して、GCPマネージド証明書を作成できます。

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

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

כדי לוודא שהאישור תקף, אפשר ללחוץ על סמל הנעילה בסרגל כתובות ה-URL בכרטיסיית Chrome.

אימות של איזון עומסים גלובלי

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

‫HipsterショップGCLBが作成されている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クラスターリージョン2で生成された負荷は、リージョン1のistio-ingressgatewayに送信されます。

7. Stackdriverによる可観測性

連携及確認する" id="目標:-istioのテレメトリデータをstackdriverに連携し、確認する" is-upgraded="" tabindex="-1">目標: IstioのテレメトリデータをStackdriverに連携し、確認する

istio-telemetryהתקנת משאבים
Istio Servicesのダッシュボードを作成/更新
コンテナのログを表示
Stackdriverで分散トレーシング情報を表示

Istioの主要な機能の1つは、ビルトインの可観測性（"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システムにあるので、それらを視覚化する方法が必要です。בקטע הזה נתקין לוח בקרה מוכן מראש שמציג 3 מתוך 4 'אותות הזהב' של מדדים.תנועה (בקשות לשנייה), חביון (במקרה הזה, אחוזון 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%の待機時間（latencyの中央値）が表示されます。

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

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

דוגמה של רשומה ביומן (במקרה הזה, accesslog של Envoy proxy) מוצגת כאן (אחרי עיצוב)::

  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 מייצגים ממשקי API שונים של Envoy (מידע נוסף).

Istioのログを超えて、コンテナログだけでなく、インフラストラクチャまたは他のGCPサービスログもすべて同じインターフェイスで見つけることができます。次に、GKEのサンプルログクエリを示します。ログビューアでは、ログから指標を作成することもできます（たとえば、「文字列に一致するすべてのエラーをカウントする」）。ダッシュボードで、またはアラートの一部として使用できます。אפשר גם להזרים את היומנים לכלים אחרים לניתוח, כמו BigQuery.

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

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

דוגמה לצילום מסך של הכלי:

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

Prometheusと 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
(חשוב לפתוח את כתובת ה-URL בחלון פרטי של Chrome, שבו פתוח גם Cloud Shell)

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

8. 相互TLS認証

היעד: הגדרת חיבור מאובטח(אימות) בין מיקרו-שירותים

הפעלת mTLS ברשת כולה
調査ログを使いmTLSを確認

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

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

opsクラスターのMeshPolicyを確認します。הערה: ‏mTLS הוא קבוע ומאפשר תנועה מוצפנת ותנועה שאינה mTLS.

kubectl --context ${OPS_GKE_1} get MeshPolicy -o yaml
kubectl --context ${OPS_GKE_2} get MeshPolicy -o yaml

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

  spec:
    peers:
    - mtls:
        mode: PERMISSIVE

mTLSをオンにします。 Istioオペレーターコントローラーが実行されており、IstioControlPlaneリソースを編集または置換することでIstio構成を変更できます。コントローラーは変更を検出し、それに応じてIstioインストール状態を更新することで対応します。‫mTLS を有効にするように IstioControlPlane リソースを設定します, גם במישור הבקרה המשותף וגם במישור הבקרה המשוכפל.これにより、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": {}
    }
  ]
}

בודקים את DestinationRule שנוצר על ידי בקר האופרטור של Istio.

kubectl --context ${OPS_GKE_1} get DestinationRule default -n istio-system -o yaml
kubectl --context ${OPS_GKE_2} get DestinationRule default -n istio-system -o yaml

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

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

בנוסף, אפשר לראות ביומן את המעבר מ-HTTP ל-HTTPS. UIのログからこの特定のフィールドを公開するには、ログエントリを1つクリックしてから、表示したいフィールドの値をクリックします。この場合、「プロトコル」の横にある「http」をクリックします。:

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

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

TODO(smcghee)

9. פריסה של גרסת הגישוש

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

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

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

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

まず、**DEV1リージョン（us-west1）**でカナリアパイプラインを実行し、そのリージョンの両方のクラスターでfrontend v2を展開します。다음으로, **DEV2 리전(us-central)**에서 카나리아 파이프라인을 실행하고 해당 리전의 두 클러스터에 v2를 배포합니다.リージョンごとにパイプラインを順番に実行することは、すべてのリージョンで並列に実行するのではなく、不適切な構成またはv2アプリ自体のバグによって引き起こされるグローバルな停止を回避するのに役立ちます。

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

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

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

מריצים את הסקריפט repo_setup.sh כדי להעתיק את מניפסט הבסיס אל k8s-repo.

cd $CANARY_DIR
./repo-setup.sh

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

פריסת frontend-v2
‫frontend-v1 תיקון (כולל תמונת מאגר עם התווית v1 ונקודת הקצה /version)
‫respy, ‏ HTTP応答の分布を書き出し、カナリアデプロイメントをリアルタイムで視覚化するのに役立つ小さなPod。
‫frontend Istio DestinationRule – מחלק את שירות ה-frontend של Kubernetes לשתי קבוצות משנה, 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リージョンでカナリアパイプラインを実行します。 מספק סקריפט לעדכון אחוז התעבורה של קצה קדמי v2 ב-VirtualService (עדכון המשקלים ל-20%, 50%, 80%, 100%).各更新の間で、スクリプトはCloud Buildパイプラインが完了するのを待ちます。 Dev1リージョンのカナリアデプロイメントスクリプトを実行します。注-このスクリプトの完了には約10分かかります。

cd ${CANARY_DIR}
K8S_REPO=${K8S_REPO} CANARY_DIR=${CANARY_DIR} OPS_DIR=${OPS_GKE_1_CLUSTER} OPS_CONTEXT=${OPS_GKE_1} ./auto-canary.sh

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

תוצאה (אין להעתיק)

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

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

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

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

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

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

Dev1でrespy Podを終了します。次に、Dev2リージョンで実行されているrespy Podに入ります。

RESPY_POD=$(kubectl --context ${DEV2_GKE_1} get pod -n frontend | grep respy | awk '{ print $1 }')
kubectl --context ${DEV2_GKE_1} exec -n frontend -it $RESPY_POD -c respy /bin/sh

respyコマンドを再度実行します。:

watch -n 1 ./respy --u http://frontend:80/version --c 10 --n 500

תוצאה (אין להעתיק)

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

*שימו לב שאזור Dev2 עדיין 'נעול' בגרסה 1.*これは、ベースラインのrepo_setupスクリプトで、VirtualServiceをプッシュして、すべてのトラフィックを明示的にv1に送信したためです。このようにして、Dev1でリージョンのカナリアを安全に実行し、新しいバージョンをグローバルに展開する前にそれが正常に実行されたことを確認できました。

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

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

Dev2のRespy Podから、Dev2 Podからのトラフィックがfrontend v1からv2に徐々に移動するのを見てください。スクリプトが完了すると、次のように表示されます。:

תוצאה (אין להעתיק)

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

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

10. 認可ポリシー

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

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

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

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

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

Перейдите в каталог примеров для утверждения.

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

cd $AUTHZ_DIR

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

cat currency-deny-all.yaml

תוצאה (אין להעתיק)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice

両方のリージョンのopsクラスターのcurrencyポリシーをk8s-repoにコピーします。

mkdir -p ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/
sed -i '/  - app-ingress\//a\ \ - app-authorization\/' ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/kustomization.yaml
cp currency-deny-all.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/; kustomize create --autodetect
cd $AUTHZ_DIR 

mkdir -p ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/
sed -i '/  - app-ingress\//a\ \ - app-authorization\/' ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/kustomization.yaml
cp currency-deny-all.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/; kustomize create --autodetect

変更をプッシュします。

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

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

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

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

currencyサービスがこのAuthorizationPolicyをどのように適用しているかを調べてみましょう。まず、ブロックされた認可呼び出しはデフォルトでは記録されないため、currency PodのいずれかのEnvoyプロキシでトレースレベルのログを有効にします。

CURRENCY_POD=$(kubectl --context ${DEV1_GKE_2} get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context ${DEV1_GKE_2} exec -it $CURRENCY_POD -n currency -c istio-proxy /bin/sh 
curl -X POST "http://localhost:15000/logging?level=trace"; exit

currencyサービスのサイドカープロキシからRBAC（認可）ログを取得します。 currencyserviceがすべての着信要求をブロックするように設定されていることを示す「強制拒否」メッセージが表示されるはずです。

kubectl --context ${DEV1_GKE_2} logs -n currency $CURRENCY_POD -c istio-proxy | grep -m 3 rbac

תוצאה (אין להעתיק)

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied

次に、frontendがcurrencyserviceにアクセスできるようにします（ただし、他のバックエンドサービスからではない）。 currency-allow-frontend.yamlを開き、その内容を調べます。次のルールを追加したことを確認してください。:

cat currency-allow-frontend.yaml

תוצאה (אין להעתיק)

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

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

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

更新されたcurrencyポリシーをコピーします。

cp $AUTHZ_DIR/currency-allow-frontend.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cp $AUTHZ_DIR/currency-allow-frontend.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml

更新をプッシュします。

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

מחכים עד ש-Cloud Build יסיים את הפעולה.
פותחים שוב את ה-frontend של אפליקציית Hipster Shop.今回は、ホームページにエラーが表示されないはずです。זאת מכיוון שהקצה הקדמי מאפשר גישה לשירות הנוכחי באופן מפורש.
次に、カートにアイテムを追加し、[place order]（注文）をクリックして、チェックアウトを実行してください。今回は、currencyサービスから価格変換エラーが表示されるはずです。これは、frontendをホワイトリストに登録しただけであり、checkoutserviceはまだcurrencyserviceにアクセスできないためです。

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

cat currency-allow-frontend-checkout.yaml

תוצאה (אין להעתיק)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]

最終的な認可ポリシーをk8s-repoにコピーします。

cp $AUTHZ_DIR/currency-allow-frontend-checkout.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cp $AUTHZ_DIR/currency-allow-frontend-checkout.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml

更新をプッシュします。

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

מחכים עד ש-Cloud Build יסיים את הפעולה.
チェックアウトを実行してみてください。正常に動作するはずです。

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

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

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

infrastructureリポジトリをクローン
terraformファイルを更新して新しいリソースを作成
שני תתי-רשתות באזור חדש (אחת לפרויקט ops ואחת לפרויקט חדש)
新しいリージョンに新しいopsクラスター (新しいサブネット内に)
‫Istio コントロールプレーンを新しいリージョンに
‫2 кластера приложений в новом проекте в новом регионе
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 יסיים את הפעולה בהצלחה, לוחצים על הקישור הבא שמופיע בפלט כדי לעבור ל-Cloud Build האחרון של k8s-repo שהופעל.

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

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

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

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

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

מציג את הקשר של האשכול. ‫8 つのクラスターが表示されるはずです。

kubectl config view -ojson | jq -r '.clusters[].name'

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

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

Istioインストールの確認

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

kubectl --context ${OPS_GKE_3} get pods -n istio-system

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

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m

Istioが両方のdev3クラスターにインストールされていることを確認してください。 dev3클러스터에서 실행되는 것은 Citadel, sidecar-injector, coredn뿐입니다.ops-3クラスターで実行されているIstioコントロールプレーンを共有します。

kubectl --context ${DEV3_GKE_1} get pods -n istio-system
kubectl --context ${DEV3_GKE_2} get pods -n istio-system

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

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

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

必要に応じて、6つのアプリケーションクラスターのすべてのopsクラスターにSecretがデプロイされていることを確認します。

kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_3} get secrets -l istio/multiCluster=true -n istio-system

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

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

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

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

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

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

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

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

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

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

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

אתם יכולים להשתמש ב-DestinationRules של Istio כדי להגדיר מדיניות של מפסק זרם.このセクションでは、次のポリシーを適用して、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秒間新しいクライアント要求から保護されます。 Si le coupe-circuit Envoy est ouvert (actif), le client reçoit une erreur 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つの方法です。עם זאת, מפסק זרם עלול לגרום לשיבוש (שעלול להיות טעות מצד המשתמש), וזה לא אידיאלי.Pour ces erreurs, vous pouvez utiliser des tests de chaos dans un environnement de préproduction afin de mieux prévoir comment les services en aval répondront lorsque le backend renverra une erreur.カオステストは、システム内の弱点を分析し、フォールトトレランスを向上させるために、意図的にサービスを中断する方法です。カオステストを使用して、たとえば、キャッシュされた結果をフロントエンドに表示することにより、バックエンドに障害が発生した場合のユーザー向けエラーを軽減する方法を特定することもできます。

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

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

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

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

k8s_manifests / prod / istio-networking / app-recommendation-vs-fault.yamlを開いてその内容を検査します。注意: Istioには、リクエストのパーセンテージにフォールトを挿入するオプションがあります。ここでは、すべてのrecommendationserviceリクエストにタイムアウトを挿入します。

תוצאה (אין להעתיק)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s

‫VirtualService を k8s_repo にコピーします。グローバルに障害を挿入するため両方のリージョンに設定を行います。

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

変更をプッシュします。

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

מחכים עד ש-Cloud Build יסיים את הפעולה.
サーキットブレーカーセクションでデプロイされたfortio Podに入り、いくつかのトラフィックをrecommendationserviceに送信します。

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

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

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

תוצאה (אין להעתיק)

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055

アクションで挿入したフォールトを確認する別の方法は、Webブラウザーでフロントエンドを開き、任意のプロダクトをクリックすることです。הטעינה של דף המוצר נמשכת עוד 5 שניות כדי לאחזר את נתוני ההמלצות שמוצגים בחלק התחתון של הדף.
両方のOpsクラスターからフォールトインジェクションサービスを削除してクリーンアップします。

kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

変更をプッシュします。

cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM

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

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

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

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

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

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

Pilotの監視

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

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

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

בדפדפן, פותחים את BASE_URL/dashboard/db/istio-pilot-dashboard כדי להציג את המדדים של Pilot.

מדדי מעקב חשובים

リソース使用量

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

Pilotのプッシュ情報

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

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

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

Envoy情報

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

מעקב במיקסר

Mixer הוא רכיב שמרכז את הטלמטריה מ-Envoy proxy אל קצה עורפי של טלמטריה (בדרך כלל Prometheus,‏ Stackdriver וכו').この容量では、データプレーンにはありません。 ‫2つのKubernetes Jobs（Mixerと呼ばれる）としてデプロイされます。これらのJobには、2つの異なるサービス名（istio-telemetryとistio-policy）が付けられています。

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 Service Mesh: מדריך Lab – יפנית

1. סדנת אלפא

2. 概要

アーキテクチャ図

הנושאים לדיון

前提条件

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

説明: スクリプトを作成してワークショップを生成する

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

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

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

ワークショップのセットアップ（単一ユーザーセットアップ）

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

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

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

ユーザー情報の取得

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

インストールの確認

Istio のインストール確認

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

‫5. תיאור של מאגר infrastructure

Infrastructure Cloud Build

מבנה התיקיות – צוותים, סביבות ומשאבים

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

変数

K8s リポジトリの説明

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

Kubernetes マニフェストと k8s_repo

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

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

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

העתקה, ביצוע קומיט ודחיפה של קובץ המניפסט

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

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

グローバル負荷分散

GKE Autoneg コントローラー

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

אימות של איזון עומסים גלובלי

7. Stackdriverによる可観測性

連携及確認する" id="目標:-istioのテレメトリデータをstackdriverに連携し、確認する" is-upgraded="" tabindex="-1">目標: IstioのテレメトリデータをStackdriverに連携し、確認する

8. 相互TLS認証

היעד: הגדרת חיבור מאובטח(אימות) בין מיקרו-שירותים

mTLSの動作確認

9. פריסה של גרסת הגישוש

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

10. 認可ポリシー

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

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

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

Istioインストールの確認

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

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

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

13. הזרקת תקלות (Fault Injection)

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

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

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

Pilotの監視

מדדי מעקב חשובים

מעקב במיקסר

מדדי מעקב חשובים

מעקב ב-Galley

מדדי מעקב חשובים

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

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

設定エラーの発見

16. ניקוי

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

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