聚焦 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 开发人员，该公司将 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 Network、SIG Storage 和 SIG Security 等其他 SIG 保持联系，并且 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（全面上市）时。我还很喜欢看到我的贡献每天都被贡献者使用，例如包含用于在压缩提交后保留 LGTM 的 GitHub 树哈希值的注释。
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 增强提案）做出贡献
- 提高意识： 创建内容，突出边车（sidecar）的优势和用例。这可以帮助其他人了解此功能并鼓励其采用。
- 提供反馈： 分享您使用边车的经验，包括积极和消极的方面。这些反馈可以用来改进该功能，使其更广泛地适用。
- 分享您的用例： 如果您在生产环境中使用边车，请与他人分享您的经验。这有助于展示该功能的实际价值，并鼓励其他人采用它。
- 改进文档： 帮助澄清和扩展该功能的文档。这可以使其他人更容易理解和使用边车。
除了 Sidecar KEP 之外，SIG Node 在许多其他领域也需要更多贡献者
- 测试覆盖率： SIG Node 一直在寻找改进 Kubernetes 组件测试覆盖率的方法。
- CI 维护： SIG Node 维护一套 e2e 测试，以确保 Kubernetes 组件在各种场景下都能按预期运行。
结论
总之，SIG Node 是 Kubernetes 旅程中的基石，确保其在不断变化的云原生计算领域中的可靠性和适应性。在 Matthias、Gunju 和 Sergey 等敬业成员的带领下，SIG Node 始终处于创新的前沿，推动 Kubernetes 向新的高度发展。