Dock的生态开源技术(Etcd&Machine&Compose&Swarm&Mesos&Kubernetes)

bingtuag

Etcd
　　CoreOS公司开源的高可用分布式键值数据库Etcd，该项目已经被广泛应用到分布式系统的一致性实现和服务发现中,基于Go语言实现。
　　Etcd就是专门为集群环境设计，可以很好地实现数据一致性，提供集群节点状态管理和服务自动发现等（类似ZooKeeper）。
　　Etcd在进行设计的时候重点考虑了下面四个要素：

• 简单：支持REST风格的HTTP+JSON API；
  
• 安全：支持HTTPS方式的访问；
  
• 快速：支持并发每秒一千次的写操作；
  
• 可靠：支持分布式结构，基于Raft
  

　　通常情况下，用户使用Etcd可以在多个节点上启动多个实例，并将它们添加为一个集群。同一个集群中的Etcd实例将会自动保持彼此信息的一致性，这意味着分布在各个节点上的应用也将获取到一致的信息。

[1]Apache ZooKeeper是一套知名的分布式系统中进行同步和一致性管理的工具。

[2]doozer是一个一致性分布式数据库实现，主要面向少量数据，更多信息可以参考https://github.com/ha/doozerd。

[3]Raft是一套通过选举主节点来实现分布式系统一致性的算法，相比于大名鼎鼎的Paxos算法，它的算法过程相对容易理解，由Stanford大学的Diego Ongaro和John Ousterhout提出。更多细节可以参考https://raftconsensus.github.io。

　　主要操作：
　　数据操作，监听数据操作，目录操作，日志操作，用户操作，角色操作，认证操作，节点操作，集群操作。
Docker Machine
　　Docker Machine是Docker官方三剑客项目之一，负责使用Docker的第一步，在多种平台上快速安装Docker环境。它支持多种平台，让用户可以在很短时间内搭建一套Docker主机集群。当要对多个Docker主机进行配置和管理时，采用Docker Machine将十分方便快捷。不仅提高了操作速度，更通过批量统一的管理减少了出错的可能。这是在大规模集群和云平台环境中所推荐的。配合Compose和Swarm，可以实现完整的Docker环境生命周期管理。
　　Machine项目是Docker官方的开源项目，负责实现对Docker主机本身进行管理，其代码在https://github.com/docker/machine上开源。
　　Machine项目主要由Go编写，用户可以在本地任意指定被Machine管理的Docker主机，并对其进行操作。Machine定位是“在本地或者云环境中创建Docker主机”。
　　其基本功能包括：

• 在指定节点上安装Docker引擎，配置其为Docker主机；
  
• 集中管理所有Docker主机。
  

　　Machine连接不同类型的节点是通过不同驱动指定的，目前已经支持了包括IBM、Amazon、Google等多家数据中心的云主机。
Docker Compose
　　Compose项目是Docker官方的开源项目，基于Python语言实现，负责实现对Docker容器集群的快速编排。从功能上看，跟OpenStack中的Heat十分类似。其代码目前在https://github.com/docker/compose上开源。
　　编排（Orchestration）功能是复杂系统实现灵活可操作性的关键。特别是在Docker应用场景中，编排意味着用户可以灵活地对各种容器资源实现定义和管理。
　　作为Docker官方编排工具，Compose的重要性不言而喻，它可以让用户通过编写一个简单的模板文件，快速地创建和管理基于Docker容器的应用集群。
　　Compose定位是“定义和运行多个Docker容器的应用”，其前身是开源项目Fig，目前仍然兼容Fig格式的模板文件。我们知道使用一个Dockerfile模板文件，可以让用户很方便地定义一个单独的应用容器。然而，在日常工作中，经常会碰到需要多个容器相互配合来完成某项任务的情况。例如要实现一个Web项目，除了Web服务容器本身，往往还需要再加上后端的数据库服务容器，甚至还包括负载均衡容器等。Compose恰好满足了这样的需求。它允许用户通过一个单独的docker-compose.yml模板文件（YAML格式）来定义一组相关联的应用容器为一个项目（project）。
　　Compose中有两个重要的概念：

• 服务（service）：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例。
  
• 项目（project）：由一组关联的应用容器组成的一个完整业务单元，在docker-compose.yml文件中定义。
  

