转载自：https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/79564365
本文主要是关于 “ 如何让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
让我们来看一下Cloud Provider。它是Kubernetes中开放给云服务商的通用接口，包含一系列的API。它存在的主要目的就是为了让Kubernetes更好地运行在云平台上。比如说：在网络方面，就是上述提到的负载均衡，给负载均衡创建公网IP，给Kubernetes中的各个Node创建路由；存储上，是提供数据持久化存储的方式；最后的话还有Node状态的维护，Node所在VM的状态、IP的变更等。Kubernetes内部也提供了Cloud Provider的支持。对于国内一些暂无内部支持的厂商，也是有方案支持的。
图 4
接下来，让我们来看一下Cloud Provider的架构。正如前所述，Cloud Provider作为一个通用的接口，云厂商会基于这些接口实现自己的逻辑，然后在这些逻辑之上，Controller Manager会和Cloud Provider进行交互，维护整个集群的四个部分的状态：Node、Route(路由)、Service(负载均衡、公网IP)、Volume(持久化存储)。除此之外还有Kubelet。Kubelet会维护Node的状态和基本信息。最后是API Serve 的 Admission Controller，包括 PV Label和PV Resize，如果用到这两个的话需要显示地使用。凡是用到Cloud Provider，都需要配置这三个组件。
图 5
来讲一下Cloud Provider接口。实际上它是很多接口定义的集合，这些接口定义是由云厂商自己去实现即可。而这些接口定义又分成不同的组，图5 中就是这些分组。其中PV略有不同，因为其它几个均是标准的接口，而PV没有，这主要是因为不同云厂商所支持的PV也是不同的。因为PV自身的特殊性，所以在Cloud Provider的演进中，也出现了一些问题，后面会进行一些介绍。
图 6
Instances主要是维护Node的状态。
图 7
LoadBalancer主要是和负载均衡相关，在实现的过程中保证最终一致性即可。
图 8
Cluster以及Zones，这两个接口主要是为了查询VM所在的位置，即哪一个集群或者哪一个Zone中，这在多集群管理中是需要的。Routes就是配置路由，也是比较关键的一部分。
图 9
PV接口，不同的云平台的实现是不同的，此处举了一个AzureFile/AzureDisk 的实例。
图 10
Kubernetes从诞生时，就是一个云原生的平台。因此在Cloud Provider在第一个Release版本中就已经定义好了。当然，这个接口也在不断的演进过程中，功能也得到不断的丰富，得到不同厂商的支持。
由于Cloud Provider是一系列Go的接口，因此其实现需要提交到Kubernetes的核心代码库中。这里就容易产生了一些问题，这主要是因为云平台的数量众多，根本不可能全部维护。因此从1.6版本开始，就把Cloud Provider核心功能拆分出来，形成一个Cloud-Controller-Manager。它目前还是alpha阶段，因此目前还是推荐本文上述的Controller Manager、API Server和Kubelet的方式来实现，但是今后是肯定会往Cloud-Controller-Manager这个方向去演进的。而有了Cloud-Controller-Manager之后，各个云厂商只需要把接口实现代码保存在自己的代码库中，然后以Addon的方式来使用即可。在1.10后的版本后，计划就是完全使用Cloud-Controller-Manager。当然这里还是有一些挑战的，比如和PV相关的。
接下来是一个更详细的介绍。
这就是当前的Cloud Provider的架构图，也是目前所推荐的架构。通过配置Controller Manager、Kubelet 和 API Server来配置Cloud Provider的一些选项，即in-tree Cloud Provider。
图 11
这是使用 Cloud Controller Manager 来管理。在阿里云等非 in-tree 的云服务上，就推荐使用该结构。该结构将Controller Manager、Kubelet 和 API Server都移到Cloud Controller Manager中。云厂商实现好这些接口后将它们部署到 Kubernetes 集群中，部署格式和上述的Kube Controller Manager是类似的。在这个阶段只是将和PV不相关的都挪到Cloud-controller-manager中，但是和PV相关的还是要放在Kube-controller-manager中，这主要是因为PV的接口是没有统一的定义，这在未来的Cloud Provider中也是有所体现的。
图 12
在接下来的版本中，会将所有逻辑都移到Cloud-controller-manager中，而Kubelet和Kube-controller-manager这两个组件就不需要考虑Cloud Provider了。而刚才提到的PV，就放在这里的Container Storage Interface中来管理。它实际上是一个通用的存储接口，是由社区规范标准化的一个grpc接口，因此它的实现可以用很多不同语言来实现。而之前和Cloud Provider相关的PV，就可以通过这个CSI的方式来实现，这样PV和Kubernetes就实现了解耦。
说到CSI，实际上现在社区中扩展Volume还有另外一种方式，Flex Volume。它的目的和CSI一样，都是为了方便存储提供商给Kubernetes提供一些存储的架构，并且在提供存储支持时，不需要修改Kubernetes的核心代码。Flex Volume的一个缺点是，在部署时需要以二进制文件的形式来部署，而这些二进制文件本身的管理是相当麻烦的，CSI是没有这个缺点的。
图 13
最后一部分是介绍Kubernetes Cloud Provider在Azure中的实践。Kubernetes在1.4版本的时候就加入了Azure Cloud Provider中，实现了上述所有的接口，同时支出AzureFile和AzureDisk持久化存储，还支持一些额外的功能。
在Azure上一系列的容器服务，如AKS、Azure Container Service Engine 和ACS 等使用了 Azure Cloud Provider。AKS目前是在preview阶段，18年上半年会 GA。AKS主要是提供一个托管的Kubernetes集群，并且其控制平面是完全免费。它的控制平面是保证了高可用的，后期的更新维护是完全不用用户操心的。Azure Container Service Engine 是一个开源的项目，在github上叫acs-engine，通过该项目可以在Azure上部署自己管理的Kubernetes集群。它的好处是，用户可以完全自己来管理Kubernetes。最后的ACS实际上是一个老版本的Azure Container Service，在AKS GA之后，还是推荐使用AKS。
图 14
来看一些配置相关的。即在使用Cloud Provider的时候需要对Kubelet、Kube-controller-manager和API Server中的配置。如指定所需要使用的云平台类型、认证密钥的参数。还有是配置格式，尽管参数繁多，但当前的云平台大多是帮用户配置好了这些参数，不需要用户去操心。
Azure上支持如下两种持久化存储方式：AzureFile和AzureDisk。
AzureFile是基于SMB协议，它的最大的一个好处就是支持跨主机共享。同时对于Windows Server支持Cache。图15中可以看到一个AzureFile实例。
图 15
AzureDisk相当于是一个Block设备，首先会挂载到Node所在的VM上。AzureDisk在Azure中使用时，首先需要一个存储账户。这个账户可以由用户来管理(Blob Disk)，也可以由平台来管理(Managed Disk)。AzureDisk的缺点，是它不支持共享。不过它的性能相比AzureFile会更好一些。
图 16
图 17
图17是一个AzureDisk实例。同时说到应用的话，还有一个重要的点就是负载均衡。它主要是为LoadBalancer 服务分配公网IP和负载均衡器、健康检查器。图18中列出的一个子集。
图 18
这是我今天讲的内容，今天讲的内容比较粗略的，如果要做自己的cloud provider，可以参考一下设计文档
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md
也可以看一下我这里整理的Kubernetes指南
https://github.com/feiskyer/kubernetes-handbook
671
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
