自研 CNI 插件固定 IP 带来的问题，求助一下各位

[zhangtao]

由于我司业务和运维环境等多方面要求，我们使用了 CNI 插件 + macvlan 这种方式，实现了 pod ip 的固定。
可以这样理解：即一个服务我们会给它分配好一个 IP range （ 10.0.0.1 ~ 10.0.0.10 ），这个服务的 pod ip 始终是在这个范围内。

正常情况下，pod 正常关闭即可释放 ip 资源。但是遇到异常情况（例如 k8s node 宕机）则会导致 ip 资源无法释放，需要人工跟进手工处理。

不知有没有什么好的办法解决此类问题？

[yuzhiquan]

在 ipam 里维护一个固定 ip 和 pod 的对应状态，异常状态下的未释放 ip，这边是集群里部署一个 cronjob 定期清理...

[rrfeng]

node 宕机自然 pod 也不存在了啊，或者迁移了。pod 不存在了 controller 自然可以更新 ipam 。
感觉你逻辑设计的有漏洞。

[yuzhiquan]

@rrfeng node 突然挂掉的话，cri 没办法调用 cni 走一遍 del 流程，可能会造成 pod ip 没释放

[FabricPath]

写个 controller 去定期全量同步

[zhangtao]

@rrfeng node 挂掉之后，这台 node 上的 kubelet 是无法正常工作的，所以没法调用 CNI 的二进制

[menyakun]

CNI 的 CmdDel 其实不能完全信任，我遇到过 Pod 被删除，但这个函数没被调用的情况。
最好是在 controller 里面处理 Pod 和 IP 的绑定关系，CNI plugin 这层只是等待 Pod 的 IP 被分配好。
关于这些异常 IP 的清理，还是要每个节点一个 Daemon 来处理。

[zhangtao]

@FabricPath 这个方案我们考虑过，但是感觉不是很优雅，所以想看看有没有更好的办法

[zhangtao]

@menyakun 请问下 如何在 conroller 中处理 Pod 和 IP 的绑定关系，能否说的详细些

[choury]

你们没有 node 故障处理流程吗，就算这个 node 挂掉了，这个 ip 也是绑定在这个 node 上的啊，下架 node 的时候清理掉上面的 ip 不就行了

[zhangtao]

@choury 下架 node 没问题，现在的问题是 node 异常宕机，我们不希望人工介入处理，希望 node 异常宕机整个过程是全自动化 不影响业务的

[choury]

@zhangtao #10 你们是 ip 太少，所以要快速回收吗？按照我的理解，node 异常宕机，如果能自动修复，kubelet 肯定已经起来了，就会调用 cni 的删除操作，如果 node 起不来了，走下架 node 流程，清理掉这个 node 绑定的所有资源
还是你们遇到的是 node 起来了，但是 kubelet 并没有调用 cni 的释放 ip 操作？

[zhangtao]

@choury 不是 ip 多少的问题，是 ip 数量固定了；比如业务 A 需要 10 个 pod，因此就配置了一个有 10 个 ip 的 ip 段

由于 ip 未正常释放，即使 pod 重新调度之后也拿不到可用 ip，导致 pod 一直在 pending 状态

[choury]

@zhangtao #12 这个配置本来就有问题，需要给点余量的，包括滚动更新什么的也需要多余的 ip，而且不管用什么流程，node 异常后的处理都是要时间的，这段时间难道 pod 就不运行了吗

[defunct9]

信也科技 https://github.com/ppdaicorp 说是把改造过的 Macvlan 插件进行了开源

[yuzhiquan]

@zhangtao 额，你们的 ipam 的 backend 用的啥？ host-local ？

[zhangtao]

@yuzhiquan etcd

[yuzhiquan]

@zhangtao 哦，如果需要固定 ip，那 ip 就是服务的一种状态，就建议使用 statefulset 来部署，这样发布过程中保持 podname 不变，ip 就不变，就不用担心上面的情况了

[menyakun]

@zhangtao 把 IP 当作一个单独的 CRD 就行了，Pod 的 ownerReference 是 IP ；然后加个 MutationWebhook 在 Pod 这个资源上，处理 Pod 与 IP 的绑定关系

[andyangyu]

@menyakun 学习了

[zhangtao]

@menyakun 感谢