发行版本

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

1 - Kubernetes 发布周期

针对发布里程碑的特性增强、Issue 和 PR

本文档重点是面向于那些需要创建针对特定发布里程碑的特性增强、问题或拉取请求的 Kubernetes 开发人员和贡献者。

• TL;DR
  • 正常开发（第 1-11周）
  • 代码冻结（第 12-14 周）
  • 发布后（第 14 周以上）
• 定义
• 发布周期
• 从里程碑中删除项目
• 向里程碑添加项目
  • 里程碑维护者
  • 新增特性
  • 问题补充
  • 新增 PR
• 其他必需标签
  • SIG 所有者标签
  • 优先级标签
  • Issue/PR 分类标签

将特性增强、问题和拉取请求引入 Kubernetes 版本的过程涉及多个利益相关者：

• 特性增强、问题和拉取请求的所有者
• SIG 负责人
• 发布团队

关于工作流程和交互的信息如下所述。

作为特性增强、问题或拉取请求 (PR) 的所有者，你有责任确保满足里程碑发布要求。 如果需要更新，自动化和发布团队将与你联系，但无响应可能会导致你的工作从里程碑中删除。 当目标里程碑是先前版本时，还存在其他要求（请参阅 Cherry Pick 流程了解更多信息）。

TL;DR

如果你希望你的 PR 被合并，它需要以下必备的标签和里程碑，它们由 Prow /commands 所添加表示：

正常开发（第 1-11 周）

• /sig {name}
• /kind {type}
• /lgtm
• /approved

代码冻结（第 12-14 周）

• /milestone {v1.y}
• /sig {name}
• /kind {bug, failing-test}
• /lgtm
• /approved

发布后（第 14 周以上）

回到“正常开发”阶段要求：

• /sig {name}
• /kind {type}
• /lgtm
• /approved

合并到 1.y 分支现在是通过 Cherry Pick，由发布管理员批准。

过去，针对里程碑的拉取请求需要打开相关的 GitHub 问题，但现在情况不再如此。 特性或特性增强实际上是 GitHub 问题或导致后续 PR 的 KEPs。

一般的打标签过程应该在不同工件类型之间保持一致。

定义

• 问题所有者：将问题移至发布里程碑的创建者、委托人和用户

• 发布小组：每个 Kubernetes 版本都有一个团队来执行这里所描述的项目管理任务。

  可以在此处找到与任何给定版本相关联的团队的联系信息。

• Y 天：指工作日

• 增强：参见“我的改进是特性增强吗？”

• 特性增强冻结： 为了使特性增强成为当前版本的一部分，必须在 KEPs 的截止日期前完成

• 异常请求： 请求延长特性增强的截止日期的过程

• 代码冻结： 最终发布日期前约 4 周的时间，在此期间，仅将关键错误修复合并到发布中。

• 修剪： 如果特性增强未完全实现或被认为不稳定，则在此过程中从发布里程碑中删除它。

• 发布里程碑：语义版本字符串或 GitHub 里程碑 指的是发布 主.次 vX.Y 版本。

  另请参阅发布版本控制。

• 发布分支：为 vX.Y 里程碑创建的 Git 分支 release-X.Y。

  在 vX.Y-rc.0 发布时创建，并在发布后使用 vX.Y.Z 补丁版本，维护大约 12 个月。

  注意：1.19 及更高版本获得 1 年的补丁版本支持，1.18 及更早版本获得 9 个月的补丁版本支持。

发布周期

Kubernetes 目前大约每年发布三次。

发布过程可被认为具有三个主要阶段：

• 特性增强定义
• 实现
• 稳定

但实际上，这是一个灵活的开源项目，功能规划和实施始终在进行。 鉴于项目规模和全球分布的开发人员基础，对项目速度至关重要的是不依赖于后续的稳定阶段， 而是进行持续集成测试，以确保项目始终稳定，以便可以将单个提交标记为有问题。

