Độ 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.
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.35, 1.34, 1.33). 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 (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.
Đố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ụ:
kube-apiserver là 1.35kube-apiserver khác trong cùng cụm là 1.35 và 1.34kubelet không được phép mới hơn của kube-apiserverkubelet đượ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ụ:
kube-apiserver là 1.35kubelet là 1.35, 1.34,
1.33, và 1.32kube-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ụ:
kube-apiserver instance trong cụm là 1.35 and 1.34kubelet sẽ là 1.34, 1.33,
và 1.32 (bản 1.35 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.34)kube-proxy không được mới hơn của kube-apiserverkube-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)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ụ:
kube-apiserver là 1.35kube-proxy là 1.35, 1.34,
1.33, và 1.32kube-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.kube-apiserver instance trong cụm là 1.35 and 1.34kube-proxy sẽ là 1.34, 1.33,
và 1.32 (bản 1.35 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.34)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ụ:
kube-apiserver là 1.35kube-controller-manager, kube-scheduler, và cloud-controller-manager được cho phép là 1.35 và 1.34kube-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ụ:
kube-apiserver instance trong cụm là 1.35 and 1.34kube-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 balancerkube-controller-manager, kube-scheduler, và cloud-controller-manager là 1.34 (bản 1.35 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.34)Độ 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ụ:
kube-apiserver là 1.35kubectl là 1.36, 1.35, và 1.34kube-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ụ:
kube-apiserver instance trong cụm là 1.35 and 1.34kubectl sẽ là 1.35 và 1.34 (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)Độ 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.34 sang phiên bản 1.35.
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:
Chẳng hạn, hiện tại bạn đang sử dụng phiên bản phát hành 1.34, 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.35.
Điều kiện:
kube-apiserver đang là 1.34kube-apiserver đang là 1.34 hoặc
1.35 (đ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)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.34 (đ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)kubelet trên tất cả các node trong cụm đều ở phiên bản 1.34 hoặc 1.33
(đ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)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.35 (hoặc sử dụng matchPolicy: Equivalent option đối với các phiên bản v1.15+)Tiến hành nâng cấp kube-apiserver lên phiên bản 1.35.
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ôngĐiều kiện:
kube-aapiserver phải là 1.35
(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.35.
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.
Điều kiện:
kube-apiserver mà kubelet sẽ tương tác phải là 1.35Có thể nâng cấp phiên bản phát hành của kubelet lên 1.35 (hoặc cũng có thể để nguyên ở 1.34, 1.33, hoặc 1.32)
kubelet, 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ợ.kubelet đ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.)Điều kiện:
kube-apiserver mà kube-proxy sẽ tương tác phải là 1.35Có thể nâng cấp phiên bản phát hành của kube-proxy lên 1.35 (hoặc cũng có thể để nguyên ở 1.34, 1.33, hoặc 1.32)
kube-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.)