基于ker的开源云主机集群管理平台

1、本科生毕业论文基于Docker的开源云主机集群管理平台opensource cloud cluster managerplatformbased on Docker毕业设计（论文）原创承诺书.本人承诺：所呈交的毕业设计（论文）ActionScript3 在Flash 游戏制作中的应用，是认真学习理解学校的长春理工大学本科毕 业设计（论文）工作条例后，在教师的指导下，保质保量独立地完 成了任务书中规定的内容，不弄虚作假，不抄袭别人的工作内容。.本人在毕业设计（论文）中引用他人的观点和研究成果，均 在文中加以注释或以参考文献形式列出， 对本文的研究工作做出重要 贡献的个人和集体均已在文中注明。.在

2、毕业设计（论文）中对侵犯任何方面知识产权的行为，由 本人承担相应的法律责任。.本人完全了解学校关于保存、 使用毕业设计（论文）的规定， 即：按照学校要求提交论文和相关材料的印刷本和电子版本；同意学校保留毕业设计（论文）的复印件和电子版本，允许被查阅和借阅； 学校可以采用影印、缩印或其他复制手段保存毕业设计（论文），可以公布其中的全部或部分内容。以上承诺的法律结果将完全由本人承担！作者签名:年 月曰摘要Docker日益火爆的今天，本次设计对其网络化和集群化能力做出了一个尝试。并开发了 Kubernetes用来搭建了一个集群管控程序。本文就其的主要部件的设计的分析和具体实现的 设计详细描述了容器的

3、大规模化之后应该去完善的工作。在整个体系中，本设计将容器升级划分成了一个一个的Pod,并将其作为最小的调度单元。解除了集群管理程序和 Docker程序的耦合。同时，通过ETCD集群做全局索引系统，利用其 实现的Raft算法带来的集群写一致性，进而保证了整个系统的一致性。同时，为互联网与 Pod之间增加了一层访问中间控制层，解决了传统软件服务发现和流量负载均衡的问题。但 是，对于DNS的支持并未达到理想的程度。最后，利用自建的机制解决了服务的动态扩容 难题，为快速部署服务提供了一个简单而可行的方案。关键字：容器集群云计算微服务AbstractDocker increasingly popular

4、 today, we made an attempt on its network clustering capabilities. And the development of Kubernetes to build a cluster control program. This article describes in detail the scale of what we should do after work on the analysis of the container main part of the design and implementation of the desig

5、n.In the whole system, we will upgrade the container is divided into a one of the Pod, and as the smallest dispatch unit. Decoupled cluster management procedures and Docker program. Meanwhile, global indexes do ETCD cluster system that uses Raft bring its implementation algorithm clusters write cons

6、istency, thus ensuring consistency throughout the system.At the same time, we will add another layer of access control layer intermediate between the Internet and Pod, to solve the traditional software Service discovery and traffic load balance. However, support for DNS did not reach the desired lev

7、el.Finally, we use self-built mechanism to solve the problem of dynamic expansion of Services for rapid deployment Services provide a simple and workable solution.Key words : Container;Cluster;Cloud Computing;Micro-ServiceII目录 TOC o 1-5 h z HYPERLINK l bookmark2 o Current Document 摘要I HYPERLINK l bo

8、okmark4 o Current Document AbstractII目录IJJ.第1章绪论1. HYPERLINK l bookmark13 o Current Document 1课题研究的背景及意义1. HYPERLINK l bookmark16 o Current Document 提高资源利用率1. HYPERLINK l bookmark18 o Current Document 服务的动态扩容和持续集成 1国内外研究现状2. HYPERLINK l bookmark20 o Current Document CasS平台2. HYPERLINK l bookmark22 o

9、 Current Document 容器VS虚拟机一一商用为主 2服务化2. HYPERLINK l bookmark24 o Current Document 主要研究内容3. HYPERLINK l bookmark26 o Current Document 论文组织结构 3.第2章总体设计4.功能设计4. HYPERLINK l bookmark31 o Current Document Minion 节点组件 4. HYPERLINK l bookmark33 o Current Document Master 节点组件5.基本概念6. HYPERLINK l bookmark37 o

10、 Current Document Pod6. HYPERLINK l bookmark39 o Current Document Service7. HYPERLINK l bookmark41 o Current Document Replication Controller7 HYPERLINK l bookmark43 o Current Document Label8. HYPERLINK l bookmark45 o Current Document 第3章详细设计9.Master 节点9.Kubectl9.API Server9. HYPERLINK l bookmark47 o