随着全年功能定义的不断进行，某些项目将冒泡作为给定版本的目标。 在发布周期约 4 周后开始 冻结特性增强。 至此，针对给定版本的所有预期功能工作都已与发布团队的 特性增强负责人 一起在合适的规划工件中定义。

特性增强冻结后，跟踪 PR 和问题的里程碑很重要。里程碑中的项目作为完成发布的下达列表。 关于问题，里程碑必须通过 SIG 的分类正确应用， 以便发布团队可以跟踪错误和特性增强（任何与特性增强相关的问题都需要里程碑）。

自动化可以自动将里程碑分配给 PR。

此自动化当前适用于以下存储库：

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

在创建时，针对 master 分支的 PR 需要人工提示他们可能希望 PR 指向哪个里程碑。 一旦合并，针对 master 分支的 PR 会自动应用里程碑，因此从那时起，不再需要人工管理该 PR 的里程碑。 在指向发布分支的 PR 上，会在创建 PR 时自动应用里程碑，因此不需要对里程碑进行人工管理。

任何其他应该由发布团队跟踪的不属于该自动化保护伞的工作都应该应用一个里程碑。

整个周期都在进行实施和错误修复，但最终会出现代码冻结期。

代码冻结 大约从第 12 周开始，持续约 2 周。 在此期间，只有关键的错误修复才会被接受到发布代码库中。

在代码冻结之后和之前的发布之间大约有两周时间，在此期间，必须在发布版本前解决所有剩余的严重问题。 这也为文档定稿提供了时间。

当代码库足够稳定时，主分支将重新打开以进行一般开发，并从那里开始下一个发布里程碑的工作。 当前版本的任何剩余修改都是从 master 挑选回发布分支。发布版本是从发布分支构建的。

每个版本都是更广泛的 Kubernetes 生命周期的一部分：

从里程碑中删除项目

在深入了解将项目添加到里程碑的过程之前，请注意：

如果发布小组的成员或负责的 SIG 确定问题实际上并未阻止发布并且不太可能及时解决，则可以从里程碑中删除问题。

发布团队的成员可以出于以下任何原因或类似原因从里程碑中删除 PR：

• PR 可能会破坏稳定，并且不需要去解决阻塞问题
• PR 是一个新的、较晚的特性 PR 并且没有经过增强过程或异常过程
• 没有负责任的 SIG 愿意接管 PR 并解决任何后续问题
• PR 未正确标记
• PR 工作明显停止，交付日期不确定或延迟

虽然发布团队的成员将帮助标记和联系 SIG，但提交者有责任对 PR 进行分类， 并获得相关 SIG 的支持，以保证由 PR 引起的任何破坏都会得到迅速解决。

如果需要采取其他措施，发布团队将通过以下渠道尝试进行人与人之间的对话：

• 在 GitHub 中发表评论，根据问题类型提及 SIG 团队和 SIG 成员
• 给 SIG 邮件列表发邮件
  • 使用来自社区 SIG 列表的群组电子邮件地址进行引导
  • 也可选择直接与 SIG 负责人或 SIG 其他成员联系
• 向 SIG 的 Slack 频道发送消息
  • 在 Slack 频道 和 SIG 负责人的引导下 [社区签名列表][签名列表]
  • 可选地直接 “@” 来提及 SIG 负责人或其他人

向里程碑添加项目

里程碑维护者

milestone-maintainers GitHub 团队的成员负责在 GitHub 工件上指定发布里程碑。

该小组由 SIG Release 维护，并有来自各个 SIG 负责人的代表。

特性添加

如今，功能规划和定义有多种形式，但一个典型的例子可能是 KEP 中描述的大量工作，以及 GitHub 中的相关任务问题。 当计划达到可实施状态并且工作正在进行中时，通过创建 GitHub 问题并使用 Prow "/milestone" 命令对其进行标记，特性增强或其部分指向未来的里程碑。

在发布周期的前 4 周左右内，发布团队的特性增强负责人将通过 GitHub、Slack 和 SIG 会议与 SIG 和特性所有者互动，以获取所有需要的计划工件。

