Post #29

cmgs 之前提过一个想法是让 cnm 调用 cni, 那么根据我目前的理解, 这件事不会特别好做. 首先 cnm 是更加细粒度的 api, 要用 cni 实现 cnm 是无法准确分步实现的. 其次 cni 的接口是要求传入 container_id 和 netns_path, 那么问题来了, 我没有创建容器哪来的 network namespace, 所以你才会看到 K8s 的 pod 这垃圾玩意儿, 先创建一个 pause 容器, 那不就有 netns 了嘛…. 他妈还发博客说什么 cnm 和 docker 耦合太紧所以采用了 coreos 的 cni, 结果你自己的接口又完全和 pod 模型耦合, 吃屎吧. 当然我本可以.. 先创建一个 netns, 让容器 attach 上去就可以了, 然而 docker run api 没有这种选项, 我去, 就连自定义 cnm 都实现不了, 创建 netns 是硬编码的实现, 是插件之外的实现, 操, 那么唯一的办法就是我在上面的那样了, 先创建一个 sleep 的容器, 然后就可以 docker run --net container:$ID, 这不就是 pod 模型了嘛! 妈的 其实 oci 这种完全中立的标准是一点问题都没有的, 在 runc init 之后, netns 创建好, 但是应用进程没有启动, prestart hook 运行 cni 还是 cnm 都刚刚好, 但是 docker 硬耦合 cnm, containerd 只有 cni, 我面对这一堆开源电子垃圾真是锤胸顿足. 结论, cni 几乎无法实现 cnm.