Hội thảo về lưới dịch vụ Anthos: Hướng dẫn cho phòng thí nghiệm

1. HỘI THẢO ALPHA

LƯU Ý QUAN TRỌNG: ĐÂY LÀ HỘI THẢO ALPHA VÀ CHỦ NGHĨA LÀ HOẠT ĐỘNG ĐÀO TẠO LỚP HỌC CÓ SỰ CỔNG HƯỚNG DẪN TRUYỀN DẪN.

Đường liên kết đến lớp học lập trình hội thảo bit.ly/asm-workshop

2. Tổng quan

Sơ đồ cấu trúc

Hội thảo này là trải nghiệm thực tế và sinh động, hướng dẫn cách thiết lập các dịch vụ được phân phối trên toàn cầu trên GCP trong phiên bản chính thức. Các công nghệ chính được sử dụng là Google Kubernetes Engine (GKE) cho điện toán và lưới dịch vụ Istio để tạo khả năng kết nối, khả năng quan sát và định hình lưu lượng nâng cao. Tất cả các phương pháp và công cụ dùng trong hội thảo này đều là những gì bạn sẽ sử dụng trong quá trình sản xuất.

Nội dung chính

• Mô-đun 0 – Giới thiệu và thiết lập nền tảng
• Giới thiệu và cấu trúc
• Giới thiệu về Lưới dịch vụ và Istio/ASM
• Phòng thí nghiệm: Thiết lập cơ sở hạ tầng: Quy trình làm việc của người dùng
• Nghỉ giải lao
• QnA
• Mô-đun 1 – Cài đặt, bảo mật và giám sát ứng dụng bằng ASM
• Mô hình Repo: Giải thích cơ sở hạ tầng và kho lưu trữ Kubernetes
• Phòng thí nghiệm: Triển khai ứng dụng mẫu
• Dịch vụ được phân phối và khả năng quan sát
• Bữa trưa
• Lab: Khả năng quan sát bằng Stackdriver
• QNA
• Học phần 2 – DevOps – Phát hành Canary, chính sách/RBAC
• Khám phá dịch vụ nhiều cụm và bảo mật/chính sách
• Phòng thí nghiệm: TLS tương hỗ
• Triển khai Canary
• Phòng thí nghiệm: Triển khai Canary
• Cân bằng tải chung an toàn nhiều cụm
• Nghỉ giải lao
• Lab: Chính sách uỷ quyền
• QNA
• Mô-đun 3 – Hoạt động cơ sở hạ tầng – Nâng cấp nền tảng
• Thành phần của Dịch vụ phân phối
• Phòng thí nghiệm: Mở rộng cơ sở hạ tầng
• Các bước tiếp theo

Trang trình bày

Bạn có thể tham khảo các trang trình bày dành cho hội thảo này tại đường liên kết sau:

Trang trình bày về hội thảo của ASM

Điều kiện tiên quyết

Bạn cần đáp ứng những yêu cầu sau đây trước khi tham gia hội thảo này:

1. Nút Tổ chức GCP
2. Mã tài khoản thanh toán (người dùng của bạn phải là Quản trị viên thanh toán trên tài khoản thanh toán này)
3. Vai trò IAM của quản trị viên tổ chức ở cấp tổ chức đối với người dùng

3. Thiết lập cơ sở hạ tầng – Quy trình làm việc của quản trị viên

Quản trị viên sẽ thực hiện các bước trong phần này khi tạo hội thảo.

Nếu bạn là người dùng đang thực hiện hội thảo này, hãy chuyển đến phần tiếp theo có nhãn Infrastructure Setup - User Workflow

Giải thích về kịch bản hội thảo Tự thân khởi nghiệp

Tập lệnh có tên bootstrap_workshop.sh được dùng để thiết lập môi trường ban đầu cho hội thảo. Bạn có thể sử dụng tập lệnh này để thiết lập một môi trường cho bản thân hoặc nhiều môi trường cho nhiều người dùng trong trường hợp bạn tổ chức hội thảo này dưới dạng chương trình đào tạo cho nhiều người dùng.

Tập lệnh hội thảo Tự thân khởi nghiệp yêu cầu dữ liệu đầu vào như sau:

• Tên tổ chức (ví dụ như yourcompany.com) – Đây là tổ chức mà bạn tạo môi trường cho hội thảo.
• Mã thanh toán (ví dụ: 12345-12345-12345) – Mã thanh toán này được dùng để lập hoá đơn cho tất cả các tài nguyên được sử dụng trong hội thảo.
• Số hội thảo (ví dụ: 01) – Số có hai chữ số. Tính năng này dùng trong trường hợp bạn tham gia nhiều hội thảo trong một ngày và muốn theo dõi riêng từng hội thảo. Số hội thảo cũng được dùng để lấy mã dự án. Việc có mã số hội thảo riêng biệt giúp bạn dễ dàng nhận được mã dự án duy nhất mỗi lần. Ngoài số hiệu hội thảo, ngày hiện tại (có định dạng là YYMMDD) cũng được dùng cho mã dự án. Sự kết hợp giữa ngày và số hội thảo tạo ra mã dự án duy nhất.
• Bắt đầu số của người dùng (ví dụ: 1) – Số này biểu thị người dùng đầu tiên trong hội thảo. Ví dụ: Nếu muốn tạo một hội thảo cho 10 người dùng, bạn có thể có số người dùng bắt đầu là 1 và số người dùng cuối là 10.
• Mã số người dùng cuối (ví dụ: 10) – Số này biểu thị người dùng cuối cùng trong hội thảo. Ví dụ: Nếu muốn tạo một hội thảo cho 10 người dùng, bạn có thể có số người dùng bắt đầu là 1 và số người dùng cuối là 10. Nếu bạn đang thiết lập một môi trường duy nhất (ví dụ: cho chính bạn), hãy đặt số bắt đầu và số của người dùng cuối giống nhau. Thao tác này sẽ tạo một môi trường duy nhất.

Ngoài ngày và số nhà xưởng, số người dùng bắt đầu và số nhà xưởng cũng được tích hợp vào mã dự án. Mã nhận dạng người dùng (đối với người dùng đang tham gia hội thảo) được lấy từ số người dùng bắt đầu và người dùng cuối. Mã nhận dạng người dùng được giải thích trong phần có tên là User schema and permissions performing the workshop.

• Bộ chứa GCS dành cho quản trị viên (ví dụ: my-gcs-bucket-name) – Bộ chứa GCS dùng để lưu trữ thông tin liên quan đến hội thảo. Thông tin này được tập lệnh cleanup_workshop.sh sử dụng để xoá linh hoạt tất cả tài nguyên được tạo trong tập lệnh hội thảo Tự khởi động. Quản trị viên tạo hội thảo phải có quyền đọc/ghi vào bộ chứa này.

Tập lệnh hội thảo Tự khởi động sử dụng các giá trị được cung cấp ở trên và hoạt động như một tập lệnh trình bao bọc gọi tập lệnh setup-terraform-admin-project.sh. Tập lệnh setup-terraform-admin-project.sh tạo môi trường hội thảo cho một người dùng.

Cần có quyền quản trị để tự khởi động hội thảo

Có hai kiểu người dùng trong hội thảo này. ADMIN_USER có vai trò tạo và xoá tài nguyên của hội thảo này. Người thứ hai là MY_USER, người thực hiện các bước trong hội thảo. MY_USER chỉ có quyền truy cập vào các tài nguyên của riêng mình. ADMIN_USER có quyền truy cập vào tất cả thông tin thiết lập người dùng. Nếu bạn đang tạo chế độ thiết lập này cho chính mình, thì ADMIN_USER và MY_USER sẽ giống nhau. Nếu bạn là người hướng dẫn đang tạo hội thảo này cho nhiều học viên, thì ADMIN_USER và MY_USER của bạn sẽ khác nhau.

Bạn cần có các quyền ở cấp tổ chức sau đây cho ADMIN_USER:

• Chủ sở hữu – Quyền của Chủ sở hữu dự án đối với tất cả dự án trong Tổ chức.
• Quản trị thư mục – Có thể tạo và xoá các thư mục trong Tổ chức. Mỗi người dùng sẽ nhận được một thư mục chứa tất cả tài nguyên của họ trong dự án.
• Quản trị viên tổ chức
• Người tạo dự án – Có thể tạo dự án trong Tổ chức.
• Project Deleter (Trình xoá dự án) – Có thể xoá dự án trong Tổ chức.
• Quản trị viên dự án IAM – Có thể tạo quy tắc IAM trong tất cả dự án trong Tổ chức.

Ngoài những việc này, ADMIN_USER cũng phải là Quản trị viên thanh toán đối với Mã thanh toán được dùng cho hội thảo này.

Giản đồ người dùng và các quyền khi tiến hành hội thảo

Nếu dự định tạo hội thảo này cho người dùng (không phải bạn) trong tổ chức của mình, bạn phải tuân theo một lược đồ đặt tên người dùng cụ thể cho MY_USERs. Trong tập lệnh bootstrap_workshop.sh, bạn cung cấp số bắt đầu và số người dùng cuối. Các số này được dùng để tạo những tên người dùng sau:

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

Ví dụ: nếu bạn chạy tập lệnh hội thảo Tự thân khởi nghiệp với số người dùng bắt đầu là 1 và số người dùng cuối là 3, trong tổ chức của bạn có tên là yourcompany.com, môi trường hội thảo cho những người dùng sau sẽ được tạo:

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

Những tên người dùng này được chỉ định vai trò Chủ sở hữu dự án cho những dự án cụ thể mà họ tạo trong tập lệnh setup_terraform_admin_project.sh. Bạn phải tuân thủ giản đồ đặt tên người dùng này khi sử dụng tập lệnh Tự khởi động. Hãy tham khảo cách thêm nhiều người dùng cùng lúc trong G Suite.

Các công cụ cần thiết cho hội thảo

Hội thảo này dự kiến sẽ tự khai thác từ Cloud Shell. Bạn cần có các công cụ sau đây cho hội thảo này.

• gcloud (phiên bản >= 270)
• kubectl
• sed (hoạt động với sed trên Cloud Shell/Linux chứ không phải Mac OS)
• git (đảm bảo bạn cập nhật thông tin)
• sudo apt update
• sudo apt install git
• jq
• môi trường
• khủng bố

Tất cả các công cụ ngoại trừ kustomize đều đã được cài đặt theo mặc định trong Cloud Shell. Nếu bạn chưa cài đặt kustomize, hãy cài đặt bằng cách sử dụng tập lệnh bash được cung cấp trong đường liên kết ở trên và đảm bảo tệp nhị phân kustomize nằm trong PATH của bạn rồi xác nhận bằng cách chạy lệnh kustomize trong Cloud Shell.

Thiết lập hội thảo cho chính bạn (thiết lập một người dùng)

1. Mở Cloud Shell, thực hiện tất cả các thao tác bên dưới trong Cloud Shell. Hãy nhấp vào đường liên kết bên dưới.

VỎ ĐÁM Mây

2. Xác minh rằng bạn đã đăng nhập vào gcloud bằng Người dùng quản trị dự kiến.

gcloud config list
 

3. Tạo một WORKDIR và sao chép kho lưu trữ hội thảo.

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

4. Xác định Tên tổ chức, mã thanh toán, mã số hội thảo và bộ chứa GCS dành cho quản trị viên để sử dụng cho hội thảo. Xem các quyền cần thiết để thiết lập hội thảo ở các phần trên.

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. Chạy tập lệnh bootstrap_workshop.sh. Tập lệnh này có thể mất vài phút để hoàn tất.

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 
 

Xin lưu ý rằng bạn không cần xác định số bắt đầu và số người dùng cuối vì bạn đang thiết lập việc này cho chính mình.

Sau khi tập lệnh bootstrap_workshop.sh hoàn tất, một thư mục GCP sẽ được tạo cho từng người dùng trong tổ chức. Trong thư mục này, một dự án quản trị Terraform sẽ được tạo. Dự án quản trị địa hình được dùng để tạo phần còn lại của những tài nguyên cần thiết cho hội thảo này trên Google Cloud Platform (GCP). Bạn bật các API bắt buộc trong dự án quản trị terraform. Bạn sẽ dùng Cloud Build để áp dụng các gói Terraform. Bạn chỉ định các vai trò quản lý danh tính và quyền truy cập (IAM) thích hợp cho tài khoản dịch vụ Cloud Build để tài khoản đó có thể tạo tài nguyên trên GCP. Cuối cùng, bạn cần định cấu hình một phần phụ trợ từ xa trong bộ chứa Google Cloud Storage (GCS) để lưu trữ các trạng thái Teraform cho mọi tài nguyên trên GCP.

Để xem các tác vụ của Cloud Build trong dự án quản trị terraform, bạn cần có mã dự án quản trị terraform. Thông tin này được lưu trữ trong tệp vars/vars.sh trong thư mục asm của bạn. Thư mục này chỉ tồn tại nếu bạn thiết lập hội thảo cho chính mình với tư cách là quản trị viên.

6. Tìm nguồn tệp biến để đặt biến môi trường

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

Thiết lập hội thảo cho nhiều người dùng (thiết lập nhiều người dùng)

7. Mở Cloud Shell, thực hiện tất cả các thao tác bên dưới trong Cloud Shell. Hãy nhấp vào đường liên kết bên dưới.

VỎ ĐÁM Mây

8. Xác minh rằng bạn đã đăng nhập vào gcloud bằng Người dùng quản trị dự kiến.

gcloud config list
 

9. Tạo một WORKDIR và sao chép kho lưu trữ hội thảo.

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

10. Xác định Tên tổ chức, Mã thanh toán, mã số hội thảo, số người dùng bắt đầu và số người dùng cuối, cũng như bộ chứa GCS dành cho quản trị viên để sử dụng cho hội thảo. Xem các quyền cần thiết để thiết lập hội thảo ở các phần trên.

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. Chạy tập lệnh bootstrap_workshop.sh. Tập lệnh này có thể mất vài phút để hoàn tất.

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. Lấy tệp hội thảo.txt từ bộ chứa GCS dành cho quản trị viên để truy xuất mã dự án terraform.

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

4. Thiết lập và chuẩn bị phòng thí nghiệm

Những người dùng thực hiện hội thảo bắt đầu từ đây. Thực hiện tất cả các bước trong cửa sổ INCOGNITO trên Chrome hoặc Firefox.

Chọn đường dẫn đến phòng thí nghiệm

Bạn có thể tiến hành các phòng thí nghiệm trong hội thảo này theo một trong hai cách:

• "Các tập lệnh tương tác dễ dàng theo dõi nhanh" đường
• "Sao chép và dán từng hướng dẫn theo cách thủ công" đường

