灵雀云
全栈云原生平台
帮助企业在任何云上构建、运行管理应用程序,覆盖应用全生命周期管理,300+金融/制造/能源等头部企业级云原生解决方案!
注册试用
获取云原生转型之旅
灵雀云亮相KubeCon 揭秘Kube-OVN IPAM容器网络实践
2020-08-20


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分配等,这些功能对多租户、隔离等场景都更加友好,对于管理来说也更直观。


02Kube-OVN IPAM 初衷及能力实现


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


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


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


PIC1.png



Kube-OVN IPAM能力实现:


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

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

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

IPAM internal

通过子网管理IP

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

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

 


PIC2.png


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


PIC3.png


在具体的实现中 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)开源项目集思广益提出建议,贡献力所能及的力量。


© 2024 All Rights Reserved. 灵雀云 版权所有 备 案号:京ICP备15011102号-2      隐私条款
电话咨询 在线客服 微信咨询 公众号