携手发展，共同前行——SIG Cloud Provider

今天为大家介绍一下SIG Cloud Provider，即云供应商特别兴趣小组。其两位代表分别是来自 Google 的 Jago Macleod 和来自 Digital Ocean 的 Andrew Sy Kim。他们将在KubeCon + CloudNativeCon 2018 中国论坛上与大家见面。

Andrew Sy Kim

SIG Cloud Provider 的长期目标是为社区建立一个中立于供应商的生态系统。

SIG 作为开发 Kubernetes 项目的核心小组，会确保为 Kubernetes 提供支持的新供应商与现有的云供应商享有同样的权利，所有供应商们都将享有一致且高质量的用户体验。

在本次会议上他们将带大家重温一下历史背景和相关情况，之后会告知大家目前努力的方向。在讨论过相关文档和代码组织之后，与会者将获得反馈和提问的机会。另外，内容还将涵盖为了云供应商向 testgrid 提交测试结果而提供的技术支持。（注：testgrid 是一个用于记录和让测试结果可视化的共享基础架构。）最后，还会介绍一下 in-tree 云供应商向外部存储库过渡的路线图。

当 Kubernetes 从构建所有必需的二进制文件转变到构建和运行 Kubernetes 集群时，云供应商必须提供一些额外的组件（例如，云控制器管理器等等）以便在新环境下有效运行。

云控制器管理器（CCM）的概念（不要与二进制混淆）最初提出的目的是使得云供应商特定代码和 Kubernetes 核心代码相互独立。 云控制器管理器能够与其他管理组件（如 Kubernetes 控制器管理器、API 服务器、调度器等）一起运行， 也能够以 Kubernetes 插件的形式启动，在这种情况下，它运行在 Kubernetes 之上。

云控制器管理器的设计基于一种插件机制，这种插件机制使得新的云提供商通过使用插件能够很容易地与 Kubernetes 集成。 目前已经有计划在 Kubernetes 中（采用 CCM）集成新的云供应商，并将已有云供应商从旧模型迁移到新的 CCM 模型。

没有引入云控制器管理器的 Kubernetes 集群架构时：

引入 CCM 的架构后，CCM 将三个组件中所有依赖云服务的逻辑进行合并，形成单一的云服务集成点，如下所示，非常直观：

如何有效地管理构建和发布过程是一个值得关注的点，本次深潜会议上将对其进行头脑风暴。需要考虑的问题包括：

1、是否以及如何在 OSS Kubernetes 的发布阻止测试套件中包含云提供商 e2e 测试。

2、如何与终端用户沟通他们是否需要以及如何获取其他组件。

3、当这些生态系统项目按其发布进度发展时，如何在 Kubernetes 的验证中管理可选插件和扩展程序（例如，N 云供应商上的 Kubernetes 上的 CoreDNS）。

本次会议将首先就最重要且紧迫的问题提出建议并进行投票表决，然后就 3-5 个主题进行公开讨论。推荐给那些从事生态系统项目的人员、对构建和发布感兴趣的人员，以及目前从事云供应商实施的人员。

如果您对上述这些内容感兴趣，或是能帮助你解决工作上遇到的问题，欢迎前来参会，一定受益匪浅。携手发展，共同前行才是王道。

本期则隆重推荐：

Jason“Jay”Smith 是谷歌的云客户工程师。他的工作职责是帮助各大企业在谷歌云上找寻方式扩大工作量。大数据是他的爱好之一，因为企业也在寻找收集、存储和分析信息的方式。目前他在 Kubeflow 上市团队任职，帮助人们以“集装箱的形式”打包机器学习技术，用于改善便携性和扩展性。他此前曾在 DockerCon 演讲。