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

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

หมายเหตุสำคัญ: เวิร์กช็อปนี้เป็นเวิร์กช็อปอัลฟ่าและมีเจตนาให้เป็นการฝึกอบรมสำหรับชั้นเรียนที่นำโดยผู้สอน

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

2. ภาพรวม

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

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

กำหนดการ

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

สไลด์

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

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

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

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

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

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

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

หากคุณเป็นผู้ใช้ที่ทำเวิร์กช็อป ให้ข้ามไปยังส่วนถัดไปที่มีป้ายกำกับ Infrastructure Setup - User Workflow

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

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

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

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

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

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

สคริปต์เวิร์กช็อป Bootstrap ใช้ค่าที่ระบุข้างต้นและทำหน้าที่เป็นสคริปต์ Wrapper ที่เรียกสคริปต์ setup-terraform-admin-project.sh สคริปต์ settings-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>

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

• [e-mail]
• [e-mail]
• [e-mail]

ชื่อผู้ใช้เหล่านี้ได้รับมอบหมายบทบาทเจ้าของโปรเจ็กต์สําหรับโปรเจ็กต์ที่เฉพาะเจาะจงซึ่งสร้างขึ้นในระหว่างสคริปต์ settings_terraform_admin_project.sh คุณต้องปฏิบัติตามสคีมาการตั้งชื่อผู้ใช้นี้เมื่อใช้สคริปต์ Bootstrap โปรดดูวิธีเพิ่มผู้ใช้หลายคนพร้อมกันใน 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 หากไม่ได้ติดตั้ง kustomize ให้ติดตั้งโดยใช้สคริปต์ Bash ที่ระบุไว้ในลิงก์ด้านบน และตรวจสอบว่าไบนารี kustomize อยู่ใน PATH และยืนยันโดยเรียกใช้คำสั่ง kustomize ใน Cloud Shell

จัดเวิร์กช็อปสำหรับตัวคุณเอง (การตั้งค่าของผู้ใช้รายเดียว)

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

CLOUD SHELL

2. ยืนยันว่าคุณเข้าสู่ระบบ gcloud ด้วยผู้ใช้ที่ดูแลระบบที่ต้องการ

gcloud config list
 

3. สร้าง WORKDIR และโคลนที่เก็บของเวิร์กช็อป

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

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

5. เรียกใช้สคริปต์ Bootstrap_workshop.sh สคริปต์นี้อาจใช้เวลาสักครู่จึงจะเสร็จสมบูรณ์

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

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

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

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

6. จัดหาไฟล์ตัวแปรเพื่อตั้งค่าตัวแปรสภาพแวดล้อม

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

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

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

CLOUD SHELL

8. ยืนยันว่าคุณเข้าสู่ระบบ gcloud ด้วยผู้ใช้ที่ดูแลระบบที่ต้องการ

gcloud config list
 

9. สร้าง WORKDIR และโคลนที่เก็บของเวิร์กช็อป

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

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

11. เรียกใช้สคริปต์ 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}
 

12. รับไฟล์ 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. การตั้งค่าและการเตรียมห้องทดลอง

ผู้ใช้ที่ดำเนินเวิร์กช็อปจะเริ่มที่นี่ ทำตามขั้นตอนทั้งหมดจากหน้าต่าง INCOGNITO ใน Chrome หรือ Firefox

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

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

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

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

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

สคริปต์การติดตามอย่างรวดเร็ว

${WORKDIR}/asm/fasttrack_scripts/<name_of_script>.sh

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

ขณะทำห้องทดลอง โปรดเลือกวิธีใดวิธีหนึ่งจาก 2 วิธี

หลังจากที่เลือกวิธีการและทำตามขั้นตอนในวิธีการนั้นแล้ว อย่าทำขั้นตอนในวิธีอื่น

การตั้งค่าสคริปต์แทร็กด่วน

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

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

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

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

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

CLOUD SHELL

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

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

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

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

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

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=[e-mail] 
 

หมายเหตุ: หากคุณเป็นผู้ดูแลระบบและจัดเวิร์กช็อปให้ตัวเองโดยใช้ "-sufa" หรือ "–setup-for-admin" จากนั้นตั้งค่า MY_USER เป็นอีเมลสำหรับบัญชี GCP ที่คุณใช้สร้างโครงการเวิร์กช็อป

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

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

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

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

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

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

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

สคริปต์การติดตามอย่างรวดเร็ว

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

${WORKDIR}/asm/fasttrack_scripts/infrastructure-setup-user-workflow.sh

