このページは Cloud Translation API によって翻訳されました。

Anthos Service Mesh ワークショップ: ラボガイド - 日本語

1. アルファ版ワークショップ

2. 概要

アーキテクチャ図

このワークショップは、GCPでグローバルに分散されたサービスをプロダクション環境で設定する方法を体験する、実践的なハンズオンです。最適なテクノロジーテクノロジーは、最適な形で Google Kubernetes Engine（GKE）と、新しくなったこと、可観測性、最適なオペレーションを実現する Istioサービスメッシュです。このワークショップで使用されるすべてのプラクティスとツールは、実際に本番で使用するものと同じです。

アジェンダ

TODO - 最終的な内訳で更新する

前提条件

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

GCP 組織のリソース
請求先アカウントの請求先アカウント ID（請求先アカウント管理者である必要があります）
組織レベルと比較しての組織管理者 IAM ロール

3. セットアップのセットアップ - 管理者用構成

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

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

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

特定（例:yourcompany.com）- これはワークショップ環境にある名前です。
請求先アカウント ID（例:12345-12345-12345）- この ID がワークショップで全てのアンケートに含まれている場合は、これらの 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 組織によっては誤っている:

オーナー - 最終的にすべてのプロジェクトに対するプロジェクトのオーナーであるため。
フォルダ管理者 - フォルダを作成して管理するための機能。すべてのユーザーは、プロジェクト内のすべてのリソースを含む単一のフォルダを取得します。
既存の管理者
プロジェクト管理者 - 組織内にプロジェクトを作成するポリシー。
プロジェクトの削除 - 変更プロジェクトを削除する権限。
プロジェクト 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スクリプトで作成された特定のプロジェクトのプロジェクト所有者ロールが割り当てられます。ワークショップ作成スクリプトを使用するときは、このユーザー命名スキーマに従う必要があります。詳細は GSuiteで複数のユーザーを一度に追加する方法を参照してください。

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

このワークショップは Cloud Shell から初期化しようとします。下記に示すツール群がワークショップで必要となります。

gcloud（バージョン 270 以上）
kubectl
sed（Mac OS ではなく Cloud Shell / Linux の sed で）
git（普段使っているかどうかを確認する）
sudo apt update
sudo apt install git
jq
envsubst
kustomize

ワークショップのセットアップ（複合ユーザーセットアップ）

Cloud Shell を維持し、以降の Cloud Shell を使用する必要があります。Cloud Shell は持っています。

Cloud Shell

移行する管理者ユーザーの場合は gcloud の設定が必要です。

gcloud config list

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

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

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

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

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

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>

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

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

bootstrap_workshop.shスクリプトが完了すると、組織内のユーザーごとにGCPフォルダが作成されます。フォルダ内に、Terraform 管理プロジェクトに関する情報があります。Terraform 管理プロジェクトは、このワークショップに必要な残りの GCP リソースを作成しています。terraform管理プロジェクトで必要なAPIを有効にします。Cloud Build を使用して Terraform プランを作成します。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 の設定が必要です。

gcloud config list

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

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

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

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

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

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>

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

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

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

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

4. セットアップのセットアップ - ユーザーに関するお問い合わせ

設定: 1 時間

目標: 一括と Istio のインストール

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

ユーザー情報の取得

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

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

このワークショップは Cloud Shell から初期化しようとします。下記に示すツール群がワークショップで必要となります。

gcloud（バージョン 270 以上）
kubectl
sed（Mac OS ではなく Cloud Shell / Linux の sed で）
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 プランを利用しています。これにより、Cloud Build サービスアカウントに適切な IAM を使用し、GCP でリソースを作成できるようになります。最終的には、GCP のすべての Terraform 状態を活用するため、サービスリモートが Google Cloud Storage（GCS）を使用するように構成されます。

Cloud Shell を維持し、以降の Cloud Shell を使用する必要があります。Cloud Shell は持っています。

Cloud Shell

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

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

pv を設定することで、セッション上でアプリを作成するときに .customize_environment の設定を確認できます。

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

お客様のアカウントは gcloud で提供してください。

gcloud config list

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

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

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

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

ワークショップに関するすべてのリソースに関する情報は、Terraform 管理の共有 GCS バケット "vars.sh" の設定で一時的に保管されています。terraform管理プロジェクトのvars.shファイルを取得します。

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

セットアップするには、Terraform 管理を有効にして Cloud Build をインポートします。

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

Cloud Build ページに掲載されているため、リソースから履歴リンクツール、最新のビルドをクリックして、Terraform に関する詳しい情報をご確認ください。次のリソースは、Terraformスクリプトの一部として作成されます。上記のアーキテクチャ図も参考になります。

