SIG Cloud Provider 聚焦

开发者使用 Kubernetes 相关服务最流行的途径之一是通过云提供商，但你是否曾想过云提供商是如何做到这一点的？Kubernetes 与各种云提供商的整个集成过程是如何发生的？为了回答这个问题，让我们将焦点放在 SIG Cloud Provider 上。

SIG Cloud Provider 致力于实现 Kubernetes 与各种云提供商之间的无缝集成。他们的使命是什么？为所有参与者维护一个公平开放的 Kubernetes 生态系统。通过设定清晰的标准和要求，他们确保每个云提供商都能与 Kubernetes 良好协作。他们的职责是配置集群组件，以启用云提供商集成。

在本期 SIG 焦点系列博客中，Arujjwal Negi 采访了 SIG Cloud Provider 的联合主席 Michael McCune (红帽)，他在社区中也被称为 elmiko，他将深入介绍该小组的工作情况。

介绍

Arujjwal: 让我们先了解一下您。您能简单介绍一下自己以及是如何接触到 Kubernetes 的吗？

Michael: 大家好，我是 Michael McCune，社区里的多数人称我为 elmiko。我从事软件开发已经很久了（在我刚开始的时候 Windows 3.1 很流行！），我职业生涯的大部分时间都与开源软件打交道。我第一次接触 Kubernetes 是作为一名机器学习和数据科学应用开发者；当时我所在的团队正在创建教程和示例，来演示 Apache Spark 等技术在 Kubernetes 上的应用。话虽如此，我对分布式系统感兴趣多年，当有机会加入一个直接从事 Kubernetes 工作的团队时，我立刻抓住了它！

运作和工作方式

Arujjwal: 您能深入介绍一下 SIG Cloud Provider 的工作内容和运作方式吗？

Michael: SIG Cloud Provider 的成立是为了帮助确保 Kubernetes 为所有基础设施提供商提供中立的集成点。我们迄今为止最大的任务是将树内云控制器提取并迁移到树外组件。SIG 定期开会讨论进展和即将到来的任务，并回答出现的问题和错误。此外，我们还充当云提供商子项目的协调点，例如 cloud provider 框架、特定云控制器实现以及 Konnectivity 代理项目。

Arujjwal: 在仔细阅读了项目 README 后，我了解到 SIG Cloud Provider 负责 Kubernetes 与云提供商的集成。整个过程是如何进行的？

Michael: 运行 Kubernetes 最常见的方式之一是将其部署到云环境（AWS、Azure、GCP 等）。通常，云基础设施具有增强 Kubernetes 性能的特性，例如为 Service 对象提供弹性负载均衡。为了确保云特定的服务能够被 Kubernetes 一致地使用，Kubernetes 社区创建了云控制器来处理这些集成点。云提供商可以使用 SIG 维护的框架或遵循 Kubernetes 代码和文档中定义的 API 指南来创建自己的控制器。我想指出的一点是，SIG Cloud Provider 不处理 Kubernetes 集群中节点的生命周期；对于这类主题，SIG Cluster Lifecycle 和 Cluster API 项目是更合适的场所。

重要子项目

Arujjwal: 这个 SIG 下有很多子项目。您能重点介绍一些最重要的子项目及其作用吗？

Michael: 我认为目前最重要的两个子项目是 cloud provider 框架和提取/迁移项目。cloud provider 框架是一个通用库，用于帮助基础设施集成商构建其基础设施的云控制器。对于新加入 SIG 的人来说，这个项目通常是起点。提取和迁移项目是另一个重要子项目，也是框架存在的重要原因之一。一点历史背景可能有助于进一步解释：很长一段时间以来，Kubernetes 需要与底层基础设施进行一些集成，不一定是添加特性，而是感知云事件，例如实例终止。云提供商集成构建在 Kubernetes 代码树中，因此产生了“树内”（in-tree）这个术语（请查阅这篇关于该主题的文章了解更多信息）。社区认为在主 Kubernetes 源码树中维护特定提供商代码的行为是不 desirable 的。社区的决定促使了提取和迁移项目的创建，以移除“树内”云控制器，转向“树外”组件。

Arujjwal: 是什么让（cloud provider 框架）成为好的起点？它有持续的适合初学者的工作吗？是哪种？

Michael: 我认为 cloud provider 框架是一个好的起点，因为它包含了社区对云控制器管理器偏好的实践方式，因此会让新人对这些管理器的工作方式和内容有深入了解。不幸的是，这个组件没有持续的适合初学者的工作流；部分原因是框架和各个提供商都比较成熟。对于那些有兴趣更深入参与的人，具备一些 Go 语言知识会很有帮助，同时了解至少一个云 API（例如 AWS、Azure、GCP）如何工作也会有益。在我个人看来，新加入 SIG Cloud Provider 可能具有挑战性，因为这个项目周围的大部分代码直接处理特定的云提供商交互。对于那些想在云提供商方面做更多工作的人，我最好的建议是熟悉一两个云 API，然后寻找针对这些云的控制器管理器的开放问题，并始终尽可能多地与其他贡献者沟通。

成就

Arujjwal: 您能分享一下让您感到自豪的 SIG 成就吗？

Michael: 自我一年多以前加入 SIG 以来，我们在推进提取和迁移子项目方面取得了巨大进展。我们已从定义 KEP 的 Alpha 状态升级到 Beta 状态，并且越来越接近从 Kubernetes 源码树中移除旧的提供商代码。我非常自豪地看到我们社区成员的积极参与，并看到我们在提取方面取得的进展。我有一种感觉，在接下来的几个版本中，我们将看到树内云控制器的最终移除和子项目的完成。

给新贡献者的建议

Arujjwal: 对于新贡献者，您有什么建议或忠告，告诉他们如何在 SIG Cloud Provider 入门吗？

Michael: 在我看来，这是一个棘手的问题。SIG Cloud Provider 专注于集成 Kubernetes 和底层基础设施的代码部分。SIG 的成员代表云提供商是常见的，但并非必须的。我建议任何对 Kubernetes 这部分感兴趣的人都应该来参加 SIG 会议，看看我们是如何运作的，同时研究 cloud provider 框架项目。我们对未来的工作有一些有趣的想法，例如一个通用测试框架，它将适用于所有云提供商，对于任何希望扩大其 Kubernetes 参与度的人来说，这将是一个很好的机会。

Arujjwal: 您是否在寻找应该强调的特定技能？举个我们 [SIG ContribEx] 自己的例子：如果您是 Hugo 专家，我们总是可以在 k8s.dev 方面提供帮助！

Michael: SIG 目前正在推进提取和迁移流程的最后阶段，但我们正在展望未来，开始规划接下来的工作。SIG 讨论的一个重要话题是测试。目前，我们没有一套通用的通用测试，可以由每个云提供商执行以确认其控制器管理器的行为。如果您是 Ginkgo 和 Kubetest 框架的专家，我们可能需要您帮助设计和实现新的测试。

对话到此结束。希望这能让您对 SIG Cloud Provider 的目标和工作有所了解。这只是冰山一角。要了解更多并参与到 SIG Cloud Provider 中，可以尝试参加他们的会议：这里。

• ←上一个
• 下一个→