Hội thảo về lưới dịch vụ Anthos: Hướng dẫn cho phòng thí nghiệm – Tiếng Nhật

1. HỘI THẢO ALPHA

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

2. 概要

アーキテクチャ図

Đây là một buổi thực hành mang tính thực tế, trong đó bạn sẽ trải nghiệm cách thiết lập các dịch vụ phân tán trên toàn cầu trong môi trường sản xuất trên GCP.使用する主なテクノロジーは、コンピューティング用の Google Kubernetes Engine（GKE）と、セキュアな接続、可観測性、高度なトラフィック操作を実現する Istioサービスメッシュです。このワークショップで使用されるすべてのプラクティスとツールは、実際に本番で使用するものと同じです。

Chương trình làm việc

TODO – update with final breakdown

Điều kiện tiên quyết

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

GCP組織リソース
請求先アカウント ID (Bạn phải là 請求先アカウント管理者 của tài khoản này)
Organization Administrator IAM role (Vai trò Quản trị viên tổ chức IAM) cho cấp tổ chức

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

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

bootstrap_workshop.shというスクリプトを使用して、ワークショップの初期環境を構築します。Bạn có thể dùng tập lệnh này để thiết lập một môi trường cho riêng mình hoặc nhiều môi trường cho nhiều người dùng.

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

組織名 (例. yourcompany.com)- これはあなたがワークショップ環境を作成する組織の名称です。
請求先アカウントID (例. 12345-12345-12345) - このIDがワークショップで作成される全てのリソースの請求先として使われます。
ワークショップ番号 (例. 01) – 2桁の数字。これは、1日に複数のワークショップを行っており、それらを個別に管理したい場合に使用されます。ワークショップ番号は、プロジェクトIDの命名にも使用されます。個別のワークショップ番号を使用すると、毎回一意のプロジェクトIDを取得しやすくなります。ワークショップ番号に加えて、現在の日付（YYMMDD形式）もプロジェクトIDに使用されます。日付とワークショップ番号の組み合わせにより、一意のプロジェクトIDが提供されます。
ユーザーの開始番号 (例. 1) – Đây là số người dùng đầu tiên của hội thảo.たとえば、10人のユーザー向けのワークショップを作成する場合、ユーザーの開始番号が1、ユーザーの終了番号が10となります
ユーザーの終了番号 (例. 10) – Đây là số người dùng cuối cùng của hội thảo.たとえば、10人のユーザー向けのワークショップを作成する場合、ユーザーの開始番号が1、ユーザーの終了番号が10となります。Nếu bạn đang thiết lập một môi trường duy nhất (ví dụ: cho chính bạn), thì số bắt đầu và số kết thúc của người dùng sẽ giống nhau.これにより、単一の環境が構築されます。

管理用 GCS バケット (例. my-gcs-bucket-name) - このGCSバケットは、ワークショップ関連の情報を保存するために使用されます。Thông tin đó được dùng bởi tập lệnh cleanup_workshop.sh để xoá đúng cách tất cả các tài nguyên được tạo trong tập lệnh tạo hội thảo.ワークショップを作成する管理者は、このバケットに対する読み取り/書き込み権限が必要です。

スクリプトの作成ワークショップは上記の値を使用し、 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 には次の組織レベルの権限が必要です:

オーナー – プロジェクトオーナーの権限。組織内のすべてのプロジェクトに適用されます。
フォルダ管理者 – 組織内のフォルダを作成および削除する機能。Tất cả người dùng sẽ nhận được một thư mục duy nhất chứa mọi tài nguyên trong dự án.
組織の管理者
プロジェクト作成者 – 組織内にプロジェクトを作成する権限。
プロジェクトの削除 – 組織内のプロジェクトを削除する権限。
Project IAM 管理者 – Có quyền tạo các quy tắc IAM cho tất cả các dự án trong tổ chức.

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

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

組織内のユーザー（自分以外）向けにこのワークショップを作成する場合は、MY_USER の特定のユーザー命名ルールに従う必要があります。 Trong khi chạy tập lệnh bootstrap_workshop.sh, hãy chỉ định số bắt đầu của người dùng và số kết thúc của người dùng.Những số này được dùng để tạo tên người dùng như sau::

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

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

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

これらのユーザー名には、setup_terraform_admin_project.shスクリプトで作成された特定のプロジェクトのプロジェクト所有者ロールが割り当てられます。ワークショップ作成スクリプトを使用するときは、このユーザー命名スキーマに従う必要があります。詳細は GSuiteで複数のユーザーを一度に追加する方法を参照してください。

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

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

