Workshop su Anthos Service Mesh: guida del lab - Giapponese

1. ALPHA WORKSHOP

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

リンク: bit.ly/asm-workshop-jp

2. 概要

アーキテクチャ図

Questo workshop è un'esperienza pratica per configurare servizi distribuiti a livello globale in GCP in un ambiente di produzione.Le tecnologie principali utilizzate sono Google Kubernetes Engine (GKE) per il computing e Istio Service Mesh per connessioni sicure, osservabilità e manipolazione avanzata del traffico.Tutte le pratiche e gli strumenti utilizzati in questo workshop sono gli stessi che vengono utilizzati in produzione.

Programma

TODO - update with final breakdown

前提条件

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

1. GCP組織リソース
2. ID account di fatturazione (devi essere l'amministratore dell'account di fatturazione di questo account)
3. Ruolo IAM Amministratore organizzazione a livello di organizzazione

3. Configurazione dell'infrastruttura - Flusso di lavoro per gli amministratori

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

Se hai partecipato a un workshop, vai alla sezione successiva: インフラストラクチャ セットアップ - ユーザーワークフロー

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

bootstrap_workshop.shというスクリプトを使用して、ワークショップの初期環境を構築します。Puoi utilizzare questo script per configurare un singolo ambiente per te o più ambienti per più utenti.

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

