前记
在开始动手设计EWS（即TAE3.0）之时, 我们参考了诸如swarm, kubernetes, mesos, yarn等众多与容器集群管理相关的系统或者设计思路, 当然最为**惊艳**的莫过于kubernetes了.考虑到历史数据及公司特有的网络, 运维环境, EWS不可能完全抛弃原有的数据模型而使用全新的设计或者说直接建立在诸如kubernetes上(感谢上帝我做了一个非常明确的决定!)。
时至今日, kubernetes也刚刚发布了1.2版本, 一大波特性袭来. 在简单了解了一番之后, 回头再看看EWS在这段时间内的变化, 觉得还是应该记录一下, 也分享一下我对于TAE模型设计方面的理解.
TAE
EWS的模型设计是由PaaS时代变迁过来的. 当时比较流程的解决方案有heroku, gae, sae等等。比较常见的组件就是一个7层负载接入层, 一个逻辑路由层以及用于运行用户App的主机(Grid)。
在TAE1.0时期, 我们使用过基于JavaWeb的运行环境, 后期使用了基于lxc的轻量级linux隔离环境, 在TAE2.0时期我们开始使用docker作为容器虚拟化环境。下表是TAE2.0时期的主要应用模型, 命名上, 当时更多的是参考了阿里的运维系统。
EWS支持多分区
与最新的kubernetes版本支持的多分区不同, EWS从一开始就支持了多分区的容器集群管理能力。下边两幅图分别简单描述了EWS与kubernetes在部署结构上的不同。
通过上两图的对比, EWS将用户运行的环境认为是受控区, 而每个受控区会对应一个管控区, 而中心管控节点(ControllerCenter)与各个管控区通信, 负责指令的下发与管理. 对于Kubernetes而言, 其所有的Node都是直接与Master进行交互的(目前Ubernetes实现多分区的思路是基于label机制, 在构架本质上并没有发生明显的变化)。
EWS模型
总结一下EWS目前的核心设计（与kubernetes对比）
EWS系统模型
目前主要支持的是商家事业部的聚石塔业务-EWS。对于商家, 对于ISV开发者来说, 我们把管控单元, 主机分区等等包装成了Region, Zone, App等概念, 明确了运维和开发两种不同的关注点。
EWS与kukernetes功能对比：
- EWS在调度层面，Container为主，Node为辅
- 将模型分为运维段和开发段，引入Region,Zone,App概念，匹配现有业务模型
- EWS 不强调块存储，但强调存有状态业务服务化，即使用RDS,OSS,OCS等服务化存储
Kubernetes
在起初看到Pod, Replication Controller, Label等等概念时, 我就暗自心想不愧是打着谷歌光环的容器集群管理系统. 下表记录了一些我认为Kubernetes较为核心的模型概念.
在1.2版本中, Kubernetes开始支持多分区集群，这与EWS的多分区支持还是有本质上不同的.。
Node,Pod,Container
Pod由Container组成并且运行在Node之上。
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语句来进行筛选或过滤.
在EWS中, 也使用了Label机制来进行对主机, 镜像, 容器等等进行划分和挑选.
Service
在Kubernetes中, Service是用于解决Pod访问问题的. 目前Kubernetes提供了NodePort和LoadBalancer两种方式.
Namespace
在Kubernetes中, Namespace可以用于对Pod, Rc, Service等等进行逻辑划分. 默认情况下, 这些对象都是被分配到"default"分组中的.
在EWS中, 由于提供了用户及主机分组的概念, 所以并没有提供Namespace概念.
后记
EWS的模型不是一蹴而就的, 在经历了TAE1.0, TAE2.0并参考了众多优秀的框架,系统设计, 目前从完整性, 功能性, 扩展性上来看已经不落后于任何已有的系统.
后续, EWS会在动态调度, 弹性缩容, 灾备恢复等场景能力上继续发力.
