1. ALPHA WORKSHOP
ワークショップ codelab へのリンク: bit.ly/asm-workshop-jp
2. 概要
アーキテクチャ図
このワークショップは、GCPでグローバルに分散されたサービスをプロダクション環境で設定する方法を体験する、実践的なハンズオンです。使用する主なテクノロジーは、コンピューティング用の Google Kubernetes Engine(GKE)と、セキュアな接続、可観測性、高度なトラフィック操作を実現する Istioサービスメッシュです。このワークショップで使用されるすべてのプラクティスとツールは、実際に本番で使用するものと同じです。
Agenda
TODO - update with final breakdown
前提条件
ワークショップを進める前に、下記の事項が必要となります:
- 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スクリプトで作成された特定のプロジェクトのプロジェクト所有者ロールが割り当てられます。ワークショップ作成スクリプトを使用するときは、このユーザー命名スキーマに従う必要があります。 詳細は GSuiteで複数のユーザーを一度に追加する方法を参照してください。
ワークショップで必要なツール群
このワークショップは Cloud Shell から実行されることを想定しています。下記に示すツール群がワークショップで必要となります。
- gcloud (ver >= 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 を開くには下記のリンクをクリックしてください。
- 想定している管理者ユーザーで 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 planを適用します。 Cloud Buildサービスアカウントに適切なIAMロールを与えて、GCPでリソースを作成できるようにします。最後に、 Google Cloud Storage(GCS)バケットでリモートバックエンドを構成して、すべてのGCPリソースの Terraform statesを保存します。
terraform管理プロジェクトでCloud Buildタスクを表示するには、terraform管理プロジェクトIDが必要です。これは、ワークショップ作成スクリプトで指定された管理用GCSバケットに保存されます。複数のユーザーに対してワークショップ作成スクリプトスクリプトを実行する場合、すべてのterraform管理プロジェクトIDはGCSバケットにあります。
- 管理用GCSバケットからworkshop.txtファイルを取得して、terraformプロジェクトIDを取得します。
export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .
ワークショップのセットアップ (複数ユーザーセットアップ)
- Cloud Shell を開き、以降の作業を Cloud Shell 上で実行します。Cloud Shell を開くには下記のリンクをクリックしてください。
- 想定している管理者ユーザーで 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 (ver >= 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 planを適用するために使用されます。スクリプトを使用して、 Cloud Buildサービスアカウントに適切なIAMロールを付与し、GCPでリソースを作成できるようにします。最後に、すべてのGCPリソースの Terraform stateを保存するために、リモートバックエンドが Google Cloud Storage(GCS)バケットに構成されます。
terraform管理プロジェクトでCloud Buildタスクを表示するには、terraform管理プロジェクトIDが必要です。これは、ワークショップ作成スクリプトで指定された管理用GCSバケットに保存されます。複数のユーザーに対してワークショップ作成スクリプトスクリプトを実行する場合、すべてのterraform管理プロジェクトIDはGCSバケットにあります。
- 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-repo
という名前のCSRリポジトリが作成されます。 GKEクラスタごとに1つのフォルダがあります。このリポジトリは、GitOps形式でKubernetesのマニフェストをクラスタにデプロイするために使用されます。 - Cloud Buildトリガーは、
k8s-repo
のmasterブランチへのコミットがあるたびに作成され、KubernetesのマニフェストをそれぞれのフォルダからGKEクラスタにデプロイします。
- terraform 管理プロジェクトでビルドが完了すると、opsプロジェクトで別のビルドが開始されます。表示されたリンクをクリックして、
ops
プロジェクトのCloud Buildページを開きます。
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
インストールの確認
- すべてのクラスタを管理するために kubeconfig ファイルを作成します。下記のスクリプトを実行します。
./scripts/setup-gke-vars-kubeconfig.sh
このスクリプトは新しい kubeconfig ファイルを kubemesh
という名前で gke
フォルダに作成します。
KUBECONFIG
変数を新しい kubeconfig ファイルに変更します。
source ./vars/vars.sh
export KUBECONFIG=`pwd`/gke/kubemesh
- var.sh を .bashrc に追加し、Cloud Shell が再起動した際に常に読み込まれるようにします。
echo "source ${WORKDIR}/asm/vars/vars.sh" >> ~/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> ~/.bashrc
- クラスタのコンテキストを取得します。6つのクラスタが見えるはずです。
kubectl config view -ojson | jq -r '.clusters[].name'
`出力結果(コピーしないでください)`
gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod
Istio のインストール確認
- すべての Pod が実行され、ジョブが完了したことを確認して、Istioが両方のクラスターにインストールされていることを確認します。
kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
`出力結果(コピーしないでください)`
NAME READY STATUS RESTARTS AGE grafana-5f798469fd-z9f98 1/1 Running 0 6m21s istio-citadel-568747d88-qdw64 1/1 Running 0 6m26s istio-egressgateway-8f454cf58-ckw7n 1/1 Running 0 6m25s istio-galley-6b9495645d-m996v 2/2 Running 0 6m25s istio-ingressgateway-5df799fdbd-8nqhj 1/1 Running 0 2m57s istio-pilot-67fd786f65-nwmcb 2/2 Running 0 6m24s istio-policy-74cf89cb66-4wrpl 2/2 Running 1 6m25s istio-sidecar-injector-759bf6b4bc-mw4vf 1/1 Running 0 6m25s istio-telemetry-77b6dfb4ff-zqxzz 2/2 Running 1 6m24s istio-tracing-cd67ddf8-n4d7k 1/1 Running 0 6m25s istiocoredns-5f7546c6f4-g7b5c 2/2 Running 0 6m39s kiali-7964898d8c-5twln 1/1 Running 0 6m23s prometheus-586d4445c7-xhn8d 1/1 Running 0 6m25s
`出力結果(コピーしないでください)`
NAME READY STATUS RESTARTS AGE grafana-5f798469fd-2s8k4 1/1 Running 0 59m istio-citadel-568747d88-87kdj 1/1 Running 0 59m istio-egressgateway-8f454cf58-zj9fs 1/1 Running 0 60m istio-galley-6b9495645d-qfdr6 2/2 Running 0 59m istio-ingressgateway-5df799fdbd-2c9rc 1/1 Running 0 60m istio-pilot-67fd786f65-nzhx4 2/2 Running 0 59m istio-policy-74cf89cb66-4bc7f 2/2 Running 3 59m istio-sidecar-injector-759bf6b4bc-grk24 1/1 Running 0 59m istio-telemetry-77b6dfb4ff-6zr94 2/2 Running 4 60m istio-tracing-cd67ddf8-grs9g 1/1 Running 0 60m istiocoredns-5f7546c6f4-gxd66 2/2 Running 0 60m kiali-7964898d8c-nhn52 1/1 Running 0 59m prometheus-586d4445c7-xr44v 1/1 Running 0 59m
- Istioが両方の
dev1
クラスターにインストールされていることを確認してください。dev1
クラスターでは、Citadel、sidecar-injector、corednのみが実行されています。 ops-1クラスターで実行されているIstioのコントロールプレーンを共有します。
kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
- Istioが両方の
dev2
クラスタにインストールされていることを確認してください。dev2
クラスタでは、Citadel、sidecar-injector、corednのみが実行されています。 ops-2クラスタで実行されているIstioのコントロールプレーンを共有します。
kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
`出力結果(コピーしないでください)`
NAME READY STATUS RESTARTS AGE istio-citadel-568747d88-4lj9b 1/1 Running 0 66s istio-sidecar-injector-759bf6b4bc-ks5br 1/1 Running 0 66s istiocoredns-5f7546c6f4-qbsqm 2/2 Running 0 78s
共有コントロールプレーンのサービスディスカバリの確認
- オプションで、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クラスターは、Secretとしてkubeconfigファイルを使用してサービスを自動的に検出できます。これには、opsクラスター内のPilotが他のすべてのクラスターのKube APIサーバーにアクセスできることが必要です。 PilotがKube APIサーバーに到達できない場合、リモートサービスを ServiceEntriesとして手動で追加します。 ServiceEntriesは、サービスレジストリのDNSエントリと考えることができます。 ServiceEntriesは、完全修飾DNS名( FQDN)と到達可能なIPアドレスを使用してサービスを定義します。詳細については、 Istio Multiclusterのドキュメントを参照してください。
5. infrastructure リポジトリの説明
Infrastructure Cloud Build
ワークショップのGCPリソースは、 Cloud Buildと Infrastructure
CSRリポジトリを使用して構築されます。ローカル端末からワークショップ作成スクリプト(scripts/bootstrap_workshop.sh
にあります)を実行します。ワークショップ作成スクリプトは、GCPフォルダ、terraform管理プロジェクト、および Cloud Buildサービスアカウントの適切なIAMアクセス許可を作成します。Terraform管理プロジェクトは、Terraform states、ログ、およびその他のスクリプトを保存するために使用されます。そこには 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 state ファイル(以下で説明)にあります。これらのリソースは、ワークショップ作成プロセス中にbashスクリプトによって作成されます(詳細については、モジュール0-インフラストラクチャ セットアップ - 管理者用ワークフローを参照)。
- network - ネットワークチームを表します。 VPCとネットワークリソースを担当します。彼らは次のGCPリソースを所有しています。
host project
- 共有VPCのホストプロジェクトを表します。shared VPC
- 共有VPC、サブネット、セカンダリIP範囲、ルーティング情報、ファイアウォールルールを表します。- ops - 運用 / DevOpsチームを表します。彼らは次のリソースを所有しています。
ops project
- すべてのopsリソースのためのプロジェクトを表します。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 の両方で使用します。
プロバイダ、state、出力 - バックエンド、共有 state
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リポジトリ(infrastructureリポジトリとは別)で、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クラスター, そしてnamespace
このワークショップのリソースは、さまざまな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 / platformチームは、
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」と呼ばれるWebベースの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ショップアプリをappsクラスターにデプロイする
k8s-repo
リポジトリをクローン- Hipsterショップのマニフェストを全てのappsクラスターにコピー
- HipsterショップアプリのためにServicesをopsクラスターに作成
- グローバルの接続性をテストするため
loadgenerator
をopsクラスターにセットアップ - Hipsterショップアプリへのセキュアな接続を確認
ops プロジェクトのリポジトリをクローン
最初のTerraformインフラストラクチャ構築の一部として、k8s-repo
はopsプロジェクトで既に作成済みです。
- WORKDIR の下に、リポジトリ用の空フォルダを作成します。:
mkdir ${WORKDIR}/k8s-repo
cd ${WORKDIR}/k8s-repo
- git リポジトリとして初期化し、リモートのリポジトリとして追加、master ブランチを pull します:
git init && git remote add origin \
https://source.developers.google.com/p/${TF_VAR_ops_project_name}/r/k8s-repo
- git のローカル設定を行います。
git config --local user.email ${MY_USER}
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master
マニフェストのコピー、コミット、そしてプッシュ
- 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つのdevクラスター以外のすべてからcartservice deployment、RBACおよびPodSecurityPolicyを削除します。 Hipsterショップはマルチクラスター展開用に構築されたものではなく、4つのdeploymentすべてを実行し続けることで、アクセスしたdeploymentに応じてカート情報に矛盾が生じてしまいます。
rm ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/deployments/app-cart-service.yaml
rm ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/podsecuritypolicies/cart-psp.yaml
rm ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/cart-rbac.yaml
rm ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/deployments/app-cart-service.yaml
rm ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/podsecuritypolicies/cart-psp.yaml
rm ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/cart-rbac.yaml
rm ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/deployments/app-cart-service.yaml
rm ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/podsecuritypolicies/cart-psp.yaml
rm ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/cart-rbac.yaml
- 最初のdevクラスターのみで、cartservice deployment、RBAC、およびPodSecurityPolicyをkustomization.yamlに追加します。
cd ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
- opsクラスターのkustomization.yamlからPodSecurityPolicies、deployment、RBACディレクトリを削除します。
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' -e '/- rbac\//d' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' -e '/- rbac\//d' ../k8s-repo/${OPS_GKE_2_CLUSTER}/app/kustomization.yaml
- RBACマニフェストのPROJECT_IDを置き換えます。
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' ../k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' ../k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
- IngressGatewayおよびVirtualServiceマニフェストをopsクラスターのソースリポジトリにコピーします。
cp -r k8s_manifests/prod/app-ingress/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-ingress/
cp -r k8s_manifests/prod/app-ingress/* ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-ingress/
- Config Connectorリソースを各プロジェクトのクラスターの1つにコピーします。
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-cnrm/
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app-cnrm/
cp -r k8s_manifests/prod/app-cnrm/* ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app-cnrm/
- Config ConnectorマニフェストのPROJECT_IDを置き換えます。
sed -i 's/${PROJECT_ID}/'${TF_VAR_ops_project_name}'/g' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-cnrm/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' ../k8s-repo/${DEV1_GKE_1_CLUSTER}/app-cnrm/*
sed -i 's/${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' ../k8s-repo/${DEV2_GKE_1_CLUSTER}/app-cnrm/*
loadgenerator
マニフェスト(Deployment、PodSecurityPolicy、RBAC)をopsクラスターにコピーします。 Hipsterショップアプリは、グローバルなGoogle Cloud Load Balancer(GCLB)を使用して公開されます。 GCLBはクライアントトラフィック(frontend
宛て)を受信し、サービスの最も近いインスタンスに送信します。loadgenerator
を両方のopsクラスターに配置すると、opsクラスターで実行されている両方のIstio Ingressゲートウェイにトラフィックが送信されます。負荷分散については、次のセクションで詳しく説明します。
cp -r k8s_manifests/prod/app-loadgenerator/. ../k8s-repo/gke-asm-1-r1-prod/app-loadgenerator/.
cp -r k8s_manifests/prod/app-loadgenerator/. ../k8s-repo/gke-asm-2-r2-prod/app-loadgenerator/.
- 両方のopsクラスターの
loadgenerator
マニフェストのopsプロジェクトIDを置き換えます。
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g' ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g' ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'${TF_VAR_ops_project_name}'/g' ../k8s-repo/${OPS_GKE_2_CLUSTER}/app-loadgenerator/loadgenerator-rbac.yaml
- 両方のopsクラスターの
loadgenerator
リソースをkustomization.yamlに追加します。
cd ../k8s-repo/${OPS_GKE_1_CLUSTER}/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
cd ../../${OPS_GKE_2_CLUSTER}/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
k8s-repo
にコミットします。
cd ${WORKDIR}/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master
- ロールアウトが完了するのを待ちます。
../asm/scripts/stream_logs.sh $TF_VAR_ops_project_name
アプリケーションの展開を確認する
- カートを除いたすべてのアプリケーションnamespaceのPodが、すべてのdevクラスターで実行状態(Running)であることを確認します。
for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
kubectl --context ${DEV1_GKE_1} get pods -n ${ns};
kubectl --context ${DEV1_GKE_2} get pods -n ${ns};
kubectl --context ${DEV2_GKE_1} get pods -n ${ns};
kubectl --context ${DEV2_GKE_2} get pods -n ${ns};
done;
出力結果(コピーしないでください)
NAME READY STATUS RESTARTS AGE currencyservice-5c5b8876db-pvc6s 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE currencyservice-5c5b8876db-xlkl9 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE currencyservice-5c5b8876db-zdjkg 2/2 Running 0 115s NAME READY STATUS RESTARTS AGE currencyservice-5c5b8876db-l748q 2/2 Running 0 82s NAME READY STATUS RESTARTS AGE emailservice-588467b8c8-gk92n 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE emailservice-588467b8c8-rvzk9 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE emailservice-588467b8c8-mt925 2/2 Running 0 117s NAME READY STATUS RESTARTS AGE emailservice-588467b8c8-klqn7 2/2 Running 0 84s NAME READY STATUS RESTARTS AGE frontend-64b94cf46f-kkq7d 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE frontend-64b94cf46f-lwskf 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE frontend-64b94cf46f-zz7xs 2/2 Running 0 118s NAME READY STATUS RESTARTS AGE frontend-64b94cf46f-2vtw5 2/2 Running 0 85s NAME READY STATUS RESTARTS AGE paymentservice-777f6c74f8-df8ml 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE paymentservice-777f6c74f8-bdcvg 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE paymentservice-777f6c74f8-jqf28 2/2 Running 0 117s NAME READY STATUS RESTARTS AGE paymentservice-777f6c74f8-95x2m 2/2 Running 0 86s NAME READY STATUS RESTARTS AGE productcatalogservice-786dc84f84-q5g9p 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE productcatalogservice-786dc84f84-n6lp8 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE productcatalogservice-786dc84f84-gf9xl 2/2 Running 0 119s NAME READY STATUS RESTARTS AGE productcatalogservice-786dc84f84-v7cbr 2/2 Running 0 86s NAME READY STATUS RESTARTS AGE recommendationservice-5fdf959f6b-2ltrk 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE recommendationservice-5fdf959f6b-dqd55 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE recommendationservice-5fdf959f6b-jghcl 2/2 Running 0 119s NAME READY STATUS RESTARTS AGE recommendationservice-5fdf959f6b-kkspz 2/2 Running 0 87s NAME READY STATUS RESTARTS AGE shippingservice-7bd5f569d-qqd9n 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE shippingservice-7bd5f569d-xczg5 2/2 Running 0 13m NAME READY STATUS RESTARTS AGE shippingservice-7bd5f569d-wfgfr 2/2 Running 0 2m NAME READY STATUS RESTARTS AGE shippingservice-7bd5f569d-r6t8v 2/2 Running 0 88s
- cart namespaceのPodが、最初のdevクラスターでのみ実行状態(Running)であることを確認します。
kubectl --context ${DEV1_GKE_1} get pods -n cart;
出力結果(コピーしないでください)
NAME READY STATUS RESTARTS AGE cartservice-659c9749b4-vqnrd 2/2 Running 0 17m
Hipsterショップアプリケーションへのアクセス
グローバル負荷分散
これで、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 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マネージド証明書は、frontend
GCLBサービスへのクライアントトラフィックを保護するために使用されます。 GCLBは、グローバルfrontend
サービスにマネージド証明書を使用し、SSLはGCLBで終端されます。このワークショップでは、マネージド証明書のドメインとして Cloud Endpointsを使用します。または、frontend
のドメインとDNS名を使用して、GCPマネージド証明書を作成できます。
- Hipsterショップにアクセスするために、下記のコマンドで出力されるリンクをクリックします。
echo "https://frontend.endpoints.${TF_VAR_ops_project_name}.cloud.goog"
- ChromeタブのURLバーのロック記号をクリックして、証明書が有効であることを確認できます。
グローバル負荷分散の確認
アプリケーション展開の一部として、GCLB HipsterショップのCloud Endpointsリンクへテストトラフィックを生成する両方のopsクラスターに、負荷生成機能が展開されました。 GCLBがトラフィックを受信し、両方のIstio Ingressゲートウェイに送信していることを確認します。
- HipsterショップGCLBが作成されているopsプロジェクトのGCLB > Monitoringリンクを取得します。
echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=${TF_VAR_ops_project_name}&cloudshell=false&tab=monitoring&duration=PT1H"
- 以下に示すように、BackendドロップダウンメニューからAll backendsからistio-ingressgatewayに変更します。
- 両方の
istio-ingressgateways
に向かうトラフィックを確認してください。
istio-ingressgateway
ごとに3つのNEGが作成されます。 opsクラスターはリージョナルクラスターであるため、リージョン内の各ゾーンに対して1つのNEGが作成されます。ただし、istio-ingressgateway
Podは、リージョンごとに単一のゾーンで実行されます。 ここでは、istio-ingressgateway
Podに向かうトラフィックが表示されます。
負荷生成機能は、両方のopsクラスターで実行され、2つのリージョンからのクライアントトラフィックをシミュレーションします。opsクラスターリージョン1で生成された負荷は、リージョン2のistio-ingressgateway
に送信されます。同様にopsクラスターリージョン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という名前のHandlerが表示されるはずです:
NAME AGE kubernetesenv 12d prometheus 12d stackdriver 69s
IstioのメトリックスがStackdriverにエクスポートされていることを確認します。このコマンドから出力されるリンクをクリックします。:
echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=${TF_VAR_ops_project_name}"
Opsプロジェクトにちなんで命名された新しいワークスペースを作成するように求められるので、[OK]を選択します。新しいUIについてのプロンプトが表示されたら、ダイアログを閉じます。
メトリクスエクスプローラーで、[レコードタイプ]をクリックし、「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などのフィルタリングや集計に使用できるラベルのセットがあることに注意してください。
- 次に、あらかじめ用意されているメトリックダッシュボードを追加しましょう。 Dashboard APIを直接使用します。これは、API呼び出しを手動で生成する場合、通常行いません。なんらかの自動化システムの一部であるか、Web UIでダッシュボードを手動で作成します。これにより、すぐに使い始められます。:
cd ${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/
sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/${TF_VAR_ops_project_name}/dashboards \
-d @services-dashboard.json
- 以下の出力されたリンクに移動して、新しく追加されたダッシュボードを表示します。
echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=${TF_VAR_ops_project_name}"
UXを使用してダッシュボードをその場で編集することもできますが、今回のケースでは、APIを使用して新しいグラフをすばやく追加します。そのためには、ダッシュボードの最新バージョンを取得し、編集内容を適用してから、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}"
ツールのスクリーンショットの例:
- クラスター内の可観測ツールを公開します。
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. カナリアデプロイメント
目標: frontendサービスの新バージョンをロールアウトする
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 deployment
- frontend-v1 パッチ ("v1"ラベルと"/ version"エンドポイントを持つコンテナイメージを含める)
- respy, HTTP応答の分布を書き出し、カナリアデプロイメントをリアルタイムで視覚化するのに役立つ小さなPod。
- frontend Istio DestinationRule - "バージョン"デプロイメントラベルに基づいて、frontend Kubernetesサービスを2つのサブセット、v1とv2に分割します
- frontend Istio VirtualService - トラフィックの100%をfrontend v1にルーティングします。これにより、Kubernetesサービスのデフォルトのラウンドロビン動作が上書きされ、すべてのDev1リージョントラフィックの50%がfrontend v2に直ちに送信されます。
- 変更内容をk8s_repoにコミットします。:
cd $K8S_REPO
git add . && git commit -am "frontend canary setup"
git push
cd $CANARY_DIR
- Ops1プロジェクトのコンソールでCloud Buildに移動します。 Cloud Buildパイプラインが完了するまで待ってから、両方のDEV1クラスターのfrontend namespaceでPodを取得します。以下が表示されるはずです。:
watch -n 1 kubectl --context ${DEV1_GKE_1} get pods -n frontend
出力結果(コピーしないでください)
NAME READY STATUS RESTARTS AGE frontend-578b5c5db6-h9567 2/2 Running 0 59m frontend-v2-54b74fc75b-fbxhc 2/2 Running 0 2m26s respy-5f4664b5f6-ff22r 2/2 Running 0 2m26s
- 別のCloud Shellセッションを開きます。 DEV1_GKE_1で実行されている新しいRespy Podに入ります。
RESPY_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n frontend | grep respy | awk '{ print $1 }')
kubectl --context ${DEV1_GKE_1} exec -n frontend -it $RESPY_POD -c respy /bin/sh
- watchコマンドを実行して、frontendサービスのHTTP応答の分布を確認します。すべてのトラフィックは、新しいVirtualServiceで定義されたfrontend v1 deploymentに向かうことがわかります。
watch -n 1 ./respy --u http://frontend:80/version --c 10 --n 500
出力結果(コピーしないでください)
500 requests to http://frontend:80/version... +----------+-------------------+ | RESPONSE | % OF 500 REQUESTS | +----------+-------------------+ | v1 | 100.0% | | | | +----------+-------------------+
- 前のCloud Shellセッションに戻り、Dev2リージョンでカナリアパイプラインを実行します。 VirtualServiceのfrontend 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からのすべての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へのアクセスを制御する方法を学習します。
最初に、4つのDevクラスターすべてに AuthorizationPolicyをデプロイし、currencyserviceへのすべてのアクセスを遮断し、frontendでエラーをトリガーします。次に、frontendサービスのみがcurrencyserviceにアクセスできるようにします。
- 認可のサンプルディレクトリに移動します。
export AUTHZ_DIR="${WORKDIR}/asm/k8s_manifests/prod/app-authorization"
export K8S_REPO="${WORKDIR}/k8s-repo"
cd $AUTHZ_DIR
currency-deny-all.yaml
の内容を見てみます。このポリシーは、Deploymentラベルセレクターを使用して、currencyserviceへのアクセスを制限します。spec
フィールドがないことに注意してください-これは、このポリシーが選択したサービスへのすべての アクセスを拒否することを意味します。
cat currency-deny-all.yaml
出力結果(コピーしないでください)
apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "currency-policy" namespace: currency spec: selector: matchLabels: app: currencyservice
- 両方のリージョンのopsクラスターのcurrencyポリシーをk8s-repoにコピーします。
mkdir -p ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/
sed -i '/ - app-ingress\//a\ \ - app-authorization\/' ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/kustomization.yaml
cp currency-deny-all.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/; kustomize create --autodetect
cd $AUTHZ_DIR
mkdir -p ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/
sed -i '/ - app-ingress\//a\ \ - app-authorization\/' ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/kustomization.yaml
cp currency-deny-all.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/; kustomize create --autodetect
- 変更をプッシュします。
cd $K8S_REPO
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push
cd $AUTHZ_DIR
- ブラウザでHipsterショップアプリのfrontendにアクセスしてみてください:
echo "https://frontend.endpoints.${TF_VAR_ops_project_name}.cloud.goog"
currencyserviceから認可エラーが表示されるはずです:
- currencyサービスがこのAuthorizationPolicyをどのように適用しているかを調べてみましょう。最初に、ブロックされた認可呼び出しはデフォルトでは記録されないため、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
- 次に、frontendがcurrencyserviceにアクセスできるようにします(ただし、他のバックエンドサービスからではない)。
currency-allow-frontend.yaml
を開き、その内容を調べます。次のルールを追加したことに確認してください。:
cat currency-allow-frontend.yaml
出力結果(コピーしないでください)
rules: - from: - source: principals: ["cluster.local/ns/frontend/sa/frontend"]
ここでは、特定の source.principal(クライアント)をホワイトリストに登録して、currencyサービスにアクセスしています。このsource.principalは、Kubernetesサービスアカウントによって定義されます。この場合、ホワイトリストに登録するサービスアカウントは、frontend namespaceのfrontendサービスアカウントです。
注:Istio AuthorizationPoliciesでKubernetesサービスアカウントを使用する場合、モジュール1で行ったように、最初にクラスター全体の相互TLSを有効にする必要があります。これは、サービスアカウントの資格情報がリクエストにマウントされるようにするためです。
- 更新されたcurrencyポリシーをコピーします。
cp $AUTHZ_DIR/currency-allow-frontend.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/app-authorization/currency-policy.yaml
cp $AUTHZ_DIR/currency-allow-frontend.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/app-authorization/currency-policy.yaml
- 更新をプッシュします。
cd $K8S_REPO
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
cd $AUTHZ_DIR
- Cloud Buildの完了を待ちます。
- Hipsterショップアプリのfrontendを再度開きます。今回は、ホームページにエラーが表示されないはずです。これは、frontendが現在のサービスにアクセスすることを明示的に許可しているためです。
- 次に、カートにアイテムを追加し、"place order"をクリックして、チェックアウトを実行してください。今回は、currencyサービスから価格変換エラーが表示されるはずです。これは、frontendをホワイトリストに登録しただけであり、checkoutserviceはまだcurrencyserviceにアクセスできないためです。
- 最後に、別のルールをcurrencyservice AuthorizationPolicyに追加して、checkoutサービスがcurrency serviceにアクセスできるようにします。frontendとcheckoutの 2つのサービスからのcurrency serviceのアクセスのみを開放していることに注意してください。他のバックエンドサービスは引き続きブロックされます。
currency-allow-frontend-checkout.yaml
を開き、その内容を見てみます。ルールのリストは論理ORとして機能することに注意してください。currency serviceは、これら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プロジェクト用、もう一つが新しいプロジェクト用)
- 新しいリージョンに新しいopsクラスター (新しいサブネット内に)
- 新しいリージョンに新しいIstioコントロールプレーン
- 新しいリージョンの新しいプロジェクトに2つのappsクラスター
infrastructure
リポジトリにコミット- セットアップを確認
プラットフォームをスケールするには、いくつかの方法があります。既存のクラスターにノードを追加することにより、さらに計算リソースを追加できます。リージョン内にさらにクラスターを追加できます。または、プラットフォームにさらにリージョンを追加できます。プラットフォームのどの側面を拡張するかの決定は、要件に依存します。たとえば、リージョン内の3つのゾーンすべてにクラスターがある場合、おそらく既存のクラスターにノード(またはノードプール)を追加すれば十分です。ただし、1つのリージョンの3つのゾーンのうち2つにクラスターがある場合、3番目のゾーンに新しいクラスターを追加すると、スケーリングと追加のフォールトドメイン(つまり、新しいゾーン)が得られます。リージョンに新しいクラスターを追加するもう1つの理由は、規制またはコンプライアンスの理由(PCI、PII情報を格納するデータベースクラスターなど)のために、単一のテナントクラスターを作成する必要がある場合があります。ビジネスとサービスが拡大するにつれて、クライアントにより近くでサービスを提供するために新しいリージョンを追加することが避けられなくなります。
現在のプラットフォームは、2つのリージョンと、リージョンごとに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に送信します。(合計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サービスの回復力をテストする
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
- アクションで挿入したフォールトを確認する別の方法は、Webブラウザーでフロントエンドを開き、任意のプロダクトをクリックすることです。製品ページは、ページの下部に表示されるrecommend情報を取得するため、ロードにさらに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を選択します)
- これにより、ブラウザに次のようなURLのタブが開きます " BASE_URL/?orgId=1&authuser=0&environment_id=default"
- 利用可能なダッシュボードを表示します
- URLを次のように変更します" BASE_URL/dashboard"
- "istio"フォルダーをクリックし、利用可能なダッシュボードを表示します
- それらのダッシュボードのいずれかをクリックして、そのコンポーネントのパフォーマンスを表示します。次のセクションでは、各コンポーネントの重要な指標を見ていきます
Pilotの監視
Pilotは、データプレーン(Envoyプロキシ)にネットワークとポリシーの構成を配布するコントロールプレーンコンポーネントです。Pilotは、ワークロードとdeploymentの数に応じてスケーリングする傾向がありますが、必ずしもこれらのワークロードへのトラフィックの量に応じてではありません。正常ではないPilotは次のようになり得ます:
- 必要以上のリソースを消費します (CPU と/または RAM)
- 更新された構成情報をEnvoyにプッシュする際に遅延が生じます
注:Pilotがダウンしている、または遅延がある場合でもワークロードは引き続きトラフィックを処理し続けます。
- ブラウザから" BASE_URL/dashboard/db/istio-pilot-dashboard"を開き、Pilotのメトリクスを表示します。
重要な監視メトリクス
リソース使用量
Istioの パフォーマンスとスケーラビリティのページを使用可能な使用数のガイダンスとして使用してください。これよりも大幅に多くのリソースを使用している場合は、GCPサポートにお問い合わせください。
Pilotのプッシュ情報
このセクションでは、EnvoyプロキシへのPilotの設定プッシュを監視します。
- Pilot Pushesは、プッシュされる設定のタイプを示します。
- ADS Monitoringは、システム内のVirtual Services、サービス、および接続されたエンドポイントの数を示します。
- 既知のエンドポイントを持たないクラスターは、設定されているが実行中のインスタンスを持たないエンドポイントを表示します(* .googleapis.comなどの外部サービスを示す場合があります)。
- Pilot Errorsは、時間の経過とともに発生したエラーの数を示します。
- Conflicts は、リスナーの構成があいまいな競合の数を示します。
エラーまたはConflictsがある場合、1つ以上のサービスの構成が正しくないか、一貫性がありません。詳細については、データプレーンのトラブルシューティングを参照してください。
Envoy情報
このセクションには、コントロールプレーンに接続するEnvoyプロキシに関する情報が含まれています。繰り返しXDS接続エラーが発生する場合は、GCPサポートにお問い合わせください。
Mixerの監視
Mixerは、Envoyプロキシからテレメトリバックエンド(通常はPrometheus、Stackdriverなど)にテレメトリを集中させるコンポーネントです。この容量では、データプレーンにはありません。 2つの異なるサービス名(istio-telemetryとistio-policy)でデプロイされた2つのKubernetes Jobs(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に伝えます。 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を開き、その中で以下のすべてのアクションを実行します。下のリンクをクリックしてください。
- 想定している管理者ユーザーで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}