search

projecteru2 / docker-cni

6 stars 4 forks source link

[Proposal] Fixed-ip #3

Open jschwinger233 opened 3 years ago

jschwinger233 commented 3 years ago

本着开发封闭的原则, 这部分工作其实是甩给 barrel 的, 但是我觉得这片净土比较适合写 proposal...

总得来说, 现有的 docker-cni 的流程是:

shim -> docker-cni -> cni-bin (calico)
                   -> oci (runc)

-> 表示一次 fork(2) + exec(2) 的进程调用, 下同.

为了支持 fixed-ip 特性, 我发现只要再多加一层就可以了, 变成:

shim -> docker-cni -> cni-wrapper (barrel) -> cni-bin (calico)
                   -> oci (runc)

多加的这层 cni-wrapper (其实就是 barrel 二进制):

  1. 在没有 fixed-ip 标记的时候啥都不干, 透明的;
  2. 在有 fixed-ip 标记的时候: a. add 流程里, 根据 ID(或者 IP) 去查询 barrel db, 有结果就直接返回, 而不必再调用 cni-bin add; 如果调用了 cni-bin add, 则把结果记录在 barrel db 里; b. del 流程里, 不调用 cni-bin del, 只是更新 barrel db 里的数据状态;

剩下要处理的就是 remove, 让作为 dockerd-wrapper 的 barrel daemon 去真正调用 cni-bin del 释放 ip, 就可以了.

jschwinger233 commented 3 years ago

周末重新想了一下, 需要对现有的 docker-cni 做一下简化, 对之后的 fixed-ip 也有好处.

几个核心的点是:

  1. 非 fixed-ip 的方案里, 不再需要旁路 netns, 这一点的实现依赖 oci hook 会把进程 pid 通过 stdin 传给 hooker
  2. fixed-ip 的继承 ip 功能, 只能限制在同一节点上继承, 这既是因为 netns 不能转移节点, 也是因为容器 ip 最好还是按照 calico block 去分布, 有利于路有收敛
  3. 在 ② 的设定下, 我发现直接用文件系统来做存储是更好的选择, 能有效解决"处理 etcd io 失败时怎么办" 和 "race condition" 的问题