Phương pháp tập lệnh theo dõi nhanh cho phép bạn chạy một tập lệnh tương tác duy nhất cho mỗi phòng thí nghiệm mà sẽ hướng dẫn bạn qua phòng thí nghiệm đó bằng cách tự động chạy các lệnh cho phòng thí nghiệm đó. Các lệnh này sẽ chạy hàng loạt kèm theo nội dung giải thích ngắn gọn về từng bước và kết quả mà các lệnh đó đạt được. Sau mỗi lô, bạn sẽ được nhắc chuyển sang lô lệnh tiếp theo. Bằng cách này, bạn có thể chạy các phòng thí nghiệm theo tốc độ của mình. Các tập lệnh theo dõi nhanh không thay đổi, nghĩa là bạn có thể chạy các tập lệnh này nhiều lần mà vẫn nhận được cùng một kết quả.

Các tập lệnh theo dõi nhanh sẽ xuất hiện ở đầu mỗi phòng thí nghiệm trong một ô màu xanh lục như được hiển thị dưới đây.

KỊCH TÍNH NHANH

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

Phương thức sao chép và dán là cách truyền thống để sao chép và dán từng khối lệnh riêng lẻ kèm theo lời giải thích về lệnh. Phương thức này chỉ dùng để chạy một lần. Không có gì đảm bảo rằng việc chạy lại các lệnh trong phương thức này sẽ mang lại cho bạn kết quả tương tự.

Khi thực hiện các phòng thí nghiệm, vui lòng chọn một trong hai phương pháp.

Sau khi bạn đã chọn một phương thức và thực hiện các bước trong phương thức đó, không thực hiện các bước trong phương thức kia.

Thiết lập tập lệnh theo dõi nhanh

Sau khi hoàn tất kịch bản theo dõi nhanh, bạn cũng kết thúc quá trình thử nghiệm đó. Không thực hiện các bước trong Hướng dẫn của Phòng thí nghiệm về tính năng sao chép và dán.

Nhận thông tin người dùng

Bạn có thể tổ chức hội thảo này bằng một tài khoản người dùng tạm thời (hoặc tài khoản phòng thí nghiệm) do quản trị viên của hội thảo tạo. Tài khoản phòng thí nghiệm sở hữu tất cả dự án trong hội thảo. Quản trị viên hội thảo cung cấp thông tin đăng nhập của tài khoản phòng thí nghiệm (tên người dùng và mật khẩu) cho người dùng tham gia hội thảo. Tất cả dự án của người dùng đều có tiền tố là tên người dùng của tài khoản phòng thí nghiệm (ví dụ: tài khoản phòng thí nghiệm [e-mail]), mã dự án quản trị terraform sẽ là user001-200131-01-tf-abcde, v.v. đối với các dự án còn lại. Mỗi người dùng phải đăng nhập bằng tài khoản phòng thí nghiệm do quản trị viên hội thảo cung cấp và thực hiện hội thảo bằng tài khoản phòng thí nghiệm đó.

Kiểm tra email công ty của bạn (chính là email bạn đã dùng để đăng ký tham dự hội thảo). Chắc hẳn bạn đã nhận được email từ quản trị viên hội thảo kèm theo thông tin đăng nhập của tài khoản phòng thí nghiệm (ví dụ: tên người dùng và mật khẩu). Email có dạng như sau.

1. Mở Cloud Shell bằng cách nhấp vào đường liên kết bên dưới.

VỎ ĐÁM Mây

2. Đăng nhập bằng thông tin xác thực tài khoản phòng thí nghiệm (không đăng nhập bằng tài khoản công ty hoặc tài khoản cá nhân của bạn). Tài khoản phòng thí nghiệm có dạng userXYZ@<workshop_domain>.com.
3. Vì đây là tài khoản mới, nên bạn sẽ được nhắc chấp nhận Điều khoản dịch vụ của Google. Nhấp vào Chấp nhận.

4. Trong màn hình tiếp theo, hãy chọn hộp đánh dấu để đồng ý với Điều khoản dịch vụ của Google rồi nhấp vào Start Cloud Shell.

Bước này cung cấp một máy ảo Linux Debian nhỏ để bạn dùng để truy cập vào các tài nguyên GCP. Mỗi tài khoản sẽ nhận được một máy ảo Cloud Shell. Đăng nhập bằng các điều khoản của tài khoản phòng thí nghiệm và đăng nhập bạn bằng thông tin đăng nhập tài khoản phòng thí nghiệm. Ngoài Cloud Shell, Trình soạn thảo mã cũng được cung cấp để giúp bạn dễ dàng chỉnh sửa các tệp cấu hình (terraform, YAML, v.v.). Theo mặc định, màn hình Cloud Shell được chia thành môi trường shell Cloud Shell (ở dưới cùng) và Trình soạn thảo mã đám mây (ở trên cùng). Biểu tượng bút chì và biểu tượng dấu nhắc lệnh shell ở góc trên cùng bên phải cho phép bạn chuyển đổi giữa hai loại này (shell và trình soạn thảo mã). Bạn cũng có thể kéo thanh phân cách ở giữa (lên hoặc xuống) và thay đổi kích thước của từng cửa sổ theo cách thủ công. 5. Tạo một WORKDIR cho hội thảo này. WORKDIR là một thư mục để bạn thực hiện tất cả các phòng thí nghiệm trong hội thảo này. Chạy các lệnh sau trong Cloud Shell để tạo WORKDIR.

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

6. Xuất người dùng tài khoản phòng thí nghiệm dưới dạng một biến sẽ được dùng cho hội thảo này. Đây chính là tài khoản mà bạn dùng để đăng nhập vào Cloud Shell.

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

Lưu ý: nếu bạn là quản trị viên và tự thiết lập hội thảo cho chính mình bằng cách sử dụng "-sufa" hoặc "–setup-for-admin" cờ rồi đặt MY_USER thành email cho tài khoản GCP mà bạn dùng để tạo dự án hội thảo.

7. Phản hồi các biến WORKDIR và MY_USER để đảm bảo cả hai biến đều được thiết lập chính xác bằng cách chạy các lệnh sau.

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

8. Sao chép kho lưu trữ hội thảo.

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

5. Thiết lập cơ sở hạ tầng – Quy trình làm việc của người dùng

Mục tiêu: Xác minh cơ sở hạ tầng và việc cài đặt Istio

• Cài đặt công cụ cho hội thảo
• Kho lưu trữ bản sao của hội thảo
• Xác minh việc cài đặt Infrastructure
• Xác minh việc cài đặt k8s-repo
• Xác minh việc cài đặt Istio

KỊCH TÍNH NHANH

Nếu bạn chọn phương pháp này, hãy chạy tập lệnh sau để hoàn tất phòng thí nghiệm này.

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

Sau khi tập lệnh hoàn tất, hãy tìm nguồn bashrc để cập nhật các biến trong phiên Cloud Shell của bạn.

source ${HOME}/.bashrc

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

LƯU Ý QUAN TRỌNG: Nếu bạn đã hoàn tất kịch bản theo dõi nhanh cho phòng thí nghiệm này, thì đừng thực hiện phương pháp sao chép và dán bên dưới**.**

Nhận thông tin người dùng

Quản trị viên thiết lập hội thảo cần cung cấp thông tin về tên người dùng và mật khẩu cho người dùng. Tất cả dự án của người dùng đều sẽ có tiền tố là tên người dùng (ví dụ: [e-mail] của người dùng), mã dự án quản trị hình chữ nhật sẽ là user001-200131-01-tf-abcde và cứ tiếp tục như vậy đối với các dự án còn lại. Mỗi người dùng chỉ có quyền truy cập vào môi trường hội thảo của riêng mình.

Các công cụ cần thiết cho hội thảo

Hội thảo này dự kiến sẽ tự khai thác từ Cloud Shell. Bạn cần có các công cụ sau đây cho hội thảo này.

Tất cả các công cụ ngoại trừ kustomize và pv đều đã được cài đặt theo mặc định trong Cloud Shell. Bạn sẽ thấy hướng dẫn cài đặt cả hai công cụ ở bên dưới.

• gcloud (phiên bản >= 270)
• kubectl
• sed (hoạt động với sed trên Cloud Shell/Linux chứ không phải Mac OS)
• git (đảm bảo bạn cập nhật thông tin)
• sudo apt update
• sudo apt install git
• jq
• môi trường
• khủng bố
• pv

Truy cập dự án quản trị terraform

Sau khi tập lệnh bootstrap_workshop.sh hoàn tất, một thư mục GCP sẽ được tạo cho từng người dùng trong tổ chức. Trong thư mục này, một dự án quản trị Terraform sẽ được tạo. Dự án quản trị địa hình được dùng để tạo phần còn lại của những tài nguyên cần thiết cho hội thảo này trên Google Cloud Platform (GCP). Tập lệnh setup-terraform-admin-project.sh bật các API bắt buộc trong dự án quản trị terraform. Cloud Build được dùng để áp dụng các gói Terraform. Thông qua tập lệnh, bạn cấp cho tài khoản dịch vụ Cloud Build các vai trò quản lý danh tính và quyền truy cập (IAM) phù hợp để tài khoản đó có thể tạo tài nguyên trên GCP. Cuối cùng, một phần phụ trợ từ xa được định cấu hình trong bộ chứa Google Cloud Storage (GCS) để lưu trữ các trạng thái Teraform cho mọi tài nguyên trên GCP.

Để xem các tác vụ của Cloud Build trong dự án quản trị terraform, bạn cần có mã dự án quản trị terraform. Dữ liệu này được lưu trữ trong bộ chứa GCS dành cho quản trị viên mà được chỉ định trong tập lệnh Tự khởi động. Nếu bạn chạy tập lệnh Tự thân khởi nghiệp cho nhiều người dùng, thì tất cả mã dự án quản trị dạng Terraform đều nằm trong bộ chứa GCS.

Hội thảo này dự kiến sẽ được thực hiện trong Cloud Shell và Cloud Console. Thực hiện các bước sau trong cửa sổ INCOGNITO vì bạn sẽ đăng nhập bằng tên người dùng và mật khẩu riêng.

1. Mở Cloud Shell (nếu phần này chưa mở trong phần Thiết lập và Chuẩn bị cho phòng thí nghiệm) bằng cách nhấp vào đường liên kết ở bên dưới.

VỎ ĐÁM Mây

2. Cài đặt kustomize (nếu chưa cài đặt) trong thư mục $HOME/bin rồi thêm thư mục $HOME/bin vào $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. Cài đặt pv và chuyển sang $HOME/bin/pv.

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

4. Cập nhật lời nhắc bash của bạn.

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. Xác minh rằng bạn đã đăng nhập vào gcloud bằng tài khoản người dùng dự kiến.

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

6. Lấy mã dự án quản trị Terraform bằng cách chạy lệnh sau:

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

7. Tất cả tài nguyên liên quan đến hội thảo được lưu trữ dưới dạng biến trong tệp vars.sh lưu trữ trong bộ chứa GCS thuộc dự án quản trị terraform. Lấy tệp vars.sh cho dự án quản trị terraform của bạn.

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. Nhấp vào đường liên kết xuất hiện để mở trang Cloud Build cho dự án quản trị Terraform và xác minh rằng bản dựng đã hoàn tất thành công.

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

Nếu đây là lần đầu tiên truy cập vào Cloud Console, hãy đồng ý với Điều khoản dịch vụ của Google.

9. Giờ bạn đã xem trang Cloud Build, hãy nhấp vào đường liên kết History trong thanh điều hướng bên trái rồi nhấp vào bản dựng mới nhất để xem thông tin chi tiết về Terraform ban đầu được áp dụng. Các tài nguyên sau đây được tạo dưới dạng một phần của tập lệnh Terraform. Bạn cũng có thể tham khảo sơ đồ cấu trúc ở trên.

• 4 dự án GCP trong tổ chức. Tài khoản thanh toán bạn cung cấp được liên kết với từng dự án.
• Có một dự án là network host project cho VPC dùng chung. Không có tài nguyên nào khác được tạo trong dự án này.
• Có một dự án là ops project dùng cho cụm GKE trên mặt phẳng điều khiển Istio.
• Hai dự án đại diện cho hai nhóm phát triển khác nhau làm việc về các dịch vụ tương ứng của họ.
• Mỗi dự án ops, dev1 và dev2 sẽ tạo 2 cụm GKE.
• Một kho lưu trữ CSR có tên k8s-repo được tạo, trong đó chứa 6 thư mục dành cho các tệp kê khai của Kubernetes. Một thư mục cho mỗi cụm GKE. Kho lưu trữ này dùng để triển khai tệp kê khai Kubernetes cho các cụm theo kiểu GitOps.
• Một điều kiện kích hoạt Cloud Build được tạo ra để mỗi khi có cam kết đối với nhánh chính của k8s-repo, gói đó sẽ triển khai tệp kê khai Kubernetes cho các cụm GKE từ các thư mục tương ứng.

Tập lệnh terraform cần 40-50 phút.

10. Sau khi bản dựng hoàn tất trong terraform admin project, một bản dựng khác sẽ bắt đầu trong dự án hoạt động. Nhấp vào đường liên kết xuất hiện để mở trang Cloud Build cho ops project và kiểm tra để đảm bảo Cloud Build k8s-repo đã hoàn tất thành công.

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

Lưu ý: Bạn cần hoàn tất bản dựng này thì mới có thể xác minh phần Cài đặt Istio.

Xác minh cài đặt

11. Tạo tệp kubeconfig cho tất cả các cụm. Chạy tập lệnh sau.

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

Tập lệnh này sẽ tạo một tệp kubeconfig mới trong thư mục gke có tên là kubemesh.

12. Thay đổi biến KUBECONFIG để trỏ đến tệp kubeconfig mới.

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

13. Thêm vars.sh và KUBECONFIG vào tệp .bashrc trong Cloud Shell để tìm nguồn mỗi khi Cloud Shell được khởi động lại.

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

14. Liệt kê ngữ cảnh cụm của bạn. Bạn sẽ thấy 6 cụm.

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

Xác minh cài đặt Istio

15. Đảm bảo Istio được cài đặt trên cả hai cụm bằng cách kiểm tra để đảm bảo tất cả các nhóm đang chạy và các công việc đã hoàn tất.

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. Đảm bảo bạn đã cài đặt Istio trên cả hai cụm dev1. Chỉ nên bao gồm thành phần, trình chèn trợ giúp và Coredns trong các cụm dev1. Các thiết bị này dùng chung một bảng điều khiển Istio đang chạy trong cụm ops-1.

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

17. Đảm bảo bạn đã cài đặt Istio trên cả hai cụm dev2. Chỉ nên bao gồm thành phần, trình chèn trợ giúp và Coredns trong các cụm dev2. Các thiết bị này dùng chung một bảng điều khiển Istio đang chạy trong cụm 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

Xác minh chế độ khám phá dịch vụ cho vùng điều khiển dùng chung

18. Bạn có thể xác minh các khoá bí mật đã được triển khai (không bắt buộc).

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

