SukhdevKapur，瞻博网络特聘工程师大家好，我是SukhdevKapur，来自TungstenFabric（以下简称TF）社区技术指导委员会。下面介绍一下TF架构和技术的现状，以及最新的进展。TF架构和部署模式我们可以看一下这张TF的宏观架构图。整体图描述了设备的物理连接，右上角是虚拟机之间的逻辑网络。TF的基本工作原理和机制是你创建一个VM或者POD，然后把它们（通过SDN）放到这些逻辑网络中。在这些逻辑网络中，您可以根据业务需要放置任何虚拟机、PODS或裸服务器。他们实际位于何处并不重要。它们可能位于集群或机架中。没关系。让我们再来看看它的下半部分。TF会使用虚拟路由器（在计算节点上）来负责这些虚拟工作负载的转发，左边是物理网络连接，比如裸机物理网络。一旦你定义好网络后，它可能会连接到实际的网络，也可能会连接到右边逻辑网络中的虚拟网络中的虚拟机。第四部分（上半部分）是CONTRAILController（SDN控制器），用于配置ControlAnalysis和CSN。第五部分是网关的功能，可以是物理网关，也可以是虚拟网关。当数据中心内的虚拟机需要与外界连接时，网络通过IP即MPLS协议进出骨干网。所有这些都是通过ORCHESTRATOR编排器管理的，它可能是OpenStack、K8s或OpenShift，并通过API安排TF工作。TF中Vrouter的架构概览这张图是TF的路由vRouter的架构图。左上角是vRouter的Agent，主要是控制部分。它将在这里学习路由、定义VRF和定义策略。如果虚拟路由器要执行策略，则必须由Agent控制：它决定网络流量是否允许通过，如果允许，应该转发到哪里。可以看到vRouter有一个转发路径，学习到的路径被封装起来，然后转发二层或者三层数据流量。vRouter的部署方式下面是TF虚拟路由器的四种部署方式。左上角是默认模式，部署在内核的vRouter中。右上角呢？如果你处于高吞吐量、高流量的状态，并且网络支持DPPK，TF可以部署DPDKvRouter。左下角其实是混合部署模式。如果您有多个VNF和其他可以使用SR-IOV的虚拟网络功能，则可以使用SR-IOV和内核vRouter共存的混合模式。第四种是基于SmartNIC的vRouter，即这些VM可以充分利用所有处理器的能力。TF与Kubernetes的整合我们来看看TF与Kubernetes（以下简称K8s）的整合。首先，TF的CONTRAILController会通过API与K8s进行通信。那么，它是如何获取指定位置的IP地址和策略的呢？怎么样？首先K8s会和TF的Scheduler通信，也就是调度管理程序，然后通过调度管理程序和CNIPlugin进行通信。左上角展示了vRouter是如何获取K8s上的policy进行IPAM读取和执行的，简单来说就是K8smanager会和TFCONTRAILController通信来确定网络策略，然后TFController会发布这个policy到vRouter。TF的微服务架构TF的技术演进一开始主要是基于虚拟机部署，后来开始支持容器技术，现在已经演进到微服务（Microservices）架构。目前我们的TF是以容器的方式部署的，大约有27-30个镜像。K8s环境中的网络隔离K8s是一个非常扁平的网络，租户和工作负载之间的任何通信都是可能的。基于这样的场景，我们实现了网络策略实现，对网络中的租户进行隔离，即只有指定区域内的用户才能进行通信。那么在TF层面，我们在管理上更进了一步，就是在一个租户的空间内，我们也可以决定哪个位置可以和哪个位置通信，也就是哪个POD和哪个POD通信。TF提供的统一策略管理功能先介绍一下TF独有的策略框架。假设我们有一个应用，这个应用有三层，分为三层，分别是Web层、应用层和数据库层。而这个应用的生命周期会分为三个阶段，分别是开发阶段、部署准备阶段和最终生产阶段。不同的阶段可能部署在不同的网络环境中，甚至部署在不同的云平台中，所以在顶层开发阶段，不同层之间（层也是tie的概念）会有一些安全访问策略。P1的策略也是），在部署准备阶段可能也需要这个策略（图中P2的策略）在生产阶段也需要。在不使用TF的情况下，很有可能会出现重复的策略，但是使用TF之后，我们就可以只使用一种策略了。我们所做的是简化策略的管理。首先，它降低了复杂性，简化了管理，提高了可扩展性。一旦定义了策略，您就可以在各种环境中实现可扩展和可扩展的重用，包括公共云、私有云和多云环境。让我向您介绍一个实际的策略框架用例。假设我们有一个应用，我们允许它的web层和应用层进行通信，那么无论是在开发阶段还是在生产阶段我们都可以使用这样的定义，比如开发阶段的web层也可以与生产阶段连接环境中的应用层进行通信。但是，也许我们不希望这样的事情发生，我们不希望某个开发者能够随意修改生产环境中的代码。这时候不需要改变策略，只需要在策略中添加AppMatchDeployment标签即可，可以指定——比如开发阶段只有web层，开发阶段只有应用层相可以沟通。同样，如果您的应用程序是地理分布的应用程序，您可以通过定义策略在地理区域A的Web层和地理区域B的应用程序层之间进行通信。如果不想这种跨层跨地域的通信，在AppMatchDeployment之后添加EndSite。所以这个匹配，不仅是它的部署，还有它的位置，你都要匹配。让我们再添加一层。可以看出我们第二个策略的意思，就是只要我们把这个网站匹配上，匹配上，那么他们都可以访问数据库。这种策略在管理中非常有用。如果你有一个非常庞大的跨地理区域分布的金融应用，它可能会使用多个网络，网络上有数百个应用。这时，你只需要一个策略就可以控制整个分布式金融应用。应用程序来管理。一个接口来处理多云部署。同时，TF还可以实现多云部署的自动化管理。例如，我们在驻地自动创建了一个名为MC-GW的多云网关，它会建立一个通道，并自动与云中（如AWS上）的相同部署进行安全连接。它还取决于您在云上部署的工作负载类型。有了这个工作负载，您可以在云原生环境中对其进行管理，而TF可以为您提供多云可见性。大家可以看看，如果自己管理多云，需要经过很多流程才能实现。而TF只需要一个GUI即可轻松管理多云。您需要做的就是点击几下。多云环境服务链下面介绍TF的多云服务链。可以看到resident上面有两个网络，左边是2.2.2.4，右边是3.3.3.5，然后是服务实例，这里假设服务实例是POD的虚拟化服务，通过TF的服务链，可以将工作负载从左边的网络传递到右边。同样，如果你想在不同的公有云上部署这样一个虚拟网络，你可以使用TF来建立这样一个从驻地到多云的服务链。我总结一下，只需要一个SDN控制器来管理连接——无论是裸机、K8sCNI、OpenStack，还是左边的各种边缘站点——并提供非常丰富的网络功能。TF与AkrainoTF的融合，也在边缘计算环境做出了自己的贡献。这是另一个开源项目。TF实现了与Akraino的集成，可以为边缘计算等场景提供支持。它纯粹基于K8s原生基础架构，非常适合工业自动化等轻量级应用。基本上它部署的环境很小，目标行业主要是电信运营商和企业用户。这是Akraino和TF集成的另一个用例，主要是构建电信云。目前，美国电信运营商AT&T已经进行了这样的架构部署。这里我们主要使用SR-IOV的虚拟化。我们做的是将TF作为一个单一的SDN来使用，它的部署方式包括了以上所有的类型。这是第三个用例。是一个叫微云的软件栈，主要用在移动场景，比如手游，工作负载是移动的。我们如何在这里做到这一点？首先，我们有一个DME（分布式匹配引擎），它知道连接了多少设备或者多少移动用户，根据移动用户的数量启动微云资源管理器做信息传递；然后微云资源管理器会匹配相应的资源；然后CRM将与TF控制器通信以部署这些资源；然后再到下一层，通过vRouter的转发层，与TFcontroller通信。TF与OpenStack的集成熟悉OpenStack的朋友都知道它有两种部署方式，一种是单一插件方式，一种是基于ML2的部署方式。TF有一个NetworkingOpenContrail，可以把TF作为一个ML2插件来启动。这样做有什么好处？我们可以同时基于OVS、SR-IOV和vRouter运行这个作业。您可以使用OpenStack运行OVS、SR-IOV工作负载，并使用我们的TF在网络级别进行管理。接下来，我们将向您演示如何将基于OVS的计算迁移到基于vRouter的计算。你也可以打开下面的蓝色链接，自己进行类似的实验。谢谢大家！
