Eru 怕是我写过时间最长的项目了，从 15 年容器圈编排调度混战之始到去年 k8s 大势已定，经历了 3 家公司到现在，它还活着并活跃在一些项目上。去年写了一篇容器战争阐述了对容器编排的一些看法，也看到了k3s这样有趣的项目印证自己的一些推断，但实话说我对这些事情其实很厌倦了，对于别人来说调度编排似乎是个很高深莫测的东西，对我来说真的…没啥有意思，因为决定平台地位的是上层工作流的定义和自动化，下面是哪个东西都行。换了工作后计划弃坑提出了换 k8s 的建议，不过没被采纳。
藉由做内部 Cloud 契机，又因为没有一个好的平台能调度编排非 application 的基础设施，Eru 继续被我用在了新的工作上。经过了这么久的重构和改造，倒也有了一些新的 exciting 的方向。
现有调度编排的一些问题
Nomad 是我最喜欢的容器调度编排系统，但很可惜，只有小部分人知道。比起它来说，其他的编排系统或多或少都有一些需要妥协的地方。
K8s 的复杂度和基础设施的侵入性，以及我们真的需要 all in one 么？就我自己的经验来说用户其实不知道自己要啥，往往他们需要是个自行车，但看到旁边有个坦克挂着 Google 的商标就吵着要这个东西了，工程师团队还不一定有会开坦克的。无论如何，作为一个老司机，我还是可以把坦克开得跟自行车一样的，要我我肯定选它，还能没事有事打一炮。
Mesos 成也 DRF 败也 DRF。大多数的场景下其实人力成本是大于资源成本的，DRF 和两层结构设计可以提高机器利用率，但多组件多语言的环境对人太不友好了。但最致命的其实是上层控制平面缺乏全局资源视野，我觉得这也是 K8s 后来居上的原因。实际场景下应用怎么部署应该是由控制平面来决定的，但由于 Mesos 的结构是以资源为导向进行分配，控制平面只能选择接受与否，这就产生的悖论：采用唯一的控制平面才能有全局资源视野，但这样双层调度就没有意义了。去年 Hulu 介绍了自己的 Capos 方案就是实现了自己的 scheduler 和 executor 来满足调度编排一致问题，Mesos 被弱化成了 DRF 的一个具体实现。
至于 Docker Swarm 这种死了的东西就不谈了。
一点个人的看法
我曾经在多个场合表达过对微内核技术看好的观点，比如 Hyper 及其后继者 Kata-Container。但对于 gvisor 这样不涉及到内核的沙箱模型来说，兼容性能2座大山短期内即便强如 Google 这样的公司应该也是翻不过去的。无论怎样，容器大概率上应该会往 Security 上靠，而这一点得基于更强的隔离。毕竟不以利润为导向的商业公司都不是合格的公司，而这几个大厂怎么可能不吃多租户公有云这块蛋糕对吧。
在这波发展中，多租户 Serverless 且强隔离的「容器」将会是重中之重。但就以这个时间点来说，我觉得反而 VirtualMachine 可能更加贴合这类需求，libvirt 就是一个比较好的选择。
Eru in 2019
我在使用 Eru 来做公司内部基础设施云的时候自然而然的就需要开始做 RDS 了。就以往的经验来说以容器作为载体去做 MySQL 快速部署也不是不行，但灾害控制数据备份迁移以及对应的 IO 才是 RDS 更加看重的部分，而这些恰恰是容器方面不那么好做的。再比如用容器伪装成「虚拟机」用于开发，那资源是硬限制呢还是软限制呢，硬限制容器猝死，软限制跟没限制没多大区别。因此在前同事 Anrs 的加入后，我计划改造 Eru 来做一个大一统调度编排的平台，允许混布和混编 VM 和容器，同时满足各类状态基础设施云化的需求。
首先要做的，就是抽离 Docker Engine 的绑定。讲实话用 Docker Engine 的 API 自己写调度啊也是一言难尽，可以明显看到多人协作下的风格割裂，比如有一个描述 Container 信息既有 Info 结构体又有 ContainerJSON 结构体，一个传值居多一个传引用居多。抽离之后，就可以实现自己的 Agent/Kublet 等来自定义 Executor 行为。
通过 Engine 的抽象使得 Eru 统一的计算资源和编排目标分布，然后根据不同的任务属性在不同的机器上部署 VM，容器或者其他类型的东西，甚至可以是 shell 命令，对于上层用户而言完全透明。在我自己的实验中，简单的实现了几个 Kubelet 的接口，就可以「像 K8s 一样部署 Pod」了。
完成了这个抽离之后，Eru 在 2019 年应该会向统一资源计算和编排平台方向继续演化，甚至可能通过 Eru 结合 libvirt 提供 K8s 作为基础服务交付给上层应用开发。虽然嘴上说着不想做平台了，不想搞底层了，但做这种事还是挺有意思的。
干活嘛，最重要的就是开心，能做成一个大一统平台差不多也就到头了。