Skip to content

Commit eaf3395

Browse files
committed
Add Version Skew Policy page in Vietnamese
Signed-off-by: khanhtc1202 <[email protected]>
1 parent 74343d4 commit eaf3395

File tree

2 files changed

+198
-0
lines changed

2 files changed

+198
-0
lines changed

content/vi/releases/_index.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,8 @@ Các phiên bản Kubernetes trước 1.18 được hỗ trợ bản vá trong k
1616
Phiên bản Kubernetes được biểu thị dưới dạng **x.y.z**.
1717
Ở đâ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.
1818

19+
Bạn có thể tìm thấy thông tin chi tiết hơn về độ lệch phiên bản (version skew) trong tài liệu [Chính sách về độ lệch phiên bản](/releases/version-skew-policy/).
20+
1921
<!-- body -->
2022

2123
## Lịch sử phát hành các phiên bản
Lines changed: 196 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,196 @@
1+
---
2+
title: Chính sách về độ lệch phiên bản
3+
type: docs
4+
description: >
5+
Độ lệch phiên bản tối đa được hỗ trợ giữa các thành phần của Kubernetes.
6+
---
7+
8+
<!-- overview -->
9+
10+
Độ 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.
11+
12+
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.
13+
14+
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.
15+
16+
<!-- body -->
17+
18+
## Các phiên bản được hỗ trợ
19+
20+
Phiên bản Kubernetes được biểu thị dưới dạng **x.y.z**.
21+
Ở đâ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](https://semver.org/)). Tham khảo thêm tại [Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning).
22+
23+
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: ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).
24+
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](/releases/patch-releases/#support-period).
25+
Các phiên bản Kubernetes trước 1.18 được hỗ trợ bản vá trong khoảng chín tháng.
26+
27+
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
28+
[lịch phát hành định kỳ](/releases/patch-releases/#cadence), cộng với các bản phát hành khẩn cấp bổ sung, khi cần thiết.
29+
30+
[Nhóm quản lý phát hành](/releases/release-managers/) sẽ chịu trách nhiệm đưa ra quyết định này.
31+
32+
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](/releases/patch-releases/).
33+
34+
## Các phiên bản lệch được hỗ trợ
35+
36+
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.
37+
38+
### kube-apiserver
39+
40+
Đối với [Cụm khả dụng cao (HA Clusters)](/docs/setup/production-environment/tools/kubeadm/high-availability/) (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ụ.
41+
42+
Ví dụ:
43+
44+
* phiên bản mới nhất của một instance `kube-apiserver`**{{< skew currentVersion >}}**
45+
* phiên bản được cho phép của các intance `kube-apiserver` khác trong cùng cụm là **{{< skew currentVersion >}}****{{< skew currentVersionAddMinor -1 >}}**
46+
47+
### kubelet
48+
49+
* phiên bản phát hành của `kubelet` không được phép mới hơn của `kube-apiserver`
50+
* 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)
51+
52+
Ví dụ:
53+
54+
* phiên bản phát hành của `kube-apiserver`**{{< skew currentVersion >}}**
55+
* phiên bản phát hành được cho phép của `kubelet`**{{< skew currentVersion >}}**, **{{< skew currentVersionAddMinor -1 >}}**,
56+
**{{< skew currentVersionAddMinor -2 >}}**, và **{{< skew currentVersionAddMinor -3 >}}**
57+
58+
{{< note >}}
59+
Trong trường hợp cụm HA chứa các instance `kube-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.
60+
{{</ note >}}
61+
62+
Ví dụ:
63+
64+
* phiên bản phát hành của các `kube-apiserver` instance trong cụm là **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}**
65+
* các phiên bản phát hành được cho phép của `kubelet` sẽ là **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**,
66+
**{{< skew currentVersionAddMinor -3 >}}** (bản **{{< skew currentVersion >}}** 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 **{{< skew currentVersionAddMinor -1 >}}**)
67+
68+
### kube-proxy
69+
70+
* phiên bản phát hành của `kube-proxy` không được mới hơn của `kube-apiserver`
71+
* 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)
72+
* 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)
73+
74+
Ví dụ:
75+
76+
* phiên bản phát hành của `kube-apiserver`**{{< skew currentVersion >}}**
77+
* phiên bản phát hành được cho phép của `kube-proxy`**{{< skew currentVersion >}}**, **{{< skew currentVersionAddMinor -1 >}}**,
78+
**{{< skew currentVersionAddMinor -2 >}}**, và **{{< skew currentVersionAddMinor -3 >}}**
79+
80+
{{< note >}}
81+
Trong trường hợp cụm HA chứa các instance `kube-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.
82+
{{</ note >}}
83+
84+
* phiên bản phát hành của các `kube-apiserver` instance trong cụm là **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}**
85+
* các phiên bản phát hành được cho phép của `kube-proxy` sẽ là **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**,
86+
**{{< skew currentVersionAddMinor -3 >}}** (bản **{{< skew currentVersion >}}** 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 **{{< skew currentVersionAddMinor -1 >}}**)
87+
88+
### kube-controller-manager, kube-scheduler, cloud-controller-manager
89+
90+
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).
91+
92+
Ví dụ:
93+
94+
* phiên bản phát hành của `kube-apiserver`**{{< skew currentVersion >}}**
95+
* phiên bản phát hành của `kube-controller-manager`, `kube-scheduler`, và `cloud-controller-manager` được cho phép là **{{< skew currentVersion >}}****{{< skew currentVersionAddMinor -1 >}}**
96+
97+
{{< note >}}
98+
Trong trường hợp cụm HA chứa các instance `kube-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.
99+
{{< /note >}}
100+
101+
Ví dụ:
102+
103+
* phiên bản phát hành của các `kube-apiserver` instance trong cụm là **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}**
104+
* `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
105+
* phiên bản phát hành được cho phép của `kube-controller-manager`, `kube-scheduler`, và `cloud-controller-manager`**{{< skew currentVersionAddMinor -1 >}}** (bản **{{< skew currentVersion >}}** 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 **{{< skew currentVersionAddMinor -1 >}}**)
106+
107+
### kubectl
108+
109+
Độ 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`
110+
111+
Ví dụ:
112+
113+
* phiên bản phát hành của `kube-apiserver`**{{< skew currentVersion >}}**
114+
* phiên bản phát hành được cho phép của `kubectl`**{{< skew currentVersionAddMinor 1 >}}**, **{{< skew currentVersion >}}**, và **{{< skew currentVersionAddMinor -1 >}}**
115+
116+
{{< note >}}
117+
Trong trường hợp cụm HA chứa các instance `kube-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.
118+
{{< /note >}}
119+
120+
Ví dụ:
121+
122+
* phiên bản phát hành của các `kube-apiserver` instance trong cụm là **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}**
123+
* phiên bản phát hành được cho phép của `kubectl` sẽ là **{{< skew currentVersion >}}****{{< skew currentVersionAddMinor -1 >}}** (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`)
124+
125+
## Thứ tự nâng cấp thành phần
126+
127+
Độ 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 **{{< skew currentVersionAddMinor -1 >}}** sang phiên bản **{{< skew currentVersion >}}**.
128+
129+
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:
130+
131+
* Đả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)
132+
* 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
133+
134+
Chẳng hạn, hiện tại bạn đang sử dụng phiên bản phát hành {{<skew currentVersionAddMinor -1>}}, 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 {{<skew currentVersion>}}.
135+
136+
### kube-apiserver
137+
138+
Điều kiện:
139+
140+
* Trường hợp cụm đơn, phiên bản phát hành của `kube-apiserver` đang là **{{< skew currentVersionAddMinor -1 >}}**
141+
* Trường hợp cụm cài đặt HA, tất cả các instance của `kube-apiserver` đang là **{{< skew currentVersionAddMinor -1 >}}** hoặc
142+
**{{< skew currentVersion >}}** (đ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)
143+
* 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 **{{< skew currentVersionAddMinor -1 >}}** (đ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)
144+
* 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 **{{< skew currentVersionAddMinor -1 >}}** hoặc **{{< skew currentVersionAddMinor -2 >}}**
145+
(đ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)
146+
* 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:
147+
* `ValidatingWebhookConfiguration``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 **{{< skew currentVersion >}}** (hoặc sử dụng [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) đối với các phiên bản v1.15+)
148+
* 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 **{{< skew currentVersion >}}**
149+
150+
Tiến hành nâng cấp `kube-apiserver` lên phiên bản **{{< skew currentVersion >}}**.
151+
152+
153+
{{< note >}}
154+
Theo chính sách cho [API deprecation](/docs/reference/using-api/deprecation-policy/)
155+
[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md), `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
156+
{{< /note >}}
157+
158+
### kube-controller-manager, kube-scheduler, cloud-controller-manager
159+
160+
Điều kiện:
161+
162+
* Phiên bản phát hành của `kube-aapiserver` phải là **{{< skew currentVersion >}}**
163+
(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)
164+
165+
Tiến hành nâng cấp `kube-controller-manager`, `kube-scheduler`, và
166+
`cloud-controller-manager` lên phiên bản **{{< skew currentVersion >}}**.
167+
168+
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.
169+
170+
### kubelet
171+
172+
Điều kiện:
173+
174+
* Phiên bản phát hành của `kube-apiserver``kubelet` sẽ tương tác phải là **{{< skew currentVersion >}}**
175+
176+
Có thể nâng cấp phiên bản phát hành của `kubelet` lên **{{< skew currentVersion >}}** (hoặc cũng có thể để nguyên ở **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, hoặc **{{< skew currentVersionAddMinor -3 >}}**)
177+
178+
{{< note >}}
179+
Trước khi tiến hành nâng cấp phiên bản `kubelet`, [drain](/docs/tasks/administer-cluster/safely-drain-node/) 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ợ.
180+
{{</ note >}}
181+
182+
{{< warning >}}
183+
Sử dụng một cụm có chứa các `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.)
184+
{{</ warning >}}
185+
186+
### kube-proxy
187+
188+
Điều kiện:
189+
190+
* Phiên bản phát hành của `kube-apiserver``kube-proxy` sẽ tương tác phải là **{{< skew currentVersion >}}**
191+
192+
Có thể nâng cấp phiên bản phát hành của `kube-proxy` lên **{{< skew currentVersion >}}** (hoặc cũng có thể để nguyên ở **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, hoặc **{{< skew currentVersionAddMinor -3 >}}**)
193+
194+
{{< warning >}}
195+
Sử dụng một cụm có chứa các `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.)
196+
{{</ warning >}}

0 commit comments

Comments
 (0)