　　Compose的默认管理对象是项目，通过子命令对项目中的一组容器进行便捷地生命周期管理。
　　Compose项目由Python编写，实现上调用了Docker服务提供的API来对容器进行管理。因此，只要所操作的平台支持Docker API，就可以在其上利用Compose来进行编排管理。
Docker Swarm
　　Docker Swarm是Docker公司推出的官方容器集群平台，基于Go语言实现。
　　Docker Swarm是Docker官方的三剑客项目之一，提供Docker容器集群服务，是Docker官方对容器云生态进行支持的核心方案。使用它，用户可以将多个Docker主机封装为单个大型的虚拟Docker主机，快速打造一套容器云平台。
　　通过使用Swarm，用户可以将若干Docker主机节点组成的集群当作一个大的虚拟Docker主机使用。并且，原先基于单机的Docker应用可以无缝地迁移到Swarm上来。实现这些功能的前提是服务自动发现能力。在现代分布式系统中，服务的自动发现、注册、更新等能力将成为系统的基本保障和重要基础。在生产环境中，Swarm的管理节点和发现服务后端要采用高可用性的保护，可以采用集群模式。
　　作为容器集群管理器，Swarm最大的优势之一就是100%支持标准的Docker API。各种基于标准API的工具，如Compose、docker-py，各种管理软件，甚至Docker本身等都可以很容易地与Swarm进行集成。这大大方便了用户将原先基于单节点的系统移植到Swarm上。同时Swarm内置了对Docker网络插件的支持，用户可以很容易地部署跨主机的容器集群服务。
　　Swarm是典型的master-slave结构，通过发现服务来选举manager。manager是中心管理节点，各个node上运行agent接受manager的统一管理。在V2中，集群会自动通过Raft协议分布式选举出manager节点，无需额外的发现服务支持，避免了单点瓶颈。同时，V2中内置了基于DNS的负载均衡和对外部负载均衡机制的集成支持。
Mesos——优秀的集群资源调度平台
　　Mesos项目是源自UC Berkeley对集群资源进行抽象和管理的开源项目，类似于操作系统内核，用户可以使用它很容易地实现分布式应用的自动化调度。同时，Mesos自身也很好地结合了Docker等相关容器技术，基于Mesos已有的大量应用框架，可以实现用户应用的快速上线。
　　Mesos可以将整个数据中心的资源（包括CPU、内存、存储、网络等）进行抽象和调度，使得多个应用同时运行在集群中分享资源，并无需关心资源的物理分布情况。如果把数据中心中的集群资源看做一台服务器，那么Mesos要做的事情，其实就是今天操作系统内核的职责：“抽象资源+调度任务”。
　　Mesos项目主要由C++语言编写，项目官方地址为http://mesos.apache.org，代码仍在快速演化中。
　　Mesos拥有许多引人注目的特性，包括：

• 支持数万个节点的大规模场景（Apple、Twitter、eBay等公司的实践）。
  
• 支持多种应用框架，包括Marathon、Singularity、Aurora等。
  
• 支持HA（基于ZooKeeper实现）。
  
• 支持Docker、LXC等容器机制进行任务隔离。
  
• 提供了多个流行语言的API，包括Python、Java、C++等。
  
• 自带了简洁易用的WebUI，方便用户直接进行操作。
  

　　值得注意的是，Mesos自身只是一个资源抽象的平台，要使用它往往需要结合运行其上的分布式应用（在Mesos中被称作框架，framework），比如Hadoop、Spark、Marathon、Elasticsearch等大部分时候，用户只需要跟这些框架打交道即可，完全无需关心底下的资源调度情况，因为Mesos已经自动帮你实现了。这大大方便了上层应用的开发和运维。当然，用户也可以基于Mesos打造自己的分布式应用框架。
　　Mesos中有三个基本的组件：管理服务（master）、任务服务（slave）以及应用框架（framework）。
　　跟大部分分布式系统中类似，主节点（master）起到管理作用，将看到全局的信息，负责不同应用框架之间的资源调度和逻辑控制。应用框架需要注册到管理服务上才能被使用。用户和应用需要通过主节点提供的API来获取集群状态和操作集群资源。
　　slave负责汇报本从节点上的资源状态（空闲资源、运行状态等等）给主节点，并负责隔离本地资源来执行主节点分配的具体任务。隔离机制目前包括各种容器机制，包括LXC、Docker等。
　　应用框架（framework）是实际干活的，包括两个主要组件：

• 调度器（scheduler）：注册到主节点，等待分配资源；
  
• 执行器（executor）：在从节点上执行框架指定的任务（框架也可以使用Mesos自带的执行器，包括shell脚本执行器和Docker执行器）。
  

