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

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

《基于Docker的开源云主机集群管理平台.docx》由会员分享，可在线阅读，更多相关《基于Docker的开源云主机集群管理平台.docx（64页珍藏版）》请在冰豆网上搜索。

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

本科生毕业论文

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

opensourcecloudclustermanager

platformbasedonDocker

毕业设计（论文）原创承诺书

1．本人承诺：

所呈交的毕业设计（论文）《ActionScript3在Flash游戏制作中的应用》，是认真学习理解学校的《长春理工大学本科毕业设计（论文）工作条例》后，在教师的指导下，保质保量独立地完成了任务书中规定的内容，不弄虚作假，不抄袭别人的工作内容。

2．本人在毕业设计（论文）中引用他人的观点和研究成果，均在文中加以注释或以参考文献形式列出，对本文的研究工作做出重要贡献的个人和集体均已在文中注明。

3．在毕业设计（论文）中对侵犯任何方面知识产权的行为，由本人承担相应的法律责任。

4．本人完全了解学校关于保存、使用毕业设计（论文）的规定，即：

按照学校要求提交论文和相关材料的印刷本和电子版本；同意学校保留毕业设计（论文）的复印件和电子版本，允许被查阅和借阅；学校可以采用影印、缩印或其他复制手段保存毕业设计（论文），可以公布其中的全部或部分内容。

以上承诺的法律结果将完全由本人承担！

作者签名：

年月日

摘要

Docker日益火爆的今天，本次设计对其网络化和集群化能力做出了一个尝试。

并开发了Kubernetes用来搭建了一个集群管控程序。

本文就其的主要部件的设计的分析和具体实现的设计详细描述了容器的大规模化之后应该去完善的工作。

在整个体系中，本设计将容器升级划分成了一个一个的Pod，并将其作为最小的调度单元。

解除了集群管理程序和Docker程序的耦合。

同时，通过ETCD集群做全局索引系统，利用其实现的Raft算法带来的集群写一致性，进而保证了整个系统的一致性。

同时，为互联网与Pod之间增加了一层访问中间控制层，解决了传统软件服务发现和流量负载均衡的问题。

但是，对于DNS的支持并未达到理想的程度。

最后，利用自建的机制解决了服务的动态扩容难题，为快速部署服务提供了一个简单而可行的方案。

关键字：

容器集群云计算微服务

Abstract

Dockerincreasinglypopulartoday,wemadeanattemptonitsnetworkclusteringcapabilities.AndthedevelopmentofKubernetestobuildaclustercontrolprogram.Thisarticledescribesindetailthescaleofwhatweshoulddoafterworkontheanalysisofthecontainermainpartofthedesignandimplementationofthedesign.

Inthewholesystem,wewillupgradethecontainerisdividedintoaoneofthePod,andasthesmallestdispatchunit.DecoupledclustermanagementproceduresandDockerprogram.Meanwhile,globalindexesdoETCDclustersystemthatusesRaftbringitsimplementationalgorithmclusterswriteconsistency,thusensuringconsistencythroughoutthesystem.Atthesametime,wewilladdanotherlayerofaccesscontrollayerintermediatebetweentheInternetandPod,tosolvethetraditionalsoftwareServicediscoveryandtrafficloadbalance.However,supportforDNSdidnotreachthedesiredlevel.Finally,weuseself-builtmechanismtosolvetheproblemofdynamicexpansionofServicesforrapiddeploymentServicesprovideasimpleandworkablesolution.

Keywords:

Container;Cluster;CloudComputing;Micro-Service

目录

摘要I

AbstractII

目录III

第1章绪论1

1.1课题研究的背景及意义1

1.1.1提高资源利用率1

1.1.2服务的动态扩容和持续集成1

1.2国内外研究现状2

1.2.1.CasS平台2

1.2.2.容器VS虚拟机——商用为主2

1.2.3微服务化3

1.3主要研究内容4

1.4论文组织结构4

第2章总体设计5

2.1功能设计5

2.1.1Minion节点组件5

2.1.2Master节点组件6

2.2基本概念7

2.2.1Pod7

2.2.2Service9

2.2.3ReplicationController9

2.2.4Label9

