发行版本

• 1: 下载 Kubernetes
• 2: 发布管理员
• 3: 说明
• 4: 版本偏差策略
• 5: 补丁版本

1 - 下载 Kubernetes

Kubernetes 为每个组件提供二进制文件以及一组标准的客户端应用程序用来引导集群或与集群交互。 像 API 服务器这样的组件能够在集群内的容器镜像中运行。 作为官方发布过程的一部分，这些组件也以容器镜像的形式提供。 所有二进制文件和容器镜像都可用于多种操作系统和硬件架构。

容器镜像

所有 Kubernetes 容器镜像都部署到 k8s.gcr.io 容器仓库。

对于 Kubernetes v1.24，以下容器镜像使用 cosign 进行签名：

所有容器镜像都支持多种体系结构，容器运行时应根据下层平台选择正确的镜像。 也可以通过给容器镜像名称加后缀来拉取特定体系结构的镜像，例如 k8s.gcr.io/kube-apiserver-arm64:v1.24.0。 所有这些派生镜像都以与多架构清单列表相同的方式签名。

Kubernetes 项目以 SBoM（软件物料清单）格式发布已签名的 Kubernetes 容器镜像列表。 你可以使用以下方法获取该列表：

curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/latest.txt)/release"  | awk '/PackageName: k8s.gcr.io\// {print $2}'

对于 Kubernetes v1.24，唯一可以验证完整性的代码工件就是容器镜像，它使用实验性签名支持。

如需手动验证 Kubernetes 核心组件的签名容器镜像，请参考验证签名容器镜像。

二进制

在 CHANGELOG 文件中找到下载 Kubernetes 组件（及其校验和）的链接。

或者，使用 downloadkubernetes.com 按版本和架构进行过滤。

kubectl

Kubernetes 命令行工具 kubectl 允许你对 Kubernetes 集群执行命令。

你可以使用 kubectl 部署应用程序、检查和管理集群资源以及查看日志。 有关更多信息，包括 kubectl 操作的完整列表，请参阅 kubectl 参考文档。

kubectl 可安装在各种 Linux 平台、macOS 和 Windows 上。 在下方找到你首选的操作系统。

• 在 Linux 上安装 kubectl
• 在 macOS 上安装 kubectl
• 在 Windows 上安装 kubectl

2 - 发布管理员

“发布管理员（Release Managers）”是一个总称，包括一批负责维护发布分支、标记发行版本以及构建/打包 Kubernetes 的 Kubernetes 贡献者。

每个角色的职责如下所述。

• 联系方式
  • 安全禁运政策
• 手册
• 发布管理员
  • 成为发布管理员
• 发布管理员助理
  • 成为发布管理员助理
• 构建管理员
• SIG 发布负责人
  • 首席
  • 技术负责人

联系方式 #{contact}

安全禁运政策

发布的相关信息受到禁运，我们已经定义了有关如何设置这些禁运的政策。 更多信息请参考安全禁运政策。

手册

注意：补丁发布团队和分支管理员手册以后将会删除重复数据。

• 补丁发布团队
• 分支管理员
• 构建管理员

发布管理员

注意： 文档可能涉及补丁发布团队和分支管理角色。这两个角色被合并到发布管理员角色中。

发布管理员和发布管理员助理的最低要求是：

• 熟悉基本的 Unix 命令并能够调试 shell 脚本。
• 熟悉通过 git 和 git 相关的命令行触发的分支源代码工作流。
• 谷歌云的常识（云构建和云存储）。
• 乐于寻求帮助和清晰地沟通。
• Kubernetes 社区 会员资格

发布管理员负责：

• 协调和确定 Kubernetes 发行版本：
  • 补丁发布（x.y.z，其中 z > 0）
  • 次要版本（x.y.z，其中 z = 0）
  • 预发布（alpha、beta 和候选发布）
  • 通过每个发布周期与发布小组合作
  • 设置补丁发布的时间表和节奏
• 维护发布分支：
  • 审查 Cherry Pick
  • 确保发布分支保持健康并且没有合并意外的补丁
