Phát hành phiên bản

• 1: Chính sách về độ lệch phiên bản
• 2: Ghi chú

1 - Chính sách về độ lệch phiên bản

Độ lệch phiên bản (version skew) đề cập đến sự khác biệt về phiên bản giữa các thành phần khác nhau trong cụm Kubernetes. Điều quan trọng là phải quản lý độ lệch phiên bản để đảm bảo khả năng tương thích và tính ổn định trong cụm.

Tài liệu này mô tả độ lệch phiên bản tối đa được hỗ trợ giữa các thành phần Kubernetes khác nhau.

Chú ý: Các công cụ triển khai cụm có thể có các hạn chế khác về độ lệch phiên bản, không được đề cập đến trong tài liệu này.

Các phiên bản được hỗ trợ

Phiên bản Kubernetes được biểu thị dưới dạng x.y.z. Ở đây, x chỉ phiên bản chính (major), y chỉ phiên bản phụ (minor) và z chỉ phiên bản vá (patch), theo thuật ngữ Phiên bản ngữ nghĩa (Semantic Versioning). Tham khảo thêm tại Kubernetes Release Versioning.

Kubernetes duy trì các nhánh phát hành cho ba bản phát hành phụ gần đây nhất: (1.32, 1.31, 1.30). Kubernetes phiên bản 1.19 trở lên sẽ nhận được hỗ trợ bản vá trong khoảng một năm. Các phiên bản Kubernetes trước 1.18 được hỗ trợ bản vá trong khoảng chín tháng.

Các bản sửa lỗi chức năng, bao gồm cả các sửa lỗi bảo mật, có thể được thêm vào ba nhánh phát hành đó, tùy thuộc vào mức độ nghiêm trọng và tính khả thi. Các bản vá được phát hành từ các nhánh đó theo lịch phát hành định kỳ, cộng với các bản phát hành khẩn cấp bổ sung, khi cần thiết.

Nhóm quản lý phát hành sẽ chịu trách nhiệm đưa ra quyết định này.

Thông tin chi tiết, tham khảo thêm tại tài liệu phát hành bản vá Kubernetes.

Các phiên bản lệch được hỗ trợ

Các phiên bản lệch (so với phiên bản mới nhất) được hỗ trợ cho từng thành phần của Kubernetes theo chính sách sau.

kube-apiserver

Đối với Cụm khả dụng cao (HA Clusters) (cụm có nhiều instance kube-apiserver cùng hoạt động), phiên bản cũ nhất và mới nhất của các instance kube-apiserver trong cụm không lệch nhau quá 1 phiên bản phụ.

Ví dụ:

• phiên bản mới nhất của một instance kube-apiserver là 1.32
• phiên bản được cho phép của các intance kube-apiserver khác trong cùng cụm là 1.32 và 1.31

kubelet

• phiên bản phát hành của kubelet không được phép mới hơn của kube-apiserver
• phiên bản phát hành của kubelet được phép tối đa cũ hơn 3 phiên bản phát hành phụ (minor release) so với của kube-apiserver (đối với kubelet phiên bản trước 1.25, được phép cũ hơn tối đa 2 phiên bản)

Ví dụ:

• phiên bản phát hành của kube-apiserver là 1.32
• phiên bản phát hành được cho phép của kubelet là 1.32, 1.31, 1.30, và 1.29

Ví dụ:

• phiên bản phát hành của các kube-apiserver instance trong cụm là 1.32 and 1.31
• các phiên bản phát hành được cho phép của kubelet sẽ là 1.31, 1.30, và 1.29 (bản 1.32 không được cho phép vì mới hơn phiên bản phát hành của instance kube-apiserver phiên bản 1.31)

kube-proxy

