Post #27

我司的编排系统目前的三大诉求 1. 固定 IP 背景是流行的容器引擎只有 start / stop API, 我们在有些场景需要一个 replace API, 重点是新容器能够继承旧容器的 IP 和 namespace, 难点是固定 IP. 真实的应用呢, 可以考虑创建容器化 etcd 集群, 无论是初始化还是动态扩节点都需要节 etcd 启动时就知道自己的 IP (要在命令行或者配置文件里硬编码写上), 在古典 docker 容器下这是不可能的, 所以我们希望可以先生成一个 init container, 拿到 IP, 然后 replace, 这样就可以构造出配置或命令行参数来运行服务. 从更大的视角看, k8s 不需要解决这个问题, 因为它是 pod 模型, 所以在启动应用的时候可以通过 hook 拿到 pause 容器的 IP; 但是 k8s 的问题是, 它不是通用编排系统, 不是为了支持 vm 等其他 runtime 而设计的, 当然可以支持 vm 而且已经又开源的 operator, 但是居然也要集成到 pod 模型下, 想象一下 vm 还要有一个 pause 容器组成 pod, 用 cmgs 的话说就是脱了裤子放屁. (当然好处不是没有, 这里不说了, vm 本身我的理解也很小白, 再过一段时间有机会恶补一下) 从容器标准 OCI 来看, 所有的这一切都不过是 hooks 而已, 要知道就连容器的网络 link 都是通过 prestart hook 搞进去的, 根本不是什么神奇的操作, 愿意的话只要在 sfterstop 里分别 hook 归还与否 ip. 不过实际来做的话却又不是那么简单, 因为几乎不会有人直接对接 runc, 否则光是 daemon 管理这一套都能让一群 web 程序员捉襟见肘; 那么更高一层的 containerd 眼下就很流行, 但是我看了一下发现 docker -> containerd 迁移成本其实也很大, 不说别的, containerd 压根从设计上就不打算暴露服务给 remote, 所以只提供 unix socket 监听, 所以先套一层服务封装一下, 这特么不就是 dockerd 了吗… 那么继续用 dockerd 的话, 压根连 hook 的 API 都没有暴露, 被 dockerd 吃掉了, 通过 oci 直接来做固定 IP 是行不通了. 不过如果继续用 dockerd 的话, 倒是可以在网络插件上动手, 对接 calico 的 CNM 插件是我们完全自控的组件, 只要能够在归还 ip 时并不实际归还给 calico ipam, 采取一个延迟归还, 或者 using -> released -> free 三级状态, 容器只是 stop 的时候 ip 进入 released 状态而不是 free, 那么可以很容易实现固定 IP. 细节不说了. 然而 cmgs 的态度是要把 dockerd 包一层, 用自己包过的 dockerd 提供服务的话, 我们可以直接为编排系统提供原生实现的 replace 接口, 简直丧心病狂, 但是实际做起来的时候由于 CNM 是内置在 dockerd 里面的, 所以也挺别扭, 我的态度是会花巨大的力气做一个看起很棒但其实限制依然很多的东西, 还不如直接在 CNM 插件上改呢. 如果说 CNM 做固定 IP 很 tricky, 那么直接用 CNI 就非常干净了, 只不过 dockerd 使用 CNI 又会有一种脱了裤子放屁的感觉… 官方做法又是先创建一个 namespace 容器, 然后 CNI 才能创建对应的 link 获取 ip 什么的; 这一点倒是可以通过裸创建 ns 来规避, 问题不大, 但是额外的工作可能是有的. 但我还是觉得比包一层 dockerd 要好啊! 2. diskquota 在我做好了把磁盘作为资源进行调度之后, 缺少的东西就是引擎对 quota 的支持的, 比如 /sda1:/data:rw:10G 这样的 volume 请求, docker 是不认识的. shopee sto 这群一言不合就 fork 然后自己改的家伙已经长期使用魔改后的 docker-ce 了, 其中就加入了对 xfs quota 的支持, 我看了一下代码, 居然是在 graphdriver 里的 quota controller 里改的, 其实挺, 不太好的, graphdriver 是 docker1.1 接口化的成果, 就是为了让人可以有接口协议做插件而不是硬编码改 docker-ce, 我也向来反对侵入式修改. 不过 cmgs 对这件事的看法居然也是把 dockerd 包一层…. 我…. 且不说 graphdriver 了, 我们直接用 prestart hook 调用一下 xfs quota 有何不好, 有现成的接口不用非要重新造轮子… 当然 dockerd 怎么去给 containerd 的 hook 加上 xfs quota 是个问题, 不过是可以想办法做的. 3. vm as runtime 意思是把 vm 作为 container 的代替物, 跑应用的时候先拉个 vm 起来, 里面用 systemd 创建应用进程, 达到完全的资源隔离. 实现这玩意儿我唯一的问题在于选型, 因为已经有符合 oci 的 vm 实现, 甚至连 hypervisor 都是可配置的, 那么是不是直接用这个会更简单呢, 毕竟因为 dockerd 也可以直接更改 oci 实现. 这倒是小问题了, vm 这一套本来我虾的政策就是放到 mesos 去管理而不是我们, 我们只是做得好玩….