基于docker的开源云主机集群管理平台本科毕业论文(编辑修改稿)

基于docker的开源云主机集群管理平台本科毕业论文(编辑修改稿)内容摘要：

是其实底层还是用的容器技术（当然不可能是 Docker）。 国内，完全基于 Docker 的 CasS 公司 DaoCloud 也于前日正式对外提供服务。 . 容器 VS 虚拟机 —— 商用为主 虚拟机技术，从最开始的分时系统，到后来的各种 VM 的乱战到 Xen 的统一服务器端江湖 [6]，直到现在 KVM 流行。 “ 现在都是 KVM[7]，如果新一点的，就玩 Container 了。 ”计算机世界分为两条线，计算和存储，虚拟化属于计算这条线，而虚拟化又分为两条，硬件虚拟化和软件虚拟化，硬件虚拟化从 IBM 时代就开始了。 1999 年，一个叫 VMware Workstation 的公司流行了一段时间，这个公司就是现在的虚拟化巨头 VMware。 但是前几年被卖给 EMC 了，现在连 EMC 都自身难保。 相较之，容器技术的概念也被提出很久了，根据国外的研究成果 [8]，之所以一致未曾实现，主要原因还是因为容器技术的不成熟。 因为是进程级别虚拟化，其隔离系统总不会像硬件级别虚拟化一样密不透风， Linux Kernel 上关于 LXC的 Security Announce 有五十多个，但是没人敢去修，因为这个东西是牵一发而动全身的。 从 IBM 360 到 VMware 的流行，国外花了近二十年时间才让硬件虚长春理工大学本科毕业设计 3 拟化技术变得为商业所接受。 同样的，容器技术要走进真正的商用还需要很长的一段路 [9]。 微服务化 云计算在当计算机科 学高度发展的今天已经越来越多参与了我们正常的生产生活。 同时，提供云计算服务的厂商也如雨后春笋般冒了出来。 与传统的 IT产业公司不同的是，云计算时代的互联网公司，作为云计算服务的提供者，越来越扮演着幕后的角色。 典型的云计算时代，当你打开手机，点开某个门户网站，浏览一段视频，与人沟通交流，这一切的一切都是由巨量的服务支撑起来的。 同样的，每一个服务都尽量做到轻量，简单。 这也正是 UNIX 的设计哲学 1，这样的服务被称之为 ―微服务 ‖。 将服务拆散开，以链接、 api、转发、负载均衡等方式对外提供，在提供商这里，拆小了业务逻 辑，将原先生产一条飞机的难度降低到了生产一颗螺丝钉上去。 对于开发者和消费者，微服务提供了更多的可能和更强大的兼容性。 然而，抛开了完整的系统，而转向微服务的我们，该如何保证微服务的稳定和高可用呢。 云计算就像一个池子，服务就像池子里的水，正常情况下，服务从提供商手里流出，保障其基础设施的运转良好。 但是当你的池子不够大呢。 扩容。 是个好办法。 但是这需要时间和成本的开销，而且运维反应速度慢和快也是衡量一个公司服务能力的重要标准。 因此，在云计算时代，无论企业还是个人，都需要一个轻便，易于部署，快速迁移，快速启动的环境设置技术来支持服务启用、备份、容灾、迁移。 这个技术，就是 Docker。 Docker 是一个容器管理程序，由 Golang 编写，采用 LXC 做 BackEnd，提供了容器的快速启动，快速部署，版本控制等方法。 Docker 就像一个集装箱，把服务需要的环境都封装在里面，想用的时候直接拿集装箱走并使用就可以。 省去了很多无用而且缓慢的部署脚本，并且，其 image 的概念的提出，为冷备 Docker 提供了一个简单而且方便的途径。 国内目前已经有学者开始对微服务化的可行性做了研究，并且， Docker 也开始和传统的云计算平台结合 [10]产生了奇妙的变化。 主要研究内容 本文主要进行了如下的研究： 1 kISS:keep it simple amp。 stupid 长春理工大学本科毕业设计 4 （ 1） 对 Kuberes 的设计和架构进行深度解析，分析各个组件的设计目的和具体实 现 （ 2） 提供一个简单、易用的自动化部署、持续集成、滚动升级、灰度、多版本追踪发布方案。 让 Docker 能够更加简单的在生产环境中应用。 （ 3） 提供一个可靠的横向扩展架构，搭建一个无状态易扩展的高可用服务器集群，自动实现负载均衡和动态扩容。 （ 4） 研究虚网络和 SDN 网络的设计模型，并对其进行分析。 以及在 Kuberes 中的应用和实战。 （ 5） 研究集群一致算法 Raft[11]，分析 Kuberes 的集群的一致性。 论文组织结构 本次论文共分三个大部分：总体设计、细节设计、实战部署。 其中，第 1 章 ~第 2 章，主要讲述的是 Kuberes 系统的架构和设计，以及一些特化的概念。 第 3 章 ~第 5 章是 Kuberes 系统的详细设计和技术细节。 本部分从 Master节点开始，逐步分析 Kuberes 系统设计实践中出现的问题，并提出自己的解决方案。 展示其各个组件的实现细节和技术上的缺陷。 第 6 章是 Kuberes 的实战部署，在一台 Ubuntu 主机上搭建单节点的 Kuberes 集群，并检测其安装结果。 长春理工大学本科毕业设计 5 第 2 章 总体设计 功能设计 本系统名叫 Kuberes，是 Google 公司推出的一款类似于 B2的开源的容器管理程序。 其总体设计图图 2 1： API ServerETCD 集群Controller ManagerScheduler核心交换机Minion 集群 图 2 1 Kuberes 网络图 对于 Kuberes，其详细组件图如图 2 2： Minion 节点组件 在每个对外提供服务的节点（对于整个集群来说，这些节点可以称之为 minion）上， Kuberes 有如下组件： kubelet：管理 Docker 本身，与 BackEnd 通讯的程序，其本身就是一个守护进程，伴随着 Docker 一起启动。 2 B 是 Google 公司内部使用的服务部署和动态迁移程序，未开源 长春理工大学本科毕业设计 6 kubeProxy：代理程序，对外提供 Docker 机器上的服务的网络转发，对内则进行端口映射和隧道压缩，将网络流转发致各个可用的服务容器上。 图 2 2 Kuberes 组件图 Master 节点组件 对于 master 节点，共有三个主要组件： kubeapiserver : 本组件是 Kuberes 系统的主要组件，对外， apiserver 提供开放的端口，即，提供服务；对内， apiserver 维持一个对于 ETCD 系统的 RESTful 持久化 对象，以便于同步集群的信息。 对整个集群，他是集群控制的入口，提供一个 RESTful 的 api 来对集群进行控制。 kubescheduler: Kuberes 的调度程序，负责调度整个集群的资源，为部署容器提供自动化的执行方案 3。 kubecontrollermanager: Kuberes 的执行各种 controller 的程序，目前 controller 共有两类，分别是：  endpointcontroller ：负责关联 Kuberes 的服务和容器 4映射的正确性。  replicationcontroller ： 负责定义容器的数量处在正确的值，即，关闭超过数量的容器，增加因为资源不足，意外宕机等原因而减少的容器的数 3 这个地方原本是 B 系统最精华的部分，但是限于 Google 公司机密，因此做成了一个简单的服务。 4 当然，这里对于容器并不是 k8s 的最基本调度单位，这里所说的实际上使指的 Service 和 pod 的正确映射关系，关于 k8s 的一些基本概念，将在下一节详细叙述 长春理工大学本科毕业设计 7 量。 etcd : etcd 是一个由 Coreos 公司实现的简易 kv 分布式数据存储系统，采用raft 算法保证集群一致性。 Kuberes 用它来实现了一个 global index 系统，从而达到全局的一致性保证。 这里面主要存储的是 Kuberes 系统的所有 Label。 基本概念 Pod Pod，是 Kuberes 的一个基本的调度单位，一个 Pod 对应的一组 Docker Container 构成的容器组，在同一个 Pod 里， Docker Volume 可以共享的挂载在同Pod 中的所有 Docker Container 中。 如下图 2 3。 在逻辑上， Pod 的提出结束了自己管理 Docker 容器的分立的状态， Pod 建立了一个“逻辑虚拟机 ‖的模型，在这个虚拟机里，每个 Docker 的 Container 相当于传统虚拟机的一个进程。 而共享的 Volume 则构成了进程之间共同访问的文件资源。 与正常的 Docker Container 一样， Pod 的生命周期，相对于整个集群来说是不持久的。 同时， Pod 给 Kuberes 提供了一个程序上的解耦，因为 Kuberes 底层是面向容器的，但不一定是只支持 Docker 的。 因此，为了与 Docker 解除绑定，也为了能定义一个更准确的逻辑模型， Kuberes 启用了 Pod 的概念。 在 Pod 被引入之前，我曾经尝试过在一个 Docker Container 同时启用多个应用。 但是后来发现这样做有其固有的缺陷： （ 1） 多个应用同时部署在一个 Docker Container 之中，会增加不必要的软件的依赖，每当其中某个依赖的软件进行变更的时候，便不得不重建整个 Docker Container。 而当 Docker Container 的数量、大小达到一定规模的时候，这样做无疑会带来巨量的系统负担。 （ 2） 用户不必运行自己的进程管理程序，多个进程之间也无需考虑进程信号量或退出码扩散等问题。 （ 3） 将多个应用部署到同一个容器之中，将不可避免的加重容器，这里所说的加重是从启动时间、监控难度、调度难度等多个方面来考量的。 长春理工大学本科毕业设计 8 R e d is M a s t e r C o n t a in e r 1 R e d is S la v e C o n t a in e r 1P o d 1V o lu m e r e d is 图 2 3 Pod 结构图 而引入 Pod 带来的了两点显著的改善： （ 1） 资源共享和容器通信 Pod 的引入将多个不同的为多个 Docker Container 之间划分了一个界限，同一个 Pod 内部的容器共享同样的 work namespace、 IP 已经端口资源，能通过UDS 进行通信。 在这样一个扁平化的虚网络里，每一个 Pod 都有拥有其独立的 IP 地址，通过该 IP 地址， Pod 之内的容器就能正常的与其他 Minion、逻辑虚拟机、或者容器进行直接通信。 同样的，共享存储卷（ Volume）的存在，方便了同一个 Pod 之内的各个容器进行共享数据，以及避免了数据在容器的重建重启等过程中的丢失，保证 了数据的一致性和安全性。 （ 2） 易于管理 和原生的 Docker API 不同， Kuberes 对底层的 API 进行封装和抽象，提供了一个方便而简易的接口，基本上所有的操作都可以通过一个 JSON（ YAML）文件来定义，简化了应用部署和管理的流程。 Pod 可以看成是管理和扩容的基本单位，这样， Docker 容器的逻辑划分， FateSharing5，拷贝协同，主机管理，资源共享以及依赖管理都可以自动化处理。 作为调度的基本单位， Kuberes 保证在整个系统里， Pod 的数量都是恒定的，和 Pod 创建的时候给定的参数相同。 当然，类似的，用户也可以动态的调整Pod 的数量，这个过程完全是由 Kuberes 自动调度完成的。 当然， Pod 的生命周期相对于集群来说是短暂的。 他的行为被 Replication Controller 所驱动。 那么， 5 参照 Wikipade: 长春理工大学本科毕业设计 9 Pod 是何时被创建，销毁，迁移是无法预测到的，每当给 Pod 绑定一个 IP 地址时候。 用户是无法确定这个 IP 可以被持久的，持续的访问。 即，对应的 IP 地址和端口是否还能存在。 为了解决这个问题， Kuberes 引入了 Services 的概念。 Service 与 Pod 相对， Service 对应的是对外的概念。 整个集群可以抽象成多个不同的服务，而每个服务则由一定数量的 Pod 组成。 目前的 Kuberes 采用的是 iptables 的 nat 网桥转发的功能实现的这个转发。 生成 kubeproxy 的数据流，连接 apiserver 和 client 上 kubeproxy 绑定的随机端口。 对于集群的使用者来说，链接的就是 Kuberes 的 Service 所提供的虚拟 IP和端口，而其内部采用轮询或者随机访问的算法来平衡各个 Pod 之间的压力。 Replication Cont。