随着容器平台与NSX-T集成越来越广泛，使用Antrea作为CNI且使用全路由（noEncap）实现Pod路由全域可达的场景也越来越多，VMware Tanzu产品下已经可以通过NSX-T实现了全自动的在T1上完成路由注入，但在原生的K8S平台以及OCP场景还依然需要手工添加，当worker节点数量较多时，以及增加worker节点时都会带来运维工作量，本文将阐述利用vSphere Cloud Provider Interface（CPI）来解决自动化问题，以实现在K8S，OCP使用NSX-T+Antrea时自动化完成T1的路由注入。

CPI介绍

in-tree solution

为了让 Kubernetes 能够更好地运行在云平台上，能够灵活地使用、管理云上其他的基础资源和基础服务，并且提供容器云服务，云厂商需要实现自己的Cloud Provider，即实现：cloudprovider.Interface。

它是 Kubernetes 中开放给云厂商的通用接口，便于 Kubernetes 自动管理和利用云服务商提供的资源，这些资源包括虚拟机资源、负载均衡服务、弹性公网 IP、存储服务等。 Kubernetes 核心库内置了很多主流云厂商的实现，包括 AWS、GCE、Azure，Vmware等，如下图所示，目前in-tree solution基本已不在维护，此目录中的Cloud providers已被弃用，即将被删除，取而代之的是外部external providers( out-of-tree)。https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider

早期的in-tree vSphere Cloud Provider 实现架构

out-of-tree solution

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

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

在 Kubernetes v1.6，引入了 Cloud Controller Manager（CCM），目的就是最终替代 Cloud Provider。因为原先的 Cloud Provider 与 Master 中的组件 kube-controller-manager、kube-apiserver 以及 Node 中的组件 kubelet 耦合很紧密，所以这三个组件也进行了重构。

解耦之后out-of-tree CPI为Kubernetes提供了部署基础设施的详细信息。当Kubernetes节点向Kubernetes API server注册时，它向cloud provider请求关于自身的附加信息。CPI为Kubernetes集群中的节点对象提供IP地址和区域/区域拓扑。当节点了解底层基础设施的拓扑结构和层次结构时，可以做出更智能的application placement决策。

out-of-tree CPI集成连接到vCenter Server，并将有关基础设施（如虚拟机、磁盘等）的信息映射回Kubernetes API。只有cloud-controller-manager

pod需要具有有效的配置文件和凭证才能连接到vCenter Server。下图说明了集群中的哪些组件应连接到vCenter Server。

目前out-tree vSphere Cloud Provider 实现架构

测试环境信息

安装注意事项

K8S兼容性

安装前请确认K8S和OCP的Kubernetes Version,并下载对应的vSphere CloudProvider，官方推荐的兼容性列表如下：

SpoofGuard profile

用户需要确认节点的segment port或segment在SpoofGuard profile中未设置绑定。