เวิร์กช็อป Anthos Service Mesh: คู่มือห้องทดลอง

1. เวิร์กช็อปอัลฟ่า

ลิงก์ไปยัง Codelab ของเวิร์กช็อป bit.ly/asm-workshop

2. ภาพรวม

แผนภาพสถาปัตยกรรม

เวิร์กช็อปนี้เป็นประสบการณ์การใช้งานแบบอินเทอร์แอกทีฟที่อธิบายวิธีตั้งค่าบริการที่กระจายอยู่ทั่วโลกใน GCP ในการผลิต เทคโนโลยีหลักที่ใช้คือ Google Kubernetes Engine (GKE) สำหรับการประมวลผลและโครงข่ายบริการ Istio เพื่อสร้างการเชื่อมต่อที่ปลอดภัย การสังเกตการณ์ และการกำหนดรูปแบบการรับส่งข้อมูลขั้นสูง แนวทางปฏิบัติและเครื่องมือทั้งหมดที่ใช้ในเวิร์กช็อปนี้คือสิ่งที่คุณจะใช้ในการผลิต

กำหนดการ

โมดูล 0 - ข้อมูลเบื้องต้นและการตั้งค่าแพลตฟอร์ม
ข้อมูลเบื้องต้นและสถาปัตยกรรม
ข้อมูลเบื้องต้นเกี่ยวกับ Service Mesh และ Istio/ASM
Lab: Infrastructure Setup: User workflow
พัก
QnA
โมดูล 1 - ติดตั้ง รักษาความปลอดภัย และตรวจสอบแอปพลิเคชันด้วย ASM
รูปแบบที่เก็บ: อธิบายที่เก็บโครงสร้างพื้นฐานและ Kubernetes
Lab: ทำให้แอปพลิเคชันตัวอย่างใช้งานได้
บริการแบบกระจายและความสามารถในการสังเกตการณ์
อาหารกลางวัน
แล็บ: การสังเกตการณ์ด้วย Stackdriver
QNA
Module 2 - DevOps - Canary rollouts, policy/RBAC
การค้นพบบริการแบบหลายคลัสเตอร์และความปลอดภัย/นโยบาย
แล็บ: TLS ร่วม
การทำให้ Canary ใช้งานได้
Lab: การติดตั้งใช้งานแบบ Canary
การจัดสรรภาระงานทั่วโลกแบบหลายคลัสเตอร์ที่ปลอดภัย
พัก
Lab: นโยบายการให้สิทธิ์
QNA
Module 3 - Infra Ops - Platform upgrades
องค์ประกอบที่ใช้สร้างสรรค์ของ Distributed Service
Lab: การปรับขนาดโครงสร้างพื้นฐาน
ขั้นตอนถัดไป

สไลด์

คุณดูสไลด์สำหรับเวิร์กช็อปนี้ได้ที่ลิงก์ต่อไปนี้

สไลด์เวิร์กช็อป ASM

ข้อกำหนดเบื้องต้น

คุณต้องมีสิ่งต่อไปนี้ก่อนที่จะเข้าร่วมเวิร์กช็อปนี้

โหนดองค์กร GCP
รหัสบัญชีสำหรับการเรียกเก็บเงิน (ผู้ใช้ต้องเป็นผู้ดูแลระบบการเรียกเก็บเงินในบัญชีสำหรับการเรียกเก็บเงินนี้)
บทบาท IAM ของผู้ดูแลระบบองค์กรที่ระดับองค์กรสำหรับผู้ใช้

3. การตั้งค่าโครงสร้างพื้นฐาน - เวิร์กโฟลว์ของผู้ดูแลระบบ

คำอธิบายสคริปต์เวิร์กช็อป Bootstrap

ระบบจะใช้สคริปต์ที่ชื่อ bootstrap_workshop.sh เพื่อตั้งค่าสภาพแวดล้อมเริ่มต้นสำหรับเวิร์กช็อป คุณสามารถใช้สคริปต์นี้เพื่อตั้งค่าสภาพแวดล้อมเดียวสำหรับตัวคุณเอง หรือสภาพแวดล้อมหลายรายการสำหรับผู้ใช้หลายรายในกรณีที่คุณจัดเวิร์กช็อปนี้เป็นการฝึกอบรมให้กับผู้ใช้หลายราย

สคริปต์การเวิร์กช็อปการเริ่มต้นระบบต้องใช้ข้อมูลต่อไปนี้เป็นอินพุต

ชื่อองค์กร (เช่น yourcompany.com) - นี่คือองค์กรที่คุณสร้างสภาพแวดล้อมสำหรับเวิร์กช็อป
รหัสการเรียกเก็บเงิน (เช่น 12345-12345-12345) - รหัสการเรียกเก็บเงินนี้ใช้ในการเรียกเก็บเงินสำหรับทรัพยากรทั้งหมดที่ใช้ในระหว่างเวิร์กช็อป
หมายเลขเวิร์กช็อป (เช่น 01) - หมายเลข 2 หลัก ซึ่งใช้ในกรณีที่คุณจัดเวิร์กช็อปหลายรายการในวันเดียวและต้องการติดตามแยกกัน นอกจากนี้ยังใช้หมายเลขเวิร์กช็อปเพื่อสร้างรหัสโปรเจ็กต์ด้วย การมีหมายเลขเวิร์กช็อปแยกกันจะช่วยให้คุณมั่นใจได้ง่ายขึ้นว่าจะได้รับรหัสโปรเจ็กต์ที่ไม่ซ้ำกันในแต่ละครั้ง นอกจากหมายเลขเวิร์กช็อปแล้ว ระบบยังใช้ข้อมูลวันที่ปัจจุบัน (จัดรูปแบบเป็น YYMMDD) สำหรับรหัสโปรเจ็กต์ด้วย การผสมผสานระหว่างวันที่และหมายเลขเวิร์กช็อปจะให้รหัสโปรเจ็กต์ที่ไม่ซ้ำกัน
หมายเลขผู้ใช้เริ่มต้น (เช่น 1) - หมายเลขนี้แสดงถึงผู้ใช้คนแรกในเวิร์กช็อป เช่น หากต้องการสร้างเวิร์กช็อปสำหรับผู้ใช้ 10 คน คุณอาจมีหมายเลขผู้ใช้เริ่มต้นเป็น 1 และหมายเลขผู้ใช้สิ้นสุดเป็น 10
หมายเลขผู้ใช้ปลายทาง (เช่น 10) - หมายเลขนี้แสดงถึงผู้ใช้คนสุดท้ายในเวิร์กช็อป เช่น หากต้องการสร้างเวิร์กช็อปสำหรับผู้ใช้ 10 คน คุณอาจมีหมายเลขผู้ใช้เริ่มต้นเป็น 1 และหมายเลขผู้ใช้สิ้นสุดเป็น 10 หากคุณกำลังตั้งค่าสภาพแวดล้อมเดียว (เช่น สำหรับตัวคุณเอง) ให้กำหนดหมายเลขผู้ใช้เริ่มต้นและสิ้นสุดให้เหมือนกัน ซึ่งจะเป็นการสร้างสภาพแวดล้อมเดียว

นอกจากวันที่และหมายเลขเวิร์กช็อปแล้ว ระบบยังรวมหมายเลขผู้ใช้เริ่มต้นและหมายเลขผู้ใช้สิ้นสุดไว้ในรหัสโปรเจ็กต์ด้วย ระบบจะดึงข้อมูลรหัสผู้ใช้ (สําหรับผู้ใช้ที่เข้าร่วมเวิร์กช็อป) จากหมายเลขผู้ใช้เริ่มต้นและหมายเลขผู้ใช้สิ้นสุด เราอธิบายรหัสผู้ใช้ไว้ในส่วนที่ชื่อว่า User schema and permissions performing the workshop

ที่เก็บข้อมูล GCS ของผู้ดูแลระบบ (เช่น my-gcs-bucket-name) - ที่เก็บข้อมูล GCS ใช้เพื่อจัดเก็บข้อมูลที่เกี่ยวข้องกับเวิร์กช็อป สคริปต์ cleanup_workshop.sh จะใช้ข้อมูลนี้เพื่อลบทรัพยากรทั้งหมดที่สร้างขึ้นระหว่างสคริปต์เวิร์กช็อปการเริ่มต้นระบบอย่างราบรื่น ผู้ดูแลระบบที่สร้างเวิร์กช็อปต้องมีสิทธิ์อ่าน/เขียนในที่เก็บข้อมูลนี้

สคริปต์เวิร์กช็อปการเริ่มต้นระบบใช้ค่าที่ระบุไว้ข้างต้นและทำหน้าที่เป็นสคริปต์ Wrapper ที่เรียกใช้สคริปต์ setup-terraform-admin-project.sh สคริปต์ setup-terraform-admin-project.sh จะสร้างสภาพแวดล้อมเวิร์กช็อปสำหรับผู้ใช้รายเดียว

สิทธิ์ผู้ดูแลระบบที่จำเป็นสำหรับการเริ่มต้นเวิร์กช็อป

ผู้เข้าร่วมเวิร์กช็อปนี้มี 2 ประเภท ADMIN_USER ซึ่งสร้างและลบทรัพยากรสำหรับเวิร์กช็อปนี้ คนที่ 2 คือ MY_USER ซึ่งทำตามขั้นตอนในเวิร์กช็อป MY_USER มีสิทธิ์เข้าถึงทรัพยากรของตัวเองเท่านั้น ADMIN_USER มีสิทธิ์เข้าถึงการตั้งค่าของผู้ใช้ทั้งหมด หากคุณกำลังสร้างการตั้งค่านี้สำหรับตัวคุณเอง ADMIN_USER และ MY_USER จะเหมือนกัน หากคุณเป็นผู้สอนที่สร้างเวิร์กช็อปนี้ให้นักเรียนหลายคน ADMIN_USER และ MY_USER จะแตกต่างกัน

ADMIN_USER ต้องมีสิทธิ์ระดับองค์กรต่อไปนี้

เจ้าของ - สิทธิ์เจ้าของโปรเจ็กต์สำหรับโปรเจ็กต์ทั้งหมดในองค์กร
ผู้ดูแลระบบโฟลเดอร์ - ความสามารถในการสร้างและลบโฟลเดอร์ในองค์กร ผู้ใช้ทุกคนจะได้รับโฟลเดอร์เดียวที่มีทรัพยากรทั้งหมดของตนเองภายในโปรเจ็กต์
ผู้ดูแลระบบขององค์กร
ผู้สร้างโปรเจ็กต์ - ความสามารถในการสร้างโปรเจ็กต์ในองค์กร
ผู้ลบโปรเจ็กต์ - ความสามารถในการลบโปรเจ็กต์ในองค์กร
ผู้ดูแลระบบ IAM ของโปรเจ็กต์ - ความสามารถในการสร้างกฎ IAM ในโปรเจ็กต์ทั้งหมดในองค์กร

นอกจากนี้ ADMIN_USER ต้องเป็นผู้ดูแลระบบการเรียกเก็บเงินสำหรับรหัสการเรียกเก็บเงินที่ใช้ในเวิร์กช็อปด้วย

สคีมาผู้ใช้และสิทธิ์ที่ใช้ในการเวิร์กช็อป

หากวางแผนที่จะสร้างเวิร์กช็อปนี้สำหรับผู้ใช้ (คนอื่นๆ ในองค์กร) คุณต้องทำตามรูปแบบการตั้งชื่อผู้ใช้ที่เฉพาะเจาะจงสำหรับ MY_USERs ในสคริปต์ bootstrap_workshop.sh คุณจะต้องระบุหมายเลขผู้ใช้เริ่มต้นและสิ้นสุด ระบบจะใช้หมายเลขเหล่านี้เพื่อสร้างชื่อผู้ใช้ต่อไปนี้

user<3 digit user number>@<organization_name>

เช่น หากคุณเรียกใช้สคริปต์เวิร์กช็อปการเริ่มต้นด้วยหมายเลขผู้ใช้เริ่มต้นเป็น 1 และหมายเลขผู้ใช้สิ้นสุดเป็น 3 ในองค์กรที่ชื่อว่า yourcompany.com ระบบจะสร้างสภาพแวดล้อมเวิร์กช็อปสำหรับผู้ใช้ต่อไปนี้

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

ระบบจะกำหนดบทบาทเจ้าของโปรเจ็กต์ให้กับชื่อผู้ใช้เหล่านี้สำหรับโปรเจ็กต์ที่เฉพาะเจาะจงซึ่งสร้างขึ้นในระหว่างสคริปต์ setup_terraform_admin_project.sh คุณต้องปฏิบัติตามรูปแบบการตั้งชื่อผู้ใช้นี้เมื่อใช้สคริปต์การเริ่มต้นระบบ โปรดดูวิธีเพิ่มผู้ใช้หลายรายพร้อมกันใน G Suite

เครื่องมือที่จำเป็นสำหรับเวิร์กช็อป

เวิร์กช็อปนี้มีไว้เพื่อเริ่มต้นจาก Cloud Shell คุณต้องมีเครื่องมือต่อไปนี้สำหรับเวิร์กช็อปนี้

gcloud (เวอร์ชัน >= 270)
kubectl
sed (ใช้ได้กับ sed ใน Cloud Shell/Linux และใช้ไม่ได้กับ Mac OS)
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

กำหนดชื่อองค์กร รหัสการเรียกเก็บเงิน หมายเลขเวิร์กช็อป และที่เก็บข้อมูล 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 admin project ภายในโฟลเดอร์ โปรเจ็กต์ผู้ดูแลระบบ Terraform ใช้เพื่อสร้างทรัพยากร GCP ที่เหลือที่จำเป็นสำหรับเวิร์กช็อปนี้ คุณเปิดใช้ API ที่จำเป็นในโปรเจ็กต์ผู้ดูแลระบบ Terraform คุณใช้ Cloud Build เพื่อใช้แผน Terraform คุณให้บทบาท IAM ที่เหมาะสมแก่บัญชีบริการ Cloud Build เพื่อให้สร้างทรัพยากรใน GCP ได้ สุดท้าย ให้กำหนดค่าแบ็กเอนด์ระยะไกลใน Bucket ของ Google Cloud Storage (GCS) เพื่อจัดเก็บ สถานะ Terraform สำหรับทรัพยากร GCP ทั้งหมด

หากต้องการดูงาน Cloud Build ในโปรเจ็กต์ผู้ดูแลระบบ Terraform คุณต้องมีรหัสโปรเจ็กต์ผู้ดูแลระบบ Terraform ซึ่งจะเก็บอยู่ในไฟล์ vars/vars.sh ในไดเรกทอรี asm ระบบจะเก็บไดเรกทอรีนี้ไว้ก็ต่อเมื่อคุณตั้งค่าเวิร์กช็อปสำหรับตัวคุณเองในฐานะผู้ดูแลระบบ

เรียกใช้ไฟล์ตัวแปรเพื่อตั้งค่าตัวแปรสภาพแวดล้อม

echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh

ตั้งค่าเวิร์กช็อปสำหรับผู้ใช้หลายคน (การตั้งค่าแบบหลายผู้ใช้)

เปิด 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

กำหนดชื่อองค์กร, รหัสการเรียกเก็บเงิน, หมายเลขเวิร์กช็อป, หมายเลขผู้ใช้เริ่มต้นและสิ้นสุด และที่เก็บข้อมูล 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}

รับไฟล์ workshop.txt จากที่เก็บข้อมูล GCS ของผู้ดูแลระบบเพื่อดึงรหัสโปรเจ็กต์ Terraform

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

4. การตั้งค่าและการเตรียมห้องทดลอง

เลือกเส้นทางห้องทดลอง

แล็บในเวิร์กช็อปนี้สามารถทำได้ 2 วิธี ดังนี้

วิธี "สคริปต์แบบอินเทอร์แอกทีฟที่รวดเร็วและง่ายดาย"
วิธี "คัดลอกและวางแต่ละคำสั่งด้วยตนเอง"

วิธีการใช้สคริปต์แบบรวดเร็วช่วยให้คุณเรียกใช้สคริปต์แบบอินเทอร์แอกทีฟเดียวสำหรับแต่ละแล็บได้ ซึ่งจะแนะนำขั้นตอนต่างๆ ในแล็บโดยการเรียกใช้คำสั่งสำหรับแล็บนั้นโดยอัตโนมัติ คำสั่งจะทำงานเป็นชุดพร้อมคำอธิบายสั้นๆ ของแต่ละขั้นตอนและสิ่งที่ทำสำเร็จ หลังจากแต่ละชุดแล้ว ระบบจะแจ้งให้คุณไปยังชุดคำสั่งถัดไป วิธีนี้จะช่วยให้คุณทดลองใช้ฟีเจอร์ใน Labs ได้ตามต้องการ สคริปต์แบบรวดเร็วเป็นแบบไอดีมโพเทนต์ ซึ่งหมายความว่าคุณสามารถเรียกใช้สคริปต์เหล่านี้ได้หลายครั้งโดยให้ผลลัพธ์เดียวกัน

สคริปต์สำหรับเส้นทางด่วนจะปรากฏที่ด้านบนของทุกแล็บในกรอบสีเขียวดังที่แสดงด้านล่าง

วิธีการคัดลอกและวางเป็นวิธีดั้งเดิมในการคัดลอกและวางบล็อกคำสั่งแต่ละรายการพร้อมคำอธิบายคำสั่ง วิธีนี้มีไว้สำหรับเรียกใช้เพียงครั้งเดียว ทั้งนี้ไม่มีการรับประกันว่าการเรียกใช้คำสั่งอีกครั้งในวิธีนี้จะให้ผลลัพธ์เหมือนเดิม

