Anthos Service Mesh 研讨会：实验指南 - 日语

1. ALPHA WORKSHOP

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

2. 概要

架构图

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

内容安排

待办事项 - 更新为最终细分

前提条件

在继续学习本讲座之前，您需要完成以下事项：

GCP組織リソース
請求先アカウント ID（このアカウントの請求先アカウント管理者である必要があります）
组织级 Organization Administrator IAM 角色

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

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

使用 bootstrap_workshop.sh 脚本构建工作坊的初始环境。このスクリプトを使用して、自分用に単一の環境をセットアップ、また複数のユーザー用に複数の環境もセットアップできます。

ワークショップ作成スクリプトには、次の情報が必要です。

组织名称（例如，yourcompany.com）- これは、ワークショップ環境を作成する組織の名前です。
請求先アカウントID (例. 12345-12345-12345) - この ID は、ワークショップで作成されるすべてのリソースの請求先として使用されます。
工作坊编号（例如：01）- 2 位数字。これは、1日に複数のワークショップを行っており、それらを個別に管理したい場合に使用されます。工作坊编号也用于命名项目 ID。個別のワークショップ番号を使用すると、毎回一意のプロジェクトIDを取得しやすくなります。ワークショップ番号に加えて、現在の日付（YYMMDD形式）もプロジェクトIDに使用されます。日付とワークショップ番号の組み合わせにより、一意のプロジェクトIDが提供されます。
ユーザーの開始番号 (例. 1）- この番号は、ワークショップの最初のユーザー番号を表します。たとえば、10人のユーザー向けのワークショップを作成する場合、ユーザーの開始番号が1、ユーザーの終了番号が10となります
用户的结束编号（例如，10）- 此编号表示工作坊的最后一个用户编号。たとえば、10人のユーザー向けのワークショップを作成する場合、ユーザーの開始番号が1、ユーザーの終了番号が10となります。単一の環境（たとえば自分用）を構築している場合は、ユーザー開始番号と終了番号は同じです。これにより、単一の環境が構築されます。

管理用 GCS バケット (例. my-gcs-bucket-name) - このGCSバケットは、ワークショップ関連の情報を保存するために使用されます。この情報は cleanup_workshop.shワークショップを作成する管理者は、このバケットに対する読み取り/書き込み権限が必要です。

ワークショップ作成スクリプトは上記の値を使用し、 setup-terraform-admin-project.shスクリプトを呼び出すラッパースクリプトとして機能します。このスクリプトは、単一ユーザーのワークショップ環境を作成します。

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

このワークショップには2種類のユーザーがいます。1つめがこのワークショップのリソースを作成および削除する ADMIN_USER 、2番目は MY_USER で、ワークショップの手順を実行します。 MY_USER 只能访问自己的资源。ADMIN_USER 可以访问所有用户设置。自分でこのセットアップを作成する場合、ADMIN_USER とMY_USER は同じとなります。あなたが複数の学生のためにこのワークショップを作成するインストラクターである場合、ADMIN_USER と MY_USER は異なります。

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

オーナー - 組織内のすべてのプロジェクトに対するプロジェクトオーナーの権限。
文件夹管理员 - 组织内文件夹的创建和删除权限。すべてのユーザーは、プロジェクト内のすべてのリソースを含む単一のフォルダを取得します。
组织的管理员
プロジェクト作成者 - 組織内にプロジェクトを作成する権限。
プロジェクトの削除 - 組織内のプロジェクトを削除する権限。
Project IAM 管理者 - 組織内のすべてのプロジェクトに IAM のルールを作成する権限。

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

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

組織内のユーザー（自分以外）向けにこのワークショップを作成する場合は、MY_USER の特定のユーザー命名ルールに従う必要があります。 bootstrap_workshop.shスクリプトの実行中に、ユーザーの開始番号とユーザーの終了番号を指定します。これらの番号は、次のようにユーザー名を作成するために使用されます。:

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

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

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

これらのユーザー名には、setup_terraform_admin_project.shスクリプトで作成された特定のプロジェクトのプロジェクト所有者ロールが割り当てられます。使用工作区创建脚本时，您必须遵循此用户命名架构。詳しくは、G Suite で複数のユーザーを一度に追加する方法をご覧ください。

工作坊所需的工具

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

gcloud（版本 >= 270）
kubectl
sed（适用于 Cloud Shell / Linux 中的 sed，但不适用于 Mac OS）
git（最新バージョンを使用していることを確認してください）
sudo apt update
sudo apt install git
jq
envsubst
kustomize

工作坊设置（单用户设置）

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

Cloud Shell

確認します。

gcloud config list

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

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

ワークショップに使用する組織名、請求アカウントID、ワークショップ番号、管理用GCSバケットを定義します。上記のセクションでワークショップのセットアップに必要な権限を確認します。

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>

运行 bootstrap_workshop.sh 脚本。このスクリプトの完了には数分かかる場合があります。

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin

bootstrap_workshop.shスクリプトが完了すると、組織内のユーザーごとにGCPフォルダが作成されます。フォルダ内に、 terraform管理プロジェクトが作成されます。 Terraform 管理プロジェクトは、このワークショップに必要な残りの GCP リソースを作成するために使用されます。在 Terraform 管理的项目中启用所需的 API。使用 Cloud Build 应用 Terraform 计划。Cloud Build サービスアカウントに適切な IAM ロールを付与して、GCP でリソースを作成できるようにします。最後に、Google Cloud Storage（GCS）バケットでリモートバックエンドを構成して、すべての GCP リソースの Terraform 状態を保存します。

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

管理用 GCS バケットから workshop.txt ファイルを取得して、Terraform プロジェクト ID を取得します。

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

工作坊设置（多用户设置）

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

Cloud Shell

確認します。

gcloud config list

作成し、ワークショップリポジトリをクローンします。

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

ワークショップに使用する組織名、請求アカウントID、ワークショップ番号、管理用GCSバケットを定義します。上記のセクションでワークショップのセットアップに必要な権限を確認します。

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>

运行 bootstrap_workshop.sh 脚本。このスクリプトの完了には数分かかる場合があります。

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

管理用 GCS バケットから workshop.txt ファイルを取得して、Terraform プロジェクト ID を取得します。

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

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

所需时间：1 小时

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

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

用户信息的获取

ワークショップをセットアップする管理者は、ユーザー名とパスワード情報をユーザーに提供する必要があります。すべてのユーザーのプロジェクトには、user001@yourcompany.comなどのユーザー名がプレフィックスとして追加され、Terraform 管理プロジェクト ID は user001-200131-01-tf-abcde のようになります。各ユーザーは、自分のワークショップ環境にのみアクセスできます。

工作坊所需的工具

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

gcloud（版本 >= 270）
kubectl
sed（适用于 Cloud Shell / Linux 中的 sed，但不适用于 Mac OS）
git（最新バージョンを使用していることを確認してください）
sudo apt update
sudo apt install git
jq
envsubst
kustomize
pv

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

bootstrap_workshop.shスクリプトが完了すると、組織内のユーザーごとにGCPフォルダが作成されます。フォルダ内に、 terraform管理プロジェクトが作成されます。 Terraform 管理プロジェクトは、このワークショップに必要な残りの GCP リソースを作成するために使用されます。setup-terraform-admin-project.shスクリプトは、terraform管理プロジェクトで必要なAPIを有効にします。 Cloud Build は、Terraform plan を適用するために使用されます。使用脚本向 Cloud Build 服务账号授予适当的 IAM 角色，以便在 GCP 中创建资源。最後に、すべてのGCPリソースの Terraform stateを保存するために、リモートバックエンドが Google Cloud Storage（GCS）バケットに構成されます。

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

Cloud Shell

将 kustomize 安装到 $HOME/bin 中（如果尚未安装），并将 $HOME/bin 添加到 $PATH 中。

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

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

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

確認します。

gcloud config list

作成し、ワークショップリポジトリをクローンします。

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

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

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

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

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

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

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

Cloud Build ページが表示されたら、左側のナビゲーションから履歴リンクをクリックし、最新のビルドをクリックして、最初の Terraform の適用の詳細を表示します。以下资源将作为 Terraform 脚本的一部分创建。您还可以参考上面的架构图。

組織内の4つのGCPプロジェクト。各プロジェクトは、提供された請求アカウント ID に関連付けられています。
1つのプロジェクトは、共有VPCが設定されている network host projectです。このプロジェクトには、他のリソースは作成されません。
1つのプロジェクトは、IstioコントロールプレーンのGKEクラスタに使用される ops project です。
それ以外の2つのプロジェクトは、それぞれのサービスに取り組んでいる2つの異なる開発チームを表しています。
3 つの ops、dev1 および dev2 プロジェクトのそれぞれで、2 つの GKE クラスタが作成されます。
Kubernetesのマニフェストファイル用の6つのフォルダを含む k8s-repo という名前のCSRリポジトリが作成されます。每个 GKE 集群都有一个文件夹。このリポジトリは、GitOps形式でKubernetesのマニフェストをクラスタにデプロイするために使用されます。
Cloud Buildトリガーは、k8s-repo のmasterブランチへのコミットがあるたびに作成され、KubernetesのマニフェストをそれぞれのフォルダからGKEクラスタにデプロイします。

terraform 管理プロジェクトでビルドが完了すると、opsプロジェクトで別のビルドが開始されます。表示されたリンクをクリックして、ops 프로젝트의 Cloud Build 페이지를 엽니다.

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

确认安装

すべてのクラスタを管理するために kubeconfig ファイルを作成します。运行以下脚本。

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

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

KUBECONFIG 将变量更改为新的 kubeconfig 文件。

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

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

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

获取集群的上下文。6 つのクラスタが表示されるはずです。

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

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

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

验证 Istio 安装

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

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

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

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

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

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

確認してください。Istio が両方のdev1クラスタにインストールされていることを確認してください。dev1クラスタでは、Citadel、sidecar-injector、coredn のみが実行されています。共享在 ops-1 集群中运行的 Istio 控制平面。

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

確認してください。dev2dev2クラスタでは、Citadel、sidecar-injector、corednのみが実行されています。 ops-2クラスタで実行されているIstioのコントロールプレーンを共有します。

kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system

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

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

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

（省略可）确认 Secret 是否已部署。

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

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

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

このワークショップでは、すべてのGKEクラスタが作成される単一の共有VPCを使用します。クラスタ全体でサービスを検出するには、ops クラスタで Secret として作成された kubeconfig ファイル（各アプリケーションクラスタ用）を使用します。Pilot は、これらの Secret を使用して、アプリケーションクラスタの Kube API サーバー（上記の Secret を介して認証された）を照会することにより、サービスを検出します。両方のopsクラスタがkubeconfigで作成された Secret を使用して、すべてのアプリクラスタに対して認証できることがわかります。 Ops クラスタは、kubeconfig ファイルを Secret として使用してサービスを自動的に検出できます。これには、opsクラスター内のPilotが他のすべてのクラスターのKube APIサーバーにアクセスできることが必要です。 Pilot が Kube API サーバーに到達できない場合は、リモートサービスを ServiceEntries として手動で追加します。ServiceEntriesは、サービスレジストリのDNSエントリと考えることができます。 ServiceEntriesは、完全修飾DNS名（ FQDN）と到達可能なIPアドレスを使用してサービスを定義します。詳しくは、Istio マルチクラスタのドキュメントをご覧ください。

5. infrastructure リポジトリの説明

基础架构 Cloud Build

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

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

Cloud Buildは、infrastructure リポジトリへのコミットがあるたびにトリガーされます。インフラストラクチャに対して行われた変更は、 Infrastructure as Code（IaC）として保存され、リポジトリにコミットされます。工作坊的状态始终保存在此代码库中。

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

Infrastructure リポジトリは、ワークショップのGCPインフラストラクチャリソースをセットアップします。フォルダとサブフォルダに構造化されています。リポジトリ内のベースフォルダは、特定のGCPリソースを所有するチームを表します。フォルダの次のレイヤーは、チームの特定の環境（たとえば、dev、stage、prod）を表します。環境内のフォルダの次のレイヤーは、特定のリソース（たとえば、host_project、gke_clusters など）を表します。必要なスクリプトと Terraform ファイルは、リソースフォルダ内に存在します。

在此工作坊中，您将看到以下 4 种类型的团队：:

infrastructure - クラウドを管理するインフラストラクチャチームを表します。他のすべてのチームのGCPリソースを作成する責任があります。リソースにはTerraform管理プロジェクトを使用します。インフラストラクチャリポジトリ自体は、Terraform 状態ファイル（以下で説明）にあります。これらのリソースは、ワークショップ作成プロセス中にbashスクリプトによって作成されます（詳細については、モジュール0-インフラストラクチャセットアップ - 管理者用ワークフローを参照）。
network - ネットワークチームを表します。负责 VPC 和网络资源。彼らは次のGCPリソースを所有しています。
host project - 共有VPCのホストプロジェクトを表します。
shared VPC - 共有VPC、サブネット、セカンダリIP範囲、ルーティング情報、ファイアウォールルールを表します。
ops - 运营 / DevOps 团队。彼らは次のリソースを所有しています。
ops project - すべての運用リソースのプロジェクトを表します。
gke clusters - リージョンごとのops GKEクラスタ。また、Istio コントロールプレーンは、各 ops GKE クラスタにインストールされます。
k8s-repo - すべてのGKEクラスタのGKEマニフェストを含むCSRリポジトリ。
apps - アプリケーションチームを表します。このワークショップは、app1 と app2 の2つのチームをシミュレーションします。彼らは次のリソースを所有しています。
app projects - すべてのアプリチームが個別のプロジェクトセットを持ちます。これにより、プロジェクトごとに請求とIAMを制御できます。
gke clusters - これらのクラスタは、アプリケーションコンテナ/ Pod が実行されるアプリケーション用クラスタです。
gce instances - 必要に応じて、GCE インスタンスで実行されるアプリケーションがある場合に使用します。このワークショップでは、app1 に、アプリケーションの一部が実行されるいくつかのGCEインスタンスがあります。

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

提供程序、状态、输出 - 后端、共享状态

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

すべてのリソースには、リソースの tfstate ファイルの場所を定義する backend.tf ファイルが含まれています。이 backend.tf 파일은 스크립트(scripts/setup_terraform_admin_project에 있음)를 사용하여 템플릿(templates/backend.tf_tmpl에 있음)에서 생성되며, 각 리소스 폴더에 배치됩니다.GCSバケットがファイル置き場として使われます。 GCSバケットフォルダ名はリソース名と一致します。すべてのリソースは、Terraform 管理プロジェクトにあります。

具有相互依赖的值的资源包括 output.tf 文件。必要な出力値は、その特定のリソースのバックエンドで定義された tfstate ファイルに保存されます。たとえば、プロジェクトにGKEクラスタを作成するには、プロジェクトIDを知る必要があります。プロジェクトIDは、GKEクラスタリソースの terraform_remote_state データソースを介して使用できる tfstate ファイルに output.tf を介して出力されます。

shared_stateファイルは、リソースのtfstateファイルを指す terraform_remote_state データソースです。shared_state_[resource_name].tf ファイルは、他のリソースからの出力を必要とするリソースフォルダに存在します。たとえば、ops_gke リソースフォルダには、ops_project および shared_vpc リソースの shared_state ファイルがあります。これは、opsプロジェクトでGKEクラスタを作成するにはプロジェクトIDとVPCの詳細が必要だからです。 shared_stateファイルは、スクリプト（scripts/setup_terraform_admin_project にある）を使用してテンプレート（templates/shared_state.tf_tmpl にある）から生成されます。所有资源的 shared_state 文件都位于 gcp/[environment]/shared_states 文件夹中。必要な shared_state ファイルは、それぞれのリソースフォルダでシンボリックリンクされています。すべての shared_state ファイルを 1 つのフォルダに配置し、それらを適切なリソースフォルダに sym リンクすると、すべての状態ファイルを 1 か所で簡単に管理できます。

変数

すべてのリソースの値は環境変数として保存されます。これらの変数は、terraform adminプロジェクトのGCSバケットにある vars.sh というファイルに（エクスポートステートメントとして）保存されます。これには、組織ID、請求先アカウント、プロジェクトID、GKEクラスタの詳細などが含まれます。您可以从任意设备下载并获取 vars.sh，然后获取设置值。

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

K8s リポジトリの説明

k8s_repo は、terraform 管理プロジェクトにある CSR リポジトリ（インフラストラクチャリポジトリとは別）で、GKE マニフェストをすべての GKE クラスタに保存および適用するために使用されます。k8s_repo由基础架构 Cloud Build 创建（有关详情，请参阅上一部分）。最初のインフラストラクチャCloud Buildプロセス中に、合計6つのGKEクラスタが作成されます。k8s_repo には、6 つのフォルダが作成されます。各フォルダ（GKE クラスタ名と一致する名前）は、それぞれのリソースマニフェストファイルを含む GKE クラスタに対応しています。インフラストラクチャの構築と同様に、Cloud Build は k8s_repo を使用して Kubernetes マニフェストをすべての GKE クラスタに適用するために使用されます。Cloud Buildは、k8s_repoリポジトリへのコミットがあるたびにトリガーされます。インフラストラクチャと同様に、すべての Kubernetes マニフェストはコードとして k8s_repo リポジトリに保存され、各 GKE クラスタの状態は常にそれぞれのフォルダに保存されます。

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

プロジェクト、GKE クラスタ、名前空間

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

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

GCPリソースを構築するインフラストラクチャチームは、Terraform管理プロジェクトを使用します。彼らは、CSRリポジトリ（infrastructure と呼ばれる）のコードとしてインフラストラクチャを管理し、GCSバケットのGCPで構築されたリソースに関するすべてのTerraform state情報を保存します。これらは、CSRリポジトリおよびTerraform state のGCSバケットへのアクセスを制御します。
共有VPCを構築するネットワークチームは、hostプロジェクトを使用します。このプロジェクトには、VPC、サブネット、ルート、ファイアウォールルールが含まれています。共有VPCを使用すると、GCPリソースのネットワークを一元管理できます。所有项目都使用网络中的这个单个共享 VPC。
GKE クラスタと ASM / Istio コントロールプレーンを構築する運用 / プラットフォームチームは、opsプロジェクトを使用します。管理 GKE クラスタとサービスメッシュのライフサイクル。これらは、クラスターを強化し、Kubernetesプラットフォームの復元力とスケールを管理する責任があります。このワークショップでは、リソースをKubernetesにデプロイするGitOpsメソッドを使用します。 CSRリポジトリ（k8s_repo と呼ばれる）がopsプロジェクトに存在します。
最後に、アプリケーションを構築するdev1およびdev2チーム（2つの開発チームを表す）は、独自のdev1およびdev2プロジェクトを使用します。これらは、顧客に提供するアプリケーションとサービスです。これらは、運用チームが管理するプラットフォーム上に構築されます。リソース（deployment、service など）は k8s_repo にプッシュされ、適切なクラスタにデプロイされます。このワークショップは CI / CD のベストプラクティスとツールに焦点を合わせていないことに注意してください。 Cloud Build を使用して、GKE クラスターへの Kubernetes リソースのデプロイを自動化します。実際の運用シナリオでは、適切な CI / CD ソリューションを使用して、アプリケーションを GKE クラスタにデプロイします。

此研讨会有 2 种 GKE 集群。

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

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

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

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

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

Kubernetes マニフェストと k8s_repo

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

6 个聚类名称如下：

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

k8s_repo には、これらのクラスターに対応するフォルダがあります。これらのフォルダに配置されたマニフェストは、対応する GKE クラスタに適用されます。为了便于管理，每个集群的清单都放置在子文件夹（集群的主文件夹内）中。このワークショップでは、 Kustomizeを使用して、デプロイされるリソースを追跡します。如需了解详情，请参阅 Kustomize 的官方文档。

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

目標: Hipster Shop アプリを apps クラスタにデプロイする

k8s-repoリポジトリをクローン
将 Hipster ショップのマニフェストをすべてのアプリクラスタにコピー
Hipster Shop 앱을 위해 Services 를 ops 클러스터에 생성
グローバルの接続性をテストするためloadgeneratorをopsクラスターにセットアップ
確認 Hipster ショップアプリへの安全な接続

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

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

在 WORKDIR 下创建一个用于存放代码库的空文件夹。:

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

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

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

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

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

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

Hipster Shop マニフェストをすべてのクラスタのソースリポジトリにコピーします。

cd ${WORKDIR}/asm
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/.
cp -r k8s_manifests/prod/app/* ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/.

Hipster ショップは、ops クラスタではなく、アプリケーションクラスタにデプロイされます。ops クラスタは、ASM / Istio コントロールプレーンでのみ使用されます。ops クラスタから Hipster Shop のデプロイメント、PodSecurityPolicy および RBAC マニフェストを削除します。

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

1 つの dev クラスタ以外のすべてから cartservice デプロイメント、RBAC および PodSecurityPolicy を削除します。Hipster ショップはマルチクラスター展開用に構築されたものではなく、4 つのデプロイメントすべてを実行し続けることで、アクセスしたデプロイメントに応じてカート情報に矛盾が生じてしまいます。

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

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

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

最初の開発クラスタのみで、cartservice デプロイメント、RBAC、および PodSecurityPolicy を kustomization.yaml に追加します。

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

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

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

替换 RBAC 清单中的 PROJECT_ID。

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

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

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

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

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

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

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

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

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

替换两个 ops 集群的 loadgenerator 清单中的 ops 项目 ID。

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

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

将两个 ops 集群的 loadgenerator 资源添加到 kustomization.yaml。

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

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

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

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

等待推出完成。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全球负载均衡

これで、4 つのアプリクラスタすべてに Hipster Shop アプリが展開されました。これらのクラスターは、2つのリージョンと4つのゾーンにあります。クライアントは、frontendサービスにアクセスしてHipsterショップアプリにアクセスできます。frontendサービスは、4つのアプリクラスターすべてで実行されます。 Google Cloud Load Balancer（ GCLB）を使用して、frontendサービスの4つのインスタンスすべてにクライアントトラフィックを取得します。

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

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

GKE Autoneg コントローラー

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

Cloud Endpoints とマネージド証明書を使用した安全な Ingress

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

如需访问 Hipster 商店，请点击以下命令输出的链接：

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

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

验证全球负载均衡

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

取得 Hipster ショップ GCLB が作成されている ops プロジェクトの GCLB > Monitoring リンク。

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

以下に示すように、Backend ドロップダウンメニューから All backends を istio-ingressgateway に変更します。

両方のistio-ingressgatewaysに向かうトラフィックを確認してください。

每个istio-ingressgateway都会创建 3 个 NEG。ops クラスタはリージョナルクラスタであるため、リージョン内の各ゾーンに対して 1 つの NEG が作成されます。ただし、istio-ingressgatewayPodは、リージョンごとに単一のゾーンで実行されます。ここでは、istio-ingressgatewayPodに向かうトラフィックが表示されます。

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

7. Stackdriver による可观测性

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

istio-telemetryリソースをインストール
创建/更新 Istio 服务的信息中心
表示コンテナのログ
Stackdriver で分散トレース情報を表示

Istio の主要な機能の 1 つは、組み込みの可観測性（"o11y"）です。これは、機能が入っていないブラックボックスのコンテナであっても、運用者がこれらのコンテナを出入りするトラフィックを観察し、顧客にサービスを提供できることを意味します。この観測は、指標、ログ、およびトレースといういくつかの異なる方法の形を取ります。

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

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

cd ${WORKDIR}/k8s-repo

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

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

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

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

等待推出完成。

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

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

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

输出中应显示名为“stackdriver”的处理程序：

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s

確認します。このコマンドから出力されるリンクをクリックします。:

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

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

在指标探索器中，点击 [记录类型]，然后输入“istio”。「Kubernetes Pod」リソースタイプには「Server Request Count」などのオプションがあります。これは、指標がメッシュから Stackdriver に流れていることを示しています。

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

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

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

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

接下来，添加预先构建的指标信息中心。直接使用信息中心 API。如果您手动生成 API 调用，通常不会这样做。なんらかの自動化システムの一部であるか、Web UIでダッシュボードを手動で作成します。これにより、すぐに使い始められます。:

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

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

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

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

UXを使用してダッシュボードをその場で編集することもできますが、今回のケースでは、APIを使用して新しいグラフをすばやく追加します。そのためには、ダッシュボードの最新バージョンを取得し、編集内容を適用してから、HTTP PATCHメソッドを使用してプッシュする必要があります。

您可以使用监控 API 获取现有信息中心。追加したばかりのダッシュボードを取得します。:

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

新しいグラフの追加：（50th％ile latency）：[ API reference] これで、新しいグラフウィジェットをコードでダッシュボードに追加できます。この変更は、ピアによってレビューされ、バージョン管理システムにチェックインされます。追加するウィジェットは、50％の待機時間（latencyの中央値）を示しています。

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

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

更新了现有的 servicesdashboard：

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

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

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

执行简单的日志分析。

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

以下はログエントリの例（この例では Envoy プロキシの accesslog）です（整形済み）。:

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

此处显示日志。:

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

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

ここでは、各サンプルアプリサービスのプロキシ設定をプッシュする Istio コントロールプレーンを確認できます。“CDS”“LDS”“RDS”分别表示不同的 Envoy API（详细信息）。

Istio のログだけでなく、コンテナログ、インフラストラクチャログ、他の GCP サービスログもすべて同じインターフェースで見つけることができます。以下に、GKE のログクエリの例を示します。ログビューアでは、ログから指標を作成することもできます（たとえば、「文字列に一致するすべてのエラーをカウントする」）。ダッシュボードで、またはアラートの一部として使用できます。您还可以将日志流式传输到 BigQuery 等其他分析工具。

以下に、Hipster ショップのいくつかのサンプルフィルタを示します。

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

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

確認分散トレーシング。

由于使用了分布式系统，因此需要使用新的调试工具，即分布式跟踪。このツールを使用すると、サービスがどのように相互作用しているのかに関する統計情報（下の図の異常な低速イベントの検出など）を見つけたり、生のサンプルトレースを見て、実際に何が起こっているのかを調べたりすることができます。

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

ドットをクリックすると、その特定のリクエストの詳細なウォーターフォールビューを見つけることができます。此功能可用于查找特定请求的原始详细信息（而不仅仅是统计汇总信息），对于了解服务之间的互动至关重要，尤其是在查找服务之间罕见但不良的互动时。

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

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

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

工具的屏幕截图示例：

公开集群中的可观测性工具。

Prometheus と Grafana は、ops クラスタの Istio コントロールプレーンの一部としてデプロイされるオープンソースの可観測性ツールです。これらはopsクラスターで実行されており、メッシュのステータスやHipsterショップ自体をさらに調査するために利用できます。

これらのツールを表示するには、Cloud Shell から次のコマンドを実行するだけです（見るべきものがあまり無いため、Prometheus はスキップします）。

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

次に、公開されたサービス（3000）を Cloud Shell ウェブプレビュータブで開きます。

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

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

8. 相互 TLS 身份验证

目標: 設定マイクロサービス間の安全な接続（身份验证）

メッシュ全体で mTLS を有効にする
使用调查日志验证 mTLS

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

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

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

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

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

  spec:
    peers:
    - mtls:
        mode: PERMISSIVE

mTLSをオンにします。 Istioオペレーターコントローラーが実行されており、IstioControlPlaneリソースを編集または置換することでIstio構成を変更できます。コントローラーは変更を検出し、それに応じてIstioインストール状態を更新することで対応します。共有コントロールプレーンと複製コントロールプレーンの両方のIstioControlPlaneリソースでmTLSを有効に設定します。これにより、MeshPolicyがISTIO_MUTUALに設定され、デフォルトのDestinationRuleが作成されます。

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

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

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

等待推出完成。

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

mTLS 的运行验证

在 ops 集群中再次检查 MeshPolicy。注. 非暗号化トラフィックは許可されず、mTLS トラフィックのみを許可します。

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

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

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

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

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

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

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

此外，您还可以通过日志确认从 HTTP 到 HTTPS 的迁移。UIのログからこの特定のフィールドを公開するには、ログエントリを1つクリックしてから、表示したいフィールドの値をクリックします。この場合、「プロトコル」の横にある「http」をクリックします。:

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

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

TODO(smcghee)

9. Canary 部署

目標: 推出前端服务的新版本

Frontend-v2(次のプロダクションバージョン)サービスを1リージョンにロールアウト
使用DestinationRules和VirtualServices逐步将流量转移到frontend-v2
k8s-repoに複数の提交，并检查 GitOps 部署流水线

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

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

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

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

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

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

実行 repo_setup.sh スクリプト以将基准清单复制到 k8s-repo。

cd $CANARY_DIR
./repo-setup.sh

以下清单会被复制：:

frontend-v2 部署
frontend-v1 パッチ ("v1"ラベルと"/ version"エンドポイントを持つコンテナイメージを含める)
respy は、HTTP 応答の分布を書き出し、カナリアデプロイメントをリアルタイムで視覚化するのに役立つ小さな Pod です。
前端 Istio DestinationRule - 根据“版本”部署标签将前端 Kubernetes 服务拆分为两个子集：v1 和 v2
前端 Istio VirtualService - 将 100% 的流量路由到前端 v1。これにより、Kubernetesサービスのデフォルトのラウンドロビン動作が上書きされ、すべてのDev1リージョントラフィックの50％がfrontend v2に直ちに送信されます。

将更改提交到 k8s_repo。：

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

在 Ops1 项目的控制台中前往 Cloud Build。Cloud Build パイプラインが完了するまで待ってから、両方の DEV1 クラスタの frontend 名前空間で Pod を取得します。您应该会看到以下内容。:

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

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

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

別のCloud Shellセッションを開きます。 DEV1_GKE_1で実行されている新しいRespy Podに入ります。

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

watch 命令を実行して、前端服务的 HTTP 响应的分布を確認します。すべてのトラフィックが、新しい VirtualService で定義された frontend v1 デプロイメントに向かうことがわかります。

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

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

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

前のCloud Shellセッションに戻り、Dev2リージョンでカナリアパイプラインを実行します。提供一个脚本，用于更新 VirtualService 的前端 v2 流量的百分比（将权重更新为 20%、50%、80% 和 100%）。各更新の間で、スクリプトは Cloud Build パイプラインが完了するのを待ちます。运行 Dev1 区域的 Canary 部署脚本。注-このスクリプトの完了には約10分かかります。

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

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

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

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

frontend v2 의 Dev1 롤아웃이 완료되면 스크립트의 마지막에 성공 메시지가 표시됩니다.
```
出力結果（コピーしないでください） 
```

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

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

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

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

在 Dev1 上终止 respy Pod。接下来，进入在 Dev2 区域中运行的 respy Pod。

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

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

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

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

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

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

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

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

Dev2のRespy Podから、Dev2 Podからのトラフィックがfrontend v1からv2に徐々に移動するのを見てください。脚本完成后，您会看到以下内容：:

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

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

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

10. 授权政策

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

AuthorizationPolicyを作成し、マイクロサービスへのアクセスを拒否する
使用 AuthorizationPolicy 允许访问特定微服务

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

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

首先，将 AuthorizationPolicy 部署到所有四个 Dev 集群，以阻止对 currencyservice 的所有访问，并在前端触发错误。次に、frontendサービスのみがcurrencyserviceにアクセスできるようにします。

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

cd $AUTHZ_DIR

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

cat currency-deny-all.yaml

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

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

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

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

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

推送更改。

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

尝试在浏览器中访问 Hipster Shop 应用的前端：

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

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

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

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

从 currency 服务的边车代理获取 RBAC（授权）日志。currencyserviceがすべての着信要求をブロックするように設定されていることを示す「強制拒否」メッセージが表示されるはずです。

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

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

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

接下来，确保前端可以访问 currencyservice（但不能从其他后端服务访问）。currency-allow-frontend.yamlを開き、その内容を調べます。请确认您已添加以下规则：:

cat currency-allow-frontend.yaml

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

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

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

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

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

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

推送更新。

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

Cloud Buildの完了を待ちます。
再次打开 Hipster Shop 应用的前端。今回は、ホームページにエラーが表示されないはずです。これは、前端明确允许前端访问当前服务。
次に、カートにアイテムを追加し、"place order"をクリックして、チェックアウトを実行してください。今回は、currencyサービスから価格変換エラーが表示されるはずです。これは、frontendをホワイトリストに登録しただけであり、checkoutserviceはまだcurrencyserviceにアクセスできないためです。

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

cat currency-allow-frontend-checkout.yaml

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

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

将最终授权政策复制到 k8s-repo。

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

推送更新。

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

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

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

11. 基础设施扩缩

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

infrastructureリポジトリをクローン
更新了 terraform 文件以创建新资源
新しいリージョンに 2 つのサブネット（1 つは ops プロジェクト用、もう 1 つは新しいプロジェクト用）
新しいリージョンに新しいopsクラスター (新しいサブネット内に)
新しいリージョンに新しいIstioコントロールプレーン
新リージョンの新しいプロジェクトに 2 つの apps クラスター
infrastructureリポジトリにコミット
確認設定

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

現在のプラットフォームは、2 つのリージョンと、リージョンごとに 2 つのゾーンのクラスタで構成されています。平台扩展可以从以下两个方面考虑：:

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

このワークショップでは、垂直ユースケースのステップも含まれるため、プラットフォームを"水平"にスケーリングします。如需通过在平台中水平添加新区域 (r3) 来扩缩平台，您需要添加以下资源：:

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

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

在 Cloud Shell 中，前往 WORKDIR 并克隆 infrastructure 代码库。

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

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

从 asm（主研讨会）代码库中检出 add-proj 分支。add-projブランチには、このセクションの変更内容が含まれています。

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

将主工作区的add-proj分支中的新资源和已更改的资源复制到infrastructure代码库。

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

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

./asm/scripts/add-project.sh

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

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

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

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

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

运行以下脚本，将新集群添加到 vars 和 kubeconfig 文件中。

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

KUBECONFIG更改变量，使其指向新的 kubeconfig 文件。

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

列出集群上下文。8 つのクラスタが表示されるはずです。

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

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

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

验证 Istio 安装

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

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

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

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

確認してください。Istio が両方のdev3クラスタにインストールされていることを確認してください。dev3クラスタで実行されるのは、Citadel、sidecar-injector、coredn のみです。ops-3共享在集群中运行的 Istio 控制平面。

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

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

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

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

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

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

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

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

12. 断路器

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

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

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

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

サーキットブレーカーパターンは、電気が流れすぎたときに"回路が落ち"て過負荷からデバイスを保護できる電気スイッチにちなんで命名されています。 Istio のセットアップでは、これは Envoy がサーキットブレーカーであり、サービスに対する保留中のリクエストの数を追跡することを意味します。在这种默认的“关闭”状态下，Envoy 会不间断地代理请求。

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

接下来，在定义的超时时间过后，Envoy 会进入半打开状态。サーバーは試用的な方法でリクエストの受信を再開できます。リクエストに正常に応答できる場合、サーキットブレーカーは再び閉じ、サーバーへのリクエストが開始され、再び流れ始めます。

この図は、Istioサーキットブレーカーパターンをまとめたものです。蓝色长方形表示 Envoy，蓝色圆圈表示客户端，白色圆圈表示服务器容器。

IstioのDestinationRulesを使用して、サーキットブレーカーポリシーを定義できます。このセクションでは、次のポリシーを適用して、shippingサービスにサーキットブレーカーを適用します。:

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

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

ここで注意すべき2つのDestinationRuleフィールドがあります。 **connectionPool**は、このサービスが許可する接続の数を定義します。 outlierDetection フィールドは、Envoy がサーキットブレーカーを開くしきい値を決定する方法を構成する場所です。ここでは、毎秒（間隔）、Envoy はサーバーコンテナから受信したエラーの数をカウントします。**consecutiveErrors**しきい値を超えると、Envoyサーキットブレーカーが開き、productcatalog Podの100％が10秒間新しいクライアント要求から保護されます。 Envoyサーキットブレーカーが開いている（アクティブになっている）場合、クライアントは503（Service Unavailable）エラーを受け取ります。実際に見てみましょう。

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

更新两个 Ops 集群中的 shipping service 的 DestinationRule。

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

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

Fortio負荷生成PodをDev1リージョンのGKE_1クラスターにコピーします。これは、shippingserviceのサーキットブレーカーを"作動"させるために使用するクライアントPodです。

cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml

提交更改。

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

Cloud Buildの完了を待ちます。
Cloud Shellに戻り、fortio Podを使用して、gRPCトラフィックを1つの同時接続でshippingServiceに送信します。（合計 1,000 件のリクエスト）connectionPool設定をまだ超えていないため、サーキットブレーカーは作動しません。

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

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

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

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

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

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

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

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

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

Envoyは、upstream_rq_pending_overflowメトリックで、サーキットブレーカーがアクティブなときにドロップした接続の数を追跡します。これをfortio Podで見つけましょう。:

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

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

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

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

kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master

このセクションでは、サービスに単一のサーキットブレーカーポリシーを設定する方法を示しました。最佳实践是为可能挂起的上游（后端）服务设置断路器。Istio サーキットブレーカーポリシーを適用することで、マイクロサービスを分離し、アーキテクチャにフォールトトレランスを構築し、高負荷下で連鎖障害が発生するリスクを軽減できます。

13. 故障注入（Fault Injection）

目标：通过有意引入延迟（在推送到生产环境之前），测试 recommendation 服务的恢复能力

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

サービスにサーキットブレーカーポリシーを追加することは、運用中のサービスに対する回復力を構築する1つの方法です。不过，断路器会带来故障（可能是用户错误），这并不理想。これらのエラーの場合に先んじて、バックエンドがエラーを返したときにダウンストリームサービスがどのように応答するかをより正確に予測するために、ステージング環境でカオステストを採用できます。カオステストは、システム内の弱点を分析し、フォールトトレランスを向上させるために、意図的にサービスを中断する方法です。カオステストを使用して、たとえば、キャッシュされた結果をフロントエンドに表示することにより、バックエンドに障害が発生した場合のユーザー向けエラーを軽減する方法を特定することもできます。

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

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

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

k8s_manifests / prod / istio-networking / app-recommendation-vs-fault.yamlを開いてその内容を検査します。请注意，Istio 提供了用于将故障插入到一定百分比的请求中的选项。ここでは、すべてのrecommendationserviceリクエストにタイムアウトを挿入します。

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

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

将 VirtualService 复制到 k8s_repo。グローバルに障害を挿入するため両方のリージョンに設定を行います。

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

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

推送更改。

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

Cloud Buildの完了を待ちます。
サーキットブレーカーセクションでデプロイされたfortio Podに入り、いくつかのトラフィックをrecommendationserviceに送信します。

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

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

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

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

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

アクションで挿入したフォールトを確認する別の方法は、ウェブブラウザでフロントエンドを開き、任意のプロダクトをクリックすることです。製品ページは、ページの下部に表示されるおすすめ情報を取得するため、ロードにさらに 5 秒かかります。
両方の Ops クラスタからフォールトインジェクションサービスを削除してクリーンアップします。

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

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

推送更改。

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

14. Istio 控制平面的监控

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

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

转发与 Istio 一起安装的 Grafana 服务。

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

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

Pilotの監視

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

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

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

ブラウザから" BASE_URL/dashboard/db/istio-pilot-dashboard"を開き、Pilot の指標を表示します。

重要的监控指标

资源使用量

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

Pilotのプッシュ情報

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

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

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

Envoy情報

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

Mixer のモニタリング

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

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

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

ブラウザから" BASE_URL/dashboard/db/istio-mixer-dashboard"を開き、Mixer の指標を表示します。

重要的监控指标

资源使用量

Mixer 概览

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

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

Galleyの監視

Galleyは、Istioの構成の検証、取り込み、処理、および配布を行うコンポーネントです。設定をKubernetes APIサーバーからPilotに伝えます。与 Pilot 类似，它会根据系统中的服务和端点数量进行扩缩。

在浏览器中打开“BASE_URL/dashboard/db/istio-galley-dashboard”，以查看 Galley 的指标。

重要的监控指标

リソース検証

検証に合格または失敗した Destination ルール、ゲートウェイ、サービスエントリなど、さまざまなタイプのリソースの数を示す、最も重要な指標です。

接続されたクライアント

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

15. Istio 故障排除

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

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

如需检查 Pilot 日志，请运行以下命令：kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery。実際には、istio-pilot -...をトラブルシューティングする Pilot インスタンスの Pod 識別子に置き換えます。

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

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

プッシュステータスは、構成をEnvoyプロキシにプッシュしようとしたときに発生した問題を示します。この場合、重複したアップストリーム宛先を示すいくつかの「クラスターの重複」メッセージが表示されています。

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

設定エラーの発見

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

16. 清理

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

组织名称 - 例如：yourcompany.com
工作坊 ID - YYMMDD-NN**形式。**例. 200131-01
管理用GCSバケット - ワークショップ作成スクリプトで定義

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

Cloud Shell

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

gcloud config list

移動到 asm 文件夹。

cd ${WORKDIR}/asm

定義要删除的组织名称和研讨会 ID。

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

按如下方式运行清理脚本：

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

Anthos Service Mesh 研讨会：实验指南 - 日语 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

1. ALPHA WORKSHOP

2. 概要

架构图

内容安排

前提条件

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

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

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

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

工作坊所需的工具

工作坊设置（单用户设置）

工作坊设置（多用户设置）

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

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

用户信息的获取

工作坊所需的工具

确认安装

验证 Istio 安装

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

5. infrastructure リポジトリの説明

基础架构 Cloud Build

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

提供程序、状态、输出 - 后端、共享状态

変数

K8s リポジトリの説明

プロジェクト、GKE クラスタ、名前空間

Kubernetes マニフェストと k8s_repo

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

目標: Hipster Shop アプリを apps クラスタにデプロイする

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

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

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

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

全球负载均衡

GKE Autoneg コントローラー

Cloud Endpoints とマネージド証明書を使用した安全な Ingress

验证全球负载均衡

7. Stackdriver による可观测性

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

8. 相互 TLS 身份验证

目標: 設定マイクロサービス間の安全な接続（身份验证）

mTLS 的运行验证

9. Canary 部署

目標: 推出前端服务的新版本

10. 授权政策

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

11. 基础设施扩缩

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

验证 Istio 安装

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

12. 断路器

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

13. 故障注入（Fault Injection）

目标：通过有意引入延迟（在推送到生产环境之前），测试 recommendation 服务的恢复能力

14. Istio 控制平面的监控

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

Pilotの監視

重要的监控指标

Mixer のモニタリング

重要的监控指标

Galleyの監視

重要的监控指标

15. Istio 故障排除

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

設定エラーの発見

16. 清理

Anthos Service Mesh 研讨会：实验指南 - 日语

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

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