Tungsten Fabric架构解析丨TF如何编排



  • Hi!这里是Tungsten Fabric架构解析内容的第七篇,介绍TF如何为OpenStack、Kubernetes、VMware vCenter等各种编排器提供虚拟网络。
    
    Tungsten Fabric架构解析系列文章,由TF中文社区为你呈现,旨在帮助初入TF社区的朋友答疑解惑。我们将系统介绍TF有哪些特点、如何运作、如何收集/分析/部署、如何编排、如何连接到物理网络等话题。
    
    欢迎大家在后台留言给我们,把你最希望了解的问题告诉我们,小编去帮你寻找答案。想看前期已发布的文章,请留意文末链接。
    

    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控制器中执行。

    6b431c8e-628e-4042-a532-cf528846df05-image.png

    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作为部署容器的典型接口,管理服务器上容器的创建和销毁。

    b6da6859-70a1-43dc-87b9-3b1a7648220a-image.png

    如上图所示,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 配置如下图所示。

    3f96906f-de90-4955-845d-e3092df4ee38-image.png

    使用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群集配置的网络模式应用网络策略。 各种选项总结在下表中。

    06291df7-66a7-47cf-a7d8-ccc26074935c-image.png

    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架构如下图所示。

    0a72327f-9bb8-483a-ac48-eb58027640bd-image.png

    虚拟网络和策略可以在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创建的容器之间的虚拟网络,如下图所示。

    83d4f6b9-e2c8-4aab-9a47-474c14f7c7d1-image.png

    编排器(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如何收集、分析、部署?


Log in to reply