異なる 4 つの GCP プロジェクト。各プロジェクトは提供された請求アカウントIDに紐付いています。
1 つのプロジェクトは、共有 VPC の network host project です。このプロジェクトには、他のリソースは作成されません。
1 つのプロジェクトは、Istio コントロールプレーンの GKE を使用する ops project です。
考慮される 2 つのプロジェクトは、複数の定期的な予算 2 つのカテゴリでは利用できません。
3 つの ops、dev1、および dev2すべてで、2 つの GKE に関するクラスターの概要が表示されます。
Kubernetes のファイルに関する 6 つのフォルダが存在する k8s-repoCSR に関して、GKEクラスタごとに1つのフォルダがあります。このリポジトリは、GitOps形式でKubernetesのマニフェストをクラスタにデプロイするために使用されます。
Cloud Build トリガーは、k8s-repo の master Team へのアカウントにあるため、Kubernetes のフォルダにあるフォルダから GKE クラスタを使用しています。

Terraform 管理ダッシュボードを構築するための、ops 自体の別のインフラストラクチャも含む。このために、opsCloud Build を使ってみる。

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

インストールの確認

すべてのクラスタを管理するために kubeconfig を設定する必要があります。下記のスクリプトを実行します。

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

Compute Engine は新しい kubeconfig kubemesh であるため、gke から取得されます。

KUBECONFIG 変数を新しい kubeconfig に置き換える。

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

var.sh を .bashrc にして、Cloud Shell がどれであっても常に使用できます。

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

クラスタのコンテキストを取得します。6 つのクラスタを確認できれば理想的です。

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

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

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

Istio のインストールの確認

すべての Pod を使用して、このグループを用意して、Istio がクラスターを構成するようにする必要があります。

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

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

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

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

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

Istioが両方のdev1クラスターにインストールされていることを確認してください。dev1クラスターでは、Citadel、sidecar-injector、corednのみが実行されています。ops-1 クラスターにある Istio の管理コントロールが必要です。

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

Istioが両方のdev2クラスタにインストールされていることを確認してください。dev2クラスタでは、Citadel、sidecar-injector、corednのみが実行されています。ops-2 クラスタを構成する Istio のコントロールプレーンが含まれています。

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

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

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

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

モニタリング、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 を使用して、アプリの Secret を使用して Kube API を提供しています（上記の Secret を使って認証された）を、サービスプロバイダとして行います。クラスタのクラスタが kubeconfig を取得する Secret を使用して、クラスタに対して認証できるレベルです。Opsクラスターは、Secretとしてkubeconfigファイルを使用してサービスを自動的に検出できます。このクラスタには、オペレーションクラスター内のパイロットがクラスターの Kube API の設定に関することが必要です。Pilot が Kube API のサービスを開始する際に、リモートサービスの ServiceEntries としてサービスを開始します。ServiceEntriesは、サービスレジストリのDNSエントリと考えることができます。ServiceEntries は、DNS 名（FQDN）とアクセス可能な IP アドレスを使用してサービスを整理します。詳しくは、Istio マルチクラスタドキュメントをご覧ください。

5. インフラストラクチャに関する説明

インフラストラクチャ 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 を使用します。各データセットで使用するのは、インストール用の場所です（詳細は参照）。そのため、一時的に、1 つ単位で、通常使用する方法が使用されるようになります（つまり、独自のリソースインポート前に GCP プロジェクトが構築されます）。適用される、cloudbuild.yaml に関する情報。

Cloud Build は、infrastructureまでに提供された一定の期間にトリガーされます。これらの目的を達成するために必要な場合は、Infrastructure as Code（IaC）を維持しつつ、存続させる必要があります。ワークショップの状態は常にこのリポジトリに保存されます。

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

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

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

インフラストラクチャ - クラウドに移行するチームを活用。他のすべてのチームのGCPリソースを作成する責任があります。リソースにはTerraform管理プロジェクトを使用します。単独で作成したものは、Terraform の状態（以下で説明）があります。これらの必要に応じて、ワークショップ作成プロセス中に bash スクリプトによって使用する（モジュール 0- セットアップのセットアップ - 管理者用を参照してください）。
network - ネットワークチームでは、VPCとネットワークリソースを担当します。彼らは次のGCPリソースを所有しています。
host project - 共有 VPC のホストプロジェクトを担当します。
shared VPC - 共有 VPC、この方法、複数の IP 範囲、ルート情報、これらのルールが必要になることもあります。
ops - 運用 / DevOps チームを使用します。彼らは次のリソースを所有しています。
ops project - すべてのオペレーションリソースのためのプロジェクトが使用されています。
gke clusters - いつでも運用する 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 の出力.tf から出力されます。

shared_state を使用するため、便利な tf ファイルの状態は 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 の設定、それらのフォルダの場所ーでシンボリックリンクがあります。すべての共有状態の共有 1 つのフォルダーに配置し、それらのデータを保持するフォルダーに ym リンクすると、すべての状態のコピーを 1 か所にまとめることができます。

変数

