Workshop Anthos Service Mesh: Panduan Lab - Bahasa Jepang

1. WORKSHOP ALPHA

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

2. 概要

アーキテクチャ図

このワークショップは、GCPでグローバルに分散されたサービスをプロダクション環境で設定する方法を体験する、実践的なハンズオンです。使用する主なテクノロジーは、コンピューティング用の Google Kubernetes Engine（GKE）と、セキュアな接続、可観測性、高度なトラフィック操作を実現する Istioサービスメッシュです。Semua praktik dan alat yang digunakan dalam workshop ini sama dengan yang digunakan dalam produksi sebenarnya.

Agenda

TODO - update dengan perincian akhir

Prasyarat

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

GCP組織リソース
ID akun penagihan (Anda harus menjadi administrator akun penagihan untuk akun ini)
Peran IAM Administrator Organisasi untuk tingkat organisasi

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

Deskripsi Skrip Pembuatan Workshop

bootstrap_workshop.shというスクリプトを使用して、ワークショップの初期環境を構築します。Anda dapat menggunakan skrip ini untuk menyiapkan satu lingkungan untuk diri Anda sendiri, atau beberapa lingkungan untuk beberapa pengguna.

Skrip pembuatan workshop memerlukan informasi berikut:

組織名 (例. yourcompany.com)- これはあなたがワークショップ環境を作成する組織の名称です。
請求先アカウントID (例. 12345-12345-12345) - ID ini akan digunakan sebagai akun penagihan untuk semua resource yang dibuat di workshop.
ワークショップ番号 (例. 01) - 2桁の数字。これは、1日に複数のワークショップを行っており、それらを個別に管理したい場合に使用されます。ワークショップ番号は、プロジェクトIDの命名にも使用されます。個別のワークショップ番号を使用すると、毎回一意のプロジェクトIDを取得しやすくなります。ワークショップ番号に加えて、現在の日付（YYMMDD形式）もプロジェクトIDに使用されます。Kombinasi tanggal dan nomor workshop akan memberikan ID project yang unik.
Nomor awal pengguna (mis. 1) - この番号は、ワークショップの最初のユーザー番号を表します。Misalnya, jika Anda membuat workshop untuk 10 pengguna, nomor awal pengguna adalah 1 dan nomor akhir pengguna adalah 10
ユーザーの終了番号 (例. 10) - この番号は、ワークショップの最後のユーザー番号を表します。Misalnya, jika Anda membuat workshop untuk 10 pengguna, nomor awal pengguna adalah 1 dan nomor akhir pengguna adalah 10.Jika Anda membangun satu lingkungan (misalnya, untuk diri sendiri), nomor awal dan akhir pengguna akan sama.これにより、単一の環境が構築されます。

管理用 GCS バケット (例. my-gcs-bucket-name) - このGCSバケットは、ワークショップ関連の情報を保存するために使用されます。Informasi tersebut digunakan oleh skrip cleanup_workshop.sh untuk menghapus semua resource yang dibuat selama skrip pembuatan workshop.Administrator yang membuat workshop harus memiliki izin baca/tulis untuk bucket ini.

スクリプト作成ワークショップは上記の値を使用し、 setup-terraform-admin-project.shスクリプトを呼び出すラッパースクリプトとして機能します。スクリプト ini membuat lingkungan workshop pengguna tunggal.

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

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

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

オーナー - 組織内のすべてのプロジェクトに対するプロジェクトオーナーの権限。
管理者 - 組織内のフォルダを作成および削除する機能。Semua pengguna akan mendapatkan satu folder yang berisi semua resource dalam project.
組織の管理者
プロジェクト作成者 - 組織内にプロジェクトを作成する権限。
プロジェクトの削除 - 組織内のプロジェクトを削除する権限。
Project IAM 管理者 - 組織内のすべてのプロジェクトに IAM のルールを作成する権限。

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

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

組織内のユーザー（自分以外）向けにこのワークショップを作成する場合は、MY_USER の特定のユーザー命名ルールに従う必要があります。 bootstrap_workshop.shスクリプトの実行中に、ユーザーの開始番号とユーザーの終了番号を指定します。Nomor ini digunakan untuk membuat nama pengguna sebagai berikut::

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

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

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

これらのユーザー名には、setup_terraform_admin_project.shスクリプトで作成された特定のプロジェクトのプロジェクト所有者ロールが割り当てられます。Saat menggunakan skrip pembuatan workshop, Anda harus mengikuti skema penamaan pengguna ini. 詳細は GSuiteで複数のユーザーを一度に追加する方法を参照してください。

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

Workshop ini diharapkan dijalankan dari Cloud Shell.Berikut adalah kumpulan alat yang diperlukan dalam workshop ini.

gcloud (ver >= 270)
kubectl
sed (Berfungsi di Cloud Shell / Linux sed, bukan Mac OS)
git (最新版を使っていることを確認してください)
sudo apt update
sudo apt install git
jq
envsubst
kustomize

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

Buka Cloud Shell, lalu lakukan langkah-langkah berikutnya di Cloud Shell.Untuk membuka Cloud Shell, klik link di bawah.

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

Tentukan nama organisasi, ID akun penagihan, nomor workshop, dan bucket GCS untuk pengelolaan yang akan digunakan dalam workshop.上記のセクションでワークショップのセットアップに必要な権限を確認します。

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を有効にします。 Terapkan rencana Terraform menggunakan Cloud Build. Cloud Buildサービスアカウントに適切なIAMロールを与えて、GCPでリソースを作成できるようにします。Terakhir, konfigurasikan backend jarak jauh di bucket Google Cloud Storage（GCS） untuk menyimpan status Terraform semua resource GCP.

Untuk melihat tugas Cloud Build di project yang dikelola Terraform, Anda memerlukan ID project yang dikelola Terraform.これは、ワークショップ作成スクリプトで指定された管理用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 .

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

Buka Cloud Shell, lalu lakukan langkah-langkah berikutnya di Cloud Shell.Untuk membuka Cloud Shell, klik link di bawah.

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

Tentukan nama organisasi, ID akun penagihan, nomor workshop, dan bucket GCS untuk pengelolaan yang akan digunakan dalam workshop.上記のセクションでワークショップのセットアップに必要な権限を確認します。

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. Penyiapan infrastruktur - Alur kerja pengguna

Waktu yang diperlukan: 1 jam

Tujuan: Memverifikasi penginstalan infrastruktur dan Istio

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

ユーザー情報の取得

ワークショップをセットアップする管理者は、ユーザー名とパスワード情報をユーザーに提供する必要があります。Semua project pengguna akan memiliki nama pengguna seperti user001@yourcompany.com sebagai awalan, dan ID project yang dikelola Terraform akan terlihat seperti user001-200131-01-tf-abcde.Setiap pengguna hanya dapat mengakses lingkungan workshopnya sendiri.

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

Workshop ini diharapkan dijalankan dari Cloud Shell.Berikut adalah kumpulan alat yang diperlukan dalam workshop ini.

