今天，我们将继续为大家带来由才云科技（Caicloud）CEO 张鑫及才云科技（Caicloud）解决方案架构师王章贵共同撰写的技术文章。相信对于需要在 Kubernetes、Swarm、Mesos 之间做出选择的用户可以提供一些参考建议。
《Kubernetes：谷歌级容器集群管理的选择》
全文目录
一.容器只是开始
1.容器的优势
2.大规模生产的核心难点：容器集群管理
二.容器集群管理方案的选择因素
三.开源社区健壮度比较
四.支持公司与厂商比较
五.落地使用率和流行趋势比较
六.项目的技术实力与背景比较
七.项目技术特性比较
八.附录：技术架构简介
1.架构设计
1.1 Kubernetes
1.2 Docker Swarm
1.3 Apache Mesos
2.功能列表
回顾之前章节内容，请点击《Kubernetes：谷歌级容器集群管理的选择（上）》
六. 项目的技术实力与背景比较
Kubernetes 是一个“含着金钥匙出世”的容器编排工具，Google 的15年全球超大量型生产基础设施服务 Borg 的结晶。从 Cgroups 到 Libconatiner 再到 Kubernetes，Google 一直是容器领域的“领路人”。Google 这些年借助容器与容器编排技术在性能、资源利用和整体效率方面取得了震撼寰宇的现象级收益。
在过去15年间，Google 利用 Kubernetes 架构和设计思想成功将其所有应用（搜索、地图、视频、金融、社交、人工智能）运行在超过100万台服务器、跨超过80个数据中心，每周运行20亿个容器。
Mesos 起初由来自几位伯克利大学的 Google 实习生在2009提出并研发，2011年成为 Apache 孵化项目。
Docker Swarm 由初创公司 Docker 2014年年底开源的 Docker 容器管理工具，Docker 公司原名为 Dotcloud，因 Docker 项目开源后名噪一时，公司更名为 Docker，并将原有的服务出售给一家德国公司。
从历史可以看出，Kubernetes 是唯一具有超过10年大规模容器生产使用的技术经验和积淀的开源项目。
七. 项目技术特性比较
Kubernetes 作为新一代集群管里系统，采用了非常优雅的软件工程设计，通过模块化、微服务的方式，实现模块化设计，使得用户可以根据自己的使用场景，通过灵活插拔的方式，采用自定义的网络、存储、调度、监控、日志等模块。
此外，Kubernetes 项目和社区秉承着开源、开放的心态，可以支持多种容器、网络、存储实施方案，这与 Docker Swarm 的自闭性形成了鲜明的对比和优势。
从功能点上来讲，Docker Swarm 最为简单，只实现了容器的基本编排功能，例如调度、编排、跨主机通信等。
此外，Mesos 注重资源调度，而 Kubernetes 则更是面向分布式应用、微服务治理、和大规模集群管理（其中融入了谷歌独有的“集群管理不仅仅是资源调度和编排”的理念）。举例来说，Kubernetes 提供了如下在大规模生产系统所需的核心功能，而这些功能在 Swarm 和 Mesos 中缺失：
应用业务与服务的自我治理：系统能自动监测应用是否在运行，并在发现问题时自动在合适的机器上重启应用。更关键的，系统不仅可以看应用是否运行，而是可以支持用户根据业务特定的逻辑，做任意自定义的“健康指标”检查（例如某个输出是否合理，某个页面是否返回正常）。
高可用守护进程管理：高可用系统的核心关键需求，对于关键任务（例如监测、守护进程），保证每个主机一直有且只有一个用户自定义程序在运行。
逻辑分区和网络、资源隔离： 作为大规模系统的必须功能，在平台内部，可以根据不同的业务定制化划分不同的“业务分区”，使得同一个底层物理集群的资源可以在多个分区间共享，同时做到不同分区间的资源隔离不相互影响，保证高可用。
面向微服务的容器组群管理：作为复杂微服务系统的必要功能，对于细粒度的微服务架构，能够支持将多个容器／微服务模块做到统一调度，保证他们在动态调度时一直分配到同一个机器，且相互之间可通过 Localhost 方式访问，提高性能并实现高可用。
基于标签的资源管理系统：作为大规模生产系统的必须功能，能够灵活的、自定义的将物理资源（机器）和应用、服务按逻辑分组，并提供查询接口。
秘密数据管理：作为核心关键安全性功能，对于敏感数据，重点保护，不以明文方式呈现，且不会由 Docker 自动保存在硬盘上的 JSON 文件。
配置服务管理：作为大规模软件系统管理的必须功能，实现应用程序完全与针对不同环境的配置解耦合，使得在开发、测试、绿、蓝环境切换时，应用程序使用完全一样的同一套镜像。
其他具体的技术参数对比请参见附录。
附录：技术架构简介
1. 架构设计
1.1 Kubernetes
Google 设计 Kubernetes 基于两个非常重要的经验：一是 Google 多年来运行大型分布式系统的经验，二是支撑快速更新、敏捷迭代的云原生应用的经验。前者保证了 Kubernetes 平台本身的稳定性和扩展性，后者保证了 Kubernetes 平台对其使用者(运维人员/开发人员)的有效性。
Kubernetes 在内部组件结构上分为：
Pod
o 一组包括一个或多个的容器组
o 共享网络全名空间
o 调度的最小单元Service
o 为一组 Pod 的逻辑抽象
o 将应用服务解耦Kube Proxy
o 宿主机上运行一个简单的网络代理及负载均衡器为 Services 提供负载均衡
o 为外部请求负载到具体的 Pod 上, 具体实现为
• Kube Proxy 为 Service IP 生成 Lptables 规则
• 将请求转发到本地的 Kubeproxy
• Kube Proxy 进行 NAT 转换，最后将请求交到后台具体 Pod 上
• Kubelet
o 宿主机上管理 Pod 及其容器、镜像、存储等等Etcd
o 分布式键值对存储方案
o 用于持久化 Master 的状态数据
o 支持 Watch 操作来完成组件内部的服务协作API Server
o Kubernetes Master 的组件之一
o 用于响应内部组件或外部插件的 Kubernetes API 的调用
o 主要是处理 REST 请求
• 对请求进行身份较验，并更新到分布式存储中（ETCD）Scheduler
o Kubernetes Master 的组件之一
o 通过/Binding API，将未被调度的 Pod 绑定到某一节点上
o 支持可插拔Controller Manager
o 支持节点的发现与监控
o 支持 Endpoints 的创建与更新
o 控制 Pod 的伸缩
1.2 Docker Swarm
Docker Swarm 基于 Docker 提供的原生集群能力，将一组 Docker 引擎变成一个虚拟的 Docker 引擎。Swarm 使用标准的 Docker API, 使用正常的 Docker 命令来运行 Docker 容器，也会选择一个适合的节点来运行容器
Docker Swarm 在内部组件结构上分为：
Swarm Manager
o Swarm 集群的 Master
o 负责编排调度 Docker 容器
o 服务发现Swarm Agent
o 接收 Swarm Manager 指令并运行 Docker 容器服务协调工具
o 可以是 Consul、Etcd 或 Zookeeper
1.3 Apache Mesos
Apache Mesos 是一个大规模集群的开源管理平台，集群量级可以从几百台到几千台，Mesos 能支持不同类型的任务框架，比如计划任务、长时间运行的任务等等，即 Mesos 的架构设计是解决高可用和弹性等问题，架构图如下：
Apache Mesos 在内部组件结构上分为：
Mesos Master
o 发送工作任务给 Agent Nodes
o 维护一张资源列表，并提供给具体的 Framework 使用，例如 Hadoop 或 Marathon
o Mesos 根据当前的资源分配策略决定分配多少资源Mesos Agent Node
o 执行工作任务
o 向 Master 报告本节点的可用资源列表Zookeeper
o Mesos Master 实例间竞选谁为真正的 MasterFrameworks
o Mesos 需要与 Framework 协同完成具体任务的分发
• 调度器向 Master 注册，根据当前可用资源列表选择使用某一资源
• 执行进程运行在 Agent 上，并监控任务的执行情况
Mesos 可有多个 Framework 同时运行在同一个 Mesos 管理的资源上，用户提交任务其实是与 Framework 交互并不是 Mesos，从上面的架构图中可以看出，Mesos 需要与 Marathon 一同实现容器编排工具的功能，Marathon 做为 Scheduler，通过向 Zookeeper 获取到真实 Mesos Master 信息，并向 Mesos Master 提交任务，当 Marathon 与 Mesos Master 同是 Ready 的状态，才能开始编排容器。
Marathon 被设计用于启动、监控长时运行的应用，包括云原生应用，客户端通过 Marathon Rest API 与 Marathon 交互。
2. 功能列表
结论
Kubernetes 与 Mesos+Maratho 和 Docker Swarm 三类开源项目在容器编排需要的功能点上看，Mesos+Marathon 与 Docker Swarm 在很多功能支持程度不如 Kubernetes，需用户做出妥协。
