Anthos 服務網格研討會：研究室指南

1. Alpha 版研討會

研討會程式碼研究室 bit.ly/asm-workshop 的連結

2. 總覽

架構圖

9a033157f44308f3.png

本研討會提供實作體驗，逐步說明如何在 GCP 的實際工作環境中設定遍及全球的服務。主要使用的技術是 Google Kubernetes Engine (GKE)，用於運算，並採用 Istio 服務網格建立安全的連線、觀測能力和進階流量型態。本工作坊採用的所有做法和工具，就是會用於實際工作環境的。

大綱

  • 單元 0 - 簡介與平台設定
  • 簡介與架構
  • Service Mesh 和 Istio/ASM 簡介
  • 研究室：基礎架構設定：使用者工作流程
  • 休息時間
  • QnA
  • 單元 1 - 透過 ASM 安裝、保護及監控應用程式
  • 存放區模型：基礎架構和 Kubernetes 存放區說明
  • 研究室：部署範例應用程式
  • 分散式服務和觀測能力
  • 午餐
  • 研究室：搭配 Stackdriver 進行觀測
  • QNA
  • 單元 2 - 開發運作 - 初期測試發布、政策/RBAC
  • 多叢集服務探索和安全性/政策
  • 研究室：雙向傳輸層安全標準 (TLS)
  • 初期測試部署
  • 研究室：初期測試部署
  • 安全的多叢集全域負載平衡
  • 休息時間
  • 研究室：授權政策
  • QNA
  • 模組 3 - 基礎架構作業 - 平台升級
  • 分散式服務構成元素
  • 研究室：基礎架構資源調度
  • 後續步驟

簡報

你可以透過以下連結取得本研討會的投影片：

ASM 研討會投影片

必要條件

您必須完成以下事項，才能進行這個研討會：

  1. GCP 機構節點
  2. 帳單帳戶 ID (您的使用者必須是這個帳單帳戶的帳單管理員)
  3. 使用者在機構層級中的機構管理員 IAM 角色

3. 基礎架構設定 - 管理員工作流程

Bootstrap 研討會腳本說明

名為 bootstrap_workshop.sh 的指令碼是用來設定研討會的初始環境。如果您要為自己或多位使用者提供此研討會的訓練，可以使用這個指令碼為自己或多位使用者設定單一環境。

啟動研討會指令碼需要下列項目做為輸入內容：

  • 機構名稱 (例如 yourcompany.com)：這是您為研討會建立環境的機構。
  • 帳單 ID (例如 12345-12345-12345)：此帳單 ID 用於收取研討會期間使用的所有資源費用。
  • 工作坊編號 (例如 01)：以兩位數的數字。如果您在一天內舉行多個研討會，而且想要分開追蹤，可以使用這個選項。工作坊編號也可用來衍生專案 ID。使用獨立的研討會號碼，可以更輕鬆確保每次都取得不重複的專案 ID。除了研討會編號之外，現在也會用於專案 ID (格式為 YYMMDD)。日期和研討會號碼的組合會提供專屬的專案 ID，
  • 啟動使用者號碼 (例如 1)：這個號碼代表研討會中的首位使用者。舉例來說，假設您想為 10 位使用者建立研討會，那麼起始使用者編號為 1，而最終使用者數量為 10。
  • 使用者號碼 (例如 10)：這個數字代表研討會最後一位使用者。舉例來說，假設您想為 10 位使用者建立研討會，那麼起始使用者編號為 1，而最終使用者數量為 10。如果您要設定單一環境 (例如自己)，請為起始和使用者編號設定相同的編號。這會建立單一環境。
  • 管理員 GCS 值區 (例如 my-gcs-bucket-name)：GCS 值區用於儲存研討會相關資訊。cleanup_workshop.sh 指令碼會使用這項資訊，妥善刪除啟動研討會指令碼期間建立的所有資源。建立研討會的管理員必須具備這個值區的讀取/寫入權限。

啟動工作坊指令碼會使用上述提供的值，並做為呼叫 setup-terraform-admin-project.sh 指令碼的包裝函式指令碼。setup-terraform-admin-project.sh 指令碼會建立單一使用者的研討會環境。

啟動研討會所需的管理員權限

本研討會包含兩種類型的使用者。ADMIN_USER，負責建立及刪除這個研討會的資源。第二個是 MY_USER，負責執行研討會中的步驟。「MY_USER」只能存取自己的資源。「ADMIN_USER」可存取所有使用者設定。如果您要為自己建立此設定，則 ADMIN_USER 和 MY_USER 會相同。如果您是為多位學生建立這堂講習課程，您的ADMIN_USER和MY_USER就會不同。

ADMIN_USER 必須具備下列機構層級權限：

  • 擁有者 - 擁有機構中所有專案的專案擁有者權限。
  • 資料夾管理員：可以在機構中建立及刪除資料夾，每位使用者都會取得一個資料夾，當中包含專案內的所有資源。
  • 機構管理員
  • 專案建立者：能夠在機構中建立專案。
  • 專案刪除者：可刪除機構中的專案。
  • 專案 IAM 管理員：能夠在機構中的所有專案建立 IAM 規則。

此外，ADMIN_USER 也必須是研討會所用帳單 ID 的帳單管理員。

執行研討會的使用者結構定義和權限

如果打算為機構中的使用者 (非您本人) 建立這場研討會，您必須為「MY_USERs」採用特定使用者命名配置。在 bootstrap_workshop.sh 指令碼中，您必須提供開始和最終使用者號碼。這些號碼可用來建立下列使用者名稱：

  • user<3 digit user number>@<organization_name>

舉例來說，如果您執行的 Bootstrap 工作坊指令碼包含初始使用者 1，使用者號碼為 3，則貴機構中為 yourcompany.com，會為下列使用者建立研討會環境：

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

系統會針對 setup_terraform_admin_project.sh 指令碼期間建立的特定專案，指派這些使用者名稱給這些專案的專案擁有者角色。使用 Bootstrap 指令碼時，必須遵守這個使用者命名結構定義。請參閱如何在 G Suite 中一次新增多位使用者。

研討會所需工具

本研討會旨在透過 Cloud Shell 自行啟動，本次研討會需要下列工具。

為自己設定研討會 (單一使用者設定)

  1. 開啟 Cloud Shell，並在 Cloud Shell 中執行下方的所有動作。請點選下方連結。

Cloud Shell

  1. 確認您已使用預期的管理員使用者身分登入 gcloud。
gcloud config list
  1. 建立 WORKDIR 並複製研討會存放區。
mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
  1. 定義機構名稱、帳單 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>
  1. 執行 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 管理員專案 ID，才能查看 terraform 管理員專案中的 Cloud Build 工作。這個檔案會儲存在 asm 目錄下的 vars/vars.sh 檔案中。只有在您以管理員身分設定研討會時，系統才會保留這個目錄。

  1. 來源變數檔案，以設定環境變數
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh

為多位使用者設定研討會 (多使用者設定)

  1. 開啟 Cloud Shell，並在 Cloud Shell 中執行下方的所有動作。請點選下方連結。

Cloud Shell

  1. 確認您已使用預期的管理員使用者身分登入 gcloud。
gcloud config list
  1. 建立 WORKDIR 並複製研討會存放區。
mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
  1. 定義貴機構名稱、帳單 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>
  1. 執行 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}
  1. 從管理員 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. 設定與準備研究室

選擇研究室路徑

本研討會的研究室可透過下列任一方式執行：

  • 「便捷的快速追蹤互動指令碼」方式
  • 「手動複製貼上每個指示」方式

快速追蹤指令碼方法可讓您為每個研究室執行單一互動式指令碼，透過自動執行該研究室的指令，讓您逐步完成研究室。這些指令會分批執行，其中包含每個步驟的簡要說明和指令完成的內容。每批次執行完後，系統都會提示你進行下一批指令。這樣就能按自己的步調執行研究室。快速追蹤指令碼具有冪等的特性，也就是說，您可以多次執行這些指令碼，獲得相同的結果。

快速追蹤指令碼會顯示在每個研究室頂端的綠色方塊中，如下所示。

「複製及貼上」是複製及貼上個別指令區塊的傳統方法，其中包含指令的說明。這個方法僅執行一次。即使在這個方法中重新執行指令，也會得到相同的結果。

進行研究室時，請從兩種方法中擇一使用。

快速追蹤指令碼設定

取得使用者資訊

本研討會使用臨時使用者帳戶 (或研究室帳戶)，由研討會管理員建立。這個研究室帳戶擁有研討會中的所有專案。研討會管理員將研究室帳戶憑證 (使用者名稱和密碼) 提供給執行研討會的使用者。使用者所有專案的前方都會加上研究室帳戶的使用者名稱，例如研究室帳戶 user001@yourcompany.com，Terraform 管理員專案 ID 會是 user001-200131-01-tf-abcde，以此類推。每位使用者都必須使用研討會管理員提供的研究室帳戶登入，並使用研究室帳戶進行研討會。

  1. 點選下方連結即可開啟 Cloud Shell。

Cloud Shell

  1. 使用研究室帳戶憑證登入 (請勿使用公司或學校帳戶登入)。研究室帳戶大致上是 userXYZ@<workshop_domain>.com。3101eca1fd3722bf.png
  2. 由於這是新帳戶，系統會提示您接受《Google 服務條款》。按一下「接受」。

fb0219a89ece5168.png 4.在下一個畫面中，勾選核取方塊來同意《Google 服務條款》，然後按一下 Start Cloud Shell。

7b198cf2e32cb457.png