如果你有针对即将发布的里程碑的特性增强，请与你的 SIG 领导以及该版本的特性增强负责人开始对话。

问题补充

通过 Prow “/milestone” 命令标记问题并指向里程碑。

发布团队的错误分类负责人和整个社区观察新出现的问题并对其进行分类， 在贡献者指南部分中描述问题分类。

用里程碑标记问题可以让社区更好地了解何时观察到问题以及社区认为何时必须解决问题。 代码冻结期间，必须设置里程碑以合并 PR。

一个 PR 不再需要一个已开启的问题，但已开启的问题和相关的 PR 应该有同步的标签。 例如，如果 PR 仅标记为较低优先级，则高优先级错误问题可能不会合并其关联的 PR。

PR 补充

PR 通过 Prow “/milestone” 命令标记并指向里程碑。

如上所述，这是代码冻结期间的阻塞要求。

其他必需的标签

这里是标签列表及其用途和目的。

SIG 所有者标签

SIG 所有者标签定义了当里程碑问题未取得进展或需要额外关注时，我们应该逐步升级的 SIG。 如果升级后没有更新，该问题可能会自动从里程碑中删除。

这些是通过 Prow "/sig" 命令添加的。 例如要添加指示 SIG Storage 负责的标签，请使用 /sig storage 进行评论。

优先级标签

优先级标签用于在将问题移出发布里程碑之前确定升级路径。 它们还用于确定在解决问题时是否应阻止发布。

• priority/critical-urgent：永远不会自动移出发布里程碑；通过所有可用渠道不断上报给贡献者和 SIG。
  • 考虑发布阻塞问题
  • 在代码冻结期间需要问题所有者的每日更新
  • 如果在次要版本之后才被发现，则需要补丁版本
• priority/important-soon：上报给问题所有者和 SIG 所有者；在几次不成功的升级尝试后退出里程碑。
  • 不考虑发布阻止问题
  • 不需要补丁版本
  • 将在 4 天的宽限期后自动移出代码冻结的发布里程碑
• priority/important-longterm：上报给问题所有者；1 次尝试后移出里程碑
  • 比 priority/important-soon 更不紧急/不关键
  • 比 priority/important-soon 更积极地移出里程碑

Issue/PR 分类标签

Issue 类型用于帮助识别随着时间的推移进入版本的更改类型。 这可以让发布团队更好地了解我们会在更快的发布节奏下错过哪些类型的 Issue。

对于发布版本的目标问题，包括拉取请求，必须设置以下问题类型标签之一：

• kind/api-change：添加、删除或更改 API
• kind/bug：修复了一个新发现的错误
• kind/cleanup：添加测试、重构、修复旧错误
• kind/design：与设计相关
• kind/documentation：添加文档
• kind/failing-test：CI 测试用例一直失败
• kind/feature：新功能
• kind/flake：CI 测试用例显示间歇性故障

2 - 版本偏差策略

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

支持的版本

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

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

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

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

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

支持的版本偏差

kube-apiserver

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

例如：

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

kubelet

• kubelet 版本不能比 kube-apiserver 版本新。
• kubelet 可以比 kube-apiserver 低三个次要版本（如果 kubelet < 1.25，则只能比 kube-apiserver 低两个次要版本）。

例如：

• kube-apiserver 处于 1.30 版本
• kubelet 支持 1.30、1.29、1.28 和 1.27 版本

例如：

• kube-apiserver 实例处于 1.30 和 1.29 版本
• kubelet 支持 1.29、1.28 和 1.27 版本， （不支持 1.30 版本，因为这将比 kube-apiserver 1.29 版本的实例新）

kube-proxy

• kube-proxy 不能比 kube-apiserver 新。
• kube-proxy 最多可以比 kube-apiserver 旧三个小版本（kube-proxy < 1.25 最多只能比 kube-apiserver 旧两个小版本）。
• kube-proxy 可能比它旁边运行的 kubelet 实例旧或新最多三个次要版本（kube-proxy < 1.25 最多只能是比它并行运行的 kubelet 实例旧或新的两个次要版本）。