11、 Current Document Minion Registry1.1 HYPERLINK l bookmark49 o Current Document Pod Registry1.1 HYPERLINK l bookmark51 o Current Document Service Registry1.1 HYPERLINK l bookmark53 o Current Document Controller Registry1.2 HYPERLINK l bookmark55 o Current Document Endpoints Registry1.2 HYPERLINK l bo

12、okmark57 o Current Document Binding Registry.12Scheduler.1.2 HYPERLINK l bookmark62 o Current Document 第4章设计实现1.4Pod14iii TOC o 1-5 h z HYPERLINK l bookmark64 o Current Document Volume15容器通信16 HYPERLINK l bookmark78 o Current Document Replication Controller1.6 HYPERLINK l bookmark70 o Current Docume

13、nt RestartPolicy 和 ReplicationController1 7 HYPERLINK l bookmark80 o Current Document Replication Controller 的工作机制1 8Replication Controller 的应用场景1 9 HYPERLINK l bookmark92 o Current Document Service20 HYPERLINK l bookmark82 o Current Document 工作机制2.1 HYPERLINK l bookmark84 o Current Document 数据结构定义

14、21服务发现22 HYPERLINK l bookmark86 o Current Document Headless Service23 HYPERLINK l bookmark88 o Current Document 入口地址和外部可路由性23 HYPERLINK l bookmark90 o Current Document 避免端口冲突 23Service 入 口24 HYPERLINK l bookmark94 o Current Document 存在的的不足 24 HYPERLINK l bookmark96 o Current Document API Server25设计目

15、的25资源对象的RESTful接口 26API操作的原子性26API Server流程27 HYPERLINK l bookmark98 o Current Document 第5章调度和网络29网络29网络模型29具体实现29其他工作29 HYPERLINK l bookmark100 o Current Document Minion 管理30Minion 发现30Minion 管控流程.31调度器31调度策略31 HYPERLINK l bookmark102 o Current Document 例 1： Predicates.PodFitsPorts32 HYPERLINK l bo

16、okmark104 o Current Document 例 2： Priorities.LeastRequestedPriority33 HYPERLINK l bookmark106 o Current Document 缓存模型33 HYPERLINK l bookmark108 o Current Document 第6章实战部署.35 HYPERLINK l bookmark110 o Current Document 环境准备35 HYPERLINK l bookmark112 o Current Document 下载软件包 35IV TOC o 1-5 h z HYPERLIN

17、K l bookmark114 o Current Document 下载源码包进行编译35upstart 脚本35安装kubernetes客户端程序.35 HYPERLINK l bookmark116 o Current Document 第7章总结37 HYPERLINK l bookmark118 o Current Document 参考文献38 HYPERLINK l bookmark120 o Current Document 致谢39 HYPERLINK l bookmark122 o Current Document 附录40第1章绪论1课题研究的背景及意义提高资源利用率现行

18、的网络服务器集群，有很大的一部分都是由巨量的服务器组成的，这些服务器根据资源的占用情况可以被分为 IO密集型、计算密集型、存储型、图形工作站、特殊用型（例如堡 垒机，基础交换机等）。事实上，对于IO密集型的机器，其计算能力会产生部分冗余，这个 无法避免，甚至在 LXG KVM等轻量级虚拟化技术诞生之前都无法利用他们，造成了很大的 资源浪费1。同样道理，计算密集型的IO、存储往往都是处于无法利用的状态。因此，对于，大规模应用来说一门轻量级的资源利用技术是极其迫切的需要2。在Docker之前，便有一些轻量级虚拟化技术冏了，事实上，Docker本身也是基于LXC4做为基础建立的（0.8版本之后改用自

19、己编译的libcontainer ,本质还是LXC）但是这些技术都有一个致命的缺陷，就是不支持冷备，所有的操作都是热操作。全热操作导致的一个巨大的问题 就是无法进行快速的部署、启动和迁移。而Docker创新的采用了 image和container分离的技术，并用版本控制系统来进行标记，让虚机迁移、部署、启动这个过程变得异常简单。当 然，这样做带来的一点负面影响就是在编写虚机的时候较为麻烦，但是完全值得。服务的动态扩容和持续集成服务，尤其是面向互联网的服务，始终面临着巨量用户的考验，随时可能到来，多大的量都 可能。例如春节时候的 12306、例如双十一的阿里巴巴，其各种资源都达到了瓶颈，无论是