這個步驟會佈建小型 Linux Debian VM，以便您存取 GCP 資源。每個帳戶都會有一個 Cloud Shell VM。請以研究室帳戶佈建帳戶的方式登入，並使用研究室帳戶憑證登入。除了 Cloud Shell 之外，您也可以透過佈建程式碼編輯器，更輕鬆地編輯設定檔 (terraform、YAML 等)。根據預設，Cloud Shell 畫面會分割為 Cloud Shell 殼層環境 (底部) 和 Cloud Code 編輯器 (位於頂端)。5643bb4ebeafd00a.png你可以使用鉛筆圖示 8bca25ef1421c17e.png 和右上角的殼層提示 eaeb4ac333783ba8.png 圖示，在殼層和程式碼編輯器之間切換。您也可以向上或向下拖曳中間分隔符列，並手動變更每個視窗的大小。5. 為這場研討會建立工作坊。WorkDIR 是一個資料夾，您將在此工作坊執行所有研究室。在 Cloud Shell 中執行下列指令來建立 WORKDIR。

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd`
  1. 將研究室帳戶使用者匯出為變數，以便用於這個研討會。也就是您登入 Cloud Shell 時使用的帳戶。
export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=user001@gcpworkshops.com
  1. 請忽略 WORKDIR 和 MY_USER 變數，透過執行下列指令來確保兩者都設定正確。
echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"
  1. 複製研討會存放區。
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm

5. 基礎架構設定 - 使用者工作流程

目標：驗證基礎架構和 Istio 安裝

  • 安裝研討會工具
  • 複製研討會存放區
  • 驗證「Infrastructure」安裝作業
  • 驗證「k8s-repo」安裝作業
  • 驗證 Istio 安裝作業

複製及貼上方法研究室操作說明

取得使用者資訊

研討會設定的管理員需將使用者名稱和密碼資訊提供給使用者。使用者所有專案的前方都會加上使用者名稱 user001@yourcompany.com，例如 terraform 管理員專案 ID 會是 user001-200131-01-tf-abcde，以此類推。每位使用者只能存取自己的研討會環境。

研討會所需工具

本研討會旨在透過 Cloud Shell 自行啟動，本次研討會需要下列工具。

存取 Terraform 管理員專案

Bootstrap_workshop.sh 指令碼完成後，系統就會為機構中的每位使用者建立 GCP 資料夾。系統會在資料夾中建立 terraform 管理員專案。terraform 管理員專案是用來建立本工作坊所需的其餘 GCP 資源。setup-terraform-admin-project.sh 指令碼會啟用 terraform 管理員專案中必要的 API。Cloud Build 用於套用 Terraform 方案。請透過指令碼為 Cloud Build 服務帳戶授予適當的 IAM 角色，讓帳戶能夠在 GCP 上建立資源。最後，遠端後端是在 Google Cloud Storage (GCS) 值區中設定，用於儲存所有 GCP 資源的 Terraform 狀態。

您需要 Terraform 管理員專案 ID，才能查看 terraform 管理員專案中的 Cloud Build 工作。這項資料會儲存在 Bootstrap 指令碼中指定的管理員 GCS 值區。如果您為多位使用者執行開機指令碼，所有 terraform 管理員專案 ID 都會在 GCS 值區中。

  1. 請點選下方連結，開啟 Cloud Shell (如果尚未在「研究室設定與準備」專區中開啟)。

Cloud Shell

  1. 如果尚未安裝在 $HOME/bin 資料夾中，請安裝 kustomize，並將 $HOME/bin 資料夾新增至 $PATH。
mkdir -p $HOME/bin
cd $HOME/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" >> $HOME/.bashrc
  1. 安裝 pv 並移至 $HOME/bin/pv。
sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv
  1. 更新 bash 提示。
cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
  1. 確認您已使用目標使用者帳戶登入 gcloud。
echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account
  1. 執行下列指令，取得 Terraform 管理員專案 ID：
export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
  1. 與研討會相關的所有資源都會以變數的形式，儲存在 terraform 管理員專案的 GCS 值區中。取得 terraform 管理員專案的 vars.sh 檔案。
mkdir $WORKDIR/asm/vars
gsutil cp gs://$TF_ADMIN/vars/vars.sh $WORKDIR/asm/vars/vars.sh
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
  1. 按一下顯示的連結，開啟 Terraform 管理員專案的 Cloud Build 頁面，並確認建構作業已順利完成。
source $WORKDIR/asm/vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"

如果是首次存取 Cloud 控制台，請同意《Google 服務條款》。

  1. 您現在已進入「Cloud Build」頁面，點選左側導覽列中的 History 連結，然後點選最新版本，即可查看套用初始 Terraform 設定的詳細資料。下列資源會做為 Terraform 指令碼的一部分建立。您也可以參考上方的架構圖。
  • 機構中的 4 項 GCP 專案。提供的帳單帳戶與各項專案相關聯。
  • 其中一項專案是共用虛擬私有雲的 network host project。這項專案中不會建立其他資源。
  • 一項專案是用於 Istio 控制層 GKE 叢集的 ops project。
  • 兩項專案代表兩個不同開發團隊處理各自的服務。
  • 三個 GKE 叢集分別建立於三個 ops、dev1 和 dev2 專案。
  • 已建立名稱為 k8s-repo 的 CSR 存放區，裡面有六個存放 Kubernetes 資訊清單檔案的資料夾。每個 GKE 叢集一個資料夾。這個存放區可用來以 GitOps 方式將 Kubernetes 資訊清單部署至叢集。
  • 系統會建立 Cloud Build 觸發條件，這樣一來，只要 k8s-repo 的主要分支版本有修訂，系統都會從各自的資料夾將 Kubernetes 資訊清單部署至 GKE 叢集。
  1. 在 terraform admin project 中完成建構作業後，另一個建構作業就會開始在作業專案中啟動。按一下顯示的連結，開啟 ops project 的 Cloud Build 頁面，並確認 k8s-repo Cloud Build 已順利完成。
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

驗證安裝

  1. 為所有叢集建立 kubeconfig 檔案。執行下列指令碼。
$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh

這個指令碼會在 gke 資料夾中建立名為 kubemesh 的新 kubeconfig 檔案。

  1. 將 KUBECONFIG 變數變更為指向新的 kubeconfig 檔案。
source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
  1. 將 vars.sh 和 KUBECONFIG var 新增至 Cloud Shell 中的 .bashrc 中，這樣每次重新啟動 Cloud Shell 時都會取得變數。
echo "source ${WORKDIR}/asm/vars/vars.sh" >> $HOME/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> $HOME/.bashrc
  1. 列出您的叢集結構定義。您應該會看到六個叢集。
kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

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 安裝

  1. 檢查所有 Pod 是否正在執行，工作也已完成，確保兩個叢集都已安裝 Istio。
kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

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

    `Output (do not copy)`

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
  1. 確保兩個 dev1 叢集都已安裝 Istio。dev1 叢集只會執行 Citadel、補充植入程式和 Coredns。並共用一個在 ops-1 叢集中執行的 Istio 控制層。
kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
  1. 確保兩個 dev2 叢集都已安裝 Istio。dev2 叢集只會執行 Citadel、補充植入程式和 Coredns。並共用一個在 ops-2 叢集中執行的 Istio 控制層。
kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

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

驗證共用控制層的服務探索作業

  1. (選用) 確認密鑰已部署完成。
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
 

    `Output (do not copy)`

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
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 叢集。如要探索不同叢集的服務，請使用在每個應用程式叢集上建立為密鑰的 kubeconfig 檔案。測試工具會查詢應用程式叢集的 Kube API 伺服器 (透過上述密鑰進行驗證)，運用這些密鑰來探索 Service。您會發現兩個作業叢集都能使用 kubeconfig-created 密鑰，向所有應用程式叢集進行驗證。作業叢集可以使用 kubeconfig 檔案做為密鑰方法，自動探索服務。必須讓 Ops 叢集中的 Pilot 存取所有其他叢集的 Kube API 伺服器。如果測試工具無法連線至 Kube API 伺服器，您必須手動將遠端服務新增為 ServiceEntries。您可以將 ServiceEntry 視為服務登錄檔中的 DNS 項目。ServiceEntry 使用完整 DNS 名稱 ( FQDN) 和可以連線的 IP 位址來定義服務。詳情請參閱 Istio Multicluster 說明文件。

6. 基礎架構存放區說明

基礎架構 Cloud Build

研討會的 GCP 資源是使用 Cloud Build 和 infrastructure CSR 存放區建構而成。您剛剛從本機終端機執行了啟動指令碼指令碼 (位於 scripts/bootstrap_workshop.sh)。Bootstrap 指令碼會為 Cloud Build 服務帳戶建立 GCP 資料夾、Terraform 管理員專案，以及適當的 IAM 權限。Terraform 管理員專案可用來儲存 Terraform 狀態、記錄檔和其他指令碼。其中包含 infrastructure 和 k8s_repo CSR 存放區。下一節將詳細說明這些存放區。Terraform 管理員專案中不會建立其他研討會資源。terraform 管理員專案中的 Cloud Build 服務帳戶可用來為研討會建立資源。

infrastructure 資料夾中的 cloudbuild.yaml 檔案可用來建構研討會的 GCP 資源。它會建立自訂建構工具映像檔，其中包含建立 GCP 資源所需的所有工具。這些工具包括 gcloud SDK、terraform 和 Python、git、jq 等其他公用程式。自訂建構工具映像檔會為每個資源執行 terraform plan 和 apply。每項資源的 Terraform 檔案位於不同的資料夾中 (詳情請見下一節)。系統會依據一般的建立方式，一次建立一個資源 (例如，在專案建立資源之前就已建立 GCP 專案)。詳情請參閱 cloudbuild.yaml 檔案。

每當有修訂至 infrastructure 存放區時，就會觸發 Cloud Build。您對基礎架構所做的任何變更都會儲存為基礎架構即程式碼 (IaC)，並提交至存放區。研討會的狀態一律會儲存在這個存放區中。

資料夾結構 - 團隊、環境和資源

基礎架構存放區會設定研討會的 GCP 基礎架構資源。則會結構化成資料夾和子資料夾。存放區中的基本資料夾代表擁有特定 GCP 資源的 team。下一層資料夾代表團隊的特定 environment (例如 dev、stage、prod)。環境中的下一層資料夾代表特定的 resource (例如 host_project、gke_clusters 等)。所需的指令碼和 Terraform 檔案位於資源資料夾中。

434fc1769bb49b8c.png

本研討會包含以下四種類型的團隊：

  1. 基礎架構 - 代表雲端基礎架構團隊。負責為其他團隊建立 GCP 資源。他們使用 Terraform 管理員專案處理資源。基礎架構存放區本身位於 Terraform 管理員專案，以及 Terraform 狀態檔案 (說明如下)。這些資源是由 bash 指令碼在啟動程序期間建立 (詳情請參閱單元 0 - 管理員工作流程)。
  2. network：代表網路團隊。對方負責虛擬私有雲和網路資源。他們擁有下列 GCP 資源。
  3. host project - 代表共用的虛擬私有雲主專案。
  4. shared VPC - 代表共用虛擬私有雲、子網路、次要 IP 範圍、路徑和防火牆規則。
  5. ops - 代表營運/開發團隊。該機構擁有下列資源。
  6. ops project - 代表所有作業資源的專案。
  7. gke clusters - 每個區域的作業 GKE 叢集。每個作業 GKE 叢集都已安裝 Istio 控制層。
  8. k8s-repo - CSR 存放區，內含所有 GKE 叢集的 GKE 資訊清單。
  9. apps - 代表應用程式團隊。本研討會模擬了 app1 和 app2 這兩個團隊，該機構擁有下列資源。
  10. app projects：每個應用程式團隊都有自己的一組專案。如此一來，他們就能控管特定專案的帳單和 IAM。
  11. gke clusters - 這些是執行應用程式容器/Pod 的應用程式叢集。
  12. gce instances - 如果客戶有在 GCE 執行個體上執行的應用程式，您也可以選擇使用。在本研討會中，app1 有兩個 GCE 執行個體，這些執行個體會在某部分執行。

在本研討會中，相同應用程式 (Hipster Shop 應用程式) 同時代表 app1 和 app2。

提供者、狀態和輸出 - 後端和共用狀態

google 和 google-beta 供應商位於 gcp/[environment]/gcp/provider.tf。每個資源資料夾中的 provider.tf 檔案都會建立符號連結。如此一來，您就能在單一位置變更提供者，而不必個別管理每個資源的提供者。

每個資源都包含 backend.tf 檔案，這個檔案定義了資源 tfstate 檔案的位置。這個 backend.tf 檔案是使用指令碼 (位於 scripts/setup_terraform_admin_project) 的範本 (位於 templates/backend.tf_tmpl) 產生，然後放入個別的資源資料夾。Google Cloud Storage (GCS) 值區用於後端。GCS 值區資料夾名稱與資源名稱相符。所有資源後端都位於 terraform 管理員專案中。

具有互通值的資源會包含 output.tf 檔案。所需的輸出值會儲存在該特定資源後端定義的 tfstate 檔案中。例如，如要在專案中建立 GKE 叢集，您必須先取得專案 ID。專案 ID 會透過 output.tf 輸出至 tfstate 檔案，並可透過 GKE 叢集資源中的 terraform_remote_state 資料來源使用。

Shared_state 檔案是指向資源 tfstate 檔案的 terraform_remote_state 資料來源。shared_state_[resource_name].tf 檔案 (一或多個) 位於需要其他資源輸出的資源資料夾中。舉例來說，ops_gke 資源資料夾中有來自 ops_project 和 shared_vpc 資源的 shared_state 檔案，因為您必須具備專案 ID 和虛擬私有雲詳細資料，才能在作業專案中建立 GKE 叢集。Shared_state 檔案是使用指令碼 (位於 scripts/setup_terraform_admin_project) 從範本 (位於 templates/shared_state.tf_tmpl) 產生。所有資源shared_state 檔案位於 gcp/[environment]/shared_states 資料夾中。必要的 shared_state 檔案在對應的資源資料夾中具有符號連結。將所有 shared_state 檔案放在同一個資料夾中，並以符號將其連結至適當的資源資料夾，可讓您輕鬆集中管理所有狀態檔案。

變數

所有資源值都會儲存為環境變數。這些變數會以匯出陳述式的形式儲存在 vars.sh 檔案中，該檔案位於 terraform 管理員專案的 GCS 值區中。其中包含機構 ID、帳單帳戶、專案 ID、GKE 叢集詳細資料等。您可以從任何終端機下載並擷取 vars.sh，以取得設定值。

Terraform 變數會以 TF_VAR_[variable name] 的形式儲存在 vars.sh 中。這些變數是用來在對應的資源資料夾中產生 variables.tfvars 檔案。variables.tfvars 檔案包含所有變數及其值。系統會使用指令碼 (位於 scripts/setup_terraform_admin_project) 並在同一個資料夾中，透過範本檔案產生 variables.tfvars 檔案。

K8s 存放區說明

k8s_repo 是 Terraform 管理員專案中的 CSR 存放區 (與基礎架構存放區分開)。可用於儲存 GKE 資訊清單，並套用至所有 GKE 叢集。k8s_repo 是由 Cloud Build 基礎架構建立 (詳情請參閱上一節)。在初始基礎架構 Cloud Build 程序中，系統會建立共六個 GKE 叢集。k8s_repo 建立了六個資料夾。每個資料夾 (與 GKE 叢集名稱相符的名稱) 都會對應至一個 GKE 叢集，其中包含個別的資源資訊清單檔案。與建構基礎架構類似，Cloud Build 可用來將 Kubernetes 資訊清單套用至使用 k8s_repo 的所有 GKE 叢集。每次有修訂 k8s_repo 存放區時，就會觸發 Cloud Build。與基礎架構類似，所有 Kubernetes 資訊清單都會以程式碼的形式儲存在 k8s_repo 存放區中，每個 GKE 叢集的狀態一律會儲存在各自的資料夾中。

做為初始基礎架構建構作業時，系統會建立 k8s_repo，並將 Istio 安裝在所有叢集。

專案、GKE 叢集和命名空間

本研討會中的資源分為不同的 GCP 專案。專案應符合貴公司的機構 (或團隊) 架構。貴機構中負責不同專案/產品/資源的團隊會使用不同的 GCP 專案。擁有獨立的專案可以讓您建立一組獨立的 IAM 權限，並在專案層級管理帳單。此外，配額也能按專案層級管理。

這場研討會由 5 個團隊組成，每個團隊有各自的專案。

  1. 建構 GCP 資源的基礎架構團隊會使用 Terraform admin project。他們會在 CSR 存放區 (稱為 infrastructure) 中以程式碼的形式管理基礎架構，並儲存與在 GCS 值區中建構的 GCP 資源相關的所有 Terraform 狀態資訊。並控管 CSR 存放區和 Terraform 狀態 GCS 值區的存取權。
  2. 建構共用虛擬私有雲的網路團隊會使用 host project。這項專案含有虛擬私有雲、子網路、路徑和防火牆規則。共用虛擬私有雲可讓客戶集中管理 GCP 資源的網路。所有專案都透過這個共用虛擬私有雲建立網路。
  3. 建構 GKE 叢集和 ASM/Istio 控制層的作業/平台團隊會使用 ops project。這類叢集會管理 GKE 叢集和服務網格的生命週期。他們負責強化叢集，管理 Kubernetes 平台的韌性和規模。在本研討會中，您將使用 Gitops 方法將資源部署至 Kubernetes。作業專案中存在 CSR 存放區 (稱為 k8s_repo)。
  4. 最後，開發應用程式的 dev1 和 dev2 團隊 (代表兩個開發團隊) 會使用自己的 dev1 和 dev2 projects。這些是你提供給客戶的應用程式和服務。這類元件是以作業團隊管理的平台為基礎。資源 (部署、服務等) 會推送至 k8s_repo，並部署至適當的叢集。值得注意的是，這場研討會的重點並非 CI/CD 最佳做法和工具，使用 Cloud Build 自動將 Kubernetes 資源部署至 GKE 叢集。在實際實際工作環境中，您會使用適當的 CI/CD 解決方案將應用程式部署至 GKE 叢集。

本研討會包含兩種 GKE 叢集，

  1. 作業叢集 - 營運團隊會使用這個叢集執行開發運作工具。在本研討會中，他們執行 ASM/Istio 控制層來管理服務網格。
  2. 應用程式 (應用程式) 叢集：開發團隊會使用這個叢集執行應用程式。在這個工作坊中，我們使用的是「Hister 商店」應用程式。

將作業/管理員工具與執行應用程式的叢集區隔開來，可讓您獨立管理各項資源的生命週期。這兩種叢集存在於與團隊/產品相關的不同專案中，因此 IAM 權限也易於管理。

GKE 叢集共有六個。作業專案中建立了兩個區域性營運叢集。ASM/Istio 控制層安裝在兩個作業叢集上。每個運算叢集位於不同區域。此外還有四個可用區應用程式叢集。這些類型是在各自的專案中建立。這個研討會以兩個開發團隊為例，說明兩個開發團隊有各自的專案，每項專案都包含兩個應用程式叢集。應用程式叢集是不同可用區中的可用區叢集。四個應用程式叢集位於兩個區域和四個可用區。取得區域與可用區備援功能。

本研討會中使用的應用程式「Hister Shop」應用程式，已部署至全部四個應用程式叢集。每個微服務都位於每個應用程式叢集的專屬命名空間中。嘻哈商店應用程式部署 (Pod) 未部署至營運叢集。不過，所有微服務的命名空間和服務資源也會在作業叢集中建立。ASM/Istio 控制層會使用 Kubernetes 服務註冊資料庫來探索服務。如果缺少 Service (在 Ops 叢集中)，您必須為應用程式叢集中執行的每項服務手動建立 ServiceEntry。

您在這個工作坊部署了 10 層微服務應用程式。這個應用程式是名為「「Hipster Shop」供使用者瀏覽商品、將商品加入購物車及購買。

Kubernetes 資訊清單和 k8s_repo

您可以使用 k8s_repo 將 Kubernetes 資源新增至所有 GKE 叢集。方法是複製 Kubernetes 資訊清單，並提交至 k8s_repo。k8s_repo 的所有修訂版本都會觸發 Cloud Build 工作，進而將 Kubernetes 資訊清單部署至個別叢集。每個叢集的資訊清單位於與叢集名稱相同的單獨資料夾中。

六個叢集的名稱如下：

  1. gke-asm-1-r1-prod：區域 1 中的區域性作業叢集
  2. gke-asm-2-r2-prod：區域 2 中的區域作業叢集
  3. gke-1-apps-r1a-prod - 區域 1 可用區中的應用程式叢集
  4. gke-2-apps-r1b-prod - 區域 1 可用區 b 中的應用程式叢集
  5. gke-3-apps-r2a-prod - 區域 2 可用區中的應用程式叢集
  6. gke-4-apps-r2b-prod：區域 2 可用區 b 中的應用程式叢集

k8s_repo 有與這些叢集相對應的資料夾。這些資料夾中的所有資訊清單都會套用至對應的 GKE 叢集。每個叢集的資訊清單會放在子資料夾 (位於叢集的主要資料夾內)，方便管理。在本研討會中，您將使用 Kustomize 追蹤已部署的資源。詳情請參閱 Kustomize 官方說明文件。

7. 部署範例應用程式

目標：在應用程式叢集上部署 Helloster Shop 應用程式

  • 複製k8s-repo
  • 將嘻哈商店資訊清單複製到所有應用程式叢集
  • 在 Ops 叢集中建立 Helloster Shop 應用程式的服務
  • 在 Ops 叢集中設定 loadgenerators，以測試全域連線
  • 驗證與嘻哈商店應用程式之間的安全連線

複製及貼上方法研究室操作說明

複製作業專案原始碼存放區

在初始 Terraform 基礎架構建構作業中，您已在作業專案中建立 k8s-repo。

  1. 為 Git 存放區建立空白目錄：
mkdir $WORKDIR/k8s-repo
  1. Init git 存放庫，新增遠端存放區，以及從遠端存放區提取主要執行個體：
cd $WORKDIR/k8s-repo
git init && git remote add origin \
https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo
  1. 進行本機 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

複製資訊清單、修訂並推送

  1. 將 Heatster Shop 命名空間和服務複製到所有叢集的原始碼存放區。
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.
  1. 將應用程式資料夾 kustomization.yaml 複製到所有叢集。
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/
  1. 將 Helloster Shop 部署作業、RBAC 和 PodSecurityPolicy 複製到應用程式叢集的原始碼存放區。
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
  1. 移除購物車服務部署作業、rbac 和 podsecuritypolicy，只保留一個開發叢集。Hellostershop 不是專為多叢集部署而打造，為了避免結果不一致，我們只使用一個購物車服務。
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml

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

rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml
  1. 將購物車服務部署作業、rbac 和 podsecuritypolicy 新增至第一個開發叢集中的 kustomization.yaml。
cd ${WORKDIR}/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
  1. 將 podsecuritypolicies、Deployment 和 rbac 目錄從 Ops 叢集 kustomization.yaml 中移除
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/kustomization.yaml
  1. 替換 RBAC 資訊清單中的 PROJECT_ID。
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  1. 將 IngressGateway 和 VirtualService 資訊清單複製到 Ops 叢集的原始碼存放區。
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
  1. 將 Config Connector 資源複製到每個專案中的其中一個叢集。
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/
  1. 取代設定連接器資訊清單中的 PROJECT_ID。
sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
  1. 將 loadgenerator 資訊清單 (Deployment、PodSecurityPolicy 和 RBAC) 複製到作業叢集。透過全域 Google Cloud 負載平衡器 (GCLB) 公開 Helloster 商店應用程式。GCLB 會接收用戶端流量 (目的地為 frontend)，並將流量傳送至最近的 Service 執行個體。在兩個作業叢集上都加入 loadgenerator，可確保流量能傳送至在 Ops 叢集中執行的兩個 Istio Ingress 閘道。下節將詳細說明負載平衡。
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/.
  1. 在兩個 Ops 叢集的 loadgenerator 資訊清單中，替換作業專案 ID。
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g'  \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
  1. 將 loadgenerator 資源新增至兩個作業叢集的 kustomization.yaml。
cd $WORKDIR/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 $WORKDIR/k8s-repo/$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
  1. 修訂至 k8s-repo。
cd $WORKDIR/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master
  1. 在先前開啟的分頁中，或點選以下連結查看作業套件專案 Cloud Build 的狀態：
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

驗證應用程式部署

  1. 確認所有應用程式命名空間中的 Pod (購物車除外) 在所有開發叢集中均處於「執行中」狀態。
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;

Output (do not copy)

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
  1. 確認購物車命名空間中的 Pod 處於「執行中」狀態 (僅在第一個開發叢集中)。
kubectl --context $DEV1_GKE_1 get pods -n cart;

Output (do not copy)

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

存取 Heatster Shop 應用程式

全域負載平衡

現在，您已成功將 Helloster Shop 應用程式部署至全部四個應用程式叢集。這些叢集位於兩個區域和四個可用區。用戶端可以透過存取 frontend 服務來存取嘻哈商店應用程式。frontend 服務會在全部四個應用程式叢集上執行。Google Cloud 負載平衡器 ( GCLB) 是用來將用戶端流量傳送至 frontend 服務全部四個執行個體的用戶端流量。

Istio Ingress 閘道只會在 Ops 叢集中執行，並做為區域性負載平衡器，用於該區域內的兩個可用區應用程式叢集。GCLB 使用兩個 Istio 輸入閘道 (在兩個作業叢集中執行) 做為全域前端服務的「後端」。Istio Ingress 閘道會接收來自 GCLB 的用戶端流量，然後將用戶端流量傳送至在應用程式叢集中執行的前端 Pod。

4c618df35cb928ee.png

或者，您也可以將 Istio Ingress 閘道直接放在應用程式叢集上，讓 GCLB 使用這些閘道做為後端。

GKE Autoneg 控制器

Istio Ingress 閘道 Kubernetes Service 使用網路端點群組 (NEG) 將本身註冊為 GCLB 的後端。NEG 允許使用 GCLB 進行容器原生負載平衡。NEG 是透過 Kubernetes Service 上的特殊註解建立，因此可將其註冊至 NEG 控制器。Autoneg 控制器是特殊的 GKE 控制器，可自動建立 NEG，並會使用服務註解將 NEG 指派為後端指派給 GCLB。系統會在初始基礎架構 Terraform Cloud Build 期間部署 Istio 輸入閘道等 Istio 控制層。GCLB 和 Autoneg 設定會在初始 Terraform 基礎架構 Cloud Build 中完成。

使用 Cloud Endpoints 和代管憑證確保輸入安全

GCP 代管憑證可用來保護傳送至 frontend GCLB 服務的用戶端流量。GCLB 會為全域 frontend 服務使用代管憑證，並由 GCLB 終止。在本研討會中，您將使用 Cloud Endpoints 做為代管憑證的網域。或者，您也可以使用您的網域和 DNS 名稱為 frontend 建立 GCP 代管憑證。

  1. 如要存取嘻哈商店，請點選下列指令的連結輸出內容。
echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog"
  1. 如要查看憑證是否有效，請按一下 Chrome 分頁網址列中的鎖頭符號。

6c403a63caa06c84.png

驗證全域負載平衡

在部署應用程式時，兩個作業叢集都部署了載入產生器，這兩個作業叢集會產生 GCLB 時尚商店 Cloud Endpoints 連結的測試流量。確認 GCLB 能夠接收流量，並傳送至兩個 Istio Ingress 閘道。

  1. 取得 GCLB >監控連結，找出建立嘻哈商店 GCLB 的 Ops 專案。
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"
  1. 如下所示，透過後端下拉式選單從「AllBackends」變更為「istio-ingressgateway」。

6697c9eb67998d27.png

  1. 請注意流向這兩個 istio-ingressgateways 的流量。

ff8126e44cfd7f5e.png

每個 istio-ingressgateway 會建立三個 NEG。由於 Ops 叢集屬於區域性叢集，因此系統會為區域中的每個可用區建立一個 NEG。不過，istio-ingressgateway Pod 會在每個區域的單一可用區中執行。流量會顯示在 istio-ingressgateway Pod 中。

兩個運算叢集皆正在執行載入產生器，以模擬來自兩個區域的用戶端流量。於作業叢集區域 1 中產生的負載將傳送至區域 2 中的 istio-ingressgateway。同樣地，作業叢集區域 2 中產生的負載也會傳送到區域 2 中的 istio-ingressgateway。

8. 使用 Stackdriver 進行觀測

目標：將 Istio 遙測資料連結至 Stackdriver 並進行驗證。

  • 安裝 istio-telemetry 項資源
  • 建立/更新 Istio 服務資訊主頁
  • 查看容器記錄檔
  • 在 Stackdriver 中查看分散式追蹤記錄

複製及貼上方法研究室操作說明

Istio 的主要功能之一是內建觀測能力 (「o11y」)。也就是說，即使使用黑箱、未檢測的容器，操作人員還是可以「觀察」這些容器進出的流量，為客戶提供服務。這項觀察結果以幾個不同方法 (即指標、記錄檔和追蹤記錄) 的形態。

我們也會使用 Stayster Shop 內建的內建載入系統。在沒有流量的靜態系統中，觀測能力的成效不盡理想，因此負載產生功能可協助我們瞭解運作方式。這項載入作業已在執行中，現在我們可以查看。

  1. 將 istio 安裝至 Stackdriver 設定檔。
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
  1. 提交至 k8s-repo。
cd $WORKDIR/k8s-repo
git add . && git commit -am "Install istio to stackdriver configuration"
git push
  1. 在先前開啟的分頁中，或點選以下連結查看作業套件專案 Cloud Build 的狀態：
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  1. 驗證 Istio → Stackdriver 整合 取得 Stackdriver 處理常式 CRD。
kubectl --context $OPS_GKE_1 get handler -n istio-system

輸出應會顯示名為 stackdriver 的處理常式：

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!
  1. 確認匯出至 Stackdriver 的 Istio 指標運作正常。按一下這個指令中的連結輸出：
echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=$TF_VAR_ops_project_name"

系統會提示您建立新工作區，並以作業專案的名稱命名，只要選擇「確定」即可。如果系統提示你使用新版 UI，只要關閉對話方塊即可。

在 Metrics Explorer 的「Find resource type and metric」(尋找資源類型和指標) 下方輸入「istio」以瞭解「伺服器要求數」等選項「Kubernetes 容器」資源類型這表示指標是從網格傳送到 Stackdriver。

(如要查看下方幾行，就必須開啟「分組依據 destination_service_name」標籤)。

b9b59432ee68e695.png

使用資訊主頁以圖表呈現指標資料：

既然我們的指標已經導入 Stackdriver APM 系統，我們也需要用圖表呈現指標。在本節中，我們會安裝預先建立的資訊主頁，顯示這四個「Golden Signals」指標：流量 (每秒要求數)、延遲時間 (本例中為第 99 和第 50 個百分位數) 以及「錯誤」 (本範例已排除「飽和度」)。

Istio 的 Envoy Proxy 提供多項指標，但建議一開始就派上用場。(完整清單請參閱這裡)。請注意，每個指標都有一組可用於篩選及匯總的標籤，例如 destination_service、source_workload_namespace、response_code、istio_tcp_received_bytes_total 等。

  1. 現在，我們要新增預先掃描的指標資訊主頁。我們會直接使用 Dashboard API。這通常可透過手動產生 API 呼叫執行，但這是自動化系統的一部分，或者是在網路使用者介面中手動建構資訊主頁。下列方式有助於我們快速上手：
sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' \
$WORKDIR/asm/k8s_manifests/prod/app-telemetry/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 @$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
  1. 請前往下方的輸出連結，查看新增的「服務資訊主頁」。
echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"

我們可以根據使用者體驗來就地編輯資訊主頁，但以本例來說，我們會使用 API 快速新增圖表。為此，請先下拉最新版本的資訊主頁、套用您的編輯內容，然後使用 HTTP PATCH 方法推送備份。

  1. 您可以查詢 Monitoring 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 > /tmp/services-dashboard.json
  1. 新增圖表：(第 50 個百分位數的延遲時間：[API 參考資料] 現在，我們可以在程式碼中新增圖表小工具。這項變更可由同業審查，並簽入版本管控。這個小工具會新增顯示第 50 個百分位數的延遲時間 (中位數)。

請嘗試編輯您剛取得的數字面板，新增主題：

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
  1. 更新現有的服務資訊主頁：
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 @/tmp/patched-services-dashboard.json
  1. 前往下列輸出連結，查看更新後的資訊主頁：
echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
  1. 進行簡單的記錄分析。

Istio 為所有網狀網路流量提供一組結構化記錄檔，並將記錄上傳至 Stackdriver Logging，透過單一強大的工具進行跨叢集分析。記錄檔中會加註服務等級的中繼資料，例如叢集、容器、應用程式、Connection_id 等。

記錄項目範例 (在本例中為 Envoy Proxy 的存取記錄檔) 可能如下所示 (經過剪輯)：

*** DO NOT PASTE *** 
 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」-

6f93b2aec6c4f520.png

這裡可以看到 Istio 控制層將每個範例應用程式服務的 Proxy 設定推送至補充 Proxy 設定。「CDS」「LDS」、和「RDS」代表不同的 Envoy API ( 瞭解詳情)。

除了 Istio 的記錄檔以外，您也可以在相同介面中查看容器記錄檔、基礎架構或其他 GCP 服務記錄檔。以下是一些 GKE 記錄檔查詢範例。記錄檢視器也可讓您從記錄檔建立指標 (例如「計算與部分字串相符的所有錯誤」)，以便用於資訊主頁或快訊。記錄檔也能串流至 BigQuery 等其他分析工具。

文青店適用的一些篩選器範例：

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

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

  1. 歡迎查看分散式追蹤記錄。

既然您已是使用分散式系統，當您進行偵錯時，就需要使用以下新工具：分散式追蹤。這項工具可讓您探索服務的互動情形統計資料 (例如，找出下圖中顯然緩慢的事件)，並且深入分析原始追蹤記錄樣本，以深入調查實際狀況。

時間軸檢視畫面會顯示一段時間以來的所有要求，並依延遲時間製作圖表，以圖表呈現延遲時間或初始要求之間花費的時間，透過 Hister 堆疊最終回應使用者。點越多，使用者體驗就越慢，且滿意度越低！

按一下圓點，即可查看該特定要求的詳細瀑布圖。這項功能可以找出特定要求的原始詳細資料 (而不只是匯總統計資料)，對於瞭解服務之間的交互作用十分重要，尤其在尋找罕見、但服務間互動不佳時更是如此。

凡是使用偵錯工具的使用者，應該都很熟悉「瀑布圖」檢視畫面；但在這個案例中，這裡顯示了在獨立容器中執行的服務，而不是顯示在單一應用程式的不同程序上花費的時間。

您可以在這裡找到追蹤記錄：

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

工具的螢幕截圖範例：

5ee238836dc9047f.png

9. 雙向傳輸層安全標準 (TLS) 驗證

目標：微服務之間的安全連線 (AuthN)。

  • 啟用網狀寬 mTLS
  • 檢查記錄以驗證 mTLS

複製及貼上方法研究室操作說明

現在應用程式已安裝完成，且觀測功能也設定完成，可以開始保護服務之間的連線安全，確保服務可以正常運作。

舉例來說，在 Kiali 資訊主頁中，我們發現我們的服務並未使用 MTLS (沒有「鎖頭」圖示)。但流量可以流動，且系統運作正常。StackDriver Golden Metrics 資訊主頁讓我們可以放心，整體作業仍在運作。

  1. 檢查作業叢集中的 MeshPolicy。注意：mTLS 設為 PERMISSIVE 允許加密和非 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'
 

    `Output (do not copy)`

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

凡是使用 Istio 運算子 (使用 IstioControlPlane 自訂資源 (CR)) 的叢集，都會設定 Istio。我們會更新 IstioControlPlane 罐頭回應並更新 k8s-repo，在所有叢集中設定 mTLS。設定全域 >mTLSenabled：在 IstioControlPlane CR 中，true 會產生下列 Istio 控制層變更：

  • MeshPolicy 可針對所有叢集內執行的所有服務開啟 mTLS 網格廣角功能。
  • 系統會建立 DestinationRule，藉此允許在所有叢集內執行的 Service 之間傳送 ISTIO_MUTUAL 流量。
  1. 我們會將 kustomize 修補程式套用至 istioControlPlane CR，以便支援 mTLS 叢集。請將修補程式複製到所有叢集的相關位置，然後新增 kustomize 修補程式。
cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml
  1. 提交至 k8s-repo。
cd $WORKDIR/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
  1. 在先前開啟的分頁中，或點選以下連結查看作業套件專案 Cloud Build 的狀態：
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

驗證 mTLS

  1. 在作業叢集中再次檢查 MeshPolicy。注意 mTLS 已不再是 PERMISSIVE，且僅允許使用 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": {}
    }
  ]
}
  1. 說明 Istio 運算子控制器建立的 DestinationRule。
kubectl --context $OPS_GKE_1 get DestinationRule default -n istio-system -o json | jq '.spec'
kubectl --context $OPS_GKE_2 get DestinationRule default -n istio-system -o json | jq '.spec'

輸出內容 (請勿複製)：

{
    host: '*.local',
    trafficPolicy: {
      tls: {
        mode: ISTIO_MUTUAL
      }
   }
}

我們也可以在記錄檔中看到從 HTTP 遷移至 HTTPS。

我們可以從使用者介面的記錄中公開這個特定欄位，只要按一下一個記錄項目，然後點選要顯示的欄位值即可。在本範例中，請按一下「http」「通訊協定：

d92e0c88cd5b2132.png

因此，這個視覺元素可清楚呈現轉換情形：

ea3d0240fa6fed81.png

10. 初期測試部署

目標：推出新版本的前端服務。

  • 在一個區域推出「frontend-v2」(下一個正式版本) 服務
  • 使用DestinationRules和VirtualServices，慢慢將車流往frontend-v2
  • 檢查 k8s-repo 的一系列修訂版本，驗證 GitOps 部署管道

複製及貼上方法研究室操作說明

「初期測試部署」是逐步推出新服務。在初期測試部署中，您將增加流量傳送至新版本，同時仍將剩餘百分比傳送到目前的版本。常見的模式是在流量拆分的每個階段執行初期測試分析，然後比較「黃金信號」與基準相比的新版本 (延遲時間、錯誤率、飽和度)。這不僅有助於防止服務中斷，並確保新版「v2」的穩定性在每個階段使用服務

在本節中，您將瞭解如何使用 Cloud Build 和 Istio 流量政策，為新版 Frontend 服務建立基本的初期測試部署。

首先，我們會在 DEV1 區域 (us-west1) 中執行 Canary 管道，並在該區域的兩個叢集上推出前端 v2。接著，我們會在 DEV2 區域 (us-central) 中執行 Canary 管道，並將第 2 版部署至該區域中的兩個叢集。在區域上執行管道，而非在所有區域中平行執行，可以避免因設定錯誤或 v2 應用程式本身發生錯誤而導致的全球服務中斷。

注意：我們會在這兩個區域中手動觸發 Canary 管道，但是在正式環境中，您應該使用自動化觸發條件，例如根據推送至登錄檔的新 Docker 映像檔標記。

  1. 在 Cloud Shell 中定義一些環境變數，簡化其他指令的執行程序。
CANARY_DIR="$WORKDIR/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="$WORKDIR/k8s-repo"
  1. 執行 repo_setup.sh 指令碼，將基準資訊清單複製到 k8s-repo。
$CANARY_DIR/repo-setup.sh

系統會複製下列資訊清單：

  • Frontend-v2 部署
  • Front-v1 修補程式 (加入「v1」標籤和含有「/version」端點的映像檔)
  • respy：這個小型 Pod 會輸出 HTTP 回應分佈情形，並幫助我們以視覺化的方式即時呈現初期測試部署。
  • 前端 Istio DestinationRule：根據「版本」將前端 Kubernetes Service 分為 v1 和 v2 兩個子集部署作業標籤
  • 前端 Istio VirtualService：將所有流量轉送至前端 v1。這會覆寫 Kubernetes Service 的預設循環行為，會立即將所有 Dev1 區域流量的 50% 傳送到前端 v2。
  1. 將變更提交至 k8s_repo：
cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
  1. 在先前開啟的分頁中，或點選以下連結查看作業套件專案 Cloud Build 的狀態：
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  1. 在 OPS1 專案的控制台中，前往 Cloud Build。等待 Cloud Build 管道完成，然後在兩個 DEV1 叢集的前端命名空間中取得 Pod。畫面應顯示如下：
watch -n 1 kubectl --context $DEV1_GKE_1 get pods -n frontend

Output (do not copy)

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

我們會使用 tmux 將 Cloud Shell 視窗分割為 2 個窗格：

  • 底部窗格將執行手錶指令，觀察前端服務的 HTTP 回應分佈情形。
  • 頂端窗格會執行實際的初期測試管道指令碼，
  1. 執行下列指令來分割 Cloud Shell 視窗，並在底部窗格中執行手錶指令。
RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"

輸出內容 (請勿複製)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+
  1. 在 Dev1 區域執行初期測試管道。我們提供一個指令碼，用於更新 VirtualService 中的 Front-v2 流量百分比 (將權重更新為 20%、50%、80%，然後 100%)。更新期間，指令碼會等待 Cloud Build 管道完成。執行 Dev1 區域的初期測試部署指令碼。注意：這個指令碼大約需要 10 分鐘才會完成。
K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_1_CLUSTER OPS_CONTEXT=$OPS_GKE_1 \
${CANARY_DIR}/auto-canary.sh

在執行 respy 指令的底部視窗中，您可以看到即時流量拆分畫面。例如，在 20% 標記處：

輸出內容 (請勿複製)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+
  1. Dev2 推出 Front-v2 的推出作業完成後，指令碼結束時應該會顯示成功訊息：
     Output (do not copy) 

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod
  1. Dev2 Pod 傳出的所有前端流量也應分配到 Front-v2：
     Output (do not copy) 

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+
  1. 關閉分割窗格。
tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'
  1. 透過系統產生的連結前往 Cloud Source Repos。
echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

您應該會看到每個流量百分比的個別修訂版本，清單最上方會顯示最新的修訂版本：

b87b85f52fd2ff0f.png

現在，請針對 Dev2 區域重複執行相同的程序。請注意，Dev2 區域仍處於「鎖定」狀態第 1 版。這是因為在基準 repo_setup 指令碼中，我們推送了 VirtualService 來明確將所有流量傳送至 v1。如此一來，我們就能在 Dev1 上安全地執行區域初期測試，並在全球推出新版本前確保測試成功執行。

  1. 執行下列指令來分割 Cloud Shell 視窗，並在底部窗格中執行手錶指令。
RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"

輸出內容 (請勿複製)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+
  1. 在 Dev2 區域執行初期測試管道。我們提供一個指令碼，用於更新 VirtualService 中的 Front-v2 流量百分比 (將權重更新為 20%、50%、80%，然後 100%)。更新期間，指令碼會等待 Cloud Build 管道完成。執行 Dev1 區域的初期測試部署指令碼。注意：這個指令碼大約需要 10 分鐘才會完成。
K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh

輸出內容 (請勿複製)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+
  1. 從 Dev2 的 Respy Pod 中，觀察來自 Dev2 Pod 的流量，從前端 v1 逐步移動到 v2。指令碼執行完畢後，您應該會看到：

輸出內容 (請勿複製)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+
  1. 關閉分割窗格。
tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

本節說明如何使用 Istio 進行區域初期測試部署。在實際工作環境中 (而非手動指令碼)，您可以使用觸發條件 (例如推送至 Container Registry 的新加上標記的映像檔)，自動將這個初期測試指令碼觸發為 Cloud Build 管道。您也可以在每個步驟之間加入初期測試分析，根據預先定義的安全性門檻分析 v2 的延遲時間和錯誤率，再傳送更多流量。

11. 授權政策

目標：設定微服務之間的 RBAC (AuthZ)。

  • 建立 AuthorizationPolicy 以存取微服務
  • 建立「AuthorizationPolicy」即可「允許」微服務的特定存取權

複製及貼上方法研究室操作說明

分散式微服務應用程式會在網路邊界內發出呼叫，而不是在單一位置執行的單體式應用程式。這代表使用者可以透過更多管道進入您的應用程式，進而獲得更多惡意攻擊機會。此外，由於 Kubernetes Pod 具有暫時 IP，因此傳統的 IP 型防火牆規則已不足以保護工作負載之間的存取安全。在微服務架構中，必須採用新的安全防護方法。Istio 以服務帳戶等 Kubernetes 安全性構成元素為基礎，為應用程式提供一套靈活彈性的安全性政策。

Istio 政策涵蓋驗證和授權。「驗證」會驗證身分 (這是代表其身分的伺服器) 和「授權」驗證權限 (這個用戶端是否允許這麼做？)。在單元 1 (MeshPolicy) 的雙向傳輸層安全標準 (TLS) 章節中，我們介紹了 Istio 驗證。在本節中，我們將瞭解如何使用 Istio 授權政策控管我們其中一項應用程式工作負載 currencyservice 的存取權。

首先，我們會在全部 4 個開發叢集內部署一個 AuthorizationPolicy，關閉所有貨幣服務的存取權，並在前端觸發錯誤。然後，我們僅允許前端服務存取貨幣服務。

  1. 檢查 currency-deny-all.yaml 的內容。這項政策會使用 Deployment 標籤選取器來限制貨幣服務的存取權。請注意，沒有 spec 欄位：這表示這項政策會拒絕所選服務的所有存取要求。
cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml

輸出內容 (請勿複製)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  1. 將兩個區域的作業叢集貨幣政策複製到 k8s-repo。
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
  1. 推送變更。
cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push
  1. 在先前開啟的分頁中，或點選以下連結查看作業套件專案 Cloud Build 的狀態：
echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
  1. 建構成功完成之後，請嘗試透過以下連結，在瀏覽器中連線至 Hellostershop 前端：
echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog"

你應該會看到貨幣服務提供的授權錯誤：

f120f3d30d6ee9f.png

  1. 讓我們調查貨幣服務強制執行此 AuthorizationPolicy 的方式。首先，在 Envoy Proxy 上針對其中一個貨幣 Pod 啟用追蹤層級記錄，因為根據預設，系統不會記錄封鎖的授權呼叫。
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 -- curl -X POST \
"http://localhost:15000/logging?level=trace"
  1. 從貨幣服務的補充 Proxy 取得 RBAC (授權) 記錄。您應該會看到「強制執行遭拒」訊息訊息，表示貨幣服務已設為封鎖所有傳入要求。
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
  1. 現在，讓我們允許前端 (而非其他後端服務) 存取貨幣服務。開啟 currency-allow-frontend.yaml 並檢查內容。請注意，我們新增了以下規則：
cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

輸出內容 (請勿複製)

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

我們將特定 source.principal (用戶端) 加入許可清單，以便存取貨幣服務。這個 source.principal 是由 Kubernetes 服務帳戶定義。在這個案例中，我們加入許可清單的服務帳戶是前端命名空間中的前端服務帳戶。

注意：在 Istio AuthorizationPolicies 中使用 Kubernetes 服務帳戶時，您必須先啟用全叢集的雙向 TLS，這點與單元 1 相同。這麼做可確保服務帳戶憑證掛接到要求中。

  1. 複製新版貨幣政策
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
  1. 推送變更。
cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
  1. 在先前開啟的分頁中，或點選以下連結查看作業套件專案 Cloud Build 的狀態：
echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
  1. 建構成功完成後，再次開啟 Heatstershop 前端。這次首頁應該不會有任何錯誤，這是因為已明確允許前端存取目前的服務。
  2. 現在，請嘗試將商品加入購物車，然後按一下 [下單] 來進行結帳。這次您應該會在貨幣服務中看到價格轉換錯誤，這是因為我們只將前端加入許可清單，所以結帳服務仍無法存取貨幣服務。

7e30813d693675fe.png

  1. 最後，在我們的貨幣服務 AuthorizationPolicy 中新增其他規則，讓結帳服務使用貨幣。請注意，我們僅開放需要存取資料的兩項服務 (前端和結帳) 開放貨幣存取權。其他後端仍會遭到封鎖。
  2. 開啟 currency-allow-frontend-checkout.yaml 並檢查內容。請注意，以邏輯函式「或」使用規則的清單而言，貨幣僅接受擁有這兩個服務帳戶之一的工作負載所發出的要求。
cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/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"]
  1. 將最終授權政策複製到 k8s-repo。
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
  1. 推送變更
cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
  1. 在先前開啟的分頁中，或點選以下連結查看作業套件專案 Cloud Build 的狀態：
echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
  1. 建構成功完成後，請嘗試執行結帳，應該就能順利執行。

本節逐步說明如何使用 Istio 授權政策，在每項服務層級強制執行精細的存取權控管機制。在實際工作環境中，您可以為每個服務建立一個 AuthorizationPolicy，然後 (例如) 使用「allow-all 政策」，讓相同命名空間中的所有工作負載互相存取。

12. 基礎架構資源調度

目標：透過新增區域、專案和叢集來擴充基礎架構。

  • 複製 infrastructure 存放區
  • 更新 Terraform 檔案來建立新資源
  • 新的區域有 2 個子網路 (一個用於 Ops 專案，另一個用於新專案)
  • 新的區域 (位於新的子網路) 的新運算叢集
  • 為新的區域新增 Istio 控制層
  • 新區域中的新專案含有 2 個應用程式叢集
  • 修訂「infrastructure」存放區
  • 驗證安裝

複製及貼上方法研究室操作說明

擴充平台的方法很多，您可以在現有叢集中新增節點，新增更多運算作業。您可以在單一區域中新增更多叢集。或者，您也可以在平台中新增更多區域。將平台的哪些部分做為擴充規模，取決於各項需求。舉例來說，如果您在某個區域的全部三個可用區都含有叢集，或許就能在現有叢集中新增更多節點 (或節點集區) 以滿足需求。不過，如果您在單一區域中設有兩個可用區的兩個可用區，則在第三個可用區中新增叢集，這樣就能調度資源並新增一個錯誤網域 (即新的可用區)。另一個在區域新增叢集的原因，可能是需要建立單一用戶群叢集，基於法規或法規遵循理由 (例如 PCI，或儲存 PII 資訊的資料庫叢集)。隨著您的業務和服務的規模擴大，加入新區域勢必將無法提供更接近客戶需求的服務。

目前的平台由兩個區域和叢集組成，每個區域位於兩個可用區。您可以透過以下兩種方式來擴充平台：

  • 垂直 - 在每個區域內新增更多運算量。方法是在現有叢集中新增更多節點 (或節點集區)，或是在區域中新增叢集。方法是透過 infrastructure 存放區完成。最簡單的路徑就是為現有叢集新增節點。您不需要額外設定。新增叢集可能需要額外的子網路 (和次要範圍)、新增合適的防火牆規則、將新叢集新增至區域性 ASM/Istio 服務網格控制層，以及將應用程式資源部署至新叢集。
  • 水平 - 新增更多區域。目前平台提供區域性範本。當中包含一個區域性作業叢集，當中有 ASM/Istio 控管，位於該叢集內，以及兩個 (或更多) 已部署應用程式資源的區域應用程式叢集。

在本研討會中，您將「水平」擴充平台其中也包含產業用途的步驟為了水平調整，在平台中新增區域 (r3) 來水平擴充平台，必須新增下列資源：

  1. 在區域 r3 中，新作業和應用程式叢集共用虛擬私有雲的主專案子網路。
  2. ASM/Istio 控制層位於區域 r3 中的區域性作業叢集。
  3. 在地區 r3 的兩個可用區中，兩個可用區應用程式叢集。
  4. 更新至 k8s-repo：
  5. 將 ASM/Istio 控制層資源部署至區域 r3 中的作業叢集。
  6. 將 ASM/Istio 共用的控制層資源部署至區域 r3 中的應用程式叢集。
  7. 雖然您不需要建立新專案，但研討會中的步驟示範如何新增專案 dev3，藉此介紹在平台中新增團隊的用途。

基礎架構存放區可用來新增上述資源。

  1. 在 Cloud Shell 中前往「WORKDIR」，然後複製 infrastructure 存放區。
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
  1. 將研討會原始碼存放區 add-proj 分支版本複製到 add-proj-repo 目錄。
cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj
  1. 從來源研討會存放區中的 add-proj 分支版本複製檔案。add-proj 分支版本包含這個部分的變更。
cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/
  1. 將 add-proj 存放區目錄中的 infrastructure 目錄替換為 infra-repo 目錄的符號連結，即可讓分支版本的指令碼執行。
rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure
  1. 執行 add-project.sh 指令碼，將共用狀態和變數複製到新的專案目錄結構。
$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo
  1. 修訂並推送變更，建立新專案
cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master
  1. 修訂版本會觸發 infrastructure 存放區，透過新的資源部署基礎架構。如要查看 Cloud Build 進度，請按一下下列連結的輸出內容，並前往頂端的最新建構作業。
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"

infrastructure Cloud Build 的最後一個步驟，會在 k8s-repo 中建立新的 Kubernetes 資源。這會在 Ops 專案中觸發 k8s-repo 中的 Cloud Build。新的 Kubernetes 資源適用於上一個步驟中新增的三個新叢集。透過 k8s-repo Cloud Build，系統會將 ASM/Istio 控制層和共用的控制層資源新增至新叢集。

  1. 基礎架構 Cloud Build 成功完成後，點選下列輸出連結，前往最新的 Cloud Build 執行作業 k8s-repo。
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  1. 執行下列指令碼，將新叢集加入 vars 和 kubeconfig 檔案。
$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm
  1. 將 KUBECONFIG 變數變更為指向新的 kubeconfig 檔案。
source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
  1. 列出您的叢集結構定義。您應該會看到八個叢集。
kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

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 安裝

  1. 檢查所有 Pod 是否正在運作且工作已完成，確保 Istio 已安裝到新的作業叢集。
kubectl --context $OPS_GKE_3 get pods -n istio-system
 

    `Output (do not copy)`

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
  1. 確保兩個 dev3 叢集都已安裝 Istio。dev3 叢集只會執行 Citadel、補充植入程式和 Coredns。他們會共用在 ops-3 叢集中執行的 Istio 控制層。
kubectl --context $DEV3_GKE_1 get pods -n istio-system
kubectl --context $DEV3_GKE_2 get pods -n istio-system
 

    `Output (do not copy)`

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

驗證共用控制層的服務探索作業

  1. 針對全部六個應用程式叢集，確認所有作業叢集已部署密鑰。
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
 

    `Output (do not copy)`

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

13. 斷路器

目標：實作運送服務的電路斷路器。

  • 為 shipping 服務建立 DestinationRule，實作斷路器
  • 使用 fortio (負載產生公用程式) 強制「離開」電路，驗證 shipping 服務的斷路器

快速追蹤指令碼研究室操作說明

「Fast Track Script Lab」即將推出！

複製及貼上方法研究室操作說明

我們已針對啟用 Istio 的服務介紹一些基本的監控和疑難排解策略，接著來看看 Istio 如何協助您提升服務的彈性，減少一開始必須執行的疑難排解作業。

微服務架構具有「連鎖性故障」的風險，當某個服務故障時，會傳播至其依附元件，以及這些依附元件的依附元件，進而造成「漣漪效應」可能會導致使用者受到影響Istio 提供斷路器流量政策，可協助您隔離服務、防止下游 (用戶端) 服務等待失敗服務，並保護上游 (伺服器端) 服務避免服務恢復上線時突然流起的下游流量。整體而言，使用斷路器可以避免所有服務因一項後端服務停止運作而失敗 SLO。

斷路器模式是針對可「脫掉」的電開關命名避免裝置過載。在 Istio 設定中，這表示 Envoy 是斷路器，可追蹤服務的待處理要求數量。在這個預設的關閉狀態下，要求會順利通過 Envoy，而不會中斷。

但如果待處理要求的數量超過您設定的門檻，斷路器會跳出 (開啟) 和 Envoy 立即傳回錯誤。如此可讓伺服器針對用戶端迅速失敗，並防止伺服器應用程式程式碼在超載時接收用戶端的要求。

而在定義的逾時時間過後，Envoy 會變為半開放狀態，伺服器可以預期方式再次開始接收要求；如果可以成功回應要求，斷路器就會再次關閉，伺服器的要求再次開始流動。

這份圖表列出了 Istio 斷路器模式的摘要。藍色長方形代表 Envoy，藍色填滿的圓圈代表用戶端，白色的圓圈則代表伺服器容器：

2127a0a172ff4802.png

您可以使用 Istio DestinationRules 定義斷路器政策。本章節會套用下列政策，為運送服務強制執行斷路器：

Output (do not copy)

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

這裡有兩個 DestinationRule 欄位需要注意。connectionPool 定義這項服務允許的連線數量。outlierDetection 欄位可讓 Envoy 決定開啟斷路器的門檻。在這個示例中，Envoy 會計算每秒從伺服器容器收到的錯誤數量，如果超過 consecutiveErrors 門檻，Envoy 斷路器會開啟，所有 100% 的產品目錄 Pod 都遭到新的用戶端要求封鎖 10 秒。Envoy 斷路器開啟 (即啟用) 後，用戶端會收到 503 (Service Unavailable) 錯誤。一起來看看實際的運作方式吧。

  1. 設定 k8s-repo 和 asm dir 的環境變數，藉此簡化指令。
export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm"
  1. 更新 k8s-repo
cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR
  1. 更新兩個 Ops 叢集的運送服務目的地規則。
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
  1. 將 Fortio 負載產生器 Pod 複製到 Dev1 區域中的 GKE_1 叢集。我們將使用這個用戶端 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
  1. 修訂變更。
cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
  1. 等待 Cloud Build 完成。
  2. 返回 Cloud Shell 後，使用 Fortio Pod 將 gRPC 流量傳送到具有 1 個並行連線、共 1,000 個要求的運送服務。由於尚未超過 connectionPool 設定，這項作業並不會讓斷路器跳脫。
FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

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

輸出內容 (請勿複製)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps
  1. 接著再次執行 Fortio，將同時連線數提高為 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
  1. 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
  1. 清除兩個區域的斷路器政策即可清除所用資源。
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 斷路器政策，您將有助於隔離微服務、將容錯能力建構到架構中，並降低在高負載情況下發生連鎖性故障的風險。

14. 錯誤植入

目標：設定延遲 (正式發布前)，測試推薦服務的彈性。

  • 為 recommendation Service 建立 VirtualService，以引入 5 秒的延遲時間
  • 使用 fortio 載入產生器測試延遲
  • 移除 VirtualService 中的延遲並驗證

快速追蹤指令碼研究室操作說明

「Fast Track Script Lab」即將推出！

複製及貼上方法研究室操作說明

為您的服務新增斷路器政策，是提高實際工作環境服務的韌性的方法之一。但斷路會導致錯誤 (使用者可能發生錯誤)，但這並不符合需求。如要避免發生這些錯誤情況，並更準確地預測下游服務在後端傳回錯誤時可能的回應方式，您可以在測試環境中進行混亂測試。混亂測試是刻意破壞服務的做法，目的是分析系統中的弱點並改善容錯能力。此外，您也可以在前端顯示快取結果 (例如，在前端顯示快取結果)，找出後端失敗時可減少使用者端錯誤的方法。

使用 Istio 進行錯誤植入會很有幫助，因為您可以使用實際工作環境的映像檔，並在網路層新增錯誤，而非修改原始碼。在實際工作環境中，除了網路層之外，您可以使用完善的Chaos 測試工具，測試 Kubernetes/運算層的彈性。

您可以使用 Istio 套用 VirtualService 並加上「fault」錯誤，以進行混亂測試] 欄位。Istio 支援兩種錯誤：延遲錯誤 (插入逾時) 和取消錯誤 (插入 HTTP 錯誤)。在本例中，我們會在建議服務中插入 5 秒延遲錯誤。但這次不使用斷路器來「快速失敗」我們就會強制下游服務結束全部逾時，

  1. 前往錯誤插入目錄。
export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
  1. 開啟 k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml 檢查內容。請注意，Istio 可選擇將錯誤植入特定比例的要求中，我們會針對所有推薦服務要求實施逾時設定。

輸出內容 (請勿複製)

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
  1. 將 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
  1. 推送變更
cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
  1. 等待 Cloud Build 完成。
  2. 執行於斷路器部分中部署的 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
 

    Once the fortio command is complete, you should see responses averaging 5s:

輸出內容 (請勿複製)

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
  1. 另一種查看插入錯誤的方法，是在網路瀏覽器中開啟前端，然後點選任何產品。產品頁面需要額外 5 秒才能載入資料，因為系統會擷取頁面底部顯示的推薦內容。
  2. 請從兩個作業套件叢集中移除錯誤植入服務，清除所用資源。
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
  1. 推送變更：
cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM

15. 監控 Istio 控制層

ASM 會安裝四個重要的控制層元件：Plot、Mixer、Galley 和 Citadel。每項服務都會將相關監控指標傳送至 Prometheus，ASM 也會隨附 Grafana 資訊主頁，讓操作人員以視覺化方式呈現監控資料，並評估控制層的健康狀態與效能。

查看資訊主頁

  1. 透過 Istio 安裝 Grafana 服務
kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null
  1. 在瀏覽器中開啟 Grafana
  2. 按一下 [網頁預覽]Cloud Shell 視窗右上角的圖示
  3. 按一下通訊埠 3000 的預覽 (請注意：如果通訊埠並非 3000，請按一下變更通訊埠，然後選取通訊埠 3000)
  4. 這會在瀏覽器中開啟分頁，網址類似於「BASE_URL/?orgId=1&authuser=0&environment_id=default"
  5. 查看可用的資訊主頁
  6. 將網址修改為BASE_URL/dashboard&quot;
  7. 按一下「istio」即可查看可用的資訊主頁
  8. 點選任一資訊主頁，即可查看該元件的成效。以下各節將介紹每個要素的重要指標。

監控前測

測試層是控制層元件，可將網路和政策設定分配到資料層 (Envoy Proxy)。前測計畫會根據工作負載和部署數量進行擴充，但不一定會隨著工作負載的流量增加。不健康的前測計畫可以：

  • 耗用更多資源 (CPU 和/或 RAM)
  • 會導致更新完成的設定資訊推送至 Envoys 時出現延遲

注意事項：如果前測計畫停止運作或發生延遲，工作負載仍會處理流量。

  1. 前往「BASE_URL/dashboard/db/istio-pilot-dashboard&quot;即可查看前測指標。

重要的受監控指標

資源使用情況

如要查看可接受的用量數據，請使用 Istio 效能與擴充性頁面。如果您發現資源用量明顯超過這個數值，請與 GCP 支援團隊聯絡。

5f1969f8e2c8b137.png

前測計畫推送資訊

這個專區會監控將設定推送至 Envoy Proxy 的前測作業。

  • 「Pilot Pushs」會顯示在任何指定時間推送的設定類型。
  • ADS 監控顯示系統中的虛擬服務、服務和已連結的端點數量。
  • 沒有已知端點的叢集會顯示已設定但執行個體未執行的任何端點 (可能顯示外部服務，例如 *.googleapis.com)。
  • 「前測錯誤」會顯示一段時間內發生的錯誤數量。
  • 「衝突」會顯示事件監聽器設定中不明確設定的衝突數量。

如有「錯誤」或「衝突」，就表示一或多項服務的設定有誤或不一致。詳情請參閱資料層疑難排解。

Envoy 資訊

本節包含與控制層聯繫的 Envoy Proxy 相關資訊。如果系統重複顯示 XDS 連線失敗記錄，請與 GCP 支援團隊聯絡。

監測混合器

Mixer 這個元件可將 Envoy Proxy 的遙測資料程序導向遙測後端 (通常是 Prometheus、Stackdriver 等)。這個容量並「不屬於」資料層。這會部署為兩個 Kubernetes 工作 (稱為 Mixer)，部署了兩種不同服務名稱 (istio-遙測和 istio-policy)。

Mixer 也可以用來整合政策系統。由於 Mixer 會進行政策檢查，導致服務無法存取服務，因此 Mixer 會「確實」影響資料層。

混合型業者傾向於根據流量調整規模。

  1. 前往「BASE_URL/dashboard/db/istio-mixer-dashboard&quot;中，即可查看 Mixer 指標。

重要監控指標

資源使用情況

如要查看可接受的用量數據，請使用 Istio 效能與擴充性頁面。如果您發現資源用量明顯超過這個數值，請與 GCP 支援團隊聯絡。

87ed83238f9addd8.png

混音器總覽

  • 「回應時間長度」是重要指標。雖然向 Mixer 遙測資料回報的情況「並不」在資料路徑中，但如果這些延遲時間偏高，一定會拖慢補充 Proxy 的效能。第 90 個百分位數應以個位數毫秒為單位，第 99 個百分位數則低於 100 毫秒。

e07bdf5fde4bfe87.png

  • Adapter Dispatch Duration 是指在呼叫轉接程式 (透過這個方式將資訊傳送至遙測和記錄系統) 時，發生延遲混合器的問題。這裡的延遲時間偏高，絕對會影響網格效能。同樣，p90 延遲時間應小於 10 毫秒。

1c2ee56202b32bd9.png

監控卡利

Galley 是 Istio 的設定驗證、擷取、處理和發布元件。並將 Kubernetes API 伺服器的設定傳遞至前測計畫。就像測試員一樣，它往往會隨著系統中的服務和端點數量進行擴充。

  1. 前往「BASE_URL/dashboard/db/istio-galley-dashboard&quot;即可查看 Galley 指標。

重要監控指標

資源驗證

應遵循的最重要指標，指出各種資源 (例如目的地規則、閘道和服務項目) 通過或驗證失敗的資源數量。

已連結的用戶端

指出有多少客戶已連線至 Galley；通常是 3 (前測、指標遙測、istio-policy)，且會隨著這些元件的擴展擴充。

16. 排解 Istio 問題

資料層疑難排解

如果測試資訊主頁顯示有設定問題，請查看前測計畫記錄，或使用 istioctl 找出設定問題。

如要檢查 Pilot 記錄，請執行 kubectl -n istio-system 記錄檔 istio-pilot-69db46c598-45m44 項探索，並將 istio-pilot-... 改成待解決前測執行個體的 Pod ID。

在顯示的記錄中，搜尋「Push Status」訊息。例如：

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 Proxy 時發生的任何問題。在這種情況下，系統會顯示幾個「重複的叢集」訊息，指出重複的上游目的地。

如需協助診斷問題，如有任何問題，請與 Google Cloud 支援團隊聯絡。

尋找設定錯誤

如要使用 istioctl 分析設定，請執行 istioctl experimental analyze -k --context $OPS_GKE_1。這項功能會分析系統中的設定，指出所有問題，以及任何建議的變更。如需這個指令可偵測的完整設定錯誤清單，請參閱說明文件。

17. 清除

管理員執行 cleanup_workshop.sh 指令碼，會刪除 bootstrap_workshop.sh 指令碼建立的資源。您需要以下資訊，才能執行清理指令碼。

  • 機構名稱 - 例如 yourcompany.com
  • 研討會 ID - 格式為 YYMMDD-NN，例如 200131-01
  • 管理員 GCS 值區 - 由啟動指令碼定義。
  1. 開啟 Cloud Shell，並在 Cloud Shell 中執行下方的所有動作。請點選下方連結。

Cloud Shell

  1. 確認您已使用預期的管理員使用者身分登入 gcloud。
gcloud config list
  1. 前往 asm 資料夾。
cd ${WORKDIR}/asm
  1. 定義要刪除的機構名稱和研討會 ID。
export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
  1. 按照下列方式執行清理指令碼。
./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}