gcloud (ver >= 270)
kubectl
sed (Berfungsi di Cloud Shell / Linux sed, bukan 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でリソースを作成できるようにします。Terakhir, backend jarak jauh dikonfigurasi ke bucket Google Cloud Storage (GCS) untuk menyimpan status Terraform semua resource GCP.

Buka Cloud Shell, lalu lakukan langkah-langkah berikutnya di Cloud Shell.Untuk membuka Cloud Shell, klik link di bawah.

CLOUD SHELL

kustomize を $HOME/bin にインストールし（未インストールの場合）、$HOME/bin を $PATH に加えます。

mkdir -p ${HOME}/bin
cd bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd ${HOME}
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:${HOME}/bin" >> ~/.bashrc

pv をインストールし、セッション上で設定を永続化するためにそれを .customize_environment に追加します。

sudo apt-get update && sudo apt-get -y install pv
echo -e  '#!/bin/sh' >> $HOME/.customize_environment
echo -e "apt-get update" >> $HOME/.customize_environment
echo -e "apt-get -y install pv" >> $HOME/.customize_environment

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

gcloud config list

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

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

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

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

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

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

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

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

Halaman Cloud Build akan ditampilkan, jadi klik link History di navigasi sebelah kiri, lalu klik build terbaru untuk melihat detail penerapan Terraform pertama.次のリソースは、Terraformスクリプトの一部として作成されます。上記のアーキテクチャ図も参考になります。

4 proyek GCP dalam organisasi.各プロジェクトは提供された請求アカウントIDに紐付いています。
1つのプロジェクトは、共有VPCが設定されている network host projectです。このプロジェクトには、他のリソースは作成されません。
1つのプロジェクトは、IstioコントロールプレーンのGKEクラスタに使用される ops project です。
Dua proyek lainnya mewakili dua tim pengembangan berbeda yang mengerjakan layanan masing-masing.
3つの ops、dev1 および dev2 プロジェクトのそれぞれで、2つのGKEクラスターが作成されます。
CSRリポジトリが作成されます。このリポジトリには、Kubernetesのマニフェストファイル用の6つのフォルダを含む k8s-repo という名前が付けられます。 GKEクラスタごとに1つのフォルダがあります。Repositori ini digunakan untuk men-deploy manifes Kubernetes ke cluster dalam format GitOps.
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 Ubah variabel ke file kubeconfig baru.

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

Mendapatkan konteks cluster.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 のインストール確認

Memastikan semua Pod berjalan dan tugas selesai, serta memastikan Istio diinstal di kedua cluster.

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クラスタにインストールされていることを確認してください。dev2Di cluster, hanya Citadel, sidecar-injector, dan coredns yang berjalan. 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

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

Secara opsional, verifikasi bahwa Secret telah di-deploy.

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を使用します。Untuk mendeteksi layanan di seluruh cluster, gunakan file kubeconfig yang dibuat sebagai Secret di cluster ops (untuk setiap cluster aplikasi).Pilot は、これらの Secret を使用して、アプリケーションクラスタの Kube API サーバー（上記の Secret を介して認証された）を照会することにより、サービスを検出します。両方のopsクラスタがkubeconfigで作成された Secret を使用して、すべてのアプリクラスタに対して認証できることがわかります。 Opsクラスタは、Secretとしてkubeconfigファイルを使用してサービスを自動的に検出できます。Hal ini mengharuskan Pilot di dalam cluster ops dapat mengakses server Kube API di semua cluster lainnya. PilotがKube APIサーバーに到達できない場合、リモートサービスを ServiceEntriesとして手動で追加します。 ServiceEntries dapat dianggap sebagai entri DNS untuk registry layanan. ServiceEntriesは、完全修飾DNS名（ FQDN）と到達可能なIPアドレスを使用してサービスを定義します。詳細については、 Istio Multiclusterのドキュメントを参照してください。

5. Penjelasan repositori infrastruktur

Build Cloud Infrastructure

ワークショップのGCPリソースは、 Cloud Buildと Infrastructure CSRリポジトリを使用して構築されます。ローカル端末からワークショップ作成スクリプト（scripts/bootstrap_workshop.shにあります）を実行します。Skrip pembuatan workshop membuat folder GCP, project yang dikelola Terraform, dan izin IAM yang sesuai untuk akun layanan Cloud Build.Proyek yang dikelola Terraform digunakan untuk menyimpan status Terraform, log, dan skrip lainnya.そこには infrastructure とk8s_repo のCSRリポジトリが含まれています。リポジトリについては、次のセクションで詳しく説明します。 terraform管理プロジェクトには、他のワークショップリソースは組み込まれていません。 Akun layanan Cloud Build untuk project yang dikelola Terraform digunakan untuk membangun resource workshop.

Infrastructure フォルダにある cloudbuild.yaml ファイルは、ワークショップのGCPリソースを構築するために使用します。 GCPリソースの作成に必要なすべてのツールを使用して、カスタムビルダーイメージを作成します。Alat ini mencakup gcloud SDK, terraform, dan utilitas lainnya seperti python, git, jq.イメージカスタムビルダーは、terraform plan を実行し、各リソースに apply します。Setiap file terraform resource berada di folder terpisah (lihat bagian berikutnya untuk mengetahui detailnya).Resource dibangun satu per satu, sesuai dengan cara biasanya resource dibuat (misalnya, project GCP dibangun sebelum resource dibuat di project).詳細については、 cloudbuild.yaml ファイルを確認してください。

Cloud Build akan memicu setiap kali ada commit ke repositori infrastructure.Perubahan yang dilakukan pada infrastruktur disimpan sebagai Infrastructure as Code (IaC) dan di-commit ke repositori.ワークショップの状態は常にこのリポジトリに保存されます。

Struktur folder - Tim, lingkungan, dan resource

Infrastructure リポジトリは、ワークショップのGCPインフラストラクチャリソースをセットアップします。フォルダとサブフォルダに構造化されています。リポジトリ内のベースフォルダは、特定のGCPリソースを所有するチームを表します。Lapisan berikutnya dalam folder mewakili lingkungan tertentu tim (misalnya, dev, stage, prod).Lapisan berikutnyaのフォルダーは、特定のリソース（たとえば、host_project、gke_clustersなど）を表します。必要なスクリプトと terraform ファイルは、リソースフォルダー内に存在します。

Dalam workshop ini, akan ada 4 jenis tim::

infrastructure - Menunjukkan tim infrastruktur yang mengelola cloud.他チームのすべてのGCPリソースを作成する責任があります。リソースにはTerraform管理プロジェクトを使用します。Repositori infrastruktur itu sendiri ada di file status Terraform (dijelaskan di bawah).Sumber daya ini dibuat oleh skrip bash selama proses pembuatan workshop (lihat Modul 0 - Penyiapan Infrastruktur - Alur Kerja Admin untuk mengetahui detailnya).
network - ネットワークチームを表します。 VPCとネットワークリソースを担当します。彼らは次のGCPリソースを所有しています。
host project - 共有VPCのホストプロジェクトを表します。
shared VPC - Mewakili VPC bersama, subnet, rentang IP sekunder, informasi perutean, dan aturan firewall.
ops - 運用 / DevOpsチームを表します。彼らは次のリソースを所有しています。
ops project - すべてのopsリソースのためのプロジェクトを表します。
gke clusters - ops GKEクラスタごとのリージョン。またIstioコントロールプレーンは、各ops GKEクラスタにインストールされます。
k8s-repo - CSRリポジトリ。すべてのGKEクラスタのGKEマニフェストを含む。
apps - Mewakili tim aplikasi.ワークショップでは、app1 と app2 の2つのチームをシミュレーションします。彼らは次のリソースを所有しています。
app projects - すべてのアプリチームが個別のプロジェクトセットを持ちます。これにより、プロジェクトごとに請求とIAMを制御できます。
gke clusters - Ini adalah cluster aplikasi tempat penampung/ Pod aplikasi dijalankan.
gce instances - オプションで、GCEインスタンスで実行されるアプリケーションがある場合に使用します。このワークショップでは、app1 に、アプリケーションの一部が実行されるいくつかのGCEインスタンスがあります。

Dalam workshop ini, aplikasi yang sama (aplikasi Hipster Shop) akan digunakan di app1 dan app2.

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

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

Semua resourceには、リソースの tfstate ファイルの場所を定義する backend.tf ファイルが含まれています。File backend.tf ini dibuat dari template (di templates/backend.tf_tmpl) menggunakan skrip (di scripts/setup_terraform_admin_project), dan ditempatkan di setiap folder resource. Bucket GCS digunakan sebagai tempat penyimpanan file. Nama folder bucket GCS cocok dengan nama resource.リソースはすべて、terraform管理プロジェクトにあります。

相互依存する値を持つリソースには、output.tf ファイルが含まれます。Nilai output yang diperlukan disimpan dalam file tfstate yang ditentukan di backend resource tertentu.たとえば、プロジェクトにGKEクラスタを作成するには、プロジェクトIDを知る必要があります。プロジェクトIDは、GKEクラスタリソースの terraform_remote_state データソースを介して使用できる tfstate ファイルに output.tf を介して出力されます。

shared_stateファイルは、リソースのtfstateファイルを指す terraform_remote_state データソースです。shared_state_[resource_name].tf ファイルは、他のリソースからの出力を必要とするリソースフォルダに存在します。たとえば、ops_gke リソースフォルダには、ops_project および shared_vpc リソースの shared_state ファイルがあります。Hal ini karena project ID dan detail VPC diperlukan untuk membuat cluster GKE dalam project ops. ファイル shared_state dibuat dari template (di templates/shared_state.tf_tmpl) menggunakan skrip (di scripts/setup_terraform_admin_project).Semua file shared_state resource ditempatkan di folder gcp/[environment]/shared_states.必要なshared_state ファイルは、それぞれのリソースフォルダーでシンボリックリンクされています。すべてのshared_stateファイルを1つのフォルダーに配置し、それらを適切なリソースフォルダーにsymリンクすると、すべての状態ファイルを1か所で簡単に管理できます。

変数

Semua nilai resource disimpan sebagai variabel lingkungan.これらの変数は、terraform adminプロジェクトのGCSバケットにある vars.sh というファイルに（エクスポートステートメントとして）保存されます。これには、組織ID、請求先アカウント、プロジェクトID、GKEクラスタの詳細などが含まれます。Anda dapat mendownload dan mendapatkan vars.sh dari perangkat mana pun untuk mendapatkan nilai penyiapan.

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

Deskripsi repositori K8s

k8s_repo は、terraform管理プロジェクトにあるCSRリポジトリ（infrastructureリポジトリとは別）で、GKEマニフェストをすべてのGKEクラスタに保存および適用するために使用されます。k8s_repo dibuat oleh Cloud Build infrastruktur (lihat bagian sebelumnya untuk mengetahui detailnya).最初のインフラストラクチャCloud Buildプロセス中に、合計6つのGKEクラスタが作成されます。k8s_repoには、6つのフォルダーが作成されます。Setiap folder (dengan nama yang sama dengan nama cluster GKE) sesuai dengan cluster GKE yang berisi file manifes resource masing-masing.Seperti halnya pembangunan infrastruktur, Cloud Build digunakan untuk menerapkan manifes Kubernetes ke semua cluster GKE menggunakan k8s_repo. Cloud Buildは、k8s_repoリポジトリへのコミットがあるたびにトリガーされます。インフラストラクチャと同様に、すべてのKubernetesマニフェストはコードとしてk8s_repoリポジトリに保存され、各GKEクラスターの状態は常にそれぞれのフォルダーに保存されます。

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

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

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

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

GCPリソースを構築するインフラストラクチャチームは、Terraform管理プロジェクトを使用します。Mereka mengelola infrastruktur sebagai kode di repositori CSR（disebut infrastructure）dan menyimpan semua informasi status Terraform untuk resource yang dibangun di GCP dalam bucket GCS.これらは、CSRリポジトリおよびTerraform state のGCSバケットへのアクセスを制御します。
共有VPCを構築するネットワークチームは、hostプロジェクトを使用します。プロジェクト ini mencakup VPC, subnet, rute, dan aturan firewall.共有VPCを使用すると、GCPリソースのネットワークを一元管理できます。Semua project menggunakan VPC bersama tunggal ini untuk jaringan.
GKEクラスターとASM / Istioコントロールプレーンを構築するops / platformチームは、opsプロジェクトを使用します。 Mengelola siklus proses cluster GKE dan Service Mesh.これらは、クラスターを強化し、Kubernetesプラットフォームの復元力とスケールを管理する責任があります。このワークショップでは、リソースをKubernetesにデプロイするGitOpsメソッドを使用します。 CSRリポジトリ（k8s_repo と呼ばれる）がopsプロジェクトに存在します。
最後に、アプリケーションを構築するdev1およびdev2チーム（2つの開発チームを表す）は、独自のdev1およびdev2プロジェクトを使用します。Ini adalah aplikasi dan layanan yang disediakan untuk pelanggan.これらは、運用チームが管理するプラットフォーム上に構築されます。リソース（deployment、service など）は k8s_repo にプッシュされ、適切なクラスターに展開されます。このワークショップは CI / CD のベストプラクティスとツールに焦点を合わせていないことに注意してください。 Gunakan Cloud Build untuk mengotomatiskan deployment resource Kubernetes ke cluster GKE.実際の運用シナリオでは、適切な CI / CD ソリューションを使用して、アプリケーションをGKEクラスターに展開します。

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

Ops クラスター - ops チームがDevOpsのツールを実行するために使用します。このワークショップでは、ASM / Istioコントロールプレーンを実行してサービスメッシュを管理します。
クラスターアプリケーション (apps) - 開発チームがアプリケーションを実行するために使用します。このワークショップでは、Hipster ショップアプリに使用されます。

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

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

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

Dalam workshop ini, Anda akan men-deploy aplikasi mikroservice 10 lapisan.このアプリケーションは、「 Hipster Shop」と呼ばれるWebベースのeコマースアプリで、ユーザーはアイテムを参照してカートに追加し、購入することができます。

Manifes Kubernetes dan k8s_repo

k8s_repo を使用して、すべてのGKEクラスターにKubernetesリソースを追加します。これを行うには、Kubernetesマニフェストをコピーし、k8s_repo にコミットします。 Semua commit ke k8s_repo akan memicu tugas Cloud Build yang men-deploy manifes Kubernetes ke setiap cluster.Manifes setiap cluster ada di folder lain dengan nama yang sama dengan nama cluster.

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

gke-asm-1-r1-prod - Regional ops cluster di region 1
gke-asm-2-r2-prod - Regional ops cluster di region 2
gke-1-apps-r1a-prod - クラスターアプリ di zona a di region 1
gke-2-apps-r1b-prod - クラスターアプリ di zona b Region 1
gke-3-apps-r2a-prod - リージョン2のゾーンaにあるアプリクラスター
gke-4-apps-r2b-prod - リージョン2のゾーンbにあるアプリクラスター

k8s_repo には、これらのクラスターに対応するフォルダーがあります。マニフェストがこれらのフォルダーに配置されると、対応するGKEクラスターに適用されます。Manifes setiap cluster ditempatkan di subfolder (dalam folder utama cluster) untuk mempermudah pengelolaan.このワークショップでは、 Kustomizeを使用して、デプロイされるリソースを追跡します。詳細については、Kustomizeの公式ドキュメントを参照してください。

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

Tujuan: Men-deploy aplikasi Hipster Shop ke cluster aplikasi

クローンを作成するk8s-repoリポジトリ
Menyalin manifes Hipster Shop ke semua cluster aplikasi
HipsterショップアプリのためにServicesをopsクラスターに作成
グローバルの接続性をテストするためloadgeneratorをopsクラスターにセットアップ
Hipsterショップアプリへのセキュアな接続を確認

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

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

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

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

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

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

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

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

Menyalin, melakukan commit, dan mengirimkan manifes

Salin manifes Hipster Shop ke repositori sumber semua cluster.

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コントロールプレーンでのみ使用されます。 Menghapus deployment Hipster Shop, PodSecurityPolicy, dan manifes RBAC dari cluster ops.

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

Hapus deployment cartservice, RBAC, dan PodSecurityPolicy dari semua kecuali satu cluster 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

opsクラスターのkustomization.yamlからPodSecurityPolicies、deployment、RBACディレクトリを削除します。

sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d'  -e '/- rbac\//d' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d'  -e '/- rbac\//d' ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/kustomization.yaml

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

sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g'  ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g'  ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g'  ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g'  ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*

IngressGatewayおよびVirtualServiceマニフェストをopsクラスターのソースリポジトリにコピーします。

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

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

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

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

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

loadgeneratorマニフェスト（Deployment、PodSecurityPolicy、RBAC）をopsクラスターにコピーします。 Hipsterショップアプリは、グローバルな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

Mengakses aplikasi Hipster Shop

負荷分散

Dengan demikian, aplikasi Hipster Shop telah di-deploy ke keempat cluster aplikasi.これらのクラスターは、2つのリージョンと4つのゾーンにあります。クライアントは、frontendサービスにアクセスしてHipsterショップアプリにアクセスできます。frontendサービスは、4つのアプリクラスターすべてで実行されます。 Google Cloud Load Balancer（ GCLB）を使用して、frontendサービスの4つのインスタンスすべてにクライアントトラフィックを取得します。

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

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

Pengontrol GKE Autoneg

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

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

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

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

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

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

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

アプリケーション展開の一部として、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が作成されます。 Karena merupakan cluster regional, satu NEG dibuat untuk setiap zona di region.ただし、istio-ingressgatewayPodは、リージョンごとに単一のゾーンで実行されます。ここでは、istio-ingressgatewayPodに向かうトラフィックが表示されます。

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

7. Kemampuan observasi dengan Stackdriver

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

istio-telemetryリソースをインストール
Istio Servicesのダッシュボードを作成/更新
コンテナのログを表示
Menampilkan informasi pelacakan terdistribusi di Stackdriver

Istioの主要な機能の1つは、ビルトインの可観測性（"o11y"）です。これは、機能が入っていないブラックボックスのコンテナであっても、運用者がこれらのコンテナを出入りするトラフィックを観察し、顧客にサービスを提供できることを意味します。Pengamatan ini dapat dilakukan dengan beberapa cara yang berbeda, yaitu metrik, log, dan rekaman aktivitas.

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

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

cd ${WORKDIR}/k8s-repo

cd gke-asm-1-r1-prod/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd ../../gke-asm-2-r2-prod/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

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

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

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

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

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

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

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

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s

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

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

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

Di Eksplorasi metrik, klik [Jenis catatan], lalu masukkan “istio”.「Kubernetes Pod」リソースタイプには「Server Request Count」などのオプションがあります。これは、メトリックがメッシュからStackdriverに流れていることを示しています。

（以下の行を表示する場合は、destination_service_nameでグループ化する必要があります。）

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

メトリックがStackdriver APMシステムにあるので、それらを視覚化する方法が必要です。このセクションでは、メトリクスの4つの" ゴールデンシグナル"のうち3つを表示するビルド済みのダッシュボードをインストールします。Traffic (permintaan per detik), latensi (dalam hal ini, persentil ke-99 dan ke-50), error (dalam contoh ini, saturasi dikecualikan).

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

次に、あらかじめ用意されているメトリックダッシュボードを追加しましょう。 Dashboard APIを直接使用します。Ini biasanya tidak dilakukan jika Anda membuat panggilan API secara manual.なんらかの自動化システムの一部であるか、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を使用して新しいグラフをすばやく追加します。Untuk melakukannya, Anda harus mendapatkan versi terbaru dasbor, menerapkan pengeditan, lalu mengirimkannya menggunakan metode HTTP PATCH.

Anda dapat menggunakan Monitoring API untuk mengambil dasbor yang ada.Mengambil dasbor yang baru ditambahkan.:

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] これで、新しいグラフウィジェットをコードでダッシュボードに追加できます。Perubahan ini ditinjau oleh rekan dan di-check in ke sistem kontrol versi.ウィジェットを追加すると、50% の待機時間（latencyの中央値）が表示されます。

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

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

