JustHaveTry 2020-04-30
在混合多云的世界里,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 V P N技术。
BGP MPLS V P N技术在运营商的广域网络有了20多年的应用历史,是一个比较成熟的技术。运营商基于BGP MPLS V P N技术,基于同一套网络基础架构和线路的基础上,为不同的网络租户提供了跨广域网的虚拟专线服务。
BGP MPLS V P N 技术的核心就是通过BGP协议作为控制平面,实现不同站点之间的路由和V P N信息的交互,BGP协议就是一个分布式的控制器。数据平面就是有MPLS标签的隧道实现传输,做到流量的隔离,同时也可以借助ECMP等技术来做链路的负载均衡。
Tungsten Fabric将广域网中的BGP MPLS V P N技术运用到了数据中心。在虚拟化的环境中,原来部署在运营商端点的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的,不带V P N功能,只相当于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对于设备的要求可以分几块来看:
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的指导文章,可以作为参考资料。
往期回顾
Tungsten Fabric +K8s集成指南系列
第一篇:部署准备与初始状态
第二篇:创建虚拟网络
第三篇:创建安全策略
第四篇:创建隔离命名空间
Tungsten Fabric +K8s轻松上手系列