20、计算资源还是网络资源。而服务的高可用最简单的方法就是提升服务器的数量。但是如何快速接入服务，阿里巴巴会在每次购物节到来之前提前一个月安排专人对服务器进行扩容和补 充，购物节结束之后又会进行服务器的删减。因为在平时维持这么巨量的服务器是完全没有意义的。这是阿里巴巴的做法，但是广大公司并没有阿里巴巴那样的财力物力。2015年初，一个叫足迹的 App火了，但是她们连 CEO加一起团队成员才 8个人，面对的却 是一天暴涨的400万用户量，服务器瞬间瘫痪，App彻底失效。她们除了给所有用户推送了一条道歉信之外什么都做不了，服务器有，但是就是提供不了服务。同样的例子也发生在了今年春节联欢晚会，但是却收到了

21、不同的效果，其中容器技术贡献巨大。羊年春晚有两个热 点，一个是巨量的网络春晚收视率，另一个就是微信红包。其中，为了推送巨量的网络视频 流，春晚后勤便采用了 Docker的动态扩容技术，在高峰到来之前迅速部署了巨量的容器， 在不同的服务器之间进行轮询，并且自动发现并重启down掉的容器。正是这样可怕的动态扩容能力，保证了春晚网络直播的顺利进行。就我所实习的公司（七牛网络信息技术有限公司，以下简称七牛）来说，Docker已经成为七牛持续集成部署的一部分了。七牛将其用在了图片处理、ufop、MEMPG处理等业务上，每一个image服务都封装成一个 container,大大提到了 image服务的处理

22、能力和持续集成能 力和监控能力5,每次部署机器，只需要拉取指定的二进制压缩包即可，简单方便。1.2国内外研究现状.CasS 平台Docker原本是DotCloud公司的一个主要项目，后来被开源出来，而 DotCloud公司提供的正 是CasS云。CasS即Container-as-Service的简写，对于这样的服务，编程人员可能并不了解， 但是其实 Google Compute Engine , Sina App Engine, Baidu App Engine 2.0,阿里巴巴 ECS云 服务器，CloudFoundry （部分采用）等技术都是提供的CasS服务。但是对外表现来说，阿里巴巴

23、的ECS更像一个PasS但是其实底层还是用的容器技术（当然不可能是 Docker）。国内，完全基于Docker的CasS公司DaoCloud也于前日正式对外提供服务。容器VS虚拟机一一商用为主虚拟机技术，从最开始的分时系统，到后来的各种VM的乱战到Xen的统一服务器端江湖6, 直到现在KVM流行。“现在都是KVM7,如果新一点的，就玩 Container 了。”计算机世界分 为两条线，计算和存储，虚拟化属于计算这条线，而虚拟化又分为两条，硬件虚拟化和软件虚拟化，硬件虚拟化从 旧M时代就开始了。 1999年，一个叫 VMware Workstation的公司流 行了一段时间，这个公司就是现在的虚

24、拟化巨头 VMware。但是前几年被卖给 EMC 了，现在 连EMC都自身难保。相较之，容器技术的概念也被提出很久了，根据国外的研究成果8,之所以一致未曾实现，主要原因还是因为容器技术的不成熟。因为是进程级别虚拟化，其隔离系统总不会像硬件级别虚拟化一样密不透风，Linux Kernel上关于LXC的Security Announce有五十多个，但是没人敢去修，因为这个东西是牵一发而动全身的。从旧M 360到VMware的流行，国外花了近二十年时间才让硬件虚拟化技术变得为商业所接受。同样的，容器技术要走进真正的商用还需要很长的一段路9。微服务化云计算在当计算机科学高度发展的今天已经越来越多参与了

25、我们正常的生产生活。同时，提供云计算服务的厂商也如雨后春笋般冒了出来。与传统的IT产业公司不同的是，云计算时代的互联网公司，作为云计算服务的提供者，越来越扮演着幕后的角色。典型的云计算时代， 当你打开手机，点开某个门户网站，浏览一段视频，与人沟通交流，这一切的一切都是由巨量的服务支撑起来的。同样的，每一个服务都尽量做到轻量，简单。这也正是UNIX的设计哲学1,这样的服务被称之为 微服务将服务拆散开，以链接、api、转发、负载均衡等方式对外提供，在提供商这里，拆小了业务逻辑，将原先生产一条飞机的难度降低到了生产一颗螺丝钉上去。对于开发者和消费者，微服务提供了更多的可能和更强大的兼容性。然而，抛开