既存のservicesdashboardを更新します:

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

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

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

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

Istioは、すべてのインメッシュネットワークトラフィックの構造化ログのセットを提供し、それらをStackdriver Loggingにアップロードして、1つの強力なツールでクロスクラスター分析を可能にします。Log akan menambahkan metadata tingkat layanan seperti cluster, container, aplikasi, dan 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}"

Untuk melihat log bidang kontrol Istio, pilih Resource > Kubernetes Containers, lalu telusuri "Pilot".

ここでは、各サンプルアプリサービスのプロキシ設定をプッシュするIstioコントロールプレーンを見ることができます。 "CDS", "LDS", dan"RDS" mewakili Envoy API yang berbeda ( informasi selengkapnya).

Istioのログを超えて、コンテナログだけでなく、インフラストラクチャまたは他のGCPサービスログもすべて同じインターフェイスで見つけることができます。 Berikutは、GKEのサンプルログクエリです。Di Log Viewer, Anda juga dapat membuat metrik dari log (misalnya, "Hitung semua error yang cocok dengan string").ダッシュボードで、またはアラートの一部として使用できます。Log juga dapat di-streaming ke alat analisis lain seperti BigQuery.

Berikut beberapa contoh filter untuk Hipster Shop:

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

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

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

分散システムを使用しているため、デバッグには新しいツールである分散トレースが必要です。Dengan alat ini, Anda dapat menemukan statistik tentang cara layanan berinteraksi (seperti deteksi peristiwa lambat yang tidak normal pada diagram di bawah) atau melihat rekaman sampel mentah untuk menyelidiki apa yang sebenarnya terjadi.