Trong hội thảo này, bạn sẽ dùng một VPC dùng chung mà trong đó tất cả các cụm GKE đều được tạo. Để khám phá dịch vụ trên nhiều cụm, bạn hãy sử dụng các tệp kubeconfig (cho mỗi cụm ứng dụng) được tạo làm khoá bí mật trong các cụm hoạt động. Pilot sử dụng những bí mật này để khám phá Dịch vụ bằng cách truy vấn máy chủ API Kube của các cụm ứng dụng (được xác thực qua các bí mật ở trên). Bạn thấy rằng cả hai cụm hoạt động đều có thể xác thực cho tất cả các cụm ứng dụng bằng cách sử dụng các khoá bí mật do kubeconfig tạo. Các cụm hoạt động có thể tự động khám phá các dịch vụ bằng cách sử dụng các tệp kubeconfig làm phương thức bí mật. Để làm được như vậy, Chương trình thí điểm trong các cụm hoạt động phải có quyền truy cập vào máy chủ API Kube của tất cả các cụm khác. Nếu Chương trình thí điểm không thể truy cập vào các máy chủ API Kube, thì bạn sẽ tự thêm các dịch vụ từ xa dưới dạng ServiceEntries. Bạn có thể coi ServiceEntries là mục nhập DNS trong sổ đăng ký dịch vụ của mình. ServiceEntries xác định dịch vụ bằng tên DNS đủ điều kiện ( FQDN) và địa chỉ IP có thể truy cập. Hãy xem tài liệu về Istio Multicluster để biết thêm thông tin.

6. Giải thích về Repo cơ sở hạ tầng

Xây dựng cơ sở hạ tầng trên đám mây

Các tài nguyên của GCP cho hội thảo này được xây dựng bằng Cloud Build và kho lưu trữ CSR infrastructure. Bạn vừa chạy tập lệnh Tự khởi động (nằm tại scripts/bootstrap_workshop.sh) từ thiết bị đầu cuối cục bộ của mình. Tập lệnh Tự thân khởi nghiệp sẽ tạo một thư mục GCP, một dự án quản trị cấp lãnh thổ và các quyền IAM thích hợp cho tài khoản dịch vụ Cloud Build. Dự án quản trị Terraform được dùng để lưu trữ các trạng thái, nhật ký và các tập lệnh khác. Lớp này chứa các kho lưu trữ CSR infrastructure và k8s_repo. Các kho lưu trữ này được giải thích chi tiết trong phần tiếp theo. Không có tài nguyên hội thảo nào khác được tạo trong dự án quản trị địa hình. Tài khoản dịch vụ Cloud Build trong dự án quản trị terraform được dùng để xây dựng tài nguyên cho hội thảo.

Tệp cloudbuild.yaml nằm trong thư mục infrastructure được dùng để tạo tài nguyên GCP cho hội thảo. Thao tác này sẽ tạo một hình ảnh trình tạo tuỳ chỉnh có tất cả công cụ cần thiết để tạo tài nguyên GCP. Các công cụ này bao gồm SDK gcloud, terraform và các tiện ích khác như python, git, jq, v.v. Hình ảnh trình tạo tuỳ chỉnh chạy terraform plan và apply cho mỗi tài nguyên. Các tệp địa hình của mỗi tài nguyên được đặt trong các thư mục riêng biệt (thông tin chi tiết trong phần tiếp theo). Các tài nguyên được tạo lần lượt và theo thứ tự xây dựng của các tài nguyên đó (ví dụ: một dự án GCP sẽ được tạo trước khi các tài nguyên đó được tạo trong dự án). Vui lòng xem lại tệp cloudbuild.yaml để biết thêm chi tiết.

Cloud Build được kích hoạt bất cứ khi nào có một cam kết đối với kho lưu trữ infrastructure. Mọi thay đổi đối với cơ sở hạ tầng này đều được lưu trữ dưới dạng Cơ sở hạ tầng dưới dạng mã (IaC) và được cam kết trong kho lưu trữ. Trạng thái của hội thảo luôn được lưu trữ trong kho lưu trữ này.

Cấu trúc thư mục – nhóm, môi trường và tài nguyên

Kho lưu trữ cơ sở hạ tầng giúp thiết lập các tài nguyên về cơ sở hạ tầng GCP cho hội thảo. Nó được cấu trúc thành các thư mục và thư mục con. Các thư mục cơ sở trong kho lưu trữ đại diện cho team sở hữu những tài nguyên GCP cụ thể. Lớp thư mục tiếp theo đại diện cho environment cụ thể của nhóm (ví dụ: phát triển, giai đoạn, sản phẩm). Lớp thư mục tiếp theo trong môi trường đại diện cho resource cụ thể (ví dụ: host_project, gke_clusters, v.v.). Các tập lệnh và tệp địa hình bắt buộc tồn tại trong các thư mục tài nguyên.

4 loại nhóm sau đây sẽ được trình bày trong hội thảo này:

1. cơ sở hạ tầng – đại diện cho nhóm cơ sở hạ tầng đám mây. Họ chịu trách nhiệm tạo tài nguyên GCP cho tất cả các nhóm khác. Họ sử dụng dự án quản trị Terraform cho tài nguyên của mình. Bản thân kho lưu trữ cơ sở hạ tầng này nằm trong dự án quản trị Terraform cũng như các tệp trạng thái Terraform (được giải thích bên dưới). Các tài nguyên này được tạo bằng tập lệnh bash trong quá trình tự khởi động (xem Mô-đun 0 – Quy trình của quản trị viên để biết thông tin chi tiết).
2. network – đại diện cho nhóm mạng. Họ chịu trách nhiệm về VPC và các tài nguyên mạng. Họ sở hữu các tài nguyên sau đây của GCP.
3. host project – đại diện cho dự án lưu trữ VPC dùng chung.
4. shared VPC – đại diện cho VPC dùng chung, mạng con, dải IP phụ, tuyến và quy tắc tường lửa.
5. ops – đại diện cho nhóm vận hành/nhà phát triển. Họ sở hữu những tài nguyên sau.
6. ops project – đại diện cho một dự án của tất cả tài nguyên hoạt động.
7. gke clusters – một cụm GKE hoạt động cho mỗi khu vực. Tầng điều khiển Istio được cài đặt trong mỗi cụm GKE hoạt động.
8. k8s-repo – một kho lưu trữ CSR chứa tệp kê khai GKE cho tất cả các cụm GKE.
9. apps – đại diện cho các nhóm ứng dụng. Hội thảo này mô phỏng 2 nhóm là app1 và app2. Họ sở hữu những tài nguyên sau.
10. app projects – mỗi nhóm phát triển ứng dụng đều có nhóm dự án riêng. Việc này giúp họ kiểm soát việc thanh toán và quản lý danh tính và quyền truy cập (IAM) cho dự án cụ thể của họ.
11. gke clusters – đây là những cụm ứng dụng nơi các vùng chứa ứng dụng/Pods chạy.
12. gce instances – không bắt buộc nếu họ có ứng dụng chạy trên các phiên bản GCE. Trong hội thảo này, ứng dụng 1 có một số thực thể GCE trong đó một phần của ứng dụng sẽ chạy.

Trong hội thảo này, cùng một ứng dụng (ứng dụng cửa hàng Hipster) đại diện cho cả app1 và app2.

Nhà cung cấp, trạng thái và đầu ra – Phần phụ trợ và trạng thái dùng chung

Các nhà cung cấp google và google-beta nằm tại gcp/[environment]/gcp/provider.tf. Tệp provider.tf được liên kết tượng trưng trong mọi thư mục tài nguyên. Điều này cho phép bạn thay đổi nhà cung cấp ở cùng một nơi thay vì quản lý riêng từng nhà cung cấp cho từng tài nguyên.

Mỗi tài nguyên chứa một tệp backend.tf xác định vị trí cho tệp tfstate của tài nguyên đó. Tệp backend.tf này được tạo từ một mẫu (nằm tại templates/backend.tf_tmpl) bằng cách sử dụng một tập lệnh (nằm tại scripts/setup_terraform_admin_project), sau đó được đặt vào thư mục tài nguyên tương ứng. Các bộ chứa Google Cloud Storage (GCS) được dùng cho phần phụ trợ. Tên thư mục bộ chứa GCS khớp với tên tài nguyên. Tất cả phần phụ trợ tài nguyên đều nằm trong dự án quản trị dạng địa hình.

Các tài nguyên có giá trị phụ thuộc lẫn nhau sẽ chứa tệp output.tf. Các giá trị đầu ra bắt buộc được lưu trữ trong tệp tfstate được xác định trong phần phụ trợ cho tài nguyên cụ thể đó. Ví dụ: để tạo một cụm GKE trong một dự án, bạn cần phải biết mã dự án. Mã dự án được xuất thông qua output.tf sang tệp tfstate có thể dùng thông qua một nguồn dữ liệu terraform_remote_state trong tài nguyên cụm GKE.

Tệp shared_state là nguồn dữ liệu terraform_remote_state trỏ đến tệp tfstate của tài nguyên. Một tệp shared_state_[resource_name].tf (hoặc các tệp) tồn tại trong những thư mục tài nguyên yêu cầu dữ liệu đầu ra từ các tài nguyên khác. Ví dụ: Trong thư mục tài nguyên ops_gke có các tệp shared_state trong các tài nguyên ops_project và shared_vpc, vì bạn cần có mã dự án và thông tin chi tiết về VPC để tạo cụm GKE trong dự án hoạt động. Các tệp shared_state được tạo từ một mẫu (nằm tại templates/shared_state.tf_tmpl) bằng tập lệnh (nằm tại scripts/setup_terraform_admin_project). Tất cả tài nguyên Các tệp shared_state được đặt trong thư mục gcp/[environment]/shared_states. Các tệp shared_state bắt buộc được liên kết tượng trưng trong các thư mục tài nguyên tương ứng. Việc đặt tất cả các tệp shared_state vào một thư mục và liên kết các tệp tượng trưng đó trong các thư mục tài nguyên thích hợp sẽ giúp bạn dễ dàng quản lý tất cả các tệp trạng thái ở cùng một nơi.

Biến

Tất cả giá trị tài nguyên được lưu trữ dưới dạng biến môi trường. Những biến này được lưu trữ (dưới dạng câu lệnh xuất) trong một tệp có tên là vars.sh, nằm trong bộ chứa GCS thuộc dự án quản trị Terraform. Tệp này chứa mã tổ chức, tài khoản thanh toán, mã dự án, thông tin chi tiết về cụm GKE, v.v. Bạn có thể tải vars.sh xuống và lấy nguồn qua thiết bị đầu cuối bất kỳ để lấy giá trị cho chế độ thiết lập của mình.

Các biến Terraform được lưu trữ trong vars.sh dưới dạng TF_VAR_[variable name]. Các biến này được dùng để tạo tệp variables.tfvars trong thư mục tài nguyên tương ứng. Tệp variables.tfvars chứa tất cả biến cùng với giá trị tương ứng. Tệp variables.tfvars được tạo từ tệp mẫu trong cùng thư mục bằng cách sử dụng tập lệnh (nằm tại scripts/setup_terraform_admin_project).

Giải thích về K8s Repo

k8s_repo là một kho lưu trữ CSR (tách biệt với kho lưu trữ cơ sở hạ tầng) nằm trong dự án quản trị Terraform. Tệp này dùng để lưu trữ và áp dụng tệp kê khai GKE cho tất cả các cụm GKE. k8s_repo do cơ sở hạ tầng Cloud Build tạo (xem phần trước để biết thông tin chi tiết). Trong quá trình Cloud Build hạ tầng ban đầu, có tổng cộng 6 cụm GKE được tạo. Trong k8s_repo, có 6 thư mục được tạo. Mỗi thư mục (tên khớp với tên cụm GKE) tương ứng với một cụm GKE chứa các tệp kê khai tài nguyên tương ứng. Tương tự như cơ sở hạ tầng xây dựng, Cloud Build được dùng để áp dụng tệp kê khai Kubernetes cho tất cả các cụm GKE bằng k8s_repo. Cloud Build được kích hoạt bất cứ khi nào có cam kết đối với kho lưu trữ k8s_repo. Tương tự như cơ sở hạ tầng, tất cả tệp kê khai của Kubernetes đều được lưu trữ dưới dạng mã trong kho lưu trữ k8s_repo và trạng thái của mỗi cụm GKE luôn được lưu trữ trong thư mục tương ứng.

Trong quá trình xây dựng cơ sở hạ tầng ban đầu, k8s_repo được tạo và Istio được cài đặt trên tất cả các cụm.

Dự án, cụm và không gian tên của GKE

Các tài nguyên trong hội thảo này được chia thành nhiều dự án GCP. Các dự án phải phù hợp với cơ cấu tổ chức (hoặc nhóm) của công ty bạn. Các nhóm (trong tổ chức của bạn) chịu trách nhiệm về các dự án/sản phẩm/tài nguyên khác nhau sử dụng các dự án GCP khác nhau. Việc có các dự án riêng biệt cho phép bạn tạo các nhóm quyền IAM và quản lý thanh toán ở cấp dự án riêng biệt. Ngoài ra, hạn mức cũng được quản lý ở cấp dự án.

Năm nhóm có mặt trong hội thảo này, mỗi nhóm có một dự án riêng.

1. Nhóm cơ sở hạ tầng phụ trách xây dựng tài nguyên GCP sẽ sử dụng Terraform admin project. Họ quản lý cơ sở hạ tầng dưới dạng mã trong kho lưu trữ CSR (có tên là infrastructure) và lưu trữ mọi thông tin trạng thái Terraform liên quan đến tài nguyên được tạo trong GCP trong bộ chứa GCS. Họ kiểm soát quyền truy cập vào kho lưu trữ CSR và bộ chứa GCS của trạng thái Terraform.
2. Nhóm mạng xây dựng VPC dùng chung sẽ sử dụng host project. Dự án này chứa VPC, mạng con, tuyến và quy tắc tường lửa. Việc sở hữu VPC dùng chung cho phép họ quản lý tập trung hoạt động nối mạng cho các tài nguyên GCP. Tất cả dự án đều sử dụng VPC dùng chung này để kết nối mạng.
3. Nhóm điều hành/nền tảng chuyên xây dựng các cụm GKE và các mặt phẳng điều khiển ASM/Istio sẽ sử dụng ops project. Họ quản lý vòng đời của cụm GKE và lưới dịch vụ. Họ chịu trách nhiệm củng cố các cụm, quản lý khả năng thích ứng và quy mô của nền tảng Kubernetes. Trong hội thảo này, bạn sẽ sử dụng phương thức gitops để triển khai tài nguyên cho Kubernetes. Kho lưu trữ CSR (còn gọi là k8s_repo) tồn tại trong dự án hoạt động.
4. Cuối cùng là nhóm dev1 và dev2 (đại diện cho 2 nhóm phát triển) xây dựng ứng dụng sử dụng dev1 và dev2 projects của riêng mình. Đây là các ứng dụng và dịch vụ mà bạn cung cấp cho khách hàng của mình. Các hoạt động này được xây dựng trên nền tảng do nhóm vận hành quản lý. Các tài nguyên (Triển khai, Dịch vụ, v.v.) được đẩy lên k8s_repo và được triển khai cho các cụm phù hợp. Xin lưu ý rằng hội thảo này không tập trung vào các công cụ và phương pháp hay nhất về CI/CD. Bạn sử dụng Cloud Build để tự động hoá việc triển khai trực tiếp các tài nguyên Kubernetes cho các cụm GKE. Trong tình huống thực tế trong môi trường thực tế, bạn sẽ sử dụng một giải pháp CI/CD phù hợp để triển khai ứng dụng cho các cụm GKE.