หลังจากสคริปต์เสร็จสมบูรณ์แล้ว ให้ระบุ bashrc เพื่ออัปเดตตัวแปรในเซสชัน Cloud Shell

source ${HOME}/.bashrc

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

สำคัญ: หากคุณทำสคริปต์แทร็กด่วนสำหรับห้องทดลองนี้เสร็จแล้ว โปรดอย่าใช้วิธีคัดลอกและวางด้านล่าง****

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

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

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

เวิร์กช็อปนี้มีไว้เพื่อเตรียมความพร้อมจาก Cloud Shell เวิร์กช็อปนี้ต้องใช้เครื่องมือต่อไปนี้

เครื่องมือทั้งหมดยกเว้น kustomize และ pv ได้รับการติดตั้งโดยค่าเริ่มต้นใน Cloud Shell แล้ว คุณจะเห็นวิธีการติดตั้งทั้ง 2 รูปแบบที่ด้านล่าง

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

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

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

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

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

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

CLOUD SHELL

2. ติดตั้ง 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
 

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

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

4. อัปเดตข้อความแจ้งเกี่ยวกับ 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
 

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

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

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

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

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

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

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

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

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

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

สคริปต์ terraform ใช้เวลา 40-50 นาที

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

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

หมายเหตุ: บิลด์นี้ต้องทำให้เสร็จก่อนที่คุณจะยืนยันการติดตั้ง Istio ได้

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

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

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

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

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

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

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

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

14. แสดงรายการบริบทคลัสเตอร์ คุณจะเห็น 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

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

16. ตรวจสอบว่าติดตั้ง Istio ในคลัสเตอร์ dev1 ทั้ง 2 คลัสเตอร์แล้ว มีเพียง Citadel, Sidecar-injector และ Coredns เท่านั้นที่ทํางานในคลัสเตอร์ dev1 โดยแชร์ระนาบควบคุม Istio ที่ทำงานอยู่ในคลัสเตอร์ Ops-1

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

17. ตรวจสอบว่าติดตั้ง Istio ในคลัสเตอร์ dev2 ทั้ง 2 คลัสเตอร์แล้ว มีเพียง Citadel, Sidecar-injector และ Coredns เท่านั้นที่ทํางานในคลัสเตอร์ dev2 โดยแชร์ระนาบควบคุม Istio ที่ทำงานอยู่ในคลัสเตอร์ 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

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

18. (ไม่บังคับ) ตรวจสอบว่ามีการนำข้อมูลลับไปใช้แล้ว

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

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

Cloud Build สำหรับโครงสร้างพื้นฐาน

ทรัพยากร GCP สำหรับเวิร์กช็อปสร้างขึ้นโดยใช้ Cloud Build และที่เก็บ CSR ของ infrastructure คุณเพิ่งเรียกใช้สคริปต์ Bootstrap (อยู่ที่ scripts/bootstrap_workshop.sh) จากเทอร์มินัลในเครื่อง สคริปต์ Bootstrap จะสร้างโฟลเดอร์ GCP, โปรเจ็กต์ผู้ดูแลระบบ terraform และสิทธิ์ IAM ที่เหมาะสมสำหรับบัญชีบริการ Cloud Build โครงการผู้ดูแลระบบ Terraform ใช้ในการจัดเก็บสถานะ บันทึก และสคริปต์อื่นๆ ของ terraform ข้อความนี้มีที่เก็บ infrastructure และ k8s_repo CSR คำอธิบายเหล่านี้จะอธิบายอย่างละเอียดในส่วนถัดไป โดยจะไม่มีการสร้างทรัพยากรของเวิร์กชอปอื่นๆ ในโปรเจ็กต์ผู้ดูแลระบบของ 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, ขั้นตอน, prod) เลเยอร์ถัดไปของโฟลเดอร์ภายในสภาพแวดล้อมจะแสดง resource ที่เฉพาะเจาะจง (เช่น host_project, gke_clusters ฯลฯ) สคริปต์และไฟล์ terraform ที่จำเป็นอยู่ในโฟลเดอร์ทรัพยากร

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

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

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

ผู้ให้บริการ สถานะ และเอาต์พุต - แบ็กเอนด์และสถานะที่แชร์

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

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

