[EWS系列分享]容器集群管理系统模型杂谈-阿里云开发者社区

开发者社区> 云原生> 正文
登录阅读全文

[EWS系列分享]容器集群管理系统模型杂谈

简介: 前记     在开始动手设计EWS(即TAE3.0)之时, 我们参考了诸如swarm, kubernetes, mesos, yarn等众多与容器集群管理相关的系统或者设计思路, 当然最为**惊艳**的莫过于kubernetes了.考虑到历史数据及公司特有的网络, 运维环境, EWS不可能
772d4201db03e5826b28098eec1a198455957c1c

前记

    在开始动手设计EWS(即TAE3.0)之时, 我们参考了诸如swarm, kubernetes, mesos, yarn等众多与容器集群管理相关的系统或者设计思路, 当然最为**惊艳**的莫过于kubernetes了.考虑到历史数据及公司特有的网络, 运维环境, EWS不可能完全抛弃原有的数据模型而使用全新的设计或者说直接建立在诸如kubernetes上(感谢上帝我做了一个非常明确的决定!)。

    时至今日, kubernetes也刚刚发布了1.2版本, 一大波特性袭来. 在简单了解了一番之后, 回头再看看EWS在这段时间内的变化, 觉得还是应该记录一下, 也分享一下我对于TAE模型设计方面的理解.

TAE

    EWS的模型设计是由PaaS时代变迁过来的. 当时比较流程的解决方案有heroku, gae, sae等等。比较常见的组件就是一个7层负载接入层, 一个逻辑路由层以及用于运行用户App的主机(Grid)。

60add192gw1f3q41wy7bvj20ai07lq33.jpg

     在TAE1.0时期, 我们使用过基于JavaWeb的运行环境, 后期使用了基于lxc的轻量级linux隔离环境, 在TAE2.0时期我们开始使用docker作为容器虚拟化环境。下表是TAE2.0时期的主要应用模型, 命名上, 当时更多的是参考了阿里的运维系统。

EWS支持多分区

    与最新的kubernetes版本支持的多分区不同, EWS从一开始就支持了多分区的容器集群管理能力。下边两幅图分别简单描述了EWS与kubernetes在部署结构上的不同。

60add192gw1f3q46vlol5j20x50t9n4z.jpg60add192gw1f3q47pf43cj21kw1augt6.jpg

   通过上两图的对比, EWS将用户运行的环境认为是受控区, 而每个受控区会对应一个管控区, 而中心管控节点(ControllerCenter)与各个管控区通信, 负责指令的下发与管理. 对于Kubernetes而言, 其所有的Node都是直接与Master进行交互的(目前Ubernetes实现多分区的思路是基于label机制, 在构架本质上并没有发生明显的变化)。


EWS模型

总结一下EWS目前的核心设计(与kubernetes对比)

60add192gw1f3q49te01fj20o70e4n1t.jpg

EWS系统模型

    目前主要支持的是商家事业部的聚石塔业务-EWS。对于商家, 对于ISV开发者来说, 我们把管控单元, 主机分区等等包装成了Region, Zone, App等概念, 明确了运维和开发两种不同的关注点。

60add192gw1f3q4c136vtj215o0puwke.jpg

EWS与kukernetes功能对比:

60add192gw1f3q4dbbzxoj20gu0dwdhs.jpg

  • EWS在调度层面,Container为主,Node为辅
  • 将模型分为运维段和开发段,引入Region,Zone,App概念,匹配现有业务模型
  • EWS 不强调块存储,但强调存有状态业务服务化,即使用RDS,OSS,OCS等服务化存储

Kubernetes

     在起初看到Pod, Replication Controller, Label等等概念时, 我就暗自心想不愧是打着谷歌光环的容器集群管理系统. 下表记录了一些我认为Kubernetes较为核心的模型概念.

60add192gw1f3q4fodssrj20kr0a6wh7.jpg在1.2版本中, Kubernetes开始支持多分区集群这与EWS的多分区支持还是有本质上不同的.。