• 指导发布管理员助理小组
• 积极开发功能并维护 k/release 中的代码
• 通过积极参与 Buddy 计划来支持发布管理员助理和贡献者
  • 每月与助理核对并委派任务，授权他们生成发行版本并指导工作
  • 支持助理小组加入新的贡献者，例如回答问题并建议他们做适当的工作

该团队有时与安全响应委员会密切合作，因此应遵守安全发布流程中规定的指导方针。

GitHub 访问控制：@kubernetes/release-managers

GitHub 提及：@kubernetes/release-engineering

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

成为发布管理员

要成为发布管理员，首先必须担任发布管理员助理。助理通过在多个周期内积极处理发布，从而毕业成为发布管理员，并且：

• 表现出带头的意愿
• 与发布管理员合作，为补丁打标记，最终独立制作发行版本
  • 因为发布具有限制功能，我们还考虑对镜像推广和其他核心发布工程任务的实质性贡献
• 质疑助理的工作方式、提出改进建议、收集反馈并推动变革
• 可靠且反应迅速
• 专注于需要发布管理员级别访问和权限才能完成的高级工作

发布管理员助理

发布管理员助理是发布管理员的学徒，以前称为发布管理员影子。他们负责：

• 补丁发布工作，Cherry Pick 审查
• 为 k/release 做贡献：更新依赖并习惯源代码库
• 为文档做贡献：维护手册，确保发布过程记录在案
• 在发布管理员的帮助下：在发布周期中与发布团队合作并减少 Kubernetes 发型版本
• 寻求机会帮助确定优先级和沟通
  • 发送有关补丁发布的预告和更新
  • 更新日历，帮助确定发布周期时间线中的发布日期和里程碑
• 通过 Buddy 计划，加入新的贡献者并与他们合作完成任务

GitHub 提及：@kubernetes/release-engineering

• Arnaud Meukam (@ameukam)
• Jim Angel (@jimangel)
• Joyce Kung (@thejoycekung)
• Max Körbächer (@mkorbi)
• Seth McCombs (@sethmccombs)
• Taylor Dolezal (@onlydole)
• Wilson Husin (@wilsonehusin)

成为发布管理员助理

贡献者可以通过展示以下内容成为助理：

• 持续参与，包括 6-12 个月的发布工程相关的积极工作
• 在发布周期内担任发布团队的技术负责人角色的经验
  • 这种经验为理解 SIG Release 如何整体运作提供了坚实的基础——包括我们对技术技能、沟通、响应能力和可靠性的期望
• 致力于改进我们与 Testgrid 交互的 k/release 项目，清理仓库等。
  • 这些工作需要与发布管理员和助理进行互动和合作

构建管理员

构建管理员（目前）是谷歌员工，他们拥有对谷歌构建系统/工具的必要访问权限，可以代表 Kubernetes 项目发布 deb/rpm 包。他们负责：

• 构建、签名和发布 deb/rpm 包
• 在每个次要 (1.Y) 和补丁 (1.Y.Z) 版本的最后步骤中与发布管理员（和助理）互锁

GitHub 团队：@kubernetes/build-admins

• Aaron Crickenberger (@spiffxp)
• Benjamin Elder (@BenTheElder)
• Grant McCloskey (@MushuEE)
• Juan Escobar (@juanfescobar)

SIG Release 负责人

SIG Release 主席和技术负责人负责：

• SIG Release 的治理
• 领导发布管理员和助理的知识交流会议
• 传授领导力和优先排序方法

此处明确提及他们，因为他们是每个角色的各种沟通渠道和权限组（GitHub 团队、GCP 访问）的所有者。 因此，他们是享有很高特权的社区成员，并参与了一些私人沟通，这些沟通有时可能与 Kubernetes 安全披露有关。

GitHub 团队：@kubernetes/sig-release-leads

主席

• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)

技术负责人

• Adolfo García Veytia (@puerco)
• Carlos Panato (@cpanato)
• Jeremy Rickard (@jeremyrickard)

过去的分支管理员，可以在 release-x.y/release_team.md 中 kubernetes/sig-release 仓库的发布目录中找到。

例如：1.15 发布团队

3 - 说明

可以通过阅读与你的 Kubernetes 版本对应的 Changelog 找到发行版本说明。 在 GitHub 上查看 1.24 的变更日志。