เมื่อทำแล็บ โปรดเลือกวิธีใดวิธีหนึ่งจาก 2 วิธี

การตั้งค่าสคริปต์ Fast Track

รับข้อมูลผู้ใช้

การเวิร์กช็อปนี้จะดำเนินการโดยใช้บัญชีผู้ใช้ชั่วคราว (หรือบัญชีแล็บ) ที่สร้างขึ้นโดยผู้ดูแลระบบของการเวิร์กช็อป บัญชีห้องทดลองเป็นเจ้าของโปรเจ็กต์ทั้งหมดในเวิร์กช็อป ผู้ดูแลระบบเวิร์กช็อปจะให้ข้อมูลเข้าสู่ระบบบัญชี Lab (ชื่อผู้ใช้และรหัสผ่าน) แก่ผู้ใช้ที่เข้าร่วมเวิร์กช็อป โปรเจ็กต์ทั้งหมดของผู้ใช้จะมีคำนำหน้าเป็นชื่อผู้ใช้ของบัญชี Lab เช่น สำหรับบัญชี Lab user001@yourcompany.com รหัสโปรเจ็กต์ผู้ดูแลระบบ Terraform จะเป็น user001-200131-01-tf-abcde และอื่นๆ สำหรับโปรเจ็กต์ที่เหลือ ผู้ใช้แต่ละคนต้องเข้าสู่ระบบด้วยบัญชี Lab ที่ผู้ดูแลระบบเวิร์กช็อปให้ไว้ และทำเวิร์กช็อปโดยใช้บัญชี Lab

เปิด Cloud Shell โดยคลิกลิงก์ด้านล่าง

CLOUD SHELL

เข้าสู่ระบบด้วยข้อมูลเข้าสู่ระบบของบัญชี Lab (อย่าเข้าสู่ระบบด้วยบัญชีบริษัทหรือบัญชีส่วนตัว) บัญชี Lab จะมีลักษณะเป็น userXYZ@<workshop_domain>.com
เนื่องจากเป็นบัญชีใหม่ ระบบจึงแจ้งให้คุณยอมรับข้อกำหนดในการให้บริการของ Google คลิก "ยอมรับ"

4. ในหน้าจอถัดไป ให้เลือกช่องทำเครื่องหมายเพื่อยอมรับข้อกำหนดในการให้บริการของ Google แล้วคลิก Start Cloud Shell

