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ủakube-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ủakube-apiserver
(đối vớikubelet
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
Lưu ý:
Trong trường hợp cụm HA chứa các instancekube-apiserver
lệch phiên bản, số lượng phiên bản được cho phép của kubelet
sẽ bị giảm đi.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 instancekube-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ủakube-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ủakube-apiserver
(đối vớikube-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ủakubelet
chạy cùng node với nó (đối vớikube-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
Lưu ý:
Trong trường hợp cụm HA chứa các instancekube-apiserver
lệch phiên bản, số lượng phiên bản được cho phép của kube-proxy
sẽ bị giảm đi.- 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 instancekube-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
Lưu ý:
Trong trường hợp cụm HA chứa các instancekube-apiserver
lệch phiên bản, và các thành phần này có thể tương tác với tất cả các instance kube-apiserver
trong cụm (chẳng hạn thông qua load balancer), số lượng phiên bản được cho phép của các thành phần này sẽ giảm đi.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 instancekube-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 instancekube-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
Lưu ý:
Trong trường hợp cụm HA chứa các instancekube-apiserver
lệch phiên bản, số lượng phiên bản được cho phép của kubectl
sẽ bị giảm đi.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ủakube-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 instancekube-apiserver
là 1) - Các thành phần
kube-controller-manager
,kube-scheduler
, vàcloud-controller-manager
đang kết nối vớikube-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ơnkube-apiserver
và có độ lệch không quá 1 phiên bản phụ so với phiên bảnkube-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ảnkube-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ụngmatchPolicy: 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.
Lưu ý:
Theo chính sách cho API deprecation và API change guidelines,kube-apiserver
được yêu cầu nâng cấp lần lượt qua tất cả các phiên bản phát hành phụ (minor release), bất kể trong trường hợp cài đặt HA hay khôngkube-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 instancekube-apiserver
trong cụm, tất cả các instancekube-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)
Lưu ý:
Trước khi tiến hành nâng cấp phiên bảnkubelet
, drain tất cả pod khỏi node đó. Nâng cấp phiên bản phát hành cho kubelet
khi đang hoạt động hiện chưa được hỗ trợ.Cảnh báo:
Sử dụng một cụm có chứa cáckubelet
đang chạy ở phiên bản phát hành cũ hơn của kube-apiserver
3 phiên bản, đồng nghĩa bạn phải nâng cấp kubelet
trước khi có thể nâng cấp control plane (kube-apiserver
, kube-controller-manager
, kube-scheduler
, etc.)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)
Cảnh báo:
Sử dụng một cụm có chứa cáckube-proxy
đang chạy ở phiên bản phát hành cũ hơn của kube-apiserver
3 phiên bản, đồng nghĩa bạn phải nâng cấp kube-proxy
trước khi có thể nâng cấp control plane (kube-apiserver
, kube-controller-manager
, kube-scheduler
, etc.)