すべてのリソースの値は環境変数として保存されます。これらの変数は、Terraform 管理者権限を持つ 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_repoKubernetes プロダクトをすべての GKE クラスタに設定する必要があります。Cloud Build は、k8s_repoまでに一定の間隔でトリガーされます。インフラストラクチャと同様に、すべてのKubernetesマニフェストはコードとしてk8s_repoリポジトリに保存され、各GKEクラスターの状態は常にそれぞれのフォルダーに保存されます。

最初に導入するイニシアチブ、k8s_repoキャンペーン、Istio がすべてのクラスターに提示されます

Kubernetes クラスタ、GKE クラスタ、

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

このワークショップには、それぞれに固有のプロジェクトがある 5 つのメーカーに出てきます。

GCPリソースを構築するインフラストラクチャチームは、Terraform管理プロジェクトを使用します。生徒は、CSR（infrastructure という名称）というコンセプトとして、GCS の GCP でアクセスできるリソースに関するすべての Terraform の状態情報を使用しています。必要な CSR、および Terraform の状態の GCS を利用可能にするには、
共有VPCを構築するネットワークチームは、hostプロジェクトを使用します。このプロジェクトには、VPC、サブネット、ルート、ファイアウォールルールが含まれています。共有VPCを使用すると、GCPリソースのネットワークを一元管理できます。すべてのプロジェクトは、ネットワークにこの単一の共有VPCを使用しています。
GKE クラスターと ASM / Istio コントロールのオプションops / platform チームは、opsプロジェクトにあります。GKEクラスターとサービスメッシュのライフサイクルを管理します。これらは、クラスターを強化し、Kubernetesプラットフォームの復元力とスケールを管理する責任があります。このワークショップでは、リソースをKubernetesにデプロイするGitOpsメソッドを使用します。CSR に含まれる（k8s_repo の名称）が ops に使用する名前です。
最終的に、アプリケーションの作成dev1 および dev2 チーム（2 つのサービスを表す）は、独自のdev1およびdev2プロジェクトでご利用いただけます。これらは、顧客に提供するアプリケーションとサービスです。これらは、運用チームが管理するプラットフォーム上に構築されます。リソース（デプロイメント、サービスなど）は k8s_repo として使用され、適切なクラスターに展開されます。このワークショップは、CI / CD のテスト機能とツールに焦点を合わせていないわけではありません。Cloud Build を使用して、GKE クラスターへの Kubernetes への追加を追加します。通常の運用方法として、適切な CI / CD を使用することで、使用する GKE クラスターに展開します。

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

運用ツールー - 運用プラットフォーム DevOps ツールを利用可能。このワークショップでは、ASM / Istio コントロールプレーンサービスポリシーを使用するとします。
アプリケーション（アプリ）を処理するー - カテゴリがアプリケーションで使用されることがあります。このワークショップでは、Hipster ショップアプリを使って説明します。

ops / Admin Tool アプリケーションエディタからクラスターから分離する場合、各最適な使用方法を紹介します。2 つのタイプのクラスターは、固有の使用チーム / 製品に関する異なるプロジェクトにも使用されています。これにより、IAM権限も管理しやすくなります。

全部で 6 つの GKE クラスターがでてきます。ops プロジェクトでは、2 つのリージョナルオペレーションクラスターに属する。ASM / Istio コントロールプレーンは、使用するオペレーションクラスターに有効になります。各opsクラスターは異なるリージョンにあります。さらに、4 つのゾーンクラスターがあります。これらは個別のプロジェクトに作成されます。このワークショップは、それぞれに固有のプロジェクトを持つ 2 つのサービスをシミュレーションします。各プロジェクトには 2 つのクラスターを使用している必要があります。アプリクラスターは、異なるゾーンのゾーンクラスターです。4 つのアプリクラスターは、2 つのサービスと 4 つのエリアの両方があります。これにより、リージョンおよびゾーンの冗長性が得られます。

このワークショップの機能アプリケーションには、Hipster ショップで、4 つのアプリクラスターすべてに展開されます。各マイクロサービスは、すべてのアプリクラスターの個別の名前空間に存在します。Hipster ショップアプリのデプロイ（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 のゾーンにあるアプリクラスター
gke-2-apps-r1b-prod - ロケーション 1 のゾーンにあるアプリクラスター
gke-3-apps-r2a-prod - ルーティン 2 のゾーンにあるアプリクラスター
gke-4-apps-r2b-prod - ルーティン 2 のゾーンにあるアプリクラスター

k8s_repo には、複数のクラスターに対応するフォルダがあります。これらのフォルダーに配置されたマニフェストは、対応するGKEクラスターに適用されます。各クラスターのマニフェストは、管理を容易にするためにサブフォルダー（クラスターのメインフォルダー内）に配置されます。このワークショップでは、Kustomize を使用して、ご利用いただけるようになるよう設定を行います。詳細については、Kustomizeの公式ドキュメントを参照してください。

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

目標: Hipster ショップアプリのアプリを紹介する

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

ops でアプリのバージョンを複製する