ขั้นตอนนี้จะจัดสรร VM ขนาดเล็กของ Linux Debian ให้คุณใช้เพื่อเข้าถึงทรัพยากร GCP แต่ละบัญชีจะได้รับ VM ของ Cloud Shell การเข้าสู่ระบบด้วยบัญชีห้องทดลองจะจัดสรรและบันทึกข้อมูลเข้าสู่ระบบบัญชีห้องทดลอง นอกจาก Cloud Shell แล้ว ระบบยังจัดสรรโปรแกรมแก้ไขโค้ดให้ด้วย ซึ่งจะช่วยให้แก้ไขไฟล์การกำหนดค่า (Terraform, YAML ฯลฯ) ได้ง่ายขึ้น โดยค่าเริ่มต้น หน้าจอ Cloud Shell จะแยกออกเป็นสภาพแวดล้อมเชลล์ของ Cloud Shell (ที่ด้านล่าง) และตัวแก้ไข Cloud Code (ที่ด้านบน) ไอคอนดินสอ และพรอมต์เชลล์ ที่มุมขวาบนช่วยให้คุณสลับระหว่าง 2 อย่างนี้ (เชลล์และเครื่องมือแก้ไขโค้ด) ได้ นอกจากนี้ คุณยังลากแถบตัวคั่นตรงกลาง (ขึ้นหรือลง) และเปลี่ยนขนาดของแต่ละหน้าต่างด้วยตนเองได้ด้วย 5. สร้าง WORKDIR สำหรับเวิร์กช็อปนี้ WORKDIR คือโฟลเดอร์ที่คุณใช้ทำแล็บทั้งหมดในเวิร์กช็อปนี้ เรียกใช้คำสั่งต่อไปนี้ใน Cloud Shell เพื่อสร้าง WORKDIR

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd`

ส่งออกผู้ใช้บัญชี Lab เป็นตัวแปรที่จะใช้สำหรับเวิร์กช็อปนี้ นี่คือบัญชีเดียวกับที่คุณใช้เข้าสู่ระบบ Cloud Shell

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=user001@gcpworkshops.com

แสดงตัวแปร WORKDIR และ MY_USER เพื่อให้แน่ใจว่าได้ตั้งค่าทั้ง 2 อย่างอย่างถูกต้องโดยเรียกใช้คำสั่งต่อไปนี้

echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"

โคลนที่เก็บเวิร์กช็อป

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm

5. การตั้งค่าโครงสร้างพื้นฐาน - เวิร์กโฟลว์ของผู้ใช้

วัตถุประสงค์: ยืนยันโครงสร้างพื้นฐานและการติดตั้ง Istio

ติดตั้งเครื่องมือเวิร์กช็อป
โคลนที่เก็บเวิร์กช็อป
ยืนยันการติดตั้ง Infrastructure
ยืนยันการติดตั้ง k8s-repo
ยืนยันการติดตั้ง Istio

วิธีการทดลองใช้การคัดลอกและวาง

รับข้อมูลผู้ใช้

ผู้ดูแลระบบที่ตั้งค่าเวิร์กช็อปต้องระบุข้อมูลชื่อผู้ใช้และรหัสผ่านให้แก่ผู้ใช้ โปรเจ็กต์ทั้งหมดของผู้ใช้จะมีคำนำหน้าเป็นชื่อผู้ใช้ เช่น สำหรับผู้ใช้ user001@yourcompany.com รหัสโปรเจ็กต์ผู้ดูแลระบบ Terraform จะเป็น user001-200131-01-tf-abcde และอื่นๆ สำหรับโปรเจ็กต์ที่เหลือ ผู้ใช้แต่ละรายจะมีสิทธิ์เข้าถึงเฉพาะสภาพแวดล้อมเวิร์กช็อปของตนเองเท่านั้น

เครื่องมือที่จำเป็นสำหรับเวิร์กช็อป

gcloud (เวอร์ชัน >= 270)
kubectl
sed (ใช้ได้กับ sed ใน Cloud Shell/Linux และใช้ไม่ได้กับ Mac OS)
git (ตรวจสอบว่าคุณใช้เวอร์ชันล่าสุด)
sudo apt update
sudo apt install git
jq
envsubst
kustomize
pv

เข้าถึงโปรเจ็กต์ผู้ดูแลระบบ Terraform

หลังจากสคริปต์ bootstrap_workshop.sh เสร็จสมบูรณ์แล้ว ระบบจะสร้างโฟลเดอร์ GCP สำหรับผู้ใช้แต่ละรายภายในองค์กร ระบบจะสร้าง terraform admin project ภายในโฟลเดอร์ โปรเจ็กต์ผู้ดูแลระบบ Terraform ใช้เพื่อสร้างทรัพยากร GCP ที่เหลือที่จำเป็นสำหรับเวิร์กช็อปนี้ สคริปต์ setup-terraform-admin-project.sh จะเปิดใช้ API ที่จำเป็นในโปรเจ็กต์ผู้ดูแลระบบ Terraform Cloud Build ใช้เพื่อใช้แผน Terraform คุณให้บทบาท IAM ที่เหมาะสมแก่บัญชีบริการ Cloud Build ผ่านสคริปต์เพื่อให้สร้างทรัพยากรใน GCP ได้ สุดท้ายนี้ ระบบจะกำหนดค่าแบ็กเอนด์ระยะไกลใน Bucket ของ Google Cloud Storage (GCS) เพื่อจัดเก็บสถานะ Terraform สำหรับทรัพยากร GCP ทั้งหมด

หากต้องการดูงาน Cloud Build ในโปรเจ็กต์ผู้ดูแลระบบ Terraform คุณต้องมีรหัสโปรเจ็กต์ผู้ดูแลระบบ Terraform โดยจะจัดเก็บไว้ใน Bucket ของ GCS สำหรับผู้ดูแลระบบที่ระบุไว้ในสคริปต์การเริ่มต้น หากเรียกใช้สคริปต์การเริ่มต้นสำหรับผู้ใช้หลายราย รหัสโปรเจ็กต์ผู้ดูแลระบบ Terraform ทั้งหมดจะอยู่ในที่เก็บข้อมูล GCS

เปิด Cloud Shell (หากยังไม่ได้เปิดจากส่วนการตั้งค่าและการเตรียมห้องทดลอง) โดยคลิกลิงก์ด้านล่าง

CLOUD SHELL

ติดตั้ง Kustomize (หากยังไม่ได้ติดตั้ง) ในโฟลเดอร์ $HOME/bin แล้วเพิ่มโฟลเดอร์ $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

ติดตั้ง pv แล้วย้ายไปที่ $HOME/bin/pv

sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv

อัปเดตพรอมต์ 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

ตรวจสอบว่าคุณได้เข้าสู่ระบบ gcloud ด้วยบัญชีผู้ใช้ที่ต้องการ

echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account

รับรหัสโปรเจ็กต์ผู้ดูแลระบบ Terraform โดยเรียกใช้คำสั่งต่อไปนี้

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

ระบบจะจัดเก็บทรัพยากรทั้งหมดที่เชื่อมโยงกับเวิร์กช็อปเป็นตัวแปรในไฟล์ vars.sh ที่จัดเก็บไว้ใน Bucket ของ GCS ในโปรเจ็กต์ผู้ดูแลระบบ Terraform รับไฟล์ vars.sh สำหรับโปรเจ็กต์ผู้ดูแลระบบ Terraform

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

คลิกลิงก์ที่แสดงเพื่อเปิดหน้า Cloud Build สำหรับโปรเจ็กต์ผู้ดูแลระบบ Terraform และยืนยันว่าการสร้างเสร็จสมบูรณ์แล้ว

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

หากเข้าถึง Cloud Console เป็นครั้งแรก ให้ยอมรับข้อกำหนดในการให้บริการของ Google

ตอนนี้คุณกำลังดูหน้า Cloud Build อยู่ ให้คลิกลิงก์ History จากแถบนำทางด้านซ้าย แล้วคลิกบิลด์ล่าสุดเพื่อดูรายละเอียดของการใช้ Terraform ครั้งแรก ระบบจะสร้างทรัพยากรต่อไปนี้เป็นส่วนหนึ่งของสคริปต์ Terraform คุณยังดูแผนภาพสถาปัตยกรรมด้านบนได้ด้วย

โปรเจ็กต์ GCP 4 โปรเจ็กต์ในองค์กร บัญชีสำหรับการเรียกเก็บเงินที่ระบุจะเชื่อมโยงกับแต่ละโปรเจ็กต์
โปรเจ็กต์หนึ่งคือ network host project สำหรับ VPC ที่แชร์ ไม่มีการสร้างทรัพยากรอื่นๆ ในโปรเจ็กต์นี้
โปรเจ็กต์หนึ่งคือ ops project ที่ใช้สำหรับคลัสเตอร์ GKE ของระนาบควบคุม Istio
2 โครงการนี้แสดงถึงทีมพัฒนา 2 ทีมที่แตกต่างกันซึ่งทำงานในบริการของตน
ระบบจะสร้างคลัสเตอร์ GKE 2 รายการในแต่ละโปรเจ็กต์ 3 รายการ ได้แก่ ops, dev1 และ dev2
ระบบจะสร้างที่เก็บ CSR ชื่อ k8s-repo ซึ่งมีโฟลเดอร์ 6 โฟลเดอร์สำหรับไฟล์ Manifest ของ Kubernetes 1 โฟลเดอร์ต่อคลัสเตอร์ GKE โดยจะใช้ที่เก็บนี้เพื่อทำให้ไฟล์ Manifest ของ Kubernetes ใช้งานได้ในคลัสเตอร์ในลักษณะ GitOps
ระบบจะสร้างทริกเกอร์ Cloud Build เพื่อให้เมื่อใดก็ตามที่มีการคอมมิตไปยังกิ่งหลักของ k8s-repo ระบบจะทําให้ไฟล์ Manifest ของ Kubernetes ใช้งานได้ในคลัสเตอร์ GKE จากโฟลเดอร์ที่เกี่ยวข้อง

เมื่อบิลด์เสร็จสมบูรณ์ใน terraform admin project บิลด์อื่นจะเริ่มในโปรเจ็กต์การดำเนินการ คลิกลิงก์ที่แสดงเพื่อเปิดหน้า Cloud Build สำหรับ ops project และยืนยันว่า Cloud Build ของ k8s-repo เสร็จสมบูรณ์แล้ว

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

ยืนยันการติดตั้ง

สร้างไฟล์ kubeconfig สำหรับคลัสเตอร์ทั้งหมด เรียกใช้สคริปต์ต่อไปนี้

$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh

สคริปต์นี้จะสร้างไฟล์ kubeconfig ใหม่ในโฟลเดอร์ gke ชื่อ kubemesh

เปลี่ยนตัวแปร KUBECONFIG ให้ชี้ไปยังไฟล์ kubeconfig ใหม่

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

เพิ่ม vars.sh และตัวแปร KUBECONFIG ลงใน .bashrc ใน Cloud Shell เพื่อให้ระบบเรียกใช้ทุกครั้งที่รีสตาร์ท Cloud Shell

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

แสดงรายการบริบทคลัสเตอร์ คุณควรเห็น 6 คลัสเตอร์

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

ตรวจสอบว่าได้ติดตั้ง Istio ในทั้ง 2 คลัสเตอร์แล้วโดยดูว่าพ็อดทั้งหมดกำลังทำงานอยู่และงานเสร็จสมบูรณ์แล้ว

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

ตรวจสอบว่าได้ติดตั้ง Istio ในคลัสเตอร์ dev1 ทั้ง 2 คลัสเตอร์แล้ว มีเพียง Citadel, sidecar-injector และ coredns เท่านั้นที่ทำงานในคลัสเตอร์ dev1 โดยใช้ Control Plane ของ Istio ที่ทำงานในคลัสเตอร์ ops-1 ร่วมกัน

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

ตรวจสอบว่าได้ติดตั้ง Istio ในคลัสเตอร์ dev2 ทั้ง 2 คลัสเตอร์แล้ว มีเพียง Citadel, sidecar-injector และ coredns เท่านั้นที่ทำงานในคลัสเตอร์ dev2 โดยจะใช้ Istio Control Plane ที่ทำงานในคลัสเตอร์ ops-2 ร่วมกัน

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

ยืนยันการค้นพบบริการสำหรับระนาบควบคุมที่แชร์

ยืนยันว่ามีการติดตั้งใช้งานข้อมูลลับ (ไม่บังคับ)

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

ในเวิร์กช็อปนี้ คุณจะใช้ VPC ที่แชร์รายการเดียวซึ่งสร้างคลัสเตอร์ GKE ทั้งหมด หากต้องการค้นพบบริการในคลัสเตอร์ คุณต้องใช้ไฟล์ kubeconfig (สำหรับคลัสเตอร์แอปพลิเคชันแต่ละคลัสเตอร์) ที่สร้างเป็นข้อมูลลับในคลัสเตอร์การดำเนินการ Pilot ใช้ข้อมูลลับเหล่านี้เพื่อค้นหาบริการโดยการค้นหาเซิร์ฟเวอร์ Kube API ของคลัสเตอร์แอปพลิเคชัน (ตรวจสอบสิทธิ์ผ่านข้อมูลลับด้านบน) คุณจะเห็นว่าคลัสเตอร์การดำเนินการทั้ง 2 คลัสเตอร์สามารถตรวจสอบสิทธิ์กับคลัสเตอร์แอปทั้งหมดได้โดยใช้ Secret ที่สร้างด้วย kubeconfig คลัสเตอร์ Ops สามารถค้นพบบริการได้โดยอัตโนมัติโดยใช้ไฟล์ kubeconfig เป็นวิธีการลับ ซึ่งกำหนดให้ไพลอตในคลัสเตอร์การดำเนินการมีสิทธิ์เข้าถึงเซิร์ฟเวอร์ Kube API ของคลัสเตอร์อื่นๆ ทั้งหมด หาก Pilot เข้าถึงเซิร์ฟเวอร์ Kube API ไม่ได้ คุณจะต้องเพิ่มบริการระยะไกลเป็น ServiceEntries ด้วยตนเอง คุณอาจมองว่า ServiceEntry เป็นรายการ DNS ในรีจิสทรีบริการ ServiceEntry จะกำหนดบริการโดยใช้ชื่อ DNS ที่สมบูรณ์ในตัวเอง ( FQDN) และที่อยู่ IP ที่เข้าถึงได้ ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบเกี่ยวกับ Istio Multicluster

6. อธิบายที่เก็บโครงสร้างพื้นฐาน

การสร้างโครงสร้างพื้นฐานของระบบคลาวด์

ทรัพยากร GCP สำหรับเวิร์กช็อปสร้างขึ้นโดยใช้ Cloud Build และ infrastructure ที่เก็บ CSR คุณเพิ่งเรียกใช้สคริปต์การเริ่มต้นระบบ (อยู่ที่ scripts/bootstrap_workshop.sh) จากเทอร์มินัลในเครื่อง สคริปต์การเริ่มต้นระบบจะสร้างโฟลเดอร์ GCP, โปรเจ็กต์ผู้ดูแลระบบ Terraform และสิทธิ์ IAM ที่เหมาะสมสำหรับบัญชีบริการ Cloud Build โปรเจ็กต์ผู้ดูแลระบบ Terraform ใช้เพื่อจัดเก็บสถานะ บันทึก และสคริปต์เบ็ดเตล็ดของ Terraform ซึ่งมีที่เก็บ infrastructure และที่เก็บ CSR ของ k8s_repo เราจะอธิบายที่เก็บเหล่านี้โดยละเอียดในส่วนถัดไป ไม่มีการสร้างทรัพยากรเวิร์กช็อปอื่นๆ ในโปรเจ็กต์ผู้ดูแลระบบ Terraform บัญชีบริการ Cloud Build ในโปรเจ็กต์ผู้ดูแลระบบ Terraform ใช้เพื่อสร้างทรัพยากรสำหรับเวิร์กช็อป

ระบบจะใช้ไฟล์ cloudbuild.yaml ที่อยู่ในโฟลเดอร์ infrastructure เพื่อสร้างทรัพยากร GCP สำหรับเวิร์กช็อป ซึ่งจะสร้างอิมเมจบิลเดอร์ที่กำหนดเองพร้อมเครื่องมือทั้งหมดที่จำเป็นต่อการสร้างทรัพยากร GCP เครื่องมือเหล่านี้ ได้แก่ gcloud SDK, Terraform และยูทิลิตีอื่นๆ เช่น Python, Git, JQ เป็นต้น อิมเมจตัวสร้างที่กำหนดเองจะเรียกใช้ terraform plan และ apply สำหรับแต่ละทรัพยากร ไฟล์ Terraform ของแต่ละทรัพยากรจะอยู่ในโฟลเดอร์แยกต่างหาก (รายละเอียดอยู่ในส่วนถัดไป) ระบบจะสร้างทรัพยากรทีละรายการและตามลำดับการสร้างตามปกติ (เช่น ระบบจะสร้างโปรเจ็กต์ GCP ก่อนที่จะสร้างทรัพยากรในโปรเจ็กต์) โปรดดูรายละเอียดเพิ่มเติมในไฟล์ cloudbuild.yaml

Cloud Build จะทริกเกอร์ทุกครั้งที่มีการคอมมิตไปยังที่เก็บ infrastructure การเปลี่ยนแปลงใดๆ ที่เกิดขึ้นกับโครงสร้างพื้นฐานจะจัดเก็บเป็นโครงสร้างพื้นฐานเป็นโค้ด (IaC) และส่งไปยังที่เก็บ ระบบจะจัดเก็บสถานะของเวิร์กช็อปไว้ในที่เก็บนี้เสมอ

โครงสร้างโฟลเดอร์ - ทีม สภาพแวดล้อม และทรัพยากร

ที่เก็บโครงสร้างพื้นฐานจะตั้งค่าทรัพยากรโครงสร้างพื้นฐานของ GCP สำหรับเวิร์กช็อป โดยจะจัดโครงสร้างเป็นโฟลเดอร์และโฟลเดอร์ย่อย โฟลเดอร์ฐานภายในที่เก็บแสดงถึงteamที่เป็นเจ้าของทรัพยากร GCP ที่เฉพาะเจาะจง เลเยอร์ถัดไปของโฟลเดอร์แสดงถึง environment ที่เฉพาะเจาะจงสำหรับทีม (เช่น dev, stage, prod) เลเยอร์ถัดไปของโฟลเดอร์ภายในสภาพแวดล้อมแสดงถึง resource ที่เฉพาะเจาะจง (เช่น host_project, gke_clusters ฯลฯ) สคริปต์และไฟล์ Terraform ที่จำเป็นจะอยู่ในโฟลเดอร์ทรัพยากร

ในการเวิร์กช็อปนี้จะมีทีม 4 ประเภทต่อไปนี้

โครงสร้างพื้นฐาน - เป็นตัวแทนของทีมโครงสร้างพื้นฐานของระบบคลาวด์ โดยมีหน้าที่สร้างทรัพยากร GCP สำหรับทีมอื่นๆ ทั้งหมด โดยใช้โปรเจ็กต์ผู้ดูแลระบบ Terraform สำหรับทรัพยากร ที่เก็บโครงสร้างพื้นฐานเองอยู่ในโปรเจ็กต์ผู้ดูแลระบบ Terraform รวมถึงไฟล์สถานะ Terraform (อธิบายไว้ด้านล่าง) ทรัพยากรเหล่านี้สร้างขึ้นโดยสคริปต์ Bash ในระหว่างกระบวนการเริ่มต้น (ดูรายละเอียดได้ที่โมดูล 0 - เวิร์กโฟลว์ของผู้ดูแลระบบ)
network - แสดงถึงทีมเครือข่าย โดยมีหน้าที่รับผิดชอบเกี่ยวกับทรัพยากร VPC และเครือข่าย โดยเป็นเจ้าของทรัพยากร GCP ต่อไปนี้
host project - แสดงถึงโปรเจ็กต์โฮสต์ VPC ที่แชร์
shared VPC - แสดงถึง VPC ที่แชร์ ซับเน็ต ช่วง IP รอง เส้นทาง และกฎไฟร์วอลล์
ops - แสดงถึงทีมปฏิบัติการ/DevOps โดยเป็นเจ้าของทรัพยากรต่อไปนี้
ops project - แสดงถึงโปรเจ็กต์สำหรับทรัพยากรการดำเนินการทั้งหมด
gke clusters - คลัสเตอร์ GKE สำหรับการดำเนินการต่อภูมิภาค ระบบจะติดตั้งระนาบควบคุม Istio ในคลัสเตอร์ GKE ของการดำเนินการแต่ละคลัสเตอร์
k8s-repo - ที่เก็บ CSR ที่มีไฟล์ Manifest ของ GKE สำหรับคลัสเตอร์ GKE ทั้งหมด
apps - แสดงถึงทีมแอปพลิเคชัน เวิร์กช็อปนี้จำลองทีม 2 ทีม ได้แก่ app1 และ app2 โดยเป็นเจ้าของทรัพยากรต่อไปนี้
app projects - ทีมแอปทุกทีมจะมีชุดโปรเจ็กต์ของตัวเอง ซึ่งจะช่วยให้ควบคุมการเรียกเก็บเงินและ IAM สำหรับโปรเจ็กต์ที่เฉพาะเจาะจงได้
gke clusters - นี่คือคลัสเตอร์แอปพลิเคชันที่คอนเทนเนอร์/พ็อดของแอปพลิเคชันทำงาน
gce instances - ไม่บังคับ หากมีแอปพลิเคชันที่ทำงานบนอินสแตนซ์ GCE ในเวิร์กช็อปนี้ app1 มีอินสแตนซ์ GCE 2 รายการซึ่งแอปพลิเคชันบางส่วนทำงานอยู่

ในเวิร์กช็อปนี้ แอปเดียวกัน (แอป Hipster Shop) จะแสดงทั้ง app1 และ app2

Provider, States และ Outputs - Backend และสถานะที่แชร์

ผู้ให้บริการ google และ google-beta อยู่ที่ gcp/[environment]/gcp/provider.tf provider.tf จะเป็น symlinked ในโฟลเดอร์ทรัพยากรทุกโฟลเดอร์ ซึ่งช่วยให้คุณเปลี่ยนผู้ให้บริการได้ในที่เดียวแทนที่จะต้องจัดการผู้ให้บริการสำหรับแต่ละแหล่งข้อมูลแยกกัน

ทรัพยากรทุกรายการจะมีbackend.tf ซึ่งกำหนดตำแหน่งของไฟล์ tfstate ของทรัพยากร ระบบจะสร้างไฟล์ backend.tf นี้จากเทมเพลต (อยู่ที่ templates/backend.tf_tmpl) โดยใช้สคริปต์ (อยู่ที่ scripts/setup_terraform_admin_project) แล้ววางไว้ในโฟลเดอร์ทรัพยากรที่เกี่ยวข้อง ระบบจะใช้ที่เก็บข้อมูล Google Cloud Storage (GCS) สำหรับแบ็กเอนด์ ชื่อโฟลเดอร์ของ Bucket ใน GCS ตรงกับชื่อทรัพยากร แบ็กเอนด์ของทรัพยากรทั้งหมดจะอยู่ในโปรเจ็กต์ผู้ดูแลระบบ Terraform

แหล่งข้อมูลที่มีค่าที่ขึ้นต่อกันจะมีไฟล์ output.tf ค่าเอาต์พุตที่จำเป็นจะจัดเก็บไว้ในไฟล์ tfstate ที่กำหนดไว้ในแบ็กเอนด์สำหรับทรัพยากรนั้นๆ เช่น หากต้องการสร้างคลัสเตอร์ GKE ในโปรเจ็กต์ คุณต้องทราบรหัสโปรเจ็กต์ ระบบจะแสดงรหัสโปรเจ็กต์ผ่าน output.tf ไปยังไฟล์ tfstate ที่ใช้ได้ผ่านแหล่งข้อมูล terraform_remote_state ในทรัพยากรคลัสเตอร์ GKE

ไฟล์ shared_state คือterraform_remote_stateแหล่งข้อมูลที่ชี้ไปยังไฟล์ tfstate ของทรัพยากร มีshared_state_[resource_name].tfไฟล์ (หรือไฟล์ต่างๆ) อยู่ในโฟลเดอร์ทรัพยากรที่ต้องใช้เอาต์พุตจากทรัพยากรอื่นๆ ตัวอย่างเช่น ในโฟลเดอร์ทรัพยากร ops_gke จะมีไฟล์ shared_state จากทรัพยากร ops_project และ shared_vpc เนื่องจากคุณต้องใช้รหัสโปรเจ็กต์และรายละเอียด VPC เพื่อสร้างคลัสเตอร์ GKE ในโปรเจ็กต์การดำเนินการ ระบบจะสร้างไฟล์ shared_state จากเทมเพลต (อยู่ที่ templates/shared_state.tf_tmpl) โดยใช้สคริปต์ (อยู่ที่ scripts/setup_terraform_admin_project) และวางไฟล์ shared_state ของทรัพยากรทั้งหมดไว้ในโฟลเดอร์ gcp/[environment]/shared_states ไฟล์ shared_state ที่จำเป็นจะได้รับการลิงก์สัญลักษณ์ในโฟลเดอร์ทรัพยากรที่เกี่ยวข้อง การวางไฟล์ shared_state ทั้งหมดไว้ในโฟลเดอร์เดียวและลิงก์สัญลักษณ์ไปยังโฟลเดอร์ทรัพยากรที่เหมาะสมจะช่วยให้จัดการไฟล์สถานะทั้งหมดได้ง่ายในที่เดียว

ตัวแปร

ระบบจะจัดเก็บค่าทรัพยากรทั้งหมดเป็นตัวแปรสภาพแวดล้อม ระบบจะจัดเก็บตัวแปรเหล่านี้ (เป็นคำสั่งส่งออก) ในไฟล์ที่ชื่อ vars.sh ซึ่งอยู่ใน Bucket ของ GCS ในโปรเจ็กต์ผู้ดูแลระบบ Terraform ซึ่งประกอบด้วยรหัสองค์กร บัญชีสำหรับการเรียกเก็บเงิน รหัสโปรเจ็กต์ รายละเอียดคลัสเตอร์ GKE ฯลฯ คุณสามารถดาวน์โหลดและจัดหา vars.sh จากเทอร์มินัลใดก็ได้เพื่อรับค่าสำหรับการตั้งค่า

ระบบจะจัดเก็บตัวแปร Terraform ไว้ใน vars.sh เป็น TF_VAR_[variable name] ระบบจะใช้ตัวแปรเหล่านี้เพื่อสร้างไฟล์ variables.tfvars ในโฟลเดอร์ทรัพยากรที่เกี่ยวข้อง variables.tfvars ไฟล์ประกอบด้วยตัวแปรทั้งหมดพร้อมค่าของตัวแปร ระบบจะสร้างไฟล์ variables.tfvars จากไฟล์เทมเพลตในโฟลเดอร์เดียวกันโดยใช้สคริปต์ (อยู่ที่ scripts/setup_terraform_admin_project)

คำอธิบายเกี่ยวกับที่เก็บ K8s

k8s_repo คือที่เก็บ CSR (แยกจากที่เก็บโครงสร้างพื้นฐาน) ซึ่งอยู่ในโปรเจ็กต์ผู้ดูแลระบบ Terraform โดยใช้เพื่อจัดเก็บและใช้ไฟล์ Manifest ของ GKE กับคลัสเตอร์ GKE ทั้งหมด k8s_repo สร้างขึ้นโดยโครงสร้างพื้นฐานของ Cloud Build (ดูรายละเอียดในส่วนก่อนหน้า) ในระหว่างกระบวนการ Cloud Build ของโครงสร้างพื้นฐานเริ่มต้น ระบบจะสร้างคลัสเตอร์ GKE ทั้งหมด 6 รายการ ใน k8s_repo ระบบจะสร้างโฟลเดอร์ 6 โฟลเดอร์ แต่ละโฟลเดอร์ (ชื่อที่ตรงกับชื่อคลัสเตอร์ GKE) จะสอดคล้องกับคลัสเตอร์ GKE ที่มีไฟล์ Manifest ของทรัพยากรที่เกี่ยวข้อง Cloud Build ใช้เพื่อใช้ไฟล์ Manifest ของ Kubernetes กับคลัสเตอร์ GKE ทั้งหมดโดยใช้ k8s_repo ซึ่งคล้ายกับการสร้างโครงสร้างพื้นฐาน ระบบจะทริกเกอร์ Cloud Build ทุกครั้งที่มีการคอมมิตไปยังที่เก็บ k8s_repo เช่นเดียวกับโครงสร้างพื้นฐาน ระบบจะจัดเก็บไฟล์ Manifest ของ Kubernetes ทั้งหมดเป็นโค้ดในที่เก็บ k8s_repo และสถานะของคลัสเตอร์ GKE แต่ละรายการจะจัดเก็บไว้ในโฟลเดอร์ที่เกี่ยวข้องเสมอ

ในขั้นตอนการสร้างโครงสร้างพื้นฐานเริ่มต้น ระบบจะสร้าง k8s_repo และติดตั้ง Istio ในคลัสเตอร์ทั้งหมด

โปรเจ็กต์ คลัสเตอร์ GKE และเนมสเปซ

ทรัพยากรในเวิร์กช็อปนี้แบ่งออกเป็นโปรเจ็กต์ GCP ต่างๆ โปรเจ็กต์ควรตรงกับโครงสร้างขององค์กร (หรือทีม) ของบริษัท ทีม (ในองค์กร) ที่รับผิดชอบโปรเจ็กต์/ผลิตภัณฑ์/ทรัพยากรต่างๆ จะใช้โปรเจ็กต์ GCP ที่แตกต่างกัน การมีโปรเจ็กต์แยกกันช่วยให้คุณสร้างชุดสิทธิ์ IAM แยกกันและจัดการการเรียกเก็บเงินที่ระดับโปรเจ็กต์ได้ นอกจากนี้ ยังมีการจัดการโควต้าที่ระดับโปรเจ็กต์ด้วย

การเวิร์กช็อปนี้มีทีมเข้าร่วม 5 ทีม โดยแต่ละทีมมีโปรเจ็กต์ของตัวเอง

ทีมโครงสร้างพื้นฐานที่สร้างทรัพยากร GCP ใช้ Terraform admin project โดยจะจัดการโครงสร้างพื้นฐานเป็นโค้ดในที่เก็บ CSR (เรียกว่า infrastructure) และจัดเก็บข้อมูลสถานะ Terraform ทั้งหมดที่เกี่ยวข้องกับทรัพยากรที่สร้างใน GCP ไว้ใน Bucket ของ GCS โดยจะควบคุมการเข้าถึงที่เก็บ CSR และที่เก็บข้อมูลสถานะ Terraform ใน GCS
ทีมเครือข่ายที่สร้าง VPC ที่แชร์จะใช้ host project โปรเจ็กต์นี้มี VPC, เครือข่ายย่อย, เส้นทาง และกฎไฟร์วอลล์ การมี VPC ที่แชร์ช่วยให้ทีมจัดการเครือข่ายสำหรับทรัพยากร GCP จากส่วนกลางได้ ทุกโปรเจ็กต์ใช้ VPC ที่แชร์เดียวนี้สำหรับการเชื่อมต่อเครือข่าย
ทีมปฏิบัติการ/แพลตฟอร์มที่สร้างคลัสเตอร์ GKE และระนาบควบคุม ASM/Istio จะใช้ ops project โดยจะจัดการวงจรของคลัสเตอร์ GKE และ Service Mesh โดยมีหน้าที่รับผิดชอบในการเพิ่มความปลอดภัยของคลัสเตอร์ การจัดการความยืดหยุ่น และการปรับขนาดแพลตฟอร์ม Kubernetes ในเวิร์กช็อปนี้ คุณจะได้ใช้วิธี GitOps ในการทำให้ทรัพยากรใช้งานได้ใน Kubernetes ที่เก็บ CSR (เรียกว่า k8s_repo) อยู่ในโปรเจ็กต์การดำเนินการ
สุดท้าย ทีม dev1 และ dev2 (แสดงถึงทีมพัฒนา 2 ทีม) ที่สร้างแอปพลิเคชันจะใช้ dev1 และ dev2 projects ของตนเอง แอปพลิเคชันและบริการเหล่านี้คือแอปพลิเคชันและบริการที่คุณให้บริการแก่ลูกค้า โดยจะสร้างขึ้นบนแพลตฟอร์มที่ทีมปฏิบัติการจัดการ ระบบจะพุชทรัพยากร (การติดตั้งใช้งาน บริการ ฯลฯ) ไปยัง k8s_repo และติดตั้งใช้งานในคลัสเตอร์ที่เหมาะสม โปรดทราบว่าเวิร์กช็อปนี้ไม่ได้มุ่งเน้นที่แนวทางปฏิบัติแนะนำและเครื่องมือ CI/CD คุณใช้ Cloud Build เพื่อทำให้การทำให้ทรัพยากร Kubernetes ใช้งานได้ในคลัสเตอร์ GKE โดยตรงเป็นอัตโนมัติ ในสถานการณ์การใช้งานจริง คุณจะต้องใช้โซลูชัน CI/CD ที่เหมาะสมเพื่อติดตั้งใช้งานแอปพลิเคชันไปยังคลัสเตอร์ GKE

ในเวิร์กช็อปนี้มีคลัสเตอร์ GKE 2 ประเภท

คลัสเตอร์ Ops - ใช้โดยทีม Ops เพื่อเรียกใช้เครื่องมือ DevOps ในเวิร์กช็อปนี้ ผู้เข้าร่วมจะเรียกใช้ Control Plane ของ ASM/Istio เพื่อจัดการ Service Mesh
คลัสเตอร์แอปพลิเคชัน (แอป) - ใช้โดยทีมพัฒนาเพื่อเรียกใช้แอปพลิเคชัน ในเวิร์กช็อปนี้ เราจะใช้แอป Hipster Shop

การแยกเครื่องมือการดำเนินการ/ผู้ดูแลระบบออกจากคลัสเตอร์ที่เรียกใช้แอปพลิเคชันจะช่วยให้คุณจัดการวงจรของทรัพยากรแต่ละรายการได้อย่างอิสระ คลัสเตอร์ทั้ง 2 ประเภทนี้ยังอยู่ในโปรเจ็กต์ต่างๆ ที่เกี่ยวข้องกับทีม/ผลิตภัณฑ์ที่ใช้คลัสเตอร์ดังกล่าว ซึ่งทําให้จัดการสิทธิ์ IAM ได้ง่ายขึ้นด้วย

มีคลัสเตอร์ GKE ทั้งหมด 6 รายการ ระบบจะสร้างคลัสเตอร์การดำเนินการระดับภูมิภาค 2 คลัสเตอร์ในโปรเจ็กต์การดำเนินการ ระบบจะติดตั้งระนาบควบคุม ASM/Istio ในคลัสเตอร์การดำเนินการทั้ง 2 คลัสเตอร์ คลัสเตอร์การดำเนินการแต่ละคลัสเตอร์อยู่ในภูมิภาคที่แตกต่างกัน นอกจากนี้ ยังมีคลัสเตอร์แอปพลิเคชันระดับโซน 4 คลัสเตอร์ โดยจะสร้างในโปรเจ็กต์ของตนเอง เวิร์กช็อปนี้จำลองทีมพัฒนา 2 ทีม ซึ่งแต่ละทีมมีโปรเจ็กต์ของตัวเอง แต่ละโปรเจ็กต์จะมีคลัสเตอร์แอป 2 กลุ่ม คลัสเตอร์แอปคือคลัสเตอร์ระดับโซนในโซนต่างๆ คลัสเตอร์แอปทั้ง 4 กลุ่มตั้งอยู่ใน 2 ภูมิภาคและ 4 โซน วิธีนี้จะช่วยให้คุณได้รับการสำรองข้อมูลระดับภูมิภาคและระดับโซน

แอปพลิเคชันที่ใช้ในเวิร์กช็อปนี้ ซึ่งก็คือแอป Hipster Shop จะได้รับการติดตั้งใช้งานในคลัสเตอร์แอปทั้ง 4 คลัสเตอร์ โดยแต่ละไมโครเซอร์วิสจะอยู่ในเนมสเปซของตัวเองในคลัสเตอร์แอปทุกคลัสเตอร์ ระบบจะไม่ติดตั้งใช้งานการติดตั้งใช้งาน (พ็อด) ของแอป Hipster Shop ในคลัสเตอร์การดำเนินการ อย่างไรก็ตาม ระบบจะสร้างเนมสเปซและทรัพยากรบริการสำหรับ Microservice ทั้งหมดในคลัสเตอร์การดำเนินการด้วย ระนาบควบคุม ASM/Istio ใช้รีจิสทรีบริการ Kubernetes สำหรับการค้นพบบริการ หากไม่มีบริการ (ในคลัสเตอร์การดำเนินการ) คุณจะต้องสร้าง ServiceEntry ด้วยตนเองสำหรับแต่ละบริการที่ทำงานในคลัสเตอร์แอป

คุณจะติดตั้งใช้งานแอปพลิเคชันแบบไมโครเซอร์วิส 10 ระดับในเวิร์กช็อปนี้ แอปพลิเคชันนี้เป็นแอปอีคอมเมิร์ซบนเว็บชื่อ "Hipster Shop" ซึ่งผู้ใช้สามารถเลือกดูสินค้า เพิ่มสินค้าลงในรถเข็น และซื้อสินค้าได้

ไฟล์ Manifest ของ Kubernetes และ k8s_repo

คุณใช้ k8s_repo เพื่อเพิ่มทรัพยากร Kubernetes ลงในคลัสเตอร์ GKE ทั้งหมด โดยคัดลอกไฟล์ Manifest ของ Kubernetes และส่งไปยัง k8s_repo การคอมมิตทั้งหมดไปยัง k8s_repo จะทริกเกอร์งาน Cloud Build ซึ่งจะทำให้ไฟล์ Manifest ของ Kubernetes ใช้งานได้กับคลัสเตอร์ที่เกี่ยวข้อง ไฟล์ Manifest ของแต่ละคลัสเตอร์จะอยู่ในโฟลเดอร์แยกต่างหากซึ่งมีชื่อเดียวกับชื่อคลัสเตอร์

ชื่อคลัสเตอร์ทั้ง 6 รายการมีดังนี้

gke-asm-1-r1-prod - คลัสเตอร์การดำเนินการระดับภูมิภาคในภูมิภาค 1
gke-asm-2-r2-prod - คลัสเตอร์การดำเนินการระดับภูมิภาคในภูมิภาค 2
gke-1-apps-r1a-prod - คลัสเตอร์แอปในโซน a ของภูมิภาค 1
gke-2-apps-r1b-prod - คลัสเตอร์แอปในโซน b ของภูมิภาค 1
gke-3-apps-r2a-prod - คลัสเตอร์แอปในโซน a ของภูมิภาค 2
gke-4-apps-r2b-prod - คลัสเตอร์แอปในโซน b ของภูมิภาค 2

k8s_repo มีโฟลเดอร์ที่สอดคล้องกับคลัสเตอร์เหล่านี้ ระบบจะนำไฟล์ Manifest ที่อยู่ในโฟลเดอร์เหล่านี้ไปใช้กับคลัสเตอร์ GKE ที่เกี่ยวข้อง ไฟล์ Manifest สำหรับแต่ละคลัสเตอร์จะอยู่ในโฟลเดอร์ย่อย (ภายในโฟลเดอร์หลักของคลัสเตอร์) เพื่อให้จัดการได้ง่าย ในเวิร์กช็อปนี้ คุณจะได้ใช้ Kustomize เพื่อติดตามทรัพยากรที่ได้รับการติดตั้งใช้งาน โปรดดูรายละเอียดเพิ่มเติมในเอกสารประกอบอย่างเป็นทางการของ Kustomize

7. ทําให้แอปตัวอย่างใช้งานได้

วัตถุประสงค์: ติดตั้งใช้งานแอป Hipster Shop ในคลัสเตอร์แอป

โคลน k8s-repo
คัดลอกไฟล์ Manifest ของร้านค้า Hipster ไปยังคลัสเตอร์แอปทั้งหมด
สร้างบริการสำหรับแอป Hipster Shop ในคลัสเตอร์การดำเนินการ
ตั้งค่า loadgenerators ในคลัสเตอร์การดำเนินการเพื่อทดสอบการเชื่อมต่อทั่วโลก
ยืนยันการเชื่อมต่อที่ปลอดภัยกับแอป Hipster Shop

วิธีการทดลองใช้การคัดลอกและวาง

โคลนที่เก็บแหล่งข้อมูลของโปรเจ็กต์การดำเนินการ

ในขั้นตอนการสร้างโครงสร้างพื้นฐาน Terraform เริ่มต้น เราได้สร้าง k8s-repo ไว้ในโปรเจ็กต์การดำเนินการแล้ว

สร้างไดเรกทอรีที่ว่างเปล่าสำหรับที่เก็บ git โดยใช้คำสั่งต่อไปนี้

mkdir $WORKDIR/k8s-repo

เริ่มต้นที่เก็บ 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

ตั้งค่าการกำหนดค่า 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

คัดลอกไฟล์ Manifest คอมมิต และพุช

คัดลอกเนมสเปซและบริการของ Hipster 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/.

คัดลอกไฟล์ 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/

คัดลอกการติดตั้งใช้งาน Hipster 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/

นำการติดตั้งใช้งาน cartservice, rbac และ podsecuritypolicy ออกจากคลัสเตอร์สำหรับนักพัฒนาซอฟต์แวร์ทั้งหมด ยกเว้น 1 คลัสเตอร์ Hipstershop ไม่ได้สร้างขึ้นสำหรับการติดตั้งใช้งานแบบหลายคลัสเตอร์ ดังนั้นเราจึงใช้ cartservice เพียงรายการเดียวเพื่อหลีกเลี่ยงผลลัพธ์ที่ไม่สอดคล้องกัน

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

เพิ่มการติดตั้งใช้งาน cartservice, 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

นำไดเรกทอรี podsecuritypolicies, การติดตั้งใช้งาน และ rbac ออกจาก ops clusters 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

แทนที่ PROJECT_ID ในไฟล์ Manifest ของ RBAC

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/*

คัดลอกไฟล์ Manifest ของ IngressGateway และ VirtualService ไปยังที่เก็บต้นทางสำหรับคลัสเตอร์การดำเนินการ

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/

คัดลอกทรัพยากร 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/

แทนที่ PROJECT_ID ในไฟล์ Manifest ของ Config Connector

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/*

คัดลอกloadgeneratorไฟล์ Manifest (การทำให้ใช้งานได้, PodSecurityPolicy และ RBAC) ไปยังคลัสเตอร์การดำเนินการ แอป Hipster Shop จะแสดงโดยใช้ตัวจัดสรรภาระงานของ Google Cloud (GCLB) ทั่วโลก GCLB จะรับการเข้าชมของไคลเอ็นต์ (ปลายทางคือ frontend) และส่งไปยังอินสแตนซ์ของบริการที่ใกล้ที่สุด การใส่ loadgenerator ในคลัสเตอร์การดำเนินการทั้ง 2 คลัสเตอร์จะช่วยให้มั่นใจได้ว่าระบบจะส่งการรับส่งข้อมูลไปยัง Istio Ingress Gateway ทั้ง 2 รายการที่ทำงานในคลัสเตอร์การดำเนินการ เราจะอธิบายการปรับสมดุลโหลดอย่างละเอียดในส่วนต่อไปนี้

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/.

แทนที่รหัสโปรเจ็กต์การดำเนินการในloadgeneratorไฟล์ Manifest สำหรับคลัสเตอร์การดำเนินการทั้ง 2 รายการ

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

เพิ่มทรัพยากร loadgenerator ลงใน kustomization.yaml สำหรับคลัสเตอร์การดำเนินการทั้ง 2 รายการ

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

มุ่งมั่นที่จะ k8s-repo

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

ดูสถานะของ Cloud Build ของโปรเจ็กต์ Ops ในแท็บที่เปิดไว้ก่อนหน้านี้ หรือโดยคลิกลิงก์ต่อไปนี้

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

ยืนยันการติดตั้งใช้งานแอปพลิเคชัน

ตรวจสอบว่าพ็อดในเนมสเปซของแอปพลิเคชันทั้งหมด ยกเว้นรถเข็น อยู่ในสถานะ "กำลังทำงาน" ในคลัสเตอร์สำหรับนักพัฒนาซอฟต์แวร์ทั้งหมด

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

ตรวจสอบว่าพ็อดในเนมสเปซของรถเข็นอยู่ในสถานะ "กำลังทำงาน" ในคลัสเตอร์สำหรับนักพัฒนาแอปคลัสเตอร์แรกเท่านั้น

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

เข้าถึงแอป Hipster Shop

การจัดสรรภาระงานทั่วโลก

ตอนนี้คุณมีแอป Hipster Shop ที่ติดตั้งใช้งานในคลัสเตอร์แอปทั้ง 4 กลุ่มแล้ว คลัสเตอร์เหล่านี้อยู่ใน 2 ภูมิภาคและ 4 โซน ลูกค้าจะเข้าถึงแอป Hipster Shop ได้โดยเข้าถึงfrontendบริการ บริการ frontend ทำงานในคลัสเตอร์แอปทั้ง 4 คลัสเตอร์ ระบบใช้ตัวจัดสรรภาระงานของ Google Cloud ( GCLB) เพื่อนำการเข้าชมของไคลเอ็นต์ไปยังอินสแตนซ์ทั้ง 4 ของบริการ frontend

เกตเวย์ Istio Ingress จะทำงานในคลัสเตอร์การดำเนินการเท่านั้น และทำหน้าที่เป็นตัวจัดสรรภาระงานระดับภูมิภาคให้กับคลัสเตอร์แอปพลิเคชันระดับโซน 2 คลัสเตอร์ภายในภูมิภาค GCLB ใช้ Istio Ingress Gateway 2 รายการ (ทำงานในคลัสเตอร์การดำเนินการ 2 รายการ) เป็นแบ็กเอนด์สำหรับบริการส่วนหน้าส่วนกลาง เกตเวย์ Istio Ingress จะรับการเข้าชมของไคลเอ็นต์จาก GCLB แล้วส่งการเข้าชมของไคลเอ็นต์ต่อไปยังพ็อดส่วนหน้าซึ่งทำงานในคลัสเตอร์แอปพลิเคชัน

หรือจะวาง Istio Ingress Gateway ไว้ในคลัสเตอร์แอปพลิเคชันโดยตรงก็ได้ และ GCLB จะใช้คลัสเตอร์เหล่านั้นเป็นแบ็กเอนด์ได้

ตัวควบคุม Autoneg ของ GKE

บริการ Kubernetes ของ Istio Ingress Gateway จะลงทะเบียนตัวเองเป็นแบ็กเอนด์กับ GCLB โดยใช้กลุ่มปลายทางของเครือข่าย (NEG) NEG อนุญาตให้ใช้การจัดสรรภาระงานสำหรับคอนเทนเนอร์เนทีฟโดยใช้ GCLB ระบบจะสร้าง NEG ผ่านคำอธิบายประกอบพิเศษในบริการ Kubernetes เพื่อให้ลงทะเบียนตัวเองกับตัวควบคุม NEG ได้ ตัวควบคุม Autoneg เป็นตัวควบคุม GKE พิเศษที่สร้าง NEG โดยอัตโนมัติ รวมถึงกำหนดให้เป็นแบ็กเอนด์ของ GCLB โดยใช้คำอธิบายประกอบของ Service ระบบจะติดตั้งใช้งานระนาบควบคุม Istio รวมถึงเกตเวย์ขาเข้าของ Istio ในระหว่างการสร้างโครงสร้างพื้นฐาน Terraform Cloud ครั้งแรก การกำหนดค่า GCLB และ autoneg จะดำเนินการเป็นส่วนหนึ่งของ Cloud Build โครงสร้างพื้นฐาน Terraform เริ่มต้น

รักษาความปลอดภัยของ Ingress โดยใช้ Cloud Endpoints และใบรับรองที่จัดการ

ใบรับรองที่จัดการของ GCP ใช้เพื่อรักษาความปลอดภัยให้กับการรับส่งข้อมูลของไคลเอ็นต์ไปยังfrontendบริการ GCLB GCLB ใช้ใบรับรองที่มีการจัดการสำหรับบริการ frontend ทั่วโลก และใบรับรองจะสิ้นสุดที่ GCLB ในเวิร์กช็อปนี้ คุณจะใช้ Cloud Endpoints เป็นโดเมนสำหรับใบรับรองที่จัดการ หรือคุณจะใช้โดเมนและชื่อ DNS สำหรับ frontend เพื่อสร้างใบรับรองที่จัดการโดย GCP ก็ได้

หากต้องการเข้าถึงร้านค้า Hipster ให้คลิกลิงก์เอาต์พุตของคำสั่งต่อไปนี้

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

คุณตรวจสอบได้ว่าใบรับรองถูกต้องหรือไม่โดยคลิกสัญลักษณ์แม่กุญแจในแถบ URL ของแท็บ Chrome

ยืนยันการจัดสรรภาระงานทั่วโลก

ในส่วนของการติดตั้งใช้งานแอปพลิเคชัน มีการติดตั้งใช้งานเครื่องมือสร้างภาระงานในคลัสเตอร์การดำเนินการทั้ง 2 คลัสเตอร์ ซึ่งสร้างการเข้าชมทดสอบไปยังลิงก์ GCLB Hipster Shop Cloud Endpoints ตรวจสอบว่า GCLB ได้รับการเข้าชมและส่งไปยังทั้ง Istio Ingress Gateway

รับลิงก์ GCLB > การตรวจสอบ สำหรับโปรเจ็กต์การดำเนินการที่สร้าง GCLB ของร้านค้า Hipster

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

เปลี่ยนจากแบ็กเอนด์ทั้งหมดเป็น istio-ingressgateway จากเมนูแบบเลื่อนลงของแบ็กเอนด์ดังที่แสดงด้านล่าง

โปรดทราบว่าการเข้าชมจะไปยังทั้ง istio-ingressgateways

โดยจะมีการสร้าง NEG 3 รายการต่อ istio-ingressgateway เนื่องจากคลัสเตอร์การดำเนินการเป็นคลัสเตอร์ระดับภูมิภาค ระบบจึงสร้าง NEG 1 รายการสำหรับแต่ละโซนในภูมิภาค แต่ istio-ingressgateway Pod จะทำงานในโซนเดียวต่อภูมิภาค การรับส่งข้อมูลจะแสดงไปยังพ็อด istio-ingressgateway

เครื่องมือสร้างภาระงานทำงานในคลัสเตอร์การดำเนินการทั้ง 2 คลัสเตอร์เพื่อจำลองการรับส่งข้อมูลของไคลเอ็นต์จาก 2 ภูมิภาคที่เครื่องมืออยู่ ระบบจะส่งภาระงานที่สร้างขึ้นในภูมิภาคคลัสเตอร์การดำเนินการ 1 ไปยัง istio-ingressgateway ในภูมิภาค 2 ในทำนองเดียวกัน ระบบจะส่งภาระงานที่สร้างขึ้นในภูมิภาคคลัสเตอร์การดำเนินการ 2 ไปยัง istio-ingressgateway ในภูมิภาค 2

8. ความสามารถในการสังเกตด้วย Stackdriver

วัตถุประสงค์: เชื่อมต่อการวัดและส่งข้อมูลของ Istio กับ Stackdriver และตรวจสอบ

ติดตั้งทรัพยากร istio-telemetry รายการ
สร้าง/อัปเดตแดชบอร์ดบริการ Istio
ดูบันทึกคอนเทนเนอร์
ดูการติดตามแบบกระจายใน Stackdriver

วิธีการทดลองใช้การคัดลอกและวาง

ฟีเจอร์หลักอย่างหนึ่งของ Istio คือความสามารถในการสังเกตการณ์ ("o11y") ในตัว ซึ่งหมายความว่าแม้จะมีคอนเทนเนอร์แบบกล่องดำที่ไม่มีการวัดผล ผู้ปฏิบัติงานก็ยังสังเกตการรับส่งข้อมูลที่เข้าและออกจากคอนเทนเนอร์เหล่านี้ได้ ซึ่งจะช่วยให้สามารถให้บริการแก่ลูกค้าได้ การสังเกตการณ์นี้มีหลายวิธี ได้แก่ เมตริก บันทึก และการติดตาม

นอกจากนี้ เราจะใช้ระบบสร้างภาระงานในตัวของ Hipster Shop ด้วย การสังเกตการณ์ไม่ค่อยได้ผลในระบบแบบคงที่ที่ไม่มีการเข้าชม ดังนั้นการสร้างโหลดจึงช่วยให้เราเห็นวิธีการทำงาน การโหลดนี้ทำงานอยู่แล้ว ตอนนี้เราจะดูได้เท่านั้น

ติดตั้งไฟล์การกำหนดค่า istio to 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

Commit to k8s-repo

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

ดูสถานะของ Cloud Build ของโปรเจ็กต์ Ops ในแท็บที่เปิดไว้ก่อนหน้านี้ หรือโดยคลิกลิงก์ต่อไปนี้

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

ยืนยันการผสานรวม Istio → Stackdriver รับ CRD ของตัวแฮนเดิล Stackdriver

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

เอาต์พุตควรแสดงแฮนเดิลชื่อ stackdriver ดังนี้

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!

ตรวจสอบว่าการส่งออกเมตริก Istio ไปยัง Stackdriver ทํางานอยู่ คลิกลิงก์เอาต์พุตจากคำสั่งนี้

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

ระบบจะแจ้งให้คุณสร้าง Workspace ใหม่โดยใช้ชื่อตามโปรเจ็กต์ Ops เพียงเลือก "ตกลง" หากระบบแจ้งให้คุณทราบเกี่ยวกับ UI ใหม่ ให้ปิดกล่องโต้ตอบ

ในเครื่องมือสำรวจเมตริก ภายใต้ "ค้นหาประเภททรัพยากรและเมตริก" ให้พิมพ์ "istio" เพื่อดูว่ามีตัวเลือกต่างๆ เช่น "จำนวนคำขอของเซิร์ฟเวอร์" ในประเภททรัพยากร "คอนเทนเนอร์ Kubernetes" ซึ่งแสดงให้เห็นว่าเมตริกไหลจาก Mesh ไปยัง Stackdriver

(คุณจะต้องจัดกลุ่มตามป้ายกำกับ destination_service_name หากต้องการดูบรรทัดด้านล่าง)

การแสดงภาพเมตริกด้วยแดชบอร์ด:

ตอนนี้เมตริกของเราอยู่ในระบบ Stackdriver APM แล้ว เราจึงต้องการวิธีแสดงภาพเมตริกเหล่านั้น ในส่วนนี้ เราจะติดตั้งแดชบอร์ดที่สร้างไว้ล่วงหน้าซึ่งแสดงเมตริก "สัญญาณทอง" 3 ใน 4 รายการ ได้แก่ การเข้าชม (คำขอต่อวินาที) เวลาในการตอบสนอง (ในกรณีนี้คือเปอร์เซ็นไทล์ที่ 99 และ 50) และข้อผิดพลาด (ในตัวอย่างนี้ เราจะยกเว้นความอิ่มตัว)

พร็อกซี Envoy ของ Istio ให้เมตริกหลายรายการแก่เรา แต่เมตริกเหล่านี้เป็นชุดที่ดีในการเริ่มต้น (ดูรายการทั้งหมดได้ที่นี่) โปรดทราบว่าเมตริกแต่ละรายการมีชุดป้ายกำกับที่ใช้ในการกรอง การรวบรวม เช่น destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total เป็นต้น

ตอนนี้เรามาเพิ่มแดชบอร์ดเมตริกที่กำหนดไว้ล่วงหน้ากัน เราจะใช้ Dashboard API โดยตรง โดยปกติแล้วคุณจะไม่ดำเนินการนี้ด้วยการสร้างการเรียก API ด้วยตนเอง แต่จะดำเนินการในระบบการทำงานอัตโนมัติ หรือสร้างแดชบอร์ดด้วยตนเองใน UI บนเว็บ ซึ่งจะช่วยให้เราเริ่มต้นได้อย่างรวดเร็ว

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

ไปที่ลิงก์เอาต์พุตด้านล่างเพื่อดู "แดชบอร์ดบริการ" ที่เพิ่มใหม่

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

เราสามารถแก้ไขแดชบอร์ดในที่เดิมได้โดยใช้ UX แต่ในกรณีนี้ เราจะเพิ่มกราฟใหม่อย่างรวดเร็วโดยใช้ API หากต้องการดำเนินการดังกล่าว คุณควรดึงแดชบอร์ดเวอร์ชันล่าสุดลงมา แก้ไข แล้วส่งกลับขึ้นไปโดยใช้เมธอด HTTP PATCH

คุณดูแดชบอร์ดที่มีอยู่ได้โดยการค้นหา 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

เพิ่มกราฟใหม่: (เวลาในการตอบสนองเปอร์เซ็นไทล์ที่ 50): [ข้อมูลอ้างอิง API] ตอนนี้เราสามารถเพิ่มวิดเจ็ตกราฟใหม่ลงในแดชบอร์ดในโค้ดได้แล้ว การเปลี่ยนแปลงนี้สามารถตรวจสอบโดยเพื่อนร่วมงานและตรวจสอบในการควบคุมเวอร์ชันได้ นี่คือวิดเจ็ตที่จะเพิ่มซึ่งแสดงเวลาในการตอบสนองเปอร์เซ็นไทล์ที่ 50 (เวลาในการตอบสนองมัธยฐาน)

ลองแก้ไขแดชบอร์ดที่คุณเพิ่งได้รับโดยเพิ่ม Stanza ใหม่

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

อัปเดตแดชบอร์ดบริการที่มีอยู่

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

ดูแดชบอร์ดที่อัปเดตแล้วโดยไปที่ลิงก์เอาต์พุตต่อไปนี้

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

ทำการวิเคราะห์บันทึกอย่างง่าย

Istio มีชุดบันทึกที่มีโครงสร้างสำหรับการรับส่งข้อมูลเครือข่ายทั้งหมดใน Mesh และอัปโหลดไปยัง Stackdriver Logging เพื่อให้วิเคราะห์ข้ามคลัสเตอร์ได้ในเครื่องมือที่มีประสิทธิภาพหนึ่งเดียว ระบบจะใส่คำอธิบายประกอบในบันทึกด้วยข้อมูลเมตาระดับบริการ เช่น คลัสเตอร์ คอนเทนเนอร์ แอป connection_id เป็นต้น

ตัวอย่างรายการบันทึก (ในกรณีนี้คือ accesslog ของพร็อกซี Envoy) อาจมีลักษณะดังนี้ (ตัดทอน)

*** 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"

คุณดูบันทึกของ Control Plane ของ Istio ได้โดยเลือกทรัพยากร > คอนเทนเนอร์ Kubernetes แล้วค้นหา "ไพลอต" ดังนี้

ในที่นี้ เราจะเห็นว่า Istio Control Plane กำลังพุชคอนฟิกพร็อกซีไปยังพร็อกซีไฟล์ช่วยเหลือสำหรับบริการแอปตัวอย่างแต่ละรายการ "CDS" "LDS" และ "RDS" แสดงถึง API ของ Envoy ที่แตกต่างกัน ( ข้อมูลเพิ่มเติม)

นอกจากบันทึกของ Istio แล้ว คุณยังดูบันทึกของคอนเทนเนอร์ รวมถึงบันทึกของโครงสร้างพื้นฐานหรือบริการอื่นๆ ของ GCP ได้ในอินเทอร์เฟซเดียวกัน ต่อไปนี้คือตัวอย่างการค้นหาบันทึกสำหรับ GKE โปรแกรมดูบันทึกยังช่วยให้คุณสร้างเมตริกจากบันทึกได้ด้วย (เช่น "นับทุกข้อผิดพลาดที่ตรงกับสตริงบางอย่าง") ซึ่งสามารถใช้ในแดชบอร์ดหรือเป็นส่วนหนึ่งของการแจ้งเตือนได้ นอกจากนี้ยังสตรีมบันทึกไปยังเครื่องมือวิเคราะห์อื่นๆ เช่น BigQuery ได้ด้วย

ตัวอย่างตัวกรองบางส่วนสำหรับร้านค้าฮิปสเตอร์

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

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

ดูการติดตามแบบกระจาย

เมื่อคุณทำงานกับระบบแบบกระจาย การแก้ไขข้อบกพร่องจึงต้องใช้เครื่องมือใหม่ นั่นคือการติดตามแบบกระจาย เครื่องมือนี้ช่วยให้คุณค้นพบสถิติเกี่ยวกับวิธีที่บริการโต้ตอบกัน (เช่น การค้นหาเหตุการณ์ที่ช้าผิดปกติในรูปภาพด้านล่าง) รวมถึงเจาะลึกร่องรอยตัวอย่างดิบเพื่อตรวจสอบรายละเอียดของสิ่งที่เกิดขึ้นจริง

มุมมองไทม์ไลน์แสดงคำขอทั้งหมดในช่วงระยะเวลาหนึ่ง โดยจะแสดงเป็นกราฟตามเวลาในการตอบสนอง หรือเวลาที่ใช้ตั้งแต่คำขอเริ่มต้นผ่านสแต็ก Hipster ไปจนถึงการตอบกลับผู้ใช้ปลายทางในที่สุด ยิ่งจุดอยู่สูงขึ้นเท่าใด ประสบการณ์ของผู้ใช้ก็จะยิ่งช้าลง (และไม่ดี!) เท่านั้น

คุณคลิกจุดเพื่อดูมุมมองน้ำตกแบบละเอียดของคำขอที่เฉพาะเจาะจงนั้นได้ ความสามารถในการค้นหารายละเอียดดิบของคำขอหนึ่งๆ (ไม่ใช่แค่สถิติรวม) มีความสำคัญอย่างยิ่งต่อการทำความเข้าใจการทำงานร่วมกันระหว่างบริการต่างๆ โดยเฉพาะอย่างยิ่งเมื่อต้องค้นหาการโต้ตอบที่เกิดขึ้นได้ยากแต่ไม่ดีระหว่างบริการ

มุมมองแบบน้ำตกควรเป็นสิ่งที่คุ้นเคยสำหรับทุกคนที่เคยใช้ดีบักเกอร์ แต่ในกรณีนี้แทนที่จะแสดงเวลาที่ใช้ในกระบวนการต่างๆ ของแอปพลิเคชันเดียว มุมมองนี้จะแสดงเวลาที่ใช้ในการข้ามผ่าน Mesh ของเรา ระหว่างบริการต่างๆ ที่ทำงานในคอนเทนเนอร์แยกกัน

คุณดูร่องรอยได้ที่นี่

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

ตัวอย่างภาพหน้าจอของเครื่องมือ

9. การตรวจสอบสิทธิ์ TLS ร่วม

วัตถุประสงค์: รักษาความปลอดภัยในการเชื่อมต่อระหว่าง Microservice (AuthN)

เปิดใช้ mTLS แบบกว้างใน Mesh
ยืนยัน mTLS โดยการตรวจสอบบันทึก

วิธีการทดลองใช้การคัดลอกและวาง

เมื่อติดตั้งแอปและตั้งค่าการสังเกตการณ์แล้ว เราก็เริ่มรักษาความปลอดภัยให้กับการเชื่อมต่อระหว่างบริการและตรวจสอบว่าบริการยังคงทำงานได้

เช่น เราจะเห็นในแดชบอร์ด Kiali ว่าบริการของเราไม่ได้ใช้ MTLS (ไม่มีไอคอน "ล็อก") แต่การเข้าชมก็ยังคงดำเนินต่อไปและระบบก็ทำงานได้ดี แดชบอร์ดเมตริกทองของ StackDriver ช่วยให้เรามั่นใจได้ว่าทุกอย่างทำงานได้ตามปกติโดยรวม

ตรวจสอบ 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 ได้รับการกำหนดค่าในคลัสเตอร์ทั้งหมดโดยใช้ตัวดำเนินการ Istio ซึ่งใช้ทรัพยากรที่กำหนดเอง (CR) ของ IstioControlPlane เราจะกำหนดค่า mTLS ในคลัสเตอร์ทั้งหมดโดยการอัปเดต IstioControlPlane CR และอัปเดต k8s-repo การตั้งค่า global > mTLS > enabled: true ในผลลัพธ์ของ IstioControlPlane CR จะทําให้เกิดการเปลี่ยนแปลง 2 อย่างต่อไปนี้ในระนาบควบคุม Istio

ตั้งค่า MeshPolicy ให้เปิดใช้ mTLS ระดับ Mesh สำหรับบริการทั้งหมดที่ทำงานในคลัสเตอร์ทั้งหมด
ระบบจะสร้าง DestinationRule เพื่ออนุญาตการรับส่งข้อมูล ISTIO_MUTUAL ระหว่างบริการที่ทำงานในคลัสเตอร์ทั้งหมด

เราจะใช้แพตช์ Kustomize กับ CR ของ IstioControlPlane เพื่อเปิดใช้ 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

Commit to k8s-repo

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

ดูสถานะของ Cloud Build ของโปรเจ็กต์ Ops ในแท็บที่เปิดไว้ก่อนหน้านี้ หรือโดยคลิกลิงก์ต่อไปนี้

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

ยืนยัน mTLS

ตรวจสอบ 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": {}
    }
  ]
}

อธิบาย DestinationRule ที่สร้างโดยตัวควบคุมโอเปอเรเตอร์ Istio

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 ในบันทึกด้วย

เราสามารถแสดงฟิลด์นี้จากบันทึกใน UI ได้โดยคลิกรายการบันทึกรายการใดรายการหนึ่ง แล้วคลิกค่าของฟิลด์ที่ต้องการแสดง ในกรณีนี้ ให้คลิก "http" ข้าง "protocol:"

ซึ่งจะช่วยให้เห็นภาพการเปลี่ยนผ่านได้อย่างชัดเจน

10. การทำให้ Canary ใช้งานได้

วัตถุประสงค์: เปิดตัวบริการส่วนหน้าเวอร์ชันใหม่

เปิดตัวบริการ frontend-v2 (เวอร์ชันที่ใช้งานจริงถัดไป) ในภูมิภาคเดียว
ใช้ DestinationRules และ VirtualServices เพื่อค่อยๆ เปลี่ยนเส้นทางการเข้าชมไปยัง frontend-v2
ยืนยันไปป์ไลน์การติดตั้งใช้งาน GitOps โดยตรวจสอบชุดการคอมมิตไปยัง k8s-repo

วิธีการทดลองใช้การคัดลอกและวาง

การติดตั้งใช้งานแบบคานารีคือการเปิดตัวบริการใหม่แบบค่อยเป็นค่อยไป ในการทำให้ใช้งานได้แบบคานารี คุณจะส่งการเข้าชมไปยังเวอร์ชันใหม่ในปริมาณที่เพิ่มขึ้น ขณะที่ยังคงส่งเปอร์เซ็นต์ที่เหลือไปยังเวอร์ชันปัจจุบัน รูปแบบที่ใช้กันทั่วไปคือการทำการวิเคราะห์คานารีในแต่ละขั้นตอนของการแยกการเข้าชม และเปรียบเทียบ "สัญญาณทอง" ของเวอร์ชันใหม่ (เวลาในการตอบสนอง อัตราข้อผิดพลาด ความอิ่มตัว) กับเกณฑ์พื้นฐาน ซึ่งจะช่วยป้องกันไม่ให้เกิดการหยุดทำงาน และรับประกันความเสถียรของบริการ "v2" ใหม่ในทุกขั้นตอนของการแยกการเข้าชม

ในส่วนนี้ คุณจะได้เรียนรู้วิธีใช้ Cloud Build และนโยบายการรับส่งข้อมูลของ Istio เพื่อสร้างการติดตั้งใช้งานแบบคานารีพื้นฐานสำหรับบริการ frontend เวอร์ชันใหม่

ก่อนอื่น เราจะเรียกใช้ไปป์ไลน์ Canary ในภูมิภาค DEV1 (us-west1) และเปิดตัวส่วนหน้า v2 ในคลัสเตอร์ทั้ง 2 รายการในภูมิภาคนั้น ประการที่ 2 เราจะเรียกใช้ไปป์ไลน์ Canary ในภูมิภาค DEV2 (us-central) และติดตั้งใช้งาน v2 ในทั้ง 2 คลัสเตอร์ในภูมิภาคนั้น การเรียกใช้ไปป์ไลน์ในภูมิภาคตามลำดับเทียบกับการเรียกใช้แบบขนานในทุกภูมิภาคจะช่วยหลีกเลี่ยงการหยุดทำงานทั่วโลกที่เกิดจากการกำหนดค่าที่ไม่ถูกต้องหรือข้อบกพร่องในแอป v2 เอง

หมายเหตุ: เราจะทริกเกอร์ไปป์ไลน์ Canary ในทั้ง 2 ภูมิภาคด้วยตนเอง แต่ในเวอร์ชันที่ใช้งานจริง คุณจะต้องใช้ทริกเกอร์อัตโนมัติ เช่น ทริกเกอร์ที่อิงตามแท็กอิมเมจ Docker ใหม่ที่พุชไปยังรีจิสทรี

จาก Cloud Shell ให้กำหนดตัวแปรสภาพแวดล้อมบางอย่างเพื่อลดความซับซ้อนในการเรียกใช้คำสั่งที่เหลือ

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

เรียกใช้สคริปต์ repo_setup.sh เพื่อคัดลอกไฟล์ Manifest พื้นฐานไปยัง k8s-repo

$CANARY_DIR/repo-setup.sh

ระบบจะคัดลอกไฟล์ Manifest ต่อไปนี้

การติดตั้งใช้งาน frontend-v2
แพตช์ frontend-v1 (เพื่อรวมป้ายกำกับ "v1" และรูปภาพที่มีปลายทาง "/version")
respy ซึ่งเป็นพ็อดขนาดเล็กที่จะพิมพ์การกระจายการตอบกลับ HTTP และช่วยให้เราเห็นภาพการติดตั้งใช้งาน Canary แบบเรียลไทม์
Istio DestinationRule ของส่วนหน้า - แยกบริการ Kubernetes ของส่วนหน้าออกเป็น 2 เซ็ตย่อย ได้แก่ v1 และ v2 โดยอิงตามป้ายกำกับการติดตั้งใช้งาน "version"
VirtualService ของ Istio แบ็กเอนด์ - กำหนดเส้นทางการรับส่งข้อมูล 100% ไปยังแบ็กเอนด์ v1 ซึ่งจะลบล้างลักษณะการทำงานแบบ Round Robin เริ่มต้นของบริการ Kubernetes ซึ่งจะส่งการรับส่งข้อมูลระดับภูมิภาคทั้งหมดของ Dev1 ไปยังส่วนหน้า v2 ทันที 50%

ส่งการเปลี่ยนแปลงไปยัง k8s_repo:

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

ดูสถานะของ Cloud Build ของโปรเจ็กต์ Ops ในแท็บที่เปิดไว้ก่อนหน้านี้ หรือโดยคลิกลิงก์ต่อไปนี้

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

ไปที่ Cloud Build ในคอนโซลสำหรับโปรเจ็กต์ OPS1 รอให้ไปป์ไลน์ Cloud Build เสร็จสมบูรณ์ จากนั้นรับพ็อดในเนมสเปซส่วนหน้าในคลัสเตอร์ DEV1 ทั้ง 2 คลัสเตอร์ คุณควรเห็นสิ่งต่อไปนี้

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 บานหน้าต่าง

บานหน้าต่างด้านล่างจะเรียกใช้คำสั่ง watch เพื่อสังเกตการกระจายการตอบสนอง HTTP สำหรับบริการส่วนหน้า
บานหน้าต่างด้านบนจะเรียกใช้สคริปต์ไปป์ไลน์ Canary จริง

เรียกใช้คำสั่งเพื่อแยกหน้าต่าง Cloud Shell แล้วเรียกใช้คำสั่ง watch ในบานหน้าต่างด้านล่าง

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%            |
|          |                   |
+----------+-------------------+

เรียกใช้ไปป์ไลน์คานารีในภูมิภาค Dev1 เรามีสคริปต์ที่อัปเดตเปอร์เซ็นต์การเข้าชม frontend-v2 ใน VirtualService (อัปเดตน้ำหนักเป็น 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%             |
|          |                   |
+----------+-------------------+

เมื่อการเปิดตัว Dev2 สำหรับ frontend-v2 เสร็จสมบูรณ์แล้ว คุณควรเห็นข้อความแสดงความสำเร็จที่ส่วนท้ายของสคริปต์
```
 Output (do not copy) 
