本文主要介绍为了统一管理不同编排系统的网络模块,简化虚拟网络功能的开发流程,虚拟网络工作组实现的新虚拟网络架构–Cable。
前言
OpenStack 架构中,Neutron 作为虚拟网络模块,管理虚机的网络。随着容器技术的发展,越来越多的应用部署到 Kubernetes 等容器编排系统中,而 Kubernetes 也有自带的网络管理模块,如 Flannel,Calico 等。分别维护 OpenStack、Kubernetes 网络模块,不仅增加管理成本,且无法满足虚机和容器网络互通等需求。为了统一管理不同编排系统的网络模块,简化虚拟网络功能的开发流程,虚拟网络工作组实现了新的虚拟网络架构 Cable。
背景简介
目前公司的虚拟网络架构有如下不足:1 物理机、虚机和容器网络分开管理,无法达到直接互联互通。2 Neutron agent 里的 DHCP、metadata 采用集中式服务,健壮性不足。3 vxlan 实现时需要外部路由器的支持,较为复杂。
新的网络架构需要满足统一管理物理机、虚机和容器网络,实现直接互联互通;简化 Neutron agent,分布式架构实现 DHCP、metadata 等功能;在虚拟网络层面实现 vxlan;提供流量镜像等新功能。
方案实现
Cable 整体框架图
为了满足上诉需求,Cable 架构实现了如下两个关键点
1 虚拟数据平面
虚拟数据平面不再基于 OVS,而是采用功能更为丰富虚拟路由器 vrouter.ko。vrouter.ko 是 Juniper 的虚拟网络架构 OpenContrail 中的开源数据模块。相比于 OVS 的简单数据包转发,vrouter.ko 支持虚拟网络路由、vxlan、流表配置安全组、流表配置 nat/snat、流量镜像等功能。丰富的数据平面功能,简化了网络功能模块的开发难度。
2 自研管理平面
重新自研开发管理平面。管理平面统一管理 OpenStack 和 Kubernetes 网络模块;采用 Kubernetes 里的 watch 方式,主动监控平台资源变化情况,并执行相关操作;分布式实现 DHCP;用 vrouter.ko 中的 flow 功能实现 nat、安全组等。
Cable 工作流程
当用户请求到达 Neutron Server 后,Contrail Neutron Plugin 将请求转发至 Cable 的控制节点(Control Node)。控制节点的 proxy 转换请求发送至 API,API 将接收到的请求发送至相应模块,其中 controller 负责具体的计算和分配工作,IPAM 模块负责网络地址的管理。每台计算节点部署了 Cable agent,通过 Rest API 监听 Control Node 的资源,如监听到资源变化,则调用 vrouter.ko 执行相应请求(添加/删除/修改网络信息)。
与 Openstack 兼容
Cable 需要考虑如何与现有的虚拟网络结构兼容,使得 Neutron 能够平滑过渡到新的架构上。所以在保持 Neutron 原有接口不变的基础上,将 Neutron 的 db 替换为 etcd,并将 DHCP-agent,metadata-agent,l3-agent 替换为统一的 cable-agent。将 Neutron 用 Cable 替代后,OpenStack 的相关命令行和 Restful API 都没有变化,实现无缝切换,方便运维管理。
Cable 代替 Neutron 后架构图
总结
新的虚拟网络架构,兼容了不同网络平面,简化了网络功能模块,使得网络更为健壮。目前 Cable 的整体架构已经基本开发完成,实现了 DHCP、metadata 和 VLAN 架构网络,后续将实现安全组、VXLAN 等更多功能,并实现自动化部署,完善监控功能。
本文转载自公众号 360 云计算(ID:hulktalk)。
原文链接:
https://mp.weixin.qq.com/s/NWftZCQNfO4crjOoUExKWg
评论