最初の Terraform を取得するには、k8s-repo オペレーションアカウントがすでに作成済みであることが必要です。

WORKDIR の保存容量は、ご利用の際に空いている必要があります。:

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

git を介して認証情報としてリモートの実行時に、マスターブランチを pull します。

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

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

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

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

Hipster Shop のすべてのクラスターのソースに基づいて計算されます。

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

Hipsterショップは、opsクラスターではなく、アプリケーションクラスターに展開されます。ops クラスターは、ASM / Istio コントロールが正常に選択された状態です。opsクラスターからHipsterショップのdeployment、PodSecurityPolicyおよびRBACマニフェストを削除します。

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

1 つの開発クラスター以外のすべてから cartservice Deployment、RBAC および PodSecurityPolicy を削除します。また、Hipster Shop は、特定のーー機能を備えた使用できるものではなく、4 つのデプロイすべてを継続的に実施しながら、デプロイによってカート情報に行われます。

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

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

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

最初の開発クラスターでのみ、cartservice Deployment、RBAC、PodSecurityPolicy を kustomization.yaml として設定します。

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

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

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

RBAC の PROJECT_ID を置き換えます。

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

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

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

Config Connector は、さまざまなクラスターの 1 つの料金でご利用いただけます。

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

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 Shop を使用すると、Google Cloud Load Balancer（GCLB）を使用して無効にできます。GCLBはクライアントトラフィック（frontend宛て）を受信し、サービスの最も近いインスタンスに送信します。loadgeneratorをグループオペレーションクラスターに配置すると、オペレーションクラスターの中で使用する 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

カート Namespace の Pod が、最初の開発環境クラスターの状態の状態（実行中）である。

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

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

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

Hipster ショップへのアクセス

グローバル負荷分散

これまでに、4 つのアプリクラスターすべてに Hipster Shop アプリがダウンロードされました。これらのクラスターは、2 つのデバイスと 4 つのオプションの両方が用意されています。クライアントは、frontendサービスにアクセスしてHipsterショップアプリにアクセスできます。frontend サービス、4 つのアプリクラスターすべてを利用する。Google Cloud Load Balancer（GCLB）を使用して、frontendサービス 4 つの主要なすべてにお客様が登録する価値があります。

Istio Ingress Ingress は、クラスター内でクラスターが割り当てられており、複数のエリアにまたがるクラスターに対してリージョナルが導入される設定になっています。GCLB は、グローバルの初期セットアップバックエンドとして 2 つの Istio の入力入口（2 つの ops クラスターの実装）を用意します。Istio Ingress Ingress は、GCLB からクライアントを使用して作成され、クライアントの初期ライブラリーに保存されたサポート Pod です。

また、Istio Ingress スタートをクラスターに実装し、GCLB が導入された使用方法について注意を喚起します。

GKE AutoNEg クラスター

Istio Ingress ゲートウェイ Kubernetes Service は、ネットワークエンドポイントグループ（NEG）を使用して、GCLB のプロモーションとして提供します。NEG では、GCLB 用のコンテナネイティブの負荷分散を使用できます。NEG は Kubernetes アプリ専用のを使用して作成することで、NEG コントローラーに独自のように設定できます。Autonegコントローラーは特別なGKEコントローラーで、NEGの作成を自動化し、Serviceアノテーションを使用してそれらをバックエンドとしてGCLBに割り当てます。Istio イングレスを始めると、Istio コントロールプレーンが Terraform Cloud Build のイニシャルモードで展開されます。GCLB および Autoneg ブランドでは、Terraform のイニシャル Cloud Build をご利用いただけます。

Cloud Endpoints とサービスを使用して取得したパス Ingress

GCP サービス証明書は、frontendGCLB 経由でご利用いただくための認証を確立していません。GCLBは、グローバルfrontendサービスにマネージド証明書を使用し、SSLはGCLBで終端されます。このワークショップでは、証明書証明書として Cloud Endpoints を使用できます。または、frontendのドメインとDNS名を使用して、GCPマネージド証明書を作成できます。

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

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

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

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

アプリケーション開発の一環として、GCLB ヒップスターショップの Cloud Endpoints リンクへテスト方法としてテストクラスターに、ロード生成を作成して拡張しました。GCLB が導入済みのし、Istio Ingress デバイスが登録されている必要があります。

Hipster ShopGCLB に掲載されているオペレーション 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"

以下では、バックエンドからすべてのバックエンドから istio-ingressgateway が返されます。

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

istio-ingressgatewayそれぞれ 3 つの NEG に関する情報。ops クラスターはリージョナルクラスターを使用することで、各種エリアごとに 1 つの NEG を把握します。ただし、istio-ingressgatewayPodは、リージョンごとに単一のゾーンで実行されます。ここでは、istio-ingressgatewayPodに向かうトラフィックが表示されます。