Node,Pod,Container

    Pod由Container组成并且运行在Node之上。

60add192gw1f3q4i7gjg2j20kj07jwev.jpg

Pod的关键特性是其内的容器共享一组资源:

  • PID命名空间: Pod中的不同应用程序可以看到其他应用程序的进程ID.
  • 网络命名空间: Pod中的多个容器能够访问同一个IP和端口范围.
  • IPC命名空间: Pod中的多个容器能够使用SystemV IPC或者POSIX消息队列进行通信.
  • UTS命名空间: Pod中的多个容器共享一个主机名
  • Volumes: Pod中的各个容器可以访问在Pod级别定义的Volumes.

    Pod是Kubernetes中一个很重要也特有的模型概念, TAE中存在叫做节点的概念与之对应, 但是不具备容器共享一组资源的能力.

   从TAE2.0时期开始, 当时我们使用docker运行诸如wordpress的做法是将Apache2, PHP, Mysql运行在一个容器中. 而如果按照Kubernetes的做法, 是应该将Apache2, PHP, Mysql都运行在独立的容器中, 一起封装成一个Pod.


Why not just run multiple programs in a single (Docker) container?1 Transparency. Making the containers within the pod visible to the infrastructure enables the infrastructure to provide services to those containers, such as process management and resource monitoring. This facilitates a number of conveniences for users.2 Decoupling software dependencies. The individual containers may be versioned, rebuilt and redeployed independently. Kubernetes may even support live updates of individual containers someday.3 Ease of use. Users don’t need to run their own process managers, worry about signal and exit-code propagation, etc.4 Efficiency. Because the infrastructure takes on more responsibility, containers can be lighter weight.

    以上是Kubernetes官方对于为何不要在一个容器中运行多个进程的理由.另外, 值得一提的是如果Pod内的容器异常退出时, Kubernetes将会如何处理?

在Pod的配置文件中有restartPolicy这个参数, 可选值是Always|Never|OnFailure.如果设置为OnFailure, Kubernetes将会在发现容器出现问题时, 尝试重启.

    在我看来, Pod更多的体现的是一种思想及规范; 而为了实现这个规范, 容器集群管理系统, 包括docker本身则需要付出较大的代价.

RC

    在我看来, Kubernetes使用Replication Controller(RC)概念, 向用户统一抽象了关于调度的几个重要问题:

  • 调度的单位: Pod.
  • 调度的结果: 最终集群中运行多少个Pod副本.
  • 调度模式: 重新调度, 弹性伸缩, 滚动更新.
  • 调度算法: 通过AlgorithmProvider来提供.

Label

Label是我认为Kubernetes中最为精彩的模型, 功能设计. Kubernetes中所有的模型几乎都是通过label来相互关联.通过对Pod, Node打上标签, 即可以通过类似SQL语句来进行筛选或过滤.

60add192gw1f3q4mkht43j20pe0dgta3.jpg

    在EWS中, 也使用了Label机制来进行对主机, 镜像, 容器等等进行划分和挑选.

Service

    在Kubernetes中, Service是用于解决Pod访问问题的. 目前Kubernetes提供了NodePort和LoadBalancer两种方式.

Namespace

    在Kubernetes中, Namespace可以用于对Pod, Rc, Service等等进行逻辑划分. 默认情况下, 这些对象都是被分配到"default"分组中的.

    在EWS中, 由于提供了用户及主机分组的概念, 所以并没有提供Namespace概念.

后记

    EWS的模型不是一蹴而就的, 在经历了TAE1.0, TAE2.0并参考了众多优秀的框架,系统设计, 目前从完整性, 功能性, 扩展性上来看已经不落后于任何已有的系统.

    后续, EWS会在动态调度, 弹性缩容, 灾备恢复等场景能力上继续发力.

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云原生
使用钉钉扫一扫加入圈子
+ 订阅

云原生时代,是开发者最好的时代

其他文章