基于Docker的开源云主机集群管理平台.docx

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

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

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

4、ngly popular 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

5、of the design.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 cluster

6、s write consistency, 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

7、 desired level.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-Service目录摘要 IAbstract II目录 III第1章绪论 11. 1课题研究的背景及意义 11.1.1 提高资源利用率 11.1.2

8、 服务的动态扩容和持续集成 11.2国内外研究现状 21.2.1.CasS平台 21.2.2. 容器VS虚拟机商用为主 21.2.3 微服务化 31.3 主要研究内容 41.4论文组织结构 4第2章总体设计 52.1功能设计 52.1.1 Minion节点组件 52.1.2 Master节点组件 62.2基本概念 72.2.1 Pod 72.2.2 Service 92.2.3 Replication Controller 92.2.4 Label 9第3章详细设计 113.1 Master节点 113.2 Kubectl 113.3 API Server 113.3.1 Minion Reg

9、istry 133.3.2 Pod Registry 133.3.3 Service Registry 133.3.4 Controller Registry 143.3.5 Endpoints Registry 143.3.6 Binding Registry 143.4 Scheduler 15第4章设计实现 174.1 Pod 174.1.1 Volume 184.1.2 容器通信 204.2 Replication Controller 204.2.1 RestartPolicy和Replication Controller 214.2.2 Replication Controller

10、的工作机制 224.2.3 Replication Controller的应用场景 234.3 Service 254.3.1 工作机制 254.3.2 数据结构定义 264.3.3 服务发现 264.3.4 Headless Service 284.3.5 入口地址和外部可路由性 284.3.6 避免端口冲突 294.3.7 Service入口 294.3.8 存在的的不足 304.4 API Server 304.4.1设计目的 314.4.2资源对象的RESTful接口 314.4.3 API操作的原子性 324.4.4 API Server流程 33第5章调度和网络 355.1 网络

11、355.1.1 网络模型 355.1.2 具体实现 355.1.3 其他工作 355.2 Minion管理 375.2.1 Minion发现 375.2.2 Minion管控流程 375.3 调度器 385.3.1 调度策略 385.3.2 例1：Predicates.PodFitsPorts 395.3.3 例2：Priorities.LeastRequestedPriority 405.3.4 缓存模型 41第6章实战部署 425.1 环境准备 425.1.1 下载软件包 425.1.2 下载源码包进行编译 425.2 upstart脚本 425.3安装kubernetes客户端程序 43

12、第7章总结 44参考文献 45致谢 46附录 47第1章绪论1. 1课题研究的背景及意义1.1.1 提高资源利用率现行的网络服务器集群，有很大的一部分都是由巨量的服务器组成的，这些服务器根据资源的占用情况可以被分为IO密集型、计算密集型、存储型、图形工作站、特殊用型（例如堡垒机，基础交换机等）。事实上，对于IO密集型的机器，其计算能力会产生部分冗余，这个无法避免，甚至在LXC、KVM等轻量级虚拟化技术诞生之前都无法利用他们，造成了很大的资源浪费1。同样道理，计算密集型的IO、存储往往都是处于无法利用的状态。因此，对于，大规模应用来说一门轻量级的资源利用技术是极其迫切的需要2。在Docker之前

13、，便有一些轻量级虚拟化技术3了，事实上，Docker本身也是基于LXC4做为基础建立的(0.8版本之后改用自己编译的libcontainer，本质还是LXC)。但是这些技术都有一个致命的缺陷，就是不支持冷备，所有的操作都是热操作。全热操作导致的一个巨大的问题就是无法进行快速的部署、启动和迁移。而Docker创新的采用了image和container分离的技术，并用版本控制系统来进行标记，让虚机迁移、部署、启动这个过程变得异常简单。当然，这样做带来的一点负面影响就是在编写虚机的时候较为麻烦，但是完全值得。1.1.2 服务的动态扩容和持续集成服务，尤其是面向互联网的服务，始终面临着巨量用户的考验，

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

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

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

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

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

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

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

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

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

23、ernetes系统设计实践中出现的问题，并提出自己的解决方案。展示其各个组件的实现细节和技术上的缺陷。第6章是Kubernetes的实战部署，在一台Ubuntu 14.04主机上搭建单节点的Kubernetes集群，并检测其安装结果。第2章总体设计2.1功能设计本系统名叫Kubernetes，是Google公司推出的一款类似于Borg的开源的容器管理程序。其总体设计图图2- 1：图2- 1 Kubernetes网络图对于Kubernetes，其详细组件图如图2- 2：2.1.1 Minion节点组件在每个对外提供服务的节点（对于整个集群来说，这些节点可以称之为minion）上，Kubernet

24、es有如下组件：kubelet：管理Docker本身，与BackEnd通讯的程序，其本身就是一个守护进程，伴随着Docker一起启动。kube-Proxy：代理程序，对外提供Docker机器上的服务的网络转发，对内则进行端口映射和隧道压缩，将网络流转发致各个可用的服务容器上。图2- 2 Kubernetes组件图2.1.2 Master节点组件对于master节点，共有三个主要组件：kube-apiserver:本组件是Kubernetes系统的主要组件，对外，apiserver提供开放的端口，即，提供服务；对内，apiserver维持一个对于ETCD系统的RESTful持久化对象，以便于同步