ทรัพยากรที่มีค่าซึ่งไม่เกี่ยวข้องกันจะมีไฟล์ output.tf ค่าเอาต์พุตที่จำเป็นจะเก็บอยู่ในไฟล์ tfstate ที่กำหนดไว้ในแบ็กเอนด์สำหรับทรัพยากรนั้นๆ ตัวอย่างเช่น คุณจำเป็นต้องทราบรหัสโปรเจ็กต์เพื่อสร้างคลัสเตอร์ GKE ในโปรเจ็กต์ รหัสโปรเจ็กต์จะแสดงผลผ่าน ISRC.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 ในโปรเจ็กต์ Ops ไฟล์ shared_state สร้างขึ้นจากเทมเพลต (อยู่ที่ templates/shared_state.tf_tmpl) โดยใช้สคริปต์ (อยู่ที่ scripts/setup_terraform_admin_project) แหล่งข้อมูลทั้งหมด ไฟล์ shared_state จะอยู่ในโฟลเดอร์ gcp/[environment]/shared_states ไฟล์ shared_state ที่จำเป็นจะได้รับลิงก์ไว้ในโฟลเดอร์ทรัพยากรที่เกี่ยวข้อง การวางไฟล์ shared_state ทั้งหมดไว้ในโฟลเดอร์เดียวและลิงก์ไฟล์เหล่านั้นไว้ในโฟลเดอร์ทรัพยากรที่เหมาะสมจะช่วยให้จัดการไฟล์สถานะทั้งหมดได้ในที่เดียว

ตัวแปร

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

ตัวแปร terform จัดเก็บไว้ใน 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 ทีม โดยแต่ละทีมมีโครงการของตนเอง

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

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

1. คลัสเตอร์ Ops - ใช้โดยทีมปฏิบัติการเพื่อเรียกใช้เครื่องมือ DevOps ในเวิร์กช็อปนี้ องค์กรใช้ระนาบควบคุม ASM/Istio เพื่อจัดการโครงข่ายบริการ
2. คลัสเตอร์แอปพลิเคชัน (แอป) - ใช้โดยทีมพัฒนาเพื่อเรียกใช้แอปพลิเคชัน ในเวิร์กช็อปนี้ มีการใช้แอปร้านค้าฮิปสเตอร์

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

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

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

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

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

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

ชื่อคลัสเตอร์ 6 ชื่อ ได้แก่

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

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

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

วัตถุประสงค์: ทำให้แอปร้านค้าฮิปสเตอร์ใช้งานได้ในกลุ่มแอป

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

สคริปต์การติดตามอย่างรวดเร็ว

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

${WORKDIR}/asm/fasttrack_scripts/deploy-sample-app.sh

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

หากคุณได้เขียนสคริปต์ช่องทางด่วนสำหรับห้องทดลองนี้เรียบร้อยแล้ว โปรดอย่าใช้วิธีคัดลอกและวางด้านล่างนี้****

โคลนที่เก็บแหล่งที่มาของโปรเจ็กต์ Ops

เนื่องจากเป็นส่วนหนึ่งของการสร้างโครงสร้างพื้นฐาน Terraform ในขั้นแรก ระบบจึงสร้าง k8s-repo ขึ้นในโครงการปฏิบัติการ

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

mkdir $WORKDIR/k8s-repo
 

2. เริ่มที่เก็บ 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
 

3. ตั้งการกำหนดค่าภายในของ 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, ยืนยัน และพุช

4. คัดลอกเนมสเปซและบริการของร้านฮิปสเตอร์ไปยังที่เก็บต้นทางสำหรับคลัสเตอร์ทั้งหมด

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

5. คัดลอกโฟลเดอร์แอป 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/
 

6. คัดลอกการทำให้ใช้งานได้ของร้านฮิปสเตอร์, 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/

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

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
 

8. เพิ่มการทำให้บริการรถเข็นใช้งานได้, 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
 

9. นำ podsecuritypolicies, การทำให้ใช้งานได้ และไดเรกทอรี rbac ออกจากคลัสเตอร์ Ops kustomization.yaml

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