或者，可以在以下位置在线搜索和筛选发行版本说明：relnotes.k8s.io。 在 relnotes.k8s.io 上查看 1.24 的筛选后的版本说明。

4 - 版本偏差策略

本文档描述了 Kubernetes 各个组件之间所支持的最大版本偏差。 特定的集群部署工具可能会对版本偏差添加额外的限制。

支持的版本

Kubernetes 版本以 x.y.z 表示，其中 x 是主要版本， y 是次要版本，z 是补丁版本，遵循语义版本控制术语。 更多信息请参见 Kubernetes 版本发布控制。

Kubernetes 项目维护最近的三个次要版本（1.24、1.23、）的发布分支。 Kubernetes 1.19 和更新的版本获得大约 1 年的补丁支持。 Kubernetes 1.18 及更早的版本获得了大约 9 个月的补丁支持。

适当的修复，包括安全问题修复，可能会被后沿三个发布分支，具体取决于问题的严重性和可行性。 补丁版本按常规节奏从这些分支中删除，并在需要时增加额外的紧急版本。

发布管理员小组拥有这件事的决定权。

有关更多信息，请参阅 Kubernetes 补丁发布页面。

支持的版本偏差

kube-apiserver

在高可用性（HA）集群中， 最新版和最老版的 kube-apiserver 实例版本偏差最多为一个次要版本。

例如：

• 最新的 kube-apiserver 实例处于 1.24 版本
• 其他 kube-apiserver 实例支持 1.24 和 1.23 版本

kubelet

kubelet 版本不能比 kube-apiserver 版本新，并且最多只可落后两个次要版本。

例如：

• kube-apiserver 处于 1.24 版本
• kubelet 支持 1.24、1.23 和 版本

例如：

• kube-apiserver 实例处于 1.24 和 1.23 版本
• kubelet 支持 1.23 和 版本， （不支持 1.24 版本，因为这将比 kube-apiserver 1.23 版本的实例新）

kube-controller-manager、kube-scheduler 和 cloud-controller-manager

kube-controller-manager、kube-scheduler 和 cloud-controller-manager 不能比与它们通信的 kube-apiserver 实例新。 它们应该与 kube-apiserver 次要版本相匹配，但可能最多旧一个次要版本（允许实时升级）。

例如：

• kube-apiserver 处于 1.24 版本
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 1.24 和 1.23 版本

例如：

• kube-apiserver 实例处于 1.24 和 1.23 版本
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 与可以路由到任何 kube-apiserver 实例的负载均衡器通信
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 1.23 版本（不支持 1.24 版本，因为它比 1.23 版本的 kube-apiserver 实例新）

kubectl

kubectl 在 kube-apiserver 的一个次要版本（较旧或较新）中支持。

例如：

• kube-apiserver 处于 1.24 版本
• kubectl 支持 1.25、1.24 和 1.23 版本

例如：

• kube-apiserver 实例处于 1.24 和 1.23 版本
• kubectl 支持 1.24 和 1.23 版本（其他版本将与 kube-apiserver 组件之一相差不止一个的次要版本）

支持的组件升级顺序

组件之间支持的版本偏差会影响必须升级组件的顺序。 本节介绍了将现有集群从 1.23 版本转换到 1.24 版本时必须升级组件的顺序。

kube-apiserver

先决条件：

• 在单实例集群中，现有的 kube-apiserver 实例处于 1.23 版本
• 在 HA 集群中，所有 kube-apiserver 实例都处于 1.23 或 1.24 版本 （这确保了最老和最新的 kube-apiserver 实例之间的 1 个次要版本的最大偏差）
• 与此服务器通信的 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 实例的版本为 1.23 （这确保它们是不比现有 API 服务器版本还要新，并且在新 API 服务器版本的 1 个次要版本内）
• 所有节点上的 kubelet 实例都是 1.23 或 版本（这确保它们不比现有 API 服务器版本新，并且在新 API 服务器版本的 2 个次要版本内）
• 已注册的 admission webhook 能够处理新的 kube-apiserver 实例将发送给他们的数据：
  • ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象已更新以包含 1.24 中添加的任何新版本的 REST 资源 （或使用 v1.15+ 中可用的 matchPolicy: Equivalent 选项）
  • webhook 能够处理将发送给它们的任何新版本的 REST 资源， 以及添加到 1.24 中现有版本的任何新字段