Có hai loại cụm GKE trong hội thảo này.

1. Cụm vận hành – được nhóm vận hành sử dụng để chạy các công cụ dành cho nhà phát triển. Trong hội thảo này, họ sẽ vận hành máy bay điều khiển ASM/Istio để quản lý lưới dịch vụ.
2. Cụm ứng dụng (ứng dụng) – được các nhóm phát triển sử dụng để chạy ứng dụng. Trong hội thảo này, ứng dụng Cửa hàng thời trang Hipster sẽ được sử dụng.

Việc tách riêng công cụ hoạt động/quản trị khỏi các cụm chạy ứng dụng cho phép bạn quản lý vòng đời của từng tài nguyên một cách độc lập. Hai loại cụm này cũng tồn tại trong các dự án khác nhau liên quan đến nhóm/sản phẩm có sử dụng chúng, giúp quản lý quyền IAM cũng dễ dàng hơn.

Có tổng cộng 6 cụm GKE. 2 cụm hoạt động theo khu vực được tạo trong dự án hoạt động. Mặt phẳng điều khiển ASM/Istio được cài đặt trên cả hai cụm hoạt động. Mỗi cụm hoạt động nằm trong một khu vực khác nhau. Ngoài ra, còn có 4 cụm ứng dụng cấp vùng. Bạn có thể tạo các đối tượng này trong dự án riêng. Hội thảo này mô phỏng 2 nhóm phát triển, mỗi nhóm có các dự án riêng. Mỗi dự án chứa 2 cụm ứng dụng. Cụm ứng dụng là các cụm vùng trong các vùng khác nhau. 4 cụm ứng dụng này nằm ở 2 khu vực và 4 vùng. Bằng cách này, bạn sẽ có được cơ chế dự phòng theo khu vực và vùng.

Ứng dụng dùng trong hội thảo này (ứng dụng Hipster Shop) được triển khai trên cả 4 cụm ứng dụng. Mỗi dịch vụ vi mô nằm trong một không gian tên riêng trong mỗi cụm ứng dụng. Triển khai ứng dụng (Pods) của cửa hàng Hipster không được triển khai trên các cụm hoạt động. Tuy nhiên, không gian tên và tài nguyên Dịch vụ của tất cả dịch vụ vi mô cũng được tạo trong các cụm hoạt động. Tầng điều khiển ASM/Istio sử dụng thông tin đăng ký dịch vụ của Kubernetes để khám phá dịch vụ. Khi không có Dịch vụ (trong các cụm hoạt động), bạn sẽ phải tạo ServiceEntries theo cách thủ công cho từng dịch vụ chạy trong cụm ứng dụng.

Bạn sẽ triển khai ứng dụng vi dịch vụ gồm 10 cấp trong hội thảo này. Ứng dụng này là một ứng dụng thương mại điện tử dựa trên nền tảng web có tên là " Hipster Shop" nơi người dùng có thể duyệt qua các mặt hàng, thêm vào giỏ hàng và mua chúng.

Tệp kê khai Kubernetes và k8s_repo

Bạn dùng k8s_repo để thêm tài nguyên Kubernetes vào tất cả các cụm GKE. Bạn thực hiện việc này bằng cách sao chép các tệp kê khai của Kubernetes và xác nhận với k8s_repo. Tất cả các cam kết đối với k8s_repo sẽ kích hoạt công việc của Cloud Build, công việc này sẽ triển khai tệp kê khai Kubernetes cho cụm tương ứng. Tệp kê khai của mỗi cụm nằm trong một thư mục riêng có tên giống với tên cụm.

6 tên cụm đó là:

1. gke-asm-1-r1-prod – cụm hoạt động theo khu vực ở khu vực 1
2. gke-asm-2-r2-prod – cụm hoạt động theo khu vực ở khu vực 2
3. gke-1-apps-r1a-prod – cụm ứng dụng ở khu vực 1 vùng a
4. gke-2-apps-r1b-prod – cụm ứng dụng ở khu vực 1 vùng b
5. gke-3-apps-r2a-prod – cụm ứng dụng ở khu vực 2 vùng a
6. gke-4-apps-r2b-prod – cụm ứng dụng ở khu vực 2 vùng b

k8s_repo có các thư mục tương ứng với những cụm này. Mọi tệp kê khai có trong các thư mục này sẽ được áp dụng cho cụm GKE tương ứng. Tệp kê khai cho từng cụm được đặt trong thư mục con (trong thư mục chính của cụm) để dễ quản lý. Trong hội thảo này, bạn sẽ sử dụng Kustomize để theo dõi các tài nguyên được triển khai. Vui lòng tham khảo tài liệu chính thức của Kustomize để biết thêm chi tiết.

7. Triển khai ứng dụng mẫu

Mục tiêu: Triển khai ứng dụng cửa hàng Hipster trên cụm ứng dụng

• Sao chép k8s-repo
• Sao chép tệp kê khai cửa hàng Hipster vào tất cả cụm ứng dụng
• Tạo dịch vụ cho ứng dụng cửa hàng Hipster trong các cụm hoạt động
• Thiết lập loadgenerators trong các cụm hoạt động để kiểm thử khả năng kết nối toàn cầu
• Xác minh kết nối an toàn với ứng dụng cửa hàng Hipster

KỊCH TÍNH NHANH

Nếu bạn chọn phương pháp này, hãy chạy tập lệnh sau để hoàn tất phòng thí nghiệm này.

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

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Nếu bạn đã hoàn tất kịch bản theo dõi nhanh cho phòng thí nghiệm này, đừng thực hiện phương pháp sao chép và dán bên dưới**.**

Sao chép kho lưu trữ nguồn dự án hoạt động

Là một phần trong bản dựng cơ sở hạ tầng Terraform ban đầu, k8s-repo đã được tạo trong dự án hoạt động.

1. Tạo thư mục trống cho kho lưu trữ git:

mkdir $WORKDIR/k8s-repo
 

2. Khởi tạo git repo, thêm điều khiển từ xa và lấy bản chính từ kho lưu trữ từ xa:

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. Đặt cấu hình git cục bộ trên máy.

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

Sao chép tệp kê khai, xác nhận và đẩy

4. Sao chép không gian tên và dịch vụ của Hipster Shop vào kho lưu trữ nguồn cho tất cả các cụm.

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. Sao chép thư mục ứng dụng kustomization.yaml vào tất cả các cụm.

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. Sao chép Hipster Shop Deployments, RBAC và PodSecurityPolicy vào kho lưu trữ nguồn cho các cụm ứng dụng.

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. Xoá hoạt động triển khai giỏ hàng, rbac và podsecuritypolicy khỏi tất cả trừ một cụm nhà phát triển. Hipstershop không được xây dựng để triển khai trên nhiều cụm. Vì vậy, để tránh kết quả không nhất quán, chúng tôi chỉ sử dụng một dịch vụ giỏ hàng.

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. Chỉ thêm tính năng triển khai giỏ hàng, rbac và podsecuritypolicy vào kustomization.yaml trong cụm nhà phát triển đầu tiên.

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. Xoá podsecuritypolicies, triển khai và thư mục rbac khỏi cụm hoạt động 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. Thay thế PROJECT_ID trong tệp kê khai 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. Sao chép tệp kê khai IngressGateway và VirtualService vào kho lưu trữ nguồn cho các cụm hoạt động.

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. Sao chép tài nguyên Trình kết nối cấu hình vào một trong các cụm thuộc mỗi dự án.

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. Thay thế PROJECT_ID trong tệp kê khai Trình kết nối Cấu hình.

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. Sao chép tệp kê khai loadgenerator (Deployment, PodSecurityPolicy và RBAC) vào các cụm hoạt động. Ứng dụng Hipster Shop được hiển thị bằng Trình cân bằng tải của Google Cloud (GCLB) toàn cầu. GCLB nhận lưu lượng truy cập từ ứng dụng khách (được gửi đến frontend) và gửi lưu lượng đó đến thực thể gần nhất của Dịch vụ. Việc đặt loadgenerator vào cả hai cụm hoạt động sẽ đảm bảo gửi lưu lượng truy cập tới cả hai cổng vào Istio đang chạy trong các cụm hoạt động. Tính năng cân bằng tải được giải thích chi tiết trong phần sau.

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. Thay thế mã dự án hoạt động trong tệp kê khai loadgenerator của cả hai cụm hoạt động.

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. Thêm tài nguyên loadgenerator vào kustomization.yaml cho cả hai cụm hoạt động.

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. Cam kết sử dụng 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. Xem trạng thái của dự án Hoạt động trên Cloud Build trong thẻ đã mở trước đó hoặc bằng cách nhấp vào đường liên kết sau:

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

Xác minh quá trình triển khai ứng dụng

19. Xác minh rằng các nhóm trong tất cả không gian tên của ứng dụng (ngoại trừ giỏ hàng) đang ở trạng thái Đang chạy trong tất cả các cụm dành cho nhà phát triển.

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. Xác minh rằng các nhóm trong không gian tên giỏ hàng chỉ ở trạng thái Đang chạy trong cụm nhà phát triển đầu tiên.

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

Truy cập vào ứng dụng Hipster Shop

Cân bằng tải chung

Bạn hiện đã triển khai ứng dụng Hipster Shop cho cả 4 cụm ứng dụng. Các cụm này nằm trong 2 khu vực và 4 vùng. Khách hàng có thể truy cập vào ứng dụng cửa hàng Hipster bằng cách truy cập vào dịch vụ frontend. Dịch vụ frontend chạy trên cả 4 cụm ứng dụng. Trình cân bằng tải của Google Cloud ( GCLB) được dùng để nhận lưu lượng truy cập từ máy khách đến cả 4 thực thể của dịch vụ frontend.

Cổng vào Istio chỉ chạy trong các cụm hoạt động và đóng vai trò là trình cân bằng tải theo khu vực cho 2 cụm ứng dụng theo vùng trong khu vực. GCLB sử dụng 2 cổng vào Istio (chạy trong 2 cụm hoạt động) làm máy chủ phụ trợ cho dịch vụ giao diện người dùng chung. Cổng vào Istio nhận lưu lượng truy cập từ máy khách từ GCLB, sau đó gửi lưu lượng truy cập từ máy khách trở đi đến các Nhóm giao diện người dùng đang chạy trong cụm ứng dụng.

Ngoài ra, bạn có thể đặt trực tiếp cổng vào Istio trên các cụm ứng dụng và GCLB có thể sử dụng các cổng đó làm phần phụ trợ.

Bộ điều khiển Autoneg của GKE

Dịch vụ Kubernetes cổng vào Istio tự đăng ký làm phần phụ trợ cho GCLB bằng cách sử dụng Nhóm thiết bị đầu cuối mạng (NEG). NEG cho phép cân bằng tải trên vùng chứa bằng cách sử dụng GCLB. Các NEG được tạo thông qua một chú thích đặc biệt trên Dịch vụ Kubernetes, vì vậy, NEG có thể tự đăng ký với Bộ điều khiển NEG. Autoneg (Autoneg) là một tay điều khiển đặc biệt của GKE, có chức năng tự động hoá việc tạo NEG, cũng như chỉ định NEG dưới dạng phần phụ trợ cho GCLB bằng Chú thích dịch vụ. Các mặt phẳng kiểm soát Istio, bao gồm cả các cổng vào Istio, được triển khai trong quá trình xây dựng cơ sở hạ tầng ban đầu Terraform Cloud Build. Cấu hình GCLB và tự động hoàn thành được thực hiện trong quá trình xây dựng Cloud Build cho cơ sở hạ tầng Terraform ban đầu.

Bảo mật đầu vào bằng Cloud Endpoints và các chứng chỉ được quản lý

Các chứng chỉ do GCP quản lý được dùng để bảo mật lưu lượng truy cập ứng dụng vào dịch vụ GCLB frontend. GCLB sử dụng các chứng chỉ được quản lý cho dịch vụ frontend toàn cầu và chứng chỉ bị chấm dứt tại GCLB. Trong hội thảo này, bạn sẽ sử dụng Cloud Endpoints làm miền của chứng chỉ được quản lý. Ngoài ra, bạn có thể sử dụng miền và tên DNS cho frontend để tạo các chứng chỉ do GCP quản lý.

21. Để truy cập cửa hàng Hipster, hãy nhấp vào đầu ra đường liên kết của lệnh sau.

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

22. Bạn có thể kiểm tra xem chứng chỉ có hợp lệ hay không bằng cách nhấp vào biểu tượng khoá trong thanh URL của thẻ Chrome.

Xác minh cân bằng tải chung

Trong quá trình triển khai ứng dụng, các trình tạo tải đã được triển khai trong cả hai cụm hoạt động tạo lưu lượng truy cập thử nghiệm đến đường liên kết Cloud Endpoints Shop GCLB Hipster. Xác minh rằng GCLB đang nhận lưu lượng truy cập và đang gửi đến cả hai cổng vào của Istio.

23. Tải GCLB > Đường liên kết theo dõi dự án hoạt động nơi tạo GCLB của cửa hàng Hipster.

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

24. Thay đổi từ Tất cả phần phụ trợ thành istio-ingressgateway trong trình đơn thả xuống Phần phụ trợ như minh hoạ dưới đây.

25. Lưu ý rằng lưu lượng truy cập sẽ đi đến cả istio-ingressgateways.

Có 3 NEG được tạo trên mỗi istio-ingressgateway. Vì các cụm hoạt động là các cụm khu vực, nên một NEG được tạo cho mỗi vùng trong khu vực. Tuy nhiên, Nhóm istio-ingressgateway chạy trong một vùng duy nhất cho mỗi khu vực. Lưu lượng truy cập được hiển thị đến Nhóm istio-ingressgateway.

Trình tạo tải đang chạy trong cả hai cụm hoạt động mô phỏng lưu lượng truy cập của ứng dụng khách từ 2 khu vực chứa chúng. Tải tạo ra trong khu vực cụm hoạt động 1 đang được gửi tới istio-ingressgateway ở khu vực 2. Tương tự, tải tạo ra trong khu vực cụm hoạt động 2 đang được gửi đến istio-ingressgateway ở khu vực 2.

8. Khả năng quan sát bằng Stackdriver

Mục tiêu: Kết nối dữ liệu đo từ xa của Istio với Stackdriver và xác thực.

• Cài đặt tài nguyên istio-telemetry
• Tạo/cập nhật trang tổng quan của Dịch vụ Istio
• Xem nhật ký vùng chứa
• Xem hoạt động theo dõi phân tán trong Stackdriver

KỊCH TÍNH NHANH

Nếu bạn chọn phương pháp này, hãy chạy tập lệnh sau để hoàn tất phòng thí nghiệm này.

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

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Nếu bạn đã hoàn tất kịch bản theo dõi nhanh cho phòng thí nghiệm này, đừng thực hiện phương pháp sao chép và dán bên dưới**.**