タイムラインビューには、最終的にエンドユーザーに応答するまでの、すべてのリクエストが時系列に表示されます。Waktu tunggu, atau waktu dari permintaan awal hingga permintaan pertama ke stack Hipster, diplot berdasarkan grafik.DPI yang lebih tinggi akan memperlambat pengalaman pengguna (dan membuat pengguna tidak senang).）。

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

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

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

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

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

Mengekspos alat observasi dalam cluster.

Prometheuと Grafanaは、opsクラスターのIstioコントロールプレーンの一部として展開されるオープンソースの可観測性ツールです。Ini berjalan di cluster ops dan dapat digunakan untuk menyelidiki lebih lanjut status mesh dan Hipster Shop itu sendiri.

Untuk melihat alat ini, cukup jalankan perintah berikut dari Cloud Shell (Prometheus dilewati karena tidak banyak yang bisa dilihat):

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
(Pastikan Anda membuka URL di jendela Chrome rahasia yang sama dengan Cloud Shell)

Grafanaは、Stackdriverのカスタムダッシュボードに似たメトリックダッシュボードシステムです。 Penginstalan Istio dilengkapi dengan beberapa dasbor bawaan yang dapat digunakan untuk menampilkan metrik layanan dan workload yang berjalan di mesh Istio tertentu, serta kondisi Istio Control Plane itu sendiri.

