OpenStack和TF集成
OpenStack是虚拟机和容器的领先的开源编排系统。Tungsten Fabric提供了Neutron网络服务的实现，并提供了许多附加功能。
在OpenStack中，用户组被分配到“项目”，其中诸如VM和网络之类的资源是私有的，并且其他项目中的用户无法看到（除非特别启用）。
在vRouters中使用VRF且每个网络都有路由表，可以直接在网络层中实施项目隔离，因为只有到允许目的地的路由才会分发到计算节点上的vRouters中的VRF，并且不会发生泛洪vRouter执行的代理服务。
网络服务是Neutron，计算代理是Nova（OpenStack计算服务）。
当两者都部署在OpenStack环境中时，Tungsten Fabric可以在VM和Docker容器之间提供无缝网络。
在下图中，可以看到OpenStack的Tungsten Fabric插件提供了从Neutron网络API到Tungsten Fabric API调用的映射，后者在Tungsten Fabric控制器中执行。
Tungsten Fabric支持网络和子网的策略，以及OpenStack网络策略和安全组。可以在OpenStack或Tungsten Fabric中创建这些实体，并且在两个系统之间同步任何更改。
此外，Tungsten Fabric还支持OpenStack LBaaS v2 API。
但是，由于Tungsten Fabric通过OpenStack提供了丰富的网络功能超集，因此许多网络功能仅通过Tungsten Fabric API或GUI提供。这些包括指定route target以实现与外部路由器的连接、服务链、配置BGP路由策略和应用程序策略。
当OpenStack使用Tungsten Fabric网络时，完全支持应用程序安全性。可以在项目、网络、主机、VM或接口级别应用Tungsten Fabric标记，并应用于标记对象中包含的所有实体。
此外，Tungsten Fabric还支持用于网络和安全性的资源，可以使用OpenStack Heat模板进行控制。
Kubernetes容器和TF集成
容器允许多个进程在同一操作系统内核上运行，但每个进程都可以访问自己的工具、库和配置文件。
与每个VM运行其自己的完整客户机操作系统的虚拟机相比，容器需要更少的计算开销。在容器中运行的应用程序通常启动速度更快，并且比在VM中运行的相同应用程序执行得更好，这也是为什么人们越来越关注在数据中心和NFV中使用容器的原因之一。
Docker是一个软件层，它使容器可以跨操作系统版本移植，并且Kubernetes作为部署容器的典型接口，管理服务器上容器的创建和销毁。
如上图所示，Kubernetes管理容器组，它们共同执行某些功能，称为_pods. pod中的容器在同一服务器上运行并共享IP地址。
一组相同的pod（通常在不同的服务器上运行）形成_services_，并且必须将指向服务的网络流量定向到服务中的特定pod。在Kubernetes网络实现中，特定pod的选择是由应用程序本身使用发送pod中的本机Kubernetes API来执行的。对于非本机应用程序，是由负载平衡代理使用中实现的虚拟IP地址，来执行发送服务器上的Linux iptables。
大多数应用程序都是非本机的，因为它们是在未考虑Kubernetes的情况下开发的现有代码的端口，因此使用了负载平衡代理。
Kubernetes环境中的标准网络实际上是扁平的，任何pod都可以与任何其他pod进行通信。如果目标pod的名称或其IP地址是已知的，则不会阻止从一个命名空间（类似于_project _in OpenStack）中的pod到另一个命名空间中的pod之间的通信。
虽然此模型适用于属于单个公司的超大规模数据中心，但它不适合数据中心在许多最终客户之间共享的服务提供商，也不适合必须将不同组的流量彼此隔离的企业。
Tungsten Fabric虚拟网络可以集成在Kubernetes环境中，以与OpenStack类似的方式提供一系列多租户网络功能。
带有Kubernetes的Tungsten Fabric 配置如下图所示。
使用Kubernetes编排和Docker容器的Tungsten Fabric架构类似于OpenStack和KVM / QEMU，其vRouter在主机Linux OS中运行，并包含带有虚拟网络转发表的VRF。
pod中的所有容器共享一个具有单个IP地址的网络堆栈（图中的IP-1，IP-2），但是侦听不同的TCP或UDP端口，并且每个网络堆栈的接口连接到vRouter的VRF。
一个名为_kube-network-manager _listens的进程使用Kubernetes _k8s _API侦听与网络相关的消息，并将这些消息发送到Tungsten Fabric API。
在服务器上创建pod时，本地_kubelet _和vRouter代理之间通过Container Network Interface（CNI）进行通信，以将新接口连接到正确的VRF。
服务中的每个pod在虚拟网络中分配唯一的IP地址，并且还为服务中的所有pods分配浮动IP地址。服务地址用于将流量从其他服务中的pod或外部客户端或服务器发送到服务中。
当流量从pod发送到服务IP时，连接到该pod的vRouter将使用到服务IP地址的路由执行ECMP负载平衡，该服务IP地址将解析为构成目标服务的各个pod的接口。
当流量需要从Kubernetes集群外部发送到服务IP时，可以将Tungsten Fabric配置为创建一对（用于冗余）_ha-proxy_负载均衡器，它可以执行基于URL的路由到Kubernetes服务，最好使用浮动IP地址避免暴露集群的内部IP地址。
这些外部可见的服务地址解析为到服务Pod的ECMP负载平衡路由。
。
在Kubernetes集群中使用Tungsten Fabric虚拟网络时，不需要Kubernetes代理负载均衡。
提供外部访问的其他替代方法包括：使用与负载均衡器对象关联的浮动IP地址，或使用与服务关联的浮动IP地址。
在Kubernetes中创建或删除服务和pod时，kube-network-manager进程会检测k8s API中的相应事件，并使用Tungsten Fabric API根据为Kubernetes群集配置的网络模式应用网络策略。 各种选项总结在下表中。
网络模式 | 网络策略 | 效果 |
|---|---|---|
Kubernetes 默认 | 任意互访，没有租户隔离。 | 任何容器都可以与任何其他容器或服务通信。 |
命名空间隔离 | Kubernetes命名空间映射到Tungsten Fabric中的项目。 | 命名空间中的容器可以相互通信。 |
服务隔离 | 每个pod都在其自己的虚拟网络中，并应用安全策略，以便只能从Pod外部访问服务IP地址。 | Pod中已启用通信，但只能从Pod外部访问服务IP地址。 |
容器隔离 | 同一个pod中容器之间“零信任”。 | 即使在pod中，也只允许特定容器之间的通信，在特定的pod中启用特定服务。 |
Tungsten Fabric为Kubernetes世界带来了许多强大的网络功能，与OpenStack的功能相同，包括：
lIP地址管理
lDHCP
lDNS
l负载均衡
l网络地址转换（1:1浮动IP和N:1 SNAT）
l访问控制列表
l基于应用程序的安全性
TF和vCenter集成{#tf-vcenter}
VMware vCenter广泛用作虚拟化平台，但需要手动配置网络网关，以实现位于不同子网中的虚拟机与vCenter群集外部目标之间的网络连接。
可以在现有vCenter环境中部署Tungsten Fabric虚拟网络，以提供先前列出的所有网络功能，同时保留用户可能依赖的工作流，以使用vCenter GUI和API创建和管理虚拟机。
此外，还在vRealize Orchestrator和vRealize Automation中实现了对Tungsten Fabric的支持，以便Tungsten Fabric中的常见任务（如创建虚拟网络和网络策略）可以包含在这些工具中实现的工作流中。
使用VMware vCenter的Tungsten Fabric架构如下图所示。
虚拟网络和策略可以在Tungsten Fabric中直接创建，也可以在vRO / vRA工作流程中使用TF任务创建。
当vCenter使用其GUI或vRO / vRA创建VM时，Tungsten Fabric的vCenter插件将在vCenter消息总线上看到相应的消息，这是Tungsten Fabric在服务器（将要创建VM的服务器）上配置vRouter的触发器。
每个VM的每个接口都连接到一个端口组，该端口组对应于该接口所在的虚拟网络。端口组具有与之关联的VLAN，由Tungsten Fabric控制器使用vCenter中的“VLAN override”选项设置，并且端口组的所有VLAN都通过中继端口组发送到vRouter。
Tungsten Fabric控制器将接口的VLAN映射到包含该子网的虚拟网络的VRF上。剥离VLAN标记，并执行VRF中的路由查找。
如本文档前面所述，通过Tungsten Fabric与vCenter的配合使用，用户可以访问Tungsten Fabric提供的全部网络和安全服务，包括零信任微分段，代理DHCP，DNS和DHCP，可避免网络泛洪，服务链，几乎无限的规模，以及与物理网络的无缝互连。
###嵌套的Kubernetes与OpenStack或vCenter {#tf-nested-kubernetes}
假设已经通过某种方式预先配置了运行容器的KVM主机。
还有一种替代方法，是使用OpenStack或vCenter来配置容器运行的VM，并使用Tungsten Fabric管理OpenStack或vCenter创建的VM与Kubernetes创建的容器之间的虚拟网络，如下图所示。
编排器（OpenStack或vCenter），Kubernetes Master和Tungsten Fabric在一组服务器或VM中运行。
编排器配置为使用Tungsten Fabric管理计算群集，因此每台服务器上都有vRouters。
可以将虚拟机启动并配置为运行Kubelet和Tungsten Fabric的CNI插件。这些虚拟机可供Kubernetes主机运行，并通过Tungsten Fabric管理网络。
由于同一个Tungsten Fabric负责管理orchestrator和Kubernetes的网络，因此可以在VM之间，容器之间，以及VM和容器之间实现无缝联网。
在嵌套场景中，Tungsten Fabric提供与前面所述相同的隔离级别，并且多个Kubernetes Masters可以共存，并且运行Kubelet的多个VM可以在同一主机上运行。 这允许提供多租户Kubernetes容器服务。
更多Tungsten Fabric解析文章
第一篇：TF主要特点和用例
第二篇：TF怎么运作
第三篇：详解vRouter体系结构
第四篇：TF的服务链
第五篇：vRouter的部署选项
第六篇：TF如何收集、分析、部署？