26、了完整的系统，而转向微服务的我们，该如何保证微服务的稳定和高可用呢？云计算就像一个池子，服务就像池子里的水，正常情况下，服务从提供商手里流出，保障其基础设施的运转良好。 但是当你的池子不够大呢？扩容？是个好办法。但是这需要时间和成本的开销，而且运维反应速度慢和快也是衡量一个公司服务能力的重要标准。因此，在云计算时代，无论企业还是个人，都需要一个轻便，易于部署，快速迁移，快速启动的环境设置技术来支持服务启用、备份、容灾、迁移。这个技术，就是 Docker。Docker是一个容器管理程序，由 Golang编写，采用LXC做BackEnd,提供了容器的快速启 kISS:keep it simple

27、& stupid动，快速部署，版本控制等方法。Docker就像一个集装箱，把服务需要的环境都封装在里面，想用的时候直接拿集装箱走并使用就可以。省去了很多无用而且缓慢的部署脚本，并且，其image的概念的提出，为冷备 Docker提供了一个简单而且方便的途径。国内目前已经有 学者开始对微服务化的可行性做了研究，并且，Docker也开始和传统的云计算平台结合10产生了奇妙的变化。主要研究内容本文主要进行了如下的研究：(1)对Kubernetes的设计和架构进行深度解析，分析各个组件的设计目的 和具体实现(2)提供一个简单、易用的自动化部署、持续集成、滚动升级、灰度、多 版本追踪发布方案。让Dock

28、er能够更加简单的在生产环境中应用。(3)提供一个可靠的横向扩展架构，搭建一个无状态易扩展的高可用服务 器集群，自动实现负载均衡和动态扩容。(4)研究虚网络和SDN网络的设计模型，并对其进行分析。以及在 Kub ernetes中的应用和实战。(5)研究集群一致算法Raft11,分析Kubernetes的集群的一致性。论文组织结构本次论文共分三个大部分：总体设计、细节设计、实战部署。其中，第1章第2章，主要讲述的是 Kubernetes系统的架构和设计，以及一些特化的概念。第3章第5章是Kubernetes系统的详细设计和技术细节。本部分从Master节点开始，逐步分析Kubernetes系统设

29、计实践中出现的问题，并提出自己的解决方案。展示其各个组件的 实现细节和技术上的缺陷。第6章是Kubernetes的实战部署，在一台 Ubuntu 14.04主机上搭建单节点的 Kubernetes集 群，并检测其安装结果。第2章总体设计功能设计本系统名叫Kubernetes ,是Google公司推出的一款类似于BorgBorg是Google公司内部使用的服务部署和动态迁移程序，未开源的开源的容器管理程序。其总体设计图图2- 1：公MScheduler%4QQ4Minion集群图 2- 1 Kubernetes 网络图对于Kubernetes,其详细组件图如图2- 2：Minion节点组件在每个

30、对外提供服务的节点（对于整个集群来说，这些节点可以称之为minion）上，Kubernetes有如下组件：kubelet:管理Docker本身，与BackEnd通讯的程序，其本身就是一个守护进程，伴随着Docker一起启动。kube-Proxy：代理程序，对外提供 Docker机器上的服务的网络转发，对内则进行端口映射和 隧道压缩，将网络流转发致各个可用的服务容器上。Master节点组件对于master节点，共有三个主要组件：kube-apiserver:本组件是 Kubernetes系统的主要组件， 对外，apiserver提供开放的端口， 即， 提供服务；对内，apiserver维持一个对

31、于ETCD系统的RESTful持久化对象，以便于同步集 群的信息。对整个集群，他是集群控制的入口，提供一个RESTful的api来对集群进行控制。kube-scheduler: Kubernetes的调度程序，负责调度整个集群的资源，为部署容器提供自动化 的执行方案3。kube-controller-manager: Kubernetes 的执行各种 controller 的程序，目前 controller 共有两类， 分别是：endpoint-controller ：负责关联Kubernetes的服务和容器4映射的正确性。replication-controller ：负责定义容器的数量处在

