聚焦 SIG 云提供商
开发者使用 Kubernetes 相关服务最流行的方式之一是通过云提供商，但您是否曾想过云提供商是如何做到这一点的？Kubernetes 与各种云提供商的集成过程是如何发生的？为了回答这个问题，让我们把焦点放在 SIG Cloud Provider 上。
SIG Cloud Provider 致力于在 Kubernetes 和各种云提供商之间创建无缝集成。他们的使命？保持 Kubernetes 生态系统对所有人公平开放。通过设定明确的标准和要求，他们确保每个云提供商都能与 Kubernetes 良好配合。他们的责任是配置集群组件以启用云提供商集成。
在本期 SIG Spotlight 系列博客中，Arujjwal Negi 采访了 SIG Cloud Provider 的联合主席 Michael McCune（Red Hat），又名 *elmiko*，以深入了解该小组的工作方式。
简介
Arujjwal：让我们先来了解一下您。您能简单介绍一下自己以及您是如何接触到 Kubernetes 的吗？
Michael：大家好，我是 Michael McCune，社区里大多数人称呼我的网名 *elmiko*。我从事软件开发已经很长时间了（我刚开始工作时 Windows 3.1 很流行！），我职业生涯的大部分时间都参与了开源软件。我最初接触 Kubernetes 是作为机器学习和数据科学应用程序的开发人员；我当时所在的团队正在创建教程和示例，以演示如何在 Kubernetes 上使用 Apache Spark 等技术。也就是说，我对分布式系统很感兴趣很多年了，当有机会加入一个直接从事 Kubernetes 工作的团队时，我毫不犹豫地加入了！
运作和工作
Arujjwal：您能否深入了解一下 SIG Cloud Provider 的工作以及它的运作方式？
Michael：成立 SIG Cloud Provider 的目的是为了确保 Kubernetes 为所有基础设施提供商提供一个中立的集成点。我们迄今为止最大的任务是将树内云控制器提取和迁移到树外组件。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 代码树中，因此创建了术语“树内”（有关更多信息，请查看这篇关于该主题的 文章）。在主 Kubernetes 源代码树中维护特定于提供商的代码的活动被社区认为是不受欢迎的。社区的决定激发了提取和迁移项目的创建，以删除“树内”云控制器，转而使用“树外”组件。
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，请尝试参加他们的会议 这里。