作者 | Wavell Watson
譯者 | 明知山
策劃 | 丁曉昀
在三類云資源（計算、存儲和網絡）中，網絡似乎最經得起云原生非功能性需求的考驗。例如，計算彈性是通過虛擬機、容器和編配器合理分配的，并通過 CI/CD 管道進行管理。網絡在實現方面似乎缺乏彈性。在本文中，我們將試圖通過云原生網絡功能將網絡應用程序引入云原生世界。但究竟什么是 CNF，為什么它們如此重要？
1
重生的 SDN？我們以前沒試過嗎？
軟件定義網絡（SDN）在過去和現在都是網絡配置自動化的一種嘗試。云原生網絡功能并不是重生的 SDN，它以一種完全不同的方式看待網絡。在某種意義上，云原生網絡功能類似于 SDN，因為它們是基于軟件而不是基于硬件的解決方案。但是，云原生網絡有一組完全不同于 SDN 的非功能性需求。云原生非功能需求優先考慮通過彈性、自動化【腳注 1】，等等，比 SDN 要多得多。這個需求的實現依賴于聲明式配置。換句話說，云原生配置更傾向于說它想要完成“什么”，而不是“如何”完成。例如，有一個禁止硬編碼 IP 地址的網絡聲明式配置。聲明式配置讓整個系統具備了自愈的能力【腳注 2】，因為這樣更容易讀取和并做出適當的響應。然后，系統可以不斷地進行自我修正。云原生系統的其他非功能需求是彈性和可用性，并通過橫向擴展而不是垂直擴展技術來實現。云原生系統試圖通過讓子組件具有更高的可服務性和冗余性來解決可靠性問題。例如，在云原生環境中，擁有一個包含多個冗余子組件的頂級組件（其中幾個組件可用，但少數組件出現故障）要比一個緊密耦合但“高可靠”的組件更可靠【腳注 3】。
2
超越虛擬化網絡
在某種意義上，“網絡功能”并不是解耦的。虛擬網絡功能（VNF）始于網絡硬件的虛擬化。VNF 的硬件與虛擬化硬件是一一對應的，下至網卡、特定于應用程序的集成電路（ASIC）或整個交換機。SDN 似乎是將物理網絡機器虛擬化，但 CNF 不僅僅是容器化的網絡虛擬機，它對網絡功能進行進一步的解耦。CNF 根據敏捷產品團隊的發布周期，從大公司的大發布周期中脫離出來，在功能上把網絡分成具有相似變化速度的組件。由產品團隊發布的軟件【腳注 4】可以被認為是“厚”微服務。“薄”微服務是指作為容器內的單個進程類型【腳注 5】交付的軟件。通過作為產品團隊來開發軟件，我們發現，在實踐中，厚微服務常常看起來很像薄微服務。
編配器的出現為管理微服務帶來了福音。編配器負責微服務的調度、啟動、停止和監控（生命周期）。現在有許多編配器，其中 Kube.NETes（K8s）是最流行的，但也有特定于領域的編配器，例如電信領域的編配器。云原生生態系統早期的一個愿景是防止編配器 K8s 被“割據”。這是通過提供官方的 K8s 認證來實現的，該認證由 CNCF 維護，以確保 K8s 的分支版本都將支持社區要求的 API 和最佳實踐。
3
究竟什么是云原生網絡功能？
云原生網絡功能存在于 OSI 網絡棧【腳注 6】之上，已從云原生軌跡圖中移除。CNF 在網絡棧的位置越低，就越難有好的云原生實現。這可能是因為網絡需要與編配器和底層主機集成，同時保留其云原生屬性，也可能是因為如果不小心將以前的網絡功能（比如轉發平面）從共享內存 / 線程模型分離到無共享進程模型【腳注 7】會降低性能。
要理解解耦網絡功能的影響，就有必要了解一下網絡分層背后的邏輯。OSI 網絡棧允許網絡出現創新，同時保持層之間的互操作性。在網絡層，IP 協議最終成為大贏家。在數據鏈路層，出現了 ARP。供應商們在每一層的協議層進行迭代，創建出新的協議和新的協議實現。云原生網絡功能可以實現為包含在開發庫、微服務中的協議，甚至可以作為網絡應用程序中的一組微服務來實現。
網絡服務網格項目的 Ed Warnicke 曾經說過，對于網絡服務來說，“數據包就是有效載荷”。這意味著實際操作（轉換、路由或分析）網絡數據包或數據幀的是網絡應用程序或服務。以下是 OSI 模型各層網絡功能的一些例子。
第 7 層：CoreDNS；
第 6 層：NFF 包檢查器；
第 5 層：Rsocket
第 4 層和第 3 層：Envoy/Network Service Mesh/Various CNI 插件；
第 2 層：基于 VPP 的 VSwitch。
對于云原生網絡應用，或更高階的跨多層云原生網絡功能，例如 MATRIXX Software 的 5G 融合計費系統和 PANTHEON.tech 的 BGP 服務器。
云原生軌跡圖在一定程度上描述了云原生應用程序的成熟度。當我們深入研究云原生化道路上的某一站時，事情會變得更加復雜，就像網絡、策略和安全性一樣。這就是說，幫助你走向云原生的工具中有一種原生云自反性。如果講這些也應用在云原生網絡功能上，那么我們最終必須像其他云原生應用程序一樣實現網絡功能。總結如下。
第 1 步從粗粒度的部署開始，通常用容器來實現。
第 2 步是使用無狀態和聲明式配置將服務或應用程序部署到 CI/CD 管道中。
第 3 步是支持部署在同構節點上的編配器（例如 K8s），用于管理服務的生命周期。
第 4 步確保網絡功能具有遙測功能，包括指標（例如，Prometheus）、跟蹤（例如，Jaeger）和兼容事件流的日志（例如，Fluentd）。
云原生成熟度的第 5 個步驟是服務發現，集群內部甚至外部的其他消費者可以用它來發現網絡服務。
為了方便聲明式配置，第 6 步概述了策略的重要性，特別是網絡和安全策略。
第 7 步是分布式存儲，適用于使用有狀態工作負載的地方，以確保兼容云原生環境。
云原生消息傳遞、注冊表、運行時和軟件分發是云原生成熟度的其他階段，這些階段將完成應用程序的整個旅程。
4
CNF 數據平面
有了 CNF，數據平面【腳注 8】（也稱為轉發平面）更進一步地遠離了傳統硬件。由于云原生更重視橫向擴展而不是垂直擴展，這意味著擁有更多同構商業化節點比擁有更少的異構專門節點更可取。正因為如此，出現了一種使用商業化服務器來取代專用網絡交換機 ASIC 的呼聲。這樣做的一個好處是出現了一種支持更敏捷的變更速度的數據平面。SDN 數據平面（這里我們討論的是真正轉發數據包的東西）位于硬件 ASIC 或傳統內核網絡轉發的虛擬機上，而 CNF 已經開始探索像用戶數據平面（例如 VPP）、帶有快速數據路徑（XDP）的擴展 Berkeley 包過濾器（eBPF）和 SmartNIC 轉發等技術。
5
Layer 3 提升
云原生數據中心偏向于 Layer 3 解決方案。能夠聲明式地指定和自動化 Layer 3 網絡配置已經成為 Kubernetes 網絡模型發展中的一個決定性因素。這些新的云原生網絡依賴 IP 地址來連接集群的節點和應用程序，而不是 Layer 2 的 mac 和 VLAN。然而，這是編配器及其應用程序的主要關注點。數據中心有多個移動部件，它們具有不同的變化速度。這三個層是這樣的：在編配器之下（例如網絡操作系統 SONIC、配置工具 Terraform）、在編配器中（例如 Kubernetes）、在編配器之上但在容器中（例如 CNF）。編配器之下的網絡基礎設施結構，例如數據中心中的機架頂部交換機，仍然具有 Layer 2 配置。電信領域是采用 CNF 的一個重要驅動因素，它仍然不可避免地繼續使用 Layer 2，例如多協議標簽交換（MPLS）。Layer 2 的故事仍在通過新的交換軟件（如 SONiC）實現來續寫。
6
結論
網絡的配置、部署和自動化是難以實現彈性（云原生環境的一個主要部分）的部分原因。這可能是影響向超規模（如 Amazon）遷移的決定性因素，即使可以保證更定制化的部署。這與電信領域尤其相關，因為他們可能希望為企業客戶提供自定義網絡協議支持（例如，MPLS）。云原生網絡功能根據變化速率解耦網絡功能，細化到粗粒度鏡像和進程（例如容器）級別，解決了這些部署問題。這避免了網絡容易出現的同步部署問題。
CNF 是一種網絡功能，傳統上被認為是位于 OSI 網絡棧上的功能，只是在實現方面遵循了與云原生生態系統耦合的云原生實踐。網絡，尤其是電信網絡，有很長一段非功能性需求的歷史，比如彈性。電信服務供應商以 911 呼叫系統為例，它就是一個要求極端彈性和可用性的關鍵任務系統。即便如此，云原生生態系統的非功能屬性已經引起了服務供應商的注意。這些屬性，例如可用性（云原生類型）、易于部署和彈性，已經促使電信服務供應商向電信設備供應商（物理和軟件）施加壓力，要求它們更多地采用云原生。這要求這些新的網絡組件遵循云原生基礎設施最佳實踐，以便在云原生生態系統中成為成熟的解決方案。但這并不容易，因為對于具有高性能要求的傳統緊耦合組件（如網絡數據平面）來說，要將它們解耦是非常困難的。
CNF 數據平面是一項正在進行當中的工作，有許多解決方案。光是數據平面概念就足以讓 CNF 變得難以理解，因為 CNF 不僅僅是一個物理服務器的虛擬化表示。簡單地說，云原生數據中心中的網絡連接可以通過專注于默認的內核網絡和 Layer 3 IP4/IP6 網絡來避免這種復雜性。這對于電信來說通常是不可行的。這些問題是解耦網絡軟件的自然進程的一部分，所以沒有辦法避免它們。如果 CNF 做得好，就能達到以前沒有達到的更高水平的可部署性、彈性、易于配置和彈性。
要了解有關云原生網絡功能的更多信息，請加入 CNCF 的云原生網絡功能工作組。這里可以找到有關 CNF 認證計劃的信息。
腳注參考資料:
1.“原生云是指不需要人類做決定的自主系統。它仍然使用自動化，但只在決定需要采取的行動之后。只有當系統無法自動決定該做什么時，才會通知人類。”——摘自“Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment”（作者 Justin Garrion & Kris Nova，由 O'Reilly 出版）。
2.“自愈基礎設施本質上是一種智能部署，能夠自動響應已知和常見的故障。根據故障的不同，架構具有固有的彈性，并采取適當的措施來糾正錯誤。”——摘自“Cloud Native Architectures: Design high-availability and cost-effective applications for the cloud”（作者 Tom Laszewski，由 Packt 出版）。
3.“從直覺上看，一個系統的可靠程度取決于它最不可靠的組件（最薄弱的環節）。但事實并非如此：事實上，這是計算領域的一個舊想法，它的前提是在一個不太可靠的底層基礎之上構建一個更可靠的系統。”——摘自“Designing Data-Intensive Applications”（作者 Martin Kleppmann，由 O'Reilly 出版）。
4. 跨職能團隊將所有負責構建和運行系統某個方面的人員集合在一起，可能包括測試人員、項目經理、分析師、商業或產品所有者，以及不同類型的工程師。這些團隊應該很小，亞馬遜稱之為“兩個披薩團隊”，意思是團隊足夠小，兩個披薩足以喂飽每個人。這種方法的優點是，人們可以專注于單一的、集中的服務或少量服務，避免了在項目之間處理多任務。由一組固定人員組成的團隊比那些成員每天都在變化的團隊工作效率更高。——”Infrastructure as Code: Managing Servers in the Cloud”（作者 Kief Morris，由 O'Reilly 出版）。
5. “最好的方法是將容器視為一種打包服務、應用程序或作業的方法。它是一種升級版的 RPM，包含了應用程序及其依賴項，還為宿主系統提供了管理運行時環境的標準方法。我們不應該在一個容器中運行多個進程，而是使用多個容器，每個容器運行一個進程。這些進程成為獨立的、松散耦合的實體。因此，容器非常適合用在微服務應用架構中。”——摘自“Infrastructure as Code: Managing Servers in the Cloud”（作者 Kief Morris，由 O'Reilly 出版）。
6. 為了盡量減少專有解決方案，創建網絡系統的開放市場，并管理好通信的復雜性，國際標準化組織（ISO）開發了一種開放通信參考模型。這個參考模型被稱為 ISO 開放系統互連（Open Systems Interconnection，OSI）參考模型，提出了一個抽象的、分層的網絡模型。具體地說，它定義了七層抽象和每一層的功能。但是，它沒有定義必須在每一層使用的特定協議，而是給出了與每一層對應的服務和協議的概念。——“Architecture of Network Systems”（作者 DimitrIOS Serpanos & Tilman Wolf，由 Morgan Kaufmann 出版）。
7. “進程不共享內存，而是通過消息傳遞相互通信。消息從發送進程的棧復制到接收進程的堆。由于進程在獨立的內存空間中并發執行，這些內存空間可以進行單獨的垃圾回收，從而使 Erlang 程序具有非常可預測的軟實時屬性，即使在持續的高負載下也是如此。……異常發生時進程會失敗，但由于沒有共享內存，故障通常會被隔離，因為進程處理的是獨立的任務。其他處理不相關或不受影響的任務的進程可以繼續執行，程序作為一個整體可以進行自我恢復。”——摘自“Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems”（作者 Francesco Cesarini & Steve Vinoski，由 O'Reilly 出版）。
8. 路由器的數據平面實現了針對典型網絡流量的一系列操作。如前所述，這些步驟包括處理已到達數據包的 IP，通過交換機結構傳輸到輸出端口，以及調度對外傳輸。數據平面中的一個關鍵操作是確定將數據包發送到哪個輸出端口。這個過程稱為路由查找……——“Architecture of Network Systems”（作者 Dimitrios Serpanos & Tilman Wolf，由 Morgan Kaufmann 出版）。
作者簡介：
Wavell Watson 已有 30 年從事軟件開發的經驗。為了追求軟件協作的完美組織結構，他花了數年時間研究博弈論和其他商業專業知識。他還創立了 Austin Software Cooperatives，并將 Vulk Coop 作為團隊開發軟件的另一種方式。他擁有多元化的背景，包括在海軍陸戰隊擔任計算機程序員，以及在多個行業（包括國防、醫療、教育和保險）開發軟件。在過去的幾年里，他一直在開發補充性的云原生系統，比如 cncf.ci 儀表盤。他目前從事與云原生網絡功能（CNF）認證和云原生網絡功能測試套件相關的工作。
https://www.infoq.com/articles/cloud-native-network-functions/#theCommentsSection
