Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,50 @@
|
||||
---
|
||||
linktitle: 发行版本历史
|
||||
title: 发行版本
|
||||
type: docs
|
||||
---
|
||||
<!--
|
||||
linktitle: Release History
|
||||
title: Releases
|
||||
type: docs
|
||||
-->
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). Kubernetes 1.18 and older received approximately 9 months of patch support.
|
||||
-->
|
||||
Kubernetes 项目维护最近三个次要版本（{{< skew latestVersion >}}、{{< skew prevMinorVersion >}}、{{< skew oldMinorVersion >}}）的发布分支。
|
||||
Kubernetes 1.19 和更新版本获得[大约 1 年的补丁支持](/zh/releases/patch-releases/#support-period)。
|
||||
Kubernetes 1.18 及更早版本获得了大约 9 个月的补丁支持周期。
|
||||
|
||||
<!--
|
||||
Kubernetes versions are expressed as **x.y.z**,
|
||||
where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
|
||||
More information in the [version skew policy](/releases/version-skew-policy/) document.
|
||||
-->
|
||||
|
||||
Kubernetes 版本表示为 **x.y.z**，
|
||||
其中 **x** 是主要版本，**y** 是次要版本，**z** 是补丁版本，遵循[语义版本控制](https://semver.org/)术语。
|
||||
|
||||
更多信息在[版本偏差策略](/zh/releases/version-skew-policy/)文档中。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!-- ## Release History -->
|
||||
## 发行版本历史
|
||||
|
||||
{{< release-data >}}
|
||||
|
||||
<!-- ## Upcoming Release -->
|
||||
## 未来的发行版本
|
||||
|
||||
<!--
|
||||
Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release!
|
||||
-->
|
||||
查看[时间表](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}})，
|
||||
Kubernetes **{{< skew nextMinorVersion >}}** 版本即将发行！
|
||||
|
||||
<!-- ## Helpful Resources -->
|
||||
## 有用的资源
|
||||
@@ -0,0 +1,168 @@
|
||||
---
|
||||
title: 下载 Kubernetes
|
||||
type: docs
|
||||
---
|
||||
<!--
|
||||
title: Download Kubernetes
|
||||
type: docs
|
||||
-->
|
||||
|
||||
<!--
|
||||
Kubernetes ships binaries for each component as well as a standard set of client
|
||||
applications to bootstrap or interact with a cluster. Components like the
|
||||
API server are capable of running within container images inside of a
|
||||
cluster. Those components are also shipped in container images as part of the
|
||||
official release process. All binaries as well as container images are available
|
||||
for multiple operating systems as well as hardware architectures.
|
||||
-->
|
||||
Kubernetes 为每个组件提供二进制文件以及一组标准的客户端应用程序用来引导集群或与集群交互。
|
||||
像 API 服务器这样的组件能够在集群内的容器镜像中运行。
|
||||
作为官方发布过程的一部分，这些组件也以容器镜像的形式提供。
|
||||
所有二进制文件和容器镜像都可用于多种操作系统和硬件架构。
|
||||
|
||||
<!--
|
||||
## Container Images
|
||||
|
||||
All Kubernetes container images are deployed to the
|
||||
[k8s.gcr.io](https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/GLOBAL)
|
||||
container registry.
|
||||
-->
|
||||
## 容器镜像
|
||||
|
||||
所有 Kubernetes 容器镜像都部署到
|
||||
[k8s.gcr.io](https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/GLOBAL) 容器仓库。
|
||||
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
For Kubernetes {{< param "version" >}}, the following
|
||||
container images are signed using [cosign](https://github.com/sigstore/cosign)
|
||||
signatures:
|
||||
-->
|
||||
对于 Kubernetes {{< param "version" >}}，以下容器镜像使用
|
||||
[cosign](https://github.com/sigstore/cosign) 进行签名：
|
||||
|
||||
<!--
|
||||
| Container Image | Supported Architectures |
|
||||
-->
|
||||
| 容器镜像 | 支持架构 |
|
||||
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
|
||||
| [k8s.gcr.io/kube-apiserver:{{< param "fullversion" >}}][0] | [amd64][0-amd64], [arm][0-arm], [arm64][0-arm64], [ppc64le][0-ppc64le], [s390x][0-s390x] |
|
||||
| [k8s.gcr.io/kube-controller-manager:{{< param "fullversion" >}}][1] | [amd64][1-amd64], [arm][1-arm], [arm64][1-arm64], [ppc64le][1-ppc64le], [s390x][1-s390x] |
|
||||
| [k8s.gcr.io/kube-proxy:{{< param "fullversion" >}}][2] | [amd64][2-amd64], [arm][2-arm], [arm64][2-arm64], [ppc64le][2-ppc64le], [s390x][2-s390x] |
|
||||
| [k8s.gcr.io/kube-scheduler:{{< param "fullversion" >}}][3] | [amd64][3-amd64], [arm][3-arm], [arm64][3-arm64], [ppc64le][3-ppc64le], [s390x][3-s390x] |
|
||||
| [k8s.gcr.io/conformance:{{< param "fullversion" >}}][4] | [amd64][4-amd64], [arm][4-arm], [arm64][4-arm64], [ppc64le][4-ppc64le], [s390x][4-s390x] |
|
||||
|
||||
[0]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver
|
||||
[0-amd64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver-amd64
|
||||
[0-arm]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver-arm
|
||||
[0-arm64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver-arm64
|
||||
[0-ppc64le]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver-ppc64le
|
||||
[0-s390x]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver-s390x
|
||||
[1]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-controller-manager
|
||||
[1-amd64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-controller-manager-amd64
|
||||
[1-arm]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-controller-manager-arm
|
||||
[1-arm64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-controller-manager-arm64
|
||||
[1-ppc64le]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-controller-manager-ppc64le
|
||||
[1-s390x]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-controller-manager-s390x
|
||||
[2]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-proxy
|
||||
[2-amd64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-proxy-amd64
|
||||
[2-arm]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-proxy-arm
|
||||
[2-arm64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-proxy-arm64
|
||||
[2-ppc64le]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-proxy-ppc64le
|
||||
[2-s390x]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-proxy-s390x
|
||||
[3]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-scheduler
|
||||
[3-amd64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-scheduler-amd64
|
||||
[3-arm]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-scheduler-arm
|
||||
[3-arm64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-scheduler-arm64
|
||||
[3-ppc64le]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-scheduler-ppc64le
|
||||
[3-s390x]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-scheduler-s390x
|
||||
[4]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/conformance
|
||||
[4-amd64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/conformance-amd64
|
||||
[4-arm]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/conformance-arm
|
||||
[4-arm64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/conformance-arm64
|
||||
[4-ppc64le]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/conformance-ppc64le
|
||||
[4-s390x]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/conformance-s390x
|
||||
|
||||
<!--
|
||||
All container images are available for multiple architectures, whereas the
|
||||
container runtime should choose the correct one based on the underlying
|
||||
platform. It is also possible to pull a dedicated architecture by suffixing the
|
||||
container image name, for example
|
||||
[`k8s.gcr.io/kube-apiserver-arm64:{{< param "fullversion" >}}`][0-arm64]. All
|
||||
those derivations are signed in the same way as the multi-architecture manifest lists.
|
||||
-->
|
||||
所有容器镜像都支持多种体系结构，容器运行时应根据下层平台选择正确的镜像。
|
||||
也可以通过给容器镜像名称加后缀来拉取特定体系结构的镜像，例如
|
||||
[`k8s.gcr.io/kube-apiserver-arm64:{{< param "fullversion" >}}`][0-arm64]。
|
||||
所有这些派生镜像都以与多架构清单列表相同的方式签名。
|
||||
|
||||
<!--
|
||||
The Kubernetes project publishes a list of signed Kubernetes container images
|
||||
in SBoM (Software Bill of Materials) format.
|
||||
You can fetch that list using:
|
||||
-->
|
||||
Kubernetes 项目以 SBoM（软件物料清单）格式发布已签名的 Kubernetes 容器镜像列表。
|
||||
你可以使用以下方法获取该列表：
|
||||
|
||||
```shell
|
||||
curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/latest.txt)/release" | awk '/PackageName: k8s.gcr.io\// {print $2}'
|
||||
```
|
||||
<!--
|
||||
For Kubernetes v{{< skew currentVersion >}}, the only kind of code artifact that
|
||||
you can verify integrity for is a container image, using the experimental
|
||||
signing support.
|
||||
|
||||
To manually verify signed container images of Kubernetes core components, refer to
|
||||
[Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-images).
|
||||
-->
|
||||
对于 Kubernetes v{{< skew currentVersion >}}，唯一可以验证完整性的代码工件就是容器镜像，它使用实验性签名支持。
|
||||
|
||||
如需手动验证 Kubernetes 核心组件的签名容器镜像，请参考[验证签名容器镜像](/zh/docs/tasks/administer-cluster/verify-signed-images)。
|
||||
|
||||
<!--
|
||||
## Binaries
|
||||
|
||||
Find links to download Kubernetes components (and their checksums) in the [CHANGELOG](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) files.
|
||||
|
||||
Alternately, use [downloadkubernetes.com](https://www.downloadkubernetes.com/) to filter by version and architecture.
|
||||
-->
|
||||
## 二进制
|
||||
|
||||
在 [CHANGELOG](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) 文件中找到下载 Kubernetes 组件（及其校验和）的链接。
|
||||
|
||||
或者，使用 [downloadkubernetes.com](https://www.downloadkubernetes.com/) 按版本和架构进行过滤。
|
||||
|
||||
### kubectl
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows
|
||||
you to run commands against Kubernetes clusters.
|
||||
|
||||
You can use kubectl to deploy applications, inspect and manage cluster resources,
|
||||
and view logs. For more information including a complete list of kubectl operations, see the
|
||||
[`kubectl` reference documentation](/docs/reference/kubectl/).
|
||||
-->
|
||||
Kubernetes 命令行工具 [kubectl](/zh/docs/reference/kubectl/kubectl/) 允许你对 Kubernetes 集群执行命令。
|
||||
|
||||
你可以使用 kubectl 部署应用程序、检查和管理集群资源以及查看日志。
|
||||
有关更多信息，包括 kubectl 操作的完整列表，请参阅
|
||||
[`kubectl` 参考文档](/zh/docs/reference/kubectl/)。
|
||||
|
||||
<!--
|
||||
kubectl is installable on a variety of Linux platforms, macOS and Windows.
|
||||
Find your preferred operating system below.
|
||||
|
||||
- [Install kubectl on Linux](/docs/tasks/tools/install-kubectl-linux)
|
||||
- [Install kubectl on macOS](/docs/tasks/tools/install-kubectl-macos)
|
||||
- [Install kubectl on Windows](/docs/tasks/tools/install-kubectl-windows)
|
||||
-->
|
||||
kubectl 可安装在各种 Linux 平台、macOS 和 Windows 上。
|
||||
在下方找到你首选的操作系统。
|
||||
|
||||
- [在 Linux 上安装 kubectl](/zh/docs/tasks/tools/install-kubectl-linux)
|
||||
- [在 macOS 上安装 kubectl](/zh/docs/tasks/tools/install-kubectl-macos)
|
||||
- [在 Windows 上安装 kubectl](/zh/docs/tasks/tools/install-kubectl-windows)
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
linktitle: 发行版本说明
|
||||
title: 说明
|
||||
type: docs
|
||||
description: >
|
||||
Kubernetes 发行版本说明。
|
||||
sitemap:
|
||||
priority: 0.5
|
||||
---
|
||||
<!--
|
||||
linktitle: Release Notes
|
||||
title: Notes
|
||||
type: docs
|
||||
description: >
|
||||
Kubernetes release notes.
|
||||
sitemap:
|
||||
priority: 0.5
|
||||
-->
|
||||
|
||||
<!--
|
||||
Release notes can be found by reading the [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) that matches your Kubernetes version. View the changelog for {{< skew currentVersionAddMinor 0 >}} on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md).
|
||||
|
||||
Alternately, release notes can be searched and filtered online at: [relnotes.k8s.io](https://relnotes.k8s.io). View filtered release notes for {{< skew currentVersionAddMinor 0 >}} on [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0).
|
||||
-->
|
||||
|
||||
可以通过阅读与你的 Kubernetes 版本对应的
|
||||
[Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)
|
||||
找到发行版本说明。
|
||||
在 [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md)
|
||||
上查看 {{< skew currentVersionAddMinor 0 >}} 的变更日志。
|
||||
|
||||
或者，可以在以下位置在线搜索和筛选发行版本说明：[relnotes.k8s.io](https://relnotes.k8s.io)。
|
||||
在 [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0)
|
||||
上查看 {{< skew currentVersionAddMinor 0 >}} 的筛选后的版本说明。
|
||||
@@ -0,0 +1,312 @@
|
||||
---
|
||||
title: 补丁版本
|
||||
type: docs
|
||||
---
|
||||
<!--
|
||||
title: Patch Releases
|
||||
type: docs
|
||||
-->
|
||||
|
||||
<!--
|
||||
Schedule and team contact information for Kubernetes patch releases.
|
||||
|
||||
For general information about Kubernetes release cycle, see the
|
||||
[release process description].
|
||||
-->
|
||||
Kubernetes 补丁版本的发布时间表和团队联系信息。
|
||||
|
||||
有关 Kubernetes 发布周期的常规信息，请参阅[发布流程说明]。
|
||||
|
||||
<!--
|
||||
## Cadence
|
||||
|
||||
Our typical patch release cadence is monthly. It is
|
||||
commonly a bit faster (1 to 2 weeks) for the earliest patch releases
|
||||
after a 1.X minor release. Critical bug fixes may cause a more
|
||||
immediate release outside of the normal cadence. We also aim to not make
|
||||
releases during major holiday periods.
|
||||
-->
|
||||
## 节奏 {#cadence}
|
||||
|
||||
我们的补丁发布节奏通常是每月一次。
|
||||
在 1.X 次要版本之后，最早的补丁版本通常要快一些（提前 1 到 2 周）。
|
||||
严重错误修复可能会导致超出正常节奏而更快速的发布。
|
||||
我们尽量避免在主假期期间发布。
|
||||
|
||||
<!--
|
||||
## Contact
|
||||
|
||||
See the [Release Managers page][release-managers] for full contact details on the Patch Release Team.
|
||||
|
||||
Please give us a business day to respond - we may be in a different timezone!
|
||||
|
||||
In between releases the team is looking at incoming cherry pick requests on a weekly basis. The team will get in touch with submitters via GitHub PR, SIG channels in Slack, and direct messages
|
||||
in Slack and [email](mailto:release-managers-private@kubernetes.io) if there are questions on the PR.
|
||||
-->
|
||||
## 联系 {#contact}
|
||||
|
||||
有关补丁发布团队的完整联系方式，请参阅[发布管理员页面][release-managers]。
|
||||
|
||||
请给我们一个工作日回复，因为我们可能在不同的时区！
|
||||
|
||||
在两次发布之间，团队每周都会查看收到的 cherry pick 请求。
|
||||
如果对 PR 有任何问题，团队将通过 GitHub PR、Slack 中的 SIG 频道以及 Slack 中的直接消息和
|
||||
[email](mailto:release-managers-private@kubernetes.io) 与提交者取得联系。
|
||||
|
||||
<!--
|
||||
## Cherry picks
|
||||
|
||||
Please follow the [cherry pick process][cherry-picks].
|
||||
|
||||
Cherry picks must be merge-ready in GitHub with proper labels (e.g.,
|
||||
`approved`, `lgtm`, `release-note`) and passing CI tests ahead of the
|
||||
cherry pick deadline. This is typically two days before the target
|
||||
release, but may be more. Earlier PR readiness is better, as we
|
||||
need time to get CI signal after merging your cherry picks ahead
|
||||
of the actual release.
|
||||
|
||||
Cherry pick PRs which miss merge criteria will be carried over and tracked
|
||||
for the next patch release.
|
||||
-->
|
||||
|
||||
## Cherry Pick
|
||||
|
||||
请遵循 [Cherry Pick 流程][cherry-picks]。
|
||||
|
||||
Cherry Pick 必须在 GitHub 中准备好合并，带有适当的标签（例如 `approved`、`lgtm`、`release-note`），
|
||||
并在 Cherry Pick 截止日期之前通过 CI 测试。这通常是目标发布前两天，但可能更早。
|
||||
PR 越早准备好越好，因为在实际发布之前，合并了你的 Cherry Pick 后，我们需要时间来获取 CI 信号。
|
||||
|
||||
不符合合并标准的 Cherry Pick PR 将被带入下一个补丁版本中跟踪。
|
||||
|
||||
<!--
|
||||
## Support Period
|
||||
|
||||
In accordance with the [yearly support KEP][yearly-support], the Kubernetes
|
||||
Community will support active patch release series for a period of roughly
|
||||
fourteen (14) months.
|
||||
|
||||
The first twelve months of this timeframe will be considered the standard
|
||||
period.
|
||||
|
||||
Towards the end of the twelve month, the following will happen:
|
||||
|
||||
- [Release Managers][release-managers] will cut a release
|
||||
- The patch release series will enter maintenance mode
|
||||
-->
|
||||
## 支持周期 {#support-period}
|
||||
|
||||
根据[年度 KEP][yearly-support]，Kubernetes 社区将在大约 14 个月的时间内支持活跃的补丁发布系列。
|
||||
|
||||
此时间范围的前 12 个月将被视为标准周期。
|
||||
|
||||
在 12 个月后，将发生以下事情：
|
||||
|
||||
- [发布管理员][release-managers]将删除一个版本
|
||||
- 补丁发布系列将进入维护模式
|
||||
|
||||
<!--
|
||||
During the two-month maintenance mode period, Release Managers may cut
|
||||
additional maintenance releases to resolve:
|
||||
|
||||
- CVEs (under the advisement of the Security Response Committee)
|
||||
- dependency issues (including base image updates)
|
||||
- critical core component issues
|
||||
|
||||
At the end of the two-month maintenance mode period, the patch release series
|
||||
will be considered EOL (end of life) and cherry picks to the associated branch
|
||||
are to be closed soon afterwards.
|
||||
|
||||
Note that the 28th of the month was chosen for maintenance mode and EOL target
|
||||
dates for simplicity (every month has it).
|
||||
-->
|
||||
在两个月的维护模式期间，发布管理员可能会删减额外的维护版本以解决：
|
||||
|
||||
- CVE（在安全响应委员会的建议下）
|
||||
- 依赖问题（包括基础镜像更新）
|
||||
- 关键核心组件问题
|
||||
|
||||
在两个月的维护模式期结束时，补丁发布系列将被视为 EOL（生命周期结束），相关分支的 Cherry Pick 将很快关闭。
|
||||
|
||||
请注意，为简单起见，选择每月 28 日作为维护模式和 EOL 目标日期（每个月都有）。
|
||||
|
||||
<!--
|
||||
## Upcoming Monthly Releases
|
||||
|
||||
Timelines may vary with the severity of bug fixes, but for easier planning we
|
||||
will target the following monthly release points. Unplanned, critical
|
||||
releases may also occur in between these.
|
||||
-->
|
||||
## 未来发布的月度版本 {#upcoming-monthly-releases}
|
||||
|
||||
时间表可能会因错误修复的严重程度而有所不同，但为了便于规划，我们将针对以下每月发布点。
|
||||
计划外的关键版本也可能发生在这些版本之间。
|
||||
|
||||
<!--
|
||||
| Monthly Patch Release | Cherry Pick Deadline | Target date |
|
||||
| --------------------- | -------------------- | ----------- |
|
||||
| May 2022 | 2022-05-20 | 2022-05-24 |
|
||||
| June 2022 | 2022-06-10 | 2022-06-15 |
|
||||
| July 2022 | 2022-07-08 | 2022-07-13 |
|
||||
| August 2022 | 2022-08-12 | 2022-08-16 |
|
||||
-->
|
||||
| 月度补丁发布 | Cherry Pick 截止日期 | 目标日期 |
|
||||
| ------------ | ------------------ | ----------- |
|
||||
| 2022 年 5 月 | 2022-05-20 | 2022-05-24 |
|
||||
| 2022 年 6 月 | 2022-06-10 | 2022-06-15 |
|
||||
| 2022 年 7 月 | 2022-07-08 | 2022-07-13 |
|
||||
| 2022 年 8 月 | 2022-08-12 | 2022-08-16 |
|
||||
|
||||
<!--
|
||||
## Detailed Release History for Active Branches
|
||||
|
||||
### 1.24
|
||||
|
||||
Next patch release is **1.24.1**
|
||||
|
||||
End of Life for **1.24** is **2023-09-29**
|
||||
|
||||
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
|
||||
|---------------|----------------------|-------------|------|
|
||||
| 1.24.1 | 2022-05-20 | 2022-05-24 | |
|
||||
-->
|
||||
## 活动分支的详细发布历史 {#detailed-release-history-for-active-branches}
|
||||
|
||||
### 1.24
|
||||
|
||||
下一个补丁版本是 **1.24.1**
|
||||
|
||||
**1.24** 的生命周期结束时间为 **2023-09-29**
|
||||
|
||||
| 补丁发布 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|
||||
|--------|---------------------|------------|-----|
|
||||
| 1.24.1 | 2022-05-20 | 2022-05-24 | |
|
||||
|
||||
### 1.23
|
||||
|
||||
<!--
|
||||
**1.23** enters maintenance mode on **2022-12-28**.
|
||||
|
||||
End of Life for **1.23** is **2023-02-28**.
|
||||
-->
|
||||
**1.23** 于 **2022-12-28** 进入维护模式。
|
||||
|
||||
**1.23** 的生命周期结束时间为 **2023-02-28**。
|
||||
|
||||
<!--
|
||||
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
|
||||
|
||||
[Out-of-Band Release](https://groups.google.com/a/kubernetes.io/g/dev/c/Xl1sm-CItaY)
|
||||
-->
|
||||
| 补丁发布 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|
||||
|---------------|----------------------|-------------|------|
|
||||
| 1.23.7 | 2022-05-20 | 2022-05-24 | |
|
||||
| 1.23.6 | 2022-04-08 | 2022-04-13 | |
|
||||
| 1.23.5 | 2022-03-11 | 2022-03-16 | |
|
||||
| 1.23.4 | 2022-02-11 | 2022-02-16 | |
|
||||
| 1.23.3 | 2022-01-24 | 2022-01-25 | [带外发布](https://groups.google.com/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) |
|
||||
| 1.23.2 | 2022-01-14 | 2022-01-19 | |
|
||||
| 1.23.1 | 2021-12-14 | 2021-12-16 | |
|
||||
|
||||
### 1.22
|
||||
|
||||
<!--
|
||||
**1.22** enters maintenance mode on **2022-08-28**
|
||||
|
||||
End of Life for **1.22** is **2022-10-28**
|
||||
-->
|
||||
**1.22** 于 **2022-08-28** 进入维护模式
|
||||
|
||||
**1.22** 的生命周期结束时间为 **2022-10-28**
|
||||
|
||||
<!--
|
||||
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
|
||||
-->
|
||||
| 补丁发布 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|
||||
|---------------|----------------------|-------------|------|
|
||||
| 1.22.10 | 2022-05-20 | 2022-05-24 | |
|
||||
| 1.22.9 | 2022-04-08 | 2022-04-13 | |
|
||||
| 1.22.8 | 2022-03-11 | 2022-03-16 | |
|
||||
| 1.22.7 | 2022-02-11 | 2022-02-16 | |
|
||||
| 1.22.6 | 2022-01-14 | 2022-01-19 | |
|
||||
| 1.22.5 | 2021-12-10 | 2021-12-15 | |
|
||||
| 1.22.4 | 2021-11-12 | 2021-11-17 | |
|
||||
| 1.22.3 | 2021-10-22 | 2021-10-27 | |
|
||||
| 1.22.2 | 2021-09-10 | 2021-09-15 | |
|
||||
| 1.22.1 | 2021-08-16 | 2021-08-19 | |
|
||||
|
||||
### 1.21
|
||||
|
||||
<!--
|
||||
**1.21** enters maintenance mode on **2022-04-28**
|
||||
|
||||
End of Life for **1.21** is **2022-06-28**
|
||||
-->
|
||||
**1.21** 于 **2022-04-28** 进入维护模式
|
||||
|
||||
**1.21** 的生命周期结束时间为 **2022-06-28**
|
||||
|
||||
<!--
|
||||
| Patch Release | Cherry Pick Deadline | Target Date | Note |
|
||||
|
||||
[Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs)
|
||||
-->
|
||||
| 补丁发布 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|
||||
| ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- |
|
||||
| 1.21.13 | 2022-05-20 | 2022-05-24 | |
|
||||
| 1.21.12 | 2022-04-08 | 2022-04-13 | |
|
||||
| 1.21.11 | 2022-03-11 | 2022-03-16 | |
|
||||
| 1.21.10 | 2022-02-11 | 2022-02-16 | |
|
||||
| 1.21.9 | 2022-01-14 | 2022-01-19 | |
|
||||
| 1.21.8 | 2021-12-10 | 2021-12-15 | |
|
||||
| 1.21.7 | 2021-11-12 | 2021-11-17 | |
|
||||
| 1.21.6 | 2021-10-22 | 2021-10-27 | |
|
||||
| 1.21.5 | 2021-09-10 | 2021-09-15 | |
|
||||
| 1.21.4 | 2021-08-07 | 2021-08-11 | |
|
||||
| 1.21.3 | 2021-07-10 | 2021-07-14 | |
|
||||
| 1.21.2 | 2021-06-12 | 2021-06-16 | |
|
||||
| 1.21.1 | 2021-05-07 | 2021-05-12 | [版本回退](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) |
|
||||
|
||||
<!--
|
||||
## Non-Active Branch History
|
||||
|
||||
These releases are no longer supported.
|
||||
-->
|
||||
## 非活动分支历史 {#non-active-branch-history}
|
||||
|
||||
不再支持这些版本。
|
||||
|
||||
<!--
|
||||
| Minor Version | Final Patch Release | EOL Date | Note |
|
||||
|
||||
Created to resolve regression introduced in 1.18.19
|
||||
|
||||
[Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs)
|
||||
-->
|
||||
| 次要版本 | 最终补丁发布版本 | EOL 日期 | 说明 |
|
||||
| ------------- | ------------------- | ---------- | ---------------------------------------------------------------------- |
|
||||
| 1.20 | 1.20.15 | 2022-02-28 | |
|
||||
| 1.19 | 1.19.16 | 2021-10-28 | |
|
||||
| 1.18 | 1.18.20 | 2021-06-18 | 创建用于解决 1.18.19 版本引入的回退 |
|
||||
| 1.18 | 1.18.19 | 2021-05-12 | [版本回退](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) |
|
||||
| 1.17 | 1.17.17 | 2021-01-13 | |
|
||||
| 1.16 | 1.16.15 | 2020-09-02 | |
|
||||
| 1.15 | 1.15.12 | 2020-05-06 | |
|
||||
| 1.14 | 1.14.10 | 2019-12-11 | |
|
||||
| 1.13 | 1.13.12 | 2019-10-15 | |
|
||||
| 1.12 | 1.12.10 | 2019-07-08 | |
|
||||
| 1.11 | 1.11.10 | 2019-05-01 | |
|
||||
| 1.10 | 1.10.13 | 2019-02-13 | |
|
||||
| 1.9 | 1.9.11 | 2018-09-29 | |
|
||||
| 1.8 | 1.8.15 | 2018-07-12 | |
|
||||
| 1.7 | 1.7.16 | 2018-04-04 | |
|
||||
| 1.6 | 1.6.13 | 2017-11-23 | |
|
||||
| 1.5 | 1.5.8 | 2017-10-01 | |
|
||||
| 1.4 | 1.4.12 | 2017-04-21 | |
|
||||
| 1.3 | 1.3.10 | 2016-11-01 | |
|
||||
| 1.2 | 1.2.7 | 2016-10-23 | |
|
||||
|
||||
[cherry-picks]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md
|
||||
[release-managers]: /releases/release-managers
|
||||
[发布流程说明]: /releases/release
|
||||
[yearly-support]: https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
@@ -0,0 +1,378 @@
|
||||
---
|
||||
title: 发布管理员
|
||||
type: docs
|
||||
---
|
||||
<!--
|
||||
title: Release Managers
|
||||
type: docs
|
||||
-->
|
||||
|
||||
<!--
|
||||
"Release Managers" is an umbrella term that encompasses the set of Kubernetes
|
||||
contributors responsible for maintaining release branches, tagging releases,
|
||||
and building/packaging Kubernetes.
|
||||
|
||||
The responsibilities of each role are described below.
|
||||
-->
|
||||
“发布管理员（Release Managers）”是一个总称，包括一批负责维护发布分支、标记发行版本以及构建/打包
|
||||
Kubernetes 的 Kubernetes 贡献者。
|
||||
|
||||
每个角色的职责如下所述。
|
||||
|
||||
<!--
|
||||
- [Contact](#contact)
|
||||
- [Security Embargo Policy](#security-embargo-policy)
|
||||
- [Handbooks](#handbooks)
|
||||
- [Release Managers](#release-managers)
|
||||
- [Becoming a Release Manager](#becoming-a-release-manager)
|
||||
- [Release Manager Associates](#release-manager-associates)
|
||||
- [Becoming a Release Manager Associate](#becoming-a-release-manager-associate)
|
||||
- [Build Admins](#build-admins)
|
||||
- [SIG Release Leads](#sig-release-leads)
|
||||
- [Chairs](#chairs)
|
||||
- [Technical Leads](#technical-leads)
|
||||
-->
|
||||
- [联系方式](#contact)
|
||||
- [安全禁运政策](#security-embargo-policy)
|
||||
- [手册](#handbooks)
|
||||
- [发布管理员](#release-managers)
|
||||
- [成为发布管理员](#becoming-a-release-manager)
|
||||
- [发布管理员助理](#release-manager-associates)
|
||||
- [成为发布管理员助理](#becoming-a-release-manager-associate)
|
||||
- [构建管理员](#build-admins)
|
||||
- [SIG 发布负责人](#sig-release-leads)
|
||||
- [首席](#chairs)
|
||||
- [技术负责人](#technical-leads)
|
||||
|
||||
<!--
|
||||
## Contact
|
||||
|
||||
| Mailing List | Slack | Visibility | Usage | Membership |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| [release-managers@kubernetes.io](mailto:release-managers@kubernetes.io) | [#release-management](https://kubernetes.slack.com/messages/CJH2GBF7Y) (channel) / @release-managers (user group) | Public | Public discussion for Release Managers | All Release Managers (including Associates, Build Admins, and SIG Chairs) |
|
||||
| [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership |
|
||||
| [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Security Response Committee | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) |
|
||||
-->
|
||||
## 联系方式 #{contact}
|
||||
|
||||
| 邮件列表 | Slack | 可见 | 用法 | 会员资格 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| [release-managers@kubernetes.io](mailto:release-managers@kubernetes.io) | [#release-management](https://kubernetes.slack.com/messages/CJH2GBF7Y)（频道）/@release-managers（用户组）| 公共 | 发布管理员的公开讨论 | 所有发布管理员（包括助理、构建管理员和 SIG 主席）|
|
||||
| [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | 不适用 | 私人 | 拥有特权的发布管理员私人讨论 | 发布管理员，SIG Release 负责人 |
|
||||
| [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG)（频道）/@security-rel-team（用户组）| 私人 | 与安全响应委员会协调的安全发布 | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) |
|
||||
|
||||
<!--
|
||||
### Security Embargo Policy
|
||||
|
||||
Some information about releases is subject to embargo and we have defined policy about how those embargoes are set. Please refer to the [Security Embargo Policy](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy) for more information.
|
||||
-->
|
||||
### 安全禁运政策 {#security-embargo-policy}
|
||||
|
||||
发布的相关信息受到禁运，我们已经定义了有关如何设置这些禁运的政策。
|
||||
更多信息请参考[安全禁运政策](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy)。
|
||||
|
||||
<!--
|
||||
## Handbooks
|
||||
|
||||
**NOTE: The Patch Release Team and Branch Manager handbooks will be de-duplicated at a later date.**
|
||||
|
||||
- [Patch Release Team][handbook-patch-release]
|
||||
- [Branch Managers][handbook-branch-mgmt]
|
||||
- [Build Admins][handbook-packaging]
|
||||
-->
|
||||
## 手册 {#handbooks}
|
||||
|
||||
**注意：补丁发布团队和分支管理员手册以后将会删除重复数据。**
|
||||
|
||||
- [补丁发布团队][handbook-patch-release]
|
||||
- [分支管理员][handbook-branch-mgmt]
|
||||
- [构建管理员][handbook-packaging]
|
||||
|
||||
<!--
|
||||
## Release Managers
|
||||
|
||||
**Note:** The documentation might refer to the Patch Release Team and the
|
||||
Branch Management role. Those two roles were consolidated into the
|
||||
Release Managers role.
|
||||
|
||||
Minimum requirements for Release Managers and Release Manager Associates are:
|
||||
|
||||
- Familiarity with basic Unix commands and able to debug shell scripts.
|
||||
- Familiarity with branched source code workflows via `git` and associated
|
||||
`git` command line invocations.
|
||||
- General knowledge of Google Cloud (Cloud Build and Cloud Storage).
|
||||
- Open to seeking help and communicating clearly.
|
||||
- Kubernetes Community [membership][community-membership]
|
||||
-->
|
||||
## 发布管理员 {#release-managers}
|
||||
|
||||
**注意：** 文档可能涉及补丁发布团队和分支管理角色。这两个角色被合并到发布管理员角色中。
|
||||
|
||||
发布管理员和发布管理员助理的最低要求是：
|
||||
|
||||
- 熟悉基本的 Unix 命令并能够调试 shell 脚本。
|
||||
- 熟悉通过 `git` 和 `git` 相关的命令行触发的分支源代码工作流。
|
||||
- 谷歌云的常识（云构建和云存储）。
|
||||
- 乐于寻求帮助和清晰地沟通。
|
||||
- Kubernetes 社区 [会员资格][community-membership]
|
||||
|
||||
<!--
|
||||
Release Managers are responsible for:
|
||||
|
||||
- Coordinating and cutting Kubernetes releases:
|
||||
- Patch releases (`x.y.z`, where `z` > 0)
|
||||
- Minor releases (`x.y.z`, where `z` = 0)
|
||||
- Pre-releases (alpha, beta, and release candidates)
|
||||
- Working with the [Release Team][release-team] through each
|
||||
release cycle
|
||||
- Setting the [schedule and cadence for patch releases][patches]
|
||||
- Maintaining the release branches:
|
||||
- Reviewing cherry picks
|
||||
- Ensuring the release branch stays healthy and that no unintended patch
|
||||
gets merged
|
||||
- Mentoring the [Release Manager Associates](#associates) group
|
||||
- Actively developing features and maintaining the code in k/release
|
||||
- Supporting Release Manager Associates and contributors through actively
|
||||
participating in the Buddy program
|
||||
- Check in monthly with Associates and delegate tasks, empower them to cut
|
||||
releases, and mentor
|
||||
- Being available to support Associates in onboarding new contributors e.g.,
|
||||
answering questions and suggesting appropriate work for them to do
|
||||
-->
|
||||
发布管理员负责：
|
||||
|
||||
- 协调和确定 Kubernetes 发行版本：
|
||||
- 补丁发布（`x.y.z`，其中 `z` > 0）
|
||||
- 次要版本（`x.y.z`，其中 `z` = 0）
|
||||
- 预发布（alpha、beta 和候选发布）
|
||||
- 通过每个发布周期与[发布小组][release-team]合作
|
||||
- 设置[补丁发布的时间表和节奏][patches]
|
||||
- 维护发布分支：
|
||||
- 审查 Cherry Pick
|
||||
- 确保发布分支保持健康并且没有合并意外的补丁
|
||||
- 指导[发布管理员助理](#associates)小组
|
||||
- 积极开发功能并维护 k/release 中的代码
|
||||
- 通过积极参与 Buddy 计划来支持发布管理员助理和贡献者
|
||||
- 每月与助理核对并委派任务，授权他们生成发行版本并指导工作
|
||||
- 支持助理小组加入新的贡献者，例如回答问题并建议他们做适当的工作
|
||||
|
||||
<!--
|
||||
This team at times works in close conjunction with the
|
||||
[Security Response Committee][src] and therefore should abide by the guidelines
|
||||
set forth in the [Security Release Process][security-release-process].
|
||||
|
||||
GitHub Access Controls: [@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers)
|
||||
|
||||
GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering)
|
||||
-->
|
||||
该团队有时与[安全响应委员会][src]密切合作，因此应遵守[安全发布流程][security-release-process]中规定的指导方针。
|
||||
|
||||
GitHub 访问控制：[@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers)
|
||||
|
||||
GitHub 提及：[@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering)
|
||||
|
||||
- Adolfo García Veytia ([@puerco](https://github.com/puerco))
|
||||
- Carlos Panato ([@cpanato](https://github.com/cpanato))
|
||||
- Marko Mudrinić ([@xmudrii](https://github.com/xmudrii))
|
||||
- Nabarun Pal ([@palnabarun](https://github.com/palnabarun))
|
||||
- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert))
|
||||
- Stephen Augustus ([@justaugustus](https://github.com/justaugustus))
|
||||
- Verónica López ([@verolop](https://github.com/verolop))
|
||||
|
||||
<!--
|
||||
### Becoming a Release Manager
|
||||
|
||||
To become a Release Manager, one must first serve as a Release Manager
|
||||
Associate. Associates graduate to Release Manager by actively working on
|
||||
releases over several cycles and:
|
||||
|
||||
- demonstrating the willingness to lead
|
||||
- tag-teaming with Release Managers on patches, to eventually cut a release
|
||||
independently
|
||||
- because releases have a limiting function, we also consider substantial
|
||||
contributions to image promotion and other core Release Engineering tasks
|
||||
- questioning how Associates work, suggesting improvements, gathering feedback,
|
||||
and driving change
|
||||
- being reliable and responsive
|
||||
- leaning into advanced work that requires Release Manager-level access and
|
||||
privileges to complete
|
||||
-->
|
||||
### 成为发布管理员 {#becoming-a-release-manager}
|
||||
|
||||
要成为发布管理员，首先必须担任发布管理员助理。助理通过在多个周期内积极处理发布，从而毕业成为发布管理员，并且：
|
||||
|
||||
- 表现出带头的意愿
|
||||
- 与发布管理员合作，为补丁打标记，最终独立制作发行版本
|
||||
- 因为发布具有限制功能，我们还考虑对镜像推广和其他核心发布工程任务的实质性贡献
|
||||
- 质疑助理的工作方式、提出改进建议、收集反馈并推动变革
|
||||
- 可靠且反应迅速
|
||||
- 专注于需要发布管理员级别访问和权限才能完成的高级工作
|
||||
|
||||
<!--
|
||||
## Release Manager Associates
|
||||
|
||||
Release Manager Associates are apprentices to the Release Managers, formerly
|
||||
referred to as Release Manager shadows. They are responsible for:
|
||||
|
||||
- Patch release work, cherry pick review
|
||||
- Contributing to k/release: updating dependencies and getting used to the
|
||||
source codebase
|
||||
- Contributing to the documentation: maintaining the handbooks, ensuring that
|
||||
release processes are documented
|
||||
- With help from a release manager: working with the Release Team during the
|
||||
release cycle and cutting Kubernetes releases
|
||||
- Seeking opportunities to help with prioritization and communication
|
||||
- Sending out pre-announcements and updates about patch releases
|
||||
- Updating the calendar, helping with the release dates and milestones from
|
||||
the [release cycle timeline][k-sig-release-releases]
|
||||
- Through the Buddy program, onboarding new contributors and pairing up with
|
||||
them on tasks
|
||||
|
||||
GitHub Mentions: @kubernetes/release-engineering
|
||||
-->
|
||||
## 发布管理员助理 {#release-manager-associates}
|
||||
|
||||
发布管理员助理是发布管理员的学徒，以前称为发布管理员影子。他们负责：
|
||||
|
||||
- 补丁发布工作，Cherry Pick 审查
|
||||
- 为 k/release 做贡献：更新依赖并习惯源代码库
|
||||
- 为文档做贡献：维护手册，确保发布过程记录在案
|
||||
- 在发布管理员的帮助下：在发布周期中与发布团队合作并减少 Kubernetes 发型版本
|
||||
- 寻求机会帮助确定优先级和沟通
|
||||
- 发送有关补丁发布的预告和更新
|
||||
- 更新日历，帮助确定[发布周期时间线][k-sig-release-releases]中的发布日期和里程碑
|
||||
- 通过 Buddy 计划，加入新的贡献者并与他们合作完成任务
|
||||
|
||||
GitHub 提及：@kubernetes/release-engineering
|
||||
|
||||
- Arnaud Meukam ([@ameukam](https://github.com/ameukam))
|
||||
- Jim Angel ([@jimangel](https://github.com/jimangel))
|
||||
- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung))
|
||||
- Max Körbächer ([@mkorbi](https://github.com/mkorbi))
|
||||
- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs))
|
||||
- Taylor Dolezal ([@onlydole](https://github.com/onlydole))
|
||||
- Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin))
|
||||
|
||||
<!--
|
||||
### Becoming a Release Manager Associate
|
||||
|
||||
Contributors can become Associates by demonstrating the following:
|
||||
|
||||
- consistent participation, including 6-12 months of active release
|
||||
engineering-related work
|
||||
- experience fulfilling a technical lead role on the Release Team during a
|
||||
release cycle
|
||||
- this experience provides a solid baseline for understanding how SIG Release
|
||||
works overall—including our expectations regarding technical skills,
|
||||
communications/responsiveness, and reliability
|
||||
- working on k/release items that improve our interactions with Testgrid,
|
||||
cleaning up libraries, etc.
|
||||
- these efforts require interacting and pairing with Release Managers and
|
||||
Associates
|
||||
-->
|
||||
### 成为发布管理员助理 {#becoming-a-release-manager-associate}
|
||||
|
||||
贡献者可以通过展示以下内容成为助理：
|
||||
|
||||
- 持续参与，包括 6-12 个月的发布工程相关的积极工作
|
||||
- 在发布周期内担任发布团队的技术负责人角色的经验
|
||||
- 这种经验为理解 SIG Release 如何整体运作提供了坚实的基础——包括我们对技术技能、沟通、响应能力和可靠性的期望
|
||||
- 致力于改进我们与 Testgrid 交互的 k/release 项目，清理仓库等。
|
||||
- 这些工作需要与发布管理员和助理进行互动和合作
|
||||
|
||||
<!--
|
||||
## Build Admins
|
||||
|
||||
Build Admins are (currently) Google employees with the requisite access to
|
||||
Google build systems/tooling to publish deb/rpm packages on behalf of the
|
||||
Kubernetes project. They are responsible for:
|
||||
|
||||
- Building, signing, and publishing the deb/rpm packages
|
||||
- Being the interlock with Release Managers (and Associates) on the final steps
|
||||
of each minor (1.Y) and patch (1.Y.Z) release
|
||||
|
||||
GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins)
|
||||
-->
|
||||
## 构建管理员 {#build-admins}
|
||||
|
||||
构建管理员（目前）是谷歌员工，他们拥有对谷歌构建系统/工具的必要访问权限，可以代表 Kubernetes 项目发布 deb/rpm 包。他们负责：
|
||||
|
||||
- 构建、签名和发布 deb/rpm 包
|
||||
- 在每个次要 (1.Y) 和补丁 (1.Y.Z) 版本的最后步骤中与发布管理员（和助理）互锁
|
||||
|
||||
GitHub 团队：[@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins)
|
||||
|
||||
- Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp))
|
||||
- Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder))
|
||||
- Grant McCloskey ([@MushuEE](https://github.com/MushuEE))
|
||||
- Juan Escobar ([@juanfescobar](https://github.com/juanfescobar))
|
||||
|
||||
<!--
|
||||
## SIG Release Leads
|
||||
|
||||
SIG Release Chairs and Technical Leads are responsible for:
|
||||
|
||||
- The governance of SIG Release
|
||||
- Leading knowledge exchange sessions for Release Managers and Associates
|
||||
- Coaching on leadership and prioritization
|
||||
|
||||
They are mentioned explicitly here as they are owners of the various
|
||||
communications channels and permissions groups (GitHub teams, GCP access) for
|
||||
each role. As such, they are highly privileged community members and privy to
|
||||
some private communications, which can at times relate to Kubernetes security
|
||||
disclosures.
|
||||
|
||||
GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads)
|
||||
-->
|
||||
## SIG Release 负责人 {#sig-release-leads}
|
||||
|
||||
SIG Release 主席和技术负责人负责：
|
||||
|
||||
- SIG Release 的治理
|
||||
- 领导发布管理员和助理的知识交流会议
|
||||
- 传授领导力和优先排序方法
|
||||
|
||||
此处明确提及他们，因为他们是每个角色的各种沟通渠道和权限组（GitHub 团队、GCP 访问）的所有者。
|
||||
因此，他们是享有很高特权的社区成员，并参与了一些私人沟通，这些沟通有时可能与 Kubernetes 安全披露有关。
|
||||
|
||||
GitHub 团队：[@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads)
|
||||
|
||||
<!--
|
||||
### Chairs
|
||||
-->
|
||||
### 主席 {#chairs}
|
||||
|
||||
- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert))
|
||||
- Stephen Augustus ([@justaugustus](https://github.com/justaugustus))
|
||||
|
||||
<!--
|
||||
### Technical Leads
|
||||
-->
|
||||
### 技术负责人 {#technical-leads}
|
||||
|
||||
- Adolfo García Veytia ([@puerco](https://github.com/puerco))
|
||||
- Carlos Panato ([@cpanato](https://github.com/cpanato))
|
||||
- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
Past Branch Managers, can be found in the [releases directory][k-sig-release-releases]
|
||||
of the kubernetes/sig-release repository within `release-x.y/release_team.md`.
|
||||
|
||||
Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md)
|
||||
-->
|
||||
过去的分支管理员，可以在 `release-x.y/release_team.md`
|
||||
中 kubernetes/sig-release 仓库的[发布目录][k-sig-release-releases]中找到。
|
||||
|
||||
例如：[1.15 发布团队](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md)
|
||||
|
||||
[community-membership]: https://git.k8s.io/community/community-membership.md#member
|
||||
[handbook-branch-mgmt]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/branch-manager.md
|
||||
[handbook-packaging]: https://git.k8s.io/sig-release/release-engineering/packaging.md
|
||||
[handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md
|
||||
[k-sig-release-releases]: https://git.k8s.io/sig-release/releases
|
||||
[patches]: /patch-releases.md
|
||||
[src]: https://git.k8s.io/community/committee-security-response/README.md
|
||||
[release-team]: https://git.k8s.io/sig-release/release-team/README.md
|
||||
[security-release-process]: https://git.k8s.io/security/security-release-process.md
|
||||
@@ -0,0 +1,660 @@
|
||||
---
|
||||
title: Kubernetes 发布周期
|
||||
type: docs
|
||||
---
|
||||
<!--
|
||||
title: Kubernetes Release Cycle
|
||||
type: docs
|
||||
auto_generated: true
|
||||
-->
|
||||
|
||||
<!-- THIS CONTENT IS AUTO-GENERATED via ./scripts/releng/update-release-info.sh in k/website -->
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
This content is auto-generated and links may not function. The source of the document is located [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md).
|
||||
-->
|
||||
此内容原文是自动生成的，链接可能无法正常访问。
|
||||
文档的来源在[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md)。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
# Targeting enhancements, Issues and PRs to Release Milestones
|
||||
|
||||
This document is focused on Kubernetes developers and contributors who need to
|
||||
create an enhancement, issue, or pull request which targets a specific release
|
||||
milestone.
|
||||
-->
|
||||
# 针对发布里程碑的特性增强、Issue 和 PR {#targeting-enhancements-issues-and-prs-to-release-milestones}
|
||||
|
||||
本文档重点是面向于那些需要创建针对特定发布里程碑的特性增强、问题或拉取请求的 Kubernetes 开发人员和贡献者。
|
||||
|
||||
<!--
|
||||
- [TL;DR](#tldr)
|
||||
- [Normal Dev (Weeks 1-11)](#normal-dev-weeks-1-11)
|
||||
- [Code Freeze (Weeks 12-14)](#code-freeze-weeks-12-14)
|
||||
- [Post-Release (Weeks 14+)](#post-release-weeks-14+)
|
||||
- [Definitions](#definitions)
|
||||
- [The Release Cycle](#the-release-cycle)
|
||||
- [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
|
||||
- [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
|
||||
- [Milestone Maintainers](#milestone-maintainers)
|
||||
- [Feature additions](#feature-additions)
|
||||
- [Issue additions](#issue-additions)
|
||||
- [PR Additions](#pr-additions)
|
||||
- [Other Required Labels](#other-required-labels)
|
||||
- [SIG Owner Label](#sig-owner-label)
|
||||
- [Priority Label](#priority-label)
|
||||
- [Issue/PR Kind Label](#issuepr-kind-label)
|
||||
-->
|
||||
- [TL;DR](#tldr)
|
||||
- [正常开发（第 1-11周）](#normal-dev-weeks-1-11)
|
||||
- [代码冻结（第 12-14 周）](#code-freeze-weeks-12-14)
|
||||
- [发布后（第 14 周以上）](#post-release-weeks-14)
|
||||
- [定义](#definitions)
|
||||
- [发布周期](#the-release-cycle)
|
||||
- [从里程碑中删除项目](#removal-of-items-from-the-milestone)
|
||||
- [向里程碑添加项目](#adding-an-item-to-the-milestone)
|
||||
- [里程碑维护者](#milestone-maintainers)
|
||||
- [新增特性](#feature-additions)
|
||||
- [问题补充](#issue-additions)
|
||||
- [新增 PR](#pr-additions)
|
||||
- [其他必需标签](#other-required-labels)
|
||||
- [SIG 所有者标签](#sig-owner-label)
|
||||
- [优先级标签](#priority-label)
|
||||
- [Issue/PR 分类标签](#issuepr-kind-label)
|
||||
|
||||
<!--
|
||||
The process for shepherding enhancements, issues, and pull requests into a
|
||||
Kubernetes release spans multiple stakeholders:
|
||||
|
||||
- the enhancement, issue, and pull request owner(s)
|
||||
- SIG leadership
|
||||
- the [Release Team][release-team]
|
||||
|
||||
Information on workflows and interactions are described below.
|
||||
-->
|
||||
将特性增强、问题和拉取请求引入 Kubernetes 版本的过程涉及多个利益相关者：
|
||||
|
||||
- 特性增强、问题和拉取请求的所有者
|
||||
- SIG 负责人
|
||||
- [发布团队][release-team]
|
||||
|
||||
关于工作流程和交互的信息如下所述。
|
||||
|
||||
<!--
|
||||
As the owner of an enhancement, issue, or pull request (PR), it is your
|
||||
responsibility to ensure release milestone requirements are met. Automation and
|
||||
the Release Team will be in contact with you if updates are required, but
|
||||
inaction can result in your work being removed from the milestone. Additional
|
||||
requirements exist when the target milestone is a prior release (see
|
||||
[cherry pick process][cherry-picks] for more information).
|
||||
-->
|
||||
作为特性增强、问题或拉取请求 (PR) 的所有者，你有责任确保满足里程碑发布要求。
|
||||
如果需要更新，自动化和发布团队将与你联系，但无响应可能会导致你的工作从里程碑中删除。
|
||||
当目标里程碑是先前版本时，还存在其他要求（请参阅 [Cherry Pick 流程][cherry-picks]了解更多信息）。
|
||||
|
||||
## TL;DR
|
||||
|
||||
<!--
|
||||
If you want your PR to get merged, it needs the following required labels and
|
||||
milestones, represented here by the Prow /commands it would take to add them:
|
||||
-->
|
||||
如果你希望你的 PR 被合并，它需要以下必备的标签和里程碑，它们由 Prow /commands 所添加表示：
|
||||
|
||||
<!--
|
||||
### Normal Dev (Weeks 1-8)
|
||||
-->
|
||||
### 正常开发（第 1-11 周） {#normal-dev-weeks-1-11}
|
||||
|
||||
- /sig {name}
|
||||
- /kind {type}
|
||||
- /lgtm
|
||||
- /approved
|
||||
|
||||
<!--
|
||||
### [Code Freeze][code-freeze] (Weeks 12-14)
|
||||
-->
|
||||
### [代码冻结][code-freeze]（第 12-14 周） {#code-freeze-code-freeze-weeks-12-14}
|
||||
|
||||
- /milestone {v1.y}
|
||||
- /sig {name}
|
||||
- /kind {bug, failing-test}
|
||||
- /lgtm
|
||||
- /approved
|
||||
|
||||
<!--
|
||||
### Post-Release (Weeks 14+)
|
||||
-->
|
||||
### 发布后（第 14 周以上） {#post-release-weeks-14}
|
||||
|
||||
<!--
|
||||
Return to 'Normal Dev' phase requirements:
|
||||
-->
|
||||
回到“正常开发”阶段要求：
|
||||
|
||||
- /sig {name}
|
||||
- /kind {type}
|
||||
- /lgtm
|
||||
- /approved
|
||||
|
||||
<!--
|
||||
Merges into the 1.y branch are now [via cherry picks][cherry-picks], approved
|
||||
by [Release Managers][release-managers].
|
||||
|
||||
In the past, there was a requirement for a milestone-targeted pull requests to
|
||||
have an associated GitHub issue opened, but this is no longer the case.
|
||||
Features or enhancements are effectively GitHub issues or [KEPs][keps] which
|
||||
lead to subsequent PRs.
|
||||
|
||||
The general labeling process should be consistent across artifact types.
|
||||
-->
|
||||
合并到 1.y 分支现在是[通过 Cherry Pick][cherry-picks]，由[发布管理员][release-managers]批准。
|
||||
|
||||
过去，针对里程碑的拉取请求需要打开相关的 GitHub 问题，但现在情况不再如此。
|
||||
特性或特性增强实际上是 GitHub 问题或导致后续 PR 的 [KEPs][keps]。
|
||||
|
||||
一般的打标签过程应该在不同工件类型之间保持一致。
|
||||
|
||||
<!--
|
||||
## Definitions
|
||||
|
||||
- *issue owners*: Creator, assignees, and user who moved the issue into a
|
||||
release milestone
|
||||
|
||||
- *Release Team*: Each Kubernetes release has a team doing project management
|
||||
tasks described [here][release-team].
|
||||
|
||||
The contact info for the team associated with any given release can be found
|
||||
[here](https://git.k8s.io/sig-release/releases/).
|
||||
|
||||
- *Y days*: Refers to business days
|
||||
|
||||
- *enhancement*: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)"
|
||||
-->
|
||||
## 定义 {#definitions}
|
||||
|
||||
- **问题所有者**：将问题移至发布里程碑的创建者、委托人和用户
|
||||
|
||||
- **发布小组**：每个 Kubernetes 版本都有一个团队来执行[这里][release-team]所描述的项目管理任务。
|
||||
|
||||
可以在[此处](https://git.k8s.io/sig-release/releases/)找到与任何给定版本相关联的团队的联系信息。
|
||||
|
||||
- **Y 天**：指工作日
|
||||
|
||||
- **增强**：参见“[我的改进是特性增强吗？](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)”
|
||||
|
||||
<!--
|
||||
- *[Enhancements Freeze][enhancements-freeze]*:
|
||||
the deadline by which [KEPs][keps] have to be completed in order for
|
||||
enhancements to be part of the current release
|
||||
|
||||
- *[Exception Request][exceptions]*:
|
||||
The process of requesting an extension on the deadline for a particular
|
||||
Enhancement
|
||||
|
||||
- *[Code Freeze][code-freeze]*:
|
||||
The period of ~4 weeks before the final release date, during which only
|
||||
critical bug fixes are merged into the release.
|
||||
|
||||
- *[Pruning](https://git.k8s.io/sig-release/releases/release*phases.md#pruning)*:
|
||||
The process of removing an Enhancement from a release milestone if it is not
|
||||
fully implemented or is otherwise considered not stable.
|
||||
-->
|
||||
- **[特性增强冻结][enhancements-freeze]**：
|
||||
为了使特性增强成为当前版本的一部分，必须在 [KEPs][keps] 的截止日期前完成
|
||||
|
||||
- **[异常请求][exceptions]**：
|
||||
请求延长特性增强的截止日期的过程
|
||||
|
||||
- **[代码冻结][code-freeze]**：
|
||||
最终发布日期前约 4 周的时间，在此期间，仅将关键错误修复合并到发布中。
|
||||
|
||||
- **[修剪](https://git.k8s.io/sig-release/releases/release*phases.md#pruning)**：
|
||||
如果特性增强未完全实现或被认为不稳定，则在此过程中从发布里程碑中删除它。
|
||||
|
||||
<!--
|
||||
- *release milestone*: semantic version string or
|
||||
[GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests)
|
||||
referring to a release MAJOR.MINOR `vX.Y` version.
|
||||
|
||||
See also
|
||||
[release versioning](/contributors/design-proposals/release/versioning.md).
|
||||
|
||||
- *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone.
|
||||
|
||||
Created at the time of the `vX.Y-rc.0` release and maintained after the
|
||||
release for approximately 12 months with `vX.Y.Z` patch releases.
|
||||
|
||||
Note: releases 1.19 and newer receive 1 year of patch release support, and
|
||||
releases 1.18 and earlier received 9 months of patch release support.
|
||||
-->
|
||||
- **发布里程碑**：语义版本字符串或
|
||||
[GitHub 里程碑](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests)
|
||||
指的是发布 主.次 `vX.Y` 版本。
|
||||
|
||||
另请参阅[发布版本控制](/contributors/design-proposals/release/versioning.md)。
|
||||
|
||||
- **发布分支**：为 `vX.Y` 里程碑创建的 Git 分支 `release-X.Y`。
|
||||
|
||||
在 `vX.Y-rc.0` 发布时创建，并在发布后使用 `vX.Y.Z` 补丁版本，维护大约 12 个月。
|
||||
|
||||
注意：1.19 及更高版本获得 1 年的补丁版本支持，1.18 及更早版本获得 9 个月的补丁版本支持。
|
||||
|
||||
<!--
|
||||
## The Release Cycle
|
||||
-->
|
||||
## 发布周期 {#the-release-cycle}
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Kubernetes releases currently happen approximately three times per year.
|
||||
|
||||
The release process can be thought of as having three main phases:
|
||||
|
||||
- Enhancement Definition
|
||||
- Implementation
|
||||
- Stabilization
|
||||
-->
|
||||
Kubernetes 目前大约每年发布三次。
|
||||
|
||||
发布过程可被认为具有三个主要阶段：
|
||||
|
||||
- 特性增强定义
|
||||
- 实现
|
||||
- 稳定
|
||||
|
||||
<!--
|
||||
But in reality, this is an open source and agile project, with feature planning
|
||||
and implementation happening at all times. Given the project scale and globally
|
||||
distributed developer base, it is critical to project velocity to not rely on a
|
||||
trailing stabilization phase and rather have continuous integration testing
|
||||
which ensures the project is always stable so that individual commits can be
|
||||
flagged as having broken something.
|
||||
-->
|
||||
但实际上，这是一个灵活的开源项目，功能规划和实施始终在进行。
|
||||
鉴于项目规模和全球分布的开发人员基础，对项目速度至关重要的是不依赖于后续的稳定阶段，
|
||||
而是进行持续集成测试，以确保项目始终稳定，以便可以将单个提交标记为有问题。
|
||||
|
||||
<!--
|
||||
With ongoing feature definition through the year, some set of items will bubble
|
||||
up as targeting a given release. **[Enhancements Freeze][enhancements-freeze]**
|
||||
starts ~4 weeks into release cycle. By this point all intended feature work for
|
||||
the given release has been defined in suitable planning artifacts in
|
||||
conjunction with the Release Team's [Enhancements Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md).
|
||||
-->
|
||||
随着全年功能定义的不断进行，某些项目将冒泡作为给定版本的目标。
|
||||
在发布周期约 4 周后开始 **[冻结特性增强][enhancements-freeze]**。
|
||||
至此，针对给定版本的所有预期功能工作都已与发布团队的
|
||||
[特性增强负责人](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md)
|
||||
一起在合适的规划工件中定义。
|
||||
|
||||
|
||||
<!--
|
||||
After Enhancements Freeze, tracking milestones on PRs and issues is important.
|
||||
Items within the milestone are used as a punchdown list to complete the
|
||||
release. *On issues*, milestones must be applied correctly, via triage by the
|
||||
SIG, so that [Release Team][release-team] can track bugs and enhancements (any
|
||||
enhancement-related issue needs a milestone).
|
||||
-->
|
||||
特性增强冻结后，跟踪 PR 和问题的里程碑很重要。里程碑中的项目作为完成发布的下达列表。
|
||||
**关于问题**，里程碑必须通过 SIG 的分类正确应用，
|
||||
以便[发布团队][release-team]可以跟踪错误和特性增强（任何与特性增强相关的问题都需要里程碑）。
|
||||
|
||||
<!--
|
||||
There is some automation in place to help automatically assign milestones to
|
||||
PRs.
|
||||
|
||||
This automation currently applies to the following repos:
|
||||
-->
|
||||
自动化可以自动将里程碑分配给 PR。
|
||||
|
||||
此自动化当前适用于以下存储库：
|
||||
|
||||
- `kubernetes/enhancements`
|
||||
- `kubernetes/kubernetes`
|
||||
- `kubernetes/release`
|
||||
- `kubernetes/sig-release`
|
||||
- `kubernetes/test-infra`
|
||||
|
||||
<!--
|
||||
At creation time, PRs against the `master` branch need humans to hint at which
|
||||
milestone they might want the PR to target. Once merged, PRs against the
|
||||
`master` branch have milestones auto-applied so from that time onward human
|
||||
management of that PR's milestone is less necessary. On PRs against release
|
||||
branches, milestones are auto-applied when the PR is created so no human
|
||||
management of the milestone is ever necessary.
|
||||
-->
|
||||
在创建时，针对 `master` 分支的 PR 需要人工提示他们可能希望 PR 指向哪个里程碑。
|
||||
一旦合并，针对 `master` 分支的 PR 会自动应用里程碑，因此从那时起，不再需要人工管理该 PR 的里程碑。
|
||||
在指向发布分支的 PR 上，会在创建 PR 时自动应用里程碑，因此不需要对里程碑进行人工管理。
|
||||
|
||||
<!--
|
||||
Any other effort that should be tracked by the Release Team that doesn't fall
|
||||
under that automation umbrella should be have a milestone applied.
|
||||
|
||||
Implementation and bug fixing is ongoing across the cycle, but culminates in a
|
||||
code freeze period.
|
||||
|
||||
**[Code Freeze][code-freeze]** starts in week ~12 and continues for ~2 weeks.
|
||||
Only critical bug fixes are accepted into the release codebase during this
|
||||
time.
|
||||
-->
|
||||
任何其他应该由发布团队跟踪的不属于该自动化保护伞的工作都应该应用一个里程碑。
|
||||
|
||||
整个周期都在进行实施和错误修复，但最终会出现代码冻结期。
|
||||
|
||||
**[代码冻结][code-freeze]** 大约从第 12 周开始，持续约 2 周。
|
||||
在此期间，只有关键的错误修复才会被接受到发布代码库中。
|
||||
|
||||
<!--
|
||||
There are approximately two weeks following Code Freeze, and preceding release,
|
||||
during which all remaining critical issues must be resolved before release.
|
||||
This also gives time for documentation finalization.
|
||||
|
||||
When the code base is sufficiently stable, the master branch re-opens for
|
||||
general development and work begins there for the next release milestone. Any
|
||||
remaining modifications for the current release are cherry picked from master
|
||||
back to the release branch. The release is built from the release branch.
|
||||
|
||||
Each release is part of a broader Kubernetes lifecycle:
|
||||
-->
|
||||
在代码冻结之后和之前的发布之间大约有两周时间，在此期间，必须在发布版本前解决所有剩余的严重问题。
|
||||
这也为文档定稿提供了时间。
|
||||
|
||||
当代码库足够稳定时，主分支将重新打开以进行一般开发，并从那里开始下一个发布里程碑的工作。
|
||||
当前版本的任何剩余修改都是从 master 挑选回发布分支。发布版本是从发布分支构建的。
|
||||
|
||||
每个版本都是更广泛的 Kubernetes 生命周期的一部分：
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
## Removal Of Items From The Milestone
|
||||
|
||||
Before getting too far into the process for adding an item to the milestone,
|
||||
please note:
|
||||
|
||||
Members of the [Release Team][release-team] may remove issues from the
|
||||
milestone if they or the responsible SIG determine that the issue is not
|
||||
actually blocking the release and is unlikely to be resolved in a timely
|
||||
fashion.
|
||||
|
||||
Members of the Release Team may remove PRs from the milestone for any of the
|
||||
following, or similar, reasons:
|
||||
-->
|
||||
## 从里程碑中删除项目 {#removal-of-items-from-the-milestone}
|
||||
|
||||
在深入了解将项目添加到里程碑的过程之前，请注意：
|
||||
|
||||
如果[发布小组][release-team]的成员或负责的 SIG
|
||||
确定问题实际上并未阻止发布并且不太可能及时解决，则可以从里程碑中删除问题。
|
||||
|
||||
发布团队的成员可以出于以下任何原因或类似原因从里程碑中删除 PR：
|
||||
|
||||
<!--
|
||||
- PR is potentially de-stabilizing and is not needed to resolve a blocking
|
||||
issue
|
||||
- PR is a new, late feature PR and has not gone through the enhancements
|
||||
process or the [exception process][exceptions]
|
||||
- There is no responsible SIG willing to take ownership of the PR and resolve
|
||||
any follow-up issues with it
|
||||
- PR is not correctly labelled
|
||||
- Work has visibly halted on the PR and delivery dates are uncertain or late
|
||||
-->
|
||||
- PR 可能会破坏稳定，并且不需要去解决阻塞问题
|
||||
- PR 是一个新的、较晚的特性 PR 并且没有经过增强过程或[异常过程][exceptions]
|
||||
- 没有负责任的 SIG 愿意接管 PR 并解决任何后续问题
|
||||
- PR 未正确标记
|
||||
- PR 工作明显停止，交付日期不确定或延迟
|
||||
|
||||
<!--
|
||||
While members of the Release Team will help with labelling and contacting
|
||||
SIG(s), it is the responsibility of the submitter to categorize PRs, and to
|
||||
secure support from the relevant SIG to guarantee that any breakage caused by
|
||||
the PR will be rapidly resolved.
|
||||
|
||||
Where additional action is required, an attempt at human to human escalation
|
||||
will be made by the Release Team through the following channels:
|
||||
-->
|
||||
虽然发布团队的成员将帮助标记和联系 SIG，但提交者有责任对 PR 进行分类，
|
||||
并获得相关 SIG 的支持，以保证由 PR 引起的任何破坏都会得到迅速解决。
|
||||
|
||||
如果需要采取其他措施，发布团队将通过以下渠道尝试进行人与人之间的对话：
|
||||
|
||||
<!--
|
||||
- Comment in GitHub mentioning the SIG team and SIG members as appropriate for
|
||||
the issue type
|
||||
- Emailing the SIG mailing list
|
||||
- bootstrapped with group email addresses from the
|
||||
[community sig list][sig-list]
|
||||
- optionally also directly addressing SIG leadership or other SIG members
|
||||
- Messaging the SIG's Slack channel
|
||||
- bootstrapped with the slackchannel and SIG leadership from the
|
||||
[community sig list][sig-list]
|
||||
- optionally directly "@" mentioning SIG leadership or others by handle
|
||||
-->
|
||||
- 在 GitHub 中发表评论，根据问题类型提及 SIG 团队和 SIG 成员
|
||||
- 给 SIG 邮件列表发邮件
|
||||
- 使用来自[社区 SIG 列表][sig-list]的群组电子邮件地址进行引导
|
||||
- 也可选择直接与 SIG 负责人或 SIG 其他成员联系
|
||||
- 向 SIG 的 Slack 频道发送消息
|
||||
- 在 Slack 频道 和 SIG 负责人的引导下
|
||||
[社区签名列表][签名列表]
|
||||
- 可选地直接 “@” 来提及 SIG 负责人或其他人
|
||||
|
||||
<!--
|
||||
## Adding An Item To The Milestone
|
||||
|
||||
### Milestone Maintainers
|
||||
|
||||
The members of the [`milestone-maintainers`](https://github.com/orgs/kubernetes/teams/milestone-maintainers/members)
|
||||
GitHub team are entrusted with the responsibility of specifying the release
|
||||
milestone on GitHub artifacts.
|
||||
|
||||
This group is [maintained](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
|
||||
by SIG Release and has representation from the various SIGs' leadership.
|
||||
-->
|
||||
## 向里程碑添加项目 {#adding-an-item-to-the-milestone}
|
||||
|
||||
### 里程碑维护者 {#milestone-maintainers}
|
||||
|
||||
[`milestone-maintainers`](https://github.com/orgs/kubernetes/teams/milestone-maintainers/members)
|
||||
GitHub 团队的成员负责在 GitHub 工件上指定发布里程碑。
|
||||
|
||||
该小组由 SIG Release
|
||||
[维护](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)，并有来自各个 SIG 负责人的代表。
|
||||
|
||||
<!--
|
||||
### Feature additions
|
||||
|
||||
Feature planning and definition takes many forms today, but a typical example
|
||||
might be a large piece of work described in a [KEP][keps], with associated task
|
||||
issues in GitHub. When the plan has reached an implementable state and work is
|
||||
underway, the enhancement or parts thereof are targeted for an upcoming milestone
|
||||
by creating GitHub issues and marking them with the Prow "/milestone" command.
|
||||
-->
|
||||
### 特性添加 {#feature-additions}
|
||||
|
||||
如今，功能规划和定义有多种形式，但一个典型的例子可能是
|
||||
[KEP][keps] 中描述的大量工作，以及 GitHub 中的相关任务问题。
|
||||
当计划达到可实施状态并且工作正在进行中时，通过创建 GitHub 问题并使用
|
||||
Prow "/milestone" 命令对其进行标记，特性增强或其部分指向未来的里程碑。
|
||||
|
||||
<!--
|
||||
For the first ~4 weeks into the release cycle, the Release Team's Enhancements
|
||||
Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG
|
||||
meetings to capture all required planning artifacts.
|
||||
|
||||
If you have an enhancement to target for an upcoming release milestone, begin a
|
||||
conversation with your SIG leadership and with that release's Enhancements
|
||||
Lead.
|
||||
-->
|
||||
在发布周期的前 4 周左右内，发布团队的特性增强负责人将通过
|
||||
GitHub、Slack 和 SIG 会议与 SIG 和特性所有者互动，以获取所有需要的计划工件。
|
||||
|
||||
如果你有针对即将发布的里程碑的特性增强，请与你的 SIG 领导以及该版本的特性增强负责人开始对话。
|
||||
|
||||
<!--
|
||||
### Issue additions
|
||||
|
||||
Issues are marked as targeting a milestone via the Prow "/milestone" command.
|
||||
|
||||
The Release Team's [Bug Triage Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md)
|
||||
and overall community watch incoming issues and triage them, as described in
|
||||
the contributor guide section on
|
||||
[issue triage](/contributors/guide/issue-triage.md).
|
||||
-->
|
||||
### 问题补充 {#issue-additions}
|
||||
|
||||
通过 Prow “/milestone” 命令标记问题并指向里程碑。
|
||||
|
||||
发布团队的[错误分类负责人](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md)和整个社区观察新出现的问题并对其进行分类，
|
||||
在贡献者指南部分中描述[问题分类](/contributors/guide/issue-triage.md)。
|
||||
|
||||
<!--
|
||||
Marking issues with the milestone provides the community better visibility
|
||||
regarding when an issue was observed and by when the community feels it must be
|
||||
resolved. During [Code Freeze][code-freeze], a milestone must be set to merge
|
||||
a PR.
|
||||
|
||||
An open issue is no longer required for a PR, but open issues and associated
|
||||
PRs should have synchronized labels. For example a high priority bug issue
|
||||
might not have its associated PR merged if the PR is only marked as lower
|
||||
priority.
|
||||
-->
|
||||
用里程碑标记问题可以让社区更好地了解何时观察到问题以及社区认为何时必须解决问题。
|
||||
[代码冻结][code-freeze]期间，必须设置里程碑以合并 PR。
|
||||
|
||||
一个 PR 不再需要一个已开启的问题，但已开启的问题和相关的 PR 应该有同步的标签。
|
||||
例如，如果 PR 仅标记为较低优先级，则高优先级错误问题可能不会合并其关联的 PR。
|
||||
|
||||
<!--
|
||||
### PR Additions
|
||||
|
||||
PRs are marked as targeting a milestone via the Prow "/milestone" command.
|
||||
|
||||
This is a blocking requirement during Code Freeze as described above.
|
||||
-->
|
||||
### PR 补充 {#pr-additions}
|
||||
|
||||
PR 通过 Prow “/milestone” 命令标记并指向里程碑。
|
||||
|
||||
如上所述，这是代码冻结期间的阻塞要求。
|
||||
|
||||
<!--
|
||||
## Other Required Labels
|
||||
|
||||
[Here is the list of labels and their use and purpose.](https://git.k8s.io/test-infra/label*sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs)
|
||||
-->
|
||||
## 其他必需的标签 {#other-required-labels}
|
||||
|
||||
[这里是标签列表及其用途和目的](https://git.k8s.io/test-infra/label*sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs)。
|
||||
|
||||
<!--
|
||||
### SIG Owner Label
|
||||
|
||||
The SIG owner label defines the SIG to which we escalate if a milestone issue
|
||||
is languishing or needs additional attention. If there are no updates after
|
||||
escalation, the issue may be automatically removed from the milestone.
|
||||
|
||||
These are added with the Prow "/sig" command. For example to add the label
|
||||
indicating SIG Storage is responsible, comment with `/sig storage`.
|
||||
-->
|
||||
### SIG 所有者标签 {#sig-owner-label}
|
||||
|
||||
SIG 所有者标签定义了当里程碑问题未取得进展或需要额外关注时，我们应该逐步升级的 SIG。
|
||||
如果升级后没有更新，该问题可能会自动从里程碑中删除。
|
||||
|
||||
这些是通过 Prow "/sig" 命令添加的。
|
||||
例如要添加指示 SIG Storage 负责的标签，请使用 `/sig storage` 进行评论。
|
||||
|
||||
<!--
|
||||
### Priority Label
|
||||
|
||||
Priority labels are used to determine an escalation path before moving issues
|
||||
out of the release milestone. They are also used to determine whether or not a
|
||||
release should be blocked on the resolution of the issue.
|
||||
-->
|
||||
### 优先级标签 {#priority-label}
|
||||
|
||||
优先级标签用于在将问题移出发布里程碑之前确定升级路径。
|
||||
它们还用于确定在解决问题时是否应阻止发布。
|
||||
|
||||
<!--
|
||||
- `priority/critical-urgent`: Never automatically move out of a release
|
||||
milestone; continually escalate to contributor and SIG through all available
|
||||
channels.
|
||||
- considered a release blocking issue
|
||||
- requires daily updates from issue owners during [Code Freeze][code-freeze]
|
||||
- would require a patch release if left undiscovered until after the minor
|
||||
release
|
||||
- `priority/important-soon`: Escalate to the issue owners and SIG owner; move
|
||||
out of milestone after several unsuccessful escalation attempts.
|
||||
- not considered a release blocking issue
|
||||
- would not require a patch release
|
||||
- will automatically be moved out of the release milestone at Code Freeze
|
||||
after a 4 day grace period
|
||||
- `priority/important-longterm`: Escalate to the issue owners; move out of the
|
||||
milestone after 1 attempt.
|
||||
- even less urgent / critical than `priority/important-soon`
|
||||
- moved out of milestone more aggressively than `priority/important-soon`
|
||||
-->
|
||||
- `priority/critical-urgent`：永远不会自动移出发布里程碑；通过所有可用渠道不断上报给贡献者和 SIG。
|
||||
- 考虑发布阻塞问题
|
||||
- 在[代码冻结][code-freeze]期间需要问题所有者的每日更新
|
||||
- 如果在次要版本之后才被发现，则需要补丁版本
|
||||
- `priority/important-soon`：上报给问题所有者和 SIG 所有者；在几次不成功的升级尝试后退出里程碑。
|
||||
- 不考虑发布阻止问题
|
||||
- 不需要补丁版本
|
||||
- 将在 4 天的宽限期后自动移出代码冻结的发布里程碑
|
||||
- `priority/important-longterm`：上报给问题所有者；1 次尝试后移出里程碑
|
||||
- 比 `priority/important-soon` 更不紧急/不关键
|
||||
- 比 `priority/important-soon` 更积极地移出里程碑
|
||||
|
||||
<!--
|
||||
### Issue/PR Kind Label
|
||||
|
||||
The issue kind is used to help identify the types of changes going into the
|
||||
release over time. This may allow the Release Team to develop a better
|
||||
understanding of what sorts of issues we would miss with a faster release
|
||||
cadence.
|
||||
|
||||
For release targeted issues, including pull requests, one of the following
|
||||
issue kind labels must be set:
|
||||
-->
|
||||
### Issue/PR 分类标签 {#issue-pr-kind-label}
|
||||
|
||||
Issue 类型用于帮助识别随着时间的推移进入版本的更改类型。
|
||||
这可以让发布团队更好地了解我们会在更快的发布节奏下错过哪些类型的 Issue。
|
||||
|
||||
对于发布版本的目标问题，包括拉取请求，必须设置以下问题类型标签之一：
|
||||
|
||||
<!--
|
||||
- `kind/api-change`: Adds, removes, or changes an API
|
||||
- `kind/bug`: Fixes a newly discovered bug.
|
||||
- `kind/cleanup`: Adding tests, refactoring, fixing old bugs.
|
||||
- `kind/design`: Related to design
|
||||
- `kind/documentation`: Adds documentation
|
||||
- `kind/failing-test`: CI test case is failing consistently.
|
||||
- `kind/feature`: New functionality.
|
||||
- `kind/flake`: CI test case is showing intermittent failures.
|
||||
-->
|
||||
- `kind/api-change`：添加、删除或更改 API
|
||||
- `kind/bug`：修复了一个新发现的错误
|
||||
- `kind/cleanup`：添加测试、重构、修复旧错误
|
||||
- `kind/design`：与设计相关
|
||||
- `kind/documentation`：添加文档
|
||||
- `kind/failing-test`：CI 测试用例一直失败
|
||||
- `kind/feature`：新功能
|
||||
- `kind/flake`：CI 测试用例显示间歇性故障
|
||||
|
||||
[cherry-picks]: /contributors/devel/sig-release/cherry-picks.md
|
||||
[code-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze
|
||||
[enhancements-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze
|
||||
[exceptions]: https://git.k8s.io/sig-release/releases/release_phases.md#exceptions
|
||||
[keps]: https://git.k8s.io/enhancements/keps
|
||||
[release-managers]: https://kubernetes.io/releases/release-managers/
|
||||
[release-team]: https://git.k8s.io/sig-release/release-team
|
||||
[sig-list]: /sig-list.md
|
||||
@@ -0,0 +1,363 @@
|
||||
---
|
||||
title: 版本偏差策略
|
||||
type: docs
|
||||
description: >
|
||||
Kubernetes 各个组件之间所支持的最大版本偏差。
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- sig-api-machinery
|
||||
- sig-architecture
|
||||
- sig-cli
|
||||
- sig-cluster-lifecycle
|
||||
- sig-node
|
||||
- sig-release
|
||||
title: Version Skew Policy
|
||||
type: docs
|
||||
description: >
|
||||
The maximum version skew supported between various Kubernetes components.
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This document describes the maximum version skew supported between various Kubernetes components.
|
||||
Specific cluster deployment tools may place additional restrictions on version skew.
|
||||
-->
|
||||
本文档描述了 Kubernetes 各个组件之间所支持的最大版本偏差。
|
||||
特定的集群部署工具可能会对版本偏差添加额外的限制。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Supported versions
|
||||
|
||||
Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
|
||||
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
|
||||
|
||||
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
|
||||
-->
|
||||
## 支持的版本 {#supported-versions}
|
||||
|
||||
Kubernetes 版本以 **x.y.z** 表示，其中 **x** 是主要版本，
|
||||
**y** 是次要版本，**z** 是补丁版本，遵循[语义版本控制](https://semver.org/)术语。
|
||||
更多信息请参见
|
||||
[Kubernetes 版本发布控制](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
|
||||
|
||||
Kubernetes 项目维护最近的三个次要版本（{{< skew latestVersion >}}、{{< skew prevMinorVersion >}}、{{< skew oldMinorVersion >}}）的发布分支。
|
||||
Kubernetes 1.19 和更新的版本获得大约 1 年的补丁支持。
|
||||
Kubernetes 1.18 及更早的版本获得了大约 9 个月的补丁支持。
|
||||
|
||||
<!--
|
||||
Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
|
||||
Patch releases are cut from those branches at a [regular cadence](https://kubernetes.io/releases/patch-releases/#cadence), plus additional urgent releases, when required.
|
||||
|
||||
The [Release Managers](/releases/release-managers/) group owns this decision.
|
||||
|
||||
For more information, see the Kubernetes [patch releases](/releases/patch-releases/) page.
|
||||
-->
|
||||
适当的修复，包括安全问题修复，可能会被后沿三个发布分支，具体取决于问题的严重性和可行性。
|
||||
补丁版本按[常规节奏](https://kubernetes.io/releases/patch-releases/#cadence)从这些分支中删除，并在需要时增加额外的紧急版本。
|
||||
|
||||
[发布管理员](/zh/releases/release-managers/)小组拥有这件事的决定权。
|
||||
|
||||
有关更多信息，请参阅 Kubernetes [补丁发布](/zh/releases/patch-releases/)页面。
|
||||
|
||||
<!--
|
||||
## Supported version skew
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
|
||||
|
||||
Example:
|
||||
|
||||
* newest `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* other `kube-apiserver` instances are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
-->
|
||||
## 支持的版本偏差 {#supported-version-skew}
|
||||
|
||||
### kube-apiserver {#kube-apiserver}
|
||||
|
||||
在[高可用性（HA）集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)中，
|
||||
最新版和最老版的 `kube-apiserver` 实例版本偏差最多为一个次要版本。
|
||||
|
||||
例如：
|
||||
|
||||
* 最新的 `kube-apiserver` 实例处于 **{{< skew latestVersion >}}** 版本
|
||||
* 其他 `kube-apiserver` 实例支持 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}** 版本
|
||||
|
||||
<!--
|
||||
### kubelet
|
||||
|
||||
`kubelet` must not be newer than `kube-apiserver`, and may be up to two minor versions older.
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kubelet` is supported at **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}**
|
||||
-->
|
||||
### kubelet {#kubelet}
|
||||
|
||||
`kubelet` 版本不能比 `kube-apiserver` 版本新，并且最多只可落后两个次要版本。
|
||||
|
||||
例如：
|
||||
|
||||
* `kube-apiserver` 处于 **{{< skew latestVersion >}}** 版本
|
||||
* `kubelet` 支持 **{{< skew latestVersion >}}**、**{{< skew prevMinorVersion >}}** 和 **{{< skew oldMinorVersion >}}** 版本
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
|
||||
-->
|
||||
如果 HA 集群中的 `kube-apiserver` 实例之间存在版本偏差，这会缩小允许的 `kubelet` 版本范围。
|
||||
{{</ note >}}
|
||||
|
||||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
* `kubelet` is supported at **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
|
||||
-->
|
||||
例如：
|
||||
|
||||
* `kube-apiserver` 实例处于 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}** 版本
|
||||
* `kubelet` 支持 **{{< skew prevMinorVersion >}}** 和 **{{< skew oldMinorVersion >}}** 版本，
|
||||
（不支持 **{{< skew latestVersion >}}** 版本，因为这将比
|
||||
`kube-apiserver` **{{< skew prevMinorVersion >}}** 版本的实例新）
|
||||
|
||||
<!--
|
||||
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
|
||||
|
||||
`kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades).
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
-->
|
||||
### kube-controller-manager、kube-scheduler 和 cloud-controller-manager {#kube-controller-manager-kube-scheduler-and-cloud-controller-manager}
|
||||
|
||||
`kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
|
||||
不能比与它们通信的 `kube-apiserver` 实例新。
|
||||
它们应该与 `kube-apiserver` 次要版本相匹配，但可能最多旧一个次要版本（允许实时升级）。
|
||||
|
||||
例如：
|
||||
|
||||
* `kube-apiserver` 处于 **{{< skew latestVersion >}}** 版本
|
||||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
|
||||
支持 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}** 版本
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
|
||||
-->
|
||||
如果 HA 集群中的 `kube-apiserver` 实例之间存在版本偏差，
|
||||
并且这些组件可以与集群中的任何 `kube-apiserver`
|
||||
实例通信（例如，通过负载均衡器），这会缩小这些组件所允许的版本范围。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer that can route to any `kube-apiserver` instance
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew prevMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
|
||||
-->
|
||||
例如：
|
||||
|
||||
* `kube-apiserver` 实例处于
|
||||
**{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}** 版本
|
||||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
|
||||
与可以路由到任何 `kube-apiserver` 实例的负载均衡器通信
|
||||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
|
||||
支持 **{{< skew prevMinorVersion >}}** 版本（不支持 **{{< skew latestVersion >}}**
|
||||
版本，因为它比 **{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 实例新）
|
||||
|
||||
<!--
|
||||
### kubectl
|
||||
|
||||
`kubectl` is supported within one minor version (older or newer) of `kube-apiserver`.
|
||||
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kubectl` is supported at **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}**, and **{{< skew prevMinorVersion >}}**
|
||||
-->
|
||||
### kubectl {#kubectl}
|
||||
|
||||
`kubectl` 在 `kube-apiserver` 的一个次要版本（较旧或较新）中支持。
|
||||
|
||||
例如：
|
||||
|
||||
* `kube-apiserver` 处于 **{{< skew latestVersion >}}** 版本
|
||||
* `kubectl` 支持 **{{< skew nextMinorVersion >}}**、**{{< skew latestVersion >}}**
|
||||
和 **{{< skew prevMinorVersion >}}** 版本
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
|
||||
-->
|
||||
如果 HA 集群中的 `kube-apiserver` 实例之间存在版本偏差，这会缩小支持的 `kubectl` 版本范围。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
* `kubectl` is supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
|
||||
-->
|
||||
例如：
|
||||
|
||||
* `kube-apiserver` 实例处于
|
||||
**{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}** 版本
|
||||
* `kubectl` 支持 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
|
||||
版本（其他版本将与 `kube-apiserver` 组件之一相差不止一个的次要版本）
|
||||
|
||||
<!--
|
||||
## Supported component upgrade order
|
||||
|
||||
The supported version skew between components has implications on the order in which components must be upgraded.
|
||||
This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew prevMinorVersion >}}** to version **{{< skew latestVersion >}}**.
|
||||
-->
|
||||
## 支持的组件升级顺序 {#supported-component-upgrade-order}
|
||||
|
||||
组件之间支持的版本偏差会影响必须升级组件的顺序。
|
||||
本节介绍了将现有集群从 **{{< skew prevMinorVersion >}}**
|
||||
版本转换到 **{{< skew latestVersion >}}** 版本时必须升级组件的顺序。
|
||||
|
||||
<!--
|
||||
### kube-apiserver
|
||||
|
||||
Pre-requisites:
|
||||
|
||||
* In a single-instance cluster, the existing `kube-apiserver` instance is **{{< skew prevMinorVersion >}}**
|
||||
* In an HA cluster, all `kube-apiserver` instances are at **{{< skew prevMinorVersion >}}** or **{{< skew latestVersion >}}** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance)
|
||||
* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **{{< skew prevMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version)
|
||||
* `kubelet` instances on all nodes are at version **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
|
||||
* Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them:
|
||||
* `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **{{< skew latestVersion >}}** (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+)
|
||||
* The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **{{< skew latestVersion >}}**
|
||||
-->
|
||||
### kube-apiserver {#kube-apiserver-1}
|
||||
|
||||
先决条件：
|
||||
|
||||
* 在单实例集群中，现有的 `kube-apiserver` 实例处于 **{{< skew prevMinorVersion >}}** 版本
|
||||
* 在 HA 集群中，所有 `kube-apiserver` 实例都处于
|
||||
**{{< skew prevMinorVersion >}}** 或 **{{< skew latestVersion >}}** 版本
|
||||
（这确保了最老和最新的 `kube-apiserver` 实例之间的 1 个次要版本的最大偏差）
|
||||
* 与此服务器通信的 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
|
||||
实例的版本为 **{{< skew prevMinorVersion >}}**
|
||||
（这确保它们是不比现有 API 服务器版本还要新，并且在新 API 服务器版本的 1 个次要版本内）
|
||||
* 所有节点上的 `kubelet` 实例都是
|
||||
**{{< skew prevMinorVersion >}}** 或 **{{< skew oldMinorVersion >}}**
|
||||
版本（这确保它们不比现有 API 服务器版本新，并且在新 API 服务器版本的 2 个次要版本内）
|
||||
* 已注册的 admission webhook 能够处理新的 `kube-apiserver` 实例将发送给他们的数据：
|
||||
* `ValidatingWebhookConfiguration` 和 `MutatingWebhookConfiguration`
|
||||
对象已更新以包含 **{{< skew latestVersion >}}** 中添加的任何新版本的 REST 资源
|
||||
（或使用 v1.15+ 中可用的 [`matchPolicy: Equivalent` 选项](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)）
|
||||
* webhook 能够处理将发送给它们的任何新版本的 REST 资源，
|
||||
以及添加到 **{{< skew latestVersion >}}** 中现有版本的任何新字段
|
||||
|
||||
<!--
|
||||
Upgrade `kube-apiserver` to **{{< skew latestVersion >}}**
|
||||
-->
|
||||
将 `kube-apiserver` 升级到 **{{< skew latestVersion >}}** 版本
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
|
||||
[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
|
||||
require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
|
||||
-->
|
||||
[API 弃用](/zh/docs/reference/using-api/deprecation-policy/)和
|
||||
[API 变更指南](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
|
||||
的项目策略要求 `kube-apiserver` 在升级时不跳过次要版本，即使在单实例集群中也是如此。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
|
||||
|
||||
Pre-requisites:
|
||||
|
||||
* The `kube-apiserver` instances these components communicate with are at **{{< skew latestVersion >}}** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components)
|
||||
|
||||
Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew latestVersion >}}**
|
||||
-->
|
||||
### kube-controller-manager、kube-scheduler 和 cloud-controller-manager {#kube-controller-manager-kube-scheduler-and-cloud-controller-manager-1}
|
||||
|
||||
先决条件：
|
||||
|
||||
* 与这些组件通信的 `kube-apiserver` 实例处于 **{{< skew latestVersion >}}** 版本
|
||||
（在 HA 集群中，这些控制平面组件可以与集群中的任何 `kube-apiserver` 实例通信，
|
||||
所有 `kube-apiserver` 实例必须在升级这些组件之前升级）
|
||||
|
||||
将 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
|
||||
升级到 **{{< skew latestVersion >}}** 版本
|
||||
|
||||
<!--
|
||||
### kubelet
|
||||
|
||||
Pre-requisites:
|
||||
|
||||
* The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew latestVersion >}}**
|
||||
|
||||
Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
|
||||
-->
|
||||
### kubelet {#kubelet-1}
|
||||
|
||||
先决条件：
|
||||
|
||||
* 与 `kubelet` 通信的 `kube-apiserver` 实例处于 **{{< skew latestVersion >}}** 版本
|
||||
|
||||
可选择将 `kubelet` 实例升级到 **{{< skew latestMinorVersion >}}** 版本
|
||||
（或者它们可以留在 **{{< skew prevMinorVersion >}}** 或 **{{< skew oldMinorVersion >}}** 版本）
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node.
|
||||
In-place minor version `kubelet` upgrades are not supported.
|
||||
-->
|
||||
在执行次要版本 `kubelet` 升级之前，[排空](/zh/docs/tasks/administer-cluster/safely-drain-node/)该节点的 Pod。
|
||||
`kubelet` 不支持原地次要版本升级。
|
||||
{{</ note >}}
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
|
||||
|
||||
* they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
|
||||
* it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
|
||||
-->
|
||||
不建议运行 `kubelet` 实例始终落后 `kube-apiserver` 两个次要版本的集群：
|
||||
|
||||
* 它们必须在 `kube-apiserver` 的一个次要版本中升级，然后才能升级控制平面
|
||||
* 它增加了运行早于三个处于维护状态的次要版本的 `kubelet` 的可能性
|
||||
{{</ warning >}}
|
||||
|
||||
<!--
|
||||
### kube-proxy
|
||||
|
||||
* `kube-proxy` must be the same minor version as `kubelet` on the node.
|
||||
* `kube-proxy` must not be newer than `kube-apiserver`.
|
||||
* `kube-proxy` must be at most two minor versions older than `kube-apiserver.`
|
||||
|
||||
Example:
|
||||
|
||||
If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**:
|
||||
|
||||
* `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**.
|
||||
* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
|
||||
-->
|
||||
### kube-proxy {#kube-proxy}
|
||||
|
||||
* `kube-proxy` 和节点上的 `kubelet` 必须是相同的次要版本。
|
||||
* `kube-proxy` 版本不能比 `kube-apiserver` 版本新。
|
||||
* `kube-proxy` 最多只能比 `kube-apiserver` 落后两个次要版本。
|
||||
|
||||
例如：
|
||||
|
||||
如果 `kube-proxy` 版本处于 **{{< skew oldMinorVersion >}}** 版本：
|
||||
|
||||
* `kubelet` 必须处于相同的次要版本 **{{< skew oldMinorVersion >}}**。
|
||||
* `kube-apiserver` 版本必须介于 **{{< skew oldMinorVersion >}}** 和 **{{< skew latestVersion >}}** 之间，包括两者。
|
||||
Reference in New Issue
Block a user