第3章详细设计11

3.1Master节点11

3.2Kubectl11

3.3APIServer11

3.3.1MinionRegistry13

3.3.2PodRegistry13

3.3.3ServiceRegistry13

3.3.4ControllerRegistry14

3.3.5EndpointsRegistry14

3.3.6BindingRegistry14

3.4Scheduler15

第4章设计实现17

4.1Pod17

4.1.1Volume18

4.1.2容器通信20

4.2ReplicationController20

4.2.1RestartPolicy和ReplicationController21

4.2.2ReplicationController的工作机制22

4.2.3ReplicationController的应用场景23

4.3Service25

4.3.1工作机制25

4.3.2数据结构定义26

4.3.3服务发现26

4.3.4HeadlessService28

4.3.5入口地址和外部可路由性28

4.3.6避免端口冲突29

4.3.7Service入口29

4.3.8存在的的不足30

4.4APIServer30

4.4.1设计目的31

4.4.2资源对象的RESTful接口31

4.4.3API操作的原子性32

4.4.4APIServer流程33

第5章调度和网络35

5.1网络35

5.1.1网络模型35

5.1.2具体实现35

5.1.3其他工作35

5.2Minion管理37

5.2.1Minion发现37

5.2.2Minion管控流程37

5.3调度器38

5.3.1调度策略38

5.3.2例1：

Predicates.PodFitsPorts39

5.3.3例2：

Priorities.LeastRequestedPriority40

5.3.4缓存模型41

第6章实战部署42

5.1环境准备42

5.1.1下载软件包42

5.1.2下载源码包进行编译42

5.2upstart脚本42

5.3安装kubernetes客户端程序43

第7章总结44

参考文献45

致谢46

附录47

第1章绪论

1.1课题研究的背景及意义

1.1.1提高资源利用率

现行的网络服务器集群，有很大的一部分都是由巨量的服务器组成的，这些服务器根据资源的占用情况可以被分为IO密集型、计算密集型、存储型、图形工作站、特殊用型（例如堡垒机，基础交换机等）。

事实上，对于IO密集型的机器，其计算能力会产生部分冗余，这个无法避免，甚至在LXC、KVM等轻量级虚拟化技术诞生之前都无法利用他们，造成了很大的资源浪费[1]。

同样道理，计算密集型的IO、存储往往都是处于无法利用的状态。

因此，对于，大规模应用来说一门轻量级的资源利用技术是极其迫切的需要[2]。

在Docker之前，便有一些轻量级虚拟化技术[3]了，事实上，Docker本身也是基于LXC[4]做为基础建立的（0.8版本之后改用自己编译的libcontainer，本质还是LXC）。

但是这些技术都有一个致命的缺陷，就是不支持冷备，所有的操作都是热操作。

全热操作导致的一个巨大的问题就是无法进行快速的部署、启动和迁移。

而Docker创新的采用了image和container分离的技术，并用版本控制系统来进行标记，让虚机迁移、部署、启动这个过程变得异常简单。

当然，这样做带来的一点负面影响就是在编写虚机的时候较为麻烦，但是完全值得。

1.1.2服务的动态扩容和持续集成

服务，尤其是面向互联网的服务，始终面临着巨量用户的考验，随时可能到来，多大的量都可能。

例如春节时候的12306、例如双十一的阿里巴巴，其各种资源都达到了瓶颈，无论是计算资源还是网络资源。

而服务的高可用最简单的方法就是提升服务器的数量。

但是如何快速接入服务，阿里巴巴会在每次购物节到来之前提前一个月安排专人对服务器进行扩容和补充，购物节结束之后又会进行服务器的删减。

因为在平时维持这么巨量的服务器是完全没有意义的。

这是阿里巴巴的做法，但是广大公司并没有阿里巴巴那样的财力物力。

2015年初，一个叫足迹的App火了，但是她们连CEO加一起团队成员才8个人，面对的却是一天暴涨的400万用户量，服务器瞬间瘫痪，App彻底失效。

她们除了给所有用户推送了一条道歉信之外什么都做不了，服务器有，但是就是提供不了服务。

同样的例子也发生在了今年春节联欢晚会，但是却收到了不同的效果，其中容器技术贡献巨大。

