从 K8S 的 Cloud Provider 到 CCM 的演进之路

Kubernetes 是一个云原生平台，但为了让 Kubernetes 能够更好地运行在公有云平台上，能够灵活地使用、管理云上其他的基础资源和基础服务，云厂商需要实现自己的适配器。本文详细解读了 Kubernetes 从 Cloud Provider 到 Cloud Controller Mananger（CCM) 的演变过程及其实现细节，希望有助于大家更好地在公有云平台上构建基于 Kubernetes 的容 器服务。

Cloud Provider 背景概要

基于 Kubernetes 的容器云

容器云最主要的功能是帮助用户把所有的应用以容器的形式在集群中跑起来。目前很多的容器云平台通过 Docker 及 Kubernetes 等技术给应用提供运行平台，从而实现运维自动化、快速部署应用、弹性伸缩和动态调整应用环境资源，提高研发运营效率。

Cloud Provider 与云厂商

为了更好地让 Kubernetes 在公有云平台上运行，并且提供容器云服务，云厂商需要实现自己的 Cloud Provider，即实现：

cloudprovider.Interface（https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go）。

它是 Kubernetes 中开放给云厂商的通用接口，便于 Kubernetes 自动管理和利用云服务商提供的资源，这些资源包括虚拟机资源、负载均衡服务、弹性公网 IP、存储服务等。

如下图所示，Kubernetes 核心库内置了很多主流云厂商的实现，包括 AWS、GCE、Azure：

Cloud Provider 的重构之路

近几年来， Kubernetes 逐渐成为在私有云、公有云和混合云环境中大规模部署容器化应用的事实标准，以至于越来越多的云厂商加入了进来，而 Cloud Provider 的实现也越来越多。

作为在 Kubernetes 核心库中的代码，这必将影响其快速更新和迭代。 所以产生了把 Cloud Provider 移出 Kubernetes 核心库并进行重构的提案（Refactor Cloud Provider out of Kubernetes Core）。

在 Kubernetes v1.6，引入了 Cloud Controller Manager（CCM），目的就是最终替代 Cloud Provider。截止到最新的 Kubernetes v1.11，还是处于 beta 阶段。

Cloud Provider 解析

Cloud Provider 的作用

在 Kubernetes 中有三个组件对 Cloud Provider 有依赖，分别是：

• kube-controller-manager

• kubelet

• kube-apiserver

这三个组件对 Cloud Provider 的依赖部分会最终编译进相应的二进制中，详细的依赖关系图如下所示：

kube-controller-manager 对于 Cloud Provider 的依赖

kube-controller-ma