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

• 1: Chính sách về độ lệch phiên bản
• 2: Ghi chú
• 3: Quản lý phát hành
• 4: Tải xuống Kubernetes

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.

3 - Quản lý phát hành

"Người quản lý phát hành" là thuật ngữ chung bao gồm nhóm những người đóng góp cho Kubernetes chịu trách nhiệm duy trì các nhánh phát hành và tạo các bản phát hành bằng cách sử dụng các công cụ mà SIG Release cung cấp.

Vai trò của từng nhóm được thể hiện như sau

• Thông tin liên hệ
  • Chính sách cấm chia sẻ thông tin an ninh
• Handbooks
• Nhóm quản lý phát hành
  • Tham gia nhóm quản lý phát hành
• Nhóm dự bị quản lý phát hành
  • Tham gia nhóm dự bị quản lý phát hành
• SIG Release Leads
  • Chairs
  • Technical Leads

Thông tin liên hệ

Chính sách cấm chia sẻ thông tin an ninh

Một số thông tin về bản phát hành có thể không được công khai và chúng tôi đã xác định chính sách về cách thiết lập lệnh cấm công khai đó. Tham khảo thêm tại Chính sách cấm chia sẻ thông tin an ninh.

Handbooks

LƯU Ý: Handbook cho Nhóm phát hành bản vá và Nhóm quản trị nhánh phát hành (branch) sẽ được loại bỏ trùng lặp sau.

• Nhóm phát hành bản vá
• Nhóm quản trị nhánh phát hành

Nhóm quản lý phát hành

Lưu ý: Tài liệu có thể đề cập đến Nhóm phát hành bản vá và vai trò Quản lý nhánh phát hành. Hai vai trò đó được hợp nhất thành vai trò Quản lý phát hành.

Yêu cầu tối thiểu cho Nhóm quản lý phát hành và Nhóm hỗ trợ quản lý phát hành:

• Thành thạo sử dụng các câu lệnh Unix, có khả năng debug shell scripts.
• Thành thạo sử dụng git và quản lý nhánh (branch) sử dụng git command.
• Kiến thức về Google Cloud (Cloud Build và Cloud Storage).
• Sẵn sàng tìm kiếm sự giúp đỡ khi gặp sự cố, khả năng giao tiếp rõ ràng.
• Kubernetes Community membership

Nhóm quản lý phát hành có trách nhiệm:

• Phối hợp và phát hành phiên bản Kubernetes:
  • Bản vá - Patch releases (x.y.z, where z > 0)
  • Bản phụ - Minor releases (x.y.z, where z = 0)
  • Bản dùng thử Pre-releases (alpha, beta, và release candidates(rc))
  • Làm việc với Nhóm phát hành trong chu kỳ phát hành
  • Thiết lập lịch và nhịp độ phát hành cho bản vá
• Duy trì các nhánh phát hành (release branch):
  • Đánh giá các cherry picks
  • Đảm bảo nhánh phát hành luôn hoạt động tốt và không có bản vá lỗi không mong muốn nào được hợp nhất
• Hướng dẫn Nhóm dự bị quản lý phát hành
• Phát triển tính năng và duy trì code trong k/release
• Hỗ trợ nhóm dự dự bị quản lý phát hành và những người đóng góp độc lập thông qua chương trình Buddy
  • Định kỳ họp mặt với nhóm dự bị, phân chia nhiệm vụ (phát triển tính năng hoặc quản lý phát hành), hoặc hướng dẫn.
  • Hỗ trợ nhóm dự bị trong việc hướng dẫn bước đầu cho những người đóng góp mới, trả lời các câu hỏi liên quan hoặc gợi ý những nhiệm vụ có thể cho họ.

Nhóm quản lý phát hành cũng làm việc chặt chẽ với Ủy ban ứng phó vấn đề an ninh, do đó tuân thủ theo các hướng dẫn được nêu trong Quy trình an ninh cho phát hành.

