介绍适用于 Yandex.Cloud 的 Kubernetes CCM（云控制器管理器）

延续最近的 CSI驱动程序发布 对于 Yandex.Cloud，我们正在为此云发布另一个开源项目 - 云控制器管理器。 CCM 不仅对于整个集群是必需的，对于 CSI 驱动程序本身也是如此。 有关其目的和一些实现功能的详细信息正在讨论中。

介绍

这是为什么？

促使我们为 Yandex.Cloud 开发 CCM 的动机与中已经描述的完全一致 公告 CSI 驱动程序。 我们维护来自不同云提供商的许多 Kubernetes 集群，为此我们使用单一工具。 它“绕过”这些提供商的托管解决方案，实现了许多便利。 是的，我们有一个相当具体的案例和需求，但因此而创建的开发可能对其他用户有用。

CCM到底是什么？

通常我们会为集群准备周围的环境 从外面 - 例如，使用 Terraform。 但有时需要管理我们周围的云环境 来自集群。 提供了这种可能性，实现的正是它 CCM.

具体来说，Cloud Controller Manager 提供五种主要的交互类型：

1. 实例 – 在 Kubernetes 中实现节点对象之间的 1:1 关系（Node）和云提供商中的虚拟机。 为此我们：
   • 填写字段 spec.providerID 在对象中 Node。 例如，对于 OpenStack CCM，该字段具有以下格式： openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0。 可以看到该对象的云提供商的名称和服务器（OpenStack中的虚拟机）的唯一UUID；
   • 补充 nodeInfo 在对象中 Node 有关虚拟机的信息。 例如，我们在AWS中指定实例类型；
   • 我们检查云中是否存在虚拟机。 例如，如果一个对象 Node 进入一种状态 NotReady，您可以通过以下方式检查虚拟机是否存在于云提供商中 providerID。 如果不存在，则删除该对象 Node，否则它将永远保留在集群中；
2. 区 – 设置对象的故障域 Node，以便调度器可以根据云提供商中的地域和可用区为Pod选择节点；
3. 负载均衡器 – 创建对象时 Service 与类型 LoadBalancer 创建一种平衡器，将流量从外部引导到集群节点。 例如，在 Yandex.Cloud 中您可以使用 NetworkLoadBalancer и TargetGroup 出于这些目的；
4. 路线 – 在节点之间建立网络，因为根据 Kubernetes 的要求，每个 Pod 必须有自己的 IP 地址，并且能够访问任何其他 Pod。 为此，您可以使用覆盖网络（VXLAN、GENEVE）或直接在云提供商的虚拟网络中设置路由表：

   

5. 音量 – 允许使用 PVC 和 SC 动态排序 PV。 最初，此功能是 CCM 的一部分，但由于其非常复杂，它被转移到一个单独的项目，即容器存储接口 (CSI)。 我们不止一次谈论过CSI писали 而且，正如已经提到的，甚至 已发布 CSI 驱动程序。

此前，所有与云交互的代码都位于 Kubernetes 项目的主 Git 存储库中，地址为 k8s.io/kubernetes/pkg/cloudprovider/providers，但由于使用大型代码库的不便，他们决定放弃这一点。 所有旧的实现都已移至 单独的存储库。 为了方便进一步的支持和开发，所有通用组件也移至 单独的存储库.

与 CSI 一样，许多大型云提供商已经设计了他们的 CCM 以利用 Kubernetes 上的云。 如果供应商没有CCM，但所有必要的功能都可以通过API获得，那么您可以自己实施CCM。

要编写自己的 CCM 实现，只需实现 所需的 Go 接口.

И 这就是我们得到的.

履行

你是怎么到这个地步的

我们开始开发（或者更确切地说，甚至使用） 准备好（！）CCM 一年前的 Yandex.Cloud。

然而，在这个实现中我们遗漏了：

• 通过 JWT IAM 令牌进行身份验证；
• 服务控制器支持。

与作者一致 （德利辛） 在 Telegram 中，我们分叉了 yandex-cloud-controller-manager 并添加了缺失的功能。

主要特点

目前，CCM支持以下接口：

• 实例;
• 区;
• 负载均衡器.

将来，当Yandex.Cloud开始使用高级VPC功能时，我们将添加一个接口 路线.

LoadBalancer 是主要挑战

最初，我们尝试像其他 CCM 实现一样创建一对 LoadBalancer и TargetGroup 每个 Service 与类型 LoadBalancer。 然而，Yandex.Cloud 发现了一个有趣的限制：你不能使用 TargetGroups 与相交 Targets （一对 SubnetID - IpAddress).

因此，在创建的 CCM 内部，会启动一个控制器，当对象发生变化时，该控制器将启动 Node 收集有关每个虚拟机上所有接口的信息，根据其所属的特定组对它们进行分组 NetworkID, 创建者 TargetGroup 上 NetworkID，并且还监视相关性。 随后，在创建对象时 Service 与类型 LoadBalanacer 我们只需附加一个预先创建的 TargetGroup 到新 NetworkLoadBalanacer'是。

如何开始使用？

CCM 支持 Kubernetes 1.15 及更高版本。 在集群中，要使其工作，需要标志 --cloud-provider=external 被设置为 true 对于 kube-apiserver、kube-controller-manager、kube-scheduler 和所有 kubelet。

安装本身的所有必要步骤均在 读我。 安装归结为从清单在 Kubernetes 中创建对象。

要使用 CCM，您还需要：

• 指定 在清单中的目录标识符（folder-id) Yandex.Cloud;
• 用于与 Yandex.Cloud API 交互的服务帐户。 在宣言中 Secret 必要 传输授权密钥 来自服务帐户。 在文档中 描述，如何创建服务帐户并获取密钥。

我们将很高兴收到您的反馈并 新问题如果您遇到任何问题！

结果

过去两周，我们一直在 20 个 Kubernetes 集群中使用已实施的 CCM，并计划在下个月将其数量扩大到 8 个。 我们目前不建议对大型且关键的 KXNUMXs 安装使用 CCM。

与 CSI 的情况一样，如果 Yandex 开发人员承担该项目的开发和支持，我们将很高兴 - 我们准备根据他们的要求转移存储库，以便处理与我们更相关的任务。

PS

另请阅读我们的博客：

• «我们在 Kubernetes 中为 Yandex.Cloud 开发 CSI 驱动程序的经验“;
• «准备一个Kubernetes集群是不是简单方便？ 宣布插件运营商“;
• «扩展和补充 Kubernetes（评论和视频报告）“。

来源： habr.com