このサービスによって生成することで、クラスタオペレーションズーを最適化し、2 つの場所から試してみましょう。オペレーションクラスターの割り当て 1 で生成された負荷は、サービス 2 のistio-ingressgateway設定です。非オペレーションクラスタークラスタ 2 で生成された負荷は、システム 1 のistio-ingressgateway設定です。

7. Stackdriverによる可観測性

目標: Istio のテレメトリ環境で Stackdriver に連携し、輸送します

istio-telemetryリソースの保護
Istio Services の作成/更新
コンテナのログを表示
Stackdriverで分散トレーシング情報を表示

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

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

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

cd ${WORKDIR}/k8s-repo

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

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

k8s-repo にお願いします。

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

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

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

Istio→Stackdriverの連携を確認します。Stackdriver Handler CRD には、

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

出力には、stackdriver のハンドラが必要となる必要があります。

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s

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

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

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

メトリクスエクスプローラーで、[レコードタイプ]をクリックし、「istio」と入力します。「Kubernetes Pod」には「Server Request Count」などが該当します。これは、メトリックがメッシュからStackdriverに流れていることを示しています。

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

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

メトリックが Stackdriver APM システムにあるため、それらの設定を行う必要があります。メトリクスの 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 レイテンシ）：[API リファレンス] に関しては、新しいグラフウィジェットを一括して設定します。この変更は、ピアによってレビューされ、バージョン管理システムにチェックインされます。ウィジェットウィジェットは、50% の待機時間（レイテンシと値）の値で構成されます。

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

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

既存のservicesdashboardを更新します:

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

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

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

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

Istio は、すべてのインメッシュネットワークによって構造化ログに関して、それらの構成を 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}"

ツールの例:

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

Prometheu と Grafana は、ops クラスターの Istio コントロールコントロールプレーンに展開される、可観測性の観点から設計されています。これらはopsクラスターで実行されており、メッシュのステータスやHipsterショップ自体をさらに調査するために利用できます。

これらのツールを使用する場合は、Cloud Shell から適切に設定すること（見るべきものがあまり無いため、Prometheus はスキップします）:

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

以降、サービス（3000）を Cloud Shell の [Web プレビュー] タブで開きます。

https://ssh.cloud.google.com/devshell/proxy?authuser=0&port=3000&environment_id=default
（必ず Cloud Shell と同じ Chrome の URL を使用してください）。

Grafanaは、Stackdriverのカスタムダッシュボードに似たメトリックダッシュボードシステムです。Istio には、特定の Istio このグループを適切に構成するためのメトリック、および Isito Control Plane 独自の機能を使用して、その情報を用意しています。

8. 相互TLS認証

目標: 複数の異なるパスワードを使用して認証（認証）します

メッシュコントロール mTLS の調整
調査ログファイル mTLS を確認

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

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

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

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

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

  spec:
    peers:
    - mtls:
        mode: PERMISSIVE

mTLS の要件。Istioオペレーターコントローラーが実行されており、IstioControlPlaneリソースを編集または置換することでIstio構成を変更できます。コントローラーは変更を検出し、それに応じてIstioインストール状態を更新することで対応します。共有コントロールプレーンと複製コントロールプレーンの両方の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. Qwiklabs の使用

目標: フロントエンドサービスをパッケージ化する

Frontend-v2（次のプロダクションバージョン）ペイロード 1 キューはすでに暗号化されています
DestinationRulesとVirtualServicesのときに注文する際にfrontend-v2使用するときに、
k8s-repoに複数のコミットを行い、GitOpsデプロイパイプラインを確認

カナリアデプロイメントは、新しいサービスの段階的なロールアウト手法です。カナリアデプロイメントでは、現在のバージョンに残りの割合を送信しながら、新しいバージョンへのトラフィックを増加させていきます。パターンパターンは、集計パターンに従ってこれらのパターンを特定し、データの「ゴールデンシグナル」（アルゴリズム、アラート率、飽和）を取り入れます。その後、サービスを停止してから、組織を整理するためのさまざまな方法を新しい「v2」方法でセットアップできるようになりました。

オブザーバビリティ、Cloud Build および Istio の使用ポリシーを使用して、frontendこれらの要件を満たすために最適なオプションを用意します。

まず、**DEV1 のサービス（us-west1）**でカスタマイズした表現を使用し、そのカスタマイズクラスターでフロントエンド v2 が必要になります。今後、**DEV2 のサービス（us-central）**でその言語を使い、そのユースケースクラスターに v2 が必要になります。そうした設定の状態を適宜に実行し、すべての方法で有効にして実行できるように、不適切な設定または v2 アプリ自体のバグによって引き起こされるようになる必要があります。

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

Cloud Shell から、アップデート用のコマンドを発行します。:

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

リポジトリのセットアップには、リポジトリ用のリポジトリが必要です。

cd $CANARY_DIR
./repo-setup.sh

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

