OpenStack integration and TF
OpenStack is a virtual machine and container leading open source filing system. Tungsten Fabric provides an implementation of Neutron network services, and offers many additional features.
In OpenStack user group is assigned to the "Project", in which the VM and network resources such as the class is private, and other items in the user can not see (unless otherwise enabled).
VRouters used in the VRF and routing table for each network, the project may be implemented in the network layer directly isolated, since only a route to the destination will allow to distribute the computing node vRouters the VRF, and the pan does not occur Hong vRouter agency services performed.
Web services are Neutron, the Calculation Agent is Nova (OpenStack computing services).
When both are deployed in OpenStack environment, Tungsten Fabric seamless network may be provided between the VM and Docker containers.
In the figure below, you can be seen Tungsten Fabric plug OpenStack provides API call from the network to the Tungsten Fabric Neutron mapping API, which is performed Tungsten Fabric controller.
Tungsten Fabric strategy to support networks and subnets, and OpenStack network policies and security groups. These entities can be created in OpenStack or Tungsten Fabric, and synchronize any changes between the two systems.
In addition, Tungsten Fabric also supports OpenStack LBaaS v2 API.
However, due to the Tungsten Fabric provides a rich network functionality superset by OpenStack, and therefore many network functions available only through Tungsten Fabric API or GUI. These include designated route target to achieve a connection with an external router, service chain, BGP routing policy configuration and application policies.
When the OpenStack using Tungsten Fabric network, fully support the application security. Can project, network, host, VM, or interface level applications Tungsten Fabric markers, and applies to all entities marked object contains.
In addition, Tungsten Fabric also supports resource for networking and security, you can use OpenStack Heat template control.
Kubernetes integrated container and TF
Containers allow multiple processes running on the same operating system kernel, but each process can access their own tools, libraries, and configuration files.
Runs its own guest operating system complete virtual machine compared to container requires less computational overhead associated with each VM. Applications running in the container typically start faster and perform better than the same application running in the VM, which is one of the reasons why people are increasingly concerned about the use of container in the data center and the NFV.
Docker is a software layer that enables the container across operating system versions transplant, and Kubernetes deployed as a typical interface container, container management server creation and destruction.
As shown above, Kubernetes management group of containers, which together perform certain functions, called _pods. Pod in the container and operating the shared IP address on the same server.
A group of the same pod (typically running on different servers) formed Services , and service must be directed to the serving network traffic directed in particular pod. In Kubernetes network implementations, selection of a particular pod is performed by the application itself in the pod using the native transmission Kubernetes of the API. For non-native applications, virtual IP address is achieved by the use of load balancing agent to perform Linux iptables on the sending server.
Most applications are non-native, because the port of the existing code developed in the case where they are not considered Kubernetes, so using the load balancing agent.
Kubernetes standard network environment is in fact flat, any pod can communicate with any other pod. If the target name or IP address of the pod are known, it will not stop from one namespace (similar _project _in OpenStack) in communication between the pod to another namespace pod.
Although this model is applicable to large scale data centers belonging to a single company, but it is not suitable for data center shared between many end customers of service providers, not suitable for traffic of different groups of enterprises must be isolated from each other.
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群集配置的网络模式应用网络策略。 各种选项总结在下表中。
Tungsten Fabric为Kubernetes世界带来了许多强大的网络功能，与OpenStack的功能相同，包括：
- IP地址管理
- DHCP
- DNS
- 负载均衡
- 网络地址转换（1:1浮动IP和N:1 SNAT）
- 访问控制列表
- 基于应用程序的安全性
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容器服务。
MORE
更多Tungsten Fabric解析文章
第一篇：TF主要特点和用例
第二篇：TF怎么运作
第三篇：详解vRouter体系结构
第四篇：TF的服务链
第五篇：vRouter的部署选项
第六篇：TF如何收集、分析、部署？
关于Tungsten Fabric：
Tungsten Fabric项目是一个开源项目协议，它基于标准协议开发，并且提供网络虚拟化和网络安全所必需的所有组件。项目的组件包括：SDN控制器，虚拟路由器，分析引擎，北向API的发布，硬件集成功能，云编排软件和广泛的REST API。
关于TF中文社区：
TF中文社区由中国的一群关注和热爱SDN的志愿者自发发起，有技术老鸟，市场老炮，也有行业专家，资深用户。将作为连接社区与中国的桥梁，传播资讯，提交问题，组织活动，联合一切对多云互联网络有兴趣的力量，切实解决云网络建设过程中遇到的问题。
Focus on micro letter: TF Chinese community 