8. 相互TLS認証

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

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

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

Misalnya, di dasbor Kiali, Anda dapat melihat bahwa layanan tidak menggunakan mTLS (tidak ada ikon "kunci").しかし、トラフィックは流れており、システムは正常に動作しています。 Dasbor metrik emas StackDriver memberikan kepastian bahwa sistem berfungsi secara keseluruhan.

opsクラスターのMeshPolicyを確認します。注. mTLSは永続的であり、暗号化されたトラフィックと非mTLSトラフィックの両方を許可します。

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

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

  spec:
    peers:
    - mtls:
        mode: PERMISSIVE

mTLSをオンにします。 Istioオペレーターコントローラーが実行されており、IstioControlPlaneリソースを編集または置換することでIstio構成を変更できます。コントローラーは変更を検出し、それに応じてIstioインストール状態を更新することで対応します。Aktifkan mTLS di kedua resource IstioControlPlane, yaitu bidang kontrol bersama dan bidang kontrol yang direplikasi.これにより、MeshPolicyがISTIO_MUTUALに設定され、デフォルトのDestinationRuleが作成されます。

cd ${WORKDIR}/asm
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${OPS_GKE_1_CLUSTER}/istio-controlplane/istio-replicated-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${OPS_GKE_2_CLUSTER}/istio-controlplane/istio-replicated-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV1_GKE_1_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV1_GKE_2_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV2_GKE_1_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml
sed -i '/global:/a\ \ \ \ \ \ mtls:\n\ \ \ \ \ \ \ \ enabled: true' ../k8s-repo/${DEV2_GKE_2_CLUSTER}/istio-controlplane/istio-shared-controlplane.yaml

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

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

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

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

mTLSの動作確認

opsクラスターでMeshPolicyをもう一度確認します。注. 非暗号化トラフィックは許可されず、mTLSトラフィックのみを許可します。

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

Hasil (jangan disalin):

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

Hasil (jangan disalin):

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

Selain itu, Anda dapat mengonfirmasi transisi dari HTTP ke HTTPS dari log. UIのログからこの特定のフィールドを公開するには、ログエントリを1つクリックしてから、表示したいフィールドの値をクリックします。この場合、「プロトコル」の横にある「http」をクリックします。:

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

Selain itu, Anda dapat mengonversi entri log menjadi metrik dan menampilkan grafik deret waktu.:

TODO(smcghee)

9. Deployment Canary

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

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

カナリアデプロイメントは、新しいサービスの段階的なロールアウト手法です。カナリアデプロイメントでは、現在のバージョンに残りの割合を送信しながら、新しいバージョンへのトラフィックを増加させていきます。Pola umumは、トラフィック分割の各段階でカナリア分析を実行し、新しいバージョンの「ゴールデンシグナル」（レイテンシ、エラー率、飽和）をベースラインと比較することです。Hal ini akan mencegah penghentian layanan dan memastikan stabilitas layanan"v2" baru di setiap tahap pemisahan traffic.

Di bagian ini, Anda akan mempelajari cara membuat deployment canary dasar untuk versi baru layanan frontend menggunakan kebijakan traffic Cloud Build dan Istio.

まず、**DEV1リージョン（us-west1）**でカナリアパイプラインを実行し、そのリージョンの両方のクラスターでfrontend v2を展開します。次に、**DEV2リージョン（us-central）**でカナリアパイプラインを実行し、そのリージョンの両方のクラスターにv2を展開します。リージョンごとにパイプラインを順番に実行することは、すべてのリージョンで並列に実行するのではなく、不適切な構成またはv2アプリ自体のバグによって引き起こされるグローバルな停止を回避するのに役立ちます。

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

Dari Cloud Shell, pindah ke direktori Canary.:

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

Jalankan skrip repo_setup.sh untuk menyalin manifes dasar ke k8s-repo.

cd $CANARY_DIR
./repo-setup.sh

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

Deployment frontend-v2
Patch frontend-v1 (termasuk image container dengan label "v1" dan endpoint"/ version")
respy, Pod kecil yang membantu memvisualisasikan distribusi respons HTTP dan men-deploy canary secara real time.
frontend Istio DestinationRule - Membagi layanan frontend Kubernetes menjadi dua subset, v1 dan v2, berdasarkan label deployment "version"
frontend Istio VirtualService - Merutekan 100% traffic ke frontend v1.Dengan demikian, perilaku round robin default layanan Kubernetes akan digantikan, dan 50% dari semua traffic Dev1 Region akan segera dikirim ke 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を取得します。Berikut yang akan ditampilkan.:

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

Jalankan perintah watch untuk melihat distribusi respons HTTP layanan frontend.すべてのトラフィックは、新しいVirtualServiceで定義されたfrontend v1 deploymentに向かうことがわかります。

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

Hasil (jangan disalin)

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