```

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

และการรับส่งข้อมูลส่วนหน้าทั้งหมดจากพ็อด Dev2 ควรไปที่ frontend-v2
```
 Output (do not copy) 
```

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

ปิดแผงแยก

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

ไปที่ Cloud Source Repos ที่ลิงก์ที่สร้างขึ้น

echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

คุณควรเห็นคอมมิตแยกต่างหากสำหรับเปอร์เซ็นต์การเข้าชมแต่ละรายการ โดยคอมมิตล่าสุดจะอยู่ด้านบนของรายการ

ตอนนี้คุณจะทำกระบวนการเดียวกันซ้ำสำหรับภูมิภาค Dev2 โปรดทราบว่าภูมิภาค Dev2 ยังคง "ล็อก" ใน v1 เนื่องจากในสคริปต์ repo_setup พื้นฐาน เราได้พุช VirtualService เพื่อส่งการรับส่งข้อมูลทั้งหมดไปยัง v1 อย่างชัดเจน ด้วยวิธีนี้ เราจึงสามารถทำการทดสอบเวอร์ชันคานารีระดับภูมิภาคใน Dev1 ได้อย่างปลอดภัย และตรวจสอบว่าการทดสอบทำงานได้สำเร็จก่อนที่จะเปิดตัวเวอร์ชันใหม่ทั่วโลก

เรียกใช้คำสั่งเพื่อแยกหน้าต่าง Cloud Shell แล้วเรียกใช้คำสั่ง watch ในบานหน้าต่างด้านล่าง

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%            |
|          |                   |
+----------+-------------------+

เรียกใช้ไปป์ไลน์ Canary ในภูมิภาค Dev2 เรามีสคริปต์ที่อัปเดตเปอร์เซ็นต์การเข้าชม frontend-v2 ใน VirtualService (อัปเดตน้ำหนักเป็น 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%            |
|          |                   |
+----------+-------------------+

จากพ็อด Respy ใน Dev2 ให้ดูการรับส่งข้อมูลจากพ็อด Dev2 ที่ค่อยๆ ย้ายจากส่วนหน้า v1 ไปยัง v2 เมื่อสคริปต์ทำงานเสร็จแล้ว คุณควรเห็นข้อมูลต่อไปนี้

เอาต์พุต (ห้ามคัดลอก)

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

ปิดแผงแยก

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

ส่วนนี้ได้แนะนำวิธีใช้ Istio สำหรับการติดตั้งใช้งาน Canary ระดับภูมิภาค ในสภาพแวดล้อมการใช้งานจริง คุณอาจเรียกใช้สคริปต์ Canary นี้โดยอัตโนมัติเป็นไปป์ไลน์ Cloud Build แทนที่จะใช้สคริปต์ที่ทำด้วยตนเอง โดยใช้ทริกเกอร์ เช่น อิมเมจที่ติดแท็กใหม่ซึ่งพุชไปยัง Container Registry นอกจากนี้ คุณยังอาจต้องการเพิ่มการวิเคราะห์ Canary ระหว่างแต่ละขั้นตอน โดยวิเคราะห์เวลาในการตอบสนองและอัตราข้อผิดพลาดของ v2 เทียบกับเกณฑ์ความปลอดภัยที่กำหนดไว้ล่วงหน้า ก่อนที่จะส่งการเข้าชมเพิ่มเติม

11. นโยบายการให้สิทธิ์

วัตถุประสงค์: ตั้งค่า RBAC ระหว่างไมโครเซอร์วิส (AuthZ)

สร้าง AuthorizationPolicy เพื่อปฏิเสธการเข้าถึงไมโครเซอร์วิส
สร้าง AuthorizationPolicy เพื่ออนุญาตการเข้าถึงเฉพาะไมโครเซอร์วิส

วิธีการทดลองใช้การคัดลอกและวาง

แอป Microservice ที่กระจายอยู่ทั่วโลกจะทำการเรียกข้ามขอบเขตเครือข่าย ซึ่งต่างจากแอปพลิเคชันแบบโมโนลิธที่อาจทำงานในที่เดียว ซึ่งหมายความว่าจะมีจุดแรกเข้าในแอปพลิเคชันมากขึ้น และมีโอกาสมากขึ้นที่จะถูกโจมตีอย่างประสงค์ร้าย และเนื่องจากพ็อด Kubernetes มี IP ชั่วคราว กฎไฟร์วอลล์แบบเดิมที่อิงตาม IP จึงไม่เพียงพอที่จะรักษาความปลอดภัยในการเข้าถึงระหว่างภาระงานอีกต่อไป ในสถาปัตยกรรมแบบไมโครเซอร์วิส คุณต้องมีแนวทางใหม่ในการรักษาความปลอดภัย Istio สร้างขึ้นจากองค์ประกอบพื้นฐานด้านความปลอดภัยของ Kubernetes เช่น บัญชีบริการ เพื่อมอบชุดนโยบายความปลอดภัยที่ยืดหยุ่นสำหรับแอปพลิเคชันของคุณ

นโยบาย Istio ครอบคลุมทั้งการตรวจสอบสิทธิ์และการให้สิทธิ์ การตรวจสอบสิทธิ์จะยืนยันตัวตน (เซิร์ฟเวอร์นี้เป็นเซิร์ฟเวอร์ที่อ้างว่าเป็นหรือไม่) และการให้สิทธิ์จะยืนยันสิทธิ์ (ไคลเอ็นต์นี้ได้รับอนุญาตให้ทำเช่นนั้นหรือไม่) เราได้กล่าวถึงการตรวจสอบสิทธิ์ Istio ในส่วน TLS ร่วมกันในโมดูลที่ 1 (MeshPolicy) ในส่วนนี้ เราจะมาดูวิธีใช้นโยบายการให้สิทธิ์ของ Istio เพื่อควบคุมการเข้าถึงเวิร์กโหลดของแอปพลิเคชันอย่างหนึ่งของเรา นั่นคือ currencyservice

ก่อนอื่น เราจะติดตั้งใช้งาน AuthorizationPolicy ในคลัสเตอร์สำหรับนักพัฒนาแอปทั้ง 4 คลัสเตอร์ ปิดการเข้าถึงทั้งหมดไปยัง currencyservice และทริกเกอร์ข้อผิดพลาดในส่วนหน้า จากนั้นเราจะอนุญาตให้เฉพาะบริการส่วนหน้าเข้าถึง currencyservice

ตรวจสอบเนื้อหาของ currency-deny-all.yaml นโยบายนี้ใช้ตัวเลือกป้ายกำกับการติดตั้งใช้งานเพื่อจำกัดการเข้าถึง currencyservice โปรดสังเกตว่าไม่มีฟิลด์ 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

คัดลอกนโยบายสกุลเงินไปยัง k8s-repo สำหรับคลัสเตอร์การดำเนินการในทั้ง 2 ภูมิภาค

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

พุชการเปลี่ยนแปลง

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push

ตรวจสอบสถานะของ Cloud Build ของโปรเจ็กต์ Ops ในแท็บที่เปิดไว้ก่อนหน้านี้ หรือโดยคลิกลิงก์ต่อไปนี้

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

หลังจากบิลด์เสร็จสมบูรณ์แล้ว ให้ลองเข้าถึงส่วนหน้าของ Hipstershop ในเบราว์เซอร์โดยใช้ลิงก์ต่อไปนี้

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

คุณควรเห็นข้อผิดพลาดในการให้สิทธิ์จาก currencyservice ดังนี้

มาดูกันว่าบริการสกุลเงินบังคับใช้ AuthorizationPolicy นี้อย่างไร ก่อนอื่น ให้เปิดใช้บันทึกระดับการติดตามในพร็อกซี 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 -- curl -X POST \
"http://localhost:15000/logging?level=trace"

รับบันทึก RBAC (การให้สิทธิ์) จากพร็อกซี Sidecar ของบริการสกุลเงิน คุณควรเห็นข้อความ "ปฏิเสธที่บังคับใช้" ซึ่งบ่งชี้ว่ามีการตั้งค่า currencyservice ให้บล็อกคำขอขาเข้าทั้งหมด

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

เอาต์พุต (ห้ามคัดลอก)

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

ตอนนี้เรามาอนุญาตให้ส่วนหน้าเข้าถึง currencyservice กัน แต่จะไม่อนุญาตให้เข้าถึงบริการแบ็กเอนด์อื่นๆ เปิด currency-allow-frontend.yaml แล้วตรวจสอบเนื้อหา โปรดทราบว่าเราได้เพิ่มกฎต่อไปนี้

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

เอาต์พุต (ห้ามคัดลอก)

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

ในที่นี้ เราจะเพิ่ม source.principal (ไคลเอ็นต์) ที่เฉพาะเจาะจงลงในรายการที่อนุญาตเพื่อให้เข้าถึงบริการสกุลเงินได้ แหล่งที่มา.หลักนี้กำหนดโดยบัญชีบริการ Kubernetes ในกรณีนี้ บัญชีบริการที่เรากำลังเพิ่มลงในรายการที่อนุญาตคือบัญชีบริการส่วนหน้าในเนมสเปซส่วนหน้า

หมายเหตุ: เมื่อใช้บัญชีบริการ Kubernetes ใน Istio AuthorizationPolicies คุณต้องเปิดใช้ TLS แบบ 2 ทางทั้งคลัสเตอร์ก่อน ดังที่เราได้ทำในโมดูลที่ 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

พุชการเปลี่ยนแปลง

cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push

ดูสถานะของ Cloud Build ของโปรเจ็กต์ Ops ในแท็บที่เปิดไว้ก่อนหน้านี้ หรือโดยคลิกลิงก์ต่อไปนี้

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

หลังจากที่บิลด์เสร็จสมบูรณ์แล้ว ให้เปิดส่วนหน้าของ Hipstershop อีกครั้ง คราวนี้คุณไม่ควรเห็นข้อผิดพลาดในหน้าแรก เนื่องจากระบบอนุญาตให้ส่วนหน้าเข้าถึงบริการปัจจุบันอย่างชัดเจน
ตอนนี้ลองดำเนินการชำระเงินโดยเพิ่มสินค้าลงในรถเข็นแล้วคลิก "สั่งซื้อ" คราวนี้คุณควรเห็นข้อผิดพลาดในการแปลงราคาจากบริการสกุลเงิน ซึ่งเป็นเพราะเราอนุญาตเฉพาะส่วนหน้า ดังนั้น checkoutservice จึงยังคงเข้าถึง currencyservice ไม่ได้

สุดท้าย มาให้สิทธิ์บริการชำระเงินเข้าถึงสกุลเงินกัน โดยเพิ่มกฎอีกข้อลงใน AuthorizationPolicy ของ currencyservice โปรดทราบว่าเราจะเปิดสิทธิ์เข้าถึงสกุลเงินให้กับบริการ 2 อย่างที่ต้องเข้าถึงสกุลเงินเท่านั้น ได้แก่ ส่วนหน้าและชำระเงิน ส่วนแบ็กเอนด์อื่นๆ จะยังคงถูกบล็อก
เปิด currency-allow-frontend-checkout.yaml แล้วตรวจสอบเนื้อหา โปรดทราบว่ารายการกฎจะทําหน้าที่เป็น OR เชิงตรรกะ โดยสกุลเงินจะยอมรับเฉพาะคําขอจากเวิร์กโหลดที่มีบัญชีบริการใดบัญชีหนึ่งใน 2 บัญชีนี้

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"]

คัดลอกนโยบายการให้สิทธิ์ขั้นสุดท้ายไปยัง 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

พุชการเปลี่ยนแปลง

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push

ดูสถานะของ Cloud Build ของโปรเจ็กต์ Ops ในแท็บที่เปิดไว้ก่อนหน้านี้ หรือโดยคลิกลิงก์ต่อไปนี้

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

หลังจากบิลด์เสร็จสมบูรณ์แล้ว ให้ลองดำเนินการชำระเงิน ซึ่งควรจะทำงานได้สำเร็จ

ส่วนนี้จะอธิบายวิธีใช้นโยบายการให้สิทธิ์ของ Istio เพื่อบังคับใช้การควบคุมการเข้าถึงแบบละเอียดที่ระดับต่อบริการ ในสภาพแวดล้อมการใช้งานจริง คุณอาจสร้าง AuthorizationPolicy 1 รายการต่อบริการ และ (เช่น) ใช้นโยบายอนุญาตทั้งหมดเพื่อให้เวิร์กโหลดทั้งหมดในเนมสเปซเดียวกันเข้าถึงกันได้

12. การปรับขนาดโครงสร้างพื้นฐาน

วัตถุประสงค์: ขยายโครงสร้างพื้นฐานโดยการเพิ่มภูมิภาค โปรเจ็กต์ และคลัสเตอร์ใหม่

โคลนที่เก็บ infrastructure
อัปเดตไฟล์ Terraform เพื่อสร้างทรัพยากรใหม่
ซับเน็ต 2 รายการในภูมิภาคใหม่ (1 รายการสำหรับโปรเจ็กต์การดำเนินการ และ 1 รายการสำหรับโปรเจ็กต์ใหม่)
คลัสเตอร์การดำเนินการใหม่ในภูมิภาคใหม่ (ในซับเน็ตใหม่)
ระนาบควบคุม Istio ใหม่สำหรับภูมิภาคใหม่
คลัสเตอร์แอป 2 รายการในโปรเจ็กต์ใหม่ในภูมิภาคใหม่
คอมมิตไปยังที่เก็บ infrastructure
ยืนยันการติดตั้ง

วิธีการทดลองใช้การคัดลอกและวาง

การปรับขนาดแพลตฟอร์มทำได้หลายวิธี คุณเพิ่มการประมวลผลได้โดยการเพิ่มโหนดลงในคลัสเตอร์ที่มีอยู่ คุณเพิ่มคลัสเตอร์ในภูมิภาคได้ หรือจะเพิ่มภูมิภาคอื่นๆ ลงในแพลตฟอร์มก็ได้ การตัดสินใจว่าจะขยายขนาดแพลตฟอร์มในด้านใดขึ้นอยู่กับข้อกำหนด เช่น หากมีคลัสเตอร์ในทั้ง 3 โซนในภูมิภาค การเพิ่มโหนด (หรือ Node Pool) ลงในคลัสเตอร์ที่มีอยู่อาจเพียงพอ อย่างไรก็ตาม หากมีคลัสเตอร์ใน 2 จาก 3 โซนในภูมิภาคเดียว การเพิ่มคลัสเตอร์ใหม่ในโซนที่ 3 จะช่วยให้คุณได้การปรับขนาดและโดเมนข้อบกพร่องเพิ่มเติม (เช่น โซนใหม่) อีกเหตุผลหนึ่งในการเพิ่มคลัสเตอร์ใหม่ในภูมิภาคอาจเป็นความจำเป็นในการสร้างคลัสเตอร์ผู้เช่ารายเดียวด้วยเหตุผลด้านกฎระเบียบหรือการปฏิบัติตามข้อกำหนด (เช่น PCI หรือคลัสเตอร์ฐานข้อมูลที่จัดเก็บข้อมูล PII) เมื่อธุรกิจและบริการของคุณขยายตัว การเพิ่มภูมิภาคใหม่ๆ จะเป็นสิ่งที่หลีกเลี่ยงไม่ได้เพื่อให้สามารถให้บริการแก่ลูกค้าได้ใกล้ชิดยิ่งขึ้น

แพลตฟอร์มปัจจุบันประกอบด้วย 2 ภูมิภาคและคลัสเตอร์ใน 2 โซนต่อภูมิภาค คุณสามารถคิดถึงการปรับขนาดแพลตฟอร์มได้ 2 วิธี ดังนี้

ในแนวตั้ง - ภายในแต่ละภูมิภาคโดยการเพิ่มการประมวลผล ซึ่งทำได้โดยการเพิ่มโหนด (หรือ Node Pool) ลงในคลัสเตอร์ที่มีอยู่ หรือเพิ่มคลัสเตอร์ใหม่ภายในภูมิภาค โดยดำเนินการผ่านinfrastructure repo เส้นทางที่ง่ายที่สุดคือการเพิ่มโหนดไปยังคลัสเตอร์ที่มีอยู่ โดยไม่จำเป็นต้องกำหนดค่าเพิ่มเติม การเพิ่มคลัสเตอร์ใหม่อาจต้องใช้เครือข่ายย่อยเพิ่มเติม (และช่วงที่สอง) การเพิ่มกฎไฟร์วอลล์ที่เหมาะสม การเพิ่มคลัสเตอร์ใหม่ไปยังระนาบควบคุมของ ASM/Istio service mesh ระดับภูมิภาค และการติดตั้งใช้งานทรัพยากรแอปพลิเคชันไปยังคลัสเตอร์ใหม่
แนวนอน - โดยการเพิ่มภูมิภาค แพลตฟอร์มปัจจุบันมีเทมเพลตระดับภูมิภาคให้คุณ ประกอบด้วยคลัสเตอร์การดำเนินการระดับภูมิภาคซึ่งเป็นที่ตั้งของระนาบควบคุม ASM/Istio และคลัสเตอร์แอปพลิเคชันระดับโซน 2 คลัสเตอร์ (หรือมากกว่า) ซึ่งเป็นที่ทำให้ทรัพยากรแอปพลิเคชันใช้งานได้

ในเวิร์กช็อปนี้ คุณจะปรับขนาดแพลตฟอร์มใน "แนวนอน" เนื่องจากครอบคลุมขั้นตอนกรณีการใช้งานในแนวดิ่งด้วย หากต้องการขยายแพลตฟอร์มในแนวนอนโดยการเพิ่มภูมิภาคใหม่ (r3) ลงในแพลตฟอร์ม คุณจะต้องเพิ่มทรัพยากรต่อไปนี้

ซับเน็ตใน VPC ที่แชร์ของโปรเจ็กต์โฮสต์ในภูมิภาค r3 สำหรับคลัสเตอร์การดำเนินการและแอปพลิเคชันใหม่
คลัสเตอร์การดำเนินการระดับภูมิภาคในภูมิภาค r3 ซึ่งเป็นที่ตั้งของระนาบควบคุม ASM/Istio
คลัสเตอร์แอปพลิเคชันระดับโซน 2 รายการใน 2 โซนในภูมิภาค r3
อัปเดต k8s-repo โดยทำดังนี้
ทำให้ทรัพยากรระนาบควบคุม ASM/Istio ใช้งานได้กับคลัสเตอร์การดำเนินการในภูมิภาค r3
ทำให้ทรัพยากร Control Plane ที่แชร์ของ ASM/Istio ใช้งานได้กับคลัสเตอร์แอปในภูมิภาค r3
แม้ว่าคุณไม่จำเป็นต้องสร้างโปรเจ็กต์ใหม่ แต่ขั้นตอนในเวิร์กช็อปจะแสดงการเพิ่มโปรเจ็กต์ใหม่ dev3 เพื่อครอบคลุมกรณีการใช้งานในการเพิ่มทีมใหม่ลงในแพลตฟอร์ม

ใช้ที่เก็บโครงสร้างพื้นฐานเพื่อเพิ่มทรัพยากรใหม่ตามที่ระบุไว้ข้างต้น

ใน 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

โคลนที่เก็บแหล่งข้อมูลของเวิร์กช็อปสาขา add-proj ลงในไดเรกทอรี add-proj-repo

cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj

คัดลอกไฟล์จากadd-projสาขาในที่เก็บเวิร์กช็อปต้นทาง สาขา add-proj มีการเปลี่ยนแปลงสำหรับส่วนนี้

cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/

แทนที่ไดเรกทอรี infrastructure ในไดเรกทอรีที่เก็บ add-proj ด้วยลิงก์สัญลักษณ์ไปยังไดเรกทอรี infra-repo เพื่อให้สคริปต์ในสาขารันได้

rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure

เรียกใช้สคริปต์ add-project.sh เพื่อคัดลอกสถานะและตัวแปรที่แชร์ไปยังโครงสร้างไดเรกทอรีของโปรเจ็กต์ใหม่

$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo

คอมมิตและพุชการเปลี่ยนแปลงเพื่อสร้างโปรเจ็กต์ใหม่

cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master

การคอมมิตจะทริกเกอร์ให้ที่เก็บ infrastructure ไปติดตั้งใช้งานโครงสร้างพื้นฐานด้วยทรัพยากรใหม่ ดูความคืบหน้าของ Cloud Build โดยคลิกเอาต์พุตของลิงก์ต่อไปนี้ แล้วไปที่บิลด์ล่าสุดที่ด้านบน

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

ขั้นตอนสุดท้ายของ infrastructure Cloud Build คือการสร้างทรัพยากร Kubernetes ใหม่ใน k8s-repo ซึ่งจะทริกเกอร์ Cloud Build ใน k8s-repo (ในโปรเจ็กต์การดำเนินการ) ทรัพยากร Kubernetes ใหม่มีไว้สำหรับคลัสเตอร์ใหม่ 3 รายการที่เพิ่มในขั้นตอนก่อนหน้า ระบบจะเพิ่ม Control Plane ของ ASM/Istio และทรัพยากร Control Plane ที่แชร์ลงในคลัสเตอร์ใหม่ด้วย k8s-repo Cloud Build

หลังจาก Cloud Build ของโครงสร้างพื้นฐานเสร็จสมบูรณ์แล้ว ให้ไปที่k8s-repoการเรียกใช้ Cloud Build ล่าสุดโดยคลิกลิงก์เอาต์พุตต่อไปนี้

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

เรียกใช้สคริปต์ต่อไปนี้เพื่อเพิ่มคลัสเตอร์ใหม่ลงในไฟล์ vars และ kubeconfig

$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm

เปลี่ยนตัวแปร KUBECONFIG ให้ชี้ไปยังไฟล์ kubeconfig ใหม่

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

แสดงรายการบริบทคลัสเตอร์ คุณควรเห็น 8 คลัสเตอร์

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

ตรวจสอบว่าได้ติดตั้ง 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

ตรวจสอบว่าได้ติดตั้ง Istio ในคลัสเตอร์ dev3 ทั้ง 2 คลัสเตอร์แล้ว มีเพียง Citadel, sidecar-injector และ coredns เท่านั้นที่ทำงานในคลัสเตอร์ dev3 โดยใช้ Control Plane ของ Istio ที่ทำงานในคลัสเตอร์ ops-3 ร่วมกัน

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

ยืนยันการค้นพบบริการสำหรับระนาบควบคุมที่แชร์

ตรวจสอบว่าได้ติดตั้งใช้งานข้อมูลลับในคลัสเตอร์การดำเนินการทั้งหมดสำหรับคลัสเตอร์แอปพลิเคชันทั้ง 6 คลัสเตอร์

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. Circuit Breaking

วัตถุประสงค์: ใช้ Circuit Breaker สำหรับบริการจัดส่ง

สร้าง DestinationRule สำหรับบริการ shipping เพื่อใช้เซอร์กิตเบรกเกอร์
ใช้ fortio (ยูทิลิตีการสร้างภาระ) เพื่อตรวจสอบตัวตัดวงจรสำหรับบริการ shipping โดยตัดวงจรโดยบังคับ

วิธีการเข้าร่วม Fast Track Script Lab

Fast Track Script Lab จะพร้อมให้บริการเร็วๆ นี้!!

วิธีการทดลองใช้การคัดลอกและวาง

ตอนนี้เราได้เรียนรู้กลยุทธ์การตรวจสอบและการแก้ปัญหาพื้นฐานสำหรับบริการที่เปิดใช้ Istio แล้ว มาดูวิธีที่ Istio ช่วยปรับปรุงความยืดหยุ่นของบริการ ซึ่งจะช่วยลดจำนวนการแก้ปัญหาที่คุณจะต้องทำตั้งแต่แรกกัน

สถาปัตยกรรมแบบไมโครเซอร์วิสทำให้เกิดความเสี่ยงของความล้มเหลวแบบลุกลาม ซึ่งความล้มเหลวของบริการหนึ่งอาจส่งผลต่อบริการที่ขึ้นอยู่กับบริการนั้น และส่งผลต่อบริการที่ขึ้นอยู่กับบริการเหล่านั้นอีกต่อหนึ่ง ทำให้เกิดการหยุดทำงานแบบ "ผลกระทบแบบระลอกคลื่น" ที่อาจส่งผลต่อผู้ใช้ปลายทาง Istio มีนโยบายการรับส่งข้อมูล Circuit Breaker เพื่อช่วยคุณแยกบริการ ปกป้องบริการปลายทาง (ฝั่งไคลเอ็นต์) จากการรอให้บริการที่ล้มเหลวกลับมาทำงาน และปกป้องบริการต้นทาง (ฝั่งเซิร์ฟเวอร์) จากการรับส่งข้อมูลปลายทางที่เพิ่มขึ้นอย่างฉับพลันเมื่อบริการกลับมาออนไลน์ โดยรวมแล้ว การใช้ Circuit Breaker จะช่วยให้คุณหลีกเลี่ยงไม่ให้บริการทั้งหมดล้มเหลวตาม SLO เนื่องจากบริการแบ็กเอนด์หนึ่งๆ ที่หยุดทำงาน

รูปแบบเบรกเกอร์มีชื่อตามสวิตช์ไฟฟ้าที่ "ตัดวงจร" เมื่อมีกระแสไฟฟ้าไหลผ่านมากเกินไป ซึ่งจะช่วยปกป้องอุปกรณ์จากการโอเวอร์โหลด ในการตั้งค่า Istio หมายความว่า Envoy คือเซอร์กิตเบรกเกอร์ที่ติดตามจำนวนคำขอที่รอดำเนินการสำหรับบริการ ในสถานะปิดเริ่มต้นนี้ คำขอจะไหลผ่าน Envoy โดยไม่หยุดชะงัก

แต่เมื่อจำนวนคำขอที่รอดำเนินการเกินเกณฑ์ที่กำหนดไว้ เซอร์กิตเบรกเกอร์จะทำงาน (เปิด) และ Envoy จะแสดงข้อผิดพลาดทันที ซึ่งจะช่วยให้เซิร์ฟเวอร์แจ้งข้อผิดพลาดแก่ไคลเอ็นต์ได้อย่างรวดเร็ว และป้องกันไม่ให้โค้ดแอปพลิเคชันเซิร์ฟเวอร์รับคำขอของไคลเอ็นต์เมื่อมีการใช้งานมากเกินไป

จากนั้นหลังจากหมดเวลาที่กำหนด Envoy จะเปลี่ยนเป็นสถานะกึ่งเปิด ซึ่งเซิร์ฟเวอร์จะเริ่มรับคำขออีกครั้งในลักษณะการทดลอง และหากตอบกลับคำขอได้สำเร็จ เบรกเกอร์วงจรจะปิดอีกครั้ง และคำขอไปยังเซิร์ฟเวอร์จะเริ่มไหลอีกครั้ง

แผนภาพนี้สรุปรูปแบบ Circuit Breaker ของ Istio สี่เหลี่ยมผืนผ้าสีน้ำเงินแสดง Envoy, วงกลมสีน้ำเงินแสดงไคลเอ็นต์ และวงกลมสีขาวแสดงคอนเทนเนอร์เซิร์ฟเวอร์

คุณกำหนดนโยบาย Circuit Breaker ได้โดยใช้ 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 ที่ควรทราบมี 2 รายการ connectionPool กำหนดจำนวนการเชื่อมต่อที่บริการนี้จะอนุญาต ฟิลด์ outlierDetection คือส่วนที่เรากำหนดค่าวิธีที่ Envoy จะกำหนดเกณฑ์ที่จะเปิด Circuit Breaker ในที่นี้ ทุกวินาที (ช่วงเวลา) Envoy จะนับจำนวนข้อผิดพลาดที่ได้รับจากคอนเทนเนอร์เซิร์ฟเวอร์ หากเกินเกณฑ์ consecutiveErrors เบรกเกอร์วงจร Envoy จะเปิดขึ้น และพ็อด productcatalog ทั้งหมด 100% จะได้รับการป้องกันจากคำขอของไคลเอ็นต์ใหม่เป็นเวลา 10 วินาที เมื่อเซอร์กิตเบรกเกอร์ Envoy เปิดอยู่ (เช่น ใช้งานอยู่) ไคลเอ็นต์จะได้รับข้อผิดพลาด 503 (บริการไม่พร้อมใช้งาน) มาดูการทำงานจริงกัน

ตั้งค่าตัวแปรสภาพแวดล้อมสำหรับไดเรกทอรี k8s-repo และ asm เพื่อลดความซับซ้อนของคำสั่ง

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

อัปเดต k8s-repo

cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR

อัปเดต DestinationRule ของบริการจัดส่งในคลัสเตอร์ Ops ทั้ง 2 รายการ

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 ลงในคลัสเตอร์ GKE_1 ในภูมิภาค Dev1 นี่คือพ็อดไคลเอ็นต์ที่เราจะใช้เพื่อ "ทริป" เบรกเกอร์วงจรสำหรับ shippingservice

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

ส่งการเปลี่ยนแปลง

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

รอให้ Cloud Build เสร็จสมบูรณ์
กลับไปที่ Cloud Shell แล้วใช้พ็อด Fortio เพื่อส่งการรับส่งข้อมูล gRPC ไปยัง shippingservice โดยมีการเชื่อมต่อพร้อมกัน 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

ตอนนี้ให้เรียกใช้ Fortio อีกครั้ง โดยเพิ่มจำนวนการเชื่อมต่อพร้อมกันเป็น 2 แต่ยังคงจำนวนคำขอทั้งหมดไว้เท่าเดิม เราควรเห็นคำขอไม่เกิน 2 ใน 3 ที่ส่งกลับข้อผิดพลาด"overflow" เนื่องจากมีการทริกเกอร์เซอร์กิตเบรกเกอร์ ในนโยบายที่เรากำหนดไว้ อนุญาตให้มีการเชื่อมต่อพร้อมกันเพียง 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 กัน

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

ล้างข้อมูลโดยนำนโยบายเซอร์กิตเบรกเกอร์ออกจากทั้ง 2 ภูมิภาค

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

ส่วนนี้แสดงวิธีตั้งค่านโยบาย Circuit Breaker เดียวสำหรับบริการ แนวทางปฏิบัติแนะนำคือการตั้งค่าเซอร์กิตเบรกเกอร์สำหรับบริการต้นทาง (แบ็กเอนด์) ที่อาจหยุดทำงาน การใช้โพลีซี Circuit Breaker ของ Istio จะช่วยแยก Microservice สร้างความทนทานต่อข้อบกพร่องในสถาปัตยกรรม และลดความเสี่ยงของข้อบกพร่องแบบลุกลามภายใต้ภาระงานสูง

14. Fault Injection

วัตถุประสงค์: ทดสอบความยืดหยุ่นของบริการแนะนำโดยการเพิ่มความล่าช้า (ก่อนที่จะพุชไปยังเวอร์ชันที่ใช้งานจริง)

สร้าง VirtualService สำหรับบริการ recommendation เพื่อให้เกิดการหน่วงเวลา 5 วินาที
ทดสอบความล่าช้าโดยใช้fortioเครื่องมือสร้างภาระงาน
นำความล่าช้าใน VirtualService ออกและตรวจสอบ

วิธีการเข้าร่วม Fast Track Script Lab

Fast Track Script Lab จะพร้อมให้บริการเร็วๆ นี้!!

วิธีการทดลองใช้การคัดลอกและวาง

การเพิ่มนโยบายเซอร์กิตเบรกเกอร์ลงในบริการเป็นวิธีหนึ่งในการสร้างความยืดหยุ่นต่อบริการในเวอร์ชันที่ใช้งานจริง แต่การหยุดวงจรจะทำให้เกิดข้อบกพร่อง ซึ่งอาจเป็นข้อผิดพลาดที่ผู้ใช้เห็น ซึ่งไม่ใช่วิธีที่ดี หากต้องการเตรียมพร้อมรับมือกับกรณีข้อผิดพลาดเหล่านี้และคาดการณ์ได้ดียิ่งขึ้นว่าบริการดาวน์สตรีมอาจตอบสนองอย่างไรเมื่อแบ็กเอนด์แสดงข้อผิดพลาด คุณสามารถใช้การทดสอบแบบสุ่มในสภาพแวดล้อมการจัดเตรียมได้ การทดสอบแบบแรนด้อมคือการจงใจทำให้บริการหยุดทำงานเพื่อวิเคราะห์จุดอ่อนในระบบและปรับปรุงความทนทานต่อข้อผิดพลาด นอกจากนี้ คุณยังใช้การทดสอบแบบแรนด้อมเพื่อระบุวิธีลดข้อผิดพลาดที่ผู้ใช้พบเมื่อแบ็กเอนด์ล้มเหลวได้ด้วย เช่น การแสดงผลลัพธ์ที่แคชไว้ในส่วนหน้า

การใช้ Istio สำหรับการแทรกข้อบกพร่องมีประโยชน์เนื่องจากคุณสามารถใช้รูปภาพรุ่นที่ใช้งานจริงและเพิ่มข้อบกพร่องที่เลเยอร์เครือข่ายได้แทนที่จะแก้ไขซอร์สโค้ด ในสภาพแวดล้อมการใช้งานจริง คุณอาจใช้เครื่องมือทดสอบความโกลาหลแบบเต็มรูปแบบเพื่อทดสอบความยืดหยุ่นที่เลเยอร์ Kubernetes/การประมวลผลนอกเหนือจากเลเยอร์เครือข่าย

คุณใช้ Istio สำหรับการทดสอบแบบแรนดอมได้โดยใช้ VirtualService ที่มีช่อง "fault" Istio รองรับข้อบกพร่อง 2 ประเภท ได้แก่ ข้อบกพร่องที่ทำให้เกิดความล่าช้า (แทรกการหมดเวลา) และข้อบกพร่องที่ทำให้เกิดการหยุด (แทรกข้อผิดพลาด HTTP) ในตัวอย่างนี้ เราจะแทรกข้อบกพร่องความล่าช้า 5 วินาทีลงในบริการคำแนะนำ แต่ครั้งนี้เราจะบังคับให้บริการดาวน์สตรีมทนต่อการหมดเวลาเต็มรูปแบบแทนที่จะใช้เซอร์กิตเบรกเกอร์เพื่อ "ล้มเหลวอย่างรวดเร็ว" กับบริการที่ค้างอยู่

ไปที่ไดเรกทอรีการแทรกข้อบกพร่อง

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

เปิด k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml เพื่อตรวจสอบเนื้อหา โปรดทราบว่า Istio มีตัวเลือกในการแทรกข้อบกพร่องลงในคำขอตามเปอร์เซ็นต์ ในที่นี้เราจะกำหนดการหมดเวลาในคำขอทั้งหมดของ recommendationservice

เอาต์พุต (ห้ามคัดลอก)

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

คัดลอก VirtualService ไปยัง k8s_repo เราจะแทรกข้อบกพร่องทั่วโลกในทั้ง 2 ภูมิภาค

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 เสร็จสมบูรณ์
Exec เข้าไปในพ็อด Fortio ที่ติดตั้งใช้งานในส่วนเบรกเกอร์ และส่งการรับส่งข้อมูลไปยัง 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

    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

อีกวิธีในการดูข้อบกพร่องที่เราแทรกไว้คือเปิดส่วนหน้าในเว็บเบราว์เซอร์ แล้วคลิกผลิตภัณฑ์ใดก็ได้ หน้าผลิตภัณฑ์ควรใช้เวลาโหลดเพิ่มอีก 5 วินาที เนื่องจากจะดึงข้อมูลสินค้าแนะนำที่แสดงที่ด้านล่างของหน้า
ล้างข้อมูลโดยนำบริการการแทรกข้อบกพร่องออกจากทั้ง 2 คลัสเตอร์ 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

15. การตรวจสอบ Control Plane ของ Istio

ASM จะติดตั้งคอมโพเนนต์ระนาบควบคุมที่สำคัญ 4 รายการ ได้แก่ Pilot, Mixer, Galley และ Citadel แต่ละรายการจะส่งเมตริกการตรวจสอบที่เกี่ยวข้องไปยัง Prometheus และ ASM มาพร้อมกับแดชบอร์ด Grafana ที่ช่วยให้ผู้ปฏิบัติงานเห็นภาพข้อมูลการตรวจสอบนี้ และประเมินสถานะและประสิทธิภาพของ Control Plane

การดูแดชบอร์ด

ส่งต่อพอร์ตของบริการ Grafana ที่ติดตั้งด้วย Istio

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

เปิด Grafana ในเบราว์เซอร์
คลิกไอคอน "ตัวอย่างเว็บ" ที่มุมขวาบนของหน้าต่าง Cloud Shell
คลิก "แสดงตัวอย่างบนพอร์ต 3000" (หมายเหตุ: หากพอร์ตไม่ใช่ 3000 ให้คลิก "เปลี่ยนพอร์ต" แล้วเลือกพอร์ต 3000)
ซึ่งจะเป็นการเปิดแท็บในเบราว์เซอร์ที่มี URL คล้ายกับ " BASE_URL/?orgId=1&authuser=0&environment_id=default"
ดูแดชบอร์ดที่พร้อมใช้งาน
แก้ไข URL เป็น "BASE_URL/dashboard"
คลิกโฟลเดอร์ "istio" เพื่อดูแดชบอร์ดที่พร้อมใช้งาน
คลิกแดชบอร์ดใดก็ได้เพื่อดูประสิทธิภาพของคอมโพเนนต์นั้น เราจะดูเมตริกที่สำคัญสำหรับแต่ละคอมโพเนนต์ในส่วนต่อไปนี้

โปรแกรมนำร่องการตรวจสอบ

Pilot เป็นคอมโพเนนต์ของ Control Plane ที่กระจายการกำหนดค่าเครือข่ายและนโยบายไปยัง Data Plane (พร็อกซี Envoy) โดยทั่วไปแล้ว Pilot จะปรับขนาดตามจำนวนภาระงานและการติดตั้งใช้งาน แม้ว่าจะไม่จำเป็นต้องปรับขนาดตามปริมาณการรับส่งข้อมูลไปยังภาระงานเหล่านั้นก็ตาม Pilot ที่มีประสิทธิภาพไม่ดีจะทำสิ่งต่อไปนี้ได้

ใช้ทรัพยากรมากกว่าที่จำเป็น (CPU และ/หรือ RAM)
ทำให้การส่งข้อมูลการกำหนดค่าที่อัปเดตไปยัง Envoy ล่าช้า

หมายเหตุ: หาก Pilot หยุดทำงานหรือมีความล่าช้า เวิร์กโหลดจะยังคงแสดงการเข้าชม

ไปที่ "BASE_URL/dashboard/db/istio-pilot-dashboard" ในเบราว์เซอร์เพื่อดูเมตริกของ Pilot

เมตริกที่สำคัญซึ่งมีการตรวจสอบ

การใช้ทรัพยากร

ใช้หน้าประสิทธิภาพและความสามารถในการปรับขนาดของ Istio เป็นแนวทางสำหรับตัวเลขการใช้งานที่ยอมรับได้ โปรดติดต่อทีมสนับสนุนของ GCP หากเห็นการใช้ทรัพยากรอย่างต่อเนื่องมากกว่านี้อย่างมาก

ข้อมูลการทดสอบข้อความ Push

ส่วนนี้จะตรวจสอบการพุชการกำหนดค่าของ Pilot ไปยังพร็อกซี Envoy

การพุชเวอร์ชันนำร่องจะแสดงประเภทของการกำหนดค่าที่พุชในเวลาใดก็ตาม
การตรวจสอบ ADS จะแสดงจำนวนบริการเสมือน บริการ และอุปกรณ์ปลายทางที่เชื่อมต่อในระบบ
คลัสเตอร์ที่ไม่มีปลายทางที่รู้จักจะแสดงปลายทางที่กำหนดค่าไว้แต่ไม่มีอินสแตนซ์ที่ทำงานอยู่ (ซึ่งอาจบ่งบอกถึงบริการภายนอก เช่น *.googleapis.com)
ข้อผิดพลาดในเวอร์ชันนำร่องแสดงจำนวนข้อผิดพลาดที่พบในช่วงระยะเวลาหนึ่ง
ความขัดแย้งจะแสดงจำนวนความขัดแย้งซึ่งเป็นการกำหนดค่าที่ไม่ชัดเจนใน Listener

หากมีข้อผิดพลาดหรือความขัดแย้ง แสดงว่าคุณมีการกำหนดค่าที่ไม่ดีหรือไม่สอดคล้องกันสำหรับบริการอย่างน้อย 1 รายการ ดูข้อมูลได้ที่การแก้ปัญหา Data Plane

ข้อมูล Envoy

ส่วนนี้ประกอบด้วยข้อมูลเกี่ยวกับพร็อกซี Envoy ที่ติดต่อกับ Control Plane โปรดติดต่อทีมสนับสนุนของ GCP หากคุณเห็นข้อผิดพลาดในการเชื่อมต่อ XDS ซ้ำๆ

มิกเซอร์สำหรับมอนิเตอร์

Mixer คือคอมโพเนนต์ที่ส่งต่อการวัดและส่งข้อมูลจากพร็อกซี Envoy ไปยังแบ็กเอนด์ของการวัดและส่งข้อมูล (โดยทั่วไปคือ Prometheus, Stackdriver ฯลฯ) ในความสามารถนี้ ไม่ได้อยู่ใน Data Plane โดยจะได้รับการติดตั้งใช้งานเป็นงาน Kubernetes 2 งาน (เรียกว่า Mixer) ที่ติดตั้งใช้งานด้วยชื่อบริการ 2 ชื่อที่แตกต่างกัน (istio-telemetry และ istio-policy)

นอกจากนี้ยังใช้ Mixer เพื่อผสานรวมกับระบบนโยบายได้ด้วย ในความสามารถนี้ Mixer มีผลต่อ Data Plane เนื่องจากนโยบายที่ตรวจสอบกับ Mixer ไม่สำเร็จจะบล็อกการเข้าถึงบริการของคุณ

Mixer มีแนวโน้มที่จะปรับขนาดตามปริมาณการเข้าชม

ไปที่ "BASE_URL/dashboard/db/istio-mixer-dashboard" ในเบราว์เซอร์เพื่อดูเมตริกของ Mixer

เมตริกที่สำคัญที่ต้องตรวจสอบ

การใช้ทรัพยากร

ภาพรวมของมิกเซอร์

ระยะเวลาการตอบกลับเป็นเมตริกที่สำคัญ แม้ว่ารายงานไปยังการวัดระยะทางของ Mixer จะไม่ได้อยู่ในเส้นทางข้อมูล แต่หากเวลาในการตอบสนองเหล่านี้สูง ก็จะทำให้ประสิทธิภาพของพร็อกซี Sidecar ช้าลงอย่างแน่นอน คุณควรคาดหวังว่าเปอร์เซ็นไทล์ที่ 90 จะอยู่ในระดับมิลลิวินาทีแบบหลักเดียว และเปอร์เซ็นไทล์ที่ 99 จะต่ำกว่า 100 มิลลิวินาที

ระยะเวลาการส่งต่ออแดปเตอร์ระบุเวลาในการตอบสนองที่ Mixer พบในการเรียกอแดปเตอร์ (ซึ่งจะส่งข้อมูลไปยังระบบการวัดระยะไกลและการบันทึก) ความหน่วงสูงที่นี่จะส่งผลต่อประสิทธิภาพใน Mesh อย่างแน่นอน อีกครั้งหนึ่ง เวลาในการตอบสนองที่เปอร์เซ็นไทล์ที่ 90 ควรต่ำกว่า 10 มิลลิวินาที

แกลเลอรีการตรวจสอบ

Galley เป็นคอมโพเนนต์การตรวจสอบความถูกต้อง การส่งผ่านข้อมูล การประมวลผล และการกระจายการกำหนดค่าของ Istio โดยจะส่งการกำหนดค่าจากเซิร์ฟเวอร์ Kubernetes API ไปยัง Pilot เช่นเดียวกับ Pilot โดยมีแนวโน้มที่จะปรับขนาดตามจำนวนบริการและปลายทางในระบบ

ไปที่ "BASE_URL/dashboard/db/istio-galley-dashboard" ในเบราว์เซอร์เพื่อดูเมตริก Galley

เมตริกที่สำคัญที่ต้องตรวจสอบ

การตรวจสอบทรัพยากร

เมตริกที่สำคัญที่สุดที่ควรติดตามซึ่งระบุจำนวนทรัพยากรประเภทต่างๆ เช่น กฎปลายทาง เกตเวย์ และรายการบริการที่ผ่านหรือไม่ผ่านการตรวจสอบ

ไคลเอ็นต์ที่เชื่อมต่อ

ระบุจำนวนไคลเอ็นต์ที่เชื่อมต่อกับ Galley โดยปกติแล้วจะมี 3 รายการ (pilot, istio-telemetry, istio-policy) และจะปรับขนาดตามการปรับขนาดของคอมโพเนนต์เหล่านั้น

16. การแก้ปัญหา Istio

การแก้ปัญหา Data Plane

หากแดชบอร์ดโปรแกรมนำร่องระบุว่าคุณมีปัญหาในการกำหนดค่า คุณควรตรวจสอบบันทึกของโปรแกรมนำร่องหรือใช้ istioctl เพื่อค้นหาปัญหาการกำหนดค่า

หากต้องการตรวจสอบบันทึกของ Pilot ให้เรียกใช้ kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery โดยแทนที่ istio-pilot-... ด้วยตัวระบุพ็อดสำหรับอินสแตนซ์ Pilot ที่คุณต้องการแก้ปัญหา

ในบันทึกที่ได้ ให้ค้นหาข้อความสถานะการพุช เช่น

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 ซึ่งจะวิเคราะห์การกำหนดค่าในระบบของคุณ ระบุปัญหาพร้อมกับการเปลี่ยนแปลงที่แนะนำ ดูเอกสารประกอบเพื่อดูรายการข้อผิดพลาดในการกำหนดค่าทั้งหมดที่คำสั่งนี้ตรวจหาได้

17. ล้างข้อมูล

ผู้ดูแลระบบเรียกใช้สคริปต์ cleanup_workshop.sh เพื่อลบทรัพยากรที่สร้างโดยสคริปต์ bootstrap_workshop.sh คุณต้องมีข้อมูลต่อไปนี้เพื่อให้สคริปต์ล้างข้อมูลทำงาน

ชื่อองค์กร เช่น yourcompany.com
รหัสเวิร์กช็อป - ในรูปแบบ YYMMDD-NN เช่น 200131-01
Bucket ของ GCS สำหรับผู้ดูแลระบบ - กำหนดไว้ในสคริปต์การเริ่มต้น

เปิด Cloud Shell แล้วดำเนินการทั้งหมดด้านล่างใน Cloud Shell คลิกลิงก์ด้านล่าง

CLOUD SHELL

ตรวจสอบว่าคุณได้เข้าสู่ระบบ gcloud ด้วยผู้ใช้ที่เป็นผู้ดูแลระบบที่ต้องการ

gcloud config list

ไปยังโฟลเดอร์ asm

cd ${WORKDIR}/asm

กำหนดชื่อองค์กรและรหัสเวิร์กช็อปที่จะลบ

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}