frontend-v2 Deployment
frontend-v1 パッチ（"v1"ラベルと"/ version"エンドポイントを含むコンテナイメージを考慮）
respy、HTTP レスポンスの分散を書き出して、キャンペーンの位置情報を取得するのに適した小さな Pod。
frontend Istio DestinationRule - "バージョン"の検索ラベルに基づいて、frontend Kubernetes Service2 つなど、v1 と v2 のデータを使用します。
frontend Istio VirtualService - 最小 100% を frontend v1 にルーティングします。現在、Kubernetes サービスの使用に関してロビンの動作が重視されていますが、すべての Dev1 の設定が 50% がフロントエンド 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 クラスタのフロントエンド名前空間で Pod です。以下が表示されるはずです。:

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

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

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

別の Cloud Shell セッションが必要な場合は、DEV1_GKE_1 を別の Respy Pod に入ります。

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

watchコマンドを実行して、frontendサービスのHTTP応答の分布を確認します。すべて、新しい VirtualService に対応するフロントエンド v1 Deployment があります。

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

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

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

以前の Cloud Shell セッションを再開し、Dev2 に合わせて、こうした機能を利用します。VirtualService のフロントエンド v2 に関する入力欄に記入します（これらの情報を 20%、50%、80%、100% にご用意ください）。今回の更新内容、スクリプトは Cloud Build を優先するのに使用します。Dev1 を使用した場合にこれまでに使用したとき。注-収益には約 10 分かかります。

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

このサービスを導入すると、respy リストに登録されている 2 番目の Cloud Shell セッションに基づいて、グループごとに分類されます。場合、20% の応答:

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

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

frontend v2 の Dev1 の実装については、必須ではなく最初から成功するように設定されています。
```
出力結果（コピーしないでください） 
```

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

そして、Dev1 Pod からすべてのフロントエンドフロントエンド v2 に向いていいます。:
```
出力結果（コピーしないでください） 
```

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

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

Dev1 で respy Pod を作成します。次に、Dev2 の履歴にある 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 がフロントエンド 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 を利用できるようにします。

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

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

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

cd $AUTHZ_DIR

currency-deny-all.yamlの内容を見てみます。このポリシーは、Deploymentラベルセレクターを使用して、currencyserviceへのアクセスを制限します。specフィールドを使用できない場合- このため、アプローチが複数のアクセスを拒否を行うこともできます。

cat currency-deny-all.yaml

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

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

指定したグループオペレーションクラスターの通貨を処理するために 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 ショップアプリのフロントエンドに取り組む:

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

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

currencyサービスがこのAuthorizationPolicyをどのように適用しているかを調べてみましょう。最初に、最初に、ウェルカムとは一緒に記録される、通貨 Pod の Envoy の設定で、これらに関して適切なログを作成する必要があります。

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

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

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

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

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

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

cat currency-allow-frontend.yaml

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

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

ここで、特定のsource.principal（クライアント）をお知らせして、通貨サービスを引き続き利用しています。このsource.principalは、Kubernetesサービスアカウントによって定義されます。ここでは、コミュニティを行うサービスで使用されている、frontend Namespace のフロントエンドサービスアカウントです。

注: Istio AuthorizationPolicies で Kubernetes サービスアカウントを使用する、モジュール 1 で旅行するように、クラスター上で相互に TLS を確立します。これは、サービスアカウントの資格情報がリクエストにマウントされるようにするためです。

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

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

更新をプッシュします。

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

Cloud Build を選択して追加する。
Hipsterショップアプリのfrontendを再度開きます。今回は、ホームページにエラーが表示されないはずです。これは、frontendが現在のサービスにアクセスすることを明示的に許可しているためです。
次に、カートにアイテムを追加し、「注文」機能を使用して、カートに商品を追加してください。今回は、currencyサービスから価格変換エラーが表示されるはずです。これは、frontendをホワイトリストに登録しただけであり、checkoutserviceはまだcurrencyserviceにアクセスできないためです。

最後に、別のルールを currencyservice AuthorizationPolicy と比較した場合は、購入手続きによって通貨サービスを使用します。frontend と checkout の2 つのサービスからの通貨サービスは、同時に起動されています。他のバックエンドサービスは引き続きブロックされます。
currency-allow-frontend-checkout.yamlを開き、その内容を見てみます。ルールのリストは論理ORとして機能することに注意してください。通貨サービスは、機能する 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 つがオペレーションプロジェクト用、もう一つが目的用）
新しい新しいクラスタクラスタ（新しいプロセス内で）
新しいリージョンに新しいIstioコントロールプレーン
新しい候補を作成するために 2 つのアプリクラスター
infrastructure メンバーシップに
セットアップを確認

