Quy trình nâng cấp hai giai đoạn mới của GKE giúp giảm thiểu rủi ro gián đoạn cụm khi thay đổi phiên bản phụ

Google Cloud thông báo rằng dịch vụ GKE của họ hiện đã cung cấp tính năng nâng cấp control-plane hai bước ở chế độ sẵn sàng chung (generally-available), cho phép khách hàng tách biệt việc nâng cấp binary phần mềm khỏi việc di chuyển định dạng dữ liệu và duy trì một khoảng thời gian có thể rollback trong quá trình thay đổi phiên bản phụ (minor version).

Tại sao GKE cần một lộ trình an toàn hơn

Việc nâng cấp Kubernetes control plane từ phiên bản phụ này sang phiên bản phụ tiếp theo luôn tiềm ẩn rủi ro. Việc chuyển từ 1.33 sang 1.34 không chỉ thay thế các binary mà còn viết lại các cấu trúc dữ liệu cơ bản. Nếu phiên bản mới chứa lỗi, cụm (cluster) không thể đơn giản là quay lại phiên bản cũ; quản trị viên phải khôi phục các bản snapshot cơ sở dữ liệu cũ hoặc xây dựng lại toàn bộ cụm, một quá trình tốn thời gian và dễ xảy ra lỗi.

Cách thức hoạt động của quá trình nâng cấp hai bước

Quy trình mới chia việc nâng cấp thành hai giai đoạn riêng biệt:

• Bước 1 – Nâng cấp Binary (chế độ mô phỏng). GKE hoán đổi các binary của control-plane sang phiên bản mục tiêu trong khi vẫn giữ nguyên định dạng dữ liệu cũ. Vì không có cấu trúc dữ liệu mới nào được ghi vào, cụm vẫn đảm bảo an toàn để rollback trong suốt giai đoạn này.
• Bước 2 – Hoàn tất. Sau một khoảng thời gian chờ có thể cấu hình, GKE sẽ chuyển đổi dữ liệu đã lưu sang định dạng mới. Một khi quá trình chuyển đổi này hoàn tất, việc rollback sẽ đòi hỏi nỗ lực khôi phục snapshot tương tự như quy trình mà bước nâng cấp hai bước này đã được thiết kế để tránh.

Sự tách biệt này tạo ra một “soak window” (khoảng thời gian theo dõi) nơi các kỹ thuật viên có thể quan sát các binary đã nâng cấp trong môi trường production mà không phải cam kết thực hiện việc di chuyển dữ liệu không thể đảo ngược.

Ứng dụng thực tế của soak window

GKE tự động giám sát các chỉ số sức khỏe chính trong giai đoạn soak—độ trễ API, tỷ lệ lỗi và sức khỏe của pod. Nếu dịch vụ phát hiện các điểm bất thường, nó sẽ dừng việc triển khai (rollout), để cụm ở trạng thái chỉ có binary, nơi việc rollback vẫn có thể thực hiện được. Google dẫn chứng tỷ lệ thành công đạt 99,999% cho các lần nâng cấp tuân theo mô hình này.

Đối với các cụm sử dụng tính năng auto-upgrade của GKE, nền tảng sẽ điều phối toàn bộ trình tự hai bước mà không cần can thiệp thủ công. Những người dùng muốn toàn quyền kiểm soát có thể thực hiện quy trình thông qua Cloud CLI hoặc Terraform.

Thực hiện nâng cấp hai bước thủ công

Một quy trình nâng cấp thủ công điển hình với cửa sổ an toàn 48 giờ trông như sau:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Để kiểm tra trạng thái hiện tại:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Nếu có lỗi phát sinh trong quá trình soak, quản trị viên có thể đưa ra lệnh rollback và quay lại phiên bản trước đó mà không làm mất dữ liệu. Khi cụm đã chứng minh được sự ổn định, việc nâng cấp có thể được hoàn tất sớm hơn bằng lệnh complete-control-plane-upgrade.

Giới hạn và yêu cầu

• Tính năng này áp dụng cho các cụm GKE chạy phiên bản 1.33 trở lên.
• Chỉ có thể nâng cấp một phiên bản phụ tại một thời điểm; việc bỏ qua các phiên bản không được hỗ trợ.
• Cả Autopilot và các cụm regional đều duy trì hoạt động trong suốt quá trình hai bước.

Những nhược điểm tiềm ẩn

Việc tách biệt nâng cấp binary và dữ liệu sẽ thêm một bước phụ vào lộ trình nâng cấp, điều này có thể kéo dài tổng thời gian đối với các tổ chức cần thay đổi phiên bản nhanh chóng. Giai đoạn soak cũng phụ thuộc vào các bước kiểm tra sức khỏe tự động; các đội ngũ chạy các khối lượng công việc (workloads) tùy chỉnh cao có thể cần bổ sung công cụ quan sát (observability tooling) riêng của họ để phát hiện các lỗi hồi quy (regressions) trong các trường hợp biên.

Những điều cần theo dõi tiếp theo

Google vẫn chưa tiết lộ lộ trình mở rộng mô hình hai bước cho các lần nâng cấp phiên bản lớn (major version), vốn vẫn yêu cầu tái tạo toàn bộ cụm trong nhiều trường hợp. Các nhà quan sát sẽ chờ đợi những thông báo về các lưới an toàn (safety nets) tương tự cho việc nâng cấp node-pool và bất kỳ sự tích hợp nào với các pipeline CI/CD của bên thứ ba để có thể tự động hóa các bước kiểm tra trong soak-window.

Điểm mấu chốt: Bằng cách tách rời việc nâng cấp binary khỏi việc di chuyển dữ liệu, GKE cung cấp cho các kỹ sư nền tảng một khoảng thời gian rollback thực tế cho các thay đổi phiên bản phụ, giúp giảm chi phí vận hành bảo trì cụm trong khi vẫn giữ thời gian ngừng hoạt động (downtime) ở mức tối thiểu.