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