• 組織名 (例. yourcompany.com: questo è il nome dell'organizzazione che crea l'ambiente del workshop.
• 請求先アカウントID (例. 12345-12345-12345) - Questo ID verrà utilizzato come account di fatturazione per tutte le risorse create nel workshop.
• ワークショップ番号 (例. 01) - 2桁の数字。これは、1日に複数のワークショップを行っており、それらを個別に管理したい場合に使用されます。Il numero del workshop viene utilizzato anche per la denominazione dell'ID progetto.L'utilizzo di numeri di workshop separati semplifica l'ottenimento di ID progetto univoci ogni volta.Oltre al numero del workshop, viene utilizzata anche la data corrente (in formato AAMMGG) per l'ID progetto.La combinazione di data e numero del workshop fornisce un ID progetto univoco.
• ユーザーの開始番号 (例. 1) - Questo numero rappresenta il numero del primo utente del workshop.Ad esempio, se crei un workshop per 10 utenti, il numero iniziale degli utenti è 1 e il numero finale è 10.
• ユーザーの終了番号 (例. 10) - Questo numero rappresenta l'ultimo numero utente del workshop.Ad esempio, se crei un workshop per 10 utenti, il numero iniziale dell'utente è 1 e il numero finale dell'utente è 10.Se stai creando un singolo ambiente (ad esempio, per uso personale), il numero iniziale e finale dell'utente sono uguali.In questo modo, viene creato un unico ambiente.

Oltre alla data e al numero del workshop, anche il numero utente iniziale e finale viene incorporato nell'ID progetto.L'ID utente (per l'utente che esegue il workshop) viene recuperato dal numero iniziale e finale dell'utente.L'ID utente è descritto nella sezione Schema e autorizzazioni utente per l'esecuzione del workshop.

• 管理用 GCS バケット (例. my-gcs-bucket-name) - Questo bucket GCS viene utilizzato per archiviare le informazioni relative al workshop.Queste informazioni vengono utilizzate dallo script cleanup_workshop.sh per rimuovere correttamente tutte le risorse create durante lo script di creazione del workshop.L'amministratore che crea il workshop deve disporre delle autorizzazioni di lettura/scrittura per questo bucket.

Lo script di creazione del workshop utilizza i valori precedenti e funge da wrapper per richiamare lo script setup-terraform-admin-project.sh. このスクリプトは、単一ユーザーのワークショップ環境を作成します。

権限

このワークショップには2種類のユーザーがいます。Il primo è per creare ed eliminare le risorse di questo workshop ADMIN_USER, il secondo è per eseguire i passaggi del workshop MY_USER. MY_USER può accedere solo alle proprie risorse. ADMIN_USER può accedere a tutte le impostazioni utente.Se crei questa configurazione autonomamente, ADMIN_USER e MY_USER saranno uguali.Se sei un istruttore che crea questo workshop per più studenti, ADMIN_USER e MY_USER sono diversi.

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

• Proprietario: i privilegi di proprietario del progetto per tutti i progetti dell'organizzazione.
• Amministratore cartelle: la possibilità di creare ed eliminare cartelle all'interno dell'organizzazione.Tutti gli utenti ricevono una singola cartella contenente tutte le risorse del progetto.
• 管理者 dell'organizzazione
• 作成者:権限を持つユーザーは、組織内にプロジェクトを作成できます。
• プロジェクトの削除 - 組織内のプロジェクトを削除する権限。
• Project IAM Admin: autorizzazione a creare regole IAM per tutti i progetti dell'organizzazione.

Oltre a questi, ADMIN_USER deve essere anche l'amministratore della fatturazione dell'ID account di fatturazione utilizzato per il workshop.

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

Se crei questo workshop per utenti della tua organizzazione (diversi da te), devi rispettare le regole di denominazione specifiche di MY_USER. Durante l'esecuzione dello script bootstrap_workshop.sh, specifica il numero iniziale e finale degli utenti.Questi numeri vengono utilizzati per creare un nome utente nel seguente modo::

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

Ad esempio, se esegui lo script di creazione del workshop per l'organizzazione yourcompany.com con il numero iniziale utente 1 e il numero finale utente 3, vengono creati gli ambienti del workshop con i seguenti nomi utente::

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

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

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

このワークショップは Cloud Shell から実行されることを想定しています。I seguenti strumenti sono necessari per il workshop:

• gcloud (versione >= 270)
• kubectl
• sed (funziona con sed di Cloud Shell / Linux, non con Mac OS)
• git (assicurati di utilizzare l'ultima versione)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Tutti gli strumenti, ad eccezione di kustomize, sono installati in Cloud Shell per impostazione predefinita. Se kustomize non è installato, installalo utilizzando lo script bash fornito nel link precedente e verifica che il file binario si trovi in PATH eseguendo il comando kustomize in Cloud Shell.

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

1. Cloud Shell を開き、以降の作業を Cloud Shell 上で実行します。Per aprire Cloud Shell, fai clic sul link riportato di seguito.

CLOUD SHELL

2. Assicurati di aver eseguito l'accesso a gcloud con l'utente amministratore previsto.

gcloud config list

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

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

4. Definisci il nome dell'organizzazione, l'ID account di fatturazione, il numero del workshop e il bucket GCS amministrativo da utilizzare per il workshop.Nella sezione precedente, controlla le autorizzazioni necessarie per configurare il 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>

5. Esegui lo script 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 

Non devi definire un numero iniziale e finale per creare un ambiente per te.

bootstrap_workshop.shスクリプトが完了すると、組織内のユーザーごとにGCPフォルダが作成されます。Nella cartella viene creato un progetto di gestione Terraform. Il progetto di gestione Terraform viene utilizzato per creare le risorse GCP rimanenti necessarie per questo workshop. Attiva le API necessarie nel progetto di gestione Terraform. Applica il piano Terraform utilizzando Cloud Build. Assegna al service account Cloud Build i ruoli IAM appropriati per consentirgli di creare risorse in GCP.Infine, configura un backend remoto nel bucket Google Cloud Storage (GCS) per archiviare tutti gli stati Terraform delle risorse GCP.

Per visualizzare i task Cloud Build nel progetto di gestione Terraform, è necessario l'ID progetto di gestione Terraform.これは、ワークショップ作成スクリプトで指定された管理用GCSバケットに保存されます。Quando esegui lo script di creazione del workshop per più utenti, tutti gli ID progetto di gestione di Terraform si trovano nel bucket GCS.

6. Recupera il file workshop.txt dal bucket GCS amministrativo per ottenere l'ID progetto Terraform.

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .

Configurazione del workshop (configurazione multiutente)

7. Cloud Shell を開き、以降の作業を Cloud Shell 上で実行します。Per aprire Cloud Shell, fai clic sul link riportato di seguito.

CLOUD SHELL

8. Assicurati di aver eseguito l'accesso a gcloud con l'utente amministratore previsto.

gcloud config list

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

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

10. Definisci il nome dell'organizzazione, l'ID account di fatturazione, il numero del workshop e il bucket GCS amministrativo da utilizzare per il workshop.Nella sezione precedente, controlla le autorizzazioni necessarie per configurare il 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>

11. Esegui lo script bootstrap_workshop.sh.このスクリプトの完了には数分かかる場合があります。

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}

12. Recupera il file workshop.txt dal bucket GCS amministrativo per ottenere l'ID progetto Terraform.

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .

4. Configurazione dell'infrastruttura - Flusso di lavoro dell'utente

Durata: 1 ora

ユーザーはここからワークショップを実行します。 Esegui i passaggi in una finestra di navigazione in incognito (INCOGNITO) di Chrome o Firefox.

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

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

ユーザー情報の取得

L'amministratore che configura il workshop deve fornire all'utente le informazioni su nome utente e password.A tutti i progetti degli utenti viene aggiunto come prefisso il nome utente, ad esempio [e-mail], e l'ID progetto di gestione di Terraform diventa user001-200131-01-tf-abcde.Chaque utilisateur ne peut accéder qu'à son propre environnement d'atelier.

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

このワークショップは Cloud Shell から実行されることを想定しています。I seguenti strumenti sono necessari per il workshop:

Tutti gli strumenti, tranne kustomize e pv, sono installati in Cloud Shell per impostazione predefinita. L'installazione di questi due strumenti è descritta di seguito.

• gcloud (versione >= 270)
• kubectl
• sed (funziona con sed di Cloud Shell / Linux, non con Mac OS)
• git (assicurati di utilizzare l'ultima versione)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

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

bootstrap_workshop.shスクリプトが完了すると、組織内のユーザーごとにGCPフォルダが作成されます。Nella cartella viene creato un progetto di gestione Terraform. Il progetto di gestione Terraform viene utilizzato per creare le risorse GCP rimanenti necessarie per questo workshop. setup-terraform-admin-project.shスクリプトは、terraform管理プロジェクトで必要なAPIを有効にします。 Cloud Build viene utilizzato per applicare il piano Terraform.Lo script viene utilizzato per concedere i ruoli IAM appropriati all'account di servizio Cloud Build, in modo che possa creare risorse in GCP.Infine, il backend remoto è configurato per il bucket Google Cloud Storage (GCS) per archiviare il Terraform state di tutte le risorse GCP.

Per visualizzare i task Cloud Build nel progetto di gestione Terraform, è necessario l'ID progetto di gestione Terraform.これは、ワークショップ作成スクリプトで指定された管理用GCSバケットに保存されます。Quando esegui lo script di creazione del workshop per più utenti, tutti gli ID progetto di gestione di Terraform si trovano nel bucket GCS.

Questo workshop è progettato per essere eseguito in Cloud Shell e Cloud Console.Per accedere con un altro nome utente e un'altra password, esegui i passaggi successivi in una finestra di navigazione in incognito (INCOGNITO).

1. Cloud Shell を開き、以降の作業を Cloud Shell 上で実行します。Per aprire Cloud Shell, fai clic sul link riportato di seguito.

CLOUD SHELL

2. Installa kustomize in $HOME/bin (se non è già installato) e aggiungi $HOME/bin a $PATH.

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

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

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

4. Assicurati di aver eseguito l'accesso a gcloud con l'utente previsto.

gcloud config list
 

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

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

6. Recupera l'ID progetto di gestione Terraform con il seguente comando::

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

7. ワークショップに関連するすべてのリソース情報は、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
 

8. Fai clic sul link visualizzato per aprire la pagina Cloud Build del progetto di gestione Terraform.

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

9. Viene visualizzata la pagina Cloud Build. Fai clic sul link Cronologia nel riquadro di navigazione a sinistra, quindi fai clic sull'ultima build per visualizzare i dettagli della prima applicazione di Terraform.Le seguenti risorse vengono create come parte dello script Terraform:上記アーキテクチャ図も参考になります。

• Quattro progetti GCP all'interno dell'organizzazione.各プロジェクトは提供された請求アカウントIDに紐付いています。
• Un progetto è un network host project in cui è configurata una VPC condivisa.このプロジェクトには、他のリソースは作成されません。
• Un progetto è il ops project utilizzato per il cluster GKE del piano di controllo Istio.
• Gli altri due progetti rappresentano due team di sviluppo diversi che lavorano sui rispettivi servizi.
• In ciascuno dei tre progetti ops, dev1 e dev2 vengono creati due cluster GKE.
• Viene creato un repository CSR denominato k8s-repo contenente sei cartelle per i file manifest Kubernetes. GKEクラスタごとに1つのフォルダがあります。このリポジトリは、GitOps形式でKubernetesのマニフェストをクラスタにデプロイするために使用されます。
• Cloud Buildトリガーは、k8s-repo のmasterブランチへのコミットがあるたびに作成され、KubernetesのマニフェストをそれぞれのフォルダからGKEクラスタにデプロイします。

L'esecuzione di questo script Terraform richiede 40-50 minuti.

10. Quando la build nel progetto di gestione Terraform viene completata, viene avviata un'altra build nel progetto ops.Fai clic sul link visualizzato per aprire la pagina Cloud Build del progetto ops.

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

Nota: questa build deve essere completata prima di verificare l'installazione di Istio.

インストールを確認

11. Crea un file kubeconfig per gestire tutti i cluster.Esegui lo script riportato di seguito.

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

Questo script crea un nuovo file kubeconfig denominato kubemesh nella cartella gke.

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

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

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

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

14. Recupera il contesto del cluster.Dovresti vedere sei cluster.

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

Verifica dell'installazione di Istio

15. Verifica che tutti i pod siano in esecuzione e che il job sia completato, quindi verifica che Istio sia installato su entrambi i 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

16. Istio が両方のdev1クラスタにインストールされていることを確認してください。dev1Nel cluster vengono eseguiti solo Citadel, sidecar-injector e coredns. Condividi il piano di controllo di Istio in esecuzione nel cluster ops-1.

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
 

17. Istioが両方のdev2クラスタにインストールされていることを確認してください。dev2Nel cluster vengono eseguiti solo Citadel, sidecar-injector e coredns. 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

Verifica del servizio di rilevamento del piano di controllo condiviso

18. (Facoltativo) Verifica che il secret sia stato eseguito il deployment.

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

Questoワークショップでは、すべてのGKEクラスタが作成される単一の 共有VPCを使用します。Per rilevare i servizi in tutto il cluster, utilizza il file kubeconfig (per ogni cluster di applicazioni) creato come Secret nel cluster ops.Pilot utilizza questi secret per rilevare i servizi eseguendo query sul server API Kube del cluster di applicazioni, autenticato tramite i secret precedenti.Puoi notare che entrambi i cluster ops possono autenticarsi in tutti i cluster app utilizzando il secret creato in kubeconfig. Il cluster Ops può rilevare automaticamente i servizi utilizzando il file kubeconfig come secret.Ciò richiede che Pilot nel cluster ops possa accedere al server API Kube di tutti gli altri cluster. Se Pilot non riesce a raggiungere il server API Kube, aggiungi manualmente i servizi remoti come ServiceEntries. ServiceEntriesは、サービスレジストリのDNSエントリと考えることができます。 ServiceEntries definisce i servizi utilizzando nomi DNS completi (FQDN) e indirizzi IP raggiungibili.詳しくは、Istio Multicluster のドキュメントをご覧ください。

5. infrastructure リポジトリの説明

Cloud Build dell'infrastruttura

Le risorse GCP del workshop vengono create utilizzando Cloud Build e Infrastructure repository CSR.Esegui lo script di creazione del workshop (disponibile in scripts/bootstrap_workshop.sh) dal terminale locale.ワークショップ作成スクリプトは、GCPフォルダ、terraform管理プロジェクト、および Cloud Buildサービスアカウントの適切なIAMアクセス許可を作成します。Terraform管理プロジェクトは、Terraform states、ログ、およびその他のスクリプトを保存するために使用されます。Contiene i repository CSR di infrastructure e k8s_repo.これらのリポジトリについては、次のセクションで詳しく説明します。 terraform管理プロジェクトには、他のワークショップリソースは組み込まれていません。 L'account di servizio Cloud Build del progetto di gestione Terraform viene utilizzato per creare le risorse del workshop.

Infrastructure フォルダにある cloudbuild.yaml ファイルは、ワークショップのGCPリソースを構築するために使用します。 Crea un'immagine del builder personalizzata utilizzando tutti gli strumenti necessari per creare risorse GCP.Questi strumenti includono gcloud SDK, Terraform e altre utilità come Python, Git e jq.カスタムビルダーイメージは、terraform plan を実行し、各リソースに apply します。I file Terraform per ogni risorsa si trovano in una cartella separata (per maggiori dettagli, consulta la sezione successiva).Le risorse vengono create una alla volta, nel modo in cui vengono normalmente create (ad esempio, il progetto GCP viene creato prima che vengano create le risorse al suo interno).Per ulteriori dettagli, consulta il file cloudbuild.yaml.

Cloud Build viene attivato ogni volta che viene eseguito un commit nel repository infrastructure.Le modifiche apportate all'infrastruttura vengono salvate come Infrastructure as Code (IaC) e vengono eseguite nel repository.ワークショップの状態は常にこのリポジトリに保存されます。

Struttura delle cartelle: team, ambienti e risorse

Infrastructure リポジトリは、ワークショップのGCPインフラストラクチャリソースをセットアップします。Organizzati in cartelle e sottocartelle.La cartella di base all'interno del repository rappresenta un team che possiede una risorsa Google Cloud specifica.次のレイヤーのフォルダは un determinato ambiente del team (ad esempio dev, stage, prod)Il livello successivo delle cartelle nell'ambiente rappresenta risorse specifiche, ad esempio host_project, gke_clusters e così via.Gli script e i file Terraform necessari si trovano nella cartella delle risorse.

In questo workshop, vedrai quattro tipi di team::

1. infrastructure: rappresenta il team dell'infrastruttura che gestisce il cloud.È responsabile della creazione delle risorse GCP per tutti gli altri team.リソースにはTerraform管理プロジェクトを使用します。Il repository dell'infrastruttura si trova nel file di stato di Terraform (descritto di seguito).Queste risorse vengono create dallo script bash durante la procedura di creazione del workshop. Per ulteriori informazioni, consulta il modulo 0 - Configurazione dell'infrastruttura - Flusso di lavoro dell'amministratore.
2. network: rappresenta il team di rete. VPCとネットワークリソースを担当します。彼らは次のGCPリソースを所有しています。
3. host project - Rappresenta il progetto host di una VPC condivisa.
4. shared VPC: rappresenta il VPC condiviso, le subnet, gli intervalli IP secondari, le informazioni di routing e le regole firewall.
5. ops: rappresenta il team operativo / DevOps.彼らは次のリソースを所有しています。
6. ops project: すべてのopsリソースのためのプロジェクトを表します。
7. gke clusters - Cluster GKE ops per regione.Inoltre, il piano di controllo Istio viene installato in ogni cluster GKE ops.
8. k8s-repo: repository CSR contenente i manifest GKE per tutti i cluster GKE.
9. apps: rappresenta il team delle applicazioni.このワークショップは、app1 と app2 の2つのチームをシミュレーションします。彼らは次のリソースを所有しています。
10. app projects: tutti i team di app hanno un insieme di progetti separato.In questo modo, puoi controllare la fatturazione e IAM per progetto.
11. gke clusters: si tratta del cluster per l'applicazione in cui vengono eseguiti i container/ pod dell'applicazione.
12. gce instances: facoltativo, da utilizzare se sono presenti applicazioni in esecuzione su istanze GCE.In questo workshop, app1 ha diverse istanze GCE in cui viene eseguita una parte dell'applicazione.

In questo workshop, utilizzeremo la stessa app (l'app Hipster Shop) sia per app1 che per app2.

Provider, stato, output - backend, stato condiviso

I provider google e google-beta si trovano in gcp/[environment]/gcp/provider.tf. provider.tf I file sono collegamenti simbolici in tutte le cartelle delle risorse.In questo modo, puoi gestire i provider in un unico posto anziché gestire separatamente il provider di ogni risorsa.

Tutte le risorse includono un file backend.tf che definisce la posizione del file tfstate della risorsa.Questo file backend.tf viene generato dal modello (in templates/backend.tf_tmpl) utilizzando lo script (in scripts/setup_terraform_admin_project) e viene inserito in ogni cartella delle risorse. GCSバケットがファイル置き場として使われます。 GCSバケットフォルダ名はリソース名と一致します。Tutte le risorse si trovano nel progetto di gestione Terraform.

Le risorse con valori interdipendenti includono un file output.tf.L'output richiesto viene salvato nel file tfstate definito nel backend di quella risorsa specifica.Ad esempio, per creare un cluster GKE in un progetto, devi conoscere l'ID progetto.L'ID progetto viene restituito tramite output.tf nel file tfstate, disponibile tramite l'origine dati terraform_remote_state per la risorsa cluster GKE.

Il file shared_state è un'origine dati terraform_remote_state che fa riferimento al file tfstate della risorsa.shared_state_[resource_name].tf Il file si trova in una cartella delle risorse che richiede l'output di altre risorse.Ad esempio, la cartella delle risorse ops_gke contiene il file shared_state delle risorse ops_project e shared_vpc.これは、opsプロジェクトでGKEクラスタを作成するにはプロジェクトIDとVPCの詳細が必要だからです。 Il file shared_state viene generato dal modello (in templates/shared_state.tf_tmpl) utilizzando lo script (in scripts/setup_terraform_admin_project).Il file shared_state di tutte le risorse si trova nella cartella gcp/[environment]/shared_states.必要なshared_state ファイルは、それぞれのリソースフォルダーでシンボリックリンクされています。Se posizioni tutti i file shared_state in una cartella e crei un link simbolico alle cartelle delle risorse appropriate, puoi gestire facilmente tutti i file di stato in un unico posto.

変数

すべてのリソースの値は環境変数として保存されます。Queste variabili vengono salvate (come istruzioni di esportazione) nel file vars.sh nel bucket GCS del progetto terraform admin.Ciò include l'ID organizzazione, l'account di fatturazione, l'ID progetto, i dettagli del cluster GKE e altro ancora.Puoi scaricare vars.sh su qualsiasi dispositivo per ottenere i valori di configurazione.

Le variabili Terraform vengono archiviate in vars.sh come TF_VAR_[variable name].Queste variabili vengono utilizzate per generare il file variables.tfvars in ogni cartella delle risorse. variables.tfvars Il file contiene tutte le variabili e i relativi valori. variables.tfvars I file vengono generati da un file modello nella stessa cartella utilizzando lo script (disponibile in scripts/setup_terraform_admin_project).

K8s リポジトリの説明

k8s_repo は、terraform管理プロジェクトにあるCSRリポジトリ（infrastructureリポジトリとは別）で、GKEマニフェストをすべてのGKEクラスタに保存および適用するために使用されます。k8s_repo viene creato dall'infrastruttura Cloud Build (per maggiori dettagli, consulta la sezione precedente).Durante il primo processo Cloud Build dell'infrastruttura, vengono creati un totale di sei cluster GKE.k8s_repoには、6つのフォルダーが作成されます。Ogni cartella (con un nome corrispondente al nome del cluster GKE) corrisponde a un cluster GKE contenente il file manifest delle risorse corrispondente.Come per la creazione dell'infrastruttura, Cloud Build viene utilizzato per applicare i manifest Kubernetes a tutti i cluster GKE utilizzando k8s_repo. Cloud Build viene attivato ogni volta che viene eseguito un commit nel repository k8s_repo.Come l'infrastruttura, tutti i manifest Kubernetes vengono archiviati come codice nel repository k8s_repo e lo stato di ogni cluster GKE viene sempre archiviato nella rispettiva cartella.

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

Progetti, cluster GKE e spazi dei nomi

このワークショップのリソースは、さまざまなGCPプロジェクトに分かれています。プロジェクトは、会社の組織（またはチーム）構造と一致する必要があります。チーム (all'interno dell'organizzazione) che lavorano su diversi progetti / prodotti / risorse utilizzano diversi progetti GCP.Se crei progetti separati, puoi creare set separati di autorizzazioni IAM e gestire la fatturazione a livello di progetto.さらに、クォータもプロジェクトレベルで管理されます。

In questo workshop, vedremo cinque team, ognuno con un progetto separato.

1. Il team dell'infrastruttura che crea le risorse GCP utilizza il progetto di gestione Terraform.Gestiscono l'infrastruttura come codice nel repository CSR (denominato infrastructure) e archiviano tutte le informazioni sullo stato di Terraform per le risorse create in GCP nel bucket GCS.Questi controllano l'accesso al bucket GCS per il repository CSR e lo stato di Terraform.
2. Il team di rete che crea il VPC condiviso utilizza il hostprogetto.このプロジェクトには、VPC、サブネット、ルート、ファイアウォールルールが含まれています。共有VPCを使用すると、GCPリソースのネットワークを一元管理できます。すべてのプロジェクトは、ネットワークにこの単一の共有VPCを使用しています。
3. Il team ops / platform che crea i cluster GKE e il piano di controllo ASM / Istio utilizza il opsprogetto. Gestisce il ciclo di vita dei cluster GKE e del service mesh.Questi sono responsabili del rafforzamento del cluster e della gestione della resilienza e della scalabilità della piattaforma Kubernetes.このワークショップでは、リソースをKubernetesにデプロイするGitOpsメソッドを使用します。 CSRリポジトリ（k8s_repo と呼ばれる）がopsプロジェクトに存在します。
4. Infine, i team dev1 e dev2 (che rappresentano due team di sviluppo) che creano l'applicazione utilizzano i propri dev1 e dev2progetti.Queste sono le applicazioni e i servizi che offri ai tuoi clienti.これらは、運用チームが管理するプラットフォーム上に構築されます。リソース（deployment、service など）は k8s_repo にプッシュされ、適切なクラスターに展開されます。このワークショップは CI / CD のベストプラクティスとツールに焦点を当てていないことに注意してください。 Utilizza Cloud Build per automatizzare il deployment delle risorse Kubernetes nel cluster GKE.In scenari operativi reali, utilizzerai una soluzione CI / CD appropriata per eseguire il deployment dell'applicazione nel cluster GKE.

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

1. Cluster ops: utilizzato dal team ops per eseguire gli strumenti DevOps.In questo workshop, esegui ASM / Istio Control Plane per gestire il service mesh.
2. Cluster applicazioni: il team di sviluppo lo utilizza per eseguire le applicazioni.このワークショップでは、Hipster ショップアプリに使用されます。

Se separi gli strumenti ops / amministrativi dal cluster in cui viene eseguita l'applicazione, puoi gestire il ciclo di vita di ogni risorsa separatamente. I due tipi di cluster esistono anche in progetti diversi associati ai team / prodotti che li utilizzano.In questo modo, è più facile gestire anche le autorizzazioni IAM.

Verranno visualizzati un totale di sei cluster GKE. opsプロジェクトでは、2つのリージョナルopsクラスターが作成されます。 ASM / Istio control plane viene installato in entrambi i cluster ops.各opsクラスターは異なるリージョンにあります。Inoltre, ci sono quattro cluster di applicazioni di zona.これらは個別のプロジェクトに作成されます。このワークショップは、それぞれ個別のプロジェクトを持つ2つの開発チームをシミュレーションします。每個專案包含兩個應用程式叢集。クラスタアプリは、異なるゾーンのゾーンクラスタです。 I quattro cluster di app si trovano in due regioni e quattro zone.これにより、リージョンおよびゾーンの冗長性が得られます。

L'applicazione Hipster Shop, utilizzata in questo workshop, viene implementata in tutti e quattro i cluster di app.Ogni microservizio si trova in uno spazio dei nomi separato per tutti i cluster di app.Hipster ショップアプリのDeployment（Pod）は、opsクラスターには展開されません。Tuttavia, anche lo spazio dei nomiとサービスリソース di tutti i microservizi vengono creati nel cluster ops.ASM / Istio control plane utilizza il registro dei servizi Kubernetes per il rilevamento dei servizi. Se non sono presenti servizi (nel cluster ops), devi creare manualmente le ServiceEntry per ogni servizio in esecuzione nel cluster app.

In questo workshop, verrà eseguito il deployment di un'applicazione di microservizi a 10 livelli.Questa applicazione è un'app di e-commerce basata sul web chiamata Hipster Shop, che consente agli utenti di sfogliare gli articoli, aggiungerli al carrello e acquistarli.

Kubernetes マニフェストと k8s_repo

Utilizza k8s_repo per aggiungere risorse Kubernetes a tutti i cluster GKE.Per farlo, copia il manifest Kubernetes e commit it in k8s_repo. すべてのコミットを k8s_repo に行うと、Cloud Build ジョブがトリガーされ、Kubernetes マニフェストがそれぞれのクラスタにデプロイされます。I manifest di ogni cluster si trovano in una cartella separata con lo stesso nome del cluster.

I sei cluster sono denominati come segue:

1. gke-asm-1-r1-prod: cluster regionale nella regione 1
2. gke-asm-2-r2-prod: cluster ops regionale nella regione 2
3. gke-1-apps-r1a-prod - Cluster di app nella zona a della regione 1
4. gke-2-apps-r1b-prod - App cluster in zona b della regione 1
5. gke-3-apps-r2a-prod: cluster di app nella zona a della regione 2
6. gke-4-apps-r2b-prod - Cluster di app nella zona b della regione 2

k8s_repo には、これらのクラスターに対応するフォルダーがあります。I manifesti inseriti in queste cartelle vengono applicati ai cluster GKE corrispondenti.I manifest di ogni cluster vengono inseriti in una sottocartella (all'interno della cartella principale del cluster) per facilitarne la gestione.In questo workshop, utilizzeremo Kustomize per tenere traccia delle risorse di cui viene eseguito il deployment.詳細については、Kustomizeの公式ドキュメントを参照してください。

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

Obiettivo: Esegui il deployment dell'app Hipster Shop nel cluster apps

• k8s-repoリポジトリをクローン
• Hipsterショップのマニフェストを全てのappsクラスターにコピー
• HipsterショップアプリのためにServicesをopsクラスターに作成
• グローバルの接続性をテストするためloadgeneratorをopsクラスターにセットアップ
• Verifica della connessione sicura all'app Hipster Shop

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

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

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

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

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

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

 

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

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

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

4. Copia il manifest di Hipster Shop nel repository di origine di tutti i 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/.
 

5. Hipsterショップは、opsクラスターではなく、アプリケーションクラスターに展開されます。 Il cluster ops viene utilizzato solo con il piano di controllo ASM / Istio. Elimina il deployment、PodSecurityPolicyおよびRBACマニフェスト di Hipster Shop dal 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
 

6. Rimuovi il deployment cartservice, RBAC e PodSecurityPolicy da tutti i cluster dev tranne uno. Il negozio Hipster non è stato creato per il deployment multicluster. Se continui a eseguire tutti e quattro i deployment, le informazioni sul carrello saranno incoerenti a seconda del deployment a cui accedi.

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

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

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

7. Aggiungi cartservice deployment, RBAC e PodSecurityPolicy a kustomization.yaml solo per il primo cluster di sviluppo.

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

8. Elimina le directory PodSecurityPolicies, deployment e RBAC da kustomization.yaml del cluster ops.

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

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

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

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

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

11. Copia la risorsa Config Connector in uno dei cluster di ogni progetto.

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

12. Sostituisci PROJECT_ID nel manifest di Config Connector.

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

13. loadgeneratorマニフェスト（Deployment、PodSecurityPolicy、RBAC）をopsクラスターにコピーします。 L'app Hipster Shop viene pubblicata utilizzando il bilanciamento del carico Google Cloud (GCLB) globale. GCLB riceve il traffico client (destinato a frontend) e lo invia all'istanza di servizio più vicina. Se loadgenerator viene distribuito in entrambi i cluster ops, il traffico viene inviato a entrambi i gateway Istio Ingress in esecuzione nei cluster ops.Il bilanciamento del carico è descritto in dettaglio nella sezione successiva.

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

14. Sostituisci l'ID progetto ops nel manifest loadgenerator di entrambi i cluster ops.

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

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

15. Aggiungi la risorsa loadgenerator di entrambi i cluster ops a kustomization.yaml.

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

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

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

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

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

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

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

18. Verifica che i pod di tutti gli spazi dei nomi delle applicazioni, tranne il carrello, siano in stato di esecuzione (Running) in tutti i cluster di sviluppo.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bilanciamento del carico globale

Ora l'app Hipster Shop è stata implementata in tutti e quattro i cluster di app.Questi cluster si trovano in due regioni e quattro zone.Il cliente può accedere al servizio frontend e all'app Hipster Shop.frontendIl servizio viene eseguito in tutti e quattro i cluster di app. Utilizza Google Cloud Load Balancer (GCLB) per ottenere il traffico client per tutte e quattro le istanze del servizio frontend.

Istio Ingressゲートウェイはopsクラスターでのみ実行され、リージョン内の2つのゾーンアプリケーションクラスターに対するリージョナルロードバランサーとして機能します。GCLB utilizza due ingressi Istio (in esecuzione in due cluster ops) come backend per il servizio di frontend globale. Istio Ingress Gateway receives client traffic from GCLB and sends it to the frontend Pods running in the application cluster.

Puoi anche posizionare i gateway Istio Ingress direttamente nei cluster delle applicazioni e utilizzare GCLB come backend.

Controller GKE Autoneg

Il servizio Kubernetes Istio Ingress Gateway utilizza i gruppi di endpoint di rete (NEG) per registrarsi come backend di GCLB. I NEG consentono il bilanciamento del carico nativo per i container utilizzando GCLB. I NEG vengono creati utilizzando un'annotazione speciale del servizio Kubernetes, in modo che possano registrarsi con il controller NEG. Il controller Autoneg è un controller GKE speciale che automatizza la creazione di NEG e le assegna a GCLB come backend utilizzando le annotazioni del servizio. Il piano di controllo Istio, incluso il gateway di ingresso Istio, viene implementato nell'infrastruttura iniziale di Terraform Cloud Build. La configurazione di GCLB e Autoneg viene eseguita come parte della creazione iniziale di Cloud Build dell'infrastruttura Terraform.

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

GCPマネージド証明書は、frontend GCLBサービスへのクライアントトラフィックを保護するために使用されます。 GCLBは、グローバルfrontendサービスにマネージド証明書を使用し、SSLはGCLBで終端されます。In questo workshop, utilizzeremo Cloud Endpoints come dominio per i certificati gestiti.または、puoi creare un certificato gestito da GCP utilizzando il dominio e il nome DNS di frontend.

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

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

21. Puoi verificare che il certificato sia valido facendo clic sull'icona a forma di lucchetto nella barra degli URL della scheda Chrome.

Verifica del bilanciamento del carico globale

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

22. Ottieni il link GCLB > Monitoring del progetto ops in cui è stato creato il bilanciatore del carico Hipster Shop GCLB.

echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=${TF_VAR_ops_project_name}&cloudshell=false&tab=monitoring&duration=PT1H"
 

23. Come mostrato di seguito, modifica il menu a discesa Backend da All backends a istio-ingressgateway.

24. Controlla il traffico in entrambe le direzioni di istio-ingressgateways.

Vengono creati tre NEG per ogni istio-ingressgateway. Poiché il cluster ops è un cluster regionale, viene creato un NEG per ogni zona della regione.Tuttavia, i pod istio-ingressgateway vengono eseguiti in una singola zona per regione. ここでは、istio-ingressgatewayPodに向かうトラフィックが表示されます。

La funzionalità di generazione del carico viene eseguita su entrambi i cluster ops e simula il traffico client da due regioni.opsクラスターリージョン1で生成された負荷は、リージョン2のistio-ingressgatewayに送信されます。Allo stesso modo, il carico generato nella regione 2 del cluster ops viene inviato a istio-ingressgateway nella regione 1.

7. Stackdriverによる可観測性

Obiettivo: integrare e visualizzare i dati di telemetria di Istio in Stackdriver

• istio-telemetryリソースをインストール
• Istio Servicesのダッシュボードを作成/更新
• コンテナのログを表示
• Visualizzare le informazioni di tracciamento distribuito in Stackdriver

Una delle funzionalità principali di Istio è l'osservabilità integrata ("o11y").Ciò significa che, anche se si tratta di un contenitore black box senza funzionalità, gli operatori possono osservare il traffico in entrata e in uscita da questi contenitori e fornire servizi ai clienti.Questa osservazione assume la forma di diverse metodologie: metriche, log e tracce.

また、Hipster ショップに組み込まれている負荷生成機能を利用します。L'osservabilità non funziona molto bene con i sistemi statici senza traffico, quindi la generazione di carico aiuta a verificarne il comportamento.La generazione del carico è già stata eseguita, quindi è facile da controllare.

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

cd ${WORKDIR}/k8s-repo

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

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

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

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

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

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

28. Istio→Stackdriverの連携を確認します。Recupera il CRD del gestore Stackdriver.

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

L'output dovrebbe mostrare un gestore denominato stackdriver:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s

Verifica che le metriche di Istio siano esportate in Stackdriver.リンクをクリックします。:

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

Ti verrà chiesto di creare un nuovo spazio di lavoro denominato in base al progetto Ops. Seleziona [Ok].新しいUIについてのプロンプトが表示されたら、ダイアログを閉じます。

In Esplora metriche, fai clic su [Tipo di record]e inserisci "istio".Il tipo di risorsa "Pod Kubernetes" include opzioni come "Conteggio richieste server".Ciò indica che la metrica viene trasmessa dalla mesh a Stackdriver.

(Se vuoi visualizzare le righe seguenti, devi raggrupparle in base a destination_service_name.）

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

Le metriche si trovano nel sistema Stackdriver APM, quindi è necessario visualizzarle.Questa sezione installa una dashboard predefinita che mostra tre delle quattro"metriche golden signal".Traffico (richieste al secondo), latenza (in questo caso, il 99° percentile e il 50° percentile) ed errori (in questo esempio, l'saturazione è esclusa).

Il proxy Envoy di Istio fornisce diverse metriche, che sono un buon punto di partenza. (L'elenco completo è disponibile qui).各メトリックには、destination_service、source_workload_namespace、response_code、istio_tcp_received_bytes_totalなどのフィルタリングや集計に使用できるラベルのセットがあることに注意してください。

29. Successivamente, aggiungi una dashboard di metriche predefinite. Dashboard APIを直接使用します。In genere, questa operazione non viene eseguita se generi manualmente le chiamate API.Fa parte di un sistema di automazione o crea manualmente il dashboard nell'interfaccia utente web.In questo modo, puoi iniziare a usararlo subito.:

cd ${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g'  services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/${TF_VAR_ops_project_name}/dashboards \
 -d @services-dashboard.json 

30. 移動して、新しく追加されたダッシュボードを表示します。

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

Puoi anche utilizzare UX per modificare la dashboard in tempo reale, ma in questo caso utilizzeremo l'API per aggiungere rapidamente un nuovo grafico.Per farlo, devi recuperare l'ultima versione della dashboard, applicare le modifiche e poi inviarla utilizzando il metodo HTTP PATCH.

31. Puoi utilizzare l'API Monitoring per recuperare le dashboard esistenti.Recupera il dashboard che hai appena aggiunto.:

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

32. Aggiunta di un nuovo grafico: (50th％ile latency) [API reference] Ora puoi aggiungere un nuovo widget grafico alla dashboard con il codice.この変更は、ピアによってレビューされ、バージョン管理システムにチェックインされます。Il widget che aggiungi mostra una latenza mediana del 50%.

Prova a modificare la dashboard che hai appena creato e aggiungi una nuova sezione:

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

33. Aggiorna il servicesdashboard esistente:

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

34. Vai al link di output seguente per visualizzare la dashboard aggiornata:

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

35. Eseguiremo un'analisi semplice dei log.

Istio fornisce un insieme di log strutturati di tutto il traffico di rete in-mesh e li carica in Stackdriver Logging per consentire l'analisi cross-cluster con un unico strumento potente.I log includono metadati a livello di servizio, come cluster, container, app e connection_id.

Un esempio di voce di log (in questo caso, accesslog per il proxy Envoy) è il seguente (formattato)::

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

Qui vengono visualizzati i log.:

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

Per visualizzare i log del control plane di Istio, seleziona Risorse > Container Kubernetes e cerca "Pilot".

Qui puoi vedere il piano di controllo Istio che esegue il push delle impostazioni proxy per ogni servizio di app di esempio. "CDS", "LDS" e"RDS" rappresentano API Envoy diverse (maggiori informazioni).

Oltre ai log di Istio, puoi trovare i log dei container, nonché i log dell'infrastruttura o di altri servizi GCP, tutto nella stessa interfaccia. Di seguito è riportata una query di log di esempio per GKE:In Visualizzatore log puoi anche creare metriche dai log, ad esempio "Conta tutti gli errori che corrispondono a una stringa".Puoi utilizzarlo nella dashboard o come parte di un avviso.I log possono anche essere trasmessi in streaming ad altri strumenti di analisi, come BigQuery.

Ecco alcuni filtri di esempio per un negozio hipster:

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

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

36. Controlla la tracciabilità distribuita.

Poiché utilizzi un sistema distribuito, il debug richiede un nuovo strumento: la traccia distribuita.Questo strumento ti consente di trovare statistiche su come interagiscono i servizi (ad esempio, il rilevamento di eventi insolitamente lenti nel diagramma riportato di seguito) o di esaminare tracce di esempio non elaborate per scoprire cosa sta succedendo.

La visualizzazione della cronologia mostra tutti i passaggi di una richiesta in ordine cronologico fino alla risposta all'utente finale.Grafico in base al tempo di attesa o al tempo dalla richiesta iniziale alla prima richiesta dello stack Hipster.Più il numero di punti è alto, più l'esperienza utente è lenta (e infelice).）。

Se fai clic sul punto, puoi trovare una visualizzazione a cascata dettagliata della richiesta specifica.Questa funzionalità, che consente di trovare i dettagli grezzi di una richiesta specifica (non solo le statistiche aggregate), è essenziale per comprendere le interazioni tra i servizi, in particolare per individuare interazioni rare e negative tra i servizi.

La visualizzazione a cascata è nota a chiunque abbia utilizzato il debugger, ma in questo caso mostra il tempo trascorso attraversando la mesh tra i servizi ed eseguiti in container separati, anziché il tempo trascorso in diversi processi di una singola applicazione.

Qui puoi trovare la traccia.:

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

Esempio di screenshot dello strumento:

37. Pubblica gli strumenti di osservabilità all'interno del cluster.

Prometheus e Grafana sono strumenti di osservabilità open source che vengono implementati come parte del piano di controllo Istio del cluster ops.Questi vengono eseguiti nel cluster ops e possono essere utilizzati per ulteriori indagini sullo stato della mesh e sullo stesso Hipster Shop.

Per visualizzare questi strumenti, esegui il seguente comando da Cloud Shell (Prometheus viene saltato perché non c'è molto da vedere):

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

Successivamente, apri il servizio pubblicato (3000) nella scheda Anteprima web di Cloud Shell.

• https://ssh.cloud.google.com/devshell/proxy?authuser=0&port=3000&environment_id=default
• (必ずCloud Shellと同じChromeのシークレットウィンドウでURLを開いてください)

Grafanaは、Stackdriverのカスタムダッシュボードに似たメトリックダッシュボードシステムです。 L'installazione di Istio include diversi dashboard predefiniti che puoi utilizzare per visualizzare le metriche dei servizi e dei carichi di lavoro in esecuzione in una determinata mesh Istio, nonché lo stato di Istio Control Plane stesso.

8. Autenticazione TLS reciproca

Obiettivo: configurare una connessione sicura tra i microservizi(autenticazione)

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

L'app è installata e l'osservabilità è garantita, quindi verifica che la connessione tra i servizi sia protetta e continui a funzionare.

Ad esempio, nella dashboard Kiali puoi verificare che il servizio non utilizzi mTLS (nessuna icona "lucchetto").Tuttavia, il traffico scorre e il sistema funziona correttamente. La dashboard delle metriche d'oro di Stackdriver ti dà la certezza che il sistema funziona nel complesso.

38. opsクラスターのMeshPolicyを確認します。Nota: mTLS è permanente e consente sia il traffico criptato che quello non mTLS.

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

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

  spec:
    peers:
    - mtls:
        mode: PERMISSIVE

39. Attiva mTLS. Istio Operator Controller è in esecuzione e puoi modificare la configurazione di Istio modificando o sostituendo la risorsa IstioControlPlane.Il controller rileva le modifiche e aggiorna di conseguenza lo stato dell'installazione di Istio.Imposta mTLS su true per le risorse IstioControlPlane sia per il piano di controllo condiviso che per il piano di controllo replicato.In questo modo, MeshPolicy viene impostata su ISTIO_MUTUAL e viene creata la DestinationRule predefinita.

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

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

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

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

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

mTLSの動作確認

42. opsクラスターでMeshPolicyをもう一度確認します。注. Il traffico non criptato non è consentito e viene consentito solo il traffico mTLS.

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

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

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

43. Controlla la DestinationRule creata dal controller dell'operatore Istio.

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

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

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

Inoltre, puoi verificare la migrazione da HTTP a HTTPS nei log. UIのログからこの特定のフィールドを公開するには、ログエントリを1つクリックしてから、表示したいフィールドの値をクリックします。In questo caso, fai clic su "http" accanto a "Protocollo".:

In questo modo, avrai un buon modo per verificare l'attivazione di mTLS.:

Puoi anche convertire le voci di log in metriche e visualizzare un grafico delle serie temporali.:

TODO(smcghee)

9. deployment canary

Obiettivo: implementare una nuova versione del servizio frontend

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

カナリアデプロイメントは、新しいサービスの段階的なロールアウト手法です。Il deployment Canary aumenta il traffico verso la nuova versione, inviando al contempo la percentuale rimanente alla versione attuale.Il pattern comune consiste nell'eseguire l'analisi canary in ogni fase della suddivisione del traffico e confrontare le nuove versioni dei "segnali d'oro" (latenza, tasso di errore e saturazione) con la baseline.In questo modo, puoi evitare interruzioni del servizio e garantire la stabilità del nuovo servizio"v2" in tutte le fasi della suddivisione del traffico.

In questa sezione, imparerai a creare una nuova versione di base del deployment canary nel servizio frontend utilizzando Cloud Build e le norme sul traffico di Istio.

Innanzitutto, esegui la pipeline canary nella **regione DEV1 (us-west1)**, che esegue il deployment di frontend v2 in entrambi i cluster della regione.Successivamente, esegui la pipeline canary nella **regione DEV2 (us-central)**, che esegue il deployment della versione 2 in entrambi i cluster della regione.L'esecuzione sequenziale della pipeline per ogni regione, anziché in parallelo in tutte le regioni, consente di evitare interruzioni globali causate da una configurazione errata o da bug dell'app v2 stessa.

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

44. Da Cloud Shell, vai alla directory canary.:

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

45. Esegui lo script repo_setup.sh per copiare il manifest di base in k8s-repo.

cd $CANARY_DIR
./repo-setup.sh 
 

Viene copiato il seguente manifest.:

• Deployment frontend-v2
• Patch frontend-v1 (inclusi un'immagine container con l'etichetta "v1" e l'endpoint "/ version")
• respy, un piccolo pod che consente di esportare la distribuzione delle risposte HTTP e visualizzare le implementazioni canary in tempo reale.
• frontend Istio DestinationRule - Divide il servizio frontend Kubernetes in due sottoinsiemi, v1 e v2, in base all'etichetta di deployment "version"
• frontend Istio VirtualService: instrada il 100% del traffico a frontend v1.In questo modo, il comportamento round robin predefinito del servizio Kubernetes viene sovrascritto e il 50% di tutto il traffico della regione Dev1 viene immediatamente inviato a frontend v2.

46. Modifiche di commit in k8s_repo.:

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

47. Ops1プロジェクトのコンソールでCloud Buildに移動します。 Attendi il completamento della pipeline Cloud Build, quindi recupera i pod nello spazio dei nomi frontend di entrambi i cluster DEV1.Dovresti visualizzare quanto segue::

watch -n 1 kubectl --context ${DEV1_GKE_1} get pods -n frontend 
 

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

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s

48. Apri un'altra sessione di Cloud Shell. Enter the new Respy pod running in DEV1_GKE_1.

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

49. Esegui il comando watch per visualizzare la distribuzione delle risposte HTTP del servizio frontend.すべてのトラフィックは、新しいVirtualServiceで定義されたfrontend v1 deploymentに向かうことがわかります。

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

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

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

50. Torna alla sessione Cloud Shell precedente ed esegui la pipeline canary nella regione Dev2. Forniamo uno script per aggiornare la percentuale di traffico frontend v2 di VirtualService (aggiorniamo i pesi al 20%, 50%, 80% e 100%).各更新の間で、スクリプトはCloud Buildパイプラインが完了するのを待ちます。 Esegui lo script di deployment canary per la regione dev1.注-このスクリプトの完了には約10分かかります。

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

Durante l'esecuzione di questo script, puoi passare alla seconda sessione di Cloud Shell in cui viene eseguito il comando respy per visualizzare la suddivisione del traffico in tempo reale.Ad esempio, al 20% si verifica quanto segue:

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

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

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

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

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

52. Inoltre, tutto il traffico frontend dal pod Dev1 deve essere indirizzato al frontend v2.:

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

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

53. **Cloud Source Repos > k8s_repoに移動します。**Vengono visualizzati commit separati per ogni percentuale di traffico e il commit più recente viene visualizzato in cima all'elenco.:

54. Dev1でrespy Podを終了します。Successivamente, accedi al pod respy in esecuzione nella regione Dev2.

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

55. Esegui di nuovo il comando respy.:

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

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

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

*Tieni presente che la regione Dev2 è ancora"bloccata" nella versione 1.*Questo perché lo script repo_setup di base ha eseguito il push di VirtualService per inviare tutto il traffico in modo esplicito alla versione 1.In questo modo, abbiamo potuto eseguire in sicurezza il canary della regione in Dev1 e verificare che funzionasse correttamente prima di implementare la nuova versione a livello globale.

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

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

57. Da Respy Pod di Dev2, osserva il traffico di Dev2 Pod che si sposta gradualmente da frontend v1 a v2.Al termine dello script, viene visualizzato il seguente messaggio::

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

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

このセクションでは、リージョンのカナリアデプロイメントにIstioを使用する方法を紹介しました。Nell'ambiente di produzione, puoi attivare automaticamente questo script canary come pipeline Cloud Build utilizzando trigger come una nuova immagine container taggata pushata nel container registry anziché uno script manuale.Puoi anche aggiungere un'analisi canary tra ogni passaggio per analizzare la latenza e il tasso di errori della v2 rispetto a una soglia di sicurezza predefinita prima di inviare il traffico.

10. 認可ポリシー

Obiettivo: configurare RBAC tra i microservizi (autorizzazione)

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

A differenza delle applicazioni monolitiche che possono essere eseguite in un'unica posizione, le app di microservizi distribuite a livello globale effettuano chiamate oltre i confini della rete.Ciò significa che ci sono più punti di ingresso per le applicazioni e quindi più opportunità per attacchi dannosi.また、Kubernetes Podには一時的なIPアドレスがあるため、従来のIPアドレスベースのファイアウォールルールは、ワークロード間のアクセスを保護するには不十分です。マイクロサービスアーキテクチャでは、セキュリティへの新しいアプローチが必要です。 Basato su blocchi di base della sicurezza di Kubernetes, come gli account di servizio, Istio fornisce un insieme flessibile di norme di sicurezza per le applicazioni.

Istioポリシーは、認証と認可の両方を対象としています。認証はIDを検証し（このサーバーは本人であると言っていますか？）、認可は権限を検証します（このクライアントは許可されていますか？）。Nella sezione TLS相互認証 del modulo 1 (MeshPolicy) abbiamo parlato dell'autenticazione Istio.In questa sezione, imparerai a controllare l'accesso a currencyservice, uno dei carichi di lavoro dell'applicazione, utilizzando le norme di autorizzazione di Istio.

Innanzitutto, esegui il deployment di AuthorizationPolicy in tutti e quattro i cluster di sviluppo per bloccare tutto l'accesso a currencyservice e attivare un errore in frontend.Successivamente, assicurati che solo il servizio frontend possa accedere a currencyservice.

58. Vai alla directory di esempio di autorizzazione.

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

cd $AUTHZ_DIR
 

59. Vediamo i contenuti di currency-deny-all.yaml.このポリシーは、Deploymentラベルセレクターを使用して、currencyserviceへのアクセスを制限します。Tieni presente che non è presente alcun campo spec. Ciò significa che questo criterio nega l'accesso a tutti i servizi selezionati.

cat currency-deny-all.yaml
 

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

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

60. コピーします。

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

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

61. Esegui il push delle modifiche.

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

62. Prova ad accedere al frontend dell'app Hipster Shop nel browser:

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

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

63. Vediamo come il servizio currency applica questo AuthorizationPolicy.Innanzitutto, attiva i log a livello di traccia in uno dei proxy Envoy del pod valuta, poiché le chiamate di autorizzazione bloccate non vengono registrate per impostazione predefinita.

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

64. currencyサービスのサイドカープロキシからRBAC（認可）ログを取得します。 Dovresti visualizzare il messaggio "Rifiuto forzato", che indica che currencyservice è configurato per bloccare tutte le richieste in entrata.

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

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

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

65. Successivamente, consenti a frontend di accedere a currencyservice (ma non da altri servizi di backend). currency-allow-frontend.yamlを開き、その内容を調べます。次のルールを追加したことを確認してください。:

cat currency-allow-frontend.yaml

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

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

Qui, un source.principal (client) specifico viene inserito nella lista consentita per accedere al servizio currency.このsource.principalは、Kubernetesサービスアカウントによって定義されます。In questo caso, l'account di servizio da inserire nella lista consentita è l'account di servizio frontend dello spazio dei nomi frontend.

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

66. Aggiornaされたcurrencyポリシーをコピーします。

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

67. Aggiorna il push.

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

68. Attendi il completamento di Cloud Build.
69. Riapri il frontend dell'app Hipster Shop.Questa volta, non dovresti visualizzare errori nella home page.Questo perché il frontend ha esplicitamente autorizzato l'accesso al servizio corrente.
70. Dopodiché, aggiungi gli articoli al carrello e fai clic su "Effettua ordine" per completare il pagamento.今回は、currencyサービスから価格変換エラーが表示されるはずです。Questo perché hai inserito nella lista consentita solo il frontend, mentre checkoutservice non può ancora accedere a currencyservice.

71. Infine, aggiungi un'altra regola al criterio di autorizzazione currencyservice per consentire al servizio checkout di accedere al servizio valuta.Note that you have only opened access to the currency service from the two services frontend and checkout.Gli altri servizi di backend continueranno a essere bloccati.
72. currency-allow-frontend-checkout.yamlを開き、その内容を見てみます。ルールのリストは論理ORとして機能することに注意してください。currency serviceを受け入れるのは、これらの 2 つのサービス アカウントのいずれかを持つワークロードからのリクエストのみです。

cat currency-allow-frontend-checkout.yaml
 

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

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

73. Copia le policy di autorizzazione finali in k8s-repo.

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

74. Aggiorna il push.

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

75. Attendi il completamento di Cloud Build.
76. チェックアウトを実行してみてください。正常に動作するはずです。

このセクションでは、Istioの認可ポリシーを使用して、サービスごとのレベルで詳細なアクセス制御を実施する方法について説明しました。Nell'ambiente di produzione, crea un AuthorizationPolicy per ogni servizio e utilizza, ad esempio, il criterio allow-all per consentire a tutti i carichi di lavoro nello stesso spazio dei nomi di accedere l'uno all'altro.

11. Scalabilità dell'infrastruttura

Obiettivo: aggiungere nuove regioni, progetti e cluster e scalare l'infrastruttura

• infrastructureリポジトリをクローン
• 新しいリソースを作成するため、terraformファイルを更新
• Due subnet nella nuova regione (una per il progetto ops e una per il nuovo progetto)
• Nuovo cluster ops nella nuova regione (all'interno della nuova subnet)
• Nuovo piano di controllo Istio nella nuova regione
• 2 cluster di app per un nuovo progetto in una nuova regione
• infrastructureリポジトリにコミット
• セットアップを確認

プラットフォームをスケールするには、いくつかの方法があります。Puoi aggiungere altre risorse di calcolo aggiungendo nodi al cluster esistente.Puoi aggiungere altri cluster all'interno della regione.または、プラットフォームにさらにリージョンを追加できます。どのプラットフォームの側面を拡張するかは、要件によって異なります。Ad esempio, se hai cluster in tutte e tre le zone di una regione, probabilmente è sufficiente aggiungere nodi (o pool di nodi) ai cluster esistenti.Tuttavia, se hai cluster in due delle tre zone di una regione, l'aggiunta di un nuovo cluster nella terza zona ti offre scalabilità e un ulteriore dominio di errore, ovvero la nuova zona.Un altro motivo per aggiungere un nuovo cluster a una regione è che potrebbe essere necessario creare un cluster single-tenant per motivi normativi o di conformità, ad esempio un cluster di database che contiene informazioni PII.Man mano che la tua attività e i tuoi servizi si espandono, diventa inevitabile aggiungere nuove regioni per servire i clienti più da vicino.

現在のプラットフォームは、2つのリージョンと、リージョンごとに2つのゾーンのクラスターで構成されています。Lo scaling della piattaforma può essere considerato in due modi::

• Verticale: aggiunge più risorse di calcolo alla regione.Ciò avviene aggiungendo nodi (o pool di nodi) a un cluster esistente o aggiungendo un nuovo cluster all'interno della regione.Ciò avviene tramite il repository infrastructure.Il modo più semplice è aggiungere nodi al cluster esistente.Non è necessaria alcuna configurazione aggiuntiva.L'aggiunta di un nuovo cluster potrebbe richiedere l'aggiunta di subnet aggiuntive (e intervalli secondari), regole firewall appropriate, l'aggiunta del nuovo cluster al piano di controllo del service mesh ASM / Istio della regione e il deployment delle risorse dell'applicazione nel nuovo cluster.
• 水平: aggiunge un'altra regione.現在のプラットフォームは、リージョンのテンプレートを提供します。 È composto da un cluster ops regionale in cui risiedono i controlli ASM / Istio e da due (o più) cluster di applicazioni di zona in cui vengono部署 le risorse dell'applicazione.

Questo workshop include anche i passaggi per i casi d'uso verticali, in modo da scalare la piattaforma in modo "orizzontale".Per scalare la piattaforma aggiungendo orizzontalmente una nuova regione (r3) alla piattaforma, devi aggiungere le seguenti risorse::

1. 新しいオペレーションとアプリケーションクラスター用にリージョンr3の共有VPCにホストプロジェクトのサブネット
2. リージョン r3 のリージョナル ops クラスタ。ここには ASM / Istio コントロールプレーンが存在します。
3. 2つのゾーンにある2つのゾーンアプリケーションクラスター（リージョンr3）
4. k8s-repoへの更新:
5. ASM / Istioコントロールプレーンリソースをリージョンr3のopsクラスターにデプロイ
6. ASM / Istio共有コントロールプレーンリソースをリージョンr3のアプリクラスターにデプロイ
7. Non è necessario creare un nuovo progetto, ma le istruzioni del workshop mostrano come aggiungere un nuovo progetto, dev3, che copre lo scenario d'uso dell'aggiunta di un nuovo team alla piattaforma.

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

1. In Cloud Shell, vai a WORKDIR e clona il repository infrastructure.

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

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

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

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

3. Copia le risorse nuove e modificate dal ramo add-proj del workshop principale al repository infrastructure.

cp -r asm/infrastructure/apps/prod/app3 ./infra-repo/apps/prod/.
cp -r asm/infrastructure/cloudbuild.yaml ./infra-repo/cloudbuild.yaml
cp -r asm/infrastructure/network/prod/shared_vpc/main.tf ./infra-repo/network/prod/shared_vpc/main.tf
cp -r asm/infrastructure/network/prod/shared_vpc/variables.tf ./infra-repo/network/prod/shared_vpc/variables.tf
cp -r asm/infrastructure/ops/prod/cloudbuild/config/cloudbuild.tpl.yaml ./infra-repo/ops/prod/cloudbuild/config/cloudbuild.tpl.yaml
cp -r asm/infrastructure/ops/prod/cloudbuild/main.tf ./infra-repo/ops/prod/cloudbuild/main.tf
cp -r asm/infrastructure/ops/prod/cloudbuild/shared_state_app3_project.tf ./infra-repo/ops/prod/cloudbuild/shared_state_app3_project.tf
cp -r asm/infrastructure/ops/prod/cloudbuild/shared_state_app3_gke.tf ./infra-repo/ops/prod/cloudbuild/shared_state_app3_gke.tf
cp -r asm/infrastructure/ops/prod/k8s_repo/build_repo.sh ./infra-repo/ops/prod/k8s_repo/build_repo.sh
cp -r asm/infrastructure/ops/prod/k8s_repo/config/make_multi_cluster_config.sh ./infra-repo/ops/prod/k8s_repo/config/make_multi_cluster_config.sh
cp -r asm/infrastructure/ops/prod/k8s_repo/main.tf ./infra-repo/ops/prod/k8s_repo/main.tf
cp -r asm/infrastructure/ops/prod/k8s_repo/shared_state_app3_project.tf ./infra-repo/ops/prod/k8s_repo/shared_state_app3_project.tf
cp -r asm/infrastructure/ops/prod/k8s_repo/shared_state_app3_gke.tf ./infra-repo/ops/prod/k8s_repo/shared_state_app3_gke.tf
cp -r asm/infrastructure/ops/prod/ops_gke/main.tf ./infra-repo/ops/prod/ops_gke/main.tf
cp -r asm/infrastructure/ops/prod/ops_gke/outputs.tf ./infra-repo/ops/prod/ops_gke/outputs.tf
cp -r asm/infrastructure/ops/prod/ops_gke/variables.tf ./infra-repo/ops/prod/ops_gke/variables.tf
cp -r asm/infrastructure/ops/prod/ops_project/main.tf ./infra-repo/ops/prod/ops_project/main.tf
 

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

./asm/scripts/add-project.sh
 

5. Il commit attiva il repository infrastructure e l'infrastruttura viene implementata con le nuove risorse.Fai clic sull'output del seguente link per visualizzare l'avanzamento di Cloud Build, andando all'ultima build in alto.

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

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

Infrastructure L'ultimo passaggio di Cloud Build crea una nuova risorsa Kubernetes in k8s-repo.In questo modo, Cloud Build viene attivato in k8s-repo (all'interno del progetto ops).Le nuove risorse Kubernetes sono per i tre nuovi cluster aggiunti nel passaggio precedente. Le risorse del piano di controllo ASM / Istio e del piano di controllo condiviso vengono aggiunte al nuovo cluster utilizzando k8s-repo Cloud Build.

6. infrastructure Una volta terminato Cloud Build, fai clic sul seguente link di output per passare all'ultima esecuzione di k8s-repo di Cloud Build.

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

7. Esegui il seguente script per aggiungere il nuovo cluster ai file vars e kubeconfig.

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

8. KUBECONFIGModifica la variabile in modo che punti al nuovo file kubeconfig.

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

9. Elenca il contesto del cluster. Dovresti vedere otto cluster.

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

Verifica dell'installazione di Istio

10. Verifica che tutti i pod siano in esecuzione e che il job sia stato completato, quindi verifica che Istio sia installato nel nuovo cluster ops.

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

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

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

11. Istio が両方のdev3クラスタにインストールされていることを確認してください。 dev3Nel cluster vengono eseguiti solo Citadel, sidecar-injector e coredns.ops-3Condividi il piano di controllo Istio in esecuzione nel cluster.

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

Controlla il servizio di rilevamento del piano di controllo condiviso

12. (Facoltativo) Verifica che il secret sia stato eseguito il deployment in tutti i cluster ops dei sei cluster di applicazioni.

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. サーキットブレーカー

Obiettivo: implementare l'interruttore automatico nel servizio di spedizione

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

Ora che hai appreso le strategie di base di monitoraggio e risoluzione dei problemi per i servizi compatibili con Istio, vediamo come Istio migliora la resilienza dei servizi e riduce la quantità di risoluzione dei problemi che devi eseguire inizialmente.

L'architettura a microservizi comporta il rischio di errori a cascata, in cui l'errore di un servizio si propaga alle sue dipendenze e alle dipendenze delle dipendenze, con un potenziale impatto sugli utenti finali. Istio fornisce criteri di traffico del circuito di interruzione che consentono di isolare i servizi, impedendo ai servizi downstream (lato client) di attendere servizi non funzionanti e proteggendo i servizi upstream (lato server) da picchi improvvisi di traffico downstream.Nel complesso, l'utilizzo di un interruttore automatico consente di evitare che tutti i servizi non rispettino l'SLO perché un servizio di backend è bloccato.

Il pattern interruttore automatico prende il nome da un interruttore elettrico che"interrompe il circuito" quando passa troppa elettricità, proteggendo il dispositivo dal sovraccarico. Nella configurazione di Istio, questo è Envoy, che è un interruttore automatico e tiene traccia del numero di richieste in attesa per un servizio.In questo stato"chiuso" predefinito, le richieste vengono proxy da Envoy senza interruzioni.

Tuttavia, se il numero di richieste in attesa supera una soglia predefinita, l'interruttore automatico si attiva (si apre) ed Envoy restituisce immediatamente un errore.In questo modo, il server si guasta immediatamente per il client, impedendo al codice dell'applicazione server di ricevere le richieste del client in caso di sovraccarico.

Successivamente, dopo il timeout definito, Envoy passa allo stato half-open.Il server può riprendる la ricezione delle richieste in modo sperimentale.Se la richiesta può essere gestita correttamente, l'interruttore automatico si chiude di nuovo e le richieste al server iniziano a fluire di nuovo.

この 図は、Istioサーキットブレーカーパターンをまとめたものです。Il rettangolo blu rappresenta Envoy, il cerchio blu rappresenta il client e il cerchio bianco rappresenta il contenitore del server.

IstioのDestinationRulesを使用して、サーキットブレーカーポリシーを定義できます。In questa sezione, applichiamo i seguenti criteri per applicare un interruttore di circuito al servizio di spedizione::

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

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

Esistono due campi DestinationRule a cui prestare attenzione. **connectionPool**は、このサービスが許可する接続の数を定義します。 Il campo outlierDetection è il punto in cui configurare la modalità di determinazione della soglia di apertura del circuito di interruzione da parte di Envoy.Qui, ogni secondo (intervallo), Envoy conta il numero di errori ricevuti dal contenitore del server. **consecutiveErrors**しきい値を超えると、Envoyサーキットブレーカーが開き、productcatalog Podの100％が10秒間新しいクライアント要求から保護されます。 Se l'interruttore Envoy è aperto (attivo), il client riceve l'errore 503 (Service Unavailable).実際に見てみましょう。

77. Vai alla directory dei circuit breaker.

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

78. Aggiorna DestinationRule per shipping service in entrambi i cluster Ops。

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

79. Fortio負荷生成PodをDev1リージョンのGKE_1クラスターにコピーします。Questo è il pod client utilizzato per"attivare" il circuito di interruzione di 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
 

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

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

81. Attendi il completamento di Cloud Build.
82. Torna a Cloud Shell e utilizza il pod fortio per inviare traffico gRPC a shippingService con una connessione simultanea.(1000 richieste totali)connectionPoolIl circuito di protezione non si attiva perché non è stato ancora superato il limite.

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

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

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

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

83. Esegui di nuovo fortio, ma aumenta il numero di connessioni simultanee a 2, mantenendo costante il numero totale di richieste.L'interruttore automatico è scattato, quindi i due terzi delle richieste restituiscono un errore "Overflow".La norma definita consente una sola connessione simultanea a intervalli di 1 secondo.

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

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

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps

84. Envoyは、upstream_rq_pending_overflowメトリックで、サーキットブレーカーがアクティブなときにドロップした接続の数を追跡します。Trova questo pod in fortio.:

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending
 

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

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433

85. Rimuovi e pulisci le policy del circuit breaker da entrambe le regioni.

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
 

このセクションでは、サービスに単一のサーキットブレーカーポリシーを設定する方法を示しました。La best practice consiste nell'impostare un interruttore automatico per i servizi upstream (backend) che potrebbero bloccarsi. L'applicazione delle norme del circuito di interruzione Istio consente di isolare i microservizi, creare la tolleranza agli errori nell'architettura e ridurre il rischio di errori a cascata in condizioni di carico elevato.

13. Fault Injection

Obiettivo: (prima del push nell'ambiente di produzione) testare la resilienza del servizio di consigli causando intenzionalmente un ritardo

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

L'aggiunta di una policy di interruzione del circuito a un servizio è un modo per creare resilienza per i servizi in produzione.Tuttavia, l'interruttore automatico causa un errore (potenzialmente un errore dell'utente), il che non è l'ideale.Per questi errori, puoi adottare il test del caos nell'ambiente di staging per prevedere con maggiore precisione il modo in cui i servizi downstream rispondono quando il backend restituisce un errore.Il test del caos è un metodo per interrompere intenzionalmente i servizi al fine di analizzare i punti deboli all'interno di un sistema e migliorare la tolleranza agli errori.Puoi anche utilizzare i test del caos per identificare i modi per ridurre gli errori per gli utenti in caso di errori di backend, ad esempio visualizzando i risultati memorizzati nella cache nel frontend.

L'utilizzo di Istio per l'inserimento di errori è utile perché consente di aggiungere errori a livello di rete utilizzando l'immagine di rilascio operativa anziché modificare il codice sorgente.Nell'ambiente di produzione, puoi utilizzare strumenti di test del caos completi per testare la resilienza a livello di rete e di calcolo / Kubernetes.

Puoi utilizzare Istio per i test del caos applicando il campo"fault" a VirtualService. Istioは、2種類のフォールトをサポートしています。 Ritardo di errore (inserisce un timeout) e Errore di interruzione (inserisce un errore HTTP).In questo esempio, inseriamo un errore di ritardo di 5 secondi nel servizio di consigli.Tuttavia, questa volta utilizzeremo un interruttore automatico per eseguire il fail fast per questo servizio in stato di blocco, anziché consentire ai servizi downstream di subire un timeout completo.

86. Vai alla directory di inserimento di errori.

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

87. k8s_manifests / prod / istio-networking / app-recommendation-vs-fault.yamlを開いてその内容を検査します。 Tieni presente che Istio offre un'opzione per inserire errori in una percentuale di richieste.Qui inseriamo un timeout per tutte le richieste recommendationservice.

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

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

88. VirtualServiceをk8s_repoにコピーします。Per inserire errori a livello globale, configura entrambe le regioni.

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

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

89. Esegui il push delle modifiche.

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

90. Attendi il completamento di Cloud Build.
91. Nella sezione interruttore automatico, entra nel pod fortio di cui è stato eseguito il deployment e invia un po' di traffico a recommendationservice.

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

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

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

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

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

92. もう 1 つ、アクションで挿入したフォールトを確認する方法は、ウェブブラウザでフロントエンドを開き、任意のプロダクトをクリックすることです。Il caricamento della pagina del prodotto richiede altri 5 secondi per recuperare le informazioni sui consigli visualizzati nella parte inferiore della pagina.
93. Rimuovi il servizio di inserimento di errori da entrambi i cluster Ops per eseguire la pulizia.

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

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

94. Esegui il push delle modifiche.

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

14. Monitoraggio del control plane Istio

ASMは、Pilot、Mixer、Galley、Citadelの4つの重要なコントロールプレーンコンポーネントをインストールします。ciascuno dei quali invia metriche di monitoraggio correlate a Prometheus.ASMにはGrafanaダッシュボードが付属しており、オペレータはこの監視データを視覚化し、コントロールプレーンの健全性とパフォーマンスを評価できます。

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

95. Trasferisci le porte del servizio Grafana installato con Istio.

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

96. Apri Grafana dal browser.
97. Fai clic sull'icona "Anteprima web" nell'angolo in alto a destra della finestra Cloud Shell.
98. Fai clic su Anteprima sulla porta 3000 (nota: se la porta non è 3000, fai clic su Modifica porta e seleziona la porta 3000).
99. In questo modo, nel browser si apre una scheda con l'URL " BASE_URL/?orgId=1&authuser=0&environment_id=default".
100. 利用可能なダッシュボードを表示します
101. URLを次のように変更します" BASE_URL/dashboard"
102. Fare clic sulla cartella "istio" per visualizzare le dashboard disponibili.
103. いずれかのダッシュボードをクリックして、そのコンポーネントのパフォーマンスを表示します。次のセクションでは、各コンポーネントの重要な指標を見ていきます

Pilotの監視

Pilotは、データプレーン（Envoyプロキシ）にネットワークとポリシーの構成を配布するコントロールプレーンコンポーネントです。Pilot tendono a scalare in base al numero di workload e deployment, ma non necessariamente in base alla quantità di traffico verso questi workload.Un Pilot non normale può:

• Consuma più risorse del necessario (CPU e/o RAM)
• 更新された構成情報をEnvoyにプッシュする際に遅延が生じます

Nota: Anche se il pilot è inattivo o presenta ritardi, il workload continua a elaborare il traffico.

98. Apri" BASE_URL/dashboard/db/istio-pilot-dashboard" dal browser per visualizzare le metriche di Pilot.

Metriche di monitoraggio importanti

リソース使用量

Utilizza la pagina relativa a prestazioni e scalabilità di Istio come guida per il numero di utilizzi disponibili.Se utilizzi molte più risorse, contatta l'assistenza GCP.

Pilotのプッシュ情報

In questa sezione, monitora il push della configurazione di Pilot al proxy Envoy.

• Pilot Pushesは、プッシュされる設定のタイプを示します。
• ADS Monitoring mostra il numero di servizi virtuali, servizi ed endpoint connessi nel sistema.
• I cluster senza endpoint noti mostrano gli endpoint configurati, ma senza istanze in esecuzione (potrebbero indicare servizi esterni come *.googleapis.com).
• Pilot Errorsは、時間の経過とともに発生したエラーの数を示します。
• Conflitti mostra il numero di conflitti in cui la composizione degli ascoltatori è ambigua.

Se sono presenti errori o conflitti, la configurazione di uno o più servizi non è corretta o coerente.詳しくは、データプレーンのトラブルシューティングをご覧ください。

Envoy情報

このセクションには、コントロールプレーンに接続するEnvoyプロキシに関する情報が含まれています。Se si verificano ripetuti errori di connessione XDS, contatta l'assistenza GCP.

Monitoraggio di Mixer

Mixer è un componente che centralizza la telemetria dal proxy Envoy al backend di telemetria (in genere Prometheus, Stackdriver e così via).この容量では、データプレーンにはありません。 Vengono implementati come due job Kubernetes (chiamati Mixer) con due nomi di servizio diversi: istio-telemetry e istio-policy.

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

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

99. Apri" BASE_URL/dashboard/db/istio-mixer-dashboard" dal browser per visualizzare le metriche di Mixer.

Metriche di monitoraggio importanti

リソース使用量

Utilizza la pagina relativa a prestazioni e scalabilità di Istio come guida per il numero di utilizzi disponibili.Se utilizzi molte più risorse, contatta l'assistenza GCP.

Mixer概要

• **応答時間（Response Duration）**は重要な指標です。 I report sulla telemetria di Mixer non si trovano nel percorso dei dati, ma se queste latenze sono elevate, le prestazioni del proxy sidecar peggiorano sicuramente. Il 90° percentile dovrebbe essere nell'ordine di millisecondi a una sola cifra, mentre il 99° percentile dovrebbe essere inferiore a 100 millisecondi.

• Adapter Dispatch Duration indica la latenza che si verifica quando Mixer chiama un adattatore (viene utilizzato per inviare informazioni ai sistemi di telemetria e logging).ここでの待ち時間が長いと、メッシュのパフォーマンスに絶対的な影響があります。Come già detto, la latenza p90 deve essere inferiore a 10 millisecondi.

Galleyの監視

Galley è il componente che esegue la convalida, l'inserimento, l'elaborazione e la distribuzione della configurazione di Istio.設定をKubernetes APIサーバーからPilotに伝えます。 Come Pilot, tende a scalare in base al numero di servizi ed endpoint nel sistema.

100. Apri"BASE_URL/dashboard/db/istio-galley-dashboard" dal browser per visualizzare le metriche di Galley.

Metriche di monitoraggio importanti

リソース検証

La metrica più importante, che mostra il numero di risorse di vari tipi, ad esempio regole di destinazione, gateway e voci di servizio, che hanno superato o meno la convalida.

Client connessi

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

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

トラブルシューティング

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

Per esaminare i log di Pilot, esegui un comando come kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery.Sostituisci istio-pilot -... con l'identificatore del pod dell'istanza Pilot da risolvere.

Nei log dei risultati, cerca il messaggio Stato push.例えば:

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

Lo stato push indica i problemi riscontrati durante il tentativo di eseguire il push della configurazione nel proxy Envoy.In questo caso, vengono visualizzati diversi messaggi &quotCluster duplicati" che indicano destinazioni upstream duplicate.

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

設定エラーの発見

Per analizzare la configurazione utilizzando istioctl, esegui istioctl experimental analyze -k --context $ OPS_GKE_1.In questo modo, viene eseguita un'analisi della configurazione del sistema e vengono visualizzati i problemi insieme alle modifiche proposte.Per un elenco completo degli errori di configurazione che questo comando può rilevare, consulta la documentazione.

16. Pulizia

I passaggi successivi vengono eseguiti dall'amministratore dopo il completamento del workshop.

L'amministratore esegue lo script cleanup_workshop.sh per rimuovere le risorse create dallo script bootstrap_workshop.sh.スクリプトを実行するには、次の情報が必要です。

• 組織名 - 例. yourcompany.com
• Workshop ID - YYMMDD-NN**形式。**例. 200131-01
• Bucket GCS amministrativo: definito nello script di creazione del workshop

13. Apri Cloud Shell ed esegui tutte le azioni seguenti.下のリンクをクリックしてください。

CLOUD SHELL

14. Assicurati di aver eseguito l'accesso a gcloud con l'utente amministratore previsto.

gcloud config list
 

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

cd ${WORKDIR}/asm
 

16. Definisci il nome dell'organizzazione e l'ID workshop da eliminare.

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

17. Esegui lo script di pulizia nel seguente modo:

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