容器技术发展趋势（二）

​容器技术已经引起了业内的广泛关注，有充分的证据表明，容器技术能够大大提升工作效率。

现在，虚拟化技术已经成为一种被大家广泛认可的服务器资源共享方式，它可以在按需构建操作系统实例的过程当中为系统管理员提供极大的灵活性。由于hypervisor虚拟化技术仍然存在一些性能和资源使用效率方面的问题，因此出现了一种称为容器（Container）的新型虚拟化技术来帮助解决这些问题，下面我们来简单聊聊容器（Container）的发展趋势。

Docker的价值

• 持续集成&持续交付
• SOA化，微服务化
• 轻量虚拟化
• 软件交付/变更模式

Docker带来的变革的意义，不单纯是对软件技术，更是对组织，流程的影响，合理的使用docker能够让组织敏捷起来！

Docker & PaaS

• 以容器为单位成为PaaS的共识，基于docker的容器打包和分发有望成为PaaS平台的标准，docker将大幅拓宽PaaS的应用范围，并促进PaaS的快速发展
• 第三代PaaS更贴近应用（应用集群管理）也更透明化（完全基于docker，不需要有限的builpack，完全由使用者决定），第二代PaaS也在不断改进（引进docker，增加应用集群管理）

Docker & IaaS

• OpenStack也在积极引入docker容器
• Nova调度和管理docker
• 通过Heat提供容器的编排调度，但整体上仍然是以资源为中心的调度，是否能够充分发挥docker的价值，还存在讨论与争议
• 独立于IaaS的容器集群调度系统（mesos，k8s...）的出现，的到了微软，红帽，IBM，VMware，docker，Mesosphere，CoreOS和SaltStack等多家厂商的支持，容器技术已有较完整的技术堆栈，未来独立的IaaS以及OpenStack可能会被边缘化。

开源容器虚拟化软件技术堆栈和阵营

• 仓库：提供容器仓库，实现镜像管理，上传，下载，容器状态和性能数据采集/展示
• 资源和集群管理（编排调度）：提供资源调度，集群管理，组合部署，服务发现，扩容缩容，多租，支持docker Application依赖关系定义
• 容器引擎，容器网络：提供容器引擎，容器网络服务，实现容器异构云部署适配，网络隔离，浮动IP等
• 容器OS：提供轻量化的容器操作系统，实现基于容器软件分发，动态升级等

Docker相关技术成熟度

• docker引擎经过两年发酵和积累，目前相对成熟，而且有较多实践案例
• 容器网络目前热度最高，业界关注和讨论，实践尝试较多，正在快速催熟
• 容器编排虽然目前热度很高，但是由于其技术复杂度及对传统管理系统的替代/冲击，所以成熟度并不高，而且存在一些产品化瓶颈（性能和算法），业界有参考其原理的一些实践，但k8s本身并没有真正的商用案例，成熟周期预计较长；但选择性使用部分技术相对成熟，无争议的组件，可以加速产品化节奏。
• 基于k8s支持Spark，Hadoop体现了k8s在生态上的积极进取和野心，未来可能成为大数据领域与mesos/yarn分庭抗礼的重要技术选择；

容器技术加速了企业应用Cloud Native化，伴随企业应用逐渐向容器迁移，用户使用云计算方式发生变化，从原有以VM资源为核心，转变为以应用容器及其编排管理调度系统为核心。

Docker Swarm

Docker swarm是Docker公司推出的Docker容器原生额集群服务

• 将一群docker宿主机变成一个单一的虚拟的主机
• 负责容器集群管理，优化资源利用率，维护集群状态
• 像使用docker一样使用swarm
• 原生docker集群服务，前端直接使用标准docker API，docker client可以直接与swarm相连（透明，兼容）
• 发现服务（docker主机）
• 使用了docker hub内置的发现服务（token service），与hub绑定
• 调度策略
• swarm scheduler支持三种调度策略：spread，binpack，random
• Label和过滤
• swarm通过主机定义的label，以及docker运行时的filter来过滤主机

Swarm优势

• 轻，简单，易用
• Docker client兼容接口，透明演进

Swarm缺点

• hub发现服务绑定
• 仍然偏Resource Centric，包括filter和strategy，仍然是资源维度来描述应用
• 功能扩展依赖社区

Docker Compose

docker compose为开发者提供了应用组合的能力，旨在让用户很容易从众多容器（比如前端，数据库和负载均衡等组件）构建一个复杂的分布式应用程序。这些应用基于独立于任何底层基础设施的分散的，可交互的docker容器之上构建

定义好应用的YAML文件后，运行工作将简单到一个命令

Kubernetes

Kubernetes是Google开源的容器集群管理系统，Google内部采用的是Borg以及基于lxc自己构建的容器；

下一代集群管理系统OMEGA（共享状态的调度架构）目前仍然停留在论文阶段；

• 分布式应用的统一描述（POD，Service，App）
• 分布式应用的资源选择和调度（调度算法，策略，集群管理）
• 分布式应用的监控（cAdvisor），SLA保障（Replication）
• 分布式应用的服务发现，服务路由

Kubernetes优势

• 灵活，完整，可定制
• App Centric（POD/App/Service），服务发现

Kubernetes缺点

• 重，不同管理接口 VS. Docker client

Mesos & Marathon

Mesos是一个统一资源管理和调度系统，如果把云比作Linux，Mesos相当于distributed system kernel，Mesos内核运行在每台机器上，通过Framework，提供夸整个数据中心和云环境进行资源管理和调度的API；

• Mesos为其上各种应用提供集群内资源调度，提高资源效率，降低相互影响
• Mesos Slave上报资源给Master，由Master分配给应用，应用决定接受与否，接受后通过Master向Slave发布任务
• 严格的将，Mesos是偏任务和资源的调度系统，并不理解应用本身
• 传统的，Mesos可用于Hadoop或者MPI

Marathon是Mesos之上的一个长生命周期应用的调度框架（Scheduler），这个应用并不限制于web应用或其他应用。

• 基于Mesos上提供应用的调度管理能力
• 支持简单的dependency，可以据此对不同应用进行有序的启动停止和升级
• 可以基于应用状态/KPI进行应用可靠性管理，监控应用状态，并保障故障时新建
• 弹性伸缩能力
• 提供部署增强能力，按主机Host和属性Attribute选择部署资源

• RancherOS的所有东西都作为docker管理的容器，包括udev和rsyslog
• RancherOS仅仅包括最少运行docker所需要的软件
• RancherOS二进制下载包只有20MB
• 所有东西都能通过docker动态拉取

与CoreOS，Atomic，Photon的主要区别

• CoreOS，Atomic系统是针对企业级应用提供的OS版本，进行了精简，内置/集成了容器引擎，还集成了容器集群/App管理软件（Atomic集成了Kubernetes，CoreOS天生就自带Fleet App管理软件）
• CoreOS，Atomic和Photon并非完全基于容器，而是基于已实例有OS（sysvinit/systemd）机制，叠加了容器引擎；RancherOS启动system docker（PID）本身就是docker，取代了（sysvinit和systemd）
• RancherOS遵从最简单原则，只提供容器引擎，并且整个OS是完全基于容器开发的

Flocker

Flocker面向dockerized应用的开源容器数据卷管理器

• docker自身没有管理数据卷迁移，数据卷被局限在单一的服务器上
• Flocker数据集是可以轻便的，可被使用在任何一款容器上，并不需要关心应用集群的容器在哪里运行

文章如有不妥之处，欢迎指正！谢谢！