Một trong những tính năng chính của Istio là khả năng quan sát được tích hợp sẵn ("o11y"). Điều này có nghĩa là ngay cả với các vùng chứa hộp đen, không được đo lường, người vận hành vẫn có thể quan sát lưu lượng ra vào các vùng chứa này, cung cấp dịch vụ cho khách hàng. Kết quả quan sát này có dạng của một vài phương pháp: chỉ số, nhật ký và dấu vết.

Chúng tôi cũng sẽ sử dụng hệ thống tạo tải tích hợp sẵn trong Hipster Shop. Khả năng quan sát không hoạt động tốt trong hệ thống tĩnh không có lưu lượng truy cập, vì vậy tính năng tạo tải giúp chúng ta thấy được cách hoạt động của tính năng này. Tải này đang chạy, giờ chúng ta chỉ có thể xem nó.

1. Cài đặt istio vào tệp cấu hình 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. Hãy cam kết sử dụng kho lưu trữ k8s.

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

3. Xem trạng thái của dự án Hoạt động trên Cloud Build trong thẻ đã mở trước đó hoặc bằng cách nhấp vào đường liên kết sau:

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

4. Xác minh Istio → Tích hợp Stackdriver Tải CRD Trình xử lý Stackdriver.

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

Kết quả sẽ hiển thị một trình xử lý có tên là stackdriver:

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

5. Xác minh rằng quá trình xuất chỉ số Istio sang Stackdriver đang hoạt động. Nhấp vào kết quả liên kết của lệnh sau:

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

Bạn sẽ được nhắc tạo một không gian làm việc mới, được đặt tên theo dự án Vận hành. Bạn chỉ cần chọn OK. Nếu nó nhắc bạn về giao diện người dùng mới, chỉ cần đóng hộp thoại.

Trong Trình khám phá chỉ số, trong mục "Tìm loại tài nguyên và chỉ số" loại "istio" thấy có các tùy chọn như "Số lượng yêu cầu máy chủ" trên "Kubernetes Container" loại tài nguyên. Điều này cho chúng ta thấy rằng các chỉ số đang chuyển từ lưới vào Stackdriver.

(Bạn sẽ phải Nhóm theo nhãn destination_service_name nếu muốn xem các dòng bên dưới.)

Trình bày các chỉ số trực quan bằng Trang tổng quan:

Giờ đây, khi các chỉ số nằm trong hệ thống APM của Stackdriver, chúng tôi muốn có một cách trực quan hoá chúng. Trong phần này, chúng ta sẽ cài đặt một trang tổng quan được tạo sẵn cho chúng ta thấy 3 trong 4 tính năng " Tín hiệu vàng" của các chỉ số: Lưu lượng truy cập (Số yêu cầu mỗi giây), Độ trễ (trong trường hợp này là phân vị thứ 99 và 50) và Lỗi (chúng tôi sẽ loại trừ Độ bão hoà trong ví dụ này).

Proxy Envoy của Istio cung cấp cho chúng ta một vài chỉ số, nhưng bạn nên bắt đầu với những chỉ số này. (danh sách đầy đủ được trình bày tại đây). Xin lưu ý rằng mỗi chỉ số có một tập hợp các nhãn có thể dùng để lọc, tổng hợp, chẳng hạn như: destination_service, source_workload_workspace, response_code, istio_tcp_received_bytes_total, v.v.).

6. Bây giờ, hãy thêm trang tổng quan về các chỉ số soạn trước. Chúng ta sẽ trực tiếp sử dụng API trang tổng quan. Đây là việc mà thường bạn sẽ không thực hiện khi tạo lệnh gọi API theo cách thủ công, đây là một phần của hệ thống tự động hoặc bạn sẽ tạo trang tổng quan theo cách thủ công trong giao diện người dùng web. Việc này sẽ giúp chúng ta nhanh chóng bắt đầu:

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. Hãy chuyển đến đường liên kết đầu ra ở bên dưới để xem "Trang tổng quan về dịch vụ" mới được thêm vào.

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

Chúng ta có thể chỉnh sửa trang tổng quan tại chỗ bằng cách sử dụng trải nghiệm người dùng. Tuy nhiên, trong trường hợp này, chúng ta sẽ nhanh chóng thêm một biểu đồ mới bằng API. Để làm được việc đó, bạn nên kéo phiên bản mới nhất của trang tổng quan xuống, áp dụng các nội dung chỉnh sửa, sau đó đẩy phiên bản đó lên lại bằng phương pháp PATCH HTTP.

8. Bạn có thể xem một trang tổng quan hiện có bằng cách truy vấn API giám sát. Lấy trang tổng quan hiện có vừa được thêm:

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. Thêm biểu đồ mới: (độ trễ thứ 50 %): [ Tài liệu tham khảo API] Bây giờ, chúng ta có thể thêm tiện ích biểu đồ mới vào trang tổng quan dưới dạng mã. Thay đổi này có thể được các ứng dụng ngang hàng xem xét và kiểm tra trong phần kiểm soát phiên bản. Đây là một tiện ích mà bạn cần thêm để hiển thị độ trễ 50% (độ trễ trung bình).

Thử chỉnh sửa trang tổng quan bạn vừa có bằng cách thêm một đoạn mới:

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. Cập nhật trang tổng quan về các dịch vụ hiện có:

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. Xem trang tổng quan mới bằng cách chuyển đến đường liên kết đầu ra sau:

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

12. Thực hiện một số phân tích nhật ký đơn giản.

Istio cung cấp một bộ nhật ký có cấu trúc cho tất cả lưu lượng truy cập mạng trong lưới và tải chúng lên Stackdriver Logging để cho phép phân tích trên nhiều cụm bằng một công cụ mạnh mẽ. Nhật ký được chú thích bằng siêu dữ liệu cấp dịch vụ, chẳng hạn như cụm, vùng chứa, ứng dụng, connection_id, v.v.

Một mục nhập nhật ký mẫu (trong trường hợp này là nhật ký truy cập của proxy Envoy) có thể có dạng như sau (đã cắt bớt):

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

Xem nhật ký của bạn tại đây:

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

Bạn có thể xem nhật ký mặt phẳng điều khiển của Istio bằng cách chọn Resource (Tài nguyên) > Vùng chứa Kubernetes và tìm kiếm về " thí điểm" –

Ở đây, chúng ta có thể thấy Istio Control Plane đẩy cấu hình proxy tới các proxy trợ giúp cho từng dịch vụ ứng dụng mẫu. "CDS" "LDS" và "RDS" đại diện cho các API Envoy khác nhau ( xem thêm thông tin).

Ngoài nhật ký của Istio, bạn cũng có thể tìm thấy cả nhật ký vùng chứa cũng như nhật ký của cơ sở hạ tầng hoặc các dịch vụ GCP khác trên cùng một giao diện. Sau đây là một số truy vấn mẫu về nhật ký dành cho GKE. Trình xem nhật ký cũng cho phép bạn tạo các chỉ số từ nhật ký (ví dụ: "đếm mọi lỗi khớp với một chuỗi nào đó") có thể được dùng trên trang tổng quan hoặc dưới dạng một phần của cảnh báo. Bạn cũng có thể truyền nhật ký đến các công cụ phân tích khác như BigQuery.

Một số bộ lọc mẫu cho cửa hàng hipster:

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

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

13. Xem dấu vết được phân phối.

Hiện tại, bạn đang làm việc với một hệ thống được phân phối, nên việc gỡ lỗi cần một công cụ mới: Theo dõi phân phối. Công cụ này cho phép bạn khám phá số liệu thống kê về cách các dịch vụ của bạn đang tương tác (chẳng hạn như tìm các sự kiện chậm ngoại lệ trong hình bên dưới), cũng như đi sâu vào các dấu vết mẫu thô để điều tra chi tiết về những gì đang thực sự xảy ra.

Chế độ xem theo dòng thời gian cho thấy tất cả các yêu cầu theo thời gian (được lập biểu đồ bằng độ trễ hoặc thời gian giữa các yêu cầu ban đầu) thông qua ngăn xếp Hipster để phản hồi người dùng cuối. Dấu chấm càng cao thì trải nghiệm của người dùng càng chậm (và kém hài lòng hơn).

Bạn có thể nhấp vào một dấu chấm để tìm Chế độ xem thác nước chi tiết của yêu cầu cụ thể đó. Khả năng tìm thông tin thô của một yêu cầu cụ thể (không chỉ là số liệu thống kê tổng hợp) là rất quan trọng để nắm được mức độ tương tác giữa các dịch vụ, đặc biệt là khi tìm được những hoạt động tương tác hiếm gặp nhưng không tốt giữa các dịch vụ.

Chế độ xem thác nước quen thuộc với bất cứ ai đã sử dụng trình gỡ lỗi, nhưng trong trường hợp này, thay vì hiển thị thời gian dành cho các quy trình khác nhau của một ứng dụng, điều này cho thấy thời gian dành cho việc truyền tải lưới của chúng ta, giữa các dịch vụ, chạy trong các vùng chứa riêng biệt.

Bạn có thể tìm thấy Dấu vết của mình tại đây:

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

Ảnh chụp màn hình ví dụ về công cụ này:

9. Xác thực TLS tương hỗ

Mục tiêu: Kết nối bảo mật giữa các dịch vụ vi mô (AuthN).

• Bật mTLS trên toàn lưới
• Xác minh mTLS bằng cách kiểm tra nhật ký

KỊCH TÍNH NHANH

Nếu bạn chọn phương pháp này, hãy chạy tập lệnh sau để hoàn tất phòng thí nghiệm này.

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

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Nếu bạn đã hoàn tất kịch bản theo dõi nhanh cho phòng thí nghiệm này, đừng thực hiện phương pháp sao chép và dán bên dưới**.**

Giờ đây, khi các ứng dụng của chúng ta đã được cài đặt và thiết lập Khả năng quan sát, chúng ta có thể bắt đầu bảo mật các kết nối giữa các dịch vụ và đảm bảo tính năng này luôn hoạt động.

Ví dụ: chúng ta có thể thấy trên trang tổng quan của Kiali rằng các dịch vụ của chúng tôi hiện không sử dụng MTLS (không có biểu tượng "khoá"). Tuy nhiên, giao thông vẫn lưu thông và hệ thống vẫn đang hoạt động bình thường. Trang tổng quan Chỉ số vàng của StackDriver giúp chúng tôi yên tâm rằng mọi thứ đều đang hoạt động bình thường.

1. Kiểm tra MeshPolicy trong các cụm hoạt động. Lưu ý: mTLS là PERMISSIVE cho phép cả lưu lượng truy cập được mã hoá và không phải 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 được định cấu hình trên tất cả các cụm bằng cách sử dụng toán tử Istio. Toán tử này sử dụng tài nguyên tuỳ chỉnh (CR) IstioControlPlane. Chúng ta sẽ định cấu hình mTLS trong tất cả các cụm bằng cách cập nhật IstioControlPlane CR và cập nhật k8s-repo. Đặt chung > mTLS > enabled: true trong IstioControlPlane CR, dẫn đến hai thay đổi sau đây đối với mặt phẳng điều khiển Istio:

• MeshPolicy được đặt để bật lưới mTLS cho tất cả Dịch vụ chạy trong tất cả các cụm.
• DestinationRule được tạo để cho phép lưu lượng ISTIO_MUTUAL giữa các Dịch vụ chạy trong tất cả các cụm.

2. Chúng tôi sẽ áp dụng một bản vá kustomize cho istioControlPlane CR để bật tính năng cho cụm mTLS trên toàn bộ. Sao chép bản vá vào thư mục liên quan cho tất cả các cụm rồi thêm bản vá tuỳ chỉnh.

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. Hãy cam kết sử dụng kho lưu trữ k8s.

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

4. Xem trạng thái của dự án Hoạt động trên Cloud Build trong thẻ đã mở trước đó hoặc bằng cách nhấp vào đường liên kết sau:

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

 

Xác minh mTLS

5. Kiểm tra MeshPolicy một lần nữa trong các cụm hoạt động. Xin lưu ý rằng mTLS không còn là PERMISSIVE và sẽ chỉ cho phép lưu lượng truy cập 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
 

Kết quả (không sao chép):

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

6. Mô tả DestinationRule do trình điều khiển toán tử Istio tạo.

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'

Kết quả (không sao chép):

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

Chúng ta cũng có thể thấy quá trình di chuyển từ HTTP sang HTTPS trong nhật ký.

Chúng ta có thể hiển thị trường cụ thể này từ nhật ký trong giao diện người dùng bằng cách nhấp vào một mục nhập nhật ký, sau đó nhấp vào giá trị của trường mà bạn muốn hiển thị. Trong trường hợp này, nhấp vào "http" bên cạnh "giao thức:

Điều này giúp bạn trực quan hoá quá trình chuyển đổi một cách hiệu quả.:

10. Triển khai Canary

Mục tiêu: Phát hành một phiên bản mới của Dịch vụ giao diện người dùng.

• Triển khai dịch vụ frontend-v2 (phiên bản phát hành công khai tiếp theo) ở một khu vực
• Sử dụng DestinationRules và VirtualServices để chậm rãi lái xe đến frontend-v2
• Xác minh quy trình triển khai GitOps bằng cách kiểm tra loạt cam kết đối với k8s-repo

KỊCH TÍNH NHANH

Nếu bạn chọn phương pháp này, hãy chạy tập lệnh sau để hoàn tất phòng thí nghiệm này.

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

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Nếu bạn đã hoàn tất kịch bản theo dõi nhanh cho phòng thí nghiệm này, đừng thực hiện phương pháp sao chép và dán bên dưới**.**

Triển khai Canary là quá trình triển khai dần một dịch vụ mới. Khi triển khai canary, bạn gửi một mức tăng lưu lượng truy cập tới phiên bản mới, trong khi vẫn gửi tỷ lệ phần trăm còn lại cho phiên bản hiện tại. Một mẫu phổ biến là thực hiện phân tích canary ở mỗi giai đoạn phân chia lưu lượng truy cập và so sánh các "tín hiệu vàng" của phiên bản mới (độ trễ, tỷ lệ lỗi, độ bão hoà) so với đường cơ sở. Việc này giúp ngăn chặn tình trạng ngừng dịch vụ và đảm bảo tính ổn định của "phiên bản 2" mới ở mọi giai đoạn phân tách lưu lượng truy cập.

Trong phần này, bạn sẽ tìm hiểu cách sử dụng các chính sách lưu lượng truy cập của Cloud Build và Istio để tạo quy trình triển khai canary cơ bản cho phiên bản mới của dịch vụ giao diện người dùng.

Trước tiên, chúng ta sẽ chạy quy trình Canary trong khu vực DEV1 (us-west1) và triển khai giao diện người dùng phiên bản 2 trên cả hai cụm trong khu vực đó. Thứ hai, chúng tôi sẽ chạy quy trình Canary trong khu vực DEV2 (us-central) và triển khai phiên bản 2 trên cả hai cụm trong khu vực đó. Việc chạy quy trình trên các khu vực theo thứ tự so với song song trên tất cả các khu vực giúp tránh tình trạng ngừng dịch vụ trên toàn cầu do cấu hình không hợp lệ hoặc do các lỗi trong chính ứng dụng v2.

