小編給大家分享一下OpenStack和TF集成的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
成都創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于網(wǎng)站設計制作、成都做網(wǎng)站、南沙網(wǎng)絡推廣、重慶小程序開發(fā)、南沙網(wǎng)絡營銷、南沙企業(yè)策劃、南沙品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)公司為所有大學生創(chuàng)業(yè)者提供南沙建站搭建服務，24小時服務熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com
OpenStack是虛擬機和容器的領先的開源編排系統(tǒng)。Tungsten Fabric提供了Neutron網(wǎng)絡服務的實現(xiàn)，并提供了許多附加功能。
在OpenStack中，用戶組被分配到“項目”，其中諸如VM和網(wǎng)絡之類的資源是私有的，并且其他項目中的用戶無法看到（除非特別啟用）。
在vRouters中使用VRF且每個網(wǎng)絡都有路由表，可以直接在網(wǎng)絡層中實施項目隔離，因為只有到允許目的地的路由才會分發(fā)到計算節(jié)點上的vRouters中的VRF，并且不會發(fā)生泛洪vRouter執(zhí)行的代理服務。
網(wǎng)絡服務是Neutron，計算代理是Nova（OpenStack計算服務）。
當兩者都部署在OpenStack環(huán)境中時，Tungsten Fabric可以在VM和Docker容器之間提供無縫網(wǎng)絡。
在下圖中，可以看到OpenStack的Tungsten Fabric插件提供了從Neutron網(wǎng)絡API到Tungsten Fabric API調(diào)用的映射，后者在Tungsten Fabric控制器中執(zhí)行。
Tungsten Fabric支持網(wǎng)絡和子網(wǎng)的策略，以及OpenStack網(wǎng)絡策略和安全組?？梢栽贠penStack或Tungsten Fabric中創(chuàng)建這些實體，并且在兩個系統(tǒng)之間同步任何更改。
此外，Tungsten Fabric還支持OpenStack LBaaS v2 API。
但是，由于Tungsten Fabric通過OpenStack提供了豐富的網(wǎng)絡功能超集，因此許多網(wǎng)絡功能僅通過Tungsten Fabric API或GUI提供。這些包括指定route target以實現(xiàn)與外部路由器的連接、服務鏈、配置BGP路由策略和應用程序策略。
當OpenStack使用Tungsten Fabric網(wǎng)絡時，完全支持應用程序安全性?？梢栽陧椖俊⒕W(wǎng)絡、主機、VM或接口級別應用Tungsten Fabric標記，并應用于標記對象中包含的所有實體。
此外，Tungsten Fabric還支持用于網(wǎng)絡和安全性的資源，可以使用OpenStack Heat模板進行控制。
容器允許多個進程在同一操作系統(tǒng)內(nèi)核上運行，但每個進程都可以訪問自己的工具、庫和配置文件。
與每個VM運行其自己的完整客戶機操作系統(tǒng)的虛擬機相比，容器需要更少的計算開銷。在容器中運行的應用程序通常啟動速度更快，并且比在VM中運行的相同應用程序執(zhí)行得更好，這也是為什么人們越來越關注在數(shù)據(jù)中心和NFV中使用容器的原因之一。
Docker是一個軟件層，它使容器可以跨操作系統(tǒng)版本移植，并且Kubernetes作為部署容器的典型接口，管理服務器上容器的創(chuàng)建和銷毀。
如上圖所示，Kubernetes管理容器組，它們共同執(zhí)行某些功能，稱為_pods. pod中的容器在同一服務器上運行并共享IP地址。
一組相同的pod（通常在不同的服務器上運行）形成_services_，并且必須將指向服務的網(wǎng)絡流量定向到服務中的特定pod。在Kubernetes網(wǎng)絡實現(xiàn)中，特定pod的選擇是由應用程序本身使用發(fā)送pod中的本機Kubernetes API來執(zhí)行的。對于非本機應用程序，是由負載平衡代理使用中實現(xiàn)的虛擬IP地址，來執(zhí)行發(fā)送服務器上的Linux iptables。
大多數(shù)應用程序都是非本機的，因為它們是在未考慮Kubernetes的情況下開發(fā)的現(xiàn)有代碼的端口，因此使用了負載平衡代理。
Kubernetes環(huán)境中的標準網(wǎng)絡實際上是扁平的，任何pod都可以與任何其他pod進行通信。如果目標pod的名稱或其IP地址是已知的，則不會阻止從一個命名空間（類似于_project _in OpenStack）中的pod到另一個命名空間中的pod之間的通信。
雖然此模型適用于屬于單個公司的超大規(guī)模數(shù)據(jù)中心，但它不適合數(shù)據(jù)中心在許多最終客戶之間共享的服務提供商，也不適合必須將不同組的流量彼此隔離的企業(yè)。
Tungsten Fabric虛擬網(wǎng)絡可以集成在Kubernetes環(huán)境中，以與OpenStack類似的方式提供一系列多租戶網(wǎng)絡功能。
帶有Kubernetes的Tungsten Fabric 配置如下圖所示。
使用Kubernetes編排和Docker容器的Tungsten Fabric架構類似于OpenStack和KVM / QEMU，其vRouter在主機Linux OS中運行，并包含帶有虛擬網(wǎng)絡轉發(fā)表的VRF。
pod中的所有容器共享一個具有單個IP地址的網(wǎng)絡堆棧（圖中的IP-1，IP-2），但是偵聽不同的TCP或UDP端口，并且每個網(wǎng)絡堆棧的接口連接到vRouter的VRF。
一個名為_kube-network-manager _listens的進程使用Kubernetes _k8s _API偵聽與網(wǎng)絡相關的消息，并將這些消息發(fā)送到Tungsten Fabric API。
在服務器上創(chuàng)建pod時，本地_kubelet_和vRouter代理之間通過Container Network Interface（CNI）進行通信，以將新接口連接到正確的VRF。
服務中的每個pod在虛擬網(wǎng)絡中分配唯一的IP地址，并且還為服務中的所有pods分配浮動IP地址。服務地址用于將流量從其他服務中的pod或外部客戶端或服務器發(fā)送到服務中。
當流量從pod發(fā)送到服務IP時，連接到該pod的vRouter將使用到服務IP地址的路由執(zhí)行ECMP負載平衡，該服務IP地址將解析為構成目標服務的各個pod的接口。
當流量需要從Kubernetes集群外部發(fā)送到服務IP時，可以將Tungsten Fabric配置為創(chuàng)建一對（用于冗余）_ha-proxy_負載均衡器，它可以執(zhí)行基于URL的路由到Kubernetes服務，最好使用浮動IP地址避免暴露集群的內(nèi)部IP地址。
這些外部可見的服務地址解析為到服務Pod的ECMP負載平衡路由。
在Kubernetes集群中使用Tungsten Fabric虛擬網(wǎng)絡時，不需要Kubernetes代理負載均衡。
提供外部訪問的其他替代方法包括：使用與負載均衡器對象關聯(lián)的浮動IP地址，或使用與服務關聯(lián)的浮動IP地址。
在Kubernetes中創(chuàng)建或刪除服務和pod時，kube-network-manager進程會檢測k8s API中的相應事件，并使用Tungsten Fabric API根據(jù)為Kubernetes群集配置的網(wǎng)絡模式應用網(wǎng)絡策略。 各種選項總結在下表中。
Tungsten Fabric為Kubernetes世界帶來了許多強大的網(wǎng)絡功能，與OpenStack的功能相同，包括：
IP地址管理
DHCP
DNS
負載均衡
網(wǎng)絡地址轉換（1:1浮動IP和N:1 SNAT）
訪問控制列表
基于應用程序的安全性
VMware vCenter廣泛用作虛擬化平臺，但需要手動配置網(wǎng)絡網(wǎng)關，以實現(xiàn)位于不同子網(wǎng)中的虛擬機與vCenter群集外部目標之間的網(wǎng)絡連接。
可以在現(xiàn)有vCenter環(huán)境中部署Tungsten Fabric虛擬網(wǎng)絡，以提供先前列出的所有網(wǎng)絡功能，同時保留用戶可能依賴的工作流，以使用vCenter GUI和API創(chuàng)建和管理虛擬機。
此外，還在vRealize Orchestrator和vRealize Automation中實現(xiàn)了對Tungsten Fabric的支持，以便Tungsten Fabric中的常見任務（如創(chuàng)建虛擬網(wǎng)絡和網(wǎng)絡策略）可以包含在這些工具中實現(xiàn)的工作流中。
使用VMware vCenter的Tungsten Fabric架構如下圖所示。
虛擬網(wǎng)絡和策略可以在Tungsten Fabric中直接創(chuàng)建，也可以在vRO / vRA工作流程中使用TF任務創(chuàng)建。
當vCenter使用其GUI或vRO / vRA創(chuàng)建VM時，Tungsten Fabric的vCenter插件將在vCenter消息總線上看到相應的消息，這是Tungsten Fabric在服務器（將要創(chuàng)建VM的服務器）上配置vRouter的觸發(fā)器。
每個VM的每個接口都連接到一個端口組，該端口組對應于該接口所在的虛擬網(wǎng)絡。端口組具有與之關聯(lián)的VLAN，由Tungsten Fabric控制器使用vCenter中的“VLAN override”選項設置，并且端口組的所有VLAN都通過中繼端口組發(fā)送到vRouter。
Tungsten Fabric控制器將接口的VLAN映射到包含該子網(wǎng)的虛擬網(wǎng)絡的VRF上。剝離VLAN標記，并執(zhí)行VRF中的路由查找。
如本文檔前面所述，通過Tungsten Fabric與vCenter的配合使用，用戶可以訪問Tungsten Fabric提供的全部網(wǎng)絡和安全服務，包括零信任微分段，代理DHCP，DNS和DHCP，可避免網(wǎng)絡泛洪，服務鏈，幾乎無限的規(guī)模，以及與物理網(wǎng)絡的無縫互連。
假設已經(jīng)通過某種方式預先配置了運行容器的KVM主機。
還有一種替代方法，是使用OpenStack或vCenter來配置容器運行的VM，并使用Tungsten Fabric管理OpenStack或vCenter創(chuàng)建的VM與Kubernetes創(chuàng)建的容器之間的虛擬網(wǎng)絡，如下圖所示。
編排器（OpenStack或vCenter），Kubernetes Master和Tungsten Fabric在一組服務器或VM中運行。
編排器配置為使用Tungsten Fabric管理計算群集，因此每臺服務器上都有vRouters。
可以將虛擬機啟動并配置為運行Kubelet和Tungsten Fabric的CNI插件。這些虛擬機可供Kubernetes主機運行，并通過Tungsten Fabric管理網(wǎng)絡。
由于同一個Tungsten Fabric負責管理orchestrator和Kubernetes的網(wǎng)絡，因此可以在VM之間，容器之間，以及VM和容器之間實現(xiàn)無縫聯(lián)網(wǎng)。
在嵌套場景中，Tungsten Fabric提供與前面所述相同的隔離級別，并且多個Kubernetes Masters可以共存，并且運行Kubelet的多個VM可以在同一主機上運行。 這允許提供多租戶Kubernetes容器服務。
以上是“OpenStack和TF集成的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