• phiên bản phát hành của kube-proxy không được mới hơn của kube-apiserver
• phiên bản phát hành của kube-proxy được phép tối đa cũ hơn 3 phiên bản phát hành phụ (minor release) so với của kube-apiserver (đối với kube-proxy phiên bản trước 1.25, được phép cũ hơn tối đa 2 phiên bản)
• phiên bản phát hành của kube-proxy được phép mới hơn hoặc cũ hơn tối đa 3 phiên bản phát hành phụ (minor release) so với của kubelet chạy cùng node với nó (đối với kube-proxy phiên bản trước 1.25, được phép mới hơn hoặc cũ hơn tối đa tối đa 2 phiên bản)

Ví dụ:

• phiên bản phát hành của kube-apiserver là 1.32
• phiên bản phát hành được cho phép của kube-proxy là 1.32, 1.31, 1.30, và 1.29

• phiên bản phát hành của các kube-apiserver instance trong cụm là 1.32 and 1.31
• các phiên bản phát hành được cho phép của kube-proxy sẽ là 1.31, 1.30, và 1.29 (bản 1.32 không được cho phép vì mới hơn phiên bản phát hành của instance kube-apiserver phiên bản 1.31)

kube-controller-manager, kube-scheduler, cloud-controller-manager

Phiên bản phát hành của kube-controller-manager, kube-scheduler, và cloud-controller-manager không được phép mới hơn của kube-apiserver mà chúng hoạt động cùng. Phiên bản phát hành được kỳ vọng là trùng với phiên bản phát hành của kube-apiserver, tuy nhiên có thể cũ hơn tối đa 1 phiên bản phát hành phụ (minor release) trong trường hợp nâng cấp cụm (live upgrades).

Ví dụ:

• phiên bản phát hành của kube-apiserver là 1.32
• phiên bản phát hành của kube-controller-manager, kube-scheduler, và cloud-controller-manager được cho phép là 1.32 và 1.31

Ví dụ:

• phiên bản phát hành của các kube-apiserver instance trong cụm là 1.32 and 1.31
• kube-controller-manager, kube-scheduler, và cloud-controller-manager có thể kết nối với tất cả các instance kube-apiserver thông qua load balancer
• phiên bản phát hành được cho phép của kube-controller-manager, kube-scheduler, và cloud-controller-manager là 1.31 (bản 1.32 không được cho phép vì mới hơn phiên bản phát hành của instance kube-apiserver phiên bản 1.31)

kubectl

Độ lệch phiên bản phát hành được cho phép của kubectl là 1 bản phát hành phụ (minor release) cũ hoặc mới hơn so với phiên bản phát hành của kube-apiserver

Ví dụ:

• phiên bản phát hành của kube-apiserver là 1.32
• phiên bản phát hành được cho phép của kubectl là 1.33, 1.32, và 1.31

Ví dụ:

• phiên bản phát hành của các kube-apiserver instance trong cụm là 1.32 and 1.31
• phiên bản phát hành được cho phép của kubectl sẽ là 1.32 và 1.31 (các phiên bản khác có thể có độ lệch lớn hơn 1 so với phiên bản phát hành của kube-apiserver)

Thứ tự nâng cấp thành phần

Độ lệch phiên bản được hỗ trợ giữa các thành phần có tác động tới thứ tự mà các thành phần được nâng cấp. Phần này mô tả thứ tự mà các thành phần phải được nâng cấp để chuyển đổi cụm hiện có từ phiên bản 1.31 sang phiên bản 1.32.

Ngoài ra, khi chuẩn bị nâng cấp, Kubernetes khuyến nghị bạn thực hiện các bước sau để được hưởng lợi từ nhiều bản sửa lỗi và hồi quy nhất có thể trong quá trình nâng cấp:

• Đảm bảo phiên bản hiện tại của các thành phần đang ở bản vá (patch) mới nhất trong số các phiên bản vá của bản phát hành phụ hiện tại (minor version)
• Khi tiến hành cập nhật, hãy cập nhật lên phiển bản vá mới nhất của phiên bản phát hành phụ dự định cập nhật

