在混合多云的世界里，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邻居，实现跨多个集群的虚拟网络的互联。
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来实现。 | |
| |
| Virtual-machine, Interface, Instance-ip |
| |
| |
| |
| |
（对此，网友也提出很多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吗？
出口网关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里面去，完成网络的对接。
是的，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轻松上手系列- 通过Kubernetes的服务进行基本应用程序连接
- 通过Kubernetes Ingress进行高级外部应用程序连接
- 通过Kubernetes命名空间实现初步的应用程序隔离
- 通过Kubernetes网络策略进行应用程序微分段
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
