Kubernetes Cloud Provider演进以及在Azure上的应用

作者介绍：倪朋飞，现于微软负责Kubernetes OpenSource相关工作，是Kubernetes项目的maintainer。

本文主要是关于 “ 如何让Kubernetes更好地在公有云平台上运行 ” 。选择的主要切入点是Cloud Provider，同时也会介绍一下在Azure中的相关实践。

图1 列出了今天分享的主要内容：首先是Kubernetes的介绍；然后是Cloud Provider在Kubernetes中的位置，“究竟是什么样的一个东西”，及其过去、现在还有未来版本中演进的过程；最后是它在Azure上的实践。

图 1

首先看一下kubernetes的架构。它的架构比较直观，是一个master/slave结构，包括master和node。

图 2

Master节点中主要有四个组件。首先是Kubernetes中负责数据存储的部分，即存储了所有需要持久化数据的ETCD。然后是Kubernetes中主要的三个控制层面的组件：API Server，Controller Manager，Scheduler。

API Server是整个集群数据访问的入口，同时也是暴露restful api给用户的一个接口。并且无论是集群内部还是外部的组件，都必须通过API Server来访问数据。

Controller Manager是Kubernetes的“大脑”，换句话说，Kubernetes中所有需要维护状态一致性相关的工作都是由其来实现的。同时Controller Manager中还包括有维护各种资源的控制器。

Scheduler的作用很直观，就是把特定的容器调度到特定的节点上。

下面部分是和Node相关的(Slave部分)，即容器真正运行的节点，其上也同时运行一些服务，如负责服务发现和负载均衡的kube-proxy，负责容器、镜像生命周期的Kubelet，负责真正运行镜像的Container Runtime以及网络插件Networking Plugins。

Kubernetes除了这些核心的组件以外，还有很多丰富的功能，而这些额外的功能都是通过“Addon”的方式来部署的。

接下来就是我们今天所要讲述的主题：如何更好地在公有云平台上运行Kubernetes。这里就涉及到了Cloud Provider。Cloud Provider在Kubernetes架构中主要所处的位置就是如图所示加亮的部分：Controller Manager、API Server 和 Kubelet。API Server需要Cloud Provider是因为其中包含了一系列Admission Controller。其中的两个是需要和Cloud Provider进行交互的：分别是PV Label 和 PV Resize。Controller Manager是和Cloud Provider交互最多的一个组件，它最主要的功能是维护集群和Node的状态。比如说它可以检测VM是否存活，然后作出相应的标记；再比如Load Balance相关的服务，创建LB或者Health Check，或者是暴露一个公网IP来让外网进行访问。再有就是Kubelet，它在启动、状态维护的时候需要去Cloud Provider中查看一些基本的信息，如内网、外网的IP地址，属于哪一个zone，标签，所处VM的状态等信息。

图 3