TF功能開發路線圖：盤點2021年Tungsten Fabric聚焦領域

在Linux基金會主辦的“LFN技術會議”上，Tungsten Fabric社群進行了一系列演講，介紹最新的功能和未來發展方向。今天帶來第一篇演講，看看Tungsten Fabric在2021年將聚焦哪些亮點功能和專案，以及計劃涵蓋的主要創新領域。

大家好！我是Nick Davey，現在是早上8點，我剛喝過咖啡，會盡量保持清醒，非常感謝你們這麼早參與進來，感謝有這個機會與社群進行探討。

我是瞻博網路的產品經理，日常工作是以各種形式使用Contrail和Tungsten Fabric，我認為自己在Tungsten Fabric上投入的情感更多一些。特別是過去的幾個季度，在整個社群——包括瞻博網路CTO在內——大家的努力下，有了一些新的進展，我很期待看到一些偉大的事情和藍圖正在展開。

我們在社群中扮演著獨特的角色，作為開發者，我們推動一些功能往前走，確保我們在Juniper所做的事情，能夠轉化為對於社群來說具有可行性的東西，這是一個不小的挑戰。但我們與社群中的技術專家和領導者一起，找到了一種方法，使功能或專案回到符合我們的意圖和願景的道路上，我認為我們已經做出了有意義的改變。

那麼我們到底要做什麼？這裡我整理了幾個簡要事項，關於重點領域已經和將要推進的工作。我會圍繞其中的一些點進行討論，希望這些專案能激發大家的討論，如果有任何問題或評論，請直接提問。

每當Juniper內部有一個版本釋出的時候，我們都會進行資格認證，針對不同的編排器和不同版本進行測試。之前幾乎所有的測試都是圍繞著K8s 1.12進行的，然後我們透過了對OpenShift 3.11的支援，將K8s版本推到了1.14和1.16，而現在已經進行了包括1.18在內的資格認證。我們花了很多時間來覆蓋1.16和1.14之間的版本。你可以對使用當前版本的K8s開展工作抱有信心，可以使用K8s RK DS版本引數部署任何版本的K8s。總之，我們現在已經執行在 Kubernetes 1.18上，它的工作狀況也非常棒！

我知道這不是什麼頭條，但對於跨編排器和跨多個版本保持靈活性，這件事真的至關重要。K8s已經顯示出非常快的創新步伐，所以我們需要確保跟上。確保花很多時間測試這些版本，確保一切都能正常工作。在K8s裡面增加了對多介面網路的支援，這裡面也有一堆工作。它們引入了對多網路附件定義的支援，對於 多介面pod是一個非常非常長的路。

多介面pod背後的想法是，pod的每一個介面都會連線到CNI，提供一套差異化的服務。電信行業使用者設想了一個部署模式，預設的pod網路提供安全的管理訪問，然後一個或多個資料平面介面將提供直接訪問或訪問底層網路的支援。

這些設想的方案，往往集中在多CNI方面，每個CNI通常有一個或多個介面。我們與Tungsten Fabric社群一起工作，去了解電信客戶設想的這個功能的用例，真的是需求什麼。我們一起合作，開發自己的網路附件定義。

我們仍然使用相同的manifest來控制這個功能，所以當你使用Tungsten Fabric的時候，它是相同的配置來建立多個介面，在K8s manifest裡面實際的附件定義會觸發Tungsten Fabric上虛擬網路的建立，這真的很酷。現在你可以讓叢集租戶自己服務於自己的網路，但關鍵的區別在於，所有的網路連線都是由單一的CNI來交付的，Tungsten Fabric交付你在pod上建立的所有介面。這很好，符合電信運營商使用者的需求，要注意的是，對這些工作負載有一些不同類別的連線要求，通常像SRIOV這樣的需求會排在前面。

