认证标志到底保证了什么

一句话总结

认证标志承诺的是“GA 且必需的 API 与 upstream 行为一致”，而不是“可以放心用于生产环境”；EKS Distro 这类发行版则在这一承诺之上，再叠加构建、补丁和支持周期等其他价值。

为什么需要它

Kubernetes 是开源的，任何人都可以修改后再发布。发行版增加到几十个之后，用户开始担心一件事：“在 A 上能运行的清单，在 B 上也能一模一样地运行吗？”如果厂商稍微改动 API，或者去掉某些默认行为，当初选择 Kubernetes 的理由——可移植性——就消失了。

因此 CNCF 运营着 Certified Kubernetes Conformance Program。厂商在自己的产品上运行规定的测试集，把结果以 PR 的形式提交到公开仓库，通过评审后即可获得认证。关键在于测试是公开的，结果也是公开的。任何人都可以在自己的集群上重新运行同样的测试。FAQ 说明，即使是仅限公司内部使用的集群，不经认证直接运行测试并通过，也算符合要求；认证只是为了使用标志而走的流程。

工作原理

什么是测试。 按照 instructions.md 的说明，标准测试是 Kubernetes e2e 测试集中带有 [Conformance] 标签的那些。测试列表按版本固定在 Kubernetes 仓库的 test/conformance/testdata/conformance.yaml 中。统计 v1.36.4 标签下的列表共有 446 项，按数量依次为 sig-node 106、sig-api-machinery 99、sig-storage 91、sig-apps 60、sig-network 47（实测）。每一项都包含 testname、codename、说明、首次纳入的 release 和源文件。

什么可以成为测试。 标准由 SIG Architecture 的 Conformance Testing in Kubernetes 规定。只有 GA 且非可选的功能才可以，必须能在所有提供商上运行，不能直接依赖 kubelet API，也不能要求节点 root 权限或公共互联网。反过来，GPU 这类依赖节点的功能、策略强制这类可选功能、云提供商专有功能，都明确不在范围内。检查 Event 内容、Condition 的 reason 和 message 这类可能随版本变化的输出的测试，同样不会纳入。

如何运行。 用于提交的结果由 Sonobuoy 或 Hydrophone 生成。使用 Sonobuoy 时需要 --mode=certified-conformance；如果自己指定 focus，则必须设置 E2E_FOCUS=\[Conformance\] 并将 E2E_SKIP 留空。认证运行不允许跳过任何一个测试。PR 中要包含 README.md、e2e.log、junit_01.xml、PRODUCT.yaml 四个文件，机器人会先检查所需的测试是否齐全、是否没有失败。可以申请认证的版本是当前发布版本及其之前的两个版本；已经通过认证的产品，每年也必须用新版本重新认证一次才能继续保持。

为什么必须对齐版本。 测试列表会随版本增加。文档要求，某个版本的一致性测试要使用由该版本发布分支构建的测试来运行。本实验的 VM 在服务器 v1.36.4+k3s1 上使用来自 dl.k8s.io 的 v1.36.4 测试二进制文件。用 dry-run 统计时，[Conformance] focus 在 7579 个 spec 中选出 446 个，与列表中的数量完全一致（实测）。

在现场相遇的样子

带标志的 k3s 只用一台也会失败。 仓库中 v1.36/k3s 的提交 README 写明，测试使用了一台控制平面加一台工作节点，结果为 446 项通过、7133 项跳过，耗时约 2 小时 54 分钟。然而，在本实验的单节点 k3s 上运行 [sig-architecture] Conformance Tests should have at least two untainted nodes，1.3 秒后就会因 Conformance requires at least two nodes 而失败（实测）。认证针对的是产品，并不代表你搭建的配置符合要求。

同一个测试能发现损坏的集群。 [sig-network] DNS should provide DNS for the cluster 在正常集群上 3.8 秒就通过了。把 CoreDNS 缩减到 0 个再运行，测试 Pod 会每 5 秒记录一次 kubernetes.default.svc.cluster.local 的查询失败，并等待 600 秒。将测试套件的超时设为 60 秒后，结果记录为 timedout（实测）。一致性测试既可用于认证，也可以在升级或更换 CNI 之后，作为确认“基本行为是否正常”的回归测试。

EKS Distro 增加了什么。 EKS Distro 文档说明，EKS-D 是与 Amazon EKS 所用的相同的 Kubernetes 及其依赖项的发行版。它打包了 Kubernetes、etcd、CoreDNS、CNI 插件和 aws-iam-authenticator，容器镜像基于 Amazon Linux 2 发布在 ECR Public 上。FAQ 表示，它不是 fork，而是对未经修改的 upstream 做了带有倾向性的打包，并且对已结束社区支持的版本，最长还会提供 14 个月的安全补丁。版本标记形如 v1-36-eks-7，即次版本通道之后跟发布编号；镜像标签形如 kube-apiserver:v1.36.2-eks-1-36-7，即 upstream 版本之后跟通道和编号。当组件版本变化，或基础镜像、构建工具（例如 Go）变化时，也会发布新的 release。2026-08-18 的 v1-36-eks-7 中 kube-apiserver 是 v1.36.2，而同一时间 upstream 的 stable-1.36 是 v1.36.4（实测）。发行版的版本不一定与 upstream 最新版相同。EKS-D 也以 type distribution 的形式提交到了 k8s-conformance 仓库的 v1.36 目录中。

实际工作中真正重要的事

标志是可移植性的底线，而不是质量的上限。 认证只说明 GA API 的行为一致。高可用配置、性能、安全默认值、是否真正拦截 NetworkPolicy 这类可选功能、升级流程、支持周期，都必须另行确认。

认证结果不等于你的集群的结果。 如果提交 README 中写明的配置（节点数、操作系统、安装参数）与你的配置不同，即使是同一个产品，也可能有测试失败。在重要变更之后，挑选相关领域的一致性测试亲自运行一遍，比相信标志更可靠。

要固定版本。 服务器与测试二进制文件的版本不一致时，列表不同，结果也就无法比较。对于像 EKS-D 这样 upstream 补丁版本与发行版发布编号各自独立变化的产品，必须同时记录两个编号，以后才能复现。

EKS-D 本身没有安装在本实验的 VM 上。安装路径（kOps、kubeadm 等）和支持路径（EKS Anywhere）只通过文档进行了确认。

下一项实验要做什么

在固定了版本的 k3s 上对齐测试二进制文件的版本，读取 conformance.yaml，找出 DNS 领域的测试。用 dry-run 统计范围之后，让一个 DNS 测试通过，并通过 JUnit 确认单节点配置会在双节点测试中失败。把 CoreDNS 缩减后，观察同一个 DNS 测试因超时而失败，再恢复并重新通过，最后用认证规则的语言整理结果。