《Kubernetes：谷歌级容器集群管理的选择》

今天，我们将继续为大家带来由才云科技（Caicloud）CEO 张鑫及才云科技（Caicloud）解决方案架构师王章贵共同撰写的技术文章。相信对于需要在 Kubernetes、Swarm、Mesos 之间做出选择的用户可以提供一些参考建议。

项目的技术实力与背景比较

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

• 一组包括一个或多个的容器组
• 共享网络全名空间
• 调度的最小单元

Service

• 为一组 Pod 的逻辑抽象
• 将应用服务解耦

Kube Proxy

• 宿主机上运行一个简单的网络代理及负载均衡器为 Services 提供负载均衡
• 为外部请求负载到具体的 Pod 上, 具体实现为
• Kube Proxy 为 Service IP 生成 Lptables 规则
• 将请求转发到本地的 Kubeproxy
• Kube Proxy 进行 NAT 转换，最后将请求交到后台具体 Pod 上
• Kubelet 宿主机上管理 Pod 及其容器、镜像、存储等等

Etcd

• 分布式键值对存储方案
• 用于持久化 Master 的状态数据
• 支持 Watch 操作来完成组件内部的服务协作

API Server 

• Kubernetes Master 的组件之一
• 用于响应内部组件或外部插件的 Kubernetes API 的调用
• 主要是处理 REST 请求
• 对请求进行身份较验，并更新到分布式存储中（ETCD）

Scheduler

• Kubernetes Master 的组件之一
• 通过/Binding API，将未被调度的 Pod 绑定到某一节点上
• 支持可插拔

Controller Manager

• 支持节点的发现与监控
• 支持 Endpoints 的创建与更新
• 控制 Pod 的伸缩

1.2   Docker Swarm

Docker Swarm 基于 Docker 提供的原生集群能力，将一组 Docker 引擎变成一个虚拟的 Docker 引擎。Swarm 使用标准的 Docker API, 使用正常的 Docker 命令来运行 Docker 容器，也会选择一个适合的节点来运行容器

Docker Swarm 在内部组件结构上分为：

Swarm Manager

• Swarm 集群的 Master
• 负责编排调度 Docker 容器
• 服务发现

Swarm Agent

• 接收 Swarm Manager 指令并运行 Docker 容器
• 服务协调工具
• 可以是 Consul、Etcd 或 Zookeeper

1.3   Apache Mesos

Apache Mesos 是一个大规模集群的开源管理平台，集群量级可以从几百台到几千台，Mesos 能支持不同类型的任务框架，比如计划任务、长时间运行的任务等等，即 Mesos 的架构设计是解决高可用和弹性等问题，架构图如下：

Apache Mesos 在内部组件结构上分为：

Mesos Master

• 发送工作任务给 Agent Nodes
• 维护一张资源列表，并提供给具体的 Framework 使用，例如 Hadoop 或 Marathon
• Mesos 根据当前的资源分配策略决定分配多少资源

Mesos Agent Node

• 执行工作任务
• 向 Master 报告本节点的可用资源列表

Zookeeper

• Mesos Master 实例间竞选谁为真正的 Master

Frameworks

• 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，需用户做出妥协。