在此基礎上，一些應用如OKD和紅帽OpenShift，會假設Multus是不間斷的，Multus將成為K8s生態系統的一部分。團隊提供了 對Multus的支援，這使得Tungsten Fabric仍然有多個介面連線到它，提供這種強大的和電信級路由器一樣的體驗。基於Tungsten Fabric可以有多個介面，連線到不同的虛擬網路，服務於不同的功能。並且，你還可以複用正在使用的實際的CNI。我們前進的方法是與上游保持一致，時刻考慮客戶和社群成員的用例。

圍繞IaaS領域，也發生了令人興奮的變化，特別是我們作為系統運營商如何管理虛擬機器方面。K8s正在變成幾乎所有東西的首選編排器，有越來越多的功能被新增到這個平臺上。 KubeVirt最新的改進，是允許使用一堆客戶資源定義在K8s裡面執行虛擬機器。這代表了一條非常寬廣的前進道路。首先，向雲原生和容器的過渡，這不是一朝一夕的事情，透過在K8s叢集裡面新增虛擬機器物件，我們現在有了選擇，可以更快地從傳統的VMware和OpenStack編排器中轉型。如果這是我們的計劃，顯然這些技術需要一段時間才能成熟，但我們要確保Tungsten Fabric在這個轉型的前沿。我們正在努力並計劃在短期內提供基於K8s在Tungsten Fabric上部署虛擬機器的能力，已經有一堆程式碼提交以確保其能夠執行，同時團隊仍在進行功能的測試和驗證，保證它能很好地工作。

最後一項工作是針對 高效能容器部署的工作，我們正在緊鑼密鼓地將DPDK介面引入到容器中。目前TF可支援 DPDK 19.11的版本，將過去我們所依賴的一些舊的DPDK程式碼從Tungsten Fabric中移除，這是我們向前邁出的一大步。社群也圍繞這個做了很多工作，確保大家所有的努力工作首先是要提供真正的功能、產品和專案。

我們已經花了大量的時間在DPDK上，無論是在Juniper內部，還是社群內部的工作，結果都是非常美妙的，我已經看到了一些資料，基於新的MD硬體，使用最新的DVDK庫，可實現每核心每秒320萬個資料包轉發。考慮到還可以透過額外的核心來擴充套件這一事實，我們有一個真正的、非常強大的高效能解決方案！我們現在正尋找將這種型別的軟體加速的資料平面帶入到容器中，並與社群成員合作，以確保聯合做到這一點。

現在我們的經驗是，很多初始的容器網路功能都是依賴於SRIOV，所以我們正在利用的一個解決方案是Multus和SRIOV CNI組合來提供 SRIOV，目前我們正在與容器網路功能廠商、電信使用者，以及運營商專案成員合作，瞭解連線這些SRIOV最理想的模式是什麼。這完全是雲運營商的選擇，但我們認為，那些希望使用更多分解堆疊的人，與那些希望看到這種能力內在地建立在單一資料平面中的人之間會有分歧。

這真的是我們在雲原生方面的關注點。世界正在走向雲原生的未來，OpenStack也有一個漫長而充滿活力的未來，有很多很多的OpenStack部署正在進行，大型的OpenStack專案正在出現，這些雲才剛剛開始，它們會成長和擴充套件，提供更多的服務，它們會發展到更多的區域。總之，OpenStack是不會消失的。我們需要認識到作為一個專案和一個社群，我們的角色是腳踏兩個陣營：幫助傳統的雲運營商，以最小的影響方式邁向雲原生的未來。

為了做到這一點，我們正努力將很多現有的生命週期管理變得具有時代性，所以在TF社群做了大量的工作，增加了對 Ubuntu新版本、 Charmed Canonical OpenStack新版本和 Red Hat OpenStack新版本的支援和更新。這可能是我們大家做的最辛苦的工作，是最不容易被發現的，或者說是最不容易興奮的，直到不能執行了才會被發現。