32、正确的值，即，关闭超过 数量的容器，增加因为资源不足，意外宕机等原因而减少的容器的数量。etcd : etcd是一个由Coreos公司实现的简易 k-v分布式数据存储系统，采用 raft算法保证集 群一致性。Kubernetes用它来实现了一个 global index系统，从而达到全局的一致性保证。这里面主要存储的是Kubernetes系统的所有Label。3这个地方原本是Borg系统最精华的部分，但是限于Google公司机密，因此做成了一个简单的服务。4当然，这里对于容器并不是k8s的最基本调度单位，这里所说的实际上使指的Service和pod的正确映射关系，关于k8s的一些基本概念，将在

33、下一节详细叙述基本概念PodPod,是Kubernetes的一个基本的调度单位，一个 Pod对应的一组 Docker Container构成的 容器组，在同一个 Pod里，Docker Volume可以共享的挂载在同 Pod中的所有 Docker Container 中。如下图2- 3。在逻辑上，Pod的提出结束了自己管理Docker容器的分立的状态，Pod建立了一个“逻辑虚拟机”的模型，在这个虚拟机里，每个 Docker的Container相当于传统虚拟机的一个进程。而共享的Volume则构成了进程之间共同访问的文件资源。 与正常的Docker Container一样， Pod的生命周期，相

34、对于整个集群来说是不持久的。同时，Pod给Kubernetes提供了一个程序上的解耦， 因为Kubernetes底层是面向容器的，但不一定是只支持 Docker的。因此，为了与 Docker解除绑定，也为了能定义一个更准确的逻 辑模型，Kubernetes启用了 Pod的概念。在Pod被引入之前，我曾经尝试过在一个Docker Container同时启用多个应用。但是后来发现这样做有其固有的缺陷：(1)多个应用同时部署在一个 Docker Container之中，会增加不必要的软 件的依赖，每当其中某个依赖的软件进行变更的时候，便不得不重建 整个Docker Container。而当Docke

35、r Container的数量、大小达到一 定规模的时候，这样做无疑会带来巨量的系统负担。(2)用户不必运行自己的进程管理程序，多个进程之间也无需考虑进程信号量或退出码扩散等问题。(3)将多个应用部署到同一个容器之中，将不可避免的加重容器，这里所 说的加重是从启动时间、监控难度、调度难度等多个方面来考量的。Pod1Redis-Master-Container1Redis-Slave-Container1Volume-redis图2- 3 Pod结构图而引入Pod带来的了两点显著的改善:(1)资源共享和容器通信Pod的引入将多个不同的为多个Docker Container之间划分了一个界限，同一个

36、 Pod内部的容器共享同样的 network namespace、IP已经端口资源，能通过 UDS进行通信。在这样一个 扁平化的虚网络里，每一个 Pod都有拥有其独立的IP地址，通过该IP地址，Pod之内的容 器就能正常的与其他 Minion、逻辑虚拟机、或者容器进行直接通信。同样的，共享存储卷(Volume)的存在，方便了同一个Pod之内的各个容器进行共享数据， 以及避免了数据在容器的重建重启等过程中的丢失，保证了数据的一致性和安全性。(2)易于管理和原生的Docker API不同，Kubernetes对底层的API进行封装和抽象，提 供了一个方便而简易的接口，基本上所有的操作都可以通过一个

37、 JSON( YAML ) 文件来定义，简化了应用部署和管理的流程。 Pod可以看成是管理和扩容的基本 单位，这样，Docker容器的逻辑划分，Fate-Sharinj,拷贝协同，主机管理，资 源共享以及依赖管理都可以自动化处理。作为调度的基本单位，Kubernetes保证在整个系统里，Pod的数量都是恒定的，和 Pod创建的时候给定的参数相同。当然，类似的，用户也可以动态的调整Pod的数量，这个过程完全是由Kubernetes自动调度完成的。 当然，Pod的生命周期相对于集群来说是短暂的。他的行 为被Replication Controller所驱动。那么，Pod是何时被创建，销毁，迁移是无

38、法预测到的， 每当给Pod绑定一个IP地址时候。用户是无法确定这个IP可以被持久的，持续的访问。即， 对应的IP地址和端口是否还能存在。为了解决这个问题，Kubernetes弓I入了 Services的概念。2.2.2 Service与Pod相对，Service对应的是对外的概念。整个集群可以抽象成多个不同的服务，而每个 服务则由一定数量的 Pod组成。目前的Kubernetes采用的是iptables的nat网桥转发的功能 实现的这个转发。生成kube-proxy的数据流，连接 api-server和client上kube-proxy绑定的随机端口。对于集群的使用者来说，链接的就是Kuber

