Kubernetes 多架构支持平台Platforms完整指南从新增构建、测试、发布到弃用移除【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文档是 Kubernetes 社区为“新增 / 移除受支持构建平台supported platform”制定的官方操作指南适用于 SIG Architecture 与 SIG Release 视角下的平台生命周期管理。读完本文你将掌握如何在社区层面发起平台支持提案lazy consensus、如何为arm/arm64/ppc64le/s390x等架构补齐构建与测试能力、如何将 CI 作业从 release-informing 升级为 release-blocking 并完成一致性conformance验证以及如何合规地弃用并移除一个已支持平台。全文以 contributors/guide/platforms.md 为主体骨架并结合本仓库中 SIG Testing、SIG Architecture 的源码级文档进行纵深佐证。一、背景为什么需要“多平台支持”Kubernetes 的默认平台是linux/amd64。这个平台从一开始就经过了完整测试构建与发布系统最初也仅支持这一平台。随着异构基础设施ARM 服务器、PowerPC、IBM Z 大型机、Windows 节点等的普及SIG Release 发起了多架构支持专项工作在构建与发布流水线中为以下架构补齐了支持armarm64ppc64les390x它们分布在 Linux、Windows、macOS 等不同操作系统之上。该专项的核心目标是让这些架构 / 操作系统组合的二进制binaries与容器镜像container images可以交付并且让社区贡献者能够基于这些产物搭建 CI 作业对新平台进行充分测试——其中特别强调在这些平台上运行一致性测试conformance tests的能力。本指南的定位是为“向 Kubernetes 新增平台”提供一个起点视角限于 SIG Architecture 与 SIG Release它不涵盖发布机制细节也不涉及平台在功能层面的可支持性supportability评估。二、Step 0与社区建立沟通新增平台或把已有平台提升到更高 Tier支持等级第一步永远是与社区达成共识在 SIG Release 仓库中提交一个 GitHub issue 表达意向参加每周的 SIG Release 例会向 SIG Release 邮件列表发送消息。需要注意无论提案是否满足下文全部硬性要求最终批准与否都会由社区按标准 lazy consensus惰性共识机制决定。外部依赖、基础设施成本、长期维护负担等因素都可能影响一个平台能否被接受。换言之“满足清单”只是必要条件不是充分条件。这一机制与社区治理文档中的共识原则一脉相承本仓库 governance.md 与 sig-wg-lifecycle.md 均体现了“社区驱动的决策 SIG 分层负责”的治理结构平台的增减正是这种治理在基础设施层面的具体落地。三、Step 1构建Building——让产物能“造出来”一个平台要进入 Kubernetes 支持矩阵前提是基于容器镜像的构建基础设施必须支持该架构。这隐含两个硬性要求golang 必须支持该平台Kubernetes 主体由 Go 编写交叉编译依赖 Go 的GOOS/GOARCH能力因此目标平台必须出现在 Go 官方支持矩阵中所有依赖都必须支持该平台无论是 vendored 依赖还是独立运行的工具链都要能在该平台上编译与运行——否则会在引入新依赖、升级依赖版本时随时出现 bit-rot位腐烂即无人验证导致的隐性失效。一句话总结这一阶段的目标社区中的任何人都应该能使用 SIG Release 提供的构建工具生成构建 Kubernetes 所需的全部产物。关于如何在本地构建 Kubernetes可以参考本仓库中的 构建与开发指南 以及 在本地运行。构建产物通常包括各平台、各架构的控制平面与节点组件二进制如kube-apiserver、kube-controller-manager、kubelet、kubectl对应的容器镜像多架构镜像通过 manifest list 聚合可执行性验证产物。实战要点仅“能编译通过”是不够的。平台支持本质上是一份长期承诺——依赖升级、vendor 变更、Go 版本更新都会破坏某个未被持续验证的架构。因此构建支持必须与“持续的自动化验证”绑定这正是下一步的主题。四、Step 2测试Testing——让平台“不烂掉”只保证构建成功远远不够当项目不断引入新变更、升级依赖版本时缺乏测试覆盖的架构会迅速 bit-rot。因此项目需要一个覆盖面广的测试作业矩阵battery of jobs在新架构上持续运行。从测试视角出发推荐的起点是测试类型定位说明单元测试unit tests基础层快、隔离、不依赖外部环境用于发现单个组件的逻辑错误端到端测试e2e tests系统层验证整个系统的端到端行为是最终的用户体验信号节点 e2e 测试node e2e testskubelet 层针对 kubelet 行为详见 e2e-node-tests.md 对应的test/e2e_node框架本仓库的 测试策略文档 用“测试金字塔”形象地概括了这一分层单元测试是底座集成测试验证子系统内组件交互e2e 测试最昂贵也最容易 flake但提供最终的系统级信号。对于新平台三者缺一不可。4.1 持续验证的“人”与“工具”仅有机器的验证还不够这隐含一个人员承诺需要有一组人站出来同时维护post-submit合入后作业与periodic周期作业密切观察结果一旦平台相关测试变红就及时拉响警报并帮助调试、修复平台特有的问题。在工具层面强烈建议为平台专属测试创建自定义TestGrid 仪表盘。本仓库的 CI 健康监控指南 说明TestGrid 是一个高度可配置的交互式测试结果网格仪表盘Kubernetes 社区拥有自己的实例每个 SIG 拥有自己的仪表盘集合由 build、unit test、integration test、e2e test 等各类作业组成e2e 作业内部又按“组件 → 子类目 → 用例”分层组织TestGrid 中则合并为扁平的测试行名社区强烈鼓励各 SIG 周期性巡检自己拥有的仪表盘发现失败作业后到对应 SIG 的邮件列表或 Slack 上报。实战要点一个新平台的生命力完全取决于“红信号有人管”。测试只是第一步维护者需要持续 triage flaky tests、修复平台特有问题否则该平台很快会回到不可用状态。五、Step 3发布Releasing——让产物可以被信任前两步能构建、有人持续测试建立了“有人负责、可复现环境可用”的合理预期。而进入发布级别是一次更大的跨越——它要求真实用户可以放心依赖所发布的产物。具体而言需要在 TestGrid 的release-informing与release-blocking两个标签页中加入一组 CI 作业先将 CI 作业加入release-informing发布参考当这些作业长期表现良好、持续稳定变绿后再提升为release-blocking发布阻塞。Kubernetes 发布团队设有“CI signal”小组他们完全依赖这些作业的状态来决定“发布”还是“搁置”一个版本。本质上如果某平台作业大部分时间红色、偶尔绿色那么就不应该费心把它纳入发布。加入 release-informing 的作业先在发布流程中“旁路观察”表现优异后才具备阻塞发布的能力。5.1 为什么“发布”是最难的一步核心矛盾在于一旦项目开始发布某平台的产物用户就会开始依赖它。一次性搭一个 CI 作业很容易但长期稳定地维护它完全是另一回事。SIG Release 期待的是足够强、足够绿的 CI 信号让 release manager 敢于切发布用户上报问题后能够被及时处理并修复通过一致性测试conformance testing确保该受支持平台的行为符合预期。关于 CI 作业类型与信号机制本仓库 测试策略文档 给出了更底层的分类可作为本步骤的纵深参考Presubmit合入前在代码合并前运行blocking 类作业失败会阻止合并Postsubmit合入后代码合并后运行常用于构建产物Periodic周期按计划间隔运行适合监控趋势与捕捉回归。文档还强调了一个关键约束Presubmit Blocking 作业必须同时是 Release Blocking 作业且前者应更快通常要求 1 小时内、最好 30 分钟内跑完因为它在每个 PR 上都会运行一旦出问题会干扰所有贡献者。因此社区不会轻易增设 presubmit blocking 作业——这与“平台作业先在 informing 观察、稳定后晋升 blocking”的渐进策略互为印证。5.2 一致性测试Conformance发布层面的一致性验证需要与 SIG Architecture 的 Conformance 子项目 协作推进。本仓库 一致性测试指南 定义Kubernetes Conformance 测试套件是 e2e 测试的子集由 SIG Architecture 批准用于定义所有符合规范的 Kubernetes 集群必须支持的核心可互操作特性集合。一致性测试的晋升门槛极其严格例如只测试 GA、非可选特性 / API不允许 alpha / beta 端点、feature flag、已弃用特性不要求直接访问 kubelet API也不允许通过 API server 的 node proxy 端点间接访问对所有 provider 通用不允许SkipIfProviderIs/SkipUnlessProviderIs仅使用经 API 暴露的能力不要求节点 root 权限、不要求写kube-system等系统命名空间不依赖公网预拉取测试镜像除外测试中使用的容器镜像必须支持 Kubernetes 发布所构建的全部架构——这一点对多平台支持至关重要测试必须稳定、无 flake并已稳定运行至少两周。特别注意“镜像支持全部架构”这一条一致性测试天然要求测试基础设施与产物同样具备多架构能力否则新平台无法通过一致性验证。六、Step 4完成Finishing——达成一致性并获取商标使用权走到这一步说明你已经与社区建立了清晰、持续的沟通与所有相关 SIG 顺畅协作内容进入了 Kubernetes 发布流程有终端用户开始采用你的架构。关键里程碑一旦平台达成 conformance一致性你将获得有条件使用 Kubernetes 商标的权利可将其用于与你自身产品 / 服务相关的描述。这是平台从“被支持”走向“被认证”的标志性成果。七、弃用与移除受支持平台Deprecating and Removing已支持平台可能因各种原因被考虑弃用例如被新平台取代不再被积极使用不再有人维护。弃用一个已支持平台必须遵循以下步骤7.1 弃用流程三步走公告与讨论在 Kubernetes Announce 邮件列表上发布弃用公告并附上对应的 Kubernetes GitHub issue用于后续讨论与共识达成共识与批准在设定的截止日期前达成共识后弃用立即生效。该决定必须包含 SIG Release 与 SIG Architecture 的批准正式移除平台移除将在下一个 minor 版本v1.N1.0发布周期开始时执行具体包括更新 Kubernetes 构建脚本将该平台从所有构建目标中排除更新 SIG Release 仓库kubernetes/sig-release使其反映当前受支持平台的集合。7.2 兼容性保障已处于活跃支持状态的历史发布分支release branches不受移除影响。这保证了既有产物消费者在尽力而为best effort的基础上仍能兼容使用旧分支上构建的产物——即移除只影响未来的新版本不破坏已经发布的版本。八、全流程对照速查表阶段核心动作成功标准关键角色Step 0 社区参与issue / 例会 / 邮件列表表达意向lazy consensus 认可SIG Release、社区Step 1 构建golang 与依赖支持目标平台任何人可用官方工具构建全部产物SIG ReleaseStep 2 测试unit / e2e / node e2e TestGrid 仪表盘持续绿信号bit-rot 可控平台维护者Step 3 发布informing → blocking 晋升 conformance发布可依赖、CI signal 绿色SIG Release、SIG ArchitectureStep 4 完成conformance 达成有条件使用 Kubernetes 商标SIG Architecture弃用与移除公告 → 共识批准 → 下个 minor 移除构建脚本与 sig-release 仓库同步更新SIG Release、SIG Architecture九、延伸阅读Platforms Guide 原文Kubernetes 测试策略含 CI 作业类型与 release blocking/informing 说明端到端测试指南kubetest 使用与测试分层TestGrid 与 CI 健康监控指南Conformance 测试指南晋升门槛与版本偏差策略SIG Architecture 的 Conformance Definition 子项目Kubernetes 构建与本地开发节点 e2e 测试test/e2e_node【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考