聚焦 SIG Cloud Provider

开发人员使用 Kubernetes 相关服务最流行的方式之一是通过云提供商，但你是否想过云提供商是如何做到的？Kubernetes 与各种云提供商集成的整个过程是如何发生的？为了回答这个问题，让我们聚焦于 SIG Cloud Provider。

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

在 SIG Spotlight 系列的这篇博客中，Arujjwal Negi 采访了 Michael McCune (Red Hat)，也被称为 elmiko，他是 SIG Cloud Provider 的联合主席，为我们深入介绍了这个小组的工作情况。

引言

Arujjwal：让我们从认识你开始吧。你能简单介绍一下自己以及你是如何接触到 Kubernetes 的吗？

Michael：大家好，我是 Michael McCune，社区里大多数人都用我的昵称 elmiko 称呼我。我从事软件开发已经很长时间了（我刚开始工作时 Windows 3.1 还很流行！），而且我职业生涯的大部分时间都与开源软件打交道。我最初接触 Kubernetes 是作为一名机器学习和数据科学应用的开发者；当时我所在的团队正在创建教程和示例，以演示如何在 Kubernetes 上使用像 Apache Spark 这样的技术。也就是说，我对分布式系统感兴趣很多年了，当有机会加入一个直接从事 Kubernetes 工作的团队时，我毫不犹豫地抓住了它！

运作和工作

Arujjwal：你能给我们介绍一下 SIG Cloud Provider 做什么以及它是如何运作的吗？

Michael：SIG Cloud Provider 的成立是为了帮助确保 Kubernetes 为所有基础设施提供商提供一个中立的集成点。我们迄今为止最大的任务是将树内（in-tree）云控制器提取和迁移到树外（out-of-tree）组件。该 SIG 定期开会讨论进展和即将到来的任务，并回答出现的问题和错误。此外，我们还充当云提供商子项目的协调点，例如云提供商框架、特定的云控制器实现以及 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：我认为今天最重要的两个子项目是云提供商框架和提取/迁移项目。云提供商框架是一个通用库，帮助基础设施集成商为他们的基础设施构建云控制器。这个项目通常是新加入 SIG 的人的起点。提取和迁移项目是另一个大的子项目，也是框架存在的一个重要原因。一些历史背景可能有助于进一步解释：在很长一段时间里，Kubernetes 需要与底层基础设施进行一些集成，不一定是为了增加功能，而是为了感知云事件，比如实例终止。云提供商集成被内置到 Kubernetes 代码树中，因此产生了“树内（in-tree）”这个术语（可以查看这篇关于该主题的文章了解更多信息）。在主 Kubernetes 源代码树中维护特定于提供商的代码的活动被社区认为是不受欢迎的。社区的决定促使了提取和迁移项目的创建，以移除“树内”云控制器，转而支持“树外（out-of-tree）”组件。

Arujjwal：是什么让[云提供商框架]成为一个好的起点？它有持续适合初学者的工作吗？是哪种类型的工作？

Michael：我认为云提供商框架是一个很好的起点，因为它编码了社区对云控制器管理器的首选实践，因此，它能让新手对管理器如何工作以及做什么有一个深刻的理解。不幸的是，这个组件并没有持续不断的适合初学者的工作；部分原因是框架以及各个提供商的成熟性。对于有兴趣更深入参与的人来说，具备一些 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 会议，看看我们是如何运作的，并研究云提供商框架项目。我们对未来的工作有一些有趣的想法，比如一个通用的测试框架，它将跨越所有云提供商，对于任何希望扩大其 Kubernetes 参与度的人来说，这将是一个很好的机会。

Arujjwal：你们是否在寻找一些我们应该强调的特定技能？举个我们自己 [SIG ContribEx] (https://github.com/kubernetes/community/blob/master/sig-contributor-experience/README.md) 的例子：如果你是 Hugo 专家，我们在 k8s.dev 方面总是需要帮助！

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

对话到此结束。我希望这能让你对 SIG Cloud Provider 的目标和工作方式有所了解。这只是冰山一角。要了解更多并参与 SIG Cloud Provider，请尝试参加他们的会议，链接在这里。

• ←上一篇
• 下一篇→