在混合多云的世界里,Kubernetes是如此流行,已经成为应用统一部署和管理的事实标准,而Tungsten Fabric与Kubernetes的集成,更增强了后者的网络性能和安全性,帮助实现业务落地。 4月28日,在TF中文社区线上直播活动【 TF Live 】中,社区技术代表杨雨与大家进行了在线交流,看看TF与K8s能碰撞出怎样的火花。 直播活动由TF中文社区和SDNLAB联合举办。
【pdf文档下载】https://tungstenfabric.org.cn/assets/uploads/files/kubernetes-sdn-tungsten-fabric.pdf
【高清视频下载链接】https://pan.baidu.com/s/1cnwFJ3pmoY7HPnLCH37hbw
提取码:guxu
杨雨曾负责多个大型金融云平台、企业云平台的建设,专注于运维自动化、SDN和分布式存储。作为2016年就接触Tungsten Fabric的老兵,他在4月28日的直播与互动中输出了很多硬核干货,和大家分享了多年的技术积累和实践。
Tungsten Fabric曾用名OpenContrail,2018年3月迁移到Linux基金会。一句话概括TF的核心技术,就是基于BGP MPLS VPN技术。
BGP MPLS VPN技术在运营商的广域网络有了20多年的应用历史,是一个比较成熟的技术。运营商基于BGP MPLS VPN技术,基于同一套网络基础架构和线路的基础上,为不同的网络租户提供了跨广域网的虚拟专线服务。
BGP MPLS VPN技术的核心就是通过BGP协议作为控制平面,实现不同站点之间的路由和VPN信息的交互,BGP协议就是一个分布式的控制器。数据平面就是有MPLS标签的隧道实现传输,做到流量的隔离,同时也可以借助ECMP等技术来做链路的负载均衡。
Tungsten Fabric将广域网中的BGP MPLS VPN技术运用到了数据中心。在虚拟化的环境中,原来部署在运营商端点的PE,现在变成了部署在每个计算节点上的vRouter。换句话说,vRouter承担了PE的角色。不同虚拟网络的虚拟机,接入不同VRF后实现了隔离,通过隧道协议实现数据传输。在控制平面上,MAC地址A和B的通信,都是通过BGP协议实现信息的下发和交互。
在多云互联、性能和扩展性方面,Tungsten Fabric都将SDN提升到了一个新的水平,在不同的数据中心(包括公有云和私有云)的部署中,轻松实现了虚拟机、容器、物理机的统一SDN环境。 在性能上,Tungsten Fabric支持原生Kernel转发,可以限速跑满一个万兆的网卡。通过控制器形成集群和分布式数据库的采用,Tungsten Fabric具有非常好的规模扩展性。在目前的实际部署中,基本都大于200个计算节点,到上千个计算节点。通过不同控制器,还可以建立EBGP邻居,实现跨多个集群的虚拟网络的互联。
图:TF功能一览
Tungsten Fabric对接的负载类型,包含虚拟机、Linux虚拟机、容器、裸机等,这些工作负载都通过TF统一的SDN控制器实现互联。而上层的云管平台,包括OpenStack、K8s、VMware,以及一些公有云平台,也都可以实现多云的统一SDN管理。
更重要的是,Tungsten Fabric可以提供丰富的网络功能。在不同的虚拟网络(如VS栈的虚拟网络或GRE的虚拟网络)上,基于不同的三层列表、二层路由表来实现隔离,同时也提供DHCP、DNS、以及IP地址管理等功能,以及防火墙、安全策略、负载均衡、服务链、监控、分析等功能。
这么多功能怎么实现的?就是通过Tungsten Fabric的控制器。
控制器基于BGP作为SDN的控制平面,实现相应的路由条目、二层转发表的管理,同时支持OVSDB实现对物理设备的配置。物理机可以通过VLAN接入TOR交换机,再转成VXLAN,和相应的容器或虚拟机、虚拟网络互通,这些都是通过BGP和OVSDB实现的。
实际上,Tungsten Fabric一开始主要支持Openstack这样的虚拟化的集群,而对于Kubernetes的对接,有些概念还需要进行对应关系的映射。比如Pod的扩展,相当于TF里面的一个虚拟机,一个Interface,五个Instance-IP。
再比如K8s里面有很多Service类型,在TF这边相应地对应于ECMP的负载均衡。怎么理解?传统的负载均衡方案,比如F5设备等,是在四层包括七层实现负载均衡,而TF使用BGP路由技术,虚拟IP的下一个,可能就是一个真实物理服务器的IP,可以使用路由里多个下一跳的条目,来做等价路径的转发,在路由层面实现比较高效的负载均衡。
另外,K8s的Ingress,相当于7层的一个负载均衡,使用内置的HAproxy来实现。
(对此,网友也提出很多Tungsten Fabric与K8s的技术问题)
Q:TF是用来替代K8s使用的Calico这种网络的吗?
首先,两者定位是一样的,Calico核心原理也是基于BGP的。但在功能实现程度上,Calico是基于IP TABLE的,不带VPN功能,只相当于TF的一个子集。在多云互联的场景,包括一些隔离的场景,和TF是有很大差距的。Calico的好处是比较简单,这种应用IPinIP的模式没有overlay的开销,比较适合在云上部署,因为云的网络已经是overlay网络了。简单的总结:Calico是一个简单可依赖的网络方案,适合小规模的集群或部署在云上的K8S集群。TF在可扩展性、多云互联和网络隔离能力上会更强。
Q:TF是否是取代K8s内的kube-proxy?
Kube-proxy在TF中只会应用在NodePort的场景。Kube-Proxy会在用户态监听相应的端口,转发给vRouter,由vRouter来实现相关的DNAT功能。
Q:TF使用了BGP,需要让企业内部的接入交换机、核心交换机都开启BGP吗?
TF对于设备的要求可以分几块来看:
出口网关Cloud Gateway,这个是TF Overlay虚拟网络和物理网络的主要连接点,需要支持MP-BGP和GRE隧道或者UDP隧道;如果需要TF管理配置下发,也需要支持NetConf;
BMS TOR交换机,用来实现物理机VLAN网络和TF的虚拟网络实现二层桥接的设备,需要支持EVPN-VXLAN协议;
Underlay网络交换机,就是用于连接各个计算节点,控制节点和BMS TOR以及Cloud Gateway的底层网络。由于TF是在vRouter, BMS TOR, Cloud Gateway实现了隧道的解封包,所以对于Underlay的网络交换机特性没有特殊的要求,只要各节点之间三层可达即可。小规模可以用静态路由,大规模可以用OSPF或者BGP;
TF对于设备是没有锁定的,只要支持相应的协议,都可以使用。但是不同厂商的协议的支持程度会有差异。如果不想做大量的测试和适配工作,Juniper的产品是优先选择,其它品牌的产品就需要在投入生产前做一些测试验证。
Q:K8s Service天然就有LB功能,这个和您讲的ECMP提供的负载均衡有什么关联呢?
K8s的LB功能也是由TF来实现了,只不过还是基于路由层面的ECMP来实现均衡,当要控制URL映射的时候,路由层面就做不了了。TF会使用Harpoxy来实现。
(关于TF与K8s的对接,杨雨在直播中进行了Demo演示,展示了Tungsten Fabric基本功能,与Kubernetes的集成对接,以及Service与External IP演示等,感兴趣的朋友,点击下方链接观看)
链接:https://pan.baidu.com/s/1cnwFJ3pmoY7HPnLCH37hbw
提取码:guxu
在两者的对接方面,Tungsten Fabric提供了标准接口,与K8s的集成还是基于CNI对接的,需要几个组件之间进行配合。
包括Kube-manager对于K8s Pod相关变动的监听,并将相应事件转成动作,调用TF API完成网络、接口创建等。
扩展起来后,TF的CNI组件负责查询Pod接口信息,把Pod的veth插入到vRouter里面去,完成网络的对接。
Q:TF和K8s的资源映射关系是双向同步的吗?
是的,TF资源映射的关系是双向同步的,以K8s为准,K8s这边删除就删除,K8s创建就做相应的创建。
Q:namespace的隔离是逻辑隔离、底层网络还是互通的,VRF是基于网络的还是什么?
默认情况下,不做任何指定的话,namespace是没有隔离的。可以开启隔离功能,或者指定就要隔离,在安全策略里,就不允许访问新创建的namespace,namespace之间就不会通。Tungsten Fabric对于不同网络接口之间的访问策略,都是比较灵活的。
Q:TF可以生成环境中的流量展示信息么?可以看到服务之间的访问关系,支持root cause分析么?便于管理员在故障期间分析是哪里出的问题。
流量分析是支持的,可以抓包,也可以通过service chain做镜像分析,安全策略等访问的展示,可视化可以基于Tungsten Fabric的界面去做,也可以接口做二次开发。
以上就是本次TF Live直播的精彩内容,这里有一些TF+K8s的指导文章,可以作为参考资料。
往期回顾
TF Live丨KK/建勋:多云、SDN,还有网工进化论
Tungsten Fabric +K8s集成指南系列
第一篇:部署准备与初始状态
第二篇:创建虚拟网络
第三篇:创建安全策略
第四篇:创建隔离命名空间
Tungsten Fabric +K8s轻松上手系列
TF Carbide 评估指南–准备篇
通过Kubernetes的服务进行基本应用程序连接
通过Kubernetes Ingress进行高级外部应用程序连接
通过Kubernetes命名空间实现初步的应用程序隔离
通过Kubernetes网络策略进行应用程序微分段