Tại sao phải upgrade version GKE?

Cập nhật Google Kubernetes Cluster (GKE) là một phần quan trọng của quản lý môi trường container và ứng dụng trên nền tảng Google Cloud. Dưới đây sẽ là vài lý do lý giải vì sao chúng ta cần phải cập nhật cụm Kubernetes:

• Đảm bảo tính ổn định của cụm Cluster
• Trải nghiệm và sử dụng các tính năng mới
• Ngăn ngừa các vấn đề bảo mật, lỗ hổng phiên bản cũ
• Và cuối cùng, cập nhật vì Cloud provider (Google) bắt phải cập nhật không thì sẽ dừng hỗ trợ. Mỗi 3 tháng 1 version sẽ bị dừng hỗ trợ, bạn có thể xem EOL (End of Life) của các version GKE ở đây https://endoflife.date/google-kubernetes-engine
• Và còn rất nhiều lý do khác nữa

Nói chung nếu bạn đã và đang làm việc với GKE thì khả năng cao bạn sẽ phải đụng đến việc cập nhật phiên bản cho các cụm Kubernetes đang chạy. Trong bài này mình sẽ hướng dẫn 1 vài cách để có thể cập nhật phiên bản cho một cụm GKE mà mình đã rút ra được trong qúa trình làm việc.

Lưu ý: Hiện tại Google có 2 dạng GKE là GKE Standard và GKE Autopilot. Đối với GKE Autopilot việc upgrade version sẽ được thực hiện một cách hoàn toàn tự động nên trong bài này mình sẽ chỉ nói về GKE Standard và trong trường hợp các bạn muốn cập nhật phiên bản 1 cách chủ động.

Minor upgrade

Minor upgrade là quá trình cập nhật hoặc nâng cấp phần mềm hoặc hệ thống từ phiên bản hiện tại lên một phiên bản mới, nhưng sự thay đổi trong phiên bản mới thường là nhỏ hoặc tập trung vào việc vá lỗi, cải tiến hiệu suất và tính năng nhỏ.

Ví dụ: Nâng cấp từ 1.24.2 lên 1.24.3 hay nâng cấp từ 1.24 lên 1.25

Để cập nhật dạng minor upgrade bạn có thể sử dụng 1 trong 2 cách sử dụng giao diện web hoặc sử dụng command line (CLI)

Sử dụng giao diện web

Truy cập vào trong cluster bạn muốn upgrade, trong mục Details bạn sẽ thấy có cụm từ Upgrade Available trong mục Cluster Basics

Chọn Version bạn muốn nâng cấp và xác nhận.

Google sẽ cập nhật Control Plane nodes trước, 1 vài phút sau khi cập nhật Control plane nodes xong, các Worker Node sẽ được cập nhật tự động.

Ưu điểm

• Khá nhàn, không phải thực hiện hành động gì nhiều

Sử dụng command line

Để sử dụng command line bạn có thể sử dụng luôn Cloud Shell trên trình duyệt web hoặc Terminal tại máy cá nhân. Tương tự như cách Google tự động cập nhật cụm cluster, với cách này ta sẽ phải thủ công cập nhật Control plane nodes và Worker nodes.

Để cập nhật các nodes Control Plane ta dùng câu lệnh như sau, thay đổi các giá trị phù hợp với cụm cluster của bạn:

gcloud container clusters upgrade cluster-1 --master --cluster-version 1.25.15-gke.1700 --region=asia-southeast1 --project lab-project

Bạn có thể sử dụng câu lệnh sau để kiểm tra trạng thái cập nhật của cluster:

gcloud container operations list --project lab-project --region=asia-southeast1

Tiếp theo, sau khi Control Plane nodes đã được cập nhật ta sẽ tiếp tục cập nhật node-pool bằng câu lệnh

gcloud container clusters upgrade cluster-1 --node-pool=default-pool --cluster-version 1.25.15-gke.1700 --region=asia-southeast1 --project lab-project

