聚焦 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 的审查员和 Prow 的维护者。我为一家名为 ARMO 的安全初创公司担任高级 Kubernetes 开发人员，该公司向 CNCF 捐赠了 Kubescape。

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 代理 —— 必须在所有这些环境中可靠地工作。至于 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 最大的挑战是它的规模和收到的众多功能请求。我们鼓励更多的人加入成为审查员，并始终乐于改进流程和处理反馈。对于每个版本，我们都会在 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 维护者期间，你是否能分享一次让你特别自豪的难忘经历或成就？

Mathias: 我认为最美好的时刻是我的第一个 KEP（引入 startupProbe）最终升级为 GA（正式发布）。我也很高兴看到我的贡献被贡献者们日常使用，比如包含 GitHub 树哈希的注释，用于在 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 维护一套 e2e 测试，确保 Kubernetes 组件在各种场景下都能按预期运行。

结论

总而言之，SIG Node 是 Kubernetes 发展过程中的基石，确保了其在不断变化的云原生计算领域的可靠性和适应性。在 Matthias、Gunju 和 Sergey 等敬业成员的带领下，SIG Node 始终处于创新的前沿，推动 Kubernetes 迈向新的地平线。

• ←上一篇
• 下一篇→