透過支援更具時代性的編排器和版本，也帶來了新的生命週期管理和新的模式。圍繞Tungsten Fabric的運營，包含了大量難以置信的工作。運營商將是我們打算如何生命週期Tungsten Fabric向前發展，不僅是OpenShift K8s，也是所有的OpenStack dest drawers，我們部署典型的虛擬機器和微服務將嵌入現在的邏輯，為運營商部署Tungsten Fabric容器，並嵌入所需的邏輯，以擴大或縮小規模，或升級這些容器。 透過雲原生的框架來管理Tungsten Fabric的控制和資料平面，隨著編排器的發展，隨著工作負載更多走向雲原生，我們很好地將其插入到這些容器中，並提供虛擬機器和容器之間的網路。

還有兩塊正在做的工作，是考慮到我們的解決方案往往部署在基礎設施網路為關鍵任務網路的情況。第一個是我們正在提高路由器的彈性，以檢測和應對網路故障或變化，你看到的是第一種工作，trickle in，現在有可調節或可適應的XMPP定時器，這是更快地檢測到故障的第一步，所以現在我們允許在所有的 vRouter節點上實現XMPP可調節。下一步是圍繞服務和可能情況下的傳輸下一跳， 提供快速收斂功能，我們正在尋找適應BGP字首獨立收斂，或選擇安裝服務路由的備份路徑等概念，以便在發生控制器或閘道器故障時，我們的反應能夠更快。我們還希望根據需要引入對其他hello和keep alive協議的支援，以方便更快地檢測到連結丟失。

現在正在進行的第二項彈性和可靠性工作，是 改善Controller和vRouter的升級體驗。首先的工作是能夠在不重啟的情況下升級vRouter。這聽起來很枯燥，但其實我們是用一個非常整潔的機制來完成這個任務的。我們對重啟的要求，最常見的是需要連續的記憶體驅動的，透過利用標準的巨量頁面部署，我們可以保證有大塊的連續記憶體，從而有更順暢的升級體驗。

此外，在其它零碎的事項上，我們也做了一些工作。第一個是關於 資料平面學習，這是以前沒有在Tungsten Fabric中做過的事情。我們通常依靠一個編排器來通知控制器Mac IP地址和埠繫結，然後用這些條目填充轉發表，並將這些條目傳播到叢集內部和外部的所有端點。我們看到大量的網路功能被部署在Tungsten Fabric或者vRouter上面的容器、虛擬機器裡面，結果是傳統的機制留下了一個盲點，我們不會有一個編排器來通知這些工作負載的位置，所以必須被動地觀察它們，聽起來很像flood and learn，但是我們做得更聰明一點。我們現在有了動態學習這些端點位置的機制，所以如果大家在執行assay、任意工作負載或透明服務鏈，它們就可以在每個虛擬網路的基礎上啟用這個功能，並看到這些轉發條目動態填充。

我們也認識到在這些容器上面部署了關鍵的基礎設施，我們把 動態服務健康檢查也作為一個選項嵌入到這些容器中。

最後，我們現在圍繞連線伺服器的網路裝置的自動化做了很多工作，這一切都始於圍繞 OpenStack ML2推動的一個專案，用於網路供應，現在正在擴充套件到允許為OpenStack連線計算節點的SRIOV虛擬功能的自動供應。現在網路中存在一種自動化的漏洞，當我們透過Tungsten Fabric在分配或連線到一個提供商網路時，我們提供一個fabric結構，這是對資料平面的訊號，我們希望能夠提供一個虛擬功能，但實際上沒有任何東西去為我們提供這種連線性。也就是說，如果我們說VLAN on WAN上分配了虛擬功能，在底層網路中並沒有任何東西可以確保VLAN on WAN的存在。而這些能力將允許我們透過VLAN on WAN上動態地提供適當的交換機埠，允許OpenStack運營商動態地驅動網路中的配置變化。

以上就是TF社群近期的亮點，我們最近所做的一些重要事項，希望為2021年即將到來的事情做鋪墊。

Tungsten Fabric內部專注於雲原生絕對會帶來很多變化，未來會迫使我們做出改變，如果我們只是在它們到來的時候做出反應，會錯過更廣闊的畫面。我們很樂意與TF社群合作，未來會以更多的雲原生方式適應或推動我們的工作。

原文 連結：

影片連結： https://v.qq.com/x/page/u3216w92rq4.html