Multiple Upgrade

Mình không chắc cái tên multiple upgrade có chuẩn hay không nên dùng tạm.

Multiple upgrade là quá trình nâng cấp từ một phiên bản cũ lên một phiên bản mới với sự thay đổi lớn, thường đánh dấu bằng việc tăng số phiên bản chính (major version). Hiểu đơn giản thay vì nâng cấp từng phiên bản nhỏ ta sẽ nâng cấp 1 lần nhiều phiên bản cùng một lúc.

Ví dụ: Nâng cấp phiên bản từ 1.24 lên 1.27. Mình cũng sẽ sử dụng ví dụ này để mô tả 2 cách cập nhật mình sẽ nói phía dưới.

Cách 1

Vắn tắt cách này mình sẽ triển khai như sau:

1. Cập nhật liên tục phiên bản của Control Plane nodes từ 1.24 lên 1.25 rồi 1.25 lên 1.26.
2. Triển khai node-pool mới với version 1.26
3. Drain dần dần các node ở node pool cũ để cho các tài nguyên chuyển qua bên node pool version mới.
4. Xóa node pool cũ.

Với cách này các bạn có thể nâng cấp tối đa 2 phiên bản do khả năng tương thích của Kubernetes.

Ví dụ: Bạn có thể triển khai cụm 1.24 lên 1.26 chứ không thể triển khai từ 1.24 lên 1.27. Cách này sẽ giúp tiết kiệm 1 khoảng thời gian kha khá khi cập nhật node pool nếu cụm của bạn có nhiều worker nodes.

Cách 2

Nếu bạn đã quen thuộc với chiến lược triển khai Blue-Green thì đây chính xác là chiến lược đó.

Thay cập nhật phiên bản cụm hiện tại, bạn sẽ tạo một cụm cluster mới với version mong muốn. Sau đó chuyển đổi routing sang cụm cluster mới này.

Vắn tắt các bước triển khai sẽ như sau:

1. Tạo cụm K8s cluster mới với version mong muốn 1.27
2. Triển khai các dịch vụ đang chạy ở môi trường cũ lên môi trường mới (vẫn giữ nguyên các tài nguyên môi trường cũ)
3. Kiểm tra khả năng hoạt động của dịch vụ trên môi trường mới
4. Chuyển hướng requests sang cụm cluster mới (thường là sẽ thay đổi DNS record, Loadbalancer configs)
5. Xóa cụm cluster phiên bản cũ 1.24

Ưu điểm

• Không có thời gian downtime
• Upgrade bao nhiêu version cũng được

Nhược điểm

• Quá trình chuẩn bị cụm cluster mới sẽ tốn rất nhiều thời gian để test kỹ càng
• Chi phí sẽ cao hơn do phải duy trì 2 cụm trong 1 khoảng thời gian

Lưu ý thêm

• Trong quá trình upgrade phiên bản cho cụm cluster bạn cần kiểm tra ApiVersion của các resource có tương thích với version cluster ở phiên bản mới không, bởi các APIVersion có thể sẽ bị loại bỏ trong phiên bản mới.
• Các dịch vụ của bản chạy trên Cluster cần có cơ chế graceful shutdown để tránh và giảm tối đa thời gian downtime của dịch vụ.

Kết

Cám ơn các bạn đã đọc hết bài, bài trên dựa trên những gì mình tìm hiểu được, nếu có cách nào hay hơn hay có sai sót trong bài bạn hãy bình luận xuống dưới để chia sẻ nhé. Have a nice day! 😁

Chuyên mục quảng cáo

Nếu như bạn đang gặp khúc mắc trong vấn đề chuyên môn hay cần người hỗ trợ về mặt hệ thống, DevOps tools thì mình tự tin có thể hỗ trợ được bạn. Liên hệ với mình để trao đổi thêm nhé https://hoangviet.io.vn/