Core

设计思想

Core 的设计第一目标是高效调度。对于核心调度器而言,现有的几个系统采用如下的实现。

  • Kubernetes 基于悲观锁的实现,这个方案的问题是在规模巨大的集群中,ETCD 性能是调度瓶颈。在最新一版的 k8s 中,已经可以达到千台规模的控制,但对于我们而言,这才是星辰大海的起点而已。

  • Mesos 基于悲观锁的实现,采用全局资源协定的模式来分配资源。Mesos 资源分配最大的问题是上层框架没法知道资源亲和性带来的双层调度悖论:如果需要让框架自行根据应用进行亲和反亲和编排则只有一个全局框架,一个全局框架就没必要双层调度。

  • Swarm 基于悲观锁,类似于 Mesos。不过是从 [paxos](https://en.wikipedia.org/wiki/Paxos_(computer_science) ) 转向了 raft 罢了,因此在问题上也是一致的。

那么在设计 Core 的时候,我们的目标是无论集群多大,都应该提供一致性的高效资源分配能力。并且,不希望随着集群大小的增长产生冲突从而降低效率。因此我们是选择了悲观锁作为实现原理。

集中式架构的好处是能掌握全局的资源状态,能够进行更好的调度决策。然而和 Mesos 不同的在于,我们将资源计算和实际部署分成了2个部分。前者纯粹的数学计算,只要这部分足够快,那么加锁带来的并发降低也是可以接受的。并且待资源邀约计算出来之后,框架想怎么用那是框架的事情,可扩展性也没有受到影响。

既然选择了非强一致性的分布式实现,HA 这块的话我们选择让 Core 无状态部署。因此 Core 在理论上是可以无限制横向部署的,从而保证高效和可靠的调度能力。

主要功能

  1. 容器的编排和部署,采用 O(n) 的算法实现。

  2. 实现 Pod 的逻辑。单个 Pod 可以跨机房,可以做物理应用隔离。

  3. 构建容器镜像,通过 build 域的内容,通过 Core 可以打包出基于 Eru 镜像继承树的应用容器。

  4. 等待容器完成,实际上是提供了采用 Eru 资源的可控 lambda 接口,跑一个函数或者一个命令皆可。

  5. 备份管理。可以针对某一组容器做内部内容备份,并存于指定地点。

部署方式

  1. CentOS 7 上我们提供了 RPM 打包方式,可以通过 RPM 部署,具体可以参考这里

  2. 我们也提供了 Docker 化的 Core

  3. 可以通过 cli 工具使用已有的 core 去部署另外一组 core,完成自举。