羊年春晚有两个热点，一个是巨量的网络春晚收视率，另一个就是微信红包。

其中，为了推送巨量的网络视频流，春晚后勤便采用了Docker的动态扩容技术，在高峰到来之前迅速部署了巨量的容器，在不同的服务器之间进行轮询，并且自动发现并重启down掉的容器。

正是这样可怕的动态扩容能力，保证了春晚网络直播的顺利进行。

就我所实习的公司（七牛网络信息技术有限公司，以下简称七牛）来说，Docker已经成为七牛持续集成部署的一部分了。

七牛将其用在了图片处理、ufop、MEMPG处理等业务上，每一个image服务都封装成一个container，大大提到了image服务的处理能力和持续集成能力和监控能力[5]，每次部署机器，只需要拉取指定的二进制压缩包即可，简单方便。

1.2国内外研究现状

1.2.1.CasS平台

Docker原本是DotCloud公司的一个主要项目，后来被开源出来，而DotCloud公司提供的正是CasS云。

CasS即Container-as-Service的简写，对于这样的服务，编程人员可能并不了解，但是其实GoogleComputeEngine，SinaAppEngine，BaiduAppEngine2.0，阿里巴巴ECS云服务器，CloudFoundry（部分采用）等技术都是提供的CasS服务。

但是对外表现来说，阿里巴巴的ECS更像一个PasS，但是其实底层还是用的容器技术（当然不可能是Docker）。

国内，完全基于Docker的CasS公司DaoCloud也于前日正式对外提供服务。

1.2.2.容器VS虚拟机——商用为主

虚拟机技术，从最开始的分时系统，到后来的各种VM的乱战到Xen的统一服务器端江湖[6]，直到现在KVM流行。

“现在都是KVM[7]，如果新一点的，就玩Container了。

”计算机世界分为两条线，计算和存储，虚拟化属于计算这条线，而虚拟化又分为两条，硬件虚拟化和软件虚拟化，硬件虚拟化从IBM时代就开始了。

1999年，一个叫VMwareWorkstation的公司流行了一段时间，这个公司就是现在的虚拟化巨头VMware。

但是前几年被卖给EMC了，现在连EMC都自身难保。

相较之，容器技术的概念也被提出很久了，根据国外的研究成果[8]，之所以一致未曾实现，主要原因还是因为容器技术的不成熟。

因为是进程级别虚拟化，其隔离系统总不会像硬件级别虚拟化一样密不透风，LinuxKernel上关于LXC的SecurityAnnounce有五十多个，但是没人敢去修，因为这个东西是牵一发而动全身的。

从IBM360到VMware的流行，国外花了近二十年时间才让硬件虚拟化技术变得为商业所接受。

同样的，容器技术要走进真正的商用还需要很长的一段路[9]。

1.2.3微服务化

云计算在当计算机科学高度发展的今天已经越来越多参与了我们正常的生产生活。

同时，提供云计算服务的厂商也如雨后春笋般冒了出来。

与传统的IT产业公司不同的是，云计算时代的互联网公司，作为云计算服务的提供者，越来越扮演着幕后的角色。

典型的云计算时代，当你打开手机，点开某个门户网站，浏览一段视频，与人沟通交流，这一切的一切都是由巨量的服务支撑起来的。

同样的，每一个服务都尽量做到轻量，简单。

这也正是UNIX的设计哲学，这样的服务被称之为“微服务”。

将服务拆散开，以链接、api、转发、负载均衡等方式对外提供，在提供商这里，拆小了业务逻辑，将原先生产一条飞机的难度降低到了生产一颗螺丝钉上去。

对于开发者和消费者，微服务提供了更多的可能和更强大的兼容性。

然而，抛开了完整的系统，而转向微服务的我们，该如何保证微服务的稳定和高可用呢？

云计算就像一个池子，服务就像池子里的水，正常情况下，服务从提供商手里流出，保障其基础设施的运转良好。

但是当你的池子不够大呢？

扩容？

是个好办法。

但是这需要时间和成本的开销，而且运维反应速度慢和快也是衡量一个公司服务能力的重要标准。