プラットフォームをスケールするには、いくつかの方法があります。既存のクラスターにノードを追加することにより、さらに計算リソースを追加できます。リージョン内にさらにクラスターを追加できます。または、プラットフォームにさらにリージョンを追加できます。プラットフォームのどの側面を拡張するかの決定は、要件に依存します。適用される、3 つのゾーンすべてにクラスターがある場合、既存のクラスターに古いもの（または記載）を含めることは可能です。ただし、1 つの選択された 3 つのゾーンのうち 2 つにグループーを設定することで、3 番目のゾーンのアラート数が多く、データと設定のフォールトドメイン（パッケージ化、新しいゾーン）に入れられます。新しいクラスターに関してもう 1 つの要件、規制またはコンプライアンスのために（PCI、PII 情報クラスタークラスターなど）のために、最適化されたクラスターの設計に基づいていることがあります。ビジネスとサービスが拡大するにつれて、クライアントにより近くでサービスを提供するために新しいリージョンを追加することが避けられなくなります。

現在のプラットフォームは、2 つのどのゾーンと、特定の 2 つのゾーンのクラスターが必要です。この新しいプロダクトは、次の 2 つのことで考えることができます。:

- 目標に合わせて目標をクリアする必要があります。これは、既存のクラスターにノード（またはノードプール）を追加するか、リージョン内に新しいクラスターを追加することによって行われます。これは、infrastructureリポジトリを介して行われます。最も簡単な方法は、既存のクラスターにノードを追加することです。追加の構成は必要ありません。新しいクラスターを利用して、そこからデータを使い（および代替ーレンジを適切に切り替える代わりに、新しいクラスターのシステム ASM / Istio サービスメッシュコントロールプレーンへの追加、アプリケーションを使用して新しいクラスターへの導入を行います。）
水平 - そのためには一定の間隔を空けてください。現在のプラットフォームは、リージョンのテンプレートを提供します。ASM / Istio コントロールが常駐するリージョナル ops ーと、アプリケーションを提供する 2 つ（またはそれ以上）のゾーンクラスタ内のクラスターを利用している。

このワークショップでは、垂直ユースケースのステップも含まれるため、プラットフォームを"水平"にスケーリングします。のレベルに公平な仕組み（r3）を導入することで、新しいプラットフォームで効率的な運用が可能になります。:

新しいオペレーションとアプリケーションクラスター用のパイプラインを確立する VPC にホストされている
ASM / Istio コントロールプレーン上のクラスタ 3 のリージョナル ops ー
この r3 の 2 つのゾーンにある 2 つのゾーンクラスター
k8s-repoへの更新:
ASM / Istio コントロールプレーンにアクセスできるのは r3 のクラスターにビルドする
ASM / Istio 共有コントロールプレーンを使用してクラスタークラスターに装備
そのためには、ワークショップを成功させるために、最先端のチームに関連する設定をカバーする開発 3 を含めることができます。

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-repoKubernetes の作成に使用する環境変数を指定します。これで、k8s-repo（ops プロジェクト内）で Cloud Build が設定されました。新しい Kubernetes 新機能、一部である 3 つの新しいクラスター用です。ASM / Istio コントロールプレーンおよび共有コントロールプレーンを使用する場合、k8s-repoCloud 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 つのアプリケーションクラスターのすべてのオペレーションクラスターに 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にサーキットブレーカーを実装するため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"

サービスオペレーションクラスターで配送サービスの 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 複数の初回接続で配送サービスを提供します。（完全な 1000 リクエスト）connectionPool設定を受け付けていないため、サーキットブレーカーは作動しません。

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

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

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

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

ここで、fortio オプションを起動し、同時に複数の方法で 2 を増やしますが、リクエストのリクエストは一定のに保ちます。サーキットブレーカーが作動させると、最大 3 分 2 が「ヒント」となることができます。実施されるポリシーでは、1 秒パターンで同時に同時に接続は 1 つのみです。

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

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

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

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

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

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

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

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

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

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

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

このセクションでは、サービスに単一のサーキットブレーカーポリシーを設定する方法を示しました。ベストプラクティスは、ハングする可能性のあるアップストリーム（バックエンド）サービスにサーキットブレーカーを設定することです。Istioサーキットブレーカーポリシーを適用することにより、マイクロサービスを分離し、アーキテクチャにフォールトトレランスを構築し、高負荷下で連鎖障害が発生するリスクを軽減できます。

13. フォールトタップ（Fault Injection）

目標: （確立可能な場合に）遅延が必要になることがあり、レコメンデーションを受け取る回復力を受け取る

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

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

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

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

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

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 に入力し、使用方法を推奨サービスに使用します。

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

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

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

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

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

アクションで挿入したフォールトを確認する別の方法は、Webブラウザーでフロントエンドを開き、任意のプロダクトをクリックすることです。商品やサービスに関する情報を提供するサードパーティアプリは、情報量を増やすため、さらに 5 秒ほど使用できます。
両方のOpsクラスターからフォールトインジェクションサービスを削除してクリーンアップします。

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

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

変更をプッシュします。

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

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

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

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

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

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