Lưu ý: chúng tôi sẽ kích hoạt quy trình Canary theo cách thủ công ở cả hai khu vực. Tuy nhiên, trong quá trình sản xuất, bạn sẽ sử dụng trình kích hoạt tự động, chẳng hạn như dựa trên thẻ hình ảnh Docker mới được đẩy vào sổ đăng ký.

1. Trong Cloud Shell, hãy xác định một số biến môi trường để đơn giản hoá việc chạy các lệnh còn lại.

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

2. Chạy tập lệnh repo_setup.sh để sao chép các tệp kê khai cơ sở vào k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Các tệp kê khai sau đây được sao chép:

• Triển khai giao diện người dùng phiên bản 2
• bản vá giao diện người dùng-v1 (để bao gồm nhãn "v1" và hình ảnh có điểm cuối "/phiên bản")
• respy, một nhóm nhỏ sẽ in phân phối phản hồi HTTP và giúp chúng tôi trực quan hoá việc triển khai canary theo thời gian thực.
• giao diện người dùng Istio DestinationRule – chia Dịch vụ Kubernetes thành hai tập con là v1 và v2, dựa trên "phiên bản" nhãn triển khai
• giao diện người dùng Istio VirtualService – định tuyến 100% lưu lượng truy cập đến giao diện người dùng phiên bản 1. Thao tác này sẽ ghi đè hành vi vòng tròn mặc định của Dịch vụ Kubernetes, tức là sẽ gửi ngay lập tức 50% tất cả lưu lượng truy cập theo khu vực của Dev1 đến giao diện người dùng v2.

3. Xác nhận các thay đổi đối với k8s_repo:

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

4. Xem trạng thái của dự án Hoạt động trên Cloud Build trong thẻ đã mở trước đó hoặc bằng cách nhấp vào đường liên kết sau:

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

5. Chuyển đến Cloud Build trong bảng điều khiển cho dự án OPS1. Chờ quy trình Cloud Build hoàn tất, sau đó tải các nhóm trong không gian tên giao diện người dùng trong cả hai cụm DEV1. Bạn sẽ thấy những thông tin sau:

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

Lưu ý: Hãy nhấn tổ hợp phím Ctrl-C để thoát khỏi lệnh trên đồng hồ

Chúng ta sẽ dùng tmux để chia cửa sổ Cloudshell thành 2 ngăn:

• Ngăn dưới cùng sẽ chạy lệnh watch để quan sát quá trình phân phối phản hồi HTTP cho dịch vụ giao diện người dùng.
• Ngăn trên cùng sẽ chạy tập lệnh quy trình canary thực tế.

6. Chạy lệnh để tách cửa sổ Cloud shell và thực thi lệnh watch trong ngăn dưới cùng.

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"
 

Đầu ra (không sao chép)

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

Chúng ta có thể thấy rằng tất cả lưu lượng truy cập sẽ chuyển đến phiên bản triển khai giao diện người dùng v1, được xác định trong VirtualService mới.

7. Thực thi quy trình canary trên khu vực Dev1. Chúng tôi cung cấp một tập lệnh cập nhật tỷ lệ phần trăm lưu lượng truy cập giao diện người dùng-v2 trong VirtualService (cập nhật trọng số lên 20%, 50%, 80%, rồi 100%). Trong quá trình cập nhật, tập lệnh sẽ chờ quy trình Cloud Build hoàn tất. Chạy tập lệnh triển khai canary cho khu vực Dev1. Lưu ý - bạn cần khoảng 10 phút để hoàn tất tập lệnh này.

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

Bạn có thể thấy chế độ chia tách lưu lượng truy cập theo thời gian thực trong cửa sổ dưới cùng nơi bạn đang chạy lệnh respy. Ví dụ: ở mốc 20% :

Đầu ra (không sao chép)

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

8. Sau khi quá trình phát hành Dev2 hoàn tất cho giao diện người dùng-v2, bạn sẽ thấy thông báo thành công ở cuối tập lệnh:

    Output (do not copy) 
   

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

9. Và tất cả lưu lượng truy cập giao diện người dùng từ nhóm Dev2 sẽ chuyển đến giao diện người dùng-v2:

    Output (do not copy) 
   

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

10. Đóng ngăn phân tách.

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

11. Chuyển đến Cloud Source Repos tại đường liên kết đã tạo.

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

Bạn sẽ thấy một cam kết riêng cho từng tỷ lệ phần trăm lưu lượng truy cập, trong đó cam kết gần đây nhất ở đầu danh sách:

Bây giờ, bạn sẽ lặp lại cùng một quy trình cho khu vực Dev2. Lưu ý rằng khu vực Dev2 vẫn "bị khoá" trên phiên bản 1. Điều này là do trong tập lệnh repo_setup cơ sở, chúng tôi đã đẩy một VirtualService để gửi rõ ràng tất cả lưu lượng truy cập đến phiên bản 1. Bằng cách này, chúng tôi có thể triển khai canary trong khu vực trên Dev1 một cách an toàn và đảm bảo mã này chạy thành công trước khi ra mắt phiên bản mới trên toàn cầu.

12. Chạy lệnh để tách cửa sổ Cloud shell và thực thi lệnh watch trong ngăn dưới cùng.

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"
 

Đầu ra (không sao chép)

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

Chúng ta có thể thấy rằng tất cả lưu lượng truy cập sẽ chuyển đến phiên bản triển khai giao diện người dùng v1, được xác định trong VirtualService mới.

13. Thực thi quy trình canary trên khu vực Dev2. Chúng tôi cung cấp một tập lệnh cập nhật tỷ lệ phần trăm lưu lượng truy cập giao diện người dùng-v2 trong VirtualService (cập nhật trọng số lên 20%, 50%, 80%, rồi 100%). Trong quá trình cập nhật, tập lệnh sẽ chờ quy trình Cloud Build hoàn tất. Chạy tập lệnh triển khai canary cho khu vực Dev1. Lưu ý - bạn cần khoảng 10 phút để hoàn tất tập lệnh này.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh
 

Đầu ra (không sao chép)

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

14. Từ nhóm Respy trong Dev2, lưu lượng truy cập theo dõi từ nhóm Dev2 di chuyển dần từ giao diện người dùng v1 sang v2. Sau khi tập lệnh hoàn tất, bạn sẽ thấy:

Đầu ra (không sao chép)

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

15. Đóng ngăn phân tách.

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

Phần này giới thiệu cách sử dụng Istio để triển khai canary theo khu vực. Trong phiên bản chính thức, thay vì tập lệnh thủ công, bạn có thể tự động kích hoạt tập lệnh canary này dưới dạng một quy trình Cloud Build, bằng cách sử dụng một điều kiện kích hoạt như hình ảnh mới được gắn thẻ được đẩy vào sổ đăng ký vùng chứa. Bạn cũng nên thêm dữ liệu phân tích canary ở giữa mỗi bước, phân tích độ trễ và tỷ lệ lỗi của phiên bản 2 dựa trên ngưỡng an toàn đã xác định trước, trước khi gửi thêm lưu lượng truy cập.

11. Chính sách uỷ quyền

Mục tiêu: Thiết lập RBAC giữa các dịch vụ vi mô (AuthZ).

• Tạo AuthorizationPolicy để từ chối quyền truy cập vào một dịch vụ vi mô
• Tạo AuthorizationPolicy để CHO PHÉP quyền truy cập cụ thể vào một dịch vụ vi mô

KỊCH TÍNH NHANH

Nếu bạn chọn phương pháp này, hãy chạy tập lệnh sau để hoàn tất phòng thí nghiệm này.

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

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Nếu bạn đã hoàn tất kịch bản theo dõi nhanh cho phòng thí nghiệm này, đừng thực hiện phương pháp sao chép và dán bên dưới**.**

Không giống như một ứng dụng nguyên khối có thể chạy ở cùng một nơi, các ứng dụng vi dịch vụ được phân phối trên toàn cầu thực hiện lệnh gọi xuyên qua các ranh giới mạng. Điều này đồng nghĩa với việc ứng dụng của bạn sẽ có nhiều điểm xâm nhập hơn và là cơ hội cho các cuộc tấn công độc hại. Ngoài ra, vì các nhóm Kubernetes có IP tạm thời, nên các quy tắc tường lửa truyền thống dựa trên IP không còn đủ để bảo mật hoạt động truy cập giữa các tải công việc. Trong kiến trúc vi dịch vụ, cần có một phương pháp bảo mật mới. Dựa trên các thành phần bảo mật của Kubernetes như tài khoản dịch vụ, Istio cung cấp một bộ chính sách bảo mật linh hoạt cho ứng dụng của bạn.

Các chính sách Istio áp dụng cho cả quy trình xác thực và uỷ quyền. Xác thực xác minh danh tính (máy chủ này có phải là chính họ không?) và uỷ quyền xác minh quyền (ứng dụng này có được phép làm điều đó không?). Chúng tôi đã đề cập đến phương thức xác thực Istio trong phần TLS tương hỗ trong Mô-đun 1 (MeshPolicy). Trong phần này, chúng ta sẽ tìm hiểu cách sử dụng chính sách uỷ quyền của Istio để kiểm soát quyền truy cập vào một trong những tải công việc ứng dụng của chúng tôi là currencyservice.

Trước tiên, chúng tôi sẽ triển khai AuthorizationPolicy trên cả 4 cụm Nhà phát triển, đóng mọi quyền truy cập vào currencyservice và kích hoạt một lỗi trong giao diện người dùng. Sau đó, chúng tôi sẽ chỉ cho phép dịch vụ giao diện người dùng truy cập vào dịch vụ đơn vị tiền tệ.

1. Kiểm tra nội dung của currency-deny-all.yaml. Chính sách này sử dụng bộ chọn nhãn Triển khai để hạn chế quyền truy cập vào dịch vụ đơn vị tiền tệ. Hãy lưu ý vì sao không có trường spec – điều này có nghĩa là chính sách này sẽ từ chối mọi quyền truy cập vào dịch vụ đã chọn.

cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml
 

Đầu ra (không sao chép)

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

2. Sao chép chính sách đơn vị tiền tệ vào kho lưu trữ k8s cho các cụm hoạt động ở cả hai khu vực.

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. Đẩy thay đổi.

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

4. Kiểm tra trạng thái của dự án Hoạt động trên Cloud Build trong thẻ đã mở trước đó hoặc bằng cách nhấp vào đường liên kết sau:

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

5. Sau khi quá trình tạo bản dựng hoàn tất, hãy thử truy cập vào giao diện người dùng hipstershop trong trình duyệt theo đường liên kết sau:

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

Bạn sẽ thấy lỗi Uỷ quyền từ Currencyservice:

6. Hãy điều tra cách dịch vụ đơn vị tiền tệ thực thi chính sách Uỷ quyền này. Trước tiên, hãy bật nhật ký cấp theo dõi trên proxy Envoy cho một trong các nhóm đơn vị tiền tệ, vì theo mặc định, các lệnh gọi uỷ quyền bị chặn không được ghi lại.

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. Lấy nhật ký RBAC (uỷ quyền) từ proxy trợ giúp của dịch vụ tiền tệ. Bạn sẽ thấy thông báo "từ chối được thực thi" cho biết rằng dịch vụ đơn vị tiền tệ được đặt để chặn tất cả yêu cầu đến.

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

Đầu ra (không sao chép)

