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À MỘT HỘI THẢO Ở GIAI ĐOẠN ALPHA VÀ CHỈ DÀNH CHO LỚP HỌC DO GIẢNG VIÊN HƯỚNG DẪN.

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

2. Tổng quan

Sơ đồ kiến trúc

Hội thảo này là một trải nghiệm thực tế, sống độ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 quá trình sản xuất. Các công nghệ chính được sử dụng là Google Kubernetes Engine (GKE) để tính toán và lưới dịch vụ Istio để tạo kết nối bảo mật, khả năng ghi nhận và định hình lưu lượng truy cập nâng cao. Tất cả các phương pháp và công cụ được sử dụng trong hội thảo này đều là những phương pháp và công cụ mà bạn sẽ sử dụng trong quá trình sản xuất.

Chương trình làm việc

• Mô-đun 0 – Giới thiệu và thiết lập nền tảng
• Giới thiệu và kiến trúc
• Giới thiệu về Service Mesh và Istio/ASM
• Thực hành: 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 các ứng dụng bằng ASM
• Mô hình kho lưu trữ: Giải thích về 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ụ phân tán và khả năng ghi nhận
• Bữa trưa
• Phòng thí nghiệm: Khả năng ghi nhận bằng Stackdriver
• QNA
• Module 2 - DevOps – Triển khai theo kiểu phát hành thử nghiệm, chính sách/RBAC
• Khám phá dịch vụ trên nhiều cụm và bảo mật/chính sách
• Phòng thí nghiệm: TLS hai chiều
• Triển khai Canary
• Phòng thí nghiệm: Triển khai Canary
• Cân bằng tải toàn cầu an toàn cho nhiều cụm
• Nghỉ giải lao
• Bài thực hành: Chính sách uỷ quyền
• QNA
• Module 3 - Infra Ops - Platform upgrades
• Thành phần của Dịch vụ phân tán
• Phòng thí nghiệm: Mở rộng quy mô cơ sở hạ tầng
• Các bước tiếp theo

Trang trình bày

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

ASM Workshop Slides

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

Bạn cần đáp ứng những yêu cầu sau trước khi tiếp tục 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 của tài khoản thanh toán này)
3. Vai trò IAM Quản trị viên tổ chức ở cấp Tổ chức cho người dùng

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

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

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

Giải thích về tập lệnh hội thảo Bootstrap

Một tập lệnh có tên là 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ể dùng tập lệnh này để thiết lập một môi trường cho riêng mình hoặc nhiều môi trường cho nhiều người dùng trong trường hợp bạn đang tổ chức hội thảo này để đào tạo nhiều người dùng.

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

• Tên tổ chức (ví dụ: 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 để thanh toán cho tất cả tài nguyên được dùng trong hội thảo.
• Số xưởng (ví dụ: 01) – Số có hai chữ số. Bạn có thể dùng tính năng này nếu tổ chức 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ố xưởng cũng được dùng để lấy mã dự án. Việc có các số hiệu riêng biệt cho mỗi hội thảo giúp bạn dễ dàng đảm bảo rằng bạn nhận được mã dự án riêng biệt mỗi lần. Ngoài số 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. Tổ hợp ngày và số hội thảo cung cấp mã dự án riêng biệt.
• Số người dùng bắt đầu (ví dụ: 1) – Số này biểu thị người dùng lần đầu 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ể đặt số người dùng bắt đầu là 1 và số người dùng kết thúc là 10.
• 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ể đặt số người dùng bắt đầu là 1 và số người dùng kết thúc 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 mình), hãy đặt số người dùng bắt đầu và kết thúc giống nhau. Thao tác này sẽ tạo ra một môi trường duy nhất.

Ngoài ngày và số hội thảo, mã nhận dạng dự án còn bao gồm số người dùng bắt đầu và số người dùng kết thúc. Mã nhận dạng người dùng (đối với người dùng thực hiện hội thảo) được lấy từ số người dùng bắt đầu và kết thúc. Mã nhận dạng người dùng được giải thích trong phần User schema and permissions performing the workshop.

• Nhóm GCS của quản trị viên (ví dụ: my-gcs-bucket-name) – Nhóm GCS được 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 dùng để xoá tất cả tài nguyên được tạo trong tập lệnh hội thảo khởi động một cách an toàn. Quản trị viên tạo hội thảo phải có quyền đọc/ghi đối với bộ chứa này.

Tập lệnh hội thảo khởi động sử dụng các giá trị được cung cấp ở trên và đóng vai trò là một tập lệ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.

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

Có 2 loại người dùng trong hội thảo này. Một ADMIN_USER, người tạo và xoá tài nguyên cho 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 tài nguyên của riêng mình. ADMIN_USER có quyền truy cập vào tất cả chế độ thiết lập của người dùng. Nếu bạn đang thiết lập 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 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.

ADMIN_USER yêu cầu các quyền sau ở cấp tổ chức:

• Chủ sở hữu – Quyền Chủ sở hữu dự án đối với tất cả dự án trong Tổ chức.
• Quản trị viên thư mục – Có thể tạo và xoá thư mục trong Tổ chức. Mỗi người dùng sẽ có một thư mục duy nhất 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.
• Người xoá dự án – Có thể xoá các dự án trong Tổ chức.
• Quản trị viên IAM dự án – Có thể tạo quy tắc IAM trong tất cả các dự án thuộc Tổ chức.

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

Lược đồ người dùng và các quyền thực hiện 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 quy tắ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ố người dùng bắt đầu và số người dùng kết thúc. Những con số này được dùng để tạo tên người dùng sau đây:

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

Ví dụ: nếu bạn chạy tập lệnh hội thảo khởi động với số người dùng bắt đầu là 1 và số người dùng kết thúc là 3, thì trong tổ chức có tên yourcompany.com, các môi trường hội thảo cho những người dùng sau đây 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 các 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ủ lược đồ đặt tên người dùng này khi sử dụng tập lệnh 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 được thiết kế để khởi động từ Cloud Shell. Bạn cần có những công cụ sau đây để tham gia 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 và không hoạt động trên Mac OS)
• git (đảm bảo bạn đã cập nhật phiên bản mới nhất)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Theo mặc định, tất cả các công cụ, ngoại trừ kustomize, đều đã được cài đặt trong Cloud Shell. Nếu bạn chưa cài đặt kustomize, hãy cài đặt bằng tập lệnh bash được cung cấp trong đường liên kết ở trên và đảm bảo rằng tệp nhị phân kustomize nằm trong PATH của bạn, sau đó 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. Nhấp vào đường liên kết bên dưới.

CLOUD SHELL

2. Xác minh rằng bạn đã đăng nhập vào gcloud bằng người dùng Quản trị viên mà bạn muốn.

gcloud config list
 

3. Tạo một WORKDIR và sao chép kho lưu trữ của 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, số hội thảo và một nhóm lưu trữ GCS quản trị để sử dụng cho hội thảo. Xem xét các quyền cần thiết để thiết lập hội thảo trong 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ố người dùng bắt đầu và kết thúc vì bạn đang thiết lập 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 mỗi 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ị terraform được dùng để tạo phần còn lại của các tài nguyên GCP cần thiết cho hội thảo này. 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 kế hoạch Terraform. Bạn cấp cho tài khoản dịch vụ Cloud Build các vai trò IAM phù hợp để tài khoản này có thể tạo tài nguyên trên GCP. Cuối cùng, bạ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 Terraform cho tất cả tài nguyên GCP.

Để xem các tác vụ 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. Thư mục này chỉ được duy trì nếu bạn đang 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. Nguồn tệp biến để thiết lập các 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 xưởng 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. Nhấp vào đường liên kết bên dưới.

CLOUD SHELL

8. Xác minh rằng bạn đã đăng nhập vào gcloud bằng người dùng Quản trị viên mà bạn muốn.

gcloud config list
 

9. Tạo một WORKDIR và sao chép kho lưu trữ của 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, số hội thảo, số người dùng bắt đầu và kết thúc, cũng như một nhóm GCS quản trị để sử dụng cho hội thảo. Xem xét các quyền cần thiết để thiết lập hội thảo trong 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 workshop.txt từ vùng chứa GCS của 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

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 của Chrome hoặc Firefox.

Chọn lộ trình học tập trong phòng thí nghiệm