39、netes的Service所提供白虚拟IP和端口，而其内部采用轮询或者随机访问的算法来平衡各个Pod之间的压力。2.2.3 Replication ControllerReplication Controller是Kubernetes集群最有用的功能，它保证 Kubernetes的集群里总能保 持正确数量的Pod。在互联网环境下，为了保证服务的高可用性，服务提供者总是提供一通 数量的的可执行的副本来提供服务。而当集群里副本数量低于规定值时，ReplicationController会从模板中创建或者直接复制现有Pod来创建出新的Pod。而且一旦创建 Pod完毕之后，再修改模板并不会改变已经生成

40、的Pod。同样的，对于过多的Pod出现的情况，Replication Controller会杀死过多的Pod,以维持整个集群的资源。在正常情况下，即使你的应用只用到一个Pod, Kubernetes也推荐你使用 Replication Controller ,这主要是因为 Replication Controller会根据Pod的存活状态自动的进行容器的重启或者迁移。这样，便能最大程度的减少因为某个Pod异常退出而导致的服务不可用的情况，提高应用的容灾能力。Replication和Pod之间的关联，主要通过存储在Label的信息来维持。同样的，用户可以通过修改Label来动态的扩展Pod的数量

41、。这在大规模部署上线的时候非常重要。省去了大量5参照 Wikipade: HYPERLINK /wiki/Fate-sharing /wiki/Fate-sharing 的部署脚本，同时也略过了复杂而缓慢的部署脚本。一切自动运行。2.2.4 LabelLabel 是用于区分和关联 Pod、Service和 Replication Controller 的键值对，每一个 Pod、Service、 Replication Controller可以有多个不同的键值对，但是每个key只能对应一个 value。Label的设计，使得Service能正常的将请求转发致多个Pod之中；同样的，多个Label

42、共存的设计，可以让 Replication Controller很容易白控制 Pod的生成，启动和销毁。 Kubernetes通过一个 简单的Label Selector机制，对Label进行字符串过滤和筛选，来解除各个组件之间的耦合， 达到一个松散的状态。可以说 Label( Selector)才是Kubernetes系统的核心。正因如此，纵观整个 Kubernetes系统，可以发现只有Label要求了集群的强一致性，其他的组件并没有强制要求，或者有着一定的延时。而存储Label的etcd系统，正是一个强一致性的集群存储系统。第3章详细设计Master 节点Master节点主要包含了 Kub

43、ernetes Master/API Server的主要注册机和声明，包括 Pod, Controller , Service, EndPoint, Minion , Binding 的 Registry,以及一个 RESTful的分布式存储 系统。整个程序是Kubernetes控制程序、管理 Kubernetes的主要构件 Pod、Service、ReplicationController是容器的最开始入口。Kubectlkubectl是Kubernetes自带的控制程序，通过 kubectl可以和集群进行动态的交互和管理。kubectl被设计来动态的管理集群，可以动态的创建、启动、连接 P

44、od和Service;并且查询 集群的状态，包括各个 Pod的状态，各个 Minion的状态；启动和停止某个服务，并且动态 的Bind某个服务到某个Pod模板上，这样就相当于新启动了一个服务。需要清楚的是，在旧版本的Kubernetes之中，一直是由一个叫kubecfg的入口来控制的，而现在是kubectl o同样的，其运作方式也发生了巨大的变化，如图 3-1。从图中可以看到，kubecfg通过发送请求到一个叫 kube-client的程序，并由kube-client转发 致API Server,其优点是可以将 kube-client从Master上拆分出来，让 master的逻辑更为纯 粹。

45、但随着集群功能的增加， API Server / Client的设计实际上冗余了两套 API,为了消除这 个不必要的冗余。 Kubernetes将kubecfg取消，并编写了一套 kubectl来与API Server直接连API ServerKubernetes 的 Master 上维持着一个 RESTful的 Storage,被称为 API Server Storage,整个 Storage 通过etcd实现，主要存储的各种不同类型的lable,还有少量的集群总体信息，如图 3-1所API ServerAPI ClinentAPI Serverkubectlkubecfgkubectl工作

46、图kubecfg工作图图3- 1 kubectl和kubecfg工作模式图人通例Wg切0hem图3- 2 API Server组件图10Minion RegistryMinion Registry负责跟集群中交互确认有多少个Minion , Kubernetes通过封装 Minion的Label来实现 API Server的中/minion部分的 RESTful APJ通过这些 API,用户可以对 Minion Registry 进彳f Create, Get, List, Delete等操作(对应增删改查中的CRD操作)。同样的，因为是Minion ,主机实体不支持 Update操作，只能进