[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. Bây giờ, hãy cho phép giao diện người dùng (chứ không phải các dịch vụ phụ trợ khác) truy cập vào Currencyservice. Mở currency-allow-frontend.yaml và kiểm tra nội dung trong đó. Xin lưu ý rằng chúng tôi đã thêm quy tắc sau:

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

Đầu ra (không sao chép)

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

Ở đây, chúng tôi sẽ liệt kê một source.principal (máy khách) cụ thể vào danh sách cho phép để truy cập vào dịch vụ tiền tệ. Nguồn.main này được xác định bằng Tài khoản dịch vụ Kubernetes. Trong trường hợp này, tài khoản dịch vụ mà chúng tôi đưa vào danh sách cho phép là tài khoản dịch vụ giao diện người dùng trong không gian tên giao diện người dùng.

Lưu ý: khi sử dụng Tài khoản dịch vụ Kubernetes trong Istio Uỷ quyền, trước tiên bạn phải bật TLS chung trên toàn cụm như chúng ta đã làm trong Mô-đun 1. Việc này nhằm đảm bảo rằng thông tin xác thực tài khoản dịch vụ được gắn kết vào yêu cầu.

9. Sao chép chính sách đơn vị tiền tệ đã cập nhật

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. Đẩy thay đổi.

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

11. Xem trạng thái của dự án Hoạt động trên Cloud Build trong thẻ đã mở trước đó hoặc bằng cách nhấp vào đường liên kết sau:

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

12. Sau khi quá trình tạo bản dựng hoàn tất, hãy mở lại giao diện người dùng của Hipstershop. Lần này, bạn sẽ không thấy lỗi nào trên trang chủ. Lý do là giao diện người dùng rõ ràng được phép truy cập vào dịch vụ hiện tại.
13. Bây giờ, hãy thử thực hiện thanh toán bằng cách thêm mặt hàng vào giỏ hàng của bạn và nhấp vào "đặt hàng". Lần này, bạn sẽ thấy lỗi quy đổi giá từ dịch vụ đơn vị tiền tệ. Đó là vì chúng tôi chỉ mới đưa giao diện người dùng vào danh sách cho phép nên dịch vụ checkout vẫn không thể truy cập vào dịch vụ đơn vị tiền tệ.

14. Cuối cùng, hãy cho phép dịch vụ thanh toán truy cập vào đơn vị tiền tệ bằng cách thêm một quy tắc khác vào cảnh Ủy quyền dịch vụ tiền tệ của chúng ta. Xin lưu ý rằng chúng tôi chỉ mở quyền truy cập tiền tệ vào hai dịch vụ cần truy cập tính năng này - giao diện người dùng và thanh toán. Các phần phụ trợ khác vẫn sẽ bị chặn.
15. Mở currency-allow-frontend-checkout.yaml và kiểm tra nội dung trong đó. Xin lưu ý rằng danh sách quy tắc hoạt động dưới dạng logic OR – đơn vị tiền tệ sẽ chỉ chấp nhận các yêu cầu từ khối lượng công việc có một trong hai tài khoản dịch vụ này.

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

Đầu ra (không sao chép)

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. Sao chép chính sách uỷ quyền sau cùng vào 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. Đẩy các thay đổi

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

18. Xem trạng thái của dự án Hoạt động trên Cloud Build trong thẻ đã mở trước đó hoặc bằng cách nhấp vào đường liên kết sau:

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

19. Sau khi quá trình tạo bản dựng hoàn tất, hãy thử thực thi quy trình thanh toán – quy trình này sẽ hoạt động thành công.

Phần này hướng dẫn cách sử dụng Chính sách uỷ quyền của Istio để thực thi biện pháp kiểm soát quyền truy cập chi tiết ở cấp dịch vụ. Khi phát hành chính thức, bạn có thể tạo một Chính sách uỷ quyền cho mỗi dịch vụ (ví dụ: sử dụng chính sách cho phép tất cả) để cho phép tất cả khối lượng công việc trong cùng một không gian tên truy cập vào nhau.

12. Mở rộng cơ sở hạ tầng

Mục tiêu: Mở rộng quy mô cơ sở hạ tầng bằng cách thêm vùng, dự án và cụm mới.

• Sao chép kho lưu trữ infrastructure
• Cập nhật các tệp địa hình để tạo tài nguyên mới
• 2 mạng con trong khu vực mới (một mạng dành cho dự án hoạt động và một mạng dành cho dự án mới)
• Cụm hoạt động mới ở khu vực mới (trong mạng con mới)
• Máy bay điều khiển Istio mới cho khu vực mới
• 2 cụm ứng dụng trong dự án mới ở khu vực mới
• Cam kết sử dụng kho lưu trữ infrastructure
• Xác minh cài đặt

KỊCH TÍNH NHANH

Nếu bạn chọn phương pháp này, hãy chạy tập lệnh sau để hoàn tất phòng thí nghiệm này.

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

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Nếu bạn đã hoàn tất kịch bản theo dõi nhanh cho phòng thí nghiệm này, đừng thực hiện phương pháp sao chép và dán bên dưới**.**

Có nhiều cách để mở rộng quy mô nền tảng. Bạn có thể thêm nhiều điện toán hơn bằng cách thêm các nút vào những cụm hiện có. Bạn có thể thêm các cụm khác trong một khu vực. Hoặc bạn có thể thêm các khu vực khác vào nền tảng. Quyết định về khía cạnh cần mở rộng của nền tảng sẽ phụ thuộc vào các yêu cầu. Ví dụ: nếu có các cụm ở cả ba vùng trong một vùng, thì bạn có thể thêm nhiều nút (hoặc nhóm nút) vào cụm hiện có. Tuy nhiên, nếu bạn có các cụm ở 2/3 vùng trong một vùng, thì việc thêm một cụm mới ở vùng thứ ba sẽ giúp bạn mở rộng quy mô và một miền lỗi bổ sung (tức là một vùng mới). Một lý do khác để thêm một cụm mới trong một khu vực có thể là bạn cần phải tạo một cụm đối tượng thuê duy nhất – vì lý do liên quan đến quy định hoặc để tuân thủ (ví dụ: PCI hoặc cụm cơ sở dữ liệu chứa thông tin nhận dạng cá nhân). Khi doanh nghiệp và dịch vụ của bạn mở rộng, việc thêm các khu vực mới là điều không thể thiếu để cung cấp dịch vụ gần hơn với khách hàng.

Nền tảng hiện tại bao gồm 2 vùng và cụm trong 2 vùng cho mỗi khu vực. Bạn có thể nghĩ đến việc mở rộng quy mô nền tảng theo hai cách:

• Theo chiều dọc – trong từng khu vực bằng cách thêm nhiều điện toán hơn. Bạn có thể thực hiện việc này bằng cách thêm các nút (hoặc nhóm nút) vào các cụm hiện có hoặc thêm các cụm mới trong vùng. Việc này được thực hiện thông qua kho lưu trữ infrastructure. Cách đơn giản nhất là thêm các nút vào các cụm hiện có. Bạn không cần phải thiết lập gì thêm. Việc thêm các cụm mới có thể yêu cầu thêm mạng con (và các dải phụ), thêm các quy tắc tường lửa thích hợp, thêm các cụm mới vào mặt phẳng kiểm soát lưới dịch vụ ASM/Istio theo khu vực và triển khai tài nguyên ứng dụng cho các cụm mới.
• Theo chiều ngang – bằng cách thêm nhiều khu vực hơn. Nền tảng hiện tại sẽ cung cấp cho bạn một mẫu theo khu vực. Nền tảng này bao gồm một cụm hoạt động theo khu vực, nơi có sẵn quyền kiểm soát ASM/Istio và hai (hoặc nhiều) cụm ứng dụng theo vùng nơi tài nguyên ứng dụng được triển khai.

Trong hội thảo này, bạn sẽ mở rộng quy mô nền tảng "theo chiều ngang" vì nó cũng bao gồm các bước trường hợp sử dụng dọc. Để mở rộng quy mô nền tảng theo chiều ngang, bạn cần thêm một khu vực mới (r3) vào nền tảng, những tài nguyên sau đây:

1. Mạng con trong dự án lưu trữ dùng chung VPC ở khu vực r3 cho các cụm hoạt động và ứng dụng mới.
2. Một cụm hoạt động khu vực trong khu vực r3 nơi có mặt phẳng điều khiển ASM/Istio.
3. Hai cụm ứng dụng vùng trong hai vùng trên vùng r3.
4. Cập nhật lên kho lưu trữ k8s:
5. Triển khai tài nguyên mặt phẳng điều khiển ASM/Istio cho cụm hoạt động trong khu vực r3.
6. Triển khai tài nguyên mặt phẳng điều khiển dùng chung ASM/Istio cho các cụm ứng dụng trong khu vực r3.
7. Mặc dù bạn không cần tạo dự án mới, nhưng các bước trong hội thảo minh hoạ cách thêm dự án dev3 mới để đề cập đến trường hợp sử dụng khi thêm nhóm mới vào nền tảng.

Kho lưu trữ cơ sở hạ tầng được dùng để thêm các tài nguyên mới nêu trên.

1. Trong Cloud Shell, hãy chuyển đến WORKDIR và sao chép kho lưu trữ 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. Sao chép nhánh add-proj của kho lưu trữ nguồn hội thảo vào thư mục add-proj-repo.

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

 

3. Sao chép các tệp từ nhánh add-proj trong kho lưu trữ hội thảo nguồn. Nhánh add-proj chứa các thay đổi cho phần này.

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

4. Thay thế thư mục infrastructure trong thư mục kho lưu trữ add-proj bằng một đường liên kết tượng trưng đến thư mục infra-repo để cho phép các tập lệnh trên nhánh đó chạy.

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

5. Chạy tập lệnh add-project.sh để sao chép các trạng thái và biến thể dùng chung vào cấu trúc thư mục dự án mới.

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

6. Xác nhận và áp dụng các thay đổi để tạo dự án mới

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

7. Cam kết kích hoạt kho lưu trữ infrastructure để triển khai cơ sở hạ tầng bằng các tài nguyên mới. Xem tiến trình của Cloud Build bằng cách nhấp vào kết quả của đường liên kết sau đây và chuyển đến bản dựng mới nhất ở trên cùng.

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

Bước này cần 25-30 phút để hoàn tất. Đến giờ nghỉ giải lao rồi.

Bước cuối cùng của infrastructure Cloud Build là tạo các tài nguyên Kubernetes mới trong k8s-repo. Thao tác này sẽ kích hoạt Bản dựng đám mây trong k8s-repo (trong dự án hoạt động). Các tài nguyên mới của Kubernetes dành cho 3 cụm mới được thêm vào ở bước trước. Gói điều khiển ASM/Istio và tài nguyên vùng điều khiển dùng chung được thêm vào các cụm mới bằng Bản dựng đám mây k8s-repo.

8. Sau khi hoàn tất thành công cơ sở hạ tầng của Cloud Build, hãy chuyển đến k8s-repo Cloud Build mới nhất đang chạy bằng cách nhấp vào đường liên kết đầu ra sau.

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

9. Chạy tập lệnh sau để thêm các cụm mới vào tệp vars và kubeconfig.

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

10. Thay đổi biến KUBECONFIG để trỏ đến tệp kubeconfig mới.

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

11. Liệt kê ngữ cảnh cụm của bạn. Bạn sẽ thấy 8 cụm.

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

Xác minh cài đặt Istio

12. Đảm bảo Istio được cài đặt trên cụm hoạt động mới bằng cách kiểm tra tất cả các nhóm đang chạy và công việc đã hoàn tất.

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. Đảm bảo bạn đã cài đặt Istio trên cả hai cụm dev3. Chỉ nên bao gồm thành phần, trình chèn trợ giúp và Coredns trong các cụm dev3. Các thiết bị này dùng chung một bảng điều khiển Istio đang chạy trong cụm 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

Xác minh chế độ khám phá dịch vụ cho vùng điều khiển dùng chung

14. Xác minh xem các bí mật đã được triển khai trong toàn bộ cụm hoạt động của cả 6 cụm ứng dụng.

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. Ngắt mạch

Mục tiêu: Triển khai cầu dao cho dịch vụ vận chuyển.

• Tạo DestinationRule cho Dịch vụ shipping để triển khai cầu dao
• Sử dụng fortio (một tiện ích tạo tải) để xác thực cầu dao cho Dịch vụ shipping bằng cách buộc rút mạch

Hướng dẫn của Fast Track Script Lab

Fast Track Script Lab sắp ra mắt!!

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Giờ đây, khi chúng ta đã học về một số chiến lược theo dõi và khắc phục sự cố cơ bản cho các dịch vụ có hỗ trợ Istio, hãy xem cách Istio giúp bạn cải thiện khả năng phục hồi cho các dịch vụ của mình, giảm bớt khối lượng khắc phục sự cố mà bạn phải thực hiện ngay từ đầu.

Một cấu trúc dịch vụ vi mô gây ra nguy cơ lỗi phân tầng, trong đó lỗi của một dịch vụ có thể truyền tới các phần phụ thuộc của dịch vụ đó và các phần phụ thuộc của các phần phụ thuộc đó, gây ra "hiệu ứng gợn sóng" có khả năng ảnh hưởng đến người dùng cuối. Istio cung cấp chính sách về lưu lượng truy cập của Thiết bị ngắt mạch để giúp bạn tách biệt các dịch vụ, bảo vệ các dịch vụ hạ nguồn (phía máy khách) khỏi phải chờ các dịch vụ không hoạt động và bảo vệ các dịch vụ ngược dòng (phía máy chủ) khỏi tình trạng bất ngờ lưu lượng truy cập hạ nguồn khi các dịch vụ này có kết nối mạng trở lại. Nhìn chung, việc sử dụng Cầu dao có thể giúp bạn tránh tình trạng tất cả các dịch vụ của mình không thực hiện được SLO do một dịch vụ phụ trợ đang bị treo.

Mẫu Cầu dao được đặt tên theo công tắc điện có thể "vạch" khi có quá nhiều dòng điện truyền qua, giúp bảo vệ các thiết bị không bị quá tải. Trong quá trình thiết lập Istio, Envoy chính là cầu dao, theo dõi số lượng yêu cầu đang chờ xử lý cho một dịch vụ. Ở trạng thái đóng mặc định này, các yêu cầu chuyển qua Envoy mà không bị gián đoạn.

Tuy nhiên, khi số lượng yêu cầu đang chờ xử lý vượt quá ngưỡng đã xác định, cầu dao sẽ bị ngắt (mở) và Envoy ngay lập tức trả về lỗi. Điều này cho phép máy chủ gặp sự cố nhanh chóng đối với ứng dụng và ngăn mã xử lý ứng dụng máy chủ nhận yêu cầu của ứng dụng khi quá tải.

Sau đó, sau thời gian chờ đã xác định, Envoy chuyển sang trạng thái mở một nửa, trong đó máy chủ có thể bắt đầu nhận lại yêu cầu theo cách thử và nếu có thể phản hồi thành công các yêu cầu, cầu dao sẽ đóng lại và các yêu cầu đến máy chủ bắt đầu thực hiện trở lại.

Sơ đồ này tóm tắt mẫu cầu dao Istio. Các hình chữ nhật màu xanh dương đại diện cho Envoy, vòng tròn tô màu xanh dương đại diện cho ứng dụng khách và các vòng tròn màu trắng đại diện cho vùng chứa phía máy chủ:

Bạn có thể xác định các chính sách của Ngắt điện bằng cách sử dụng Istio DestinationRules. Trong phần này, chúng tôi sẽ áp dụng chính sách sau để thực thi cầu dao trong dịch vụ vận chuyển:

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

Có hai trường DestinationRule cần lưu ý ở đây. connectionPool xác định số lượng kết nối mà dịch vụ này sẽ cho phép. Trường bên ngoàiDetection là nơi chúng ta định cấu hình cách Envoy sẽ xác định ngưỡng mở cầu dao. Tại đây, mỗi giây (khoảng thời gian), Envoy sẽ đếm số lượng lỗi nhận được từ vùng chứa phía máy chủ. Nếu vượt quá ngưỡng consecutiveErrors, thì cầu dao Envoy sẽ mở và 100% nhóm danh mục sản phẩm sẽ được bảo vệ khỏi các yêu cầu của khách hàng mới trong 10 giây. Sau khi cầu dao Envoy mở (tức là đang hoạt động), máy khách sẽ gặp lỗi 503 (Dịch vụ không có sẵn). Hãy xem ví dụ thực tế.

1. Thiết lập các biến môi trường cho k8s-repo và asm dir để đơn giản hoá các lệnh.

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

2. Cập nhật kho lưu trữ k8s

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

3. Cập nhật DestinationRule của dịch vụ vận chuyển trên cả hai cụm Vận hành.

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. Sao chép một nhóm trình tạo tải Fortio vào cụm GKE_1 trong khu vực Dev1. Đây là nhóm ứng dụng khách mà chúng tôi sẽ sử dụng để "di chuyển" cầu dao cho dịch vụ vận chuyển.

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. Xác nhận các thay đổi.

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

6. Chờ Cloud Build hoàn tất.
7. Quay lại Cloud Shell, hãy sử dụng nhóm fortio để gửi lưu lượng truy cập gRPC đến dịch vụ vận chuyển bằng 1 kết nối đồng thời, tổng cộng 1.000 yêu cầu. Thao tác này sẽ không làm vấp cầu dao vì chúng ta chưa vượt quá chế độ cài đặt 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 
 

Đầu ra (không sao chép)

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

8. Bây giờ, hãy chạy lại fortio, tăng số lượng kết nối đồng thời lên 2, nhưng giữ tổng số yêu cầu không đổi. Chúng ta sẽ thấy tối đa 2/3 yêu cầu trả về thông báo "overflow" ( tràn) do cầu dao đã bị vấp: trong chính sách mà chúng tôi đã xác định, chỉ cho phép 1 kết nối đồng thời trong khoảng thời gian 1 giây.

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 
 

Đầu ra (không sao chép)

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 theo dõi số lượng kết nối bị rớt khi cầu dao đang hoạt động, thông qua chỉ số upstream_rq_pending_overflow. Hãy tìm thông tin này trong nhóm 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
 

Đầu ra (không sao chép)

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. Hãy dọn dẹp bằng cách xoá chính sách cầu dao khỏi cả hai khu vực.

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
 

Phần này minh hoạ cách thiết lập chính sách đối với một cầu dao cho một dịch vụ. Phương pháp hay nhất là thiết lập một cầu dao cho mọi dịch vụ đầu nguồn (máy chủ phụ trợ) có khả năng bị treo. Bằng cách áp dụng chính sách về cầu dao Istio, bạn sẽ giúp tách biệt các dịch vụ vi mô của mình, xây dựng khả năng chống lỗi vào cấu trúc của mình và giảm nguy cơ lỗi phân tầng ở mức tải cao.

14. Chèn lỗi

Mục tiêu: Kiểm tra khả năng thích ứng của Dịch vụ đề xuất bằng cách đưa ra độ trễ (trước khi chuyển sang giai đoạn sản xuất).

• Tạo VirtualService cho Dịch vụ recommendation để giới thiệu độ trễ 5 giây
• Kiểm tra độ trễ bằng trình tạo tải fortio
• Xoá độ trễ trong VirtualService rồi xác thực

Hướng dẫn của Fast Track Script Lab

Fast Track Script Lab sắp ra mắt!!

Hướng dẫn của Phòng thí nghiệm về phương pháp sao chép và dán

Thêm chính sách về cầu dao vào dịch vụ là một cách để tăng cường khả năng chống chịu cho các dịch vụ trong quá trình sản xuất. Tuy nhiên, việc ngắt mạch dẫn đến lỗi — có thể là lỗi mà người dùng gặp phải — đây không phải là điều lý tưởng. Để tránh gặp phải những trường hợp lỗi như vậy và dự đoán chính xác hơn cách các dịch vụ thứ cấp của bạn có thể phản hồi khi phần phụ trợ trả về lỗi, bạn có thể áp dụng tính năng kiểm thử hỗn loạn trong một môi trường chạy thử. Kiểm thử hỗn loạn là phương pháp cố ý làm hỏng dịch vụ để phân tích những điểm yếu trong hệ thống và cải thiện khả năng chịu lỗi. Bạn cũng có thể sử dụng kiểm thử sự hỗn loạn để xác định cách giảm thiểu lỗi giao diện người dùng khi chương trình phụ trợ gặp sự cố, chẳng hạn như bằng cách hiển thị kết quả được lưu vào bộ nhớ đệm trong giao diện người dùng.

Việc sử dụng Istio để chèn lỗi rất hữu ích vì bạn có thể sử dụng hình ảnh bản phát hành chính thức và thêm lỗi ở lớp mạng, thay vì sửa đổi mã nguồn. Trong phiên bản phát hành chính thức, ngoài lớp mạng, bạn có thể sử dụng một công cụ kiểm thử hỗn hợp hoàn chỉnh để kiểm thử khả năng phục hồi ở lớp Kubernetes/tính toán.

Bạn có thể dùng Istio để kiểm thử sự hỗn loạn bằng cách áp dụng một VirtualService với "lỗi" . Istio hỗ trợ 2 loại lỗi: lỗi trễ (chèn thời gian chờ) và lỗi huỷ bỏ (chèn lỗi HTTP). Trong ví dụ này, chúng tôi sẽ chèn lỗi độ trễ 5 giây vào dịch vụ đề xuất. Nhưng lần này, thay vì dùng cầu dao để "thất bại nhanh" đối với dịch vụ treo này, chúng tôi sẽ buộc các dịch vụ hạ nguồn phải chịu hết thời gian chờ.

11. Chuyển đến thư mục chèn lỗi.

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

12. Mở k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml để kiểm tra nội dung trong đó. Lưu ý rằng Istio có lựa chọn chèn lỗi vào một tỷ lệ phần trăm các yêu cầu. Ở đây, chúng tôi sẽ đặt thời gian chờ cho tất cả các yêu cầu dịch vụ đề xuất.

Đầu ra (không sao chép)

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. Sao chép VirtualService vào k8s_repo. Chúng tôi sẽ đưa lỗi vào toàn bộ, trên cả hai khu vực.

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. Đẩy các thay đổi

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

15. Chờ Cloud Build hoàn tất.
16. Thực hiện vào nhóm fortio được triển khai trong bộ phận cầu dao và gửi một số lưu lượng truy cập đến dịch vụ đề xuất.

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:

Đầu ra (không sao chép)

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. Một cách khác để xem lỗi mà chúng tôi đã đưa vào thực tế là mở giao diện người dùng trong trình duyệt web và nhấp vào bất kỳ sản phẩm nào. Trang sản phẩm sẽ mất thêm 5 giây để tải vì trang này tìm nạp các đề xuất hiển thị ở cuối trang.
18. Dọn dẹp bằng cách xoá dịch vụ chèn lỗi khỏi cả hai cụm Vận hành.

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. Thay đổi về thông báo đẩy:

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

15. Giám sát máy bay điều khiển Istio

ASM lắp đặt 4 thành phần quan trọng của máy bay điều khiển: Phi công, Máy trộn, Galley và Thành. Mỗi đơn vị đều gửi các chỉ số giám sát có liên quan cho Prometheus, còn ASM cung cấp các trang tổng quan của Grafana để cho phép người vận hành trực quan hoá dữ liệu giám sát này cũng như đánh giá tình trạng và hiệu suất của máy bay điều khiển.

Xem Trang tổng quan

20. Chuyển tiếp dịch vụ Grafana được cài đặt với Istio

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

21. Mở Grafana trong trình duyệt
22. Nhấp vào "Bản xem trước trên web" biểu tượng ở góc trên cùng bên phải của Cửa sổ Cloud Shell
23. Nhấp vào Xem trước trên cổng 3000 (Lưu ý: nếu cổng không phải là 3000, hãy nhấp vào Thay đổi cổng và chọn cổng 3000)
24. Thao tác này sẽ mở một thẻ trong trình duyệt có URL tương tự như " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Xem những trang tổng quan có sẵn
26. Sửa đổi URL thành " BASE_URL/dashboard"
27. Nhấp vào "istio" thư mục để xem các trang tổng quan có sẵn
28. Nhấp vào bất kỳ trang tổng quan nào trong số đó để xem hiệu suất của thành phần đó. Chúng ta sẽ xem xét các chỉ số quan trọng cho từng thành phần trong các phần sau.

Phi công giám sát

Thí điểm là thành phần vùng điều khiển phân phối cấu hình mạng và cấu hình chính sách cho vùng dữ liệu (các proxy Envoy). Chương trình thí điểm có xu hướng mở rộng quy mô theo số lượng khối lượng công việc và đợt triển khai, mặc dù không nhất thiết phải kéo theo lưu lượng truy cập đối với những khối lượng công việc đó. Phi công không khoẻ mạnh có thể:

• tiêu tốn nhiều tài nguyên hơn mức cần thiết (CPU và/hoặc RAM)
• dẫn đến sự chậm trễ trong việc gửi thông tin cấu hình mới cho Envoys

Lưu ý: Nếu Chương trình thí điểm ngừng hoạt động hoặc nếu có sự chậm trễ, thì khối lượng công việc của bạn vẫn phân phát lưu lượng truy cập.

23. Điều hướng tới " BASE_URL/dashboard/db/istio-pilot-dashboard" trong trình duyệt để xem các chỉ số của Chương trình thí điểm.

Các chỉ số quan trọng được giám sát

Sử dụng tài nguyên

Bạn có thể tham khảo trang Hiệu suất và khả năng mở rộng của Istio để biết các con số về mức sử dụng chấp nhận được. Hãy liên hệ với nhóm hỗ trợ GCP nếu bạn thấy mức sử dụng tài nguyên ổn định cao hơn đáng kể so với mức này.

Thông tin về chương trình thí điểm

Phần này giám sát các lần đẩy cấu hình đến các proxy Envoy của bạn.

• Hoạt động đẩy thí điểm cho biết loại cấu hình được đẩy tại một thời điểm nhất định bất kỳ.
• Mục Giám sát ADS hiển thị số lượng Dịch vụ ảo, Dịch vụ và Thiết bị đầu cuối được kết nối trong hệ thống.
• Các cụm không có điểm cuối đã biết cho thấy các điểm cuối đã được định cấu hình nhưng không có thực thể nào đang chạy (có thể cho biết các dịch vụ bên ngoài, chẳng hạn như *.googleapis.com).
• Lỗi thí điểm cho thấy số lượng lỗi gặp phải theo thời gian.
• Xung đột cho biết số lượng xung đột có cấu hình không rõ ràng trên trình nghe.

Nếu bạn gặp Lỗi hoặc Xung đột thì tức là một hoặc nhiều dịch vụ của bạn có cấu hình kém hoặc không nhất quán. Xem Khắc phục sự cố vùng dữ liệu để biết thông tin.

Thông tin của Đặc phái viên

Phần này chứa thông tin về các proxy Envoy liên hệ với mặt phẳng điều khiển. Liên hệ với bộ phận hỗ trợ GCP nếu bạn thấy Lỗi kết nối XDS nhiều lần.

Bộ trộn giám sát

Mixer là thành phần chuyển kênh đo từ xa từ proxy Envoy sang các phần phụ trợ đo từ xa (thường là Prometheus, Stackdriver, v.v.). Trong dung lượng này, mục đó không nằm trong vùng dữ liệu. API này được triển khai khi 2 Công việc Kubernetes (còn gọi là Bộ trộn) được triển khai bằng 2 tên dịch vụ khác nhau (istio-telemetry và istio-policy).

Bạn cũng có thể sử dụng trình trộn để tích hợp với các hệ thống chính sách. Trong khả năng này, Mixer có ảnh hưởng đến vùng dữ liệu vì kiểm tra chính sách đối với Mixer không chặn quyền truy cập vào các dịch vụ của bạn.

Mixer có xu hướng mở rộng quy mô theo lưu lượng truy cập.

24. Điều hướng tới " BASE_URL/dashboard/db/istio-mixer-dashboard" trong trình duyệt để xem các chỉ số của Mixer (Bộ trộn).

Các chỉ số quan trọng được giám sát

Sử dụng tài nguyên

Bạn có thể tham khảo trang Hiệu suất và khả năng mở rộng của Istio để biết các con số về mức sử dụng chấp nhận được. Hãy liên hệ với nhóm hỗ trợ GCP nếu bạn thấy mức sử dụng tài nguyên ổn định cao hơn đáng kể so với mức này.

Tổng quan về trình kết hợp

• Thời lượng phản hồi là một chỉ số quan trọng. Mặc dù các báo cáo cho phương pháp đo từ xa của Mixer không nằm trong đường dẫn dữ liệu, nhưng nếu các độ trễ này cao thì chắc chắn sẽ làm chậm hiệu suất của proxy trợ giúp. Bạn sẽ thấy phân vị thứ 90 nằm trong mili giây một chữ số và phân vị thứ 99 sẽ dưới 100 mili giây.

• Thời lượng điều phối bộ chuyển đổi cho biết Trình kết hợp độ trễ đang gặp phải khi gọi bộ chuyển đổi (thông qua bộ chuyển đổi này, bộ chuyển đổi sẽ gửi thông tin đến hệ thống đo từ xa và ghi nhật ký). Độ trễ cao ở đây sẽ hoàn toàn ảnh hưởng đến hiệu suất của lưới. Xin nhắc lại, độ trễ p90 phải dưới 10 mili giây.

Thiết bị giám sát Galley

Galley là thành phần xác thực, truyền dẫn, xử lý và phân phối cấu hình của Istio. API này truyền tải cấu hình từ máy chủ API Kubernetes đến Chương trình thí điểm. Giống như Pilot, chương trình này có xu hướng mở rộng quy mô theo số lượng dịch vụ và điểm cuối trong hệ thống.

25. Điều hướng tới " BASE_URL/dashboard/db/istio-galley-dashboard" trên trình duyệt để xem các chỉ số của Galley.

Các chỉ số quan trọng được giám sát

Xác thực tài nguyên

Chỉ số quan trọng nhất cần tuân theo cho biết số lượng tài nguyên thuộc nhiều loại khác nhau như Quy tắc đích đến, Cổng vào và các mục nhập Dịch vụ đang đạt hoặc không xác thực được.

Ứng dụng đã kết nối

Cho biết có bao nhiêu ứng dụng được kết nối với Galley; thường thì số liệu này sẽ là 3 (pilot, istio-telemetry, istio-policy) và sẽ mở rộng khi các thành phần đó mở rộng quy mô.

16. Khắc phục sự cố với Istio

Khắc phục sự cố vùng dữ liệu

Nếu Trang tổng quan chương trình thí điểm cho thấy bạn gặp vấn đề về cấu hình, thì bạn nên kiểm tra nhật ký PIlot hoặc sử dụng istioctl để tìm vấn đề về cấu hình.

Để kiểm tra nhật ký của Chương trình thí điểm, hãy chạy phương thức khám phá kubectl -n istio-system istio-pilot-69db46c598-45m44, thay thế istio-pilot-... bằng giá trị nhận dạng nhóm cho thực thể thí điểm mà bạn muốn khắc phục sự cố.

Trong nhật ký kết quả, tìm kiếm thông báo Push Status (Trạng thái đẩy). Ví dụ:

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="
}