Chẳng hạn, hiện tại bạn đang sử dụng phiên bản phát hành 1.31, hãy chắc chắn bạn đã đang sử dụng bản vá mới nhất. Sau đó, tiến hành nâng cấp cụm lên phiên bản vá mới nhất của 1.32.

kube-apiserver

Điều kiện:

• Trường hợp cụm đơn, phiên bản phát hành của kube-apiserver đang là 1.31
• Trường hợp cụm cài đặt HA, tất cả các instance của kube-apiserver đang là 1.31 hoặc 1.32 (điều này đảm bảo độ lệch phiên bản tối đa giữa các instance kube-apiserver là 1)
• Các thành phần kube-controller-manager, kube-scheduler, và cloud-controller-manager đang kết nối với kube-apiserver phải ở phiên bản 1.31 (điều này đảm bảo chúng không chạy phiên bản mới hơn kube-apiserver và có độ lệch không quá 1 phiên bản phụ so với phiên bản kube-apiserver dự định nâng cấp)
• Phiên bản phát hành của các instance kubelet trên tất cả các node trong cụm đều ở phiên bản 1.31 hoặc 1.30 (điều này đảm bảo chúng không chạy phiên bản phát hành mới hơn và có độ lệch phiên bản không quá 2 so với phiên bản kube-apiserver dự định nâng cấp)
• Các webhooks quản lý đăng ký phải có khả năng tiếp nhận dữ liệu mà instance kube-apiserver mới sẽ gửi cho chúng:
  • ValidatingWebhookConfiguration và MutatingWebhookConfiguration object được cập nhật để chứa thông tin về phiên bản mới của các REST resources được thêm vào trong phiên bản 1.32 (hoặc sử dụng matchPolicy: Equivalent option đối với các phiên bản v1.15+)
  • Các webhooks phải có khả năng tiếp nhận và xử lý bất cứ phiên bản mới của các REST resources sẽ được gửi tới chúng, cũng như bất kỳ thông tin mới được thêm vào cho các phiên bản hiện tại 1.32

Tiến hành nâng cấp kube-apiserver lên phiên bản 1.32.

kube-controller-manager, kube-scheduler, cloud-controller-manager

Điều kiện:

• Phiên bản phát hành của kube-aapiserver phải là 1.32 (trong trường hợp cụm HA, các thành phần này có khả năng tương tác với tất cả các instance kube-apiserver trong cụm, tất cả các instance kube-apiserver phải được nâng cấp trước khi nâng cấp controllers và scheduler)

Tiến hành nâng cấp kube-controller-manager, kube-scheduler, và cloud-controller-manager lên phiên bản 1.32.

Không có yêu cầu nào về thứ tự nâng cấp giữa các controllers và scheduler. Bạn có thể nâng cấp theo bất cứ thứ tự nào, thậm trí nâng cấp đồng thời tất cả các controllers và scheduler.

kubelet

Điều kiện:

• Phiên bản phát hành của kube-apiserver mà kubelet sẽ tương tác phải là 1.32

Có thể nâng cấp phiên bản phát hành của kubelet lên 1.32 (hoặc cũng có thể để nguyên ở 1.31, 1.30, hoặc 1.29)

kube-proxy

Điều kiện:

• Phiên bản phát hành của kube-apiserver mà kube-proxy sẽ tương tác phải là 1.32

Có thể nâng cấp phiên bản phát hành của kube-proxy lên 1.32 (hoặc cũng có thể để nguyên ở 1.31, 1.30, hoặc 1.29)

2 - Ghi chú

Bạn có thể tìm thấy ghi chú về bản phát hành (Release Note) của phiên bản Kubernetes bạn đang sử dụng thông qua trang Changelog trong repo Kubernetes trên GitHub. Ví dụ, ghi chú về bản phát hành 1.32 tại Changelog Kubernetes.

Ngoài ra, bạn cũng có thể tìm kiếm ghi chú về bản phát hành một cách trực tiếp thông qua: relnotes.k8s.io. Ví dụ, ghi chú về bản phát hành 1.32 tại relnotes.k8s.io.