47、行创建或者删除。最后， Minion Registry将Minion的 信息存储到etcd集群。另外，kubelet会收集Minion的各种资源容量信息，并分析。而Master上的调度算法则会根据Minion Registry维持的这些资源信息来考虑是否在这个节点上新建Pod。需要注意的是，当集群资源不足的时候，调度算法会自动忽略容量信息，而采取一种平衡的算法将Pod公平的平均分发至不同的Minion上，所以，保证集群机器性能类似或者相差不大是一个很好的做法。Pod RegistryPod Registry负责统计跟踪集群中有多少Pod的运行信息，以及这些Pod和Minion的映射关系。同时，

48、Pod Registry将自己和Cloud Provider的信息及其他运行时信息封装成以上类似的 RESTful接口，通过这些 API,可以对 Pod进彳T CRUD操作。这里需要注意的是，你只可以对 Pod层面进行操作，但是无法操作到 Minion。同样，对Minion 的操作也不会影响到Pod。例如，当需要减少一个Pod副本数量的时候，不能指定减少哪个Pod, Kubernetes会自动的将某个 Minion上白P Pod删除，具体是哪个，是用户不能控制的。同样的，每当删除一个 Minion，会导致这台Minion上的Pod同时被移除，但是由于Replication Controller

49、的存在，被移除的Pod会自动被迁移到另外的机器上，从而保证了集群的自动高可用性。3.3.3Service Registry与Pod Registry类似，Service Registry提供了一个方便的接口来对服务进行CRUDB作。但是，因为Pod的创建更新时间一般都会远远高于Service的修改更新时间，因此在Update服务的时候，Kubernetes采取的策略是保证服务随时可用为先，即使这个服务是错误的。即执行流程是：(1)根据模板创建新的Pod(2)等待Pod创建完成，对Pod进行复制(3)复制完成后启动所有Pod(4)停止服务转发致原Pod(5)将服务转发修改为到新的Pod(6)删除

50、原Pod这样可以保证在整个服务更新过程中的服务质量不变。因为每次服务转发到的都是最新的Pod,也就不会存在服务中断的情况。但是这样以来却也会造成Pod副本过多的情况，当集群存储资源不足或者Pod的大小特别巨大的时候，这种问题尤为突出，甚至可能导致 Update失败。因此，考虑拆分服务以减小 Pod的大小，或者采用滚动升级方案，是解决这种问题的好办法。11Controller Registry这里的 Controller,特指的是 Replication Controller , Replication Controller 保证集群中 Pod 总 是运行在一个指定的数量上。Replicatio

51、n Controller通过查询 Pod Registry的信息来获取 Pod的状态，同时通知调度器来进行调度，执行最终调度，并将调度结果保存至etcd集群里。Endpoints RegistryEndpoint Registry负责对Service的Endpoin信息进行收集，然后将结果汇集到 Etcd集群里去。 同时 Endpoint Registry 属于 Controller Manager 的一部分，是一种特殊的 Controller, Kubernetes 在收集信息的同时，还会对收集到的信息进行分析。确保 Service和Pod总是动态的关联到 一起的，并且关联正确。当然，根据设

52、计，可以将不同的Service绑定到不同的Pod上，于是这个实体也可以做 Create Get、List、Update Delete以及watch操作。3.3.6Binding RegistryBinding Registry 执行的是绑定 Pod 和 Pods 所在的 Minion, Scheduler 会对 Binding Registry 操 作，然后将 Pod绑定到一个 Minion。但是，需要注意的是，这个 Binding Registry是一个 Write-Only的对象，所有操作里只有Create可以使用，否则会引起错误。因此，为了屏蔽这种可能的错误风险。在API层面禁止了这种操

53、作，而改为由 Scheduler自动操纵。3.4 SchedulerScheduler是Kubernetes集群上的调度程序，位于 Master上，总体负责收集、统计分析 Kubernetes集群中所有 Minion的资源负载情况，然后以此为依据通知Replication Controller将新建的Pod发送到可用的Kubernetes集群节点上去。由于每个Minion上前资源是有限的， 一旦这些资源被分配给了某个Pod,那么部分资源就称之为“Ordered；已经被预定了。除非这些持有资源的Pod被删除或者意外退出，其他的Pod便不能再获取到这部分已经被分配完的资源了。因此，需要一个专门的算