因此，在云计算时代，无论企业还是个人，都需要一个轻便，易于部署，快速迁移，快速启动的环境设置技术来支持服务启用、备份、容灾、迁移。

这个技术，就是Docker。

Docker是一个容器管理程序，由Golang编写，采用LXC做BackEnd，提供了容器的快速启动，快速部署，版本控制等方法。

Docker就像一个集装箱，把服务需要的环境都封装在里面，想用的时候直接拿集装箱走并使用就可以。

省去了很多无用而且缓慢的部署脚本，并且，其image的概念的提出，为冷备Docker提供了一个简单而且方便的途径。

国内目前已经有学者开始对微服务化的可行性做了研究，并且，Docker也开始和传统的云计算平台结合[10]产生了奇妙的变化。

1.3主要研究内容

本文主要进行了如下的研究：

（1）对Kubernetes的设计和架构进行深度解析，分析各个组件的设计目的和具体实现

（2）提供一个简单、易用的自动化部署、持续集成、滚动升级、灰度、多版本追踪发布方案。

让Docker能够更加简单的在生产环境中应用。

（3）提供一个可靠的横向扩展架构，搭建一个无状态易扩展的高可用服务器集群，自动实现负载均衡和动态扩容。

（4）研究虚网络和SDN网络的设计模型，并对其进行分析。

以及在Kubernetes中的应用和实战。

（5）研究集群一致算法Raft[11]，分析Kubernetes的集群的一致性。

1.4论文组织结构

本次论文共分三个大部分：

总体设计、细节设计、实战部署。

其中，第1章~第2章，主要讲述的是Kubernetes系统的架构和设计，以及一些特化的概念。

第3章~第5章是Kubernetes系统的详细设计和技术细节。

本部分从Master节点开始，逐步分析Kubernetes系统设计实践中出现的问题，并提出自己的解决方案。

展示其各个组件的实现细节和技术上的缺陷。

第6章是Kubernetes的实战部署，在一台Ubuntu14.04主机上搭建单节点的Kubernetes集群，并检测其安装结果。

第2章总体设计

2.1功能设计

本系统名叫Kubernetes，是Google公司推出的一款类似于Borg的开源的容器管理程序。

其总体设计图图2-1：

图2-1Kubernetes网络图

对于Kubernetes，其详细组件图如图2-2：

2.1.1Minion节点组件

在每个对外提供服务的节点（对于整个集群来说，这些节点可以称之为minion）上，Kubernetes有如下组件：

kubelet：

管理Docker本身，与BackEnd通讯的程序，其本身就是一个守护进程，伴随着Docker一起启动。

kube-Proxy：

代理程序，对外提供Docker机器上的服务的网络转发，对内则进行端口映射和隧道压缩，将网络流转发致各个可用的服务容器上。

图2-2Kubernetes组件图

2.1.2Master节点组件

对于master节点，共有三个主要组件：

kube-apiserver:

本组件是Kubernetes系统的主要组件，对外，apiserver提供开放的端口，即，提供服务；对内，apiserver维持一个对于ETCD系统的RESTful持久化对象，以便于同步集群的信息。

对整个集群，他是集群控制的入口，提供一个RESTful的api来对集群进行控制。

kube-scheduler:

Kubernetes的调度程序，负责调度整个集群的资源，为部署容器提供自动化的执行方案。

kube-controller-manager:

Kubernetes的执行各种controller的程序，目前controller共有两类，分别是：

●endpoint-controller：

负责关联Kubernetes的服务和容器映射的正确性。

●replication-controller：

负责定义容器的数量处在正确的值，即，关闭超过数量的容器，增加因为资源不足，意外宕机等原因而减少的容器的数量。

etcd:

etcd是一个由Coreos公司实现的简易k-v分布式数据存储系统，采用raft算法保证集群一致性。

Kubernetes用它来实现了一个globalindex系统，从而达到全局的一致性保证。

这里面主要存储的是Kubernetes系统的所有Label。

2.2基本概念

2.2.1Pod

Pod，是Kubernetes的一个基本的调度单位，一个Pod对应的一组DockerContainer构成的容器组，在同一个Pod里，DockerVolume可以共享的挂载在同Pod中的所有DockerContainer中。

