Kubernetes 项目维护最近三个次要版本（1.32、1.31、 1.30）的发布分支。 Kubernetes 1.19 和更新版本获得大约 1 年的补丁支持。 Kubernetes 1.18 及更早版本获得了大约 9 个月的补丁支持周期。
Kubernetes 版本表示为 x.y.z， 其中 x 是主要版本，y 是次要版本，z 是补丁版本，遵循语义版本控制术语。
更多信息在版本偏差策略文档中。
查看即将发布的 Kubernetes 1.33 时间表！
有关角色和发布流程的重要信息， 请参阅 Kubernetes 发布团队 资源。
此内容原文是自动生成的，链接可能无法正常访问。 文档的来源在这里。
本文档重点是面向于那些需要创建针对特定发布里程碑的特性增强、问题或拉取请求的 Kubernetes 开发人员和贡献者。
将特性增强、问题和拉取请求引入 Kubernetes 版本的过程涉及多个利益相关者：
关于工作流程和交互的信息如下所述。
作为特性增强、问题或拉取请求 (PR) 的所有者，你有责任确保满足里程碑发布要求。 如果需要更新，自动化和发布团队将与你联系，但无响应可能会导致你的工作从里程碑中删除。 当目标里程碑是先前版本时，还存在其他要求（请参阅 Cherry Pick 流程了解更多信息）。
如果你希望你的 PR 被合并，它需要以下必备的标签和里程碑，它们由 Prow /commands 所添加表示：
回到“正常开发”阶段要求：
合并到 1.y 分支现在是通过 Cherry Pick，由发布管理员批准。
过去，针对里程碑的拉取请求需要打开相关的 GitHub 问题，但现在情况不再如此。 特性或特性增强实际上是 GitHub 问题或导致后续 PR 的 KEPs。
一般的打标签过程应该在不同工件类型之间保持一致。
问题所有者：将问题移至发布里程碑的创建者、委托人和用户
发布小组：每个 Kubernetes 版本都有一个团队来执行这里所描述的项目管理任务。
可以在此处找到与任何给定版本相关联的团队的联系信息。
Y 天：指工作日
增强：参见“我的改进是特性增强吗？”
异常请求： 请求延长特性增强的截止日期的过程
代码冻结： 最终发布日期前约 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/enhancementskubernetes/kuberneteskubernetes/releasekubernetes/sig-releasekubernetes/test-infra在创建时，针对 master 分支的 PR 需要人工提示他们可能希望 PR 指向哪个里程碑。
一旦合并，针对 master 分支的 PR 会自动应用里程碑，因此从那时起，不再需要人工管理该 PR 的里程碑。
在指向发布分支的 PR 上，会在创建 PR 时自动应用里程碑，因此不需要对里程碑进行人工管理。
任何其他应该由发布团队跟踪的不属于该自动化保护伞的工作都应该应用一个里程碑。
整个周期都在进行实施和错误修复，但最终会出现代码冻结期。
代码冻结 大约从第 12 周开始，持续约 2 周。 在此期间，只有关键的错误修复才会被接受到发布代码库中。
在代码冻结之后和之前的发布之间大约有两周时间，在此期间，必须在发布版本前解决所有剩余的严重问题。 这也为文档定稿提供了时间。
当代码库足够稳定时，主分支将重新打开以进行一般开发，并从那里开始下一个发布里程碑的工作。 当前版本的任何剩余修改都是从 master 挑选回发布分支。发布版本是从发布分支构建的。
每个版本都是更广泛的 Kubernetes 生命周期的一部分：
在深入了解将项目添加到里程碑的过程之前，请注意：
如果发布小组的成员或负责的 SIG 确定问题实际上并未阻止发布并且不太可能及时解决，则可以从里程碑中删除问题。
发布团队的成员可以出于以下任何原因或类似原因从里程碑中删除 PR：
虽然发布团队的成员将帮助标记和联系 SIG，但提交者有责任对 PR 进行分类， 并获得相关 SIG 的支持，以保证由 PR 引起的任何破坏都会得到迅速解决。
如果需要采取其他措施，发布团队将通过以下渠道尝试进行人与人之间的对话：
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 通过 Prow “/milestone” 命令标记并指向里程碑。
如上所述，这是代码冻结期间的阻塞要求。
SIG 所有者标签定义了当里程碑问题未取得进展或需要额外关注时，我们应该逐步升级的 SIG。 如果升级后没有更新，该问题可能会自动从里程碑中删除。
这些是通过 Prow "/sig" 命令添加的。
例如要添加指示 SIG Storage 负责的标签，请使用 /sig storage 进行评论。
优先级标签用于在将问题移出发布里程碑之前确定升级路径。 它们还用于确定在解决问题时是否应阻止发布。
priority/critical-urgent：永远不会自动移出发布里程碑；通过所有可用渠道不断上报给贡献者和 SIG。priority/important-soon：上报给问题所有者和 SIG 所有者；在几次不成功的升级尝试后退出里程碑。priority/important-longterm：上报给问题所有者；1 次尝试后移出里程碑priority/important-soon 更不紧急/不关键priority/important-soon 更积极地移出里程碑Issue 类型用于帮助识别随着时间的推移进入版本的更改类型。 这可以让发布团队更好地了解我们会在更快的发布节奏下错过哪些类型的 Issue。
对于发布版本的目标问题，包括拉取请求，必须设置以下问题类型标签之一：
kind/api-change：添加、删除或更改 APIkind/bug：修复了一个新发现的错误kind/cleanup：添加测试、重构、修复旧错误kind/design：与设计相关kind/documentation：添加文档kind/failing-test：CI 测试用例一直失败kind/feature：新功能kind/flake：CI 测试用例显示间歇性故障本文档描述了 Kubernetes 各个组件之间所支持的最大版本偏差。 特定的集群部署工具可能会对版本偏差添加额外的限制。
Kubernetes 版本以 x.y.z 表示，其中 x 是主要版本， y 是次要版本，z 是补丁版本，遵循语义版本控制术语。 更多信息请参见 Kubernetes 版本发布控制。
Kubernetes 项目维护最近的三个次要版本（1.32、1.31、1.30）的发布分支。 Kubernetes 1.19 和更新的版本获得大约 1 年的补丁支持。 Kubernetes 1.18 及更早的版本获得了大约 9 个月的补丁支持。
适当的修复，包括安全问题修复，可能会被后沿三个发布分支，具体取决于问题的严重性和可行性。 补丁版本按常规节奏从这些分支中删除，并在需要时增加额外的紧急版本。
发布管理员小组拥有这件事的决定权。
有关更多信息，请参阅 Kubernetes 补丁发布页面。
在高可用性（HA）集群中，
最新版和最老版的 kube-apiserver 实例版本偏差最多为一个次要版本。
例如：
kube-apiserver 实例处于 1.32 版本kube-apiserver 实例支持 1.32 和 1.31 版本kubelet 版本不能比 kube-apiserver 版本新。kubelet 可以比 kube-apiserver 低三个次要版本（如果 kubelet < 1.25，则只能比 kube-apiserver 低两个次要版本）。例如：
kube-apiserver 处于 1.32 版本kubelet 支持 1.32、1.31、1.30 和 1.29 版本如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，这会缩小允许的 kubelet 版本范围。
例如：
kube-apiserver 实例处于 1.32 和 1.31 版本kubelet 支持 1.31、1.30 和 1.29 版本，
（不支持 1.32 版本，因为这将比
kube-apiserver 1.31 版本的实例新）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.32kube-proxy 支持的版本是 1.32、
1.31 、1.30 和
1.29如果在 HA 集群中的 kube-apiserver 实例之间存在版本偏差，
所允许的 kube-proxy 版本范围会被缩小。
例如：
kube-apiserver 实例的版本是 1.32 和 1.31kube-proxy 版本为 1.31、
1.30 和 1.29。（1.32 将不被支持，
因为该版本将比 1.31 的 kube-apiserver 实例更新）kube-controller-manager、kube-scheduler 和 cloud-controller-manager
不能比与它们通信的 kube-apiserver 实例新。
它们应该与 kube-apiserver 次要版本相匹配，但可能最多旧一个次要版本（允许实时升级）。
例如：
kube-apiserver 处于 1.32 版本kube-controller-manager、kube-scheduler 和 cloud-controller-manager
支持 1.32 和 1.31 版本如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，
并且这些组件可以与集群中的任何 kube-apiserver
实例通信（例如，通过负载均衡器），这会缩小这些组件所允许的版本范围。
例如：
kube-apiserver 实例处于
1.32 和 1.31 版本kube-controller-manager、kube-scheduler 和 cloud-controller-manager
与可以路由到任何 kube-apiserver 实例的负载均衡器通信kube-controller-manager、kube-scheduler 和 cloud-controller-manager
支持 1.31 版本（不支持 1.32
版本，因为它比 1.31 版本的 kube-apiserver 实例新）kubectl 在 kube-apiserver 的一个次要版本（较旧或较新）中支持。
例如：
kube-apiserver 处于 1.32 版本kubectl 支持 1.33、1.32
和 1.31 版本如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，这会缩小支持的 kubectl 版本范围。
例如：
kube-apiserver 实例处于
1.32 和 1.31 版本kubectl 支持 1.32 和 1.31
版本（其他版本将与 kube-apiserver 组件之一相差不止一个的次要版本）组件之间支持的版本偏差会影响必须升级组件的顺序。 本节介绍了将现有集群从 1.31 版本转换到 1.32 版本时必须升级组件的顺序。
作为一种可选方案，在准备升级时，Kubernetes 项目建议你执行以下操作， 有利于升级时包含尽可能多的回归和错误修复：
例如，如果你正在运行版本 1.31， 请确保你使用的是最新的补丁版本。 然后，升级到 1.32 的最新补丁版本。
先决条件：
kube-apiserver 实例处于 1.31 版本kube-apiserver 实例都处于
1.31 或 1.32 版本
（这确保了最老和最新的 kube-apiserver 实例之间的 1 个次要版本的最大偏差）kube-controller-manager、kube-scheduler 和 cloud-controller-manager
实例的版本为 1.31
（这确保它们是不比现有 API 服务器版本还要新，并且在新 API 服务器版本的 1 个次要版本内）kubelet 实例都是
1.31 或 1.30
版本（这确保它们不比现有 API 服务器版本新，并且在新 API 服务器版本的 2 个次要版本内）kube-apiserver 实例将发送给他们的数据：ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration
对象已更新以包含 1.32 中添加的任何新版本的 REST 资源
（或使用 v1.15+ 中可用的 matchPolicy: Equivalent 选项）将 kube-apiserver 升级到 1.32 版本
先决条件：
kube-apiserver 实例处于 1.32 版本
（在 HA 集群中，这些控制平面组件可以与集群中的任何 kube-apiserver 实例通信，
所有 kube-apiserver 实例必须在升级这些组件之前升级）将 kube-controller-manager、kube-scheduler 和 cloud-controller-manager
升级到 1.32 版本。
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 的升级顺序没有要求。
你可以按任意顺序升级这些组件，甚至可以同时升级这些组件。
先决条件：
kubelet 通信的 kube-apiserver 实例处于 1.32 版本可选择将 kubelet 实例升级到 版本
（或者它们可以留在 1.31 或 1.30 或 1.29 版本）
在执行次要版本 kubelet 升级之前，排空该节点的 Pod。
kubelet 不支持原地次要版本升级。
在一个集群中运行持续比 kube-apiserver 落后两个次版本的 kubelet 实例意味着在升级控制平面之前必须先升级它们。
前提条件：
在一个集群中运行持续比 kube-apiserver 落后三个次版本的 kube-proxy 实例意味着在升级控制平面之前必须先升级它们。
Kubernetes 补丁版本的发布时间表和团队联系信息。
有关 Kubernetes 发布周期的常规信息，请参阅发布流程说明。
我们的补丁发布节奏通常是每月一次。 在 1.X 次要版本之后，最早的补丁版本通常要快一些（提前 1 到 2 周）。 严重错误修复可能会导致超出正常节奏而更快速的发布。 我们尽量避免在重要的节假日期间发布。
有关补丁发布团队（Patch Release Team）的完整联系方式， 请参阅发布管理员页面。
请给我们一个工作日回复，因为我们可能在不同的时区！
在两次发布之间，团队每周都会查看收到的 cherry pick 请求。 如果对 PR 有任何问题，团队将通过 GitHub PR、Slack 中的 SIG 频道以及 Slack 中的直接消息和 Email 与提交者取得联系。
请遵循 Cherry Pick 流程。
Cherry Pick 必须在 GitHub 中准备好合并，带有适当的标签（例如 approved、lgtm、release-note），
并在 Cherry Pick 截止日期之前通过 CI 测试。这通常是目标发布前两天，但可能更早。
PR 越早准备好越好，因为在实际发布之前，合并了你的 Cherry Pick 后，我们需要时间来获取 CI 信号。
不符合合并标准的 Cherry Pick PR 将被带入下一个补丁版本中跟踪。
根据年度支持 KEP 约定，Kubernetes 社区将在大约 14 个月的时间内支持活跃的补丁发布系列。
此时间范围的前 12 个月将被视为标准周期。
在 12 个月后，将发生以下事情：
在两个月的维护模式期间，发布管理员可能会删减额外的维护版本以解决：
在两个月的维护模式期结束时，补丁发布系列将被视为 EOL（生命周期结束），相关分支的 Cherry Pick 将很快关闭。
请注意，为简单起见，选择每月 28 日作为维护模式和 EOL 目标日期（每个月都有）。
时间表可能会因错误修复的严重程度而有所不同，但为了便于规划，我们每月将按照以下时间点进行发布。 中间可能会发布一些计划外的关键版本。
| Monthly Patch Release | Cherry Pick 截止日期 | 目标日期 |
|---|---|---|
| January 2025 | ||
| February 2025 | ||
| March 2025 |
下个补丁发布是 1.32.1。
1.32 于 进入维护模式，生命周期结束于 。
| 补丁版本 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|---|---|---|---|
| 1.32.0 | - |
下个补丁发布是 1.31.5。
1.31 于 进入维护模式，生命周期结束于 。
| 补丁版本 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|---|---|---|---|
| 1.31.4 | |||
| 1.31.3 | |||
| 1.31.2 | |||
| 1.31.1 | |||
| 1.31.0 | - |
下个补丁发布是 1.30.9。
1.30 于 进入维护模式，生命周期结束于 。
| 补丁版本 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|---|---|---|---|
| 1.30.8 | |||
| 1.30.7 | |||
| 1.30.6 | |||
| 1.30.5 | |||
| 1.30.4 | |||
| 1.30.3 | |||
| 1.30.2 | |||
| 1.30.1 | |||
| 1.30.0 | - |
下个补丁发布是 1.29.13。
1.29 于 进入维护模式，生命周期结束于 。
| 补丁版本 | Cherry Pick 截止日期 | 目标日期 | 说明 |
|---|---|---|---|
| 1.29.12 | |||
| 1.29.11 | |||
| 1.29.10 | |||
| 1.29.9 | |||
| 1.29.8 | |||
| 1.29.7 | |||
| 1.29.6 | |||
| 1.29.5 | |||
| 1.29.4 | |||
| 1.29.3 | |||
| 1.29.2 | |||
| 1.29.1 | |||
| 1.29.0 | - |
不再支持这些版本。
| 次要版本 | 最终补丁发布 | 停止支持日期 | 说明 |
|---|---|---|---|
| 1.28 | 1.28.15 | ||
| 1.27 | 1.27.16 | ||
| 1.26 | 1.26.15 | 1.26.15 was released in March 2024 (after the EOL date) to pick up a new version of Go to address several Go CVEs | |
| 1.25 | 1.25.16 | 1.25.16 was released in November 2023 (after the EOL date) to fix CVE-2023-5528 | |
| 1.24 | 1.24.17 | 1.24.17 was released in August 2023 (after the EOL date) to fix CVE-2023-3676 and CVE-2023-3955 | |
| 1.23 | 1.23.17 | ||
| 1.22 | 1.22.17 | 1.22.17 was released in December 2022 (after the EOL date) to backport registry changes and fix two critical issues. | |
| 1.21 | 1.21.14 | ||
| 1.20 | 1.20.15 | ||
| 1.19 | 1.19.16 | ||
| 1.18 | 1.18.20 | Created to solve regression introduced in 1.18.19 | |
| 1.17 | 1.17.17 | ||
| 1.16 | 1.16.15 | ||
| 1.15 | 1.15.12 | ||
| 1.14 | 1.14.10 | ||
| 1.13 | 1.13.12 | ||
| 1.12 | 1.12.10 | ||
| 1.11 | 1.11.10 | ||
| 1.10 | 1.10.13 | ||
| 1.9 | 1.9.11 | ||
| 1.8 | 1.8.15 | ||
| 1.7 | 1.7.16 | ||
| 1.6 | 1.6.13 | ||
| 1.5 | 1.5.8 | ||
| 1.4 | 1.4.12 | ||
| 1.3 | 1.3.10 | ||
| 1.2 | 1.2.7 |
“发布管理员（Release Managers）” 是一个总称，通过使用 SIG Release 提供的工具， 负责维护发布分支、标记发行版本以及创建发行版本的贡献者。
每个角色的职责如下所述。
| 邮件列表 | Slack | 可见范围 | 用法 | 会员资格 |
|---|---|---|---|---|
| release-managers@kubernetes.io | #release-management（频道）/@release-managers（用户组） | 公共 | 发布管理员公开讨论 | 所有发布管理员（包括助理和 SIG 主席） |
| release-managers-private@kubernetes.io | 不适用 | 私人 | 拥有特权的发布管理员私人讨论 | 发布管理员，SIG Release 负责人 |
| security-release-team@kubernetes.io | #security-release-team（频道）/@security-rel-team（用户组） | 私人 | 与安全响应委员会协调安全发布 | security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io |
发布的相关信息受到禁运，我们已经定义了有关如何设置这些禁运的政策。 更多信息请参考安全禁运政策。
注意：补丁发布团队和分支管理员手册以后将会删除重复数据。
注意： 文档可能涉及补丁发布团队和分支管理角色。这两个角色被合并到发布管理员角色中。
发布管理员和发布管理员助理的最低要求是：
git 和 git 相关命令行触发的分支源代码工作流。发布管理员负责：
x.y.z，其中 z > 0）x.y.z，其中 z = 0）该团队有时与安全响应委员会密切合作，因此应遵守安全发布流程中规定的指导方针。
GitHub 访问控制：@kubernetes/release-managers
GitHub 提及：@kubernetes/release-engineering
要成为发布管理员，须先担任发布管理员助理。助理通过在多个周期内积极处理发布，从而毕业成为发布管理员，并且：
发布管理员助理是发布管理员的学徒，以前称为发布管理员影子。他们负责：
GitHub 提及：@kubernetes/release-engineering
贡献者可以通过展示以下内容成为助理：
SIG Release 主席和技术负责人负责：
之所以此处明确提及他们，是因为他们是每个角色的各种沟通渠道和权限组（GitHub 团队、GCP 访问）的所有者。 因此，他们是享有很高特权的社区成员，并参与了一些私人沟通，这些沟通有时可能与 Kubernetes 安全披露有关。
GitHub 团队：@kubernetes/sig-release-leads
有关以往的分支管理员，可以在 release-x.y/release_team.md
中 kubernetes/sig-release 仓库的发布目录中找到。
例如：1.15 发布团队
可以通过阅读与你的 Kubernetes 版本对应的 Changelog 找到发行版本说明。 在 GitHub 上查看 1.32 的变更日志。
或者，可以在以下位置在线搜索和筛选发行版本说明：relnotes.k8s.io。 在 relnotes.k8s.io 上查看 1.32 的筛选后的版本说明。
Kubernetes 为每个组件提供二进制文件以及一组标准的客户端应用来引导集群或与集群交互。 像 API 服务器这样的组件能够在集群内的容器镜像中运行。 这些组件作为官方发布过程的一部分，也以容器镜像的形式提供。 所有二进制文件和容器镜像都可用于多种操作系统和硬件架构。
Kubernetes 命令行工具 kubectl 允许你对 Kubernetes 集群执行命令。
你可以使用 kubectl 部署应用，还可以检查和管理集群资源以及查看日志。
有关包括 kubectl 完整操作列表在内的更多信息，请参阅
kubectl 参考文档。
kubectl 可安装在各种 Linux 平台、macOS 和 Windows 上。 在下方找到你首选的操作系统。
所有 Kubernetes 容器镜像都被部署到 registry.k8s.io 容器镜像仓库。
| 容器镜像 | 支持架构 |
|---|---|
| registry.k8s.io/kube-apiserver:v1.32.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-controller-manager:v1.32.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-proxy:v1.32.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-scheduler:v1.32.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/conformance:v1.32.0 | amd64, arm, arm64, ppc64le, s390x |
所有容器镜像都支持多架构，而容器运行时应根据下层平台选择正确的镜像。
也可以通过给容器镜像名称加后缀来拉取适合特定架构的镜像，例如
registry.k8s.io/kube-apiserver-arm64:v1.32.0。
Kubernetes v1.26 [beta]对于 Kubernetes v1.32，容器镜像使用 sigstore 进行签名：
目前，不同地理位置之间的容器镜像 sigstore 签名不匹配。 有关此问题的更多信息，请参阅相应的 GitHub Issue。
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 核心组件的签名容器镜像， 请参考验证签名容器镜像。
如果你要拉取特定架构的容器镜像，则单架构镜像的签名方式与多架构清单列表相同。
你可以在 CHANGELOG 文件中找到下载 Kubernetes 组件（及其校验和）的链接。另外你还可以使用 downloadkubernetes.com 筛选版本和架构。