自研 CNI 插件固定 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 感谢