SIG Node 焦点
在容器编排领域，Kubernetes 至高无上，为全球一些最复杂和动态的应用程序提供动力。在幕后，由特别兴趣小组 (SIG) 组成的网络推动着 Kubernetes 的创新和稳定性。
今天，我很荣幸与 Matthias Bertschy、Gunju Kim 和 Sergey Kanzhelev 交谈，他们是 SIG Node 的成员，他们将阐述自己在 SIG Node 中的角色、面临的挑战以及令人兴奋的进展。
所有受访者共同给出的答案将用他们的姓名首字母标注。
介绍
Arpit：感谢你们今天接受采访。请简单介绍一下你们自己，并简要概述一下你们在 SIG Node 中的角色。
Matthias：我叫 Matthias Bertschy，是法国人，住在日内瓦湖附近，靠近法国阿尔卑斯山。我自 2017 年以来一直是 Kubernetes 的贡献者，也是 SIG Node 的 reviewer 和 Prow 的 maintainer。我在一家名为 ARMO 的安全初创公司担任高级 Kubernetes 开发者，该公司将 Kubescape 捐赠给了 CNCF。
Gunju：我叫 Gunju Kim。我是 NAVER 的一名软件工程师，主要负责为搜索服务开发云平台。我从 2021 年起开始在业余时间为 Kubernetes 项目做贡献。
Sergey：我叫 Sergey Kanzhelev。我在 Kubernetes 和 Google Kubernetes Engine 工作了 3 年，并且多年来一直从事开源项目。我是 SIG Node 的主席。
了解 SIG Node
Arpit：谢谢！能否为我们的读者概述一下 SIG Node 在 Kubernetes 生态系统中的职责？
M/G/S：SIG Node 是 Kubernetes 中最早的 SIG 之一。该 SIG 负责 Kubernetes 与节点资源之间的所有交互，以及节点本身的维护。这是一个相当大的范围，该 SIG 拥有 Kubernetes 代码库的很大一部分。由于这种广泛的所有权，SIG Node 始终与其他 SIG 保持联系，例如 SIG Network、SIG Storage 和 SIG Security，并且 Kubernetes 中的几乎所有新功能和开发都以某种方式涉及 SIG Node。
Arpit：SIG Node 如何为 Kubernetes 的性能和稳定性做出贡献？
M/G/S：Kubernetes 可以在各种不同大小和形状的节点上工作，从配备廉价硬件的小型物理虚拟机到大型 AI/ML 优化的 GPU 节点。节点可能在线数月，也可能是短生命周期，并且随时可能被抢占，因为它们运行在云提供商的富余计算资源上。
kubelet——节点上的 Kubernetes Agent——必须在所有这些环境中可靠地工作。至于 kubelet 操作的性能，这在今天变得越来越重要。一方面，随着 Kubernetes 在电信和零售环境中越来越多地用于超小型节点，它需要尽可能地缩小占用空间。另一方面，对于 AI/ML 工作负载，每个节点都极其昂贵，延迟操作的每一秒都会显著改变计算成本。
挑战与机遇
Arpit：SIG Node 正在关注哪些即将到来的挑战和机遇？
M/G/S：随着 Kubernetes 进入其第二个十年，我们看到了支持新工作负载类型的巨大需求。SIG Node 将在这方面发挥重要作用。我们将稍后讨论的 Sidecar KEP 是加强支持新工作负载类型的一个例子。
我们在未来几年面临的关键挑战是如何在保持现有场景的高质量和向后兼容性的同时，持续进行创新。SIG Node 将继续在 Kubernetes 中发挥核心作用。
Arpit：SIG Node 内部是否有任何正在进行的研究或开发领域让你们感到兴奋？
M/G/S：支持新的工作负载类型对我们来说是一个引人入胜的领域。我们最近对 sidecar 容器的探索证明了这一点。Sidecar 提供了一种通用的解决方案，可以在不改变核心代码库的情况下增强应用程序功能。
Arpit：在维护 SIG Node 时，你们遇到过哪些挑战？又是如何克服的？
M/G/S：SIG Node 面临的最大挑战是其规模和收到的众多功能请求。我们正在鼓励更多人加入 reviewer 队伍，并且始终乐于改进流程和处理反馈。对于每个版本，我们都会在 SIG Node 会议上进行反馈会议，并识别问题区域和行动项。
Arpit：SIG Node 是否正在密切关注或集成到 Kubernetes 中的特定技术或进展？
M/G/S：SIG 依赖的组件的开发进展，例如容器运行时（例如containerd 和 CRI-O），以及操作系统特性，都是我们贡献并密切关注的。例如，即将到来的是 cgroup v1 的弃用和移除，Kubernetes 和 SIG Node 需要引导 Kubernetes 用户完成这一过程。Containerd 也正在发布版本 2.0，该版本移除了已弃用的功能，这将影响到 Kubernetes 用户。
Arpit：能否分享一个你们作为 SIG Node maintainer 期间特别引以为豪的难忘经历或成就？
Mathias：我认为最美好的时刻是我的第一个 KEP（引入 startupProbe）最终达到 GA（正式可用）阶段。我也很喜欢看到我的贡献被贡献者们日常使用，例如包含 GitHub tree hash 的注释，用于在 squash 提交后保留 LGTM。
Sidecar 容器
Arpit：您能否详细介绍一下 sidecar 容器的概念及其在 Kubernetes 背景下的演变？
M/G/S：sidecar 容器的概念可以追溯到 2015 年，当时 Kubernetes 引入了复合容器的思想。这些额外的容器与主应用程序容器在同一个 Pod 中运行，被视为一种在不修改核心代码库的情况下扩展和增强应用程序功能的方式。早期采用 sidecar 的用户使用自定义脚本和配置来管理它们，但这种方法在一致性和可伸缩性方面带来了挑战。
Arpit：能否分享一些 sidecar 容器特别有益的具体用例或示例？
M/G/S：Sidecar 容器是一种通用工具，可以通过多种方式增强应用程序的功能：
- 日志记录和监控：Sidecar 容器可用于从主应用程序容器收集日志和指标，并将它们发送到集中式日志记录和监控系统。
- 流量过滤和路由：Sidecar 容器可用于过滤和路由进出主应用程序容器的流量。
- 加密和解密：Sidecar 容器可用于在主应用程序容器和外部服务之间流动的数据进行加密和解密。
- 数据同步：Sidecar 容器可用于在主应用程序容器和外部数据库或服务之间同步数据。
- 故障注入：Sidecar 容器可用于向主应用程序容器注入故障，以测试其对故障的弹性。
Arpit：提案中提到，有些公司正在使用添加了 sidecar 功能的 Kubernetes 分支版本。您能否介绍一下这项功能的采用程度和社区兴趣？
M/G/S：虽然我们缺乏衡量采用率的具体指标，但 KEP 已经引起了社区的广泛兴趣，特别是在 Istio 等服务网格供应商中，他们积极参与了其 Alpha 测试阶段。通过大量的博客文章、访谈、演讲和工作坊，KEP 的知名度进一步证明了其广泛吸引力。KEP 解决了 Kubernetes Pod 中对主容器旁增加额外功能日益增长的需求，例如网络代理、日志系统和安全措施。社区认识到为现有工作负载提供简便迁移路径对于促进该功能的广泛采用至关重要。
Arpit：是否有公司在生产环境中使用 sidecar 容器的显著示例或成功案例？
M/G/S: 在生产环境中期待广泛采用还为时过早。1.29 版本自 2024 年 1 月 11 日起才在 Google Kubernetes Engine (GKE) 中可用，并且仍然缺乏关于如何通过通用注入器有效启用和使用它们的全面文档。流行的服务网格平台 Istio 也缺乏启用原生 Sidecar 的适当文档，这使得开发者难以开始使用这项新功能。然而，随着原生 Sidecar 支持的成熟和文档的改进，我们可以期待这项技术在生产环境中得到更广泛的应用。
Arpit: 该提案建议为 init 容器引入一个 restartPolicy 字段来表明 Sidecar 功能。您能解释一下这个解决方案如何解决上面提到的挑战吗？
M/G/S: 为 init 容器引入 restartPolicy 字段的提案通过利用现有基础设施并简化 Sidecar 管理来解决上述挑战。这种方法避免在 Pod 规范中添加新字段，使其保持易于管理并避免更多的混乱。通过利用现有的 init 容器机制，Sidecar 可以在 Pod 启动期间与常规 init 容器一起运行，确保初始化顺序的一致性。此外，将 Sidecar init 容器的重启策略设置为 Always 明确表明它们即使在主应用程序容器终止后也会继续运行，从而支持日志记录和监控等持久服务，直到工作负载结束。
Arpit: 为 init 容器引入 restartPolicy 字段将如何影响与现有 Kubernetes 配置的向后兼容性？
M/G/S: 为 init 容器引入 restartPolicy 字段将保持与现有 Kubernetes 配置的向后兼容性。现有的 init 容器将继续像以前一样运行，新的 restartPolicy 字段将仅适用于明确标记为 Sidecar 的 init 容器。这种方法确保现有应用程序和部署不会因新功能而中断，并提供了一种更简化的方式来定义和管理 Sidecar。
贡献给 SIG Node
Arpit: 对于新成员，尤其是初学者来说，最好的贡献地方在哪里？
M/G/S: 新成员和初学者可以通过以下方式为 Sidecar KEP (Kubernetes Enhancement Proposal) 做出贡献：
- 提高认知：创建强调 Sidecar 益处和用例的内容。这可以教育其他人了解这项功能并鼓励其采用。
- 提供反馈：分享您使用 Sidecar 的经验，包括积极的和消极的。这些反馈可用于改进该功能并使其更易于广泛使用。
- 分享您的用例：如果您在生产环境中使用 Sidecar，请与他人分享您的经验。这有助于展示该功能的实际价值并鼓励其他人采用它。
- 改进文档：帮助澄清和扩展该功能的文档。这可以使其他人更容易理解和使用 Sidecar。
除了 Sidecar KEP，SIG Node 还需要更多贡献者的其他领域包括：
- 测试覆盖率：SIG Node 一直在寻找改进 Kubernetes 组件测试覆盖率的方法。
- CI 维护：SIG Node 维护一套端到端测试，确保 Kubernetes 组件在各种场景下按预期运行。
结论
总之，SIG Node 是 Kubernetes 发展历程中的基石，确保了其在不断变化的云原生计算领域中的可靠性和适应性。在 Matthias、Gunju 和 Sergey 等敬业成员的带领下，SIG Node 始终处于创新的前沿，推动 Kubernetes 迈向新的高度。