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