Grafanaをブラウザから開きます。
Cloud Shell を使用した場合の「Web プレビュー」について
ポート 3000 でポート 3000（注：ポートが 3000 では変更、変更変更ポート 3000 を推奨）
新しい [新しい URL のタブ] を使用して、BASE_URL/?orgId=1&authuser=0&environment_id=default」
利用可能なダッシュボードを表示します
URLを次のように変更します"BASE_URL/dashboard"
"istio"フォルダーをクリックし、利用可能なダッシュボードを表示します
それらのダッシュボードのいずれかをクリックして、そのコンポーネントのパフォーマンスを表示します。次のセクションでは、各コンポーネントの重要な指標を見ていきます

パイロットの監視

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

必要以上の場合は消費します（CPU と RAM のいずれかまたは両方）
更新された構成情報をEnvoyにプッシュする際に遅延が生じます

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

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

重要な監視メトリクス

リソース使用量

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

パイロットの情報の提供

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

Pilot Pushes は、プッシュされる設定サービスです。
ADS Monitoringは、システム内の仮想サービス、サービス、およびエンドポイントの数に含まれます。
既知のエンドポイントを持たないクラスターは、グループが維持されている場合、エンドポイント情報が保持されます（* .googleapis.com などの外部サービスは表示されません）。
Pilot Error は、次のとおりです。
Conflicts は、モニタリングモニタリングがあいまいなウェブ数で表示される場合に限られます。

競合の有無は、1 つ以上のサービスが設定されているか、エラーまたは不可能でなければなりません。詳細については、データプレーンのトラブルシューティングを参照してください。

Envoy情報

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

ミキサーの監視

Mixerは、Envoyプロキシからテレメトリバックエンド（通常はPrometheus、Stackdriverなど）にテレメトリを集中させるコンポーネントです。この容量では、データプレーンにはありません。2 つの異なるグループ（istio-telemetry と istio-policy）で、2 つの Kubernetes Job（Mixer と呼ばれる）をビルドします。

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

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

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

重要な監視メトリクス

リソース使用量

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

Mixer の概要

**応答時間（Response Duration）**は主なものです。Mixerテレメトリへのレポートはデータパスにありませんが、これらのレイテンシが大きい場合、サイドカープロキシのパフォーマンスが確実に低下します。90 の使用は 1 つの際に使用することになりますが、99 個の使用は 100 ユーザーの同意を得る必要があります。

[Adapter Dispatch Duration] は、Mixer が有効にしている場合に有効にするためのプープ（データベースと収集した情報に関する情報が提供されます）です。ここでの待ち時間が長いと、メッシュのパフォーマンスに絶対的な影響があります。繰り返します。p90 は 10 未満である必要があります。

Galleyの監視

Galleyは、Istioの構成の検証、取り込み、処理、および配布を行うコンポーネントです。Kubernetes API を使用してパイロットを実施しています。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 -...をトラブルシューティングする PilotPod を使用するオプション。

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

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. アルファ版ワークショップ

2. 概要

アーキテクチャ図

アジェンダ

前提条件

3. セットアップのセットアップ - 管理者用構成

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

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

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

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

ワークショップのセットアップ（複合ユーザーセットアップ）

ワークショップのセットアップ（セットアップのセットアップ）

4. セットアップのセットアップ - ユーザーに関するお問い合わせ

目標: 一括と Istio のインストール

ユーザー情報の取得

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

インストールの確認

Istio のインストールの確認

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

5. インフラストラクチャに関する説明

インフラストラクチャ Cloud Build

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

プロバイダ、状態、出力 - プロビジョニング、共有状態

変数

K8s についての説明文

Kubernetes クラスタ、GKE クラスタ、

Kubernetes にすると k8s_repo

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

目標: Hipster ショップ アプリのアプリを紹介する

ops でアプリのバージョンを複製する

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

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

Hipster ショップへのアクセス

グローバル負荷分散

GKE AutoNEg クラスター

Cloud Endpoints とサービスを使用して取得したパス Ingress

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

7. Stackdriverによる可観測性

目標: Istio のテレメトリ環境で Stackdriver に連携し、輸送します

8. 相互TLS認証

目標: 複数の異なるパスワードを使用して認証（認証）します

mTLS 検証

9. Qwiklabs の使用

目標: フロントエンド サービスをパッケージ化する

10. 承認ポリシー

目標: 複数の間で RBAC を共有（承認）

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

目標: 新しいアプローチ、プロジェクト、パラメーターを追加したモデルをスケールする

Istio のインストールの確認

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

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

目標: サーキットブレーカーを出荷する際の実装

13. フォールトタップ（Fault Injection）

目標: （確立可能な場合に）遅延が必要になることがあり、レコメンデーションを受け取る回復力を受け取る

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

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

パイロットの監視

重要な監視メトリクス

ミキサーの監視

重要な監視メトリクス

Galleyの監視

重要な監視メトリクス

15. Istio ベース

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

設定エラーの発見

16. クリーンアップ

目標: Hipster ショップアプリのアプリを紹介する

目標: フロントエンドサービスをパッケージ化する