前のCloud Shellセッションに戻り、Dev2リージョンでカナリアパイプラインを実行します。 Menyediakan skrip untuk memperbarui proporsi traffic frontend v2 VirtualService（memperbarui bobot menjadi 20%, 50%, 80%, 100%）。それぞれの更新の間で、スクリプトはCloud Buildパイプラインが完了するのを待ちます。 Dev1リージョンのカナリアデプロイメントスクリプトを実行します。Catatan-Skrip ini akan memerlukan waktu sekitar 10 menit untuk diselesaikan.

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

Saat skrip ini berjalan, Anda dapat beralih ke sesi Cloud Shell kedua yang menjalankan perintah respy untuk melihat pembagian traffic secara real time.Misalnya, 20% akan terlihat seperti ini:

Hasil (jangan disalin)

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

Kemudian, semua traffic frontend dari Dev1 Pod harus diarahkan ke 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

Hasil (jangan disalin)

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

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

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

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

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

Hasil (jangan disalin)

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

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

10. 認可ポリシー

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

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

1か所で実行される可能性のあるモノリシックアプリケーションとは異なり、グローバルに分散したマイクロサービスアプリは、ネットワークの境界を越えて呼び出しを行います。Artinya, titik entri ke aplikasi bertambah, sehingga peluang untuk menerima serangan berbahaya juga meningkat.また、Kubernetes Podには一時的なIPアドレスがあるため、従来のIPアドレスベースのファイアウォールルールは、ワークロード間のアクセスを保護するには不十分です。マイクロサービスアーキテクチャでは、セキュリティへの新しいアプローチが必要です。サービスアカウントなどのKubernetesセキュリティビルディングブロックに基づいて、Istioはアプリケーションに柔軟なセキュリティポリシーのセットを提供します。

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

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

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

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

cd $AUTHZ_DIR

currency-deny-all.yamlの内容を見てみます。Kebijakan ini membatasi akses ke currencyservice menggunakan pemilih label Deployment.specフィールドがないことに注意してください-これは、このポリシーが選択したサービスへのすべてのアクセスを拒否することを意味します。

cat currency-deny-all.yaml

Hasil (jangan disalin)

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

Perubahan akan di-push.

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

Coba akses frontend aplikasi Hipster Shop di browser:

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

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

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

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

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

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

Hasil (jangan disalin)

[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

Selanjutnya, pastikan frontend dapat mengakses currencyservice (tetapi tidak dari layanan backend lainnya). currency-allow-frontend.yamlを開き、その内容を調べます。次のルールを追加したことに確認してください。:

cat currency-allow-frontend.yaml

Hasil (jangan disalin)

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

ここでは、特定の source.principal（クライアント）をホワイトリストに登録して、currencyサービスにアクセスしています。source.principal ini ditentukan oleh akun layanan Kubernetes.Dalam hal ini, akun layanan yang akan didaftarkan ke daftar yang diizinkan adalah akun layanan frontend untuk 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

Memperbarui.

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

Tunggu hingga Cloud Build selesai.
Hipsterショップアプリのfrontendを再度開きます。今回は、ホームページにエラーが表示されないはずです。これは、frontendが現在のサービスにアクセスすることを明示的に許可しているためです。
Selanjutnya, tambahkan item ke keranjang, lalu klik "place order" untuk melakukan checkout.今回は、currencyサービスから価格変換エラーが表示されるはずです。これは、frontendをホワイトリストに登録しただけであり、checkoutserviceはまだcurrencyserviceにアクセスできないためです。

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

cat currency-allow-frontend-checkout.yaml

Hasil (jangan disalin)

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

Salin kebijakan otorisasi akhir ke 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

Memperbarui.

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

Tunggu hingga Cloud Build selesai.
チェックアウトを実行してみてください。正常に動作するはずです。

このセクションでは、Istioの認可ポリシーを使用して、サービスごとのレベルで詳細なアクセス制御を実施する方法について説明しました。Di lingkungan produksi, buat satu AuthorizationPolicy per layanan dan gunakan (misalnya) kebijakan izinkan semua untuk memungkinkan semua beban kerja dalam namespace yang sama saling mengakses.

11. Penskalaan infrastruktur

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

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

プラットフォームをスケールするには、いくつかの方法があります。既存のクラスターにノードを追加することにより、さらに計算リソースを追加できます。リージョン内にさらにクラスターを追加できます。または、プラットフォームにさらにリージョンを追加できます。Keputusan tentang aspek platform mana yang akan diperluas bergantung pada persyaratan Anda.Misalnya, jika ada cluster di ketiga zona dalam region, mungkin cukup menambahkan node (atau kumpulan node) ke cluster yang ada.Namun, jika ada cluster di 2 dari 3 zona di suatu region, menambahkan cluster baru ke zona ketiga akan memberikan penskalaan dan domain kegagalan tambahan (yaitu, zona baru).Alasan lain untuk menambahkan cluster baru ke region adalah karena alasan peraturan atau kepatuhan (seperti cluster database yang menyimpan informasi PCI, PII), Anda mungkin perlu membuat cluster tenant tunggal.ビジネスとサービスが拡大するにつれて、クライアントにより近くでサービスを提供するために新しいリージョンを追加することが避けられなくなります。

Platform saat ini terdiri dari dua region dan cluster dua zona per region.Penskalaan platform dapat dipertimbangkan dengan dua cara berikut::

垂直 - リージョンにより多くのコンピューティングを追加します。Hal ini dilakukan dengan menambahkan node (atau kumpulan node) ke cluster yang ada atau menambahkan cluster baru dalam region.これは、infrastructureリポジトリを介して行われます。Cara termudah adalah menambahkan node ke cluster yang ada.追加の構成は必要ありません。新しいクラスターを追加するには、追加のサブネット（およびセカンダリーレンジ）、適切なファイアウォールルールの追加、新しいクラスターのリージョンASM / Istioサービスメッシュコントロールプレーンへの追加、アプリケーションリソースの新しいクラスターへのデプロイが必要になる場合があります。
水平 - さらにリージョンを追加します。現在のプラットフォームは、リージョンのテンプレートを提供します。 ASM / Istioコントロールが常駐するリージョナルopsクラスターと、アプリケーションリソースがデプロイされる2つ（またはそれ以上）のゾーンアプリケーションクラスターで構成されます。

このワークショップでは、垂直ユースケースのステップも含まれるため、プラットフォームを"水平"にスケーリングします。Untuk menskalakan platform dengan menambahkan region baru (r3) secara horizontal ke platform, Anda harus menambahkan resource berikut::

新しいオペレーションとアプリケーションクラスター用にリージョンr3の共有VPCにホストプロジェクトのサブネット
ASM / Istioコントロールプレーンが存在するリージョンr3のリージョナルopsクラスター
リージョンr3の2つのゾーンにある2つのゾーンアプリケーションクラスター
k8s-repoへの更新:
ASM / Istioコントロールプレーンリソースをリージョンr3のopsクラスターにデプロイ
ASM / Istio共有コントロールプレーンリソースをリージョンr3のアプリクラスターにデプロイ
Anda tidak perlu membuat project baru, tetapi langkah-langkah workshop menunjukkan cara menambahkan project dev3 baru yang mencakup kasus penggunaan untuk menambahkan tim baru ke platform.

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

Di Cloud Shell, pindah ke WORKDIR, lalu buat clone repositori 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スクリプトを実行します。スクリプト ini membuat backend resource baru, memperbarui variabel Terraform, dan melakukan perubahan ke repositori infrastructure.

./asm/scripts/add-project.sh

コミットにより、infrastructureリポジトリがトリガーされ、新しいリソースでインフラストラクチャがデプロイされます。Klik output link berikut, lalu buka build terbaru di bagian atas untuk melihat progres 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}"