54、法来维持Kubernetes集群中所有的Minion的资源总在用户预先规定的负载线以下（超过的话可能会触发运维上的报警）。图 3- 3 Scheduler I/O 图Scheduler关注的是Pod的调度，其余 Pod的对对应关系图 2-2, Scheduler调度器的输入是 待调度Pod和可用的Minion列表，输出是应用调度算法从可用的Minion列表中选择的一个最优的用于绑定待调度Pod的Minion。所以Scheduler会实时监控 Kubernetes集群上所有未分发出去的Pod。将所有Pod排入一个队列之中，然后依次的取未生成完毕的Pod。并将已经取出的Pod状态标记为Pendin

55、g,即等待调度。同时，Scheduler还会实时监控集群上所有 运行中的Pod, Scheduler会根据这些 Pod的运行状态，已经资源消耗情况，去查找同时满 足剩余资源Scheduler收集和分析当前 Kubernetes集群中所有 Minion节点的资源（内存、CPU涣载情况，12然后依此分发新建的Pod至ij Kubernetes集群中可用的节点。由于一旦 Minion节点的资源被分配给Pod,那这些资源就不能再分配给其他Pod,除非这些Pod被删除或者退出，因此，Kubernetes需要分析集群中所有 Minion的资源使用情况，保证分发的工作负载不会超出当 前该Minion节点的可

56、用资源范围。具体来说，Scheduler做以下工作：实时监测Kubernetes集群中未分发的Pod。实时监测Kubernetes集群中所有运行的Pod, Scheduler需要根据这些Pod的资源状况安全地将未分发的 Pod分发到指定的Minion节点上。Scheduler也监测Minion节点信息，由于会频繁查找 Minion节点，Sche duler会缓存一份最新的信息在本地。最后，Scheduler在分发Pod到指定的Minion节点后，会把Pod相关的 信息 Binding 写回 API Server。13第4章设计实现4.1 PodPod共有如下字段如表 4- 1所示这其中，Typ

57、eMeta类型是一个结构体，是所有RES破源的共有属性，Golang通过组合的方式代替继承，因此，这里的一个没有名字的TypeMeta类型可以认为是一种特殊的继承方式，由Pod继承自TypeMetao因此，TypeMeta也可以说是一个对象的元数据。其中包括：资源 类型、对象名、namespace、UUID、版本、创建时间、和资源对象的 API版本等信息。Labels 是创建Pod时资源文件里为 Pod指定的Labels字段。表4- 2 Pod字段表字段类型-TypeMetaRES破源共有属性Labelsmapstringstring本Pod的Labels,可以动态的附加DesiredStat

58、ePodState当前Pod操作完成之后的状态CurrentStatePodState当前Pod的状态NodeSelectormapstringstring是一个 LabelSelector,用于选取和Pod对应的MinionDesiredState和 CurrentState是一对相对的状态，是一个 struct,其中包含了很多属性， DesiredState.ContainerManifest 属性即代表了组成一个Pod 的 Volumes 和 Containers 的配置信息，该属性的内容与 Pod资源文件的 DesiredState.Manifest字段内容等价。CurrentStat

59、e属性则代表该Pod的当前状态，该属性的内容不需要用户填入而是在系统运行过程中被系统 填充进去的。NodeSelector即一个Label Selector,用于为Pod选取Minion ,如果需要可以在 Pod资源文件中设置，该属性在kube-Scheduler调度Pod时会用到。PodState.ContainerManifest可以在创建 Pod的控制文件中声明，其对应表如表 4- 2所示： 其中Containers和Volumes是两个子类列表，其中 Container包含了一系列预定义的资源上 限以及资源标识。其中， Container主要包括容器名、image名、预执行命令、工作目

60、录、需 要挂载的Volume等信息。而 Volumes是预先声明的 Volume的字段，主要用来预申请这些 Volume ,只有当所有的 Volume都可用的时候，Kubernetes才会继续进行调度。表 4- 3ContainerManifest 字段表需文件Version是stringmanifest的版本号是目前必需是v1beta2 的ID是stringManifest的名字是UUID是string唯一标小Pod的ID否只读，由系统自动 填充Containers是Container 要在Pod里启动 的所有容器是RestartPolicy否stringPod的重启策略是包含三种策略：Al