这篇文章已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。
SIG Architecture 焦点：一致性
这是 SIG Architecture Spotlight 系列的第一篇访谈，该系列将涵盖不同的子项目。我们从 SIG Architecture：Conformance 子项目开始。
在本期 SIG Architecture Spotlight 中，我们与 Riaan Kleinhans (ii.nz) 进行了访谈，他是 Conformance 子项目的负责人。
关于 SIG Architecture 和 Conformance 子项目
Frederico (FSM)：Riaan 你好，欢迎！首先，请简单介绍一下你自己、你的角色以及你是如何参与到 Kubernetes 中的。
Riaan Kleinhans (RK)：你好！我的名字是 Riaan Kleinhans，我住在南非。我是新西兰 ii.nz 团队的项目经理。当我加入 ii 时，计划是在 2020 年 4 月搬到新西兰，然后新冠疫情发生了。幸运的是，作为一个灵活而充满活力的团队，我们得以远程工作，并且在非常不同的时区协调。
ii 团队的任务是管理 Kubernetes Conformance 测试的技术债务，并编写测试来清理这些技术债务。我担任项目经理的角色，负责协调监控、测试编写和社区之间的工作。通过这项工作，我有幸在头几个月认识了 Dan Kohn，他对我们正在做的工作的热情给了我很大的启发。
FSM：谢谢 - 那么，你参与 SIG Architecture 是因为 Conformance 的工作吗？
RK：SIG Architecture 是 Kubernetes Conformance 子项目的“家”。最初，我的大部分互动都是通过 Conformance 子项目直接与 SIG Architecture 进行的。然而，当我们开始按 SIG 组织工作时，我们开始直接与各个 SIG 互动。与拥有未测试 API 的 SIGs 的互动帮助我们加快了工作进度。
FSM：你如何描述 Conformance 子项目的主要目标和工作领域？
RM：Kubernetes Conformance 子项目通过开发和维护全面的 conformance 测试套件，致力于确保 Kubernetes 规范的兼容性和遵从性。其主要目标包括确保不同 Kubernetes 实现之间的兼容性、验证对 API 规范的遵从性、通过鼓励 conformance 认证来支持生态系统，以及促进 Kubernetes 社区内的协作。通过提供标准化测试并促进一致的行为和功能，Conformance 子项目为开发者和用户确保了一个可靠且兼容的 Kubernetes 生态系统。
关于 Conformance Test Suite 的更多信息
FSM：我认为，提供这些标准化测试的一部分是 Conformance Test Suite。你能解释一下它是什么以及它的重要性吗？
RK：Kubernetes Conformance Test Suite 检查 Kubernetes 发行版是否符合项目规范，确保不同实现之间的兼容性。它涵盖了诸如 API、网络、存储、调度和安全等各种特性。通过测试确认了正确的实现，并促进了容器编排平台的一致性和可移植性。
FSM：是的，测试在定义任何 Kubernetes 集群必须支持的最小特性方面非常重要。你能描述一下确定哪些特性被考虑纳入 conformance 的过程吗？在更 minimal 的方法与其他 SIG 的提议之间是否存在任何冲突？
RK：SIG Architecture 明确定义了每个接受 conformance 测试的 endpoint 的要求。只有正式可用 (GA) 且非 optional 的 API endpoint 才符合 conformance 条件。多年来，关于 conformance profiles 进行了一些讨论，探讨了在特定 profiles 中包含像 RBAC 这样被大多数终端用户广泛使用的 optional endpoints 的可能性。然而，这方面仍在进展中。
不符合 conformance 标准的 endpoint 列在 ineligible_endpoints.yaml 文件中，该文件可在 Kubernetes 仓库中公开访问。随着 endpoint 状态或要求的改变，可以更新此文件来添加或移除 endpoint。这些不符合条件的 endpoint 也可以在 APISnoop 上查看。
对 SIG Architecture 而言，确保 endpoint 资格或不资格的透明度并纳入社区输入至关重要。
FSM：为新特性编写测试通常需要某种程度的强制性。你如何看待 Kubernetes 在这方面的演进？是否曾有专门的努力来改进流程，使得所需的测试成为一级公民，或者这从未成为问题？
RK：当关于 Kubernetes conformance 计划的讨论在 2018 年开始时，大约只有 11% 的 endpoint 有测试覆盖。当时，CNCF 的理事会要求，如果要为覆盖缺失的 conformance 测试提供资金，Kubernetes 社区应该采纳一项政策，不允许添加新特性，除非它们为其稳定的 API 包含 conformance 测试。
SIG Architecture 负责管理这一要求，而 APISnoop 在这方面已被证明是一个无价的工具。通过自动化，APISnoop 每周生成一个 pull request，以突出 Conformance 覆盖率中的任何差异。如果任何 endpoint 在没有 conformance 测试的情况下晋升到正式可用 (GA)，它将立即被识别出来。这种方法有助于防止新技术的积累。
此外，近期计划创建一个 release informing job，这将增加一层额外的防护，以防止任何新的技术债务。
FSM：我明白了，工具和自动化在这方面发挥着重要作用。在你看来，在 conformance 方面，哪些领域仍然需要做一些工作？换句话说，目前优先改进的领域是什么？
RK：我们在 1.27 版本中已经达到了“100% Conformance Tested”的里程碑！
那时，社区重新审视了所有被列为不符合 conformance 条件的 endpoint。该列表是多年来通过社区输入填充的。一些之前被认为不符合 conformance 条件的 endpoint 已经被识别出来，并转移到一个新的专用列表中，目前正在重点关注这些 endpoint 的 conformance 测试开发。同样，该列表也可以在 apisnoop.cncf.io 上查看。
为了确保 conformance 项目中避免新的技术债务，近期计划建立一个 release informing job 作为额外的预防措施。
虽然 APISnoop 目前托管在 CNCF 基础设施上，但该项目已被慷慨捐赠给 Kubernetes 社区。因此，它将在 2023 年底前转移到社区拥有的基础设施。
FSM：这是个好消息！对于任何想提供帮助的人，你会重点推荐哪些协作途径？所有这些都要求对 Kubernetes 整体有扎实的了解吗，还是有方法让项目新手也能贡献？
RK：为 conformance 测试做贡献类似于“洗碗”的任务——它可能不太显眼，但却极其重要。它需要对 Kubernetes 有深入的了解，特别是在需要测试 endpoint 的领域。这就是为什么与拥有待测试 API endpoint 的每个 SIG 合作如此重要的原因。
作为我们致力于让每个人都能轻松编写测试的一部分，ii 团队目前正在开发一个“点击即部署”解决方案。该解决方案旨在让任何人都能在几分钟内快速在真实硬件上创建一个工作环境。一旦准备好，我们将分享有关此开发的最新进展。
FSM：非常有帮助，谢谢。你还有什么想对读者分享的吗？
RK：Conformance 测试是一项协作性的社区工作，需要 SIGs 之间广泛的合作。SIG Architecture 发起了这项倡议并提供了指导。然而，工作的进展在很大程度上依赖于所有 SIGs 在审查、改进和认可测试方面的支持。
我要衷心感谢 ii 团队多年来为解决技术债务所做的坚定不移的努力。特别是，Hippie Hacker 的指导和对愿景的领导是无价的。此外，我要特别表彰 Stephen Heywood 在最近的版本中承担了大部分的测试编写工作，以及 Zach Mandeville 对 APISnoop 的贡献。
FSM：非常感谢你的时间和富有洞察力的评论，我个人从中受益匪浅，我相信我们的读者也会一样。