Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
【转载】Kubernetes:谷歌级容器集群管理的选择(下) – zoues

LOADING

Follow me

【转载】Kubernetes:谷歌级容器集群管理的选择(下)
五月 26, 2017|DockerPaaS

【转载】Kubernetes:谷歌级容器集群管理的选择(下)

【转载】Kubernetes:谷歌级容器集群管理的选择(下)

今天,我们将继续为大家带来由才云科技(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:谷歌级容器集群管理的选择(下)

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 容器,也会选择一个适合的节点来运行容器
 

Kubernetes:谷歌级容器集群管理的选择(下)

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 的架构设计是解决高可用和弹性等问题,架构图如下:
 

Kubernetes:谷歌级容器集群管理的选择(下)

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

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

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

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

  • Frameworks
    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:谷歌级容器集群管理的选择(下)

结论

Kubernetes 与 Mesos+Maratho 和 Docker Swarm 三类开源项目在容器编排需要的功能点上看,Mesos+Marathon 与 Docker Swarm 在很多功能支持程度不如 Kubernetes,需用户做出妥协。

Kubernetes:谷歌级容器集群管理的选择(下)

no comments
Share