例如：

• kube-apiserver 的版本是 1.30
• kube-proxy 支持的版本是 1.30、 1.29 、1.28 和 1.27

例如：

• kube-apiserver 实例的版本是 1.30 和 1.29
• kube-proxy 版本为 1.29、 1.28 和 1.27。（1.30 将不被支持， 因为该版本将比 1.29 的 kube-apiserver 实例更新）

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

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

例如：

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

例如：

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

kubectl

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

例如：

• kube-apiserver 处于 1.30 版本
• kubectl 支持 1.31、1.30 和 1.29 版本

例如：

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

支持的组件升级顺序

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

作为一种可选方案，在准备升级时，Kubernetes 项目建议你执行以下操作， 有利于升级时包含尽可能多的回归和错误修复：

• 确保组件是当前次要版本的最新补丁版本。
• 将组件升级到目标次要版本的最新补丁版本。

例如，如果你正在运行版本 1.29， 请确保你使用的是最新的补丁版本。 然后，升级到 1.30 的最新补丁版本。

kube-apiserver

先决条件：

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

将 kube-apiserver 升级到 1.30 版本

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

先决条件：

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

将 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 升级到 1.30 版本。 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 的升级顺序没有要求。 你可以按任意顺序升级这些组件，甚至可以同时升级这些组件。

kubelet

先决条件：

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

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

kube-proxy

前提条件：

• 与 kube-proxy 通信的 kube-apiserver 实例的版本是 1.30。 可以选择升级 kube-proxy 实例到 1.30 （或者它们可以保持在 1.29 或 1.28）

3 - 补丁版本

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

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

节奏

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

联系方式

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

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

在两次发布之间，团队每周都会查看收到的 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.29

下个补丁发布是 1.29.3。

1.29 于 2024-12-28 进入维护模式，生命周期结束于 2025-02-28。

1.28

下个补丁发布是 1.28.8。

1.28 于 2024-08-28 进入维护模式，生命周期结束于 2024-10-28。

1.27

下个补丁发布是 1.27.12。

1.27 于 2024-04-28 进入维护模式，生命周期结束于 2024-06-28。

1.26

下个补丁发布是 Not Planned。

1.26 于 2023-12-28 进入维护模式，生命周期结束于 2024-02-28。

非活动分支历史

不再支持这些版本。

4 - 发布管理员

“发布管理员（Release Managers）” 是一个总称，通过使用 SIG Release 提供的工具， 负责维护发布分支、标记发行版本以及创建发行版本的贡献者。

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

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

联系方式

安全禁运政策

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

手册

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

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

发布管理员

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

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

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

发布管理员负责：

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

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

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

GitHub 提及：@kubernetes/release-engineering

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

成为发布管理员

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

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

发布管理员助理

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

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

GitHub 提及：@kubernetes/release-engineering

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

成为发布管理员助理

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

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

SIG Release 负责人

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

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

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

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

主席

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

技术负责人

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

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

例如：1.15 发布团队

5 - 说明

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

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

6 - 下载 Kubernetes

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

kubectl

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

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

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

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

容器镜像

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

容器镜像架构

所有容器镜像都支持多架构，而容器运行时应根据下层平台选择正确的镜像。 也可以通过给容器镜像名称加后缀来拉取适合特定架构的镜像，例如 registry.k8s.io/kube-apiserver-arm64:v%!f(string=1.).0。

容器镜像签名

对于 Kubernetes v1.30，容器镜像使用 sigstore 进行签名：

Kubernetes 项目以 SPDX 2.3 格式发布已签名的 Kubernetes 容器镜像列表。你可以使用以下方法获取该列表：

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

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

如果你要拉取特定架构的容器镜像，则单架构镜像的签名方式与多架构清单列表相同。

二进制