Trạng thái đẩy sẽ cho biết mọi vấn đề xảy ra khi cố gắng đẩy cấu hình đến proxy của Envoy – trong trường hợp này, chúng ta sẽ thấy một vài "Cụm trùng lặp" cho biết các đích đến trùng lặp trong luồng ngược.

Để được trợ giúp chẩn đoán sự cố, hãy liên hệ với nhóm hỗ trợ Google Cloud về vấn đề.

Tìm lỗi cấu hình

Nếu muốn sử dụng istioctl cho việc phân tích cấu hình của bạn, hãy chạy istioctl experimental analyze -k --context $OPS_GKE_1. Thao tác này sẽ phân tích cấu hình trong hệ thống của bạn, chỉ ra mọi vấn đề cùng với mọi thay đổi được đề xuất. Hãy xem tài liệu để biết danh sách đầy đủ các lỗi cấu hình mà lệnh này có thể phát hiện.

17. Dọn dẹp

Quản trị viên sẽ thực hiện các bước sau đây sau khi hội thảo kết thúc.

Quản trị viên chạy tập lệnh Cleanup_workshop.sh để xoá các tài nguyên do tập lệnh bootstrap_workshop.sh tạo ra. Bạn cần các thông tin sau để chạy tập lệnh dọn dẹp.

• Tên tổ chức (ví dụ: yourcompany.com)
• Mã hội thảo – có dạng YYMMDD-NN, ví dụ: 200131-01
• Bộ chứa GCS của quản trị viên – được xác định trong tập lệnh Tự khởi động.

13. Mở Cloud Shell, thực hiện tất cả các thao tác bên dưới trong Cloud Shell. Hãy nhấp vào đường liên kết bên dưới.

VỎ ĐÁM Mây

14. Xác minh rằng bạn đã đăng nhập vào gcloud bằng Người dùng quản trị dự kiến.

gcloud config list
 

15. Chuyển đến thư mục asm.

cd ${WORKDIR}/asm
 

16. Xác định Tên tổ chức và mã hội thảo cần xoá.

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

17. Chạy tập lệnh dọn dẹp như sau.

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