gcloud (phiên bản >= 270)
kubectl
sed (hoạt động trên Cloud Shell / Linux sed chứ không phải 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

Xác định tên tổ chức, mã tài khoản thanh toán, số hội thảo và vùng lưu trữ GCS quản trị sẽ được sử dụng cho hội thảo.上記のセクションでワークショップのセットアップに必要な権限を確認します。

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を適用します。 Cấp cho tài khoản dịch vụ Cloud Build vai trò IAM thích hợp để có thể tạo tài nguyên trên 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

Xác định tên tổ chức, mã tài khoản thanh toán, số hội thảo và vùng lưu trữ GCS quản trị sẽ được sử dụng cho hội thảo.上記のセクションでワークショップのセットアップに必要な権限を確認します。

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

ユーザー情報の取得

Quản trị viên thiết lập hội thảo cần cung cấp thông tin tên người dùng và mật khẩu cho người dùng.Mọi dự án của người dùng đều có tên người dùng (chẳng hạn như user001@yourcompany.com) được thêm làm tiền tố và mã dự án do Terraform quản lý sẽ có dạng user001-200131-01-tf-abcde.各ユーザーは、自分のワークショップ環境にのみアクセスできます。

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

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

gcloud (phiên bản >= 270)
kubectl
sed (hoạt động trên Cloud Shell / Linux sed chứ không phải 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ファイルに変数として保存されています。 Lấy tệp vars.sh của dự án được quản lý bằng Terraform.

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プロジェクト。各プロジェクトは提供された請求アカウントIDに紐付いています。
1つのプロジェクトは、共有VPCが設定されている network host projectです。このプロジェクトには、他のリソースは作成されません。
1つのプロジェクトは、IstioコントロールプレーンのGKEクラスタに使用される ops project です。
それ以外の2つのプロジェクトは、それぞれのサービスに取り組んでいる2つの異なる開発チームを表しています。
3つの ops、dev1 および dev2 プロジェクトのそれぞれで、2つのGKEクラスターが作成されます。
CSRリポジトリ k8s-repo が作成されます。このリポジトリには、Kubernetesのマニフェストファイル用の6つのフォルダが含まれています。 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クラスターでは、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

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

Bạn có thể tuỳ chọn xác minh rằng Secret đã được triển khai.

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を使用します。Để phát hiện các dịch vụ trên toàn bộ cụm, hãy sử dụng tệp kubeconfig được tạo dưới dạng Secret trong cụm ops (cho mỗi cụm ứng dụng).Pilot は、これらの Secret を使用して、アプリケーションクラスタの Kube API サーバー（上記の Secret を介して認証された）を照会することにより、サービスを検出します。Bạn có thể thấy rằng cả hai cụm ops đều có thể xác thực cho tất cả các cụm ứng dụng bằng cách sử dụng Secret được tạo bằng kubeconfig. Opsクラスターは、Secretとしてkubeconfigファイルを使用してサービスを自動的に検出できます。Điều này yêu cầu Pilot trong cụm ops có thể truy cập vào máy chủ Kube API của tất cả các cụm khác. PilotがKube APIサーバーに到達できない場合、リモートサービスを ServiceEntriesとして手動で追加します。 ServiceEntriesは、サービスレジストリのDNSエントリと考えることができます。 ServiceEntriesは、完全修飾DNS名（ FQDN）と到達可能なIPアドレスを使用してサービスを定義します。詳細については、 Istio Multiclusterのドキュメントを参照してください。

5. infrastructure リポジトリの説明

Cơ sở hạ tầng Cloud Build

ワークショップのGCPリソースは、 Cloud Buildと Infrastructure CSRリポジトリを使用して構築されます。Chạy tập lệnh tạo hội thảo (có trong scripts/bootstrap_workshop.sh) từ thiết bị cục bộ.Tập lệnh tạo hội thảo sẽ tạo các quyền IAM thích hợp cho thư mục GCP, dự án do Terraform quản lý và tài khoản dịch vụ Cloud Build.Dự án do Terraform quản lý được dùng để lưu trữ các trạng thái, nhật ký và tập lệnh khác của Terraform.そこには infrastructure とk8s_repo のCSRリポジトリが含まれています。Những kho lưu trữ này sẽ được mô tả chi tiết trong phần tiếp theo. terraform管理プロジェクトには、他のワークショップリソースは組み込まれていません。 terraform管理プロジェクトのCloud Buildサービスアカウントは、ワークショップのリソースを構築するために使用されます。

Infrastructure フォルダにある cloudbuild.yaml ファイルは、ワークショップのGCPリソースを構築するために使用します。 Tạo hình ảnh trình tạo tuỳ chỉnh bằng tất cả các công cụ cần thiết để tạo tài nguyên GCP.Các công cụ này bao gồm gcloud SDK, terraform và các tiện ích khác như python, git, jq.カスタムビルダーイメージは、terraform plan を実行し、各リソースに apply します。各リソースの terraform ファイルは個別のフォルダーにあります（詳細は次のセクションを参照）。Tài nguyên được tạo từng cái một theo cách thông thường (ví dụ: dự án GCP được tạo trước khi tài nguyên được tạo trong dự án).詳細については、 cloudbuild.yaml ファイルを確認してください。

Cloud Buildは、infrastructure リポジトリへのコミットがあるたびにトリガーされます。インフラストラクチャに対して行われた変更は、 Infrastructure as Code（IaC）として保存され、リポジトリにコミットされます。ワークショップの状態は常にこのリポジトリに保存されます。

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

リポジトリは、ワークショップのGCPインフラストラクチャリソースをセットアップします。フォルダとサブフォルダに構造化されています。Thư mục cơ sở trong kho lưu trữ đại diện cho nhóm sở hữu một tài nguyên GCP cụ thể.Thư mục tiếp theo biểu thị một môi trường cụ thể của nhóm (ví dụ: dev, stage, prod).Lớp tiếp theo của thư mục trong môi trường đại diện cho một tài nguyên cụ thể (ví dụ: host_project, gke_clusters, v.v.).必要なスクリプトと terraform ファイルは、リソースフォルダー内に存在します。

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

infrastructure – クラウドを管理するインフラストラクチャチームを表します。Bạn chịu trách nhiệm tạo tài nguyên GCP cho tất cả các nhóm khác.リソースにはTerraform管理プロジェクトを使用します。リポジトリ自体は、Terraform state ファイル（以下で説明）にあります。Những tài nguyên này được tạo bằng tập lệnh bash trong quy trình tạo hội thảo (xem Mô-đun 0 – Thiết lập cơ sở hạ tầng – Quy trình làm việc của quản trị viên để biết thêm thông tin).
network – 代表ネットワークチーム。 VPCとネットワークリソースを担当します。彼らは次のGCPリソースを所有しています。
host project – Biểu thị dự án lưu trữ của VPC dùng chung.
shared VPC – Biểu thị VPC, mạng con, dải IP phụ, thông tin định tuyến và quy tắc tường lửa dùng chung.
ops – 運用 / DevOpsチームを表します。彼らは次のリソースを所有しています。
ops project – すべてのopsリソースのためのプロジェクトを表します。
gke clusters – リージョンごとのops GKEクラスタ。またIstioコントロールプレーンは、各ops GKEクラスタにインストールされます。
k8s-repo – CSRリポジトリ。すべてのGKEクラスタのGKEマニフェストが含まれます。
apps – 代表アプリケーションチーム（Nhóm ứng dụng).このワークショップは、app1 と app2 の2つのチームをシミュレーションします。彼らは次のリソースを所有しています。
app projects – すべてのアプリチームが個別のプロジェクトセットを持ちます。これにより、プロジェクトごとに請求とIAMを制御できます。
gke clusters – これらは、アプリケーションコンテナ/ Pod が実行されるアプリケーション用クラスタです。
gce instances – オプションで、GCEインスタンスで実行されるアプリケーションがある場合に使用します。このワークショップでは、app1 に、アプリケーションの一部が実行されるいくつかのGCEインスタンスがあります。

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

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

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

Mọi tài nguyên đều có tệp backend.tf xác định vị trí của tệp tfstate của tài nguyên.Tệp backend.tf này được tạo từ mẫu (nằm trong templates/backend.tf_tmpl) bằng cách sử dụng tập lệnh (nằm trong scripts/setup_terraform_admin_project) và được đặt trong thư mục tài nguyên tương ứng. GCSバケットがファイル置き場として使われます。 GCSバケットフォルダ名はリソース名と一致します。リソースはすべて、terraform管理プロジェクトにあります。

Tài nguyên có các giá trị phụ thuộc lẫn nhau sẽ có tệp output.tf.Giá trị đầu ra cần thiết được lưu trữ trong tệp tfstate do phần phụ trợ của tài nguyên cụ thể đó xác định.たとえば、プロジェクトにGKEクラスタを作成するには、プロジェクトIDを知る必要があります。Mã dự án được xuất thông qua output.tf trong tệp tfstate mà bạn có thể sử dụng thông qua nguồn dữ liệu terraform_remote_state của tài nguyên cụm GKE.

shared_stateファイルは、リソースのtfstateファイルを指す terraform_remote_state データソースです。shared_state_[resource_name].tf ファイルは、他のリソースからの出力を必要とするリソースフォルダに存在します。たとえば、ops_gke リソースフォルダには、ops_project および shared_vpc リソースの shared_state ファイルがあります。これは、opsプロジェクトでGKEクラスタを作成するにはプロジェクトIDとVPCの詳細が必要だからです。 Tệp shared_state được tạo từ mẫu (trong templates/shared_state.tf_tmpl) bằng cách sử dụng tập lệnh (trong scripts/setup_terraform_admin_project).Tệp shared_state của tất cả các tài nguyên sẽ được đặt trong thư mục gcp/[environment]/shared_states.必要なshared_state ファイルは、それぞれのリソースフォルダーでシンボリックリンクされています。すべてのshared_stateファイルを1つのフォルダに配置し、それらを適切なリソースフォルダにsymリンクすると、すべての状態ファイルを1か所で簡単に管理できます。

変数

すべてのリソースの値は環境変数として保存されます。Những biến số này được lưu trữ (dưới dạng câu lệnh xuất) trong tệp vars.sh trong vùng chứa GCS của dự án quản trị terraform.これには、組織ID、請求先アカウント、プロジェクトID、GKEクラスタの詳細などが含まれます。任意の端末から vars.sh をダウンロードして入手し、セットアップの値を取得できます。

Terraform変数は、TF_VAR_[variable name]として vars.sh に保存されます。Các biến này được dùng để tạo tệp variables.tfvars trong thư mục tài nguyên tương ứng. 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つのフォルダーが作成されます。Mỗi thư mục (có tên trùng với tên cụm GKE) tương ứng với một cụm GKE chứa tệp kê khai tài nguyên tương ứng.インフラストラクチャの構築と同様に、Cloud Buildは、k8s_repoを使用してKubernetesマニフェストをすべてのGKEクラスタに適用するために使用されます。 Cloud Buildは、k8s_repoリポジトリへのコミットがあるたびにトリガーされます。Tương tự như cơ sở hạ tầng, tất cả các tệp kê khai Kubernetes đều được lưu trữ dưới dạng mã trong kho lưu trữ k8s_repo và trạng thái của mỗi cụm GKE luôn được lưu trữ trong thư mục tương ứng.

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

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

このワークショップのリソースは、さまざまなGCPプロジェクトに分かれています。プロジェクトは、会社の組織（またはチーム）構造と一致する必要があります。Các nhóm (trong tổ chức) phụ trách nhiều dự án / sản phẩm / tài nguyên sẽ sử dụng nhiều dự án GCP.個別のプロジェクトを作成すると、IAMアクセス許可の個別のセットを作成し、プロジェクトレベルで請求を管理できます。さらに、クォータもプロジェクトレベルで管理されます。

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

GCPリソースを構築するインフラストラクチャチームは、Terraform管理プロジェクトを使用します。Họ quản lý cơ sở hạ tầng dưới dạng mã trong kho lưu trữ CSR (gọi là infrastructure) và lưu trữ tất cả thông tin về trạng thái Terraform liên quan đến các tài nguyên được tạo trên GCP trong vùng chứa GCS.これらは、CSRリポジトリおよびTerraform state のGCSバケットへのアクセスを制御します。
共有VPCを構築するネットワークチームは、hostプロジェクトを使用します。Dự án này bao gồm VPC, mạng con, tuyến đường và quy tắc tường lửa.共有VPCを使用すると、GCPリソースのネットワークを一元管理できます。すべてのプロジェクトは、ネットワークにこの単一の共有VPCを使用しています。
GKEクラスターとASM / Istioコントロールプレーンを構築するops / platformチームは、opsプロジェクトを使用します。 GKEクラスターとサービスメッシュのライフサイクルを管理します。これらは、クラスターを強化し、Kubernetesプラットフォームの復元力とスケールを管理する責任があります。このワークショップでは、リソースをKubernetesにデプロイするGitOpsメソッドを使用します。 CSRリポジトリ（k8s_repo と呼ばれる）がopsプロジェクトに存在します。
Cuối cùng, các nhóm dev1 và dev2 (đại diện cho 2 nhóm phát triển) xây dựng ứng dụng sẽ sử dụng dự án dev1 và dev2 riêng.これらは、顧客に提供するアプリケーションとサービスです。これらは、運用チームが管理するプラットフォーム上に構築されます。リソース（deployment、service など）は k8s_repo にプッシュされ、適切なクラスターに展開されます。このワークショップは CI / CD のベストプラクティスとツールに焦点を合わせていないことに注意してください。 Cloud Build を使用して、GKEクラスターへのKubernetesリソースの展開を自動化します。実際の運用シナリオでは、適切な CI / CD ソリューションを使用して、アプリケーションをGKEクラスターに展開します。

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

Ops クラスター: ops チームがDevOpsのツールを実行するために使用します。Trong hội thảo này, bạn sẽ chạy ASM / Istio Control Plane để quản lý lưới dịch vụ.
クラスタアプリケーション – 開発チームがアプリケーションを実行するために使用します。このワークショップでは、Hipster ショップアプリに使用されます。

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

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

Ứng dụng Hipster Shop mà bạn sẽ sử dụng trong hội thảo này được triển khai trên cả 4 cụm ứng dụng.各マイクロサービスは、すべてのアプリクラスタの個別の名前空間に存在します。Hipster ショップアプリのDeployment（Pod）は、opsクラスターには展開されません。ただし、すべてのマイクロサービスのnamespaceとサービスリソースもopsクラスターに作成されます。ASM / Istioコントロールプレーンは、サービスディスカバリにKubernetesサービスレジストリを使用します。（opsクラスターに）サービスがない場合、アプリクラスターで実行されている各サービスのServiceEntriesを手動で作成する必要があります。

Trong hội thảo này, bạn sẽ triển khai một ứng dụng gồm 10 lớp vi dịch vụ.Ứng dụng này là một ứng dụng thương mại điện tử dựa trên web có tên là "Hipster Shop", cho phép người dùng duyệt xem, thêm vào giỏ hàng và mua các mặt hàng.

Kubernetes マニフェストと k8s_repo

k8s_repo を使用して、すべてのGKEクラスターにKubernetesリソースを追加します。これを行うには、Kubernetesマニフェストをコピーし、k8s_repo にコミットします。 k8s_repo へのすべてのコミットは、KubernetesマニフェストをそれぞれのクラスターにデプロイするCloud Buildジョブをトリガーします。マニフェスト cho mỗi cụm nằm trong một thư mục khác có cùng tên với tên cụm.

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

gke-asm-1-r1-prod – Cụm ops theo khu vực ở Khu vực 1
gke-asm-2-r2-prod – リージョン2にあるリージョナルopsクラスター
gke-1-apps-r1a-prod – Cụm ứng dụng trong vùng a của khu vực 1
gke-2-apps-r1b-prod – Cụm ứng dụng trong vùng b của khu vực 1
gke-3-apps-r2a-prod – Cụm ứng dụng trong vùng a của khu vực 2
gke-4-apps-r2b-prod – Cụm ứng dụng trong vùng b của khu vực 2

k8s_repo には、これらのクラスターに対応するフォルダーがあります。Các tệp kê khai được đặt trong các thư mục này sẽ được áp dụng cho các cụm GKE tương ứng.各クラスターのマニフェストは、管理を容易にするためにサブフォルダー（クラスターのメインフォルダー内）に配置されます。このワークショップでは、 Kustomizeを使用して、デプロイされるリソースを追跡します。詳細については、Kustomizeの公式ドキュメントを参照してください。

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

Mục tiêu: デプロイする Hipsterショップアプリをappsクラスターにデプロイする

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

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

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

Xoá việc triển khai cartservice, RBAC và PodSecurityPolicy khỏi mọi thứ, ngoại trừ một cụm dev. Hipsterショップはマルチクラスター展開用に構築されたものではなく、4つのdeploymentすべてを実行し続けることで、アクセスしたdeploymentに応じてカート情報に矛盾が生じてしまいます。

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

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

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

最初の dev クラスタのみで、cartservice deployment、RBAC、および PodSecurityPolicy を kustomization.yaml に追加します。

cd ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm

Xoá PodSecurityPolicies, deployment và thư mục RBAC khỏi kustomization.yaml của cụm 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

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

Sao chép tệp kê khai IngressGateway và VirtualService vào kho lưu trữ nguồn của cụm ops.

cp -r k8s_manifests/prod/app-ingress/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-ingress/
cp -r k8s_manifests/prod/app-ingress/* ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-ingress/

Config Connectorリソースを各プロジェクトのクラスタの1つにコピーします。

cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-cnrm/
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app-cnrm/
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app-cnrm/

Config ConnectorマニフェストのPROJECT_IDを置き換えます。

sed -i 's/${PROJECT_ID}/'${TF_VAR_ops_project_name}'/g' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-cnrm/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g'  ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app-cnrm/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g'  ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app-cnrm/*

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

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

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

sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/loadgenerator-rbac.yaml

sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g'  ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-loadgenerator/loadgenerator-rbac.yaml

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

cd ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd ../../${OPS_GKE_2_CLUSTER}/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

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

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

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

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

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

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

for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context ${DEV1_GKE_1} get pods -n ${ns};
  kubectl --context ${DEV1_GKE_2} get pods -n ${ns};
  kubectl --context ${DEV2_GKE_1} get pods -n ${ns};
  kubectl --context ${DEV2_GKE_2} get pods -n ${ns};
done;

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

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

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

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

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

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

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

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s

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

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

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

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

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

Cân bằng tải toàn cầu

これで、4つのアプリクラスタすべてにHipster Shopアプリが展開されました。Những cụm này nằm ở 2 khu vực và 4 vùng.クライアントは、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 を使用した cân bằng tải gốc của vùng chứa có thể được thực hiện. NEGはKubernetesサービスの特別なアノテーションを使って作成されるため、NEGコントローラーに自身を登録できます。 Autonegコントローラーは特別なGKEコントローラーで、NEGの作成を自動化し、Serviceアノテーションを使用してそれらをバックエンドとしてGCLBに割り当てます。 Istioコントロールプレーン（Istio Control Plane）（Istioイングレスゲートウェイを含む）は、Terraform Cloud Buildのイニシャルインフラストラクチャで展開されます。 GCLBおよびAutonegの設定は、TerraformインフラストラクチャのイニシャルCloud Buildの一部として行われます。

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

GCPマネージド証明書は、frontend GCLBサービスへのクライアントトラフィックを保護するために使用されます。 GCLBは、グローバルfrontendサービスにマネージド証明書を使用し、SSLはGCLBで終端されます。Trong hội thảo này, bạn sẽ sử dụng Cloud Endpoints làm miền cho chứng chỉ được quản lý.または、frontendのドメインとDNS名を使用して、GCPマネージド証明書を作成できます。

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

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

Bạn có thể nhấp vào biểu tượng khoá trên thanh URL của thẻ Chrome để xác minh rằng chứng chỉ vẫn còn hiệu lực.

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

アプリケーション展開の一部として、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による可観測性

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

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

Một trong những tính năng chính của Istio là khả năng quan sát tích hợp ("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}"

Bạn sẽ được yêu cầu tạo một không gian làm việc mới có tên theo dự án Ops, vì vậy hãy chọn [OK].新しいUIについてのプロンプトが表示されたら、ダイアログを閉じます。

Trong Trình khám phá chỉ số, hãy nhấp vào [Loại bản ghi]rồi nhập "istio".Loại tài nguyên "Kubernetes Pod" có các lựa chọn như "Server Request Count" (Số yêu cầu của máy chủ).これは、メトリックがメッシュからStackdriverに流れていることを示しています。

(Bạn cần nhóm theo destination_service_name nếu muốn hiển thị các dòng sau.）

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

メトリックがStackdriver APMシステムにあるので、それらを視覚化する方法が必要です。Trong phần này, bạn sẽ cài đặt một trang tổng quan được tạo sẵn, hiển thị 3 trong số 4"tín hiệu vàng" của chỉ số.トラフィック（1秒あたりのリクエスト数）、レイテンシ（この場合、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を使用して新しいグラフをすばやく追加します。そのため、 bạn cần lấy phiên bản mới nhất của trang tổng quan, áp dụng nội dung chỉnh sửa rồi đẩy bằng phương thức 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] これで、新しいグラフウィジェットをコードでダッシュボードに追加できます。この変更は、ピアによってレビューされ、バージョン管理システムにチェックインされます。Tiện ích mà bạn muốn thêm cho thấy độ trễ (giá trị trung bình) là 50%.

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

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

既存のservicesdashboardを更新します:

curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/${TF_VAR_ops_project_name}/dashboards/servicesdash \
 -d @patched-services-dashboard.json

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

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

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

Istio cung cấp một tập hợp nhật ký có cấu trúc cho tất cả lưu lượng truy cập mạng trong lưới, đồng thời tải các nhật ký đó lên Stackdriver Logging để cho phép phân tích trên nhiều cụm bằng một công cụ mạnh mẽ.Các nhật ký sẽ có thêm siêu dữ liệu ở cấp dịch vụ, chẳng hạn như cụm, vùng chứa, ứng dụng, connection_id.

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

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

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

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

Istioのコントロールプレーンログを表示するには、リソース > Kubernetesコンテナーを選択し、"Pilot"-で検索します。

ここでは、各サンプルアプリサービスのプロキシ設定をプッシュするIstioコントロールプレーンを見ることができます。 "CDS", "LDS" và"RDS" đại diện cho các API Envoy khác nhau ( Thông tin chi tiết).

Ngoài nhật ký Istio, bạn có thể tìm thấy tất cả nhật ký vùng chứa, cũng như nhật ký cơ sở hạ tầng hoặc nhật ký dịch vụ GCP khác trong cùng một giao diện. GKEのサンプルログクエリを次に示します。Trình xem nhật ký cũng cho phép bạn tạo chỉ số từ nhật ký (ví dụ: "đếm tất cả các lỗi khớp với chuỗi").ダッシュボードで、またはアラートの一部として使用できます。ログは、BigQueryなどの他の分析ツールにストリーミングすることもできます。

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

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

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

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

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

タイムラインビューには、最終的にエンドユーザーに応答するまでの、すべてのリクエストが時系列に表示されます。Được lập biểu đồ theo thời gian chờ hoặc thời gian từ yêu cầu ban đầu đến yêu cầu đầu tiên đến ngăn xếp Hipster.ドットが高くなるほど、ユーザーエクスペリエンスが遅くなります（そして不幸になります！）。

ドットをクリックすると、その特定のリクエストの詳細なウォーターフォールビューを見つけることができます。Tính năng này giúp bạn tìm thấy thông tin chi tiết thô (chứ không chỉ số liệu thống kê tổng hợp) của một yêu cầu cụ thể. Đây là tính năng không thể thiếu để hiểu được hoạt động tương tác giữa các dịch vụ, đặc biệt là khi bạn tìm kiếm hoạt động tương tác không tốt nhưng hiếm gặp giữa các dịch vụ.

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

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

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

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

公開クラスター内の可観測ツール。

Prometheus và Grafana là những công cụ nguồn mở có khả năng quan sát được triển khai như một phần của mặt phẳng điều khiển Istio của cụm ops.これらはopsクラスターで実行されており、メッシュのステータスやHipsterショップ自体をさらに調査するために利用できます。

Để xem các công cụ này, bạn chỉ cần chạy lệnh sau từ Cloud Shell (bỏ qua Prometheus vì không có nhiều thứ để xem):

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 là một hệ thống trang tổng quan về chỉ số tương tự như trang tổng quan tuỳ chỉnh của Stackdriver. Istioのインストールには、特定のIstioメッシュで実行されているサービスとワークロードのメトリック、およびIsito Control Plane自体のヘルスを表示するために使用できるいくつかのビルド済みダッシュボードが付属しています。

8. 相互TLS認証

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

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

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

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

opsクラスターのMeshPolicyを確認します。Lưu ý: mTLS là vĩnh viễn và cho phép cả lưu lượng được mã hoá và lưu lượng không phải mTLS.

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

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

  spec:
    peers:
    - mtls:
        mode: PERMISSIVE

Bật mTLS. Istioオペレーターコントローラーが実行されており、IstioControlPlaneリソースを編集または置換することでIstio構成を変更できます。コントローラーは変更を検出し、それに応じてIstioインストール状態を更新することで対応します。Thiết lập mTLS trong cảリソース IstioControlPlane của mặt phẳng điều khiển được chia sẻ và mặt phẳng điều khiển được sao chép.これにより、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の動作確認

もう一度 MeshPolicy trong cụm ops.注. 非暗号トラフィックは許可されず、mTLSトラフィックのみを許可します。

kubectl --context ${OPS_GKE_1} get MeshPolicy -o json | jq .items[].spec
kubectl --context ${OPS_GKE_2} get MeshPolicy -o json | jq .items[].spec

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

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}

Istioオペレーターコントローラーによって作成されたDestinationRuleを確認します。

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

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

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

また、ログからHTTPからHTTPSへの移行を確認できます。 UIのログからこの特定のフィールドを公開するには、ログエントリを1つクリックしてから、表示したいフィールドの値をクリックします。Trong trường hợp này, hãy nhấp vào "http" bên cạnh "プロトコル" (Giao thức).:

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

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

TODO(smcghee)

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

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

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

カナリアデプロイメントは、新しいサービスの段階的なロールアウト手法です。Trong quá trình triển khai theo kiểu phát hành có chọn lọc, bạn sẽ tăng lưu lượng truy cập vào phiên bản mới trong khi vẫn gửi phần còn lại đến phiên bản hiện tại.一般的なパターンは、トラフィック分割の各段階でカナリア分析を実行し、新しいバージョンの「ゴールデンシグナル」（レイテンシ、エラー率、飽和）をベースラインと比較することです。Điều này giúp ngăn chặn tình trạng ngừng dịch vụ và đảm bảo tính ổn định của dịch vụ"v2" mới ở mọi giai đoạn phân chia lưu lượng truy cập.

Trong phần này, bạn sẽ tìm hiểu cách tạo một phiên bản mới của quy trình triển khai cơ bản theo kiểu phát hành có chọn lọc trong dịch vụ frontend bằng Cloud Build và chính sách lưu lượng truy cập của Istio.

まず、**DEV1リージョン（us-west1）**でカナリアパイプラインを実行し、そのリージョン両方のクラスターでfrontend v2を展開します。次に、**DEV2リージョン（us-central）**でカナリアパイプラインを実行し、そのリージョンの両方のクラスターにv2を展開します。Việc thực thi từng quy trình theo trình tự cho từng khu vực sẽ giúp tránh được tình trạng ngừng hoạt động trên toàn cầu do cấu hình không phù hợp hoặc lỗi của chính ứng dụng v2 gây ra, thay vì thực thi song song trên tất cả các khu vực.

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

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

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

Chạy tập lệnh repo_setup.sh để sao chép tệp kê khai cơ sở vào k8s-repo.

cd $CANARY_DIR
./repo-setup.sh

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

Việc triển khai frontend-v2
frontend-v1 bản vá ("v1" nhãn và bao gồm hình ảnh vùng chứa có điểm cuối"/ version")
respy, HTTP応答の分布を書き出し、カナリアデプロイメントをリアルタイムで視覚化するのに役立つ小さなPod。
frontend Istio DestinationRule – Dựa trên nhãn triển khai "phiên bản", hãy chia dịch vụ frontend Kubernetes thành 2 tập hợp con, v1 và v2
frontend Istio VirtualService – Định tuyến 100% lưu lượng truy cập đến 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リージョンでカナリアパイプラインを実行します。 Cung cấp tập lệnh để cập nhật tỷ lệ lưu lượng truy cập frontend v2 của VirtualService (cập nhật trọng số thành 20%, 50%, 80%, 100%).それぞれの更新の間で、スクリプトはCloud Buildパイプラインが完了するのを待ちます。 Dev1リージョンのカナリアデプロイメントスクリプトを実行します。注 – このスクリプトの完了には約10分かかります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Từ Respy Pod của Dev2, hãy xem lưu lượng truy cập từ Dev2 Pod di chuyển dần từ frontend v1 sang v2.Sau khi tập lệnh hoàn tất, bạn sẽ thấy thông báo sau::

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

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

このセクションでは、リージョンのカナリアデプロイメントにIstioを使用する方法を紹介しました。Trong môi trường sản xuất, bạn có thể sử dụng các trình kích hoạt như hình ảnh vùng chứa được gắn thẻ mới được đẩy vào sổ đăng ký vùng chứa để tự động kích hoạt tập lệnh canary này dưới dạng quy trình Cloud Build thay vì tập lệnh thủ công.また、各ステップの間にカナリア分析を追加して、トラフィックを送信する前に、事前定義された安全なしきい値に対してv2のレイテンシとエラー率を分析することもできます。

10. 認可ポリシー

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

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

1か所で実行される可能性のあるモノリシックアプリケーションとは異なり、グローバルに分散したマイクロサービスアプリは、ネットワークの境界を越えて呼び出しを行います。つまり、アプリケーションへのエントリポイントが増え、悪意のある攻撃を受ける機会が増えます。また、Kubernetes Podには一時的なIPアドレスがあるため、従来のIPアドレスベースのファイアウォールルールは、ワークロード間のアクセスを保護するには不十分です。マイクロサービスアーキテクチャでは、セキュリティへの新しいアプローチが必要です。 Dựa trên các khối bảo mật Kubernetes, chẳng hạn như tài khoản dịch vụ, Istio cung cấp một bộ chính sách bảo mật linh hoạt cho các ứng dụng.

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をどのように適用しているかを調べてみましょう。Đầu tiên, hãy bật nhật ký cấp theo dõi trên một trong các proxy Envoy của currency Pod vì theo mặc định, các lệnh gọi uỷ quyền bị chặn sẽ không được ghi lại.

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 này được tài khoản dịch vụ Kubernetes xác định.この場合、ホワイトリストに登録するサービスアカウントは、frontend namespaceのfrontendサービスアカウントです。

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

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

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

更新をプッシュします。

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

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

最後に、別のルールをcurrencyservice AuthorizationPolicyに追加して、checkoutサービスがcurrency serviceにアクセスできるようにします。frontendとcheckoutの 2つのサービスからのcurrency serviceのアクセスのみを開放していることに注意してください。他のバックエンドサービスは引き続きブロックされます。
currency-allow-frontend-checkout.yamlを開き、その内容を見てみます。ルールリストは論理ORとして機能することに注意してください。currency service chỉ chấp nhận các yêu cầu từ những tải có một trong hai tài khoản dịch vụ này.

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

Đợi Cloud Build hoàn tất.
チェックアウトを実行してみてください。正常に動作するはずです。

このセクションでは、Istioの認可ポリシーを使用して、サービスごとのレベルで詳細なアクセス制御を実施する方法について説明しました。Trong môi trường sản xuất, hãy tạo một AuthorizationPolicy cho mỗi dịch vụ và sử dụng (ví dụ: chính sách cho phép tất cả) để cho phép tất cả các tải công việc trong cùng một không gian tên truy cập lẫn nhau.

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

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

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

プラットフォームをスケールするには、いくつかの方法があります。既存のクラスターにノードを追加することにより、さらに計算リソースを追加できます。リージョン内にさらにクラスターを追加できます。または、プラットフォームにさらにリージョンを追加できます。プラットフォームのどの側面を拡張するかの決定は、要件に依存します。Ví dụ: nếu bạn có một cụm trong cả 3 khu vực của một khu vực, thì có thể bạn chỉ cần thêm các nút (hoặc nhóm nút) vào cụm hiện có.ただし、1つのリージョンの3つのゾーンのうち2つにクラスターがある場合、3番目のゾーンに新しいクラスターを追加すると、スケーリングと追加のフォールトドメイン（つまり、新しいゾーン）が得られます。もう1つの理由として、リージョンに新しいクラスタを追加する必要があるのは、規制またはコンプライアンスの理由（PCI、PII情報を格納するデータベースクラスタなど）のために、単一のテナントクラスタを作成する必要がある場合です。ビジネスとサービスが拡大するにつれて、クライアントにより近くでサービスを提供するために新しいリージョンを追加することが避けられなくなります。

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

垂直 – リージョンにより多くのコンピューティングを追加します。これは、既存のクラスタにノード（またはノードプール）を追加するか、リージョン内に新しいクラスタを追加することによって行われます。これは、infrastructureリポジトリを介して行われます。最も簡単な方法は、既存のクラスターにノードを追加することです。追加の構成は必要ありません。Để thêm một cụm mới, bạn có thể cần thêm các mạng con bổ sung (và dải ô thứ cấp), thêm các quy tắc tường lửa thích hợp, thêm cụm mới vào ASM / Istio Service Mesh Control Plane của khu vực và triển khai tài nguyên ứng dụng vào cụm mới.
水平 – さらにリージョンを追加します。現在のプラットフォームは、リージョンのテンプレートを提供します。 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 は、上記の新しいリソースを追加するために使用されます。

Trong Cloud Shell, hãy chuyển đến WORKDIR rồi sao chép 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リポジトリがトリガーされ、新しいリソースでインフラストラクチャがデプロイされます。Nhấp vào đầu ra của đường liên kết tiếp theo, chuyển đến bản dựng mới nhất ở trên cùng để xem tiến trình của Cloud Build.

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

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

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

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

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

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

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

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

クラスターコンテキストを一覧表示します。 8つのクラスターが表示されるはずです。

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

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

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

Istioインストールの確認

Xác minh rằng tất cả các Pod đều đang chạy và công việc đã hoàn tất, đồng thời xác minh rằng Istio đã được cài đặt trên cụm ops mới.

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

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

Ngoài ra, hãy xác minh rằng Secret được triển khai cho mọi cụm ops trong 6 cụm ứng dụng.

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 cung cấp chính sách lưu lượng truy cập của bộ ngắt mạch giúp tách biệt các dịch vụ, ngăn dịch vụ hạ nguồn (phía máy khách) chờ dịch vụ bị lỗi và bảo vệ dịch vụ thượng nguồn (phía máy chủ) khỏi lưu lượng truy cập hạ nguồn đột ngột tăng lên.Nhìn chung, việc sử dụng cầu dao có thể giúp bạn tránh được trường hợp tất cả các dịch vụ đều không đạt được SLO do một dịch vụ phụ trợ bị treo.

Mẫu cầu dao được đặt tên theo công tắc điện có thể"ngắt mạch" khi dòng điện quá lớn để bảo vệ thiết bị khỏi tình trạng quá tải. 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がサーキットブレーカーを開くしきい値を決定する方法を構成する場所です。Ở đây, mỗi giây (khoảng thời gian), Envoy sẽ đếm số lượng lỗi nhận được từ vùng chứa máy chủ. **consecutiveErrors**しきい値を超えると、Envoyサーキットブレーカーが開き、productcatalog Podの100％が10秒間新しいクライアント要求から保護されます。 Nếu Envoy ngắt mạch (đang hoạt động), thì máy khách sẽ nhận được lỗi 503 (Không truy cập được dịch vụ).これを実際に見てみましょう。

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

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クラスターにコピーします。Đây là Pod ứng dụng khách được dùng để"kích hoạt" bộ ngắt mạch của shippingservice.

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が"オーバーフロー"エラーを返します。Theo chính sách đã xác định, chỉ cho phép một kết nối đồng thời trong khoảng thời gian 1 giây.

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

このセクションでは、サービスに単一のサーキットブレーカーポリシーを設定する方法を示しました。Cách hay nhất là thiết lập cầu dao cho các dịch vụ thượng nguồn (phụ trợ) có thể bị treo. Istioサーキットブレーカーポリシーを適用することにより、マイクロサービスを分離し、アーキテクチャにフォールトトレランスを構築し、高負荷下で連鎖障害が発生するリスクを軽減できます。

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

Mục tiêu: (本番環境にプッシュされる前に) 意図的に遅延を発生させることにより、recommendationサービスの回復力をテストする

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

サービスにサーキットブレーカーポリシーを追加することは、運用中のサービスに対する回復力を構築する1つの方法です。しかし、サーキットブレーカーは障害（潜在的にユーザー側のエラー）をもたらし、これは理想的ではありません。Trong những trường hợp này, bạn có thể áp dụng kiểm thử hỗn loạn trong môi trường dàn dựng để dự đoán chính xác hơn cách dịch vụ hạ nguồn phản hồi khi phụ trợ trả về lỗi.Kiểm thử hỗn loạn là phương pháp cố ý làm gián đoạn dịch vụ để phân tích các điểm yếu trong hệ thống và cải thiện khả năng chịu lỗi.カオステストを使用して、たとえば、キャッシュされた結果をフロントエンドに表示することにより、バックエンドに障害が発生した場合のユーザー向けエラーを軽減する方法を特定することもできます。

Việc sử dụng Istio để chèn lỗi sẽ rất hữu ích vì bạn có thể sử dụng hình ảnh phát hành hoạt động để thêm lỗi ở lớp mạng thay vì sửa đổi mã nguồn.本番環境では、本格的なカオステストツールを使用して、ネットワークレイヤーに加えてKubernetes / computeレイヤーで復元力をテストできます。

Bạn có thể sử dụng Istio cho kiểm thử hỗn loạn bằng cách áp dụng trường"fault" cho VirtualService. 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を開いてその内容を検査します。 Lưu ý rằng Istio có lựa chọn chèn lỗi vào tỷ lệ phần trăm yêu cầu.ここには、すべての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の完了を待ちます。
Truy cập vào Pod fortio được triển khai trong phần Circuit Breaker (Cầu dao) và gửi một số lưu lượng truy cập đến recommendationservice.

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

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

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

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

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

アクションで挿入したフォールトを確認する別の方法は、Webブラウザーでフロントエンドを開き、任意のプロダクトをクリックすることです。製品ページは、ページの下部に表示されるrecommend情報を取得するため、ロードにさらに5秒かかります。
Xoá dịch vụ chèn lỗi khỏi cả hai cụm Ops để dọn dẹp.

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 đi kèm với trang tổng quan Grafana, cho phép các toán tử trực quan hoá dữ liệu giám sát này và đánh giá tình trạng cũng như hiệu suất của lớp điều khiển.

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

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

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

Grafanaをブラウザから開きます。
Nhấp vào biểu tượng"Xem trước trên web" ở góc trên cùng bên phải của cửa sổ Cloud Shell
Nhấp vào Xem trước trên cổng 3000 (Lưu ý: Nếu cổng không phải là 3000, hãy nhấp vào Thay đổi cổng rồi chọn cổng 3000)
これにより、ブラウザに次のようなURLのタブが開きます " BASE_URL/?orgId=1&authuser=0&environment_id=default"
利用可能なダッシュボードを表示します
URLを次のように変更します" BASE_URL/dashboard"
Nhấp vào thư mục "istio" để xem trang tổng quan có sẵn
Nhấp vào một trong các trang tổng quan đó để xem hiệu suất của thành phần đó.次のセクションでは、各コンポーネントの重要な指標を見ていきます

Pilotの監視

Pilot là thành phần của mặt phẳng điều khiển, phân phối cấu hình mạng và chính sách cho mặt phẳng dữ liệu (Envoy Proxy).Pilot có xu hướng mở rộng quy mô theo số lượng tải và triển khai, nhưng không nhất thiết phải theo lượng lưu lượng truy cập vào các tải này.正常ではないPilotは次のようになり得ます:

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

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

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

重要な監視メトリクス

リソース使用量

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

Pilotのプッシュ情報

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

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

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

Envoy情報

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

Mixerの監視

Mixer là một thành phần tập trung đo từ xa từ proxy Envoy đến phần phụ trợ đo từ xa (thường là Prometheus, Stackdriver, v.v.).この容量では、データプレーンにはありません。 2つの異なるサービス名（istio-telemetryとistio-policy）でデプロイされた2つのKubernetes Jobs（Mixerと呼ばれる）としてデプロイされます。

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

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

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

重要な監視メトリクス

リソース使用量

Sử dụng trang hiệu suất và khả năng mở rộng của Istio làm hướng dẫn về số lượng sử dụng có thể.これよりも大幅に多くのリソースを使用している場合は、GCPサポートにお問い合わせください。

Mixer概要

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

Adapter Dispatch Duration cho biết độ trễ xảy ra khi Mixer gọi bộ chuyển đổi (được dùng để gửi thông tin đến hệ thống đo từ xa và ghi nhật ký).ここでの待ち時間が長いと、メッシュのパフォーマンスに絶対的な影響があります。繰り返しますが、p90のレイテンシは10ミリ秒未満である必要があります。

Galleyの監視

Galley là thành phần xác thực, tiếp nhận, xử lý và phân phối cấu hình của Istio.設定をKubernetes APIサーバーからPilotに伝えます。 Pilotと同様に、システム内のサービスとエンドポイントの数に応じてスケーリングする傾向があります。

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

重要な監視メトリクス

リソース検証

Đây là chỉ số quan trọng nhất, cho biết số lượng tài nguyên thuộc nhiều loại (chẳng hạn như Destinationルール、ゲートウェイ、サービスエントリ) đã vượt qua hoặc không vượt qua quy trình xác証。

接続されたクライアント

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

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

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

Nếu Bảng điều khiển thử nghiệm cho biết có vấn đề về cấu hình, bạn cần kiểm tra nhật ký thử nghiệm hoặc sử dụng istioctl để tìm vấn đề về cấu hình.

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

Trạng thái đẩy cho biết vấn đề xảy ra khi bạn cố gắng đẩy cấu hình vào proxy Envoy.Trong trường hợp này, bạn sẽ thấy một số thông báo "Trùng lặp cụm" cho biết các đích đến trùng lặp ở nguồn phát.

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

設定エラーの発見

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

16. クリーンアップ

Quản trị viên sẽ chạy tập lệnh cleanup_workshop.sh để xoá các tài nguyên do tập lệnh bootstrap_workshop.sh tạo.クリーンアップスクリプトを実行するには、次の情報が必要です。

組織名 - 例. 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}

Hội thảo về lưới dịch vụ Anthos: Hướng dẫn cho phòng thí nghiệm – Tiếng Nhật

1. HỘI THẢO ALPHA

2. 概要

アーキテクチャ図

Chương trình làm việc

Điều kiện tiên quyết

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

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

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

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

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

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

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

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

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

ユーザー情報の取得

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

インストールを確認

Istio のインストール確認

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

5. infrastructure リポジトリの説明

Cơ sở hạ tầng Cloud Build

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

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

変数

K8s リポジトリの説明

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

Kubernetes マニフェストと k8s_repo

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

Mục tiêu: デプロイする Hipsterショップアプリをappsクラスターにデプロイする

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

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

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

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

Cân bằng tải toàn cầu

GKE Autoneg コントローラー

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

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

7. Stackdriverによる可観測性

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

8. 相互TLS認証

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

mTLSの動作確認

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

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

10. 認可ポリシー

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

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

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

Istioインストールの確認

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

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

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

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

Mục tiêu: (本番環境にプッシュされる前に) 意図的に遅延を発生させることにより、recommendationサービスの回復力をテストする

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

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

Pilotの監視

重要な監視メトリクス

Mixerの監視

重要な監視メトリクス

Galleyの監視

重要な監視メトリクス

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

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

設定エラーの発見

16. クリーンアップ

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

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