GitHub Access Controls: @kubernetes/release-managers

GitHub Mentions: @kubernetes/release-engineering

• Adolfo García Veytia (@puerco)
• Cici Huang (@cici37)
• Carlos Panato (@cpanato)
• Jeremy Rickard (@jeremyrickard)
• Marko Mudrinić (@xmudrii)
• Nabarun Pal (@palnabarun)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)
• Verónica López (@verolop)

Tham gia nhóm quản lý phát hành

Để trở thành thành viên nhóm quản lý phát hành, bạn phải trải qua quá trình dự bị quản lý phát hành. Những thành viên dự bị được thăng hạng trở thành thành viên quản lý phát hành thông qua việc hoàn thành những nhiệm vụ được giao qua nhiều vòng phát triển (release cycles), đồng thời:

• Thể hiện sự sẵn sàng cho vai trò quản lý
• Làm việc hiệu quả với nhóm quản lý phát hành và có khả năng tạo bản phát hành một cách độc lập
  • Vì mỗi bản phát hành có chức năng hạn chế, chúng tôi cũng xem xét những đóng góp đáng kể cho việc quảng bá hình ảnh và các nhiệm vụ kỹ thuật khác trong quá trình phát hành
• Khả năng hỗ trợ các dự bị quản lý phát hành khác, khả năng đề xuất cải tiến, thu thập phản hồi và thúc đẩy sự thay đổi
• Đáng tin cậy, có khả năng phản hồi nhanh
• Có lý do chính đáng cho việc tham gia, chẳng hạn cần có quyền truy cập của nhóm quản lý phát hành để hoàn thành nhiệm vụ được giao

Nhóm dự bị quản lý phát hành

Nhóm dự bị quản lý phát hành được hiểu là người học việc để trở thành người thuộc Nhóm quản lý phát hành. Trách nhiệm bao gồm:

• Các nhiệm vụ liên quan đến phát hành bản vá, review cherry-pick
• Đóng góp trực tiếp cho k/release: nâng cấp phiên bản cho các thư viện phụ thuộc, làm quen với source codebase
• Đóng góp cho tài liệu: bảo trì handbook, đảm bảo quy trình phát hành được tài liệu hóa
• Với sự hỗ trợ của Nhóm quản lý phát hành: làm việc cùng nhóm phát hành trong các vòng phát triển, hỗ trợ việc phát hành các phiên bản
• Chủ động tìm kiếm các cơ hộ để quảng bá và thông báo về các bản phát hành
  • Đưa ra các thông báo sớm hoặc các cập nhật về các bản vá sắp tới
  • Cập nhật lịch phát hành, đưa ra các mốc thời gian cũng như thông báo về các bản phát hành mới trên Timeline vòng phát triển
• Thông qua chương trình Buddy, hướng dẫn bước đầu cho những người đóng góp mới và làm việc cùng họ trong các nhiệm vụ

GitHub Mentions: @kubernetes/release-engineering

• Arnaud Meukam (@ameukam)
• Jim Angel (@jimangel)
• Joseph Sandoval (@jrsapi)
• Xander Grzywinski(@salaxander)

Tham gia nhóm dự bị quản lý phát hành

Người đóng góp độc lập có thể tham gia vào nhóm dự bị quản lý phát hành qua việc đạt được các tiêu chí sau:

• Tham gia thường xuyên, bao gồm 6-12 tháng có hoạt động liên quan đến vấn đề kỹ thuật
• Có kinh nghiệm đảm nhiệm vai trò lãnh đạo kỹ thuật trong Nhóm phát hành trong chu kỳ phát hành
  • kinh nghiệm này cung cấp một cơ sở vững chắc để hiểu cách SIG Release hoạt động tổng thể—bao gồm cả kỳ vọng của chúng tôi về kỹ năng kỹ thuật, giao tiếp/phản hồi và độ tin cậy
