在Linux基金会主办的“LFN技术会议”上，Tungsten Fabric社区进行了一系列演讲，介绍最新的功能和未来发展方向。今天带来第一篇演讲，看看Tungsten Fabric在2021年将聚焦哪些亮点功能和项目，以及计划涵盖的主要创新领域。
大家好！我是Nick Davey，现在是早上8点，我刚喝过咖啡，会尽量保持清醒，非常感谢你们这么早参与进来，感谢有这个机会与社区进行探讨。
我是瞻博网络的产品经理，日常工作是以各种形式使用Contrail和Tungsten Fabric，我认为自己在Tungsten Fabric上投入的情感更多一些。特别是过去的几个季度，在整个社区——包括瞻博网络CTO在内——大家的努力下，有了一些新的进展，我很期待看到一些伟大的事情和蓝图正在展开。
我们在社区中扮演着独特的角色，作为开发者，我们推动一些功能往前走，确保我们在Juniper所做的事情，能够转化为对于社区来说具有可行性的东西，这是一个不小的挑战。但我们与社区中的技术专家和领导者一起，找到了一种方法，使功能或项目回到符合我们的意图和愿景的道路上，我认为我们已经做出了有意义的改变。
那么我们到底要做什么？这里我整理了几个简要事项，关于重点领域已经和将要推进的工作。我会围绕其中的一些点进行讨论，希望这些项目能激发大家的讨论，如果有任何问题或评论，请直接提问。
我把要关注的工作集中到两个框里。第一个是让Tungsten Fabric更具时代性，适应更多的云原生用例。Tungsten Fabric社区一直是走在网络前沿，我们已经有了一个令人难以置信的强大的解决方案，首先是开放的 Contrail，然后是用于容器编排和网络的Tungsten Fabric。我想这要追溯到两年半以前，那时我们已经有了一套强大的K8s功能套件项目。今年的主要进展之一，是更动态地适应可用的K8s服务和API端点，并允许我们部署较新的版本。
每当Juniper内部有一个版本发布的时候，我们都会进行资格认证，针对不同的编排器和不同版本进行测试。之前几乎所有的测试都是围绕着K8s 1.12进行的，然后我们通过了对OpenShift 3.11的支持，将K8s版本推到了1.14和1.16，而现在已经进行了包括1.18在内的资格认证。我们花了很多时间来覆盖1.16和1.14之间的版本。你可以对使用当前版本的K8s开展工作抱有信心，可以使用K8s RK DS版本参数部署任何版本的K8s。总之，我们现在已经运行在Kubernetes 1.18上，它的工作状况也非常棒！
我知道这不是什么头条，但对于跨编排器和跨多个版本保持灵活性，这件事真的至关重要。K8s已经显示出非常快的创新步伐，所以我们需要确保跟上。确保花很多时间测试这些版本，确保一切都能正常工作。在K8s里面增加了对多接口网络的支持，这里面也有一堆工作。它们引入了对多网络附件定义的支持，对于多接口pod是一个非常非常长的路。
多接口pod背后的想法是，pod的每一个接口都会连接到CNI，提供一套差异化的服务。电信行业用户设想了一个部署模式，默认的pod网络提供安全的管理访问，然后一个或多个数据平面接口将提供直接访问或访问底层网络的支持。
这些设想的方案，往往集中在多CNI方面，每个CNI通常有一个或多个接口。我们与Tungsten Fabric社区一起工作，去了解电信客户设想的这个功能的用例，真的是需求什么。我们一起合作，开发自己的网络附件定义。
我们仍然使用相同的manifest来控制这个功能，所以当你使用Tungsten Fabric的时候，它是相同的配置来创建多个接口，在K8s manifest里面实际的附件定义会触发Tungsten Fabric上虚拟网络的创建，这真的很酷。现在你可以让集群租户自己服务于自己的网络，但关键的区别在于，所有的网络连接都是由单一的CNI来交付的，Tungsten Fabric交付你在pod上创建的所有接口。这很好，符合电信运营商用户的需求，要注意的是，对这些工作负载有一些不同类别的连接要求，通常像SRIOV这样的需求会排在前面。
在此基础上，一些应用如OKD和红帽OpenShift，会假设Multus是不间断的，Multus将成为K8s生态系统的一部分。团队提供了对Multus的支持，这使得Tungsten Fabric仍然有多个接口连接到它，提供这种强大的和电信级路由器一样的体验。基于Tungsten Fabric可以有多个接口，连接到不同的虚拟网络，服务于不同的功能。并且，你还可以复用正在使用的实际的CNI。我们前进的方法是与上游保持一致，时刻考虑客户和社区成员的用例。
围绕IaaS领域，也发生了令人兴奋的变化，特别是我们作为系统运营商如何管理虚拟机方面。K8s正在变成几乎所有东西的首选编排器，有越来越多的功能被添加到这个平台上。KubeVirt最新的改进，是允许使用一堆客户资源定义在K8s里面运行虚拟机。这代表了一条非常宽广的前进道路。首先，向云原生和容器的过渡，这不是一朝一夕的事情，通过在K8s集群里面添加虚拟机对象，我们现在有了选择，可以更快地从传统的VMware和OpenStack编排器中转型。如果这是我们的计划，显然这些技术需要一段时间才能成熟，但我们要确保Tungsten Fabric在这个转型的前沿。我们正在努力并计划在短期内提供基于K8s在Tungsten Fabric上部署虚拟机的能力，已经有一堆代码提交以确保其能够运行，同时团队仍在进行功能的测试和验证，保证它能很好地工作。
最后一项工作是针对高性能容器部署的工作，我们正在紧锣密鼓地将DPDK接口引入到容器中。目前TF可支持DPDK 19.11的版本，将过去我们所依赖的一些旧的DPDK代码从Tungsten Fabric中移除，这是我们向前迈出的一大步。社区也围绕这个做了很多工作，确保大家所有的努力工作首先是要提供真正的功能、产品和项目。
我们已经花了大量的时间在DPDK上，无论是在Juniper内部，还是社区内部的工作，结果都是非常美妙的，我已经看到了一些数据，基于新的MD硬件，使用最新的DVDK库，可实现每核心每秒320万个数据包转发。考虑到还可以通过额外的核心来扩展这一事实，我们有一个真正的、非常强大的高性能解决方案！我们现在正寻找将这种类型的软件加速的数据平面带入到容器中，并与社区成员合作，以确保联合做到这一点。
现在我们的经验是，很多初始的容器网络功能都是依赖于SRIOV，所以我们正在利用的一个解决方案是Multus和SRIOV CNI组合来提供SRIOV，目前我们正在与容器网络功能厂商、电信用户，以及运营商项目成员合作，了解连接这些SRIOV最理想的模式是什么。这完全是云运营商的选择，但我们认为，那些希望使用更多分解堆栈的人，与那些希望看到这种能力内在地建立在单一数据平面中的人之间会有分歧。
这真的是我们在云原生方面的关注点。世界正在走向云原生的未来，OpenStack也有一个漫长而充满活力的未来，有很多很多的OpenStack部署正在进行，大型的OpenStack项目正在出现，这些云才刚刚开始，它们会成长和扩展，提供更多的服务，它们会发展到更多的区域。总之，OpenStack是不会消失的。我们需要认识到作为一个项目和一个社区，我们的角色是脚踏两个阵营：帮助传统的云运营商，以最小的影响方式迈向云原生的未来。
为了做到这一点，我们正努力将很多现有的生命周期管理变得具有时代性，所以在TF社区做了大量的工作，增加了对Ubuntu新版本、Charmed Canonical OpenStack新版本和Red Hat OpenStack新版本的支持和更新。这可能是我们大家做的最辛苦的工作，是最不容易被发现的，或者说是最不容易兴奋的，直到不能运行了才会被发现。
通过支持更具时代性的编排器和版本，也带来了新的生命周期管理和新的模式。围绕Tungsten Fabric的运营，包含了大量难以置信的工作。运营商将是我们打算如何生命周期Tungsten Fabric向前发展，不仅是OpenShift K8s，也是所有的OpenStack dest drawers，我们部署典型的虚拟机和微服务将嵌入现在的逻辑，为运营商部署Tungsten Fabric容器，并嵌入所需的逻辑，以扩大或缩小规模，或升级这些容器。通过云原生的框架来管理Tungsten Fabric的控制和数据平面，随着编排器的发展，随着工作负载更多走向云原生，我们很好地将其插入到这些容器中，并提供虚拟机和容器之间的网络。
还有两块正在做的工作，是考虑到我们的解决方案往往部署在基础设施网络为关键任务网络的情况。第一个是我们正在提高路由器的弹性，以检测和应对网络故障或变化，你看到的是第一种工作，trickle in，现在有可调节或可适应的XMPP定时器，这是更快地检测到故障的第一步，所以现在我们允许在所有的vRouter节点上实现XMPP可调节。下一步是围绕服务和可能情况下的传输下一跳，提供快速收敛功能，我们正在寻找适应BGP前缀独立收敛，或选择安装服务路由的备份路径等概念，以便在发生控制器或网关故障时，我们的反应能够更快。我们还希望根据需要引入对其他hello和keep alive协议的支持，以方便更快地检测到链接丢失。
现在正在进行的第二项弹性和可靠性工作，是改善Controller和vRouter的升级体验。首先的工作是能够在不重启的情况下升级vRouter。这听起来很枯燥，但其实我们是用一个非常整洁的机制来完成这个任务的。我们对重启的要求，最常见的是需要连续的内存驱动的，通过利用标准的巨量页面部署，我们可以保证有大块的连续内存，从而有更顺畅的升级体验。
此外，在其它零碎的事项上，我们也做了一些工作。第一个是关于数据平面学习，这是以前没有在Tungsten Fabric中做过的事情。我们通常依靠一个编排器来通知控制器Mac IP地址和端口绑定，然后用这些条目填充转发表，并将这些条目传播到集群内部和外部的所有端点。我们看到大量的网络功能被部署在Tungsten Fabric或者vRouter上面的容器、虚拟机里面，结果是传统的机制留下了一个盲点，我们不会有一个编排器来通知这些工作负载的位置，所以必须被动地观察它们，听起来很像flood and learn，但是我们做得更聪明一点。我们现在有了动态学习这些端点位置的机制，所以如果大家在运行assay、任意工作负载或透明服务链，它们就可以在每个虚拟网络的基础上启用这个功能，并看到这些转发条目动态填充。
我们也认识到在这些容器上面部署了关键的基础设施，我们把动态服务健康检查也作为一个选项嵌入到这些容器中。
最后，我们现在围绕连接服务器的网络设备的自动化做了很多工作，这一切都始于围绕OpenStack ML2推动的一个项目，用于网络供应，现在正在扩展到允许为OpenStack连接计算节点的SRIOV虚拟功能的自动供应。现在网络中存在一种自动化的漏洞，当我们通过Tungsten Fabric在分配或连接到一个提供商网络时，我们提供一个fabric结构，这是对数据平面的信号，我们希望能够提供一个虚拟功能，但实际上没有任何东西去为我们提供这种连接性。也就是说，如果我们说VLAN on WAN上分配了虚拟功能，在底层网络中并没有任何东西可以确保VLAN on WAN的存在。而这些能力将允许我们通过VLAN on WAN上动态地提供适当的交换机端口，允许OpenStack运营商动态地驱动网络中的配置变化。
以上就是TF社区近期的亮点，我们最近所做的一些重要事项，希望为2021年即将到来的事情做铺垫。
Tungsten Fabric内部专注于云原生绝对会带来很多变化，未来会迫使我们做出改变，如果我们只是在它们到来的时候做出反应，会错过更广阔的画面。我们很乐意与TF社区合作，未来会以更多的云原生方式适应或推动我们的工作。
