OpenStack和TF集成的示例分析

OpenStack和TF集成的示例分析

小编给大家分享一下OpenStack和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控制器中执行。

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

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容器服务。

以上是“OpenStack和TF集成的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注恰卡编程网行业资讯频道!

发布于 2021-12-28 22:20:45
收藏
分享
海报
0 条评论
46
上一篇:如何利用Hyperledger Fabric的SDK来开发REST API服务器 下一篇:如何下载Fabric-Sampl与二进制包
目录

    0 条评论

    本站已关闭游客评论,请登录或者注册后再评论吧~

    忘记密码?

    图形验证码