灵雀云亮相 KubeCon 揭秘 Kube-OVN IPAM 容器网络实践

8 月 1 日，首届 KubeCon 2020 线上峰会圆满结束。灵雀云资深云原生网络专家刘梦馨发表了《适用于具有多个网络接口 Pod 的通用中央 IPAM》的主题演讲，重点介绍了灵雀云和 Kube-OVN 开源项目如何通过通用 IPAM 来处理多网卡下容器 IP 的分配，以及 Kube-OVN 在这方面的用户实践探索和解决方案。

他主要从四个方面阐述了当天的演讲主题。首先，什么是 IPAM，容器 IPAM 和普通 IPAM 的区别。其次，Kube-OVN 为什么要做 IPAM，有哪些功能是现有社区方案和开源项目无法解决的。再次，通过内部实现和样例演示介绍 Kube-OVN 如何解决该问题，并对未来功能进行了展望。

01

为什么需要新的 IPAM？

谈到 IPAM 就必须要提到 CNI 网络规范，官方提供的网络插件主要分成两部分：Main 和 IPAM。Main 主要功能是创建网卡，创建方式有多种，比如用 Veth Pair 创建网卡对，IPVlan、MacVlan 创建虚拟的子接口。IPAM 是网络规范另外一个很重要的部分，它包含有了容器网卡后，网卡应该有哪些 IP 信息，这包括 DHCP、Host-Local、Static 等网络插件。

他指出，社区官方提供的 IPAM 都有自身的局限性。比如，DHCP 为节点分配 IP 的机制非常传统，需要 L2 连接(MacVlan / IPVlan)，对 IP 分配的控制非常有限(mac -> IP)，也没有子网、静态 IP、路由配置等功能。Flannel 和 Calico 都支持的 Host-Local 尽管是分布式分配机制，所有 Host-Local 都依赖于本地文件，每台主机可以在分布式的区域分配 IP。但也有明显的缺陷，IP 是和主机绑定的，不能漂移到其他节点，很难更改容器的 CIDR 范围，很难对容器网络进行扩展。此外，也没有子网、静态 IP、网关配置等功能。

Calico IPAM 是功能上更强大的 IPAM 实现方式，每个命名空间对应一个 IPPool，支持通用管理，CIDR，tunnel 和 NAT 配置每个 IPPool，但是不能被其他 CNI 插件使用。

Kube-OVN 提供的 IPAM 功能更加齐全，namespace 和子网绑定，支持子网间访问控制，支持 CIDR、Exclude IPs、Gateway、NAT 配置，支持静态 IP 分配等，这些功能对多租户、隔离等场景都更加友好，对于管理来说也更直观。

02

Kube-OVN IPAM 初衷及能力实现

他在演讲中介绍了某电信用户的案例，这也是促使 Kube-OVN 做通用 IPAM 的原因。

他指出，该电信运营商有 Pod 多网卡的场景需求。主网卡使用 OVN、Flannel 或 Calico 等常见的网络类型实现容器的管理。除此之外，该运营商还有高性能数据传输的需求。由于容器是部署在用于核心交换的 BGP 节点的机房，对网络性能和吞吐量要求很高。

关于网络管理，解决这种需求常见的方式有用 Host-device 直接把宿主机上的物理网卡加载到容器里，或者用 macvlan。对于高性能数据传输，需要有静态 IP、子网、和 IPPool 等管理方面的支持。Kube-OVN 凭借自身比较完善的功能很好地实现了上述两大功能需求。

Kube-OVN IPAM 能力实现：

• Controller 管理子网 CRD, IP 分配/释放和静态 IP 分配

• Controller 用分配的 IP/MAC 和其他元数据注释 Pod

• CNIServer 读取 Pod 注释来配置网络接口

• IPAM internal

• 通过子网管理 IP

• 使用 FreeIPList, ReleasedIPList, ReservedIPList 实现不同的 IP 分配算法

• 使用 map 记录 address /pod 关系，保持静态分配

他着重指出，Kube-OVN 是基于 OVN 的网络插件，但是在 IP 分配方面反而跟 OVN 是完全解绑的。尽管在早期，Kube-OVN 用 OVN 的 IPAM 能力实现过一些功能，但在最新版本里，整个 IPAM 的逻辑是跟 OVN 脱离的。因此，Kube-OVN 有机会将这套框架复用到其他网络，以及多网卡的情况。

在具体的实现中 Kube-OVN 使用 Multus-CNI 来管理多个网络插件，并修改 Kube-OVN 的逻辑为多个网络插件提供 IPAM 能力。第一步需要将 Multus-CNI 中的 NetworkAttachmentDefinition 和 Kube-OVN 的子网对应，这样 Kube-OVN-Controller 就可以纳管第三方网络的子网进行地址的管理和分配。第二步需要在 Kube-OVN-Controller 对不同的网络分配不同地址和 annotation 方便之后在每台机器上运行的 Kube-OVN-CNI 进行区分使用。第三步在第三方网络插件的配置文件中关联 Kube-OVN-CNI 的 IPAM 插件，这样第三方网络分配完网卡后会调用 Kube-OVN 的插件获取分配到的 IP 地址。

03

未来计划

Kube-OVN 为 macvlan 这样一个没有任何能力的网络插件，提供了全局子网和固定 IP 能力。未来还有许多事情可以去尝试。

第一，Kube-OVN 可以扩展一些可分配的字段。很多元数据信息是现在的网络插件没有提供的。比如 Host-device，DeviceID 是缺少中心管理的，Macvlan、Vlan 也是如此。所有需要通过集中式方式管理的，都可以通过 IPAM 的能力来进行扩展。其次，一些路由、DNS 等附属信息，以及用户自定义传递的信息，比如 label，注释，用户自定义的一些元数据，都可以通过 annotation 的方式传递，实现一种通用的多信息分配方式。

第二，Kube-OVN 团队也在思考能否将 IPAM 完全独立出来，实现主网卡也可以利用 IPAM 的能力。

他最后号召大家访问 Github，为 Kube-OVN（项目地址为：https://github.com/alauda/kube-ovn）开源项目集思广益提出建议，贡献力所能及的力量。

据悉，在社区版基础上，Kube-OVN 计划推出商业版功能和支持服务，近期将正式发布，敬请期待！