• Làm việc trên các mục k/release giúp cải thiện tương tác của chúng tôi với Testgrid, dọn dẹp thư viện, v.v.
  • Những nhiệm vụ này đòi hỏi phải tương tác với các thành viên Nhóm quản lý phát hành và dự bị

SIG Release Leads

SIG Release Chairs và Technical Leads có nhiệm vụ:

• Quản lý SIG Release
• Dẫn dắt các buổi trao đổi kiến ​​thức cho các quản lý phát hành và dự bị quản lý phát hành
• Huấn luyện các kỹ năng lãnh đạo và lên lịch ưu tiên

Họ được đề cập rõ ràng ở đây vì họ là có đặc quyền ở nhiều kênh liên lạc và nhóm phân quyền (ví dụ nhóm phân quyền trên GitHub org, quyền truy cập GCP) cho từng vai trò. Do đó, họ là thành viên cộng đồng có đặc quyền cao và được biết một số thông tin liên lạc không công khai, đôi khi có thể liên quan đến vấn đề bảo mật của Kubernetes.

GitHub team: @kubernetes/sig-release-leads

Chairs

• Jeremy Rickard (@jeremyrickard)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)

Technical Leads

• Adolfo García Veytia (@puerco)
• Carlos Panato (@cpanato)
• Verónica López (@verolop)

Bạn có thể tìm thấy thông tin về các nhóm quản lý nhánh phát hành trước đây tại thư mục releases của repo kubernetes/sig-release, các tệp release-x.y/release_team.md.

Ví dụ: 1.15 Release Team

4 - Tải xuống Kubernetes

Kubernetes cung cấp các tệp nhị phân cho từng thành phần cũng như một bộ các công cụ chuẩn để khởi động hoặc tương tác với một cụm. Các thành phần như máy chủ API (kube-apiserver) có khả năng chạy trong container image (tương tự một ứng dụng trên Kubernetes) bên trong một cụm. Các thành phần như vậy được đóng gói dưới dạng container image như một phần của quy trình phát hành chính thức. Tất cả các tệp nhị phân cũng như container image được phát hành tương thích cho nhiều hệ điều hành cũng như phần cứng.

kubectl

Công cụ command-line của Kubernetes, kubectl, cho phép bạn tương tác với cụm Kubernetes.

Có thể sử dụng kubectl để triển khai ứng dụng, quan sát, quản lý tài nguyên của cụm, hay xem log. Chi tiết thêm về kubectl, tham khảo the tài liệu về kubectl.

kubectl có thể được cài đặt trên nhiều hệ điều hành khác nhau, Linux, macOS hay Windows. Bạn có thể tìm thấy hướng dẫn cài đặt cụ thể tương ứng ở dưới

• Cài đặt kubectl cho Linux
• Cài đặt kubectl cho macOS
• Cài đặt kubectl cho Windows

Container images

Tất cả các container image của Kubernetes đều được tải lên registry.k8s.io.

Container image architectures

Tất cả các container image đều có sẵn cho các kiến trúc (hardware architecture). Bạn có thể kéo chính xác container image tương ứng với kiến trúc của máy bằng cách thêm vào phần đuôi tên container image. Ví dụ registry.k8s.io/kube-apiserver-arm64:v1.32.0.

Container image signatures

Tất cả các container image của Kubernetes được ký (sign) sử dụng chữ ký sigstore

Kubernetes công khai danh sách các container images đã được ký xác nhận theo SPDX 2.3. Bạn có thể lấy thông tin về danh sách bằng cách:

curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" |  grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/'

Để kiểm tra các container image được ký xác nhận, làm theo hướng dẫn ở Verify Signed Container Images.

Nếu bạn kéo về một container image cho một kiến trúc phần cứng chỉ định, container image cho kiến trúc đơn (single-architecture) được ký cùng cách với danh sách manifest cho kiến trúc đa (multi-architecture).

Binaries