将 kube-apiserver 升级到 1.24 版本

kube-controller-manager、kube-scheduler 和 cloud-controller-manager

先决条件：

• 与这些组件通信的 kube-apiserver 实例处于 1.24 版本 （在 HA 集群中，这些控制平面组件可以与集群中的任何 kube-apiserver 实例通信， 所有 kube-apiserver 实例必须在升级这些组件之前升级）

将 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 升级到 1.24 版本

kubelet

先决条件：

• 与 kubelet 通信的 kube-apiserver 实例处于 1.24 版本

可选择将 kubelet 实例升级到 版本 （或者它们可以留在 1.23 或 版本）

kube-proxy

• kube-proxy 和节点上的 kubelet 必须是相同的次要版本。
• kube-proxy 版本不能比 kube-apiserver 版本新。
• kube-proxy 最多只能比 kube-apiserver 落后两个次要版本。

例如：

如果 kube-proxy 版本处于 版本：

• kubelet 必须处于相同的次要版本 。
• kube-apiserver 版本必须介于 和 1.24 之间，包括两者。

5 - 补丁版本

Kubernetes 补丁版本的发布时间表和团队联系信息。

有关 Kubernetes 发布周期的常规信息，请参阅发布流程说明。

节奏

我们的补丁发布节奏通常是每月一次。 在 1.X 次要版本之后，最早的补丁版本通常要快一些（提前 1 到 2 周）。 严重错误修复可能会导致超出正常节奏而更快速的发布。 我们尽量避免在主假期期间发布。

联系

有关补丁发布团队的完整联系方式，请参阅发布管理员页面。

请给我们一个工作日回复，因为我们可能在不同的时区！

在两次发布之间，团队每周都会查看收到的 cherry pick 请求。 如果对 PR 有任何问题，团队将通过 GitHub PR、Slack 中的 SIG 频道以及 Slack 中的直接消息和 email 与提交者取得联系。

Cherry Pick

请遵循 Cherry Pick 流程。

Cherry Pick 必须在 GitHub 中准备好合并，带有适当的标签（例如 approved、lgtm、release-note）， 并在 Cherry Pick 截止日期之前通过 CI 测试。这通常是目标发布前两天，但可能更早。 PR 越早准备好越好，因为在实际发布之前，合并了你的 Cherry Pick 后，我们需要时间来获取 CI 信号。

不符合合并标准的 Cherry Pick PR 将被带入下一个补丁版本中跟踪。

支持周期

根据年度 KEP，Kubernetes 社区将在大约 14 个月的时间内支持活跃的补丁发布系列。

此时间范围的前 12 个月将被视为标准周期。

在 12 个月后，将发生以下事情：

• 发布管理员将删除一个版本
• 补丁发布系列将进入维护模式

在两个月的维护模式期间，发布管理员可能会删减额外的维护版本以解决：

• CVE（在安全响应委员会的建议下）
• 依赖问题（包括基础镜像更新）
• 关键核心组件问题

在两个月的维护模式期结束时，补丁发布系列将被视为 EOL（生命周期结束），相关分支的 Cherry Pick 将很快关闭。

请注意，为简单起见，选择每月 28 日作为维护模式和 EOL 目标日期（每个月都有）。

未来发布的月度版本

时间表可能会因错误修复的严重程度而有所不同，但为了便于规划，我们将针对以下每月发布点。 计划外的关键版本也可能发生在这些版本之间。

活动分支的详细发布历史

1.24

下一个补丁版本是 1.24.1

1.24 的生命周期结束时间为 2023-09-29

1.23

1.23 于 2022-12-28 进入维护模式。

1.23 的生命周期结束时间为 2023-02-28。

1.22

1.22 于 2022-08-28 进入维护模式

1.22 的生命周期结束时间为 2022-10-28

1.21

1.21 于 2022-04-28 进入维护模式

1.21 的生命周期结束时间为 2022-06-28

非活动分支历史

不再支持这些版本。