Jalankan skrip berikut untuk menambahkan cluster baru ke file vars dan 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

Mencantumkan konteks cluster. 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

Memastikan penginstalan Istio

Semua Pod berjalan dan tugas selesai, serta Istio diinstal pada cluster ops baru.

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

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

Secara opsional, verifikasi bahwa Secret telah di-deploy ke semua cluster ops dari 6 cluster aplikasi.

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がサービスの回復力を向上させ、最初に行う必要のあるトラブルシューティングの量を削減する方法を見てみましょう。

Arsitektur mikroservis menimbulkan risiko kegagalan beruntun, yang dapat menyebabkan kegagalan satu layanan menyebar ke dependensinya dan dependensi dependensinya, sehingga memengaruhi pengguna akhir. Istioは、サービスを分離するのに役立つサーキットブレーカートラフィックポリシーを提供し、ダウンストリーム（クライアント側）サービスが障害のあるサービスを待機するのを防ぎ、アップストリーム（サーバー側）サービスがダウンストリームトラフィックの突然の大量アクセスから保護されます。Secara keseluruhan, pemutus sirkuit dapat mencegah semua layanan gagal mencapai SLO karena satu layanan backend mengalami hang.

Pola pemutus arus dinamai berdasarkan sakelar listrik yang dapat"memutus arus" saat listrik mengalir terlalu banyak untuk melindungi perangkat dari kelebihan beban. Istioのセットアップでは、これはEnvoyがサーキットブレーカーであり、サービスに対する保留中のリクエストの数を追跡することを意味します。このデフォルトの"閉じた"状態では、リクエストはEnvoyが中断せずにプロキシします。

Namun, jika jumlah permintaan yang tertunda melebihi nilai minimum yang telah ditentukan, pemutus sirkuit akan diaktifkan (terbuka) dan Envoy akan segera menampilkan error.Hal ini menyebabkan server segera gagal merespons klien dan mencegah kode aplikasi server menerima permintaan klien saat terjadi kelebihan beban.

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

図 ini merangkum pola pemutus rangkaian Istio.Persegi panjang biru mewakili Envoy, lingkaran biru mewakili klien, dan lingkaran putih mewakili penampung server.

Anda dapat定義サーキットブレーカーポリシーを使用する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

Di sini ada 2 kolom DestinationRule yang perlu diperhatikan. **connectionPool**は、このサービスが許可する接続の数を定義します。 Bidang outlierDetectionは、Envoyがサーキットブレーカーを開くしきい値を決定する方法を構成する場所です。Di sini, setiap detik (interval), Envoy menghitung jumlah error yang diterima dari penampung server. **consecutiveErrors**Jika nilai batas terlampaui, pemutus sirkuit Envoy akan terbuka dan 100% Pod productcatalog akan dilindungi dari permintaan klien baru selama 10 detik. Envoyサーキットブレーカーが開いている（アクティブになっている）場合、クライアントは503（Service Unavailable）エラーを受け取ります。Mari kita lihat contohnya.

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

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クラスターにコピーします。Ini adalah Pod klien yang digunakan untuk"mengaktifkan" pemutus sirkuit 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

Tunggu hingga Cloud Build selesai.
Kembali ke Cloud Shell, lalu gunakan Pod fortio untuk mengirim traffic gRPC ke shippingService dengan satu koneksi serentak.（合計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

Hasil (jangan disalin)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps

ここでfortioを再度実行し、同時接続数を2に増やしますが、リクエストの総数は一定に保ちます。サーキットブレーカーが作動したため、リクエストの最大3分の2が"オーバーフロー"エラーを返します。定義したポリシーでは、1秒間隔で許可される同時接続は1つのみです。

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051

Hasil (jangan disalin)

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

Hasil (jangan disalin)

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

Hapus kebijakan pemutus sirkuit dari kedua region untuk melakukan pembersihan.

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

このセクションでは、サービスに単一のサーキットブレーカーポリシーを設定する方法を示しました。Praktik terbaiknya adalah menyetel pemutus sirkuit pada layanan upstream (backend) yang berpotensi mengalami hang. Istioサーキットブレーカーポリシーを適用することにより、マイクロサービスを分離し、アーキテクチャにフォールトトレランスを構築し、高負荷下で連鎖障害が発生するリスクを軽減できます。

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

Tujuan: （Sebelum di-push ke lingkungan produksi）Menguji ketahanan layanan rekomendasi dengan sengaja menyebabkan penundaan

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

サービスにサーキットブレーカーポリシーを追加することは、運用中のサービスに対する回復力を構築する1つの方法です。Namun, pemutus sirkuit menyebabkan kegagalan (yang berpotensi merupakan kesalahan pengguna), yang tidak ideal.Untuk mengatasi error ini, Anda dapat menerapkan pengujian kekacauan di lingkungan penyiapan untuk memprediksi secara lebih akurat cara layanan hilir merespons saat backend menampilkan error.カオステストは、システム内の弱点を分析し、フォールトトレランスを向上させるために、意図的にサービスを中断する方法です。カオステストを使用して、たとえば、キャッシュされた結果をフロントエンドに表示することにより、バックエンドに障害が発生した場合のユーザー向けエラーを軽減する方法を特定することもできます。

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

Anda dapat menggunakan Istio untuk pengujian kekacauan dengan menerapkan kolom"fault" ke 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を開いてその内容を検査します。 Perhatikan bahwa Istio memiliki opsi untuk menyisipkan kesalahan pada persentase permintaan.Di sini, kita akan menyisipkan waktu tunggu untuk semua permintaan recommendationservice.

Hasil (jangan disalin)

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

Perubahan akan di-push.

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

Tunggu hingga Cloud Build selesai.
Masuk ke Pod fortio yang di-deploy di bagian circuit breaker dan kirim beberapa traffic ke 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秒かかっていることが表示されます。

Hasil (jangan disalin)

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ブラウザーでフロントエンドを開き、任意のプロダクトをクリックすることです。Halaman produk memerlukan waktu 5 detik lagi untuk dimuat guna mendapatkan informasi rekomendasi yang ditampilkan di bagian bawah halaman.
両方のOpsクラスターからフォールトインジェクションサービスを削除してクリーンアップします。

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

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

Perubahan akan di-push.

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

14. Memantau bidang kontrol Istio

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

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

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

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