　　应用框架可以分两种：一种是对资源的需求，是会扩展的（如Hadoop、Spark等），申请后还可能调整；另一种是对资源需求大小是固定的（如MPI等），一次申请即可。
Kubernetes——生产级容器集群平台
　　Kubernetes是Google团队发起并维护的开源容器集群管理系统，支持如Docker等容器技术。类似Docker Swarm，使用Kubernetes，用户可以轻松搭建和管理一个私有容器云。该项目基于Go语言实现，试图为基于容器的应用部署和管理打造一套强大并且易用的管理平台。
　　Kubernetes拥有鲜明的技术优势：

• 优秀的API设计，以及简洁高效的架构设计，主要组件个数很少，彼此之间通过接口调用；
  
• 基于微服务模式的多层资源抽象模型，兼顾灵活性与可操作性，提出的Pod模型被许多平台借鉴；
  
• 可拓展性好，模块化容易替换，伸缩能力极佳，1.2.0版本单集群支持1000个节点，同时运行30000个Pods；
  
• 自动化程度高，真正实现“所得即所需”，用户通过模板声明服务后，生命周期都是自动化管理；
  
• 部署支持多种环境，包括虚拟机、裸机部署，还很好地支持常见云平台，包括AWS、GCE等；
  
• 支持丰富的运维工具，方便用户对集群进行性能测试、问题检查和状态监控；
  
• 自带控制台、客户端命令等工具，允许用户通过多种方式与kubernetes集群进行交互。
  

　　基于Kubernetes，可以很容易地实现一套PaaS，比如Openshift和Deis。Kubernetes目前在github.com/kubernetes/kubernetes进行维护。
　　Kubernete模型中的核心概念。这些核心概念反映了Kubernetes设计过程中对应用容器集群的认知模型。
　　集群组件，从架构上看，Kubernetes集群（Cluster）也采用了典型的“主-从”架构。一个集群主要由管理组件（Master）和工作节点（Node）组件构成。
　　Kubernetes集群的主要任务始终围绕着应用的生命周期。通过将不同资源进行不同层次的抽象，Kubernetes提供了灵活可靠的生命周期管理。
　　资源的核心抽象主要包括：

• 容器组（Pod）：由位于同一节点上若干容器组成，彼此共享网络命名空间和存储卷（Volume）。Pod是Kubernetes中进行管理的最小资源单位，是最为基础的概念。跟容器类似，Pod是短暂的，随时可变的；
  
• 服务（Service）：若干（往往是同类型的）Pod形成的对外提供某个功能的抽象，不随Pod改变而变化，带有唯一固定的访问路径，如IP地址或者域名。
  
• 复制控制器（Replication Controller）：负责启动Pod，并维护其健康运行的状态。是用户管理Pod的句柄。
  
• 部署（Deployment）：创建Pod，并可根据参数自动创建管理Pod的复制控制器，并且支持升级。1.2.0版本引入提供比复制控制器更方便的操作；
  
• 横向Pod扩展器（Horizontal Pod Autoscaler，HPA）：类似云里面的自动扩展组，根据Pod的使用率（典型如CPU）自动调整一个部署里面Pod的个数，保障服务可用性；
  

　　还有一些管理资源相关的辅助概念，主要包括：

• 注解（Annotation）：键值对，可以存放大量任意数据，一般用来添加对资源对象的详细说明，可供其他工具处理。
  
• 标签（Label）：键值对，可以标记到资源对象上，用来对资源进行分类和筛选；
  
• 名字（Name）：用户提供给资源的别名，同类资源不能重名；
  
• 命名空间（Namespace）：这里是指资源的空间，避免不同租户的资源发生命名冲突，另外可以进行资源限额；
  
• 持久卷（PersistentVolume）：类似于Docker中数据卷的概念，就是一个数据目录，Pod对其有访问权限。
  
• 秘密数据（Secret）：存放敏感数据，例如用户认证的口令等；
  
• 选择器（Selector）：基于标签概念的一个正则表达式，可通过标签来筛选出一组资源；
  
• Daemon集（DaemonSet）：确保节点上肯定运行某个Pod，一般用来采集日志和监控节点；
  
• 任务（Job）：确保给定数目的Pod正常退出（完成了任务）；
  
• 入口资源（Ingress Resource）：用来提供七层代理服务；
  
• 资源限额（Resource Quotas）：用来限制某个命名空间下对资源的使用，开始逐渐提供多租户支持；
  
• 安全上下文（Security Context）：应用到容器上的系统安全配置，包括uid、gid、capabilities、SELinux角色等；
  
• 服务账号（Service Accounts）：操作资源的用户账号。