本文整理自瞻博網絡傑出工程師Sukhdev Kapur在「TF中文社區成立暨第一次全員大會」上的演講，增加了對於TF功能的描述。
瞻博網絡傑出工程師Sukhdev Kapur
大家好，我叫SukhdevKapur，來自Tungsten Fabric（以下簡稱TF）社區技術指導委員會，下面我為大家介紹一下TF的架構和技術的現狀，以及最新的進展。
TF架構與部署模式
我們可以看一下這張TF的宏觀架構圖，整體圖描述是設備的物理連接，而右上角有虛機之間的邏輯網絡，TF基本的工作原理和機制，就是你創建VM或者POD，然後（通過SDN）把它們放到這些邏輯網絡裡。
在這些邏輯網絡中，你能夠以根據自己業務需要，放置任何虛機、PODS、或者裸伺服器，它們的物理位置在哪裡沒有關係，它們可能會在一個集群裡，也可能在一個機架中，這都沒有關係。
大家再看一下它下面底層的部分，TF會利用虛擬的路由器（計算節點上），來負責是這些虛擬的工作負載的轉發，而左邊是一個物理網絡的連接，例如一個裸機的物理網絡，一旦你做好了網絡定義，它可能會和實際網絡連接，也可能會和右邊邏輯網絡裡頭虛擬網絡的虛機來進行連接
第四部分（上半部分）是CONTRAILController（SDN控制器），是做配置控制分析和CSN的。
第五部分是網關的功能，它可能是一個物理網關，或者是一個虛擬的網關，當數據中心的虛機需要對外互聯的時候，通過IP的組網——也就是MPLS這種協議——進出骨幹網絡。
所有這一切，都是通過一個ORCHESTRATOR編排器去管理，它可能是OpenStack、K8s或OpenShift，通過API來調度TF來工作。
TF中Vrouter的體系架構概述
這張圖說的是TF的路由vRouter的架構，左上角是vRouter的Agent，主要是控制的部分，在這裡它會通過路由的學習，VRFs的定義，以及策略的定義，如果虛擬路由器要進行策略的執行，必須是由Agent去控制的：它來決定網絡的流量是允許通過,還是拒絕，如果允許的話，應該把它轉發到哪個位置。
你可以看到，vRouter有一個轉發的路徑，學習的路徑進行封裝，然後做二層或者三層的數據流量的轉發。
vRouter的部署模式
這是TF虛擬路由器的四種部署模式，左上角是默認的模式，在內核的vRouter部署。
右上角呢？如果你在一個高吞吐、高流量的狀態下，網絡支持DPPK的話，TF可以有的DPDKvRouter的部署。
左下角其實是一種混合部署的模式，如果你有好幾個VNF這種虛擬網絡的功能，可以用到SR-IOV的話，可以採用SR-IOV和內核的vRouter共存的混合模式。
第四種就是基於SmartNIC的vRouter，也就是說，這些VM可以充分地利用到所有處理器的能力。
TF與Kubernetes的集成
大家再來看一下TF和Kubernetes（以下簡稱K8s）的集成，首先，TF的CONTRAIL Controller會和K8s通過API進行通訊，那麼，某一個指定的位置，它是如何得到IP位址以及策略的呢？首先，K8s會和TF的Scheduler也就是調度管理程序進行通訊，再通過調度管理程序和CNI Plugin插件進行聯繫，在左上角就表示vRouter是如何獲得在K8s這邊的策略，去進行IPAM的讀取和執行的，簡單一點說，K8s的管理器會和TF的CONTRAIL Controller進行通訊，確定網絡的策略，然後TF的Controller會把這個策略發布到vRouter。
TF的微服務架構
TF的技術演進，一開始主要是基於虛機部署，後來開始支持容器技術，現在已經演進到了微服務（Microservices）的架構。目前我們的TF在部署是完全採用containers的方式進行部署，大概有27-30個左右的image。
K8s環境下的網絡隔離
K8s是一個非常扁平的網絡，租戶和租戶之間可以進行任意的溝通，工作負載之間也是這樣。
基於這樣的場景，我們就通過網絡策略的執行，去實現網絡中租戶的隔離，也就是說，只是在指定區域內的用戶之間，才可以進行溝通。
那麼在TF這一層，我們把管理又向前推進了一步，即在一個租戶的空間之內，我們也可以決定哪個位置和哪個位置可以溝通，也就是哪個POD和哪個POD通訊。
TF提供的統一策略管理功能
下面為大家介紹一下TF的獨特的策略框架。假設我們有一個應用，該應用有三層，分成三層，分別是Web層、應用層和資料庫層。而這個應用的生命周期會有三個階段，分別是開發的階段，部署準備的階段，和最後的生產階段。
不同的階段可能部署在不同的網絡環境，甚至於不同的雲平臺中，那麼在最上面的開發階段，不同的層之間（層也是tie的概念），會有一些安全的訪問策略（圖中P1的策略也），而這個策略可能在部署準備階段也需要（圖中P2的策略）在生產階段也需要，在不使用TF的情況下，很有可能會出現重複的策略，而是用TF之後，我們可以只使用一個策略
我們所做的就是把策略的管理進行了簡化，首先就是降低了複雜性，簡化管理，提高了可伸縮度。一旦定義好了策略，你就可以在各種各樣的環境之下，進行規模性的、可伸縮的復用，包括公有雲、私有雲，以及多雲的環境。
給大家介紹一個實際的策略框架用例。
假設我們有一個應用，我們允許它的Web層和應用層進行溝通，那麼不管是在開發階段，還是在生產階段，我們都可以使用這樣一個定義，比如在開發階段的Web層，也可以和生產環境下的應用層進行溝通。
但是，也許我們並不希望有這樣的事情發生，我們不希望某一個開發人員能夠隨意修改在生產環境下的代碼。這時你不用去改變策略，只需要在策略裡頭加上App Match Deployment的標籤，它可以去規定——比如說只有在開發階段的Web層和開發階段的應用層才可以進行通信。
同樣地，如果你的應用是一個地理分布式的應用，你可以通過定義策略，讓在地理區域A的Web層和在地理區域B的應用層之間進行通信。
如果你不希望這種跨層、跨區域的通信產生，就在AppMatch Deployment的後頭再加上End Site。所以說這個match，不光是它的部署，還有它的位置，你都要把它match一下。
我們再加一層，你看我們第二個策略的意思，就是說只要是這個站點我們match上了，匹配上了，那麼它們都可以和資料庫進行訪問。
這樣的一種策略在管理方面非常的有用。如果你有一個非常大型的跨地理區域分布式的金融應用，它可能使用了多個網絡，網絡上還有數百種的應用，這個時候你只需要一個策略，就可以對整個分布式的金融應用進行管理。
一個界面，搞定多雲部署
同時，TF還可以實現多雲部署的自動化管理。比如說我們在駐地這裡自動創建了一個叫做多雲的網關MC-GW，它會建立一個通道，和在雲端的（比如說AWS上的）同樣的部署，自動地進行安全的連接。
這裡也要看，你在雲上部署的工作負載到底是什麼種類的。有了這個工作負載，你可以在本地雲的環境下進行管理，而TF能夠給你一個多雲的可視性。
大家可以看一下，如果你自己去進行多雲管理，需要通過很多的流程來實現。而TF只需要一個單一的圖形用戶界面，就能夠輕鬆地進行多雲管理，你需要做的，只是做幾下點擊的動作。
多雲環境的服務鏈
下面來介紹一下TF的多雲服務鏈。大家看到最上面有兩個網絡在駐地，左邊的是2.2.2.4，右邊的是3.3.3.5，然後有一個服務的實例，假設服務實例是POD的虛擬化服務，通過TF的服務鏈，可以將工作負載從左邊的網絡傳到右邊。
同樣地，如果要在不同的公有雲上也去部署這樣的虛擬網絡，你可以通過TF，從駐地到多雲建立這樣一個服務鏈。
我來總結一下，只需要一個SDN的控制器，就能夠去管理連接——不管是金屬裸機、K8s CNI、OpenStack，還是左邊的各種邊緣的站點——並且提供非常豐富的網絡功能。
TF與Akraino的集成
TF在邊緣計算的環境下也做出了自己的貢獻，這是另外一個開源的項目，TF實現了和Akraino的集成，能夠為邊緣計算這樣的場景提供支持，它是純基於K8s原生基礎架構的，非常適用於輕量級的，像工業自動化這種應用。基本上它部署的環境是非常小的，目標行業主要是電信運營商和企業級用戶。
這是另外一個Akraino和TF集成的用例，主要是打造電信雲，目前美國電信運營商AT&T就做了這樣的一個架構部署。這裡主要是使用SR-IOV這種虛擬化，我們所做的就是把TF作為一個單一的SDN，它的部署模式包含了以上所有類型。
這是第三個用例，它是一種叫做微雲的軟體堆棧，主要應用於移動的場景，例如手機遊戲，工作負載是移動化的這種架構。
在這裡我們是怎麼做的？首先，我們有一個DME（分布式的匹配引擎），它知道有多少個設備或者多少個移動用戶接入進來，並根據移動用戶的數量，啟動微雲資源管理器去做信息傳遞；然後微雲資源管理器就會匹配到相應的資源；接下來CRM會和TF的控制器進行溝通，來進行這種資源的部署；再到下面一層，通過vRouter的轉發層，和TF的控制器進行聯繫。
TF與OpenStack的集成
熟悉OpenStack的朋友都知道，它有兩種部署模式，一種是單一的插件方式，另一種是基於ML2的部署。
TF專門有一個Networking Open Contrail，可以將TF作為一個ML2的插件去啟動。這樣做有什麼好處呢？我們可以同時去運行基於OVS、SR-IOV和vRouter的這工作。
你可以用OpenStack來運行OVS、SR-IOV的工作負載，並且在網絡層面使用我們的TF去進行管理。
接下來我們將為大家進行演示，看看如何把基於OVS的計算遷移到基於vRouter上面。大家也可以打開下面藍色的連結，自己去進行類似的實驗。
謝謝各位！