Bạn có thể thực hiện các bài thực hành trong hội thảo này theo một trong hai cách:

• Cách "kịch bản tương tác dễ dàng và nhanh chóng"
• Cách "sao chép và dán từng chỉ dẫn theo cách thủ công"

Phương thức tập lệnh đường tắt 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, hướng dẫn bạn thực hiện 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 được chạy theo lô, kèm theo phần giải thích ngắn gọn về từng bước và mục đích của từng bước. Sau mỗi nhóm, bạn sẽ được nhắc chuyển sang nhóm lệnh tiếp theo. Nhờ đó, bạn có thể thực hiện các bài thực hành theo tốc độ của riêng mình. Các tập lệnh trong kênh phát hành công khai là đẳng năng, tức là bạn có thể chạy các tập lệnh này nhiều lần mà vẫn có cùng kết quả.

Các tập lệnh đường tắt sẽ xuất hiện ở đầu mỗi phòng thí nghiệm trong một hộp màu xanh lục như minh hoạ bên dưới.

FAST TRACK SCRIPT

${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 kèm theo phần giải thích về các lệnh. Phương thức này chỉ được 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 theo phương thức này sẽ mang lại kết quả tương tự.

Khi thực hiện các bài thực hành, vui lòng chọn một trong hai phương thức.

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 đó, đừng thực hiện các bước trong phương thức còn lại.

Thiết lập tập lệnh nhanh

Sau khi hoàn thành kịch bản đường tắt, bạn đã hoàn thành phòng thí nghiệm đó. Không thực hiện các bước trong phần Hướng dẫn sao chép và dán trong phòng thí nghiệm.

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

Hội thảo này được thực hiện bằng 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ực hành sở hữu tất cả cá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 tài khoản phòng thực hành (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ả cá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ụ: đối với tài khoản phòng thí nghiệm [e-mail], mã dự án quản trị viên terraform sẽ là user001-200131-01-tf-abcde, v.v. cho 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ực hành 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ực hành.

Kiểm tra email công ty của bạn (chính là email bạn đã dùng để đăng ký tham gia hội thảo). Bạn sẽ nhận được email từ quản trị viên hội thảo kèm theo thông tin đăng nhập tài khoản phòng thực hành (tức là tên người dùng và mật khẩu). Email sẽ 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.

CLOUD SHELL

2. Đăng nhập bằng thông tin đăng nhập 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). 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 sử dụng nhằm truy cập vào các tài nguyên GCP. Mỗi tài khoản sẽ có một VM Cloud Shell. Việc đăng nhập bằng tài khoản phòng thí nghiệm sẽ cung cấp và đăng nhập cho bạn bằng thông tin đăng nhập của tài khoản phòng thí nghiệm. Ngoài Cloud Shell, một Trình chỉnh sửa 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 chỉnh sửa Cloud Code (ở trên cùng). Biểu tượng bút chì và dấu nhắc shell ở góc trên cùng bên phải cho phép bạn chuyển đổi giữa hai biểu tượng (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 mà bạn thực hiện tất cả các bài thực hành cho 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ố để sử dụng cho hội thảo này. Đây 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 bằng cách sử dụng cờ "-sufa" hoặc "–setup-for-admin", hãy đặt MY_USER thành email cho tài khoản GCP mà bạn đã dùng để tạo các dự án hội thảo.

7. Lặp lại các biến WORKDIR và MY_USER để đảm bảo cả hai biến đều được đặt đúng cách 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à quá trình cài đặt Istio

• Lắp đặt công cụ trong xưởng
• Sao chép kho lưu trữ xưởng
• Xác minh lượt cài đặt Infrastructure
• Xác minh lượt cài đặt k8s-repo
• Xác minh quá trình cài đặt Istio

FAST TRACK SCRIPT

Nếu bạn chọn phương thức này, hãy chạy tập lệnh sau để hoàn tất bài thực hành 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.

source ${HOME}/.bashrc

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

LƯU Ý QUAN TRỌNG: Nếu bạn đã hoàn thành kịch bản theo hướng dẫn nhanh cho bài thực hành 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ả các dự án của người dùng sẽ có tiền tố là tên người dùng, ví dụ: đối với người dùng [e-mail], mã dự án quản trị viên 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 chỉ có quyền truy cập vào môi trường hội thảo của riêng họ.

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

Hội thảo này được thiết kế để khởi động từ Cloud Shell. Bạn cần có những công cụ sau đây để tham gia hội thảo này.

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

• gcloud (phiên bản >= 270)
• kubectl
• sed (hoạt động với sed trên Cloud Shell/Linux và không hoạt động trên Mac OS)
• git (đảm bảo bạn đã cập nhật phiên bản mới nhất)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Truy cập vào 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 mỗi 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ị terraform được dùng để tạo phần còn lại của các tài nguyên GCP cần thiết cho hội thảo này. Tập lệnh setup-terraform-admin-project.sh cho phép các API bắt buộc trong dự án quản trị terraform. Cloud Build được dùng để áp dụng các kế hoạch Terraform. Thông qua tập lệnh này, bạn cấp cho tài khoản dịch vụ Cloud Build các vai trò IAM phù hợp để tài khoản này 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 Terraform cho tất cả tài nguyên GCP.

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

Hội thảo này được thiết kế để 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 chưa mở từ phần Thiết lập và chuẩn bị cho phòng thực hành) bằng cách nhấp vào đường liên kết bên dưới.

CLOUD SHELL

2. Cài đặt kustomize (nếu chưa cài đặt) trong thư mục $HOME/bin và 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à di chuyển pv đến $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 dấu nhắc bash.

cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
 

5. Xác minh rằng bạn đã đăng nhập vào gcloud bằng tài khoản người dùng mà bạn muố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 kết với hội thảo đều được lưu trữ dưới dạng các biến trong tệp vars.sh được lưu trữ trong một bộ chứa GCS trong 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 quá trình tạo đã 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 truy cập vào Bảng điều khiển Google Cloud lần đầu tiên, hãy đồng ý với Điều khoản dịch vụ của Google.

9. Bây giờ, khi bạn đang xem trang Cloud Build, hãy nhấp vào đường liên kết History trong trình đơn đ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ề lần áp dụng Terraform ban đầu. Các tài nguyên sau được tạo trong 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 được cung cấp sẽ được liên kết với từng dự án.
• 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.
• Một dự án là ops project dùng cho các cụm GKE của lớp điều khiển Istio.
• Hai dự án đại diện cho hai nhóm phát triển khác nhau đang làm việc trên các dịch vụ tương ứng.
• Hai cụm GKE được tạo trong mỗi dự án ops, dev1 và dev2.
• Một kho lưu trữ CSR có tên là k8s-repo được tạo, chứa 6 thư mục cho các tệp kê khai Kubernetes. Một thư mục cho mỗi cụm GKE. Kho lưu trữ này được dùng để triển khai các tệp kê khai Kubernetes cho các cụm theo kiểu GitOps.
• Một trình kích hoạt Cloud Build được tạo để bất cứ khi nào có một cam kết đối với nhánh chính của k8s-repo, trình kích hoạt này sẽ triển khai các tệp kê khai Kubernetes vào các cụm GKE từ các thư mục tương ứng.

Tập lệnh terraform mất từ 40 đến 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 trên dự án ops. Nhấp vào đường liên kết xuất hiện để mở trang Cloud Build cho ops project và xác minh rằng 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 quá trình 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à biến KUBECONFIG vào .bashrc trong Cloud Shell để biến này được lấy nguồn mỗi khi Cloud Shell 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ê các bối cảnh cụm từ. 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 quá trình cài đặt Istio

15. Đảm bảo bạn đã cài đặt Istio trên cả hai cụm bằng cách kiểm tra xem tất cả các nhóm đều đ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ỉ Citadel, sidecar-injector và coredns chạy trong các cụm dev1. Chúng dùng chung một controlplane Istio 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ỉ Citadel, sidecar-injector và coredns chạy trong các cụm dev2. Chúng dùng chung một controlplane Istio 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 tính năng khám phá dịch vụ cho các mặt phẳng điều khiển dùng chung

18. Bạn có thể xác minh rằng các khoá bí mật đã được triển khai.

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ẽ sử dụng một VPC dùng chung duy nhất để tạo tất cả các cụm GKE. Để khám phá các dịch vụ trên các cụm, bạn sử dụng tệp kubeconfig (cho từng cụm ứng dụng) được tạo dưới dạng các bí mật trong các cụm hoạt động. Pilot sử dụng các khoá bí mật này để khám phá các Dịch vụ bằng cách truy vấn máy chủ Kube API của các cụm ứng dụng (được xác thực thông qua các khoá 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 mã bí mật do kubeconfig tạo. Các cụm Ops có thể tự động phát hiện các dịch vụ bằng cách sử dụng tệp kubeconfig làm phương thức bí mật. Điều này đòi hỏi Pilot trong các cụm hoạt động phải có quyền truy cập vào máy chủ Kube API của tất cả các cụm khác. Nếu Pilot không thể truy cập vào các máy chủ Kube API, bạn sẽ phải thêm các dịch vụ từ xa dưới dạng ServiceEntries. Bạn có thể coi ServiceEntry là các mục DNS trong sổ đăng ký dịch vụ của bạn. ServiceEntry xác định một dịch vụ bằng cách sử dụng tên DNS đủ điều kiện ( FQDN) và địa chỉ IP mà dịch vụ đó 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ề Infrastructure Repo

Cơ sở hạ tầng Cloud Build

Các tài nguyên trên GCP cho hội thảo được tạo bằng Cloud Build và infrastructure kho lưu trữ CSR. Bạn vừa chạy một tập lệnh khởi động (nằm tại scripts/bootstrap_workshop.sh) trên thiết bị đầu cuối cục bộ. Tập lệnh khởi động sẽ tạo một thư mục GCP, một dự án quản trị terraform 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à tập lệnh linh tinh của Terraform. Thư mục này chứa infrastructure và k8s_repo CSR repo. Những 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ị terraform. Tài khoản dịch vụ Cloud Build trong dự án quản trị viên terraform được dùng để tạo 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á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 gcloud SDK, 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 từng tài nguyên. Tệp terraform của mỗi tài nguyên nằm 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 từng cái một và theo thứ tự mà chúng thường được tạo (ví dụ: dự án GCP được tạo trước khi các tài nguyên được tạo trong dự án). Vui lòng xem tệp cloudbuild.yaml để biết thêm thông tin chi tiết.

Cloud Build sẽ đượ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 đề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 với 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 thiết lập các tài nguyên cơ sở hạ tầng GCP cho hội thảo. Thư mục này đượ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 các tài nguyên cụ thể của GCP. Lớp thư mục tiếp theo đại diện cho environment cụ thể của nhóm (ví dụ: dev, stage, prod). 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 terraform bắt buộc nằm trong các thư mục tài nguyên.

Hội thảo này có 4 loại nhóm sau:

1. infrastructure – đạ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 các tài nguyên của mình. Bản thân kho lưu trữ cơ sở hạ tầng 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 một tập lệnh bash trong quá trình khởi động (xem Mô-đun 0 – Quy trình làm việc 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 GCP sau đây.
3. host project – đại diện cho dự án máy chủ VPC dùng chung.
4. shared VPC – biểu thị 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/devops. Họ sở hữu các tài nguyên sau.
6. ops project – đại diện cho một dự án cho tất cả cá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. Mặt phẳng điều khiển Istio được cài đặt trong mỗi cụm GKE ops.
8. k8s-repo – một kho lưu trữ CSR chứa các 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 các tài nguyên sau.
10. app projects – mỗi nhóm ứng dụng sẽ có một tập hợp dự án riêng. Nhờ đó, họ có thể kiểm soát việc thanh toán và IAM cho dự án cụ thể của mình.
11. gke clusters – đây là các cụm ứng dụng nơi các vùng chứa/Pod ứng dụng chạy.
12. gce instances – không bắt buộc, nếu họ có các ứng dụng chạy trên các phiên bản GCE. Trong hội thảo này, app1 có một số phiên bản GCE nơi một phần của ứng dụng chạy.

Trong hội thảo này, cùng một ứng dụng (ứng dụng cửa hàng Hipster) sẽ đạ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 được chia sẻ

Các trình cung cấp google và google-beta nằm tại gcp/[environment]/gcp/provider.tf. Tệp provider.tf được symlinked trong mọi thư mục tài nguyên. Nhờ đó, bạn có thể thay đổi nhà cung cấp ở một nơi thay vì quản lý riêng từng nhà cung cấp cho mỗi tài nguyên.

Mỗi tài nguyên đều 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 ở templates/backend.tf_tmpl) bằng một tập lệnh (nằm ở scripts/setup_terraform_admin_project), sau đó được đặt trong thư mục tài nguyên tương ứng. Bộ chứa Google Cloud Storage (GCS) được dùng cho các 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ả các phần phụ trợ tài nguyên đều nằm trong dự án quản trị terraform.

Các tài nguyên có giá trị phụ thuộc lẫn nhau 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 ở 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 biết mã dự án. Mã dự án được xuất thông qua output.tf vào tệp tfstate có thể dùng thông qua nguồn dữ liệu terraform_remote_state trong tài nguyên cụm GKE.

Tệp shared_state là một nguồn dữ liệu terraform_remote_state trỏ đến tệp tfstate của một tài nguyên. Tệp shared_state_[resource_name].tf (hoặc các tệp) tồn tại trong các thư mục tài nguyên cần có đầ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 từ tài nguyên ops_project và shared_vpc, vì bạn cần mã dự án và thông tin chi tiết về VPC để tạo các cụm GKE trong dự án ops. Các tệp shared_state được tạo từ một mẫu (nằm ở templates/shared_state.tf_tmpl) bằng một tập lệnh (nằm ở scripts/setup_terraform_admin_project). Tất cả các tệp shared_state của tài nguyên đều đượ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 tượng trưng các tệp đó vào các thư mục tài nguyên thích hợp giúp bạn dễ dàng quản lý tất cả các tệp trạng thái ở một nơi duy nhất.

Biến

Tất cả các giá trị tài nguyên đều được lưu trữ dưới dạng biến môi trường. Các 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 một bộ chứa GCS trong 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 xuống và lấy vars.sh từ bất kỳ thiết bị đầu cuối nào để nhận các 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ả các biến cùng với giá trị của chúng. Tệp variables.tfvars được tạo từ một tệp mẫu trong cùng thư mục bằng một 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. Công cụ này được 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 được tạo bởi cơ sở hạ tầng Cloud Build (xem phần trước để biết thông tin chi tiết). Trong quy trình xây dựng Cloud Build ban đầu của cơ sở hạ tầng, tổng cộng có 6 cụm GKE được tạo. Trong k8s_repo, 6 thư mục sẽ được tạo. Mỗi thư mục (tên trùng 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ư việc tạo cơ sở hạ tầng, Cloud Build được dùng để áp dụng các tệp kê khai Kubernetes cho tất cả các cụm GKE bằng k8s_repo. Cloud Build sẽ được kích hoạt bất cứ khi nào có một cam kết đối với kho lưu trữ k8s_repo. Tương tự như cơ sở hạ tầng, tất cả các tệp kê khai 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 tạo cơ sở hạ tầng ban đầu, k8s_repo sẽ được tạo và Istio sẽ được cài đặt trên tất cả các cụm.

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

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ấu trúc 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ẽ 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 riêng biệt và quản lý việc thanh toán ở cấp dự án. Ngoài ra, hạn mức cũng được quản lý ở cấp dự án.

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

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

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

Việc tách các công cụ quản trị/vận hành khỏi các cụm đang 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 sử dụng chúng, giúp bạn dễ dàng quản lý các quyền IAM.

Có tổng cộng 6 cụm GKE. Hai cụm hoạt động theo khu vực được tạo trong dự án hoạt động. Tầ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 ở một khu vực khác nhau. Ngoài ra, còn có 4 cụm ứng dụng theo khu vực. Các dự án này được tạo trong các 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ó 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 theo khu vực ở các khu vực khác nhau. Bốn 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 tính dự phòng theo khu vực và theo vùng.

Ứng dụng được 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 vi dịch vụ nằm trong không gian tên riêng trong mọi cụm ứng dụng. Các bản triển khai (Pod) ứng dụng cửa hàng Hipster không được triển khai trên các cụm ops. Tuy nhiên, không gian tên và tài nguyên Dịch vụ cho tất cả các vi dịch vụ cũng được tạo trong các cụm hoạt động. Mặt phẳng điều khiển ASM/Istio sử dụng các sổ đăng ký dịch vụ Kubernetes để khám phá dịch vụ. Nếu không có Dịch vụ (trong các cụm hoạt động), bạn sẽ phải tạo ServiceEntry theo cách thủ công cho từng dịch vụ đang chạy trong cụm ứng dụng.

Bạn triển khai một ứng dụng gồm 10 cấp độ vi dịch vụ 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 web có tên là "Hipster Shop", nơi người dùng có thể duyệt xem các mặt hàng, thêm mặt hàng vào giỏ hàng và mua hàng.

Tệp kê khai Kubernetes và k8s_repo

Bạn sử 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 tệp kê khai Kubernetes và cam kết với k8s_repo. Tất cả các cam kết đối với k8s_repo đều kích hoạt một công việc Cloud Build để triển khai các 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 biệt có tên giống như 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 ở vùng 1, khu vực a
4. gke-2-apps-r1b-prod – cụm ứng dụng ở vùng 1, khu vực b
5. gke-3-apps-r2a-prod – cụm ứng dụng ở vùng 2, khu vực a
6. gke-4-apps-r2b-prod – cụm ứng dụng ở vùng 2, khu vực 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 đặt 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 mỗi cụm được đặt trong các 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 thông tin chi tiết.

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

Mục tiêu: Triển khai ứng dụng Hipster Shop trên các 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ác cụm ứng dụng
• Tạo các dịch vụ cho ứng dụng Hipster shop 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 trên toàn cầu
• Xác minh khả năng kết nối an toàn với ứng dụng Hipster Shop

FAST TRACK SCRIPT

Nếu bạn chọn phương thức này, hãy chạy tập lệnh sau để hoàn tất bài thực hành này.

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

Nếu bạn đã hoàn thành tập lệnh theo hướng dẫn nhanh cho lớp học này, thì đừng thực hiện phương thức sao chép và dán bên dưới**.**

Sao chép kho lưu trữ nguồn dự án ops

Trong quá trình tạo cơ sở hạ tầng Terraform ban đầu, k8s-repo đã được tạo trong dự án ops.

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

mkdir $WORKDIR/k8s-repo
 

2. Khởi động kho lưu trữ git, thêm kho lưu trữ từ xa và kéo nhánh 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ộ.

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 kustomization.yaml của thư mục ứng dụng 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á việc triển khai cartservice, rbac và podsecuritypolicy khỏi tất cả các cụm phát triển, trừ một cụm. Hipstershop không được xây dựng để triển khai nhiều cụm, vì vậy, để tránh kết quả không nhất quán, chúng ta chỉ sử dụng một cartservice.

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

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

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

8. Chỉ thêm việc triển khai cartservice, rbac và podsecuritypolicy vào kustomization.yaml trong cụm 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, các thư mục triển khai và rbac khỏi ops clusters kustomization.yaml

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

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 các tài nguyên Config Connector vào một trong các cụm trong 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 Config Connector.

sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
 

14. Sao chép loadgenerator tệp kê khai (Triển khai, PodSecurityPolicy và RBAC) vào các cụm hoạt động. Ứng dụng cửa hàng Hipster được hiển thị bằng cách sử dụng Trình cân bằng tải Google Cloud (GCLB) trên toàn cầu. GCLB nhận lưu lượng truy cập của máy khách (dành cho frontend) và gửi lưu lượng truy cập đó đến phiên bản gần nhất của Dịch vụ. Việc đặt loadgenerator trên cả hai cụm ops sẽ đảm bảo lưu lượng truy cập được gửi đến cả hai cổng Istio Ingress đang chạy trong các cụm ops. 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 ops trong tệp kê khai loadgenerator cho cả hai cụm ops.

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

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 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 Cloud Build cho dự án Ops 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 việc triển khai ứng dụng

19. Xác minh rằng các pod trong tất cả không gian tên ứng dụng (ngoại trừ giỏ hàng) đều ở trạng thái Đang chạy trong tất cả các cụm 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 pod trong không gian tên giỏ hàng đang ở trạng thái Đang chạy chỉ trong cụm 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 trên toàn cầu

Giờ đây, bạ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 ở 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 để chuyển lưu lượng truy cập của ứng dụng khách đến cả 4 phiên bản của dịch vụ frontend.

Cổng Istio Ingress chỉ chạy trong các cụm hoạt động và đóng vai trò là bộ 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 các dịch vụ phụ trợ cho dịch vụ giao diện người dùng toàn cầu. Các cổng Istio Ingress nhận lưu lượng truy cập của ứng dụng khách từ GCLB, sau đó gửi lưu lượng truy cập của ứng dụng khách đến các Pod giao diện người dùng đang chạy trong các cụm ứng dụng.

Ngoài ra, bạn có thể đặt các cổng Istio Ingress trực tiếp 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 GKE Autoneg

Dịch vụ Kubernetes của cổng Istio Ingress tự đăng ký làm một phần phụ trợ cho GCLB bằng cách sử dụng Nhóm điểm 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. NEG được tạo thông qua một chú thích đặc biệt trên một Dịch vụ Kubernetes, vì vậy, NEG có thể tự đăng ký với Trình điều khiển NEG. Bộ điều khiển Autoneg là một bộ điều khiển đặc biệt của GKE, tự động hoá việc tạo NEG cũng như chỉ định chúng làm phần phụ trợ cho GCLB bằng cách sử dụng chú thích Dịch vụ. Các mặt phẳng điều khiển Istio, bao gồm cả các cổng vào Istio, được triển khai trong quá trình tạo cơ sở hạ tầng ban đầu bằng Terraform Cloud. Cấu hình GCLB và autoneg được thực hiện trong quá trình Cloud Build cơ sở hạ tầng Terraform ban đầu.

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

Chứng chỉ do GCP quản lý được dùng để bảo mật lưu lượng truy cập của ứng dụng đến dịch vụ frontend GCLB. GCLB sử dụng chứng chỉ được quản lý cho dịch vụ frontend trên toàn cầu và chứng chỉ này sẽ kết thúc tại GCLB. Trong hội thảo này, bạn sẽ sử dụng Cloud Endpoints làm miền cho 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 chứng chỉ do GCP quản lý.

21. Để truy cập vào cửa hàng Hipster, hãy nhấp vào đường liên kết đầu ra 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 tính năng cân bằng tải trên toàn cầu

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 kiểm thử đến đường liên kết GCLB Hipster shop Cloud Endpoints. Xác minh rằng GCLB đang nhận lưu lượng truy cập và gửi đến cả hai cổng Istio Ingress.

23. Lấy đường liên kết GCLB > Monitoring (GCLB > Giám sát) cho dự án hoạt động nơi GCLB của cửa hàng Hipster được tạo.

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ả cá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 ý lưu lượng truy cập đến cả istio-ingressgateways.

Có 3 NEG được tạo cho mỗi istio-ingressgateway. Vì các cụm hoạt động là 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, các Pod 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ị khi đi đến istio-ingressgateway Pods.

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

8. Khả năng ghi nhận bằng Stackdriver

Mục tiêu: Kết nối số 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 về Dịch vụ Istio
• Xem nhật ký vùng chứa
• Xem tính năng theo dõi phân tán trong Stackdriver

FAST TRACK SCRIPT

Nếu bạn chọn phương thức này, hãy chạy tập lệnh sau để hoàn tất bài thực hành này.

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

Nếu bạn đã hoàn thành tập lệnh theo hướng dẫn nhanh cho lớp học này, thì đừng thực hiện phương thức 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 ghi nhận ("o11y") được tích hợp sẵn. Đ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, các toán tử vẫn có thể quan sát lưu lượng truy cập ra vào các vùng chứa này, cung cấp dịch vụ cho khách hàng. Hoạt động quan sát này có một số phương thức: chỉ số, nhật ký và dấu vết.

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

1. Cài đặt tệp cấu hình istio vào 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. Commit vào k8s-repo.

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

3. Xem trạng thái của Cloud Build cho dự án Ops 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 việc tích hợp Istio → Stackdriver Lấy CRD của Trình xử lý Stackdriver.

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

Đầu ra sẽ cho thấy 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 tính năng xuất chỉ số Istio sang Stackdriver đang hoạt động. Nhấp vào đường liên kết được xuất ra từ lệnh này:

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 Workspace mới, được đặt tên theo dự án Ops, chỉ cần chọn OK. Nếu hệ thống nhắc bạn về giao diện người dùng mới, hãy đóng hộp thoại.

Trong Trình khám phá chỉ số, trong mục "Tìm chỉ số và kiểu tài nguyên", hãy nhập "istio" để xem các lựa chọn như "Số lượng yêu cầu của máy chủ" trên kiểu tài nguyên "Kubernetes Container". Điều này cho thấy các chỉ số đang truyề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ực quan hoá các chỉ số bằng Trang tổng quan:

Giờ đây, khi các chỉ số của chúng ta đã có trong hệ thống Stackdriver APM, chúng ta cần một cách để trực quan hoá các chỉ số đó. 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 số 4 "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à thứ 50) và Lỗi (chúng ta sẽ loại trừ Độ bão hoà trong ví dụ này).

Envoy proxy của Istio cung cấp cho chúng ta một số chỉ số, nhưng đây là một nhóm chỉ số phù hợp để bắt đầu. (danh sách đầy đủ có tại đây). Xin lưu ý rằng mỗi chỉ số đều có một nhóm nhãn có thể dùng để lọc, tổng hợp, chẳng hạn như: destination_service, source_workload_namespace, 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ố được tạo sẵn. Chúng ta sẽ sử dụng trực tiếp Dashboard API. Đây là việc mà bạn thường không làm bằng cách tạo lệnh gọi API theo cách thủ công, mà sẽ là một phần của hệ thống tự động hoá 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 bắt đầu nhanh chóng:

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

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 UX, nhưng 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 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 nội dung chỉnh sửa rồi đẩy nội dung đó lên lại bằng phương thức HTTP PATCH.

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

Hãy thử chỉnh sửa trang tổng quan mà bạn vừa nhận được, thêm một khổ thơ 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 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 nhật ký đó lên Stackdriver Logging để cho phép phân tích trên nhiều cụm trong 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à accesslog 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ý của lớp điều khiển Istio bằng cách chọn Resource > Kubernetes Container (Tài nguyên > Vùng chứa Kubernetes) rồi tìm kiếm "pilot" –

Ở đây, chúng ta có thể thấy Istio Control Plane đẩy cấu hình proxy đến các proxy phụ 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 nhật ký vùng chứa cũng như nhật ký cơ sở hạ tầng hoặc nhật ký dịch vụ GCP khác trong cùng một giao diện. Sau đây là một số truy vấn nhật ký mẫu cho GKE. Trình xem nhật ký cũng cho phép bạn tạo chỉ số từ nhật ký (ví dụ: "đếm mọi lỗi khớp với một chuỗi nào đó") mà bạn có thể sử dụng trên trang tổng quan hoặc làm một phần của cảnh báo. Bạn cũng có thể truyền trực tuyến nhật ký sang các công cụ phân tích khác, chẳng hạn 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. Hãy xem Distributed Traces.

Giờ đây, khi bạn đang làm việc với một hệ thống phân tán, việc gỡ lỗi cần một công cụ mới: Theo dõi phân tán. Công cụ này giú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 bất thường trong hình bên dưới), cũng như tìm hiểu sâu về các dấu vết mẫu thô để điều tra chi tiết về những gì thực sự đang diễn ra.

Chế độ xem dòng thời gian cho thấy tất cả các yêu cầu theo thời gian, được vẽ đồ thị theo độ trễ hoặc thời gian đã trôi qua giữa yêu cầu ban đầu, thông qua ngăn xếp Hipster, cho đến khi phản hồi cuối cùng cho người dùng cuối. Các dấu chấm càng ở trên thì trải nghiệm của người dùng càng chậm (và càng không hài lòng!).

Bạn có thể nhấp vào một dấu chấm để xem Chế độ xem thác nước chi tiết của yêu cầu cụ thể đó. Khả năng tìm thấy thông tin chi tiết 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 để hiểu được sự tương tác giữa các dịch vụ, đặc biệt là khi tìm ra nhữ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 sẽ quen thuộc với bất kỳ ai đã sử dụng trình gỡ lỗi, nhưng trong trường hợp này, thay vì cho biết thời gian đã dành cho các quy trình khác nhau của một ứng dụng duy nhất, chế độ xem này cho biết thời gian đã dành cho việc di chuyển qua lưới của chúng tôi, 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 các 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 hai chiều

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

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

FAST TRACK SCRIPT

Nếu bạn chọn phương thức này, hãy chạy tập lệnh sau để hoàn tất bài thực hành này.

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

Nếu bạn đã hoàn thành tập lệnh theo hướng dẫn nhanh cho lớp học này, thì đừng thực hiện phương thức sao chép và dán bên dưới**.**

Giờ đây, khi các ứng dụng đã được cài đặt và Khả năng quan sát đã được thiết lập, 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 rằng các kết nối này vẫn hoạt động.

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

1. Kiểm tra MeshPolicy trong các cụm ops. Lưu ý rằng 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, sử dụng tài nguyên tuỳ chỉnh (CR) IstioControlPlane. Chúng tôi sẽ định cấu hình mTLS trong tất cả các cụm bằng cách cập nhật CR IstioControlPlane và cập nhật k8s-repo. Việc đặt global > mTLS > enabled: true trong IstioControlPlane CR sẽ dẫn đến 2 thay đổi sau đây đối với mặt phẳng điều khiển Istio:

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

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

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

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

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

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

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

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

3. Commit vào k8s-repo.

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

4. Xem trạng thái của Cloud Build cho dự án Ops 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. Lưu ý: mTLS không còn là PERMISSIVE nữa 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
 

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

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

6. Mô tả DestinationRule do bộ điều khiển của 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'

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

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

Chúng tôi 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ý rồi 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, hãy nhấp vào "http" bên cạnh "protocol:

Điều này giúp bạn hình dung rõ ràng quá trình chuyển đổi.

10. Triển khai Canary

Mục tiêu: Triển khai phiên bản mới của Dịch vụ giao diện người dùng.

• Phát hành 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 để chuyển hướng lưu lượng truy cập từ từ đến frontend-v2
• Xác minh quy trình triển khai GitOps bằng cách kiểm tra chuỗi cam kết đối với k8s-repo

FAST TRACK SCRIPT

Nếu bạn chọn phương thức này, hãy chạy tập lệnh sau để hoàn tất bài thực hành này.

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

Nếu bạn đã hoàn thành tập lệnh theo hướng dẫn nhanh cho lớp học này, thì đừng thực hiện phương thức sao chép và dán bên dưới**.**

Triển khai theo giai đoạn là quá trình triển khai từng bước một dịch vụ mới. Trong quá trình triển khai canary, bạn sẽ gửi một lượng lưu lượng truy cập ngày càng tăng đến phiên bản mới, đồng thời vẫn gửi phần trăm còn lại đến phiên bản hiện tại. Một mẫu hình phổ biến là thực hiện phân tích thử nghiệm 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 quan trọng" của phiên bản mới (độ trễ, tỷ lệ lỗi, độ bão hoà) với một đường cơ sở. Điều này giúp ngăn chặn tình trạng ngừng hoạt động và đảm bảo tính ổn định của dịch vụ "v2" mới ở mọi giai đoạn phân chia lưu lượng truy cập.

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

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

Lưu ý: chúng ta sẽ kích hoạt quy trình Canary theo cách thủ công ở cả hai khu vực, nhưng trong quá trình sản xuất, bạn sẽ sử dụng một 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 một 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 sẽ được sao chép:

• Việc triển khai frontend-v2
• Bản vá frontend-v1 (để thêm nhãn "v1" và hình ảnh có điểm cuối "/version")
• respy, một nhóm nhỏ sẽ in bản phân phối phản hồi HTTP và giúp chúng tôi hình dung việc triển khai canary theo thời gian thực.
• Istio DestinationRule của giao diện người dùng – chia Dịch vụ Kubernetes của giao diện người dùng thành 2 tập hợp con, v1 và v2, dựa trên nhãn triển khai "version"
• Istio VirtualService trên giao diện người dùng – đị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 mặc định luân phiên của Dịch vụ Kubernetes. Theo đó, 50% tổng lưu lượng truy cập theo khu vực Dev1 sẽ được gửi ngay đến giao diện người dùng phiên bản 2.

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 Cloud Build cho dự án Ops 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. Đợi quy trình Cloud Build hoàn tất, sau đó lấy các nhóm trong không gian tên giao diện người dùng ở 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 ý: Nhấn tổ hợp phím Ctrl-C để thoát khỏi các lệnh theo dõi

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 để theo dõi việc 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 để chia 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 đều chuyển đến việc triển khai giao diện người dùng phiên bản 1, đượ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 frontend-v2 trong VirtualService (cập nhật trọng số thành 20%, 50%, 80%, sau đó là 100%). Giữa các lần 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 thử nghiệm cho khu vực Dev1. Lưu ý: bạn sẽ mất khoảng 10 phút để hoàn thành 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 tính năng phân chia 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 triển khai Dev2 hoàn tất cho frontend-v2, bạn sẽ thấy một 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. Tất cả lưu lượng truy cập từ giao diện người dùng của một nhóm Dev2 sẽ chuyển đến frontend-v2:

    Output (do not copy) 
   

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

10. Đóng ngăn chia.

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

11. Chuyển đến Cloud Source Repos theo đườ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, với cam kết gần đây nhất ở đầu danh sách:

Bây giờ, bạn sẽ lặp lại quy trình tương tự cho khu vực Dev2. Xin 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ơ bản, chúng tôi đã đẩy một VirtualService để gửi rõ ràng tất cả lưu lượng truy cập đến v1. Bằng cách này, chúng tôi có thể thực hiện một cách an toàn quy trình phát hành thử nghiệm theo khu vực trên Dev1 và đảm bảo quy trình này chạy thành công trước khi triển khai phiên bản mới trên toàn cầu.

12. Chạy lệnh để chia 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 đều chuyển đến việc triển khai giao diện người dùng phiên bản 1, đượ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 frontend-v2 trong VirtualService (cập nhật trọng số thành 20%, 50%, 80%, sau đó là 100%). Giữa các lần 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 thử nghiệm cho khu vực Dev1. Lưu ý: bạn sẽ mất khoảng 10 phút để hoàn thành 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, hãy theo dõi lưu lượng truy cập từ các nhóm Dev2 di chuyển dần từ giao diện người dùng phiên bản 1 sang phiên bản 2. 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 chia.

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

Phần này giới thiệu cách sử dụng Istio cho việc triển khai thử nghiệm theo khu vực. Trong quá trình sản xuất, thay vì sử dụng tập lệnh thủ công, bạn có thể tự động kích hoạt tập lệnh thử nghiệm này dưới dạng một quy trình Cloud Build, bằng cách sử dụng một trình kích hoạt như hình ảnh được gắn thẻ mới được đẩy vào một sổ đăng ký vùng chứa. Bạn cũng nên thêm quy trình phân tích thử nghiệm trong mỗi bước, phân tích độ trễ và tỷ lệ lỗi của phiên bản 2 so với ngưỡng an toàn được 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 vi dịch vụ (AuthZ).

• Tạo AuthorizationPolicy để TỪ CHỐI quyền truy cập vào một vi dịch vụ
• Tạo AuthorizationPolicy để CHO PHÉP quyền truy cập cụ thể vào một vi dịch vụ

FAST TRACK SCRIPT

Nếu bạn chọn phương thức này, hãy chạy tập lệnh sau để hoàn tất bài thực hành này.

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

Nếu bạn đã hoàn thành tập lệnh theo hướng dẫn nhanh cho lớp học này, thì đừng thực hiện phương thức 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ể đang chạy ở một nơi, các ứng dụng vi dịch vụ được phân phối trên toàn cầu sẽ thực hiện các lệnh gọi trên các ranh giới mạng. Điều này có nghĩa là ứng dụng của bạn sẽ có nhiều điểm xâm nhập hơn và nhiều cơ hội hơn cho các cuộc tấn công độc hại. 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 quyền truy cập giữa các khối lượng công việc. Trong cấu trúc vi dịch vụ, bạn cần có một phương pháp bảo mật mới. Dựa trên các khối 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 các ứng dụng của bạn.

Các chính sách của Istio bao gồm cả 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à người mà họ nói không?), còn uỷ quyền xác minh quyền (khách hàng này có được phép làm việc đó không?). Chúng ta đã đề cập đến hoạt động xác thực Istio trong phần TLS tương hỗ ở 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 các khối lượng công việc của ứng dụng, đó là currencyservice.

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

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 currencyservice. Lưu ý rằng 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 về đơn vị tiền tệ vào k8s-repo 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 các 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 Cloud Build cho dự án Ops 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 bản dựng hoàn tất thành công, hãy thử truy cập vào giao diện người dùng của 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 cùng tìm hiểu cách dịch vụ tiền tệ thực thi AuthorizationPolicy 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 tiền tệ, vì theo mặc định, các lệnh gọi uỷ quyền bị chặn sẽ không được ghi nhật ký.

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. Nhận nhật ký RBAC (uỷ quyền) từ proxy phụ của dịch vụ tiền tệ. Bạn sẽ thấy thông báo "enforced denied" (bị từ chối bắt buộc), cho biết currencyservice được thiết lập để chặn tất cả cá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 (nhưng không cho phép các dịch vụ phụ trợ khác) truy cập vào currencyservice. Mở currency-allow-frontend.yaml rồi kiểm tra nội dung của tệp này. 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 ta đang đưa 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ệ. source.principal 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 ta đang đư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 AuthorizationPolicies, trước tiên, bạn phải bật TLS hai chiều trên toàn bộ cụm, như chúng ta đã làm trong Mô-đun 1. Điều này là để đảm bảo rằng thông tin xác thực tài khoản dịch vụ được gắn vào các yêu cầu.

9. Sao chép chính sách mới về đơn vị tiền 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 các 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 Cloud Build cho dự án Ops 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 hoàn tất thành công, hãy mở lại giao diện người dùng Hipstershop. Lần này, bạn sẽ không thấy lỗi nào trên trang chủ vì giao diện người dùng được phép truy cập vào dịch vụ hiện tại một cách rõ ràng.
13. Bây giờ, hãy thử thực hiện quy trình thanh toán bằng cách thêm các mặt hàng vào giỏ hàng rồi 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ụ tiền tệ – điều này là do chúng ta chỉ đưa giao diện người dùng vào danh sách cho phép, nên checkoutservice vẫn không thể truy cập vào currencyservice.

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 AuthorizationPolicy của currencyservice. Xin lưu ý rằng chúng tôi chỉ mở quyền truy cập vào đơn vị tiền tệ cho 2 dịch vụ cần truy cập vào đơn vị tiền tệ – giao diện người dùng và quy trình thanh toán. Các máy chủ phụ trợ khác vẫn sẽ bị chặn.
15. Mở currency-allow-frontend-checkout.yaml rồi kiểm tra nội dung của tệp này. Xin lưu ý rằng danh sách quy tắc hoạt động như một điều kiện OR logic – đơn vị tiền tệ sẽ chỉ chấp nhận các yêu cầu từ những tải 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 cuối 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 Cloud Build cho dự án Ops 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 bản dựng hoàn tất thành công, hãy thử thực hiện 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 quyền kiểm soát truy cập chi tiết ở cấp độ từng dịch vụ. Trong quá trình sản xuất, bạn có thể tạo một AuthorizationPolicy cho mỗi dịch vụ và (ví dụ) sử dụng chính sách cho phép tất cả để cho phép tất cả các tải trọng trong cùng một không gian tên truy cập lẫn nhau.

12. Điều chỉnh quy mô 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 khu vực, dự án và cụm mới.

• Sao chép kho lưu trữ infrastructure
• Cập nhật các tệp terraform để tạo tài nguyên mới
• 2 mạng con trong khu vực mới (một cho dự án ops và một cho dự án mới)
• Cụm hoạt động mới ở khu vực mới (trong mạng con mới)
• Mặt phẳng đ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 với kho lưu trữ infrastructure
• Xác minh cài đặt

FAST TRACK SCRIPT

Nếu bạn chọn phương thức này, hãy chạy tập lệnh sau để hoàn tất bài thực hành này.

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

Nếu bạn đã hoàn thành tập lệnh theo hướng dẫn nhanh cho lớp học này, thì đừng thực hiện phương thức sao chép và dán bên dưới**.**

Có một số cách để mở rộng quy mô nền tảng. Bạn có thể thêm nhiều tài nguyên điện toán hơn bằng cách thêm các nút vào các cụm hiện có. Bạn có thể thêm nhiều cụm hơn trong một khu vực. Hoặc bạn có thể thêm nhiều khu vực vào nền tảng. Quyết định về khía cạnh nào của nền tảng cần mở rộng quy mô sẽ phụ thuộc vào các yêu cầu. Ví dụ: nếu bạn có các cụm trong cả 3 vùng của một khu vực, thì có lẽ việc thêm nhiều nút (hoặc nhóm nút) vào cụm hiện có là đủ. Tuy nhiên, nếu bạn có các cụm trong 2 trong số 3 vùng ở một khu vực duy nhất, thì việc thêm một cụm mới vào vùng thứ ba sẽ giúp bạn mở rộng quy mô và có thêm một miền lỗi (tức là một vùng mới). Một lý do khác để thêm một cụm mới vào một khu vực có thể là nhu cầu tạo một cụm đơn người thuê – vì lý do pháp lý hoặc tuân thủ (ví dụ: PCI hoặc một cụm cơ sở dữ liệu lưu trữ 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ể tránh khỏi để 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 khu vực và các 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 mỗi khu vực bằng cách thêm nhiều tài nguyên điện toán hơn. Việc này được thực hiện bằng cách thêm nhiều nút (hoặc nhóm nút) vào các cụm hiện có hoặc bằng cách thêm các cụm mới trong khu vực. 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 các mạng con (và dải thứ cấp), 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 điều khiển lưới dịch vụ ASM/Istio theo khu vực và triển khai tài nguyên ứng dụng vào 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 cung cấp cho bạn một mẫu theo khu vực. Cấu trúc này bao gồm một cụm hoạt động theo khu vực nơi đặt ASM/Istio và hai (hoặc nhiều) cụm ứng dụng theo vùng nơi triển khai các tài nguyên ứng dụng.

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ền tảng này cũng bao gồm các bước của trường hợp sử dụng theo chiều dọc. Để mở rộng nền tảng theo chiều ngang bằng cách thêm một khu vực mới (r3) vào nền tảng, bạn cần thêm các tài nguyên sau:

1. Mạng con trong VPC dùng chung của dự án lưu trữ ở khu vực r3 cho các cụm ứng dụng và hoạt động mới.
2. Một cụm hoạt động theo khu vực ở khu vực r3, nơi đặt tầng điều khiển ASM/Istio.
3. Hai cụm ứng dụng theo khu vực trong hai khu vực trên vùng r3.
4. Cập nhật k8s-repo:
5. Triển khai các tài nguyên của tầng điều khiển ASM/Istio vào cụm hoạt động trong khu vực r3.
6. Triển khai các tài nguyên tầ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 này sẽ minh hoạ cách thêm một dự án mới (dev3) để đề cập đến trường hợp sử dụng là thêm một 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 như đã nêu ở trên.

1. Trong Cloud Shell, hãy chuyển đến WORKDIR rồi 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 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 được chia sẻ 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à đẩy 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. Lệnh cam kết sẽ 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 Cloud Build bằng cách nhấp vào đầu ra của đường liên kết sau 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 mất từ 25 đến 30 phút để hoàn tất. Đây là thời điểm thích hợp để nghỉ giải lao.

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

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

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ê các bối cảnh cụm từ. 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 quá trình 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 xem tất cả các nhóm đều đang chạy và các 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ỉ Citadel, sidecar-injector và coredns chạy trong các cụm dev3. Chúng dùng chung một controlplane Istio 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 tính năng khám phá dịch vụ cho các mặt phẳng điều khiển dùng chung

14. Xác minh rằng các khoá bí mật được triển khai trong tất cả các cụm hoạt động cho 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 một Circuit Breaker cho dịch vụ vận chuyển.

• Tạo một DestinationRule cho Dịch vụ shipping để triển khai một 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 ngắt mạch

Hướng dẫn về Fast Track Script Lab

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

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

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

Mẫu Cầu dao được đặt tên theo một công tắc điện có thể "ngắt" khi có quá nhiều điện chạy qua, giúp bảo vệ các thiết bị khỏi tình trạng quá tải. Trong thiết lập Istio, điều này có nghĩa là Envoy là bộ ngắt mạch, 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 sẽ truyền qua Envoy mà không bị gián đoạn.

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

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

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

Bạn có thể xác định các chính sách Ngắt mạch bằng Istio DestinationRules. Trong phần này, chúng ta sẽ áp dụng chính sách sau để thực thi một cầu dao cho 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 outlierDetection 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, cứ mỗi giây (khoảng thời gian), Envoy sẽ đếm số lỗi mà vùng chứa phía máy chủ nhận được. Nếu vượt quá ngưỡng consecutiveErrors, cầu dao Envoy sẽ mở và 100% các nhóm productcatalog sẽ được bảo vệ khỏi các yêu cầu mới của máy khách trong 10 giây. Sau khi cầu dao Envoy mở (tức là đang hoạt động), các ứng dụng sẽ nhận được lỗi 503 (Service Unavailable). Hãy xem ví dụ thực tế.

1. Đặt 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 k8s-repo

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

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

4. Sao chép một pod trình tạo tải Fortio vào cụm GKE_1 trong khu vực Dev1. Đây là nhóm máy khách mà chúng ta sẽ dùng để "kích hoạt" cầu dao cho shippingservice.

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

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 dùng pod fortio để gửi lưu lượng truy cập gRPC đến shippingservice với 1 kết nối đồng thời, tổng cộng 1000 yêu cầu – thao tác này sẽ không kích hoạt bộ ngắt mạch 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 vẫn giữ nguyên tổng số yêu cầu. Chúng ta sẽ thấy tối đa 2/3 số yêu cầu trả về lỗi"tràn" , vì cầu dao đã được kích hoạt: trong chính sách mà chúng ta 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 mà nó đã ngắt khi cầu dao đang hoạt động, bằng chỉ số upstream_rq_pending_overflow. Hãy tìm thông tin này trong pod 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. 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 một chính sách 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ụ thượng nguồn (phụ trợ) có khả năng bị treo. Bằng cách áp dụng các chính sách về bộ ngắt mạch Istio, bạn có thể giúp cô lập các vi dịch vụ, tích hợp khả năng chịu lỗi vào cấu trúc và giảm nguy cơ xảy ra lỗi liên tiếp khi tải cao.

14. Chèn lỗi

Mục tiêu: Kiểm thử khả năng phục hồi của Dịch vụ đề xuất bằng cách đưa ra các độ trễ (trước khi đẩy sang giai đoạn phát hành công khai).

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

Hướng dẫn về Fast Track Script Lab

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

Hướng dẫn về phòng thực hành theo phương thức sao chép và dán

Thêm các chính sách về cầu dao vào dịch vụ của bạn là một cách để tăng khả năng phục hồi trước các dịch vụ trong quá trình sản xuất. Nhưng việc ngắt mạch sẽ dẫn đến lỗi (có thể là lỗi mà người dùng gặp phải), điều này không lý tưởng. Để tránh những trường hợp lỗi này và dự đoán chính xác hơn cách các dịch vụ hạ nguồn có thể phản hồi khi các dịch vụ phụ trợ trả về lỗi, bạn có thể áp dụng thử nghiệm hỗn loạn trong môi trường dàn dựng. Kiểm thử hỗn loạn là phương pháp cố ý làm gián đoạn các dịch vụ của bạn để phân tích các đ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ử hỗn loạn để xác định các cách giảm thiểu lỗi mà người dùng gặp phải khi các phần phụ trợ gặp lỗi – 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 phát hành sản xuất và thêm lỗi ở lớp mạng thay vì sửa đổi mã nguồn. Trong quá trình sản xuất, bạn có thể sử dụng một công cụ kiểm thử sự cố hoàn chỉnh để kiểm thử khả năng phục hồi ở lớp Kubernetes/điện toán ngoài lớp mạng.

Bạn có thể sử dụng Istio để kiểm thử sự cố bằng cách áp dụng một VirtualService với trường "fault". Istio hỗ trợ 2 loại lỗi: lỗi trễ (chèn thời gian chờ) và lỗi huỷ (chèn lỗi HTTP). Trong ví dụ này, chúng ta sẽ chèn một lỗi trễ 5 giây vào dịch vụ đề xuất. Nhưng lần này, thay vì sử dụng một cầu dao để "thất bại nhanh" đối với dịch vụ bị treo này, chúng ta sẽ buộc các dịch vụ hạ nguồn phải chịu đựng toàn bộ 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. Xin lưu ý rằng Istio có một lựa chọn để chèn lỗi vào một tỷ lệ phần trăm yêu cầu – ở đây, chúng ta sẽ đưa ra thời gian chờ cho tất cả các yêu cầu recommendationservice.

Đầ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ẽ chèn lỗi trên toàn cầu, ở 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 thi vào pod fortio được triển khai trong phần cầu dao, rồi gửi một số lưu lượng truy cập đến recommendationservice.

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

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

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

Đầ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 ta đã chèn vào hoạt động 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 xuất hiện ở 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 Ops.

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

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

19. Đẩy các thay đổi:

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

15. Giám sát Tầng điều khiển Istio

ASM cài đặt 4 thành phần quan trọng của lớp điều khiển: Pilot, Mixer, Galley và Citadel. Mỗi dịch vụ sẽ gửi các chỉ số giám sát có liên quan đến Prometheus và ASM đi kèm với trang tổng quan Grafana cho phép người vận hành hình dung dữ liệu giám sát này và đánh giá tình trạng cũng như hiệu suất của lớp điều khiển.

Xem trang tổng quan

20. Chuyển tiếp cổng dịch vụ Grafana đã cài đặt bằng 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 biểu tượng "Xem trước trên web" ở góc trên cùng bên phải của cửa sổ Cloud Shell
23. Nhấp vào Preview on port 3000 (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 change port (thay đổi cổng) rồi chọn cổng 3000)
24. Thao tác này sẽ mở một thẻ trong trình duyệt của bạn bằng một URL tương tự như " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Xem các trang tổng quan có sẵn
26. Sửa đổi URL thành " BASE_URL/dashboard"
27. Nhấp vào thư mục "istio" để xem các trang tổng quan hiện có
28. Nhấp vào một trong các trang tổng quan đó để 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.

Chương trình giám sát thử nghiệm

Pilot là thành phần của lớp kiểm soát, phân phối cấu hình mạng và chính sách cho lớp dữ liệu (các proxy Envoy). Pilot có xu hướng mở rộng quy mô theo số lượng khối lượng công việc và việc triển khai, mặc dù không nhất thiết phải theo lượng lưu lượng truy cập vào các khối lượng công việc đó. Một phi công không đủ sức khoẻ 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 việc đẩy thông tin cấu hình đã cập nhật đến Envoy bị chậm trễ

Lưu ý: nếu Pilot ngừng hoạt động hoặc nếu có sự chậm trễ, thì các 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. Chuyển đến " BASE_URL/dashboard/db/istio-pilot-dashboard" trong trình duyệt để xem các chỉ số của Pilot.

Các chỉ số quan trọng cần theo dõi

Mức sử dụng tài nguyên

Hãy sử dụng trang Hiệu suất và khả năng mở rộng của Istio làm hướng dẫn cho các số liệu sử dụng có thể 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 duy trì cao hơn đáng kể so với mức này.

Thông tin về thông báo đẩy trong giai đoạn thí điểm

Phần này theo dõi các lần đẩy cấu hình của Pilot đến các proxy Envoy.

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

Nếu có Lỗi hoặc Xung đột, tức là bạn có cấu hình không chính xác hoặc không nhất quán cho một hoặc nhiều dịch vụ. Hãy xem phần Khắc phục sự cố về lớp dữ liệu để biết thông tin.

Thông tin về Envoy

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. Hãy liên hệ với nhóm hỗ trợ GCP nếu bạn thấy lỗi Kết nối XDS nhiều lần.

Bàn trộn âm thanh giám sát

Mixer là thành phần chuyển hướng dữ liệu đo từ xa từ các proxy Envoy đến các phần phụ trợ đo từ xa (thường là Prometheus, Stackdriver, v.v.). Trong khả năng này, nó không nằm trong lớp dữ liệu. Thành phần này được triển khai dưới dạng 2 Kubernetes Jobs (gọi là Mixer) đượ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ể dùng Mixer để tích hợp với các hệ thống chính sách. Trong trường hợp này, Mixer có ảnh hưởng đến lớp dữ liệu, vì các lượt kiểm tra chính sách đối với Mixer không thành công sẽ 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. Chuyển đến " BASE_URL/dashboard/db/istio-mixer-dashboard" trong trình duyệt để xem các chỉ số của Mixer.

Các chỉ số quan trọng cần theo dõi

Mức sử dụng tài nguyên

Hãy sử dụng trang Hiệu suất và khả năng mở rộng của Istio làm hướng dẫn cho các số liệu sử dụng có thể 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 duy trì cao hơn đáng kể so với mức này.

Tổng quan về Mixer

• 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 về dữ liệu đo từ xa của Mixer không nằm trong đường dẫn dữ liệu, nhưng nếu độ trễ này cao, thì chắc chắn hiệu suất của proxy phụ sẽ bị chậm đi. Bạn nên kỳ vọng phân vị thứ 90 sẽ ở mức một chữ số mili giây và phân vị thứ 99 sẽ dưới 100 mili giây.

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

Giám sát phòng bếp

Galley là thành phần xác thực, tiếp nhận, xử lý và phân phối cấu hình của Istio. Nó truyền tải cấu hình từ máy chủ API Kubernetes đến Pilot. Giống như Pilot, nó 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. Chuyển đến " BASE_URL/dashboard/db/istio-galley-dashboard" trong trình duyệt để xem các chỉ số của Galley.

Các chỉ số quan trọng cần theo dõi

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

Chỉ số quan trọng nhất cần theo dõi cho biết số lượng tài nguyên thuộc nhiều loại (chẳng hạn như quy tắc Đích đến, Cổng và Mục nhập dịch vụ) đang vượt qua hoặc không vượt qua quy trình xác thực.

Các ứng dụng được kết nối

Cho biết số lượng ứng dụng được kết nối với Galley; thường thì số này sẽ là 3 (pilot, istio-telemetry, istio-policy) và sẽ tăng lên khi các thành phần đó tăng lên.

16. Khắc phục sự cố Istio

Khắc phục sự cố về lớp dữ liệu

Nếu trang tổng quan về chương trình Thử nghiệm cho biết bạn gặp vấn đề về cấu hình, thì bạn nên kiểm tra nhật ký của chương trình Thử nghiệm hoặc sử dụng istioctl để tìm các vấn đề về cấu hình.

Để kiểm tra nhật ký Pilot, hãy chạy kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery, thay thế istio-pilot-... bằng mã nhận dạng pod cho phiên bản Pilot mà bạn muốn khắc phục sự cố.

Trong nhật ký kết quả, hãy tìm thông báo Push Status (Trạng thái truyền dữ liệu). 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 truyền tải sẽ cho biết mọi vấn đề xảy ra khi cố gắng truyền tải cấu hình đến các proxy Envoy – trong trường hợp này, chúng ta thấy một số thông báo "Cụm trùng lặp", cho biết các đích đến trùng lặp ở nguồn.

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

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

Để sử dụng istioctl nhằm 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, cho biết 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 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. Bạn cần có những thông tin sau để chạy tập lệnh dọn dẹp.

• Tên tổ chức – ví dụ: yourcompany.com
• Mã nhận dạng hội thảo – ở dạng YYMMDD-NN, ví dụ: 200131-01
• Bộ chứa GCS dành cho quản trị viên – được xác định trong tập lệnh 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. Nhấp vào đường liên kết bên dưới.

CLOUD SHELL

14. Xác minh rằng bạn đã đăng nhập vào gcloud bằng người dùng Quản trị viên mà bạn muố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ã nhận dạng 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}