Grafanaをブラウザから開きます。
Klik ikon"Webプレビュー" di sudut kanan atas jendela Cloud Shell
Klik プレビュー di port 3000 (Catatan: Jika portnya bukan 3000, klik Ubah port, lalu pilih port 3000)
これにより、ブラウザに次のようなURLのタブが開きます " BASE_URL/?orgId=1&authuser=0&environment_id=default"
利用可能なダッシュボードを表示します
URLを次のように変更します" BASE_URL/dashboard"
"istio"フォルダーをクリックし、利用可能なダッシュボードを表示します
Klik salah satu dasbor tersebut untuk melihat performa komponen.Di bagian berikutnya, kita akan melihat metrik penting untuk setiap komponen

監視パイロット

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

Menggunakan lebih banyak resource daripada yang diperlukan (CPU dan/atau RAM)
更新された構成情報をEnvoyにプッシュする際に遅延が生じます

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

Buka" BASE_URL/dashboard/db/istio-pilot-dashboard" dari browser untuk melihat metrik Pilot.

Metrik pemantauan penting

リソース使用量

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

Pilotのプッシュ情報

Di bagian ini, Anda akan memantau push konfigurasi Pilot ke proxy Envoy.

Pilot Pushes menunjukkan jenis konfigurasi yang di-push.
ADS Monitoring menunjukkan jumlah Virtual Service, layanan, dan endpoint yang terhubung dalam sistem.
既知のエンドポイントを持たないクラスターは、設定されているが実行中のインスタンスを持たないエンドポイントを表示します（* .googleapis.comなどの外部サービスを示す場合があります）。
エラー数（Pilot Errors）は、時間の経過とともに発生したエラーの数を示します。
Conflicts は、リスナーの構成があいまいな競合の数を示します。

Jika ada Error atau Konflik, berarti konfigurasi satu atau beberapa layanan tidak benar atau tidak konsisten.詳細については、データプレーンのトラブルシューティングを参照してください。

Envoy情報

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

Pemantauan Mixer

Mixer adalah komponen yang memusatkan telemetri dari proxy Envoy ke backend telemetri (biasanya Prometheus, Stackdriver, dll.).この容量では、データプレーンにはありません。 2つの異なるサービス名（istio-telemetryとistio-policy）でデプロイされた2つのKubernetes Jobs（Mixerと呼ばれる）としてデプロイされます。

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

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

Buka" BASE_URL/dashboard/db/istio-mixer-dashboard" dari browser untuk melihat metrik Mixer.

Metrik pemantauan penting

リソース使用量

Gunakan halaman Performa dan skalabilitas Istio sebagai panduan untuk penggunaan yang tersedia.これよりも大幅に多くのリソースを使用している場合は、GCPサポートにお問い合わせください。

Ringkasan Mixer

**応答時間（Response Duration）**は重要な指標です。 Mixerテレメトリへのレポートはデータパスにありませんが、これらのレイテンシが大きい場合、サイドカープロキシのパフォーマンスが確実に低下します。 Persentil ke-90 harus dalam satuan milidetik, dan persentil ke-99 harus kurang dari 100 milidetik.

Adapter Dispatch Duration menunjukkan latensi yang terjadi saat Mixer memanggil adaptor (digunakan untuk mengirim informasi ke sistem telemetri dan logging).ここでの待ち時間が長いと、メッシュのパフォーマンスに絶対的な影響があります。Sekali lagi, latensi p90 harus kurang dari 10 milidetik.

Pemantauan Galley

Galley adalah komponen yang memvalidasi, mengambil, memproses, dan mendistribusikan konfigurasi Istio.設定をKubernetes APIサーバーからPilotに伝えます。 Pilotと同様に、システム内のサービスとエンドポイントの数に応じてスケーリングする傾向があります。

Buka" BASE_URL/dashboard/db/istio-galley-dashboard" dari browser untuk melihat metrik Galley.

Metrik pemantauan penting

リソース検証

Metrik paling penting yang menunjukkan jumlah berbagai jenis resource, seperti aturan宛先、ゲートウェイ、エントリサービス、yang lulus atau gagal validasi.

接続されたクライアント

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

15. Pemecahan masalah Istio

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

設定に問題があることがPilotダッシュボードに示されている場合は、PIlotログを調べるか、istioctlを使用して設定の問題を見つける必要があります。

Pilotログを調べるには、kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discoveryのようなコマンドを実行ます。実際にはistio-pilot -...をトラブルシューティングするPilotインスタンスのPod識別子に置き換えます。

結果のログで、プッシュステータスメッセージを検索します。例えば:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

Status push menunjukkan masalah yang terjadi saat mencoba mengirim konfigurasi ke proxy Envoy.この場合、重複したアップストリーム宛先を示すいくつかの「クラスターの重複」メッセージが表示されています。

Untuk mendapatkan dukungan terkait diagnosis masalah, hubungi dukungan Google Cloud.

設定エラーの発見

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

16. Pembersihan

管理者はcleanup_workshop.shスクリプトを実行して、bootstrap_workshop.shスクリプトによって作成されたリソースを削除します。スクリプトを実行するには、次の情報が必要です。

組織名 - 例. yourcompany.com
ワークショップID - YYMMDD-NN**形式。**Contoh. 200131-01
バケット GCS 管理 - ワークショップ作成スクリプトで定義

Buka Cloud Shell, lalu lakukan semua tindakan berikut di dalamnya:下のリンクをクリックしてください。

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}

Workshop Anthos Service Mesh: Panduan Lab - Bahasa Jepang

1. WORKSHOP ALPHA

2. 概要

アーキテクチャ図

Agenda

Prasyarat

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

Deskripsi Skrip Pembuatan Workshop

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

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

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

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

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

4. Penyiapan infrastruktur - Alur kerja pengguna

Tujuan: Memverifikasi penginstalan infrastruktur dan Istio

ユーザー情報の取得

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

確認のインストール

Istio のインストール確認

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

5. Penjelasan repositori infrastruktur

Build Cloud Infrastructure

Struktur folder - Tim, lingkungan, dan resource

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

変数

Deskripsi repositori K8s

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

Manifes Kubernetes dan k8s_repo

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

Tujuan: Men-deploy aplikasi Hipster Shop ke cluster aplikasi

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

Menyalin, melakukan commit, dan mengirimkan manifes

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

Mengakses aplikasi Hipster Shop

負荷分散

Pengontrol GKE Autoneg

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

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

7. Kemampuan observasi dengan Stackdriver

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

8. 相互TLS認証

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

mTLSの動作確認

9. Deployment Canary

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

10. 認可ポリシー

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

11. Penskalaan infrastruktur

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

Memastikan penginstalan Istio

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

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

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

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

Tujuan: （Sebelum di-push ke lingkungan produksi）Menguji ketahanan layanan rekomendasi dengan sengaja menyebabkan penundaan

14. Memantau bidang kontrol Istio

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

監視パイロット

Metrik pemantauan penting

Pemantauan Mixer

Metrik pemantauan penting

Pemantauan Galley

Metrik pemantauan penting

15. Pemecahan masalah Istio

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

設定エラーの発見

16. Pembersihan

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