10. แทนที่ 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/*
  

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

cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
 

12. คัดลอกทรัพยากรเครื่องมือเชื่อมต่อการกำหนดค่าไปยังคลัสเตอร์ใดคลัสเตอร์หนึ่งในแต่ละโปรเจ็กต์

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/
 

13. แทนที่ 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/*
 

14. คัดลอกไฟล์ Manifest loadgenerator (Deployment, PodSecurityPolicy และ RBAC) ไปยังคลัสเตอร์ Ops เปิดตัวแอปร้านฮิปสเตอร์โดยใช้ตัวจัดสรรภาระงานของ Google Cloud (GCLB) ทั่วโลก GCLB จะรับการรับส่งข้อมูลของลูกค้า (ปลายทางคือ frontend) และส่งไปยังอินสแตนซ์ที่ใกล้ที่สุดของบริการ การวาง loadgenerator บนคลัสเตอร์การดำเนินการทั้งสองจะทำให้การรับส่งข้อมูลไปยังเกตเวย์ Istio Ingress ทั้ง 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/. 
 

15. แทนที่รหัสโปรเจ็กต์ Ops ในไฟล์ Manifest ของ loadgenerator สำหรับคลัสเตอร์ Ops ทั้ง 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
 

16. เพิ่มทรัพยากร loadgenerator ไปยัง kustomization.yaml สำหรับคลัสเตอร์ Ops ทั้ง 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
 

17. คอมมิตกับ k8s-repo

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

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

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

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

19. ยืนยันว่าพ็อดในเนมสเปซของแอปพลิเคชันทั้งหมดยกเว้นรถเข็นอยู่ในสถานะกำลังทำงานในคลัสเตอร์ dev ทั้งหมด

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

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

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

เข้าถึงแอปฮิปสเตอร์ Shop

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

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

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

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

ตัวควบคุม GKE Autoneg

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

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

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

21. หากต้องการเข้าถึงร้านฮิปสเตอร์ ให้คลิกผลลัพธ์ลิงก์ของคำสั่งต่อไปนี้

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

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

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

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

23. รับ GCLB > ลิงก์การตรวจสอบสำหรับโครงการปฏิบัติการที่สร้าง GCLB ร้านค้าฮิปสเตอร์

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" 
 

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

25. บันทึกการเข้าชมที่ไปยัง istio-ingressgateways ทั้ง 2 หมายเลข

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

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

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

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

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

สคริปต์การติดตามอย่างรวดเร็ว

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

${WORKDIR}/asm/fasttrack_scripts/observability-with-stackdriver.sh

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

หากคุณได้เขียนสคริปต์ช่องทางด่วนสำหรับห้องทดลองนี้เรียบร้อยแล้ว โปรดอย่าใช้วิธีคัดลอกและวางด้านล่างนี้****

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

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

1. ติดตั้งไฟล์กำหนดค่า istio ไปยังStackdriver

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
 

2. คอมมิตกับที่เก็บ k8s-repo

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

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

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

4. ตรวจสอบ Istio → การผสานรวม Stackdriver รับ CRD ของ Stackdriver Handler

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

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

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

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

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

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

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

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

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

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

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

6. ตอนนี้เรามาเพิ่มแดชบอร์ดเมตริกสำเร็จรูป เราจะใช้ 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
 

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

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

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

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

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

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

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
 

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

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
 

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

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

12. ทำการวิเคราะห์บันทึกแบบง่ายๆ

Istio มีชุดบันทึกที่มีโครงสร้างสำหรับการจราจรของข้อมูลในเครือข่ายภายในเครือข่ายทั้งหมด และอัปโหลดไปยัง Stackdriver Logging เพื่อให้สามารถวิเคราะห์ข้ามคลัสเตอร์ได้ในเครื่องมือที่มีประสิทธิภาพเพียงเครื่องมือเดียว บันทึกจะมีคำอธิบายประกอบด้วยข้อมูลเมตาระดับบริการ เช่น คลัสเตอร์, คอนเทนเนอร์, แอป, Connect_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"
 

คุณสามารถดูบันทึกระนาบควบคุมของ Istio ได้โดยเลือก Resource > คอนเทนเนอร์ Kubernetes และการค้นหาบน "การนำร่อง" -

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

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

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

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

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

13. ดูการติดตามที่เผยแพร่

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

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

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

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

คุณค้นหาการติดตามได้ที่นี่

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

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

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

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

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

สคริปต์การติดตามอย่างรวดเร็ว

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

${WORKDIR}/asm/fasttrack_scripts/mutual-tls.sh

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

หากคุณได้เขียนสคริปต์ช่องทางด่วนสำหรับห้องทดลองนี้เรียบร้อยแล้ว โปรดอย่าใช้วิธีคัดลอกและวางด้านล่างนี้****

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

ตัวอย่างเช่น เราเห็นในหน้าแดชบอร์ด Kiali ว่าบริการของเราไม่ได้ใช้ MTLS (ไม่มีไอคอน "ล็อก") แต่การจราจรลื่นไหลและระบบทำงานเป็นปกติ หน้าแดชบอร์ด StackDriver Golden Metrics ช่วยให้เราสามารถวางใจว่าสิ่งต่างๆ กำลังทำงานอยู่ในภาพรวม

1. ตรวจสอบ MeshPolicy ในคลัสเตอร์การดำเนินการ โปรดทราบว่า mTLS คือ PERMISSIVE ซึ่งอนุญาตสำหรับการรับส่งข้อมูลทั้งที่เข้ารหัสและไม่ใช่ mTLS

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

    `Output (do not copy)`

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

Istio ได้รับการกำหนดค่าบนคลัสเตอร์ทั้งหมดโดยใช้โอเปอเรเตอร์ Istio ซึ่งใช้ทรัพยากรที่กำหนดเอง (CR) IstioControlPlane เราจะกำหนดค่า mTLS ในคลัสเตอร์ทั้งหมดโดยอัปเดต IstioControlPlane CR และอัปเดตที่เก็บ k8s การตั้งค่าส่วนกลาง > mTLS เปิดใช้งาน: true ใน IstioControlPlane CR ส่งผลให้เกิดการเปลี่ยนแปลง 2 รายการต่อไปนี้ในระนาบควบคุม Istio

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

2. เราจะใช้แพตช์ Kustomize กับ istioControlPlane CR เพื่อเปิดใช้คลัสเตอร์ mTLS แบบกว้าง คัดลอกแพตช์ไปยังไดเรกทอรีที่เกี่ยวข้องสำหรับคลัสเตอร์ทั้งหมด และเพิ่มแพตช์การตรวจสอบ

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
 

3. คอมมิตกับที่เก็บ k8s-repo

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

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

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

 

ยืนยัน mTLS

5. ตรวจสอบ MeshPolicy อีกครั้งในคลัสเตอร์ Ops โปรดทราบว่า 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": {}
    }
  ]
}

6. อธิบายปลายทางRule ที่สร้างโดยตัวควบคุมโอเปอเรเตอร์ 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" ข้าง "โปรโตคอล:

ซึ่งช่วยให้เห็นภาพการเปลี่ยนแปลงได้ดี:

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

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

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

สคริปต์การติดตามอย่างรวดเร็ว

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

${WORKDIR}/asm/fasttrack_scripts/canary-deployments.sh

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

หากคุณได้เขียนสคริปต์ช่องทางด่วนสำหรับห้องทดลองนี้เรียบร้อยแล้ว โปรดอย่าใช้วิธีคัดลอกและวางด้านล่างนี้****

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

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

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

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

1. กำหนดตัวแปร env บางรายการจาก Cloud Shell เพื่อให้เรียกใช้คำสั่งที่เหลือได้ง่ายขึ้น

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

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

$CANARY_DIR/repo-setup.sh 
 

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

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

3. คอมมิตการเปลี่ยนแปลงใน k8s_repo:

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

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

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

5. ไปที่ 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

หมายเหตุ: Ctrl-C เพื่อออกจากคำสั่งของนาฬิกา

เราจะใช้ tmux เพื่อแบ่งหน้าต่าง Cloudshell เป็น 2 แผง ดังนี้

• แผงด้านล่างจะเรียกใช้คำสั่ง Watch เพื่อดูการกระจายการตอบสนอง HTTP สำหรับบริการฟรอนท์เอนด์
• แผงด้านบนจะเรียกใช้สคริปต์ไปป์ไลน์ Canary จริง

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

RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

เอาต์พุต (ไม่คัดลอก)

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

เราจะเห็นว่าการเข้าชมทั้งหมดไปที่การทำให้ฟรอนท์เอนด์ v1 ใช้งานได้ ที่กำหนดไว้ใน VirtualService ใหม่

7. ดำเนินการไปป์ไลน์ Canary ในภูมิภาค Dev1 เรามีสคริปต์ที่อัปเดตเปอร์เซ็นต์การเข้าชมฟรอนท์เอนด์ v2 ใน VirtualService (อัปเดตน้ำหนักเป็น 20%, 50%, 80% และ 100%) ระหว่างการอัปเดต สคริปต์จะรอให้ไปป์ไลน์ Cloud Build เสร็จสมบูรณ์ เรียกใช้สคริปต์การติดตั้งใช้งาน Canary สำหรับภูมิภาค 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%             |
|          |                   |
+----------+-------------------+

8. เมื่อการเปิดตัว Dev2 สำหรับ Frontend-v2 เสร็จสมบูรณ์ คุณควรเห็นข้อความดำเนินการสำเร็จที่ส่วนท้ายของสคริปต์:

    Output (do not copy) 
   

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

9. และการรับส่งข้อมูลฟรอนท์เอนด์ทั้งหมดจากพ็อด Dev2 ควรไปที่ฟรอนท์เอนด์ v2:

    Output (do not copy) 
   

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

10. ปิดแผงที่มีการแบ่งส่วน

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

11. ไปยังที่เก็บซอร์สของ Cloud ที่ลิงก์ที่สร้างไว้

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

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

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

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

RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

เอาต์พุต (ไม่คัดลอก)

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

เราจะเห็นว่าการเข้าชมทั้งหมดไปที่การทำให้ฟรอนท์เอนด์ v1 ใช้งานได้ ที่กำหนดไว้ใน VirtualService ใหม่

13. ดำเนินการไปป์ไลน์ Canary ในภูมิภาค Dev2 เรามีสคริปต์ที่อัปเดตเปอร์เซ็นต์การเข้าชมฟรอนท์เอนด์ v2 ใน VirtualService (อัปเดตน้ำหนักเป็น 20%, 50%, 80% และ 100%) ระหว่างการอัปเดต สคริปต์จะรอให้ไปป์ไลน์ Cloud Build เสร็จสมบูรณ์ เรียกใช้สคริปต์การติดตั้งใช้งาน Canary สำหรับภูมิภาค 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%            |
|          |                   |
+----------+-------------------+

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

เอาต์พุต (ไม่คัดลอก)

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

15. ปิดแผงที่มีการแบ่งส่วน

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

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

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

วัตถุประสงค์: ตั้งค่า RBAC ระหว่าง microservice (AuthZ)

• สร้าง AuthorizationPolicy เพื่อปฏิเสธสิทธิ์เข้าถึง Microservice
• สร้าง AuthorizationPolicy เพื่ออนุญาตสิทธิ์เข้าถึง Microservice ที่เฉพาะเจาะจง

สคริปต์การติดตามอย่างรวดเร็ว

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

${WORKDIR}/asm/fasttrack_scripts/authorization-policy.sh

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

หากคุณได้เขียนสคริปต์ช่องทางด่วนสำหรับห้องทดลองนี้เรียบร้อยแล้ว โปรดอย่าใช้วิธีคัดลอกและวางด้านล่างนี้****

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

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

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

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

2. คัดลอกนโยบายสกุลเงินลงในที่เก็บ k8s-repo สำหรับคลัสเตอร์ Ops ของทั้ง 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

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

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

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

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

5. หลังจากสร้างบิลด์สำเร็จแล้ว ให้ลองเข้าถึงฟรอนท์เอนด์ของฮิปสเตอร์ช็อปในเบราว์เซอร์ตามลิงก์ต่อไปนี้

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

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

6. มาตรวจสอบกันว่าบริการสกุลเงินบังคับใช้ 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"
 

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

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

เอาต์พุต (ไม่คัดลอก)

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

8. ตอนนี้ให้อนุญาตฟรอนท์เอนด์ แต่ไม่ใช่บริการแบ็กเอนด์อื่นๆ ให้เข้าถึง 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 (ไคลเอ็นต์) ที่เฉพาะเจาะจงไว้ในรายการที่อนุญาตพิเศษเพื่อเข้าถึงบริการสกุลเงิน ส่วน source.โดเมนหลัก จะกำหนดโดยบัญชีบริการ Kubernetes ในกรณีนี้ บัญชีบริการที่เราอนุญาตพิเศษคือบัญชีบริการฟรอนท์เอนด์ในเนมสเปซฟรอนท์เอนด์

หมายเหตุ: เมื่อใช้บัญชีบริการ Kubernetes ใน Istio AuthorizationPolicies คุณต้องเปิดใช้ TLS ร่วมในระดับคลัสเตอร์ก่อน ตามที่ทำในโมดูล 1 เพื่อให้มั่นใจว่าข้อมูลเข้าสู่ระบบของบัญชีบริการจะได้รับการต่อเชื่อมในคำขอ

9. คัดลอกนโยบายสกุลเงินที่อัปเดตแล้ว

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
 

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

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

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

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

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

14. สุดท้าย อนุญาตให้บริการการชำระเงินเข้าถึงสกุลเงิน โดยเพิ่มกฎอื่นใน AuthorizationPolicy ของบริการสกุลเงิน โปรดทราบว่าเราจะเปิดให้เข้าถึงโดยใช้สกุลเงินเฉพาะกับบริการ 2 บริการที่ต้องเข้าถึงเท่านั้น ได้แก่ ฟรอนท์เอนด์และจุดชำระเงิน ระบบจะยังคงบล็อกแบ็กเอนด์อื่นๆ
15. เปิด currency-allow-frontend-checkout.yaml และตรวจสอบเนื้อหา โปรดทราบว่ารายการกฎทำหน้าที่เป็นสกุลเงินเชิงตรรกะ "หรือ" จะยอมรับเฉพาะคำขอจากภาระงานที่มีบัญชีบริการใดบัญชีบริการหนึ่งจาก 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"]

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

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

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

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

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

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

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

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

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

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

สคริปต์การติดตามอย่างรวดเร็ว

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

${WORKDIR}/asm/fasttrack_scripts/infrastructure-scaling.sh

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

หากคุณได้เขียนสคริปต์ช่องทางด่วนสำหรับห้องทดลองนี้เรียบร้อยแล้ว โปรดอย่าใช้วิธีคัดลอกและวางด้านล่างนี้****

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

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

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

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

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

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

1. ใน Cloud Shell ให้ไปที่ WORKDIR แล้วโคลนที่เก็บ infrastructure

mkdir -p $WORKDIR/infra-repo
cd $WORKDIR/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure
git config --local user.email ${MY_USER}
git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

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

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

 

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

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

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

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

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

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

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

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

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

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

ขั้นตอนนี้ใช้เวลา 25 - 30 นาทีจึงจะเสร็จสมบูรณ์ ถึงเวลาพักดื่มกาแฟแล้ว

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

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

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

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

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

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

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

11. แสดงรายการบริบทคลัสเตอร์ คุณจะเห็นคลัสเตอร์ 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

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

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

13. ตรวจสอบว่าติดตั้ง Istio ในคลัสเตอร์ dev3 ทั้ง 2 คลัสเตอร์แล้ว มีเพียง Citadel, Sidecar-injector และ Coredns เท่านั้นที่ทํางานในคลัสเตอร์ dev3 โดยแชร์ระนาบควบคุม 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

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

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

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

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

คำแนะนำ Fast Track Script Lab

พบ Fast Track Script Lab เร็วๆ นี้!!

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

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

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

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

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

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

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

คุณกำหนดนโยบาย Circuit Breaker ได้โดยใช้ IstioปลายทางRules ในส่วนนี้ เราจะใช้นโยบายต่อไปนี้เพื่อบังคับใช้เบรกเกอร์สำหรับบริการจัดส่ง

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

มีช่องปลายทาง 2 ช่องที่ควรระบุที่นี่ connectionPool กำหนดจำนวนการเชื่อมต่อที่บริการนี้จะอนุญาต ฟิลด์ OutlierDetection คือที่ที่เรากำหนดค่าวิธีการที่ Envoy จะกำหนดเกณฑ์ที่ใช้ในการเปิดเบรกเกอร์ ในส่วนนี้ Envoy จะนับจำนวนข้อผิดพลาดที่ได้รับจากคอนเทนเนอร์ของเซิร์ฟเวอร์ หากเกินเกณฑ์ consecutiveErrors เบรกเกอร์ Envoy จะเปิดขึ้นและพ็อดแคตตาล็อกผลิตภัณฑ์ 100% จะได้รับการป้องกันจากคำขอของไคลเอ็นต์ใหม่เป็นเวลา 10 วินาที เมื่อตัวตัดวงจร Envoy เปิดขึ้น (เช่น ทำงานอยู่) ไคลเอ็นต์จะได้รับข้อผิดพลาด 503 (บริการไม่พร้อมใช้งาน) มาดูการทำงานกัน

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

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

2. อัปเดตที่เก็บ k8s-repo

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

3. อัปเดต EndRule ของบริการจัดส่งในคลัสเตอร์ 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
 

4. คัดลอกพ็อดสร้างโหลด Fortio ไปยังคลัสเตอร์ GKE_1 ในภูมิภาค Dev1 นี่คือพ็อดไคลเอ็นต์ที่เราจะใช้เพื่อ "เดินทาง" เบรกเกอร์สำหรับบริการจัดส่ง

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
 

5. ยืนยันการเปลี่ยนแปลง

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

6. รอให้ Cloud Build ดำเนินการเสร็จสมบูรณ์
7. กลับไปที่ Cloud Shell ให้ใช้ Fortio Pod เพื่อส่งการเข้าชม gRPC ไปยังบริการจัดส่งที่มีการเชื่อมต่อพร้อมกัน 1 รายการ รวมคำขอทั้งหมด 1,000 รายการ ซึ่งการดำเนินการนี้จะไม่ทำให้เบรกเกอร์ทำงานเกิน เนื่องจากเรายังไม่ได้ตั้งค่าเกิน connectionPool

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

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

เอาต์พุต (ไม่คัดลอก)

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

8. เรียกใช้ fortio อีกครั้ง เพิ่มจำนวนการเชื่อมต่อพร้อมกันเป็น 2 แต่รักษาจำนวนคำขอทั้งหมดให้คงที่ เราควรจะเห็นคำขอมากถึงสองในสามของคำขอที่ส่งผลลัพธ์เป็น "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

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

10. ล้างข้อมูลโดยนำนโยบายตัวตัดวงจรออกจากทั้ง 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 ของ Istio จะช่วยแยก Microservice สร้างการยอมรับข้อผิดพลาดในสถาปัตยกรรม และลดความเสี่ยงที่จะเกิดความล้มเหลวต่อเนื่องเมื่อมีภาระงานสูง

14. Fault Injection

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

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

คำแนะนำ Fast Track Script Lab

พบ Fast Track Script Lab เร็วๆ นี้!!

คำแนะนำสำหรับห้องทดลองวิธีการคัดลอกและวาง

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

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

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

11. ไปที่ไดเรกทอรี Fault Injection

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

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

เอาต์พุต (ไม่คัดลอก)

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

13. คัดลอก 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
 

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

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

15. รอให้ Cloud Build ดำเนินการเสร็จสมบูรณ์
16. ดำเนินการเข้าไปในพ็อด Fortio ที่ทำให้ใช้งานได้ในส่วน Circuit Breaker แล้วส่งการรับส่งข้อมูลบางส่วนไปยัง recommendationsservice

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

17. อีกวิธีหนึ่งในการดูข้อผิดพลาดที่เราแทรกเข้ามาคือเปิดฟรอนท์เอนด์ในเว็บเบราว์เซอร์ แล้วคลิกผลิตภัณฑ์ใดก็ได้ หน้าผลิตภัณฑ์อาจใช้เวลาโหลดเพิ่มเติม 5 วินาที เนื่องจากหน้าเว็บจะดึงข้อมูลคำแนะนำที่แสดงอยู่ด้านล่างของหน้า
18. ทำความสะอาดโดยนำบริการ Fault Injection ออกจากคลัสเตอร์ Ops ทั้ง 2 รายการ

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

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

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

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

15. การตรวจตราระนาบควบคุม Istio

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

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

20. ส่งต่อบริการ Grafana ที่ติดตั้งไว้ด้วย Istio

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

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

การนำร่องการตรวจสอบ

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

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

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

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

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

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

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

ข้อมูลพุชจากการนำร่อง

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

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

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

ข้อมูล Envoy

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

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

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

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

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

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

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

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

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

ภาพรวมเครื่องผสม

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

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

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

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

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

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

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

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

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

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

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

การแก้ปัญหาเกี่ยวกับระนาบข้อมูล

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

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

ในบันทึกที่เป็นผลลัพธ์ ให้ค้นหาข้อความ Push Status เช่น

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

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

หากต้องการความช่วยเหลือในการวินิจฉัยปัญหา โปรดติดต่อทีมสนับสนุนของ Google Cloud ที่มีปัญหา

กำลังค้นหาข้อผิดพลาดในการกำหนดค่า

หากต้องการใช้ istioctl เพื่อวิเคราะห์การกำหนดค่า ให้เรียกใช้ istioctl experimental analyze -k --context $OPS_GKE_1 ซึ่งจะทำการวิเคราะห์การกำหนดค่าในระบบ และระบุปัญหาพร้อมกับการเปลี่ยนแปลงที่แนะนำ ดูรายการข้อผิดพลาดทั้งหมดของการกำหนดค่าที่คำสั่งนี้ตรวจพบได้ในเอกสารประกอบ

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

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

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

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

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

CLOUD SHELL

14. ยืนยันว่าคุณเข้าสู่ระบบ gcloud ด้วยผู้ใช้ที่ดูแลระบบที่ต้องการ

gcloud config list
 

15. ไปยังส่วนต่างๆ ของโฟลเดอร์ asm

cd ${WORKDIR}/asm
 

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

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

17. เรียกใช้สคริปต์การล้างข้อมูลดังนี้

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