如下图2-3。

在逻辑上，Pod的提出结束了自己管理Docker容器的分立的状态，Pod建立了一个“逻辑虚拟机”的模型，在这个虚拟机里，每个Docker的Container相当于传统虚拟机的一个进程。

而共享的Volume则构成了进程之间共同访问的文件资源。

与正常的DockerContainer一样，Pod的生命周期，相对于整个集群来说是不持久的。

同时，Pod给Kubernetes提供了一个程序上的解耦，因为Kubernetes底层是面向容器的，但不一定是只支持Docker的。

因此，为了与Docker解除绑定，也为了能定义一个更准确的逻辑模型，Kubernetes启用了Pod的概念。

在Pod被引入之前，我曾经尝试过在一个DockerContainer同时启用多个应用。

但是后来发现这样做有其固有的缺陷：

（1）多个应用同时部署在一个DockerContainer之中，会增加不必要的软件的依赖，每当其中某个依赖的软件进行变更的时候，便不得不重建整个DockerContainer。

而当DockerContainer的数量、大小达到一定规模的时候，这样做无疑会带来巨量的系统负担。

（2）用户不必运行自己的进程管理程序，多个进程之间也无需考虑进程信号量或退出码扩散等问题。

（3）将多个应用部署到同一个容器之中，将不可避免的加重容器，这里所说的加重是从启动时间、监控难度、调度难度等多个方面来考量的。

图2-3Pod结构图

而引入Pod带来的了两点显著的改善：

（1）资源共享和容器通信

Pod的引入将多个不同的为多个DockerContainer之间划分了一个界限，同一个Pod内部的容器共享同样的networknamespace、IP已经端口资源，能通过UDS进行通信。

在这样一个扁平化的虚网络里，每一个Pod都有拥有其独立的IP地址，通过该IP地址，Pod之内的容器就能正常的与其他Minion、逻辑虚拟机、或者容器进行直接通信。

同样的，共享存储卷（Volume）的存在，方便了同一个Pod之内的各个容器进行共享数据，以及避免了数据在容器的重建重启等过程中的丢失，保证了数据的一致性和安全性。

（2）易于管理

和原生的DockerAPI不同，Kubernetes对底层的API进行封装和抽象，提供了一个方便而简易的接口，基本上所有的操作都可以通过一个JSON（YAML）文件来定义，简化了应用部署和管理的流程。

Pod可以看成是管理和扩容的基本单位，这样，Docker容器的逻辑划分，Fate-Sharing，拷贝协同，主机管理，资源共享以及依赖管理都可以自动化处理。

作为调度的基本单位，Kubernetes保证在整个系统里，Pod的数量都是恒定的，和Pod创建的时候给定的参数相同。

当然，类似的，用户也可以动态的调整Pod的数量，这个过程完全是由Kubernetes自动调度完成的。

当然，Pod的生命周期相对于集群来说是短暂的。

他的行为被ReplicationController所驱动。

那么，Pod是何时被创建，销毁，迁移是无法预测到的，每当给Pod绑定一个IP地址时候。

用户是无法确定这个IP可以被持久的，持续的访问。

即，对应的IP地址和端口是否还能存在。

为了解决这个问题，Kubernetes引入了Services的概念。

2.2.2Service

与Pod相对，Service对应的是对外的概念。

整个集群可以抽象成多个不同的服务，而每个服务则由一定数量的Pod组成。

目前的Kubernetes采用的是iptables的nat网桥转发的功能实现的这个转发。

生成kube-proxy的数据流，连接api-server和client上kube-proxy绑定的随机端口。

对于集群的使用者来说，链接的就是Kubernetes的Service所提供的虚拟IP和端口，而其内部采用轮询或者随机访问的算法来平衡各个Pod之间的压力。

2.2.3ReplicationController

ReplicationController是Kubernetes集群最有用的功能，它保证Kubernetes的集群里总能保持正确数量的Pod。

在互联网环境下，为了保证服务的高可用性，服务提供者总是提供一通数量的的可执行的副本来提供服务。

而当集群里副本数量低于规定值时，ReplicationController会从模板中创建或者直接复制现有Pod来创建