25、集群的信息。对整个集群，他是集群控制的入口，提供一个RESTful的api来对集群进行控制。kube-scheduler: Kubernetes的调度程序，负责调度整个集群的资源，为部署容器提供自动化的执行方案。kube-controller-manager: Kubernetes的执行各种controller的程序，目前controller共有两类，分别是： endpoint-controller ：负责关联Kubernetes的服务和容器映射的正确性。 replication-controller：负责定义容器的数量处在正确的值，即，关闭超过数量的容器，增加因为资源不足，意外宕机等原因而减

26、少的容器的数量。etcd : etcd是一个由Coreos公司实现的简易k-v分布式数据存储系统，采用raft算法保证集群一致性。Kubernetes用它来实现了一个global index系统，从而达到全局的一致性保证。这里面主要存储的是Kubernetes系统的所有Label。2.2基本概念2.2.1 PodPod，是Kubernetes的一个基本的调度单位，一个Pod对应的一组Docker Container构成的容器组，在同一个Pod里，Docker Volume可以共享的挂载在同Pod中的所有Docker Container中。如下图2- 3。在逻辑上，Pod的提出结束了自己管理Do

27、cker容器的分立的状态，Pod建立了一个“逻辑虚拟机”的模型，在这个虚拟机里，每个Docker 的Container相当于传统虚拟机的一个进程。而共享的Volume则构成了进程之间共同访问的文件资源。与正常的Docker Container一样，Pod的生命周期，相对于整个集群来说是不持久的。同时，Pod给Kubernetes提供了一个程序上的解耦，因为Kubernetes底层是面向容器的，但不一定是只支持Docker的。因此，为了与Docker解除绑定，也为了能定义一个更准确的逻辑模型，Kubernetes启用了Pod的概念。在Pod被引入之前，我曾经尝试过在一个Docker Contai

28、ner同时启用多个应用。但是后来发现这样做有其固有的缺陷：（1） 多个应用同时部署在一个Docker Container之中，会增加不必要的软件的依赖，每当其中某个依赖的软件进行变更的时候，便不得不重建整个Docker Container。而当Docker Container的数量、大小达到一定规模的时候，这样做无疑会带来巨量的系统负担。（2） 用户不必运行自己的进程管理程序，多个进程之间也无需考虑进程信号量或退出码扩散等问题。（3） 将多个应用部署到同一个容器之中，将不可避免的加重容器，这里所说的加重是从启动时间、监控难度、调度难度等多个方面来考量的。图2- 3 Pod结构图而引入Pod带来

29、的了两点显著的改善：（1） 资源共享和容器通信Pod的引入将多个不同的为多个Docker Container之间划分了一个界限，同一个Pod内部的容器共享同样的network namespace、IP已经端口资源，能通过UDS进行通信。在这样一个扁平化的虚网络里，每一个Pod都有拥有其独立的IP地址，通过该IP地址，Pod之内的容器就能正常的与其他Minion、逻辑虚拟机、或者容器进行直接通信。同样的，共享存储卷（Volume）的存在，方便了同一个Pod之内的各个容器进行共享数据，以及避免了数据在容器的重建重启等过程中的丢失，保证了数据的一致性和安全性。（2） 易于管理和原生的Docker A

30、PI不同，Kubernetes对底层的API进行封装和抽象，提供了一个方便而简易的接口，基本上所有的操作都可以通过一个JSON（YAML）文件来定义，简化了应用部署和管理的流程。Pod可以看成是管理和扩容的基本单位，这样，Docker容器的逻辑划分，Fate-Sharing，拷贝协同，主机管理，资源共享以及依赖管理都可以自动化处理。作为调度的基本单位，Kubernetes保证在整个系统里，Pod的数量都是恒定的，和Pod创建的时候给定的参数相同。当然，类似的，用户也可以动态的调整Pod的数量，这个过程完全是由Kubernetes自动调度完成的。当然，Pod的生命周期相对于集群来说是短暂的。他的

31、行为被Replication Controller所驱动。那么，Pod是何时被创建，销毁，迁移是无法预测到的，每当给Pod绑定一个IP地址时候。用户是无法确定这个IP可以被持久的，持续的访问。即，对应的IP地址和端口是否还能存在。为了解决这个问题，Kubernetes引入了Services的概念。2.2.2 Service与Pod相对，Service对应的是对外的概念。整个集群可以抽象成多个不同的服务，而每个服务则由一定数量的Pod组成。目前的Kubernetes采用的是iptables的nat网桥转发的功能实现的这个转发。生成kube-proxy的数据流，连接api-server和clien

32、t上kube-proxy绑定的随机端口。对于集群的使用者来说，链接的就是Kubernetes的Service所提供的虚拟IP和端口，而其内部采用轮询或者随机访问的算法来平衡各个Pod之间的压力。2.2.3 Replication ControllerReplication Controller是Kubernetes集群最有用的功能，它保证Kubernetes的集群里总能保持正确数量的Pod。在互联网环境下，为了保证服务的高可用性，服务提供者总是提供一通数量的的可执行的副本来提供服务。而当集群里副本数量低于规定值时，Replication Controller会从模板中创建或者直接复制现有Pod来创建