基于K8S 的SDN 控制器可擴展性優化研究

李家興，朱曉東，曾學文

（1.中國科學院聲學研究所國家網絡新媒體工程技術研究中心，北京 100190；2.中國科學院大學，北京 100049）

軟件定義網絡(Software Defined Networking,SDN)[1]中，控制面接收數據面消息，利用全局網絡拓撲及帶寬資源信息制定靈活的可編程策略[2]。網絡規模的擴大暴露出了控制面處理能力不足的問題，為此出現了控制面可擴展性的相關研究[3-6]。圍繞控制面可擴展性的研究主要集中在扁平化多實例擴展[7-9]和層次型分層控制擴展[10-12]兩種方法，但該兩類方法面臨著節點狀態同步開銷大、逐層傳遞時延高、線性擴展能力弱以及彈性控制能力差的問題。

該文針對控制面擴展性差的問題，基于K8S 系統架構[13]對控制器模塊化解耦合進行水平擴展，提升控制平面的可擴展性能力。

1 K8S系統架構

K8S 容器編排系統由Google 開源推出，該文利用K8S 編排特性對SDN 控制面可擴展性進行研究。K8S 系統架構如圖1 所示，包含Worker 節點和管理Worker 節點的Master 節點。

圖1 K8S系統架構圖

Master 節點用于對整個K8S 集群進行全局控制，節點內部包含Kube-apiserver、controller-manager、scheduler 以及etcd 等核心控制管理組件，其中Kubeapiserver 是供客戶端和其他組件進行相互調用的對外接口，controller-manager 用于監視管理集群的資源狀態，scheduler 負責對集群資源進行調度，etcd 則存儲集群狀態。

Worker 節點執行具體的應用程序，是任務工作節點，通常包含kubelet、kube-proxy 以及cAdvisor 等核心組件，其中kubelet 組件從Kube-apiserver 拉取Pod 生命周期信息，負責Pod 的創建、啟動以及刪除停止任務，其中Pod 為K8S 集群進行資源調度的最小單位，內部由一個或者多個Docker 容器組成，kubeproxy 負責進行服務發現和訪問路由，cAdvisor 則用以監測統計集群內部主機、Service 以及Pod 的運行數據。

K8S 集群內部除了前述各組件之外，還涉及Label、Selector以及Service等資源，其中Label是為Pod 所指定的標簽，集群內部的Selector 選擇器用于根據Pod 的Label 標簽篩選出一組具有相同標識的Pod 分組構建Service 服務，以暴露IP 地址和服務端口的方式提供服務，當客戶端訪問Service 時，會結合負載均衡算法從Service 的后端Pod 副本中選取一個Pod 提供服務，通過這種方式將復雜的處理邏輯隱藏于Service 之后。

2 基于K8S的SDN控制器架構

2.1 網絡控制器架構設計

對SDN 控制器進行模塊化解耦合，將解耦后的控制器子模塊封裝成相互獨立的Service 部署于K8S集群，通過擴展各模塊Service 的Pod 數量，提升模塊化處理能力，從而以增強控制器各子模塊處理能力的方法提升控制面對SDN 消息的處理能力，該文所設計的架構如圖2 所示。

圖2 基于K8S的控制器架構圖

如圖2 所示，將SDN 控制器拆分成包括協議和驅動模塊、控制模塊、設備管理模塊、配置模塊以及一系列應用模塊在內的多個子模塊，各模塊之間建立TCP 連接傳送SDN 消息。在該設計中，為追求模塊的性能和穩定性，采用高性能的NGINX Web 服務框架[14]對各子模塊進行開發。

協議和驅動模塊：該模塊位于SDN 控制器最南端，通過OpenFlow 協議[15]或具有協議無關性質的POF 協議[16]與交換機交互SDN 消息。對消息的處理流程包括兩個階段，第一階段是當交換機上線時，該模塊負責與交換機設備進行握手并獲取交換機相關設備信息，第二階段過程中，該模塊接收交換機上報的packet-in 消息以通知控制器處理新數據流的首個網包以及請求刪除流表項的flow-removed 消息，并逐級往上傳遞至應用模塊(application module)。

控制模塊：負責將所接收到的南向流量分發至北向各應用模塊，并將應用模塊處理后的響應消息向下轉發至協議和驅動模塊。為實現Pod 無狀態水平擴展以及消息在模塊間的高效分發，該文采用北向應用對消息進行主動訂閱并使用高可靠的Redis數據庫[17]對訂閱規則進行管理的方法，該部分內容將在2.2 節詳細展開。

設備管理模塊：控制平面為獲取網絡拓撲，通過LLDP(Link Layer Discovery Protocol)協議進行鏈路發現，設備管理模塊負責對數據平面的設備狀態以及所獲取到的鏈路狀態信息進行管理，供北向應用進行調用。

配置模塊：該模塊為控制面操作人員提供了一個使用方便、配置簡單的接口，對轉發設備的IP、MAC 等物理接口信息進行配置并對配置信息進行存儲管理。

應用模塊：交換機端發起的SDN 請求消息最終交由此模塊處理生成packet-out 消息或flow-mod 消息，并向下傳遞最終在交換機上生效，該模塊的處理邏輯可根據具體應用需求進行靈活編程。

控制器模塊解耦后，交換機所發起的SDN 請求消息通過協議和驅動模塊上送至控制模塊，控制模塊將所接收到的消息分發至應用模塊進行處理，應用模塊生成的響應消息又通過控制模塊轉發至協議和驅動模塊，最終下發至軟件交換機?？刂破髂K化解耦之后將各模塊部署成K8S集群中不同的Service，從圖3所示的關系圖中可以看出，一個Service后端可以包含多個Pod，當控制器子模塊接收到訪問請求時，從組成該Service的Pod集合中選出一個Pod提供服務。

圖3 Service與Pod關系圖

在上述控制器架構中，協議和驅動模塊、控制模塊以及應用模塊需要處理大量的SDN 消息，對處理性能具有很高的要求，通過增加Service 后端Pod 副本數量的方法增強子模塊處理能力，進而提升整個控制面的可擴展性能力。

2.2 基于K8S的網絡控制器關鍵技術

2.2.1 高效分發與高可靠機制

在常見的網絡控制器架構中，協議和驅動模塊通過TCP 協議與交換機連接，解析控制消息，將packet-in 消息通過南向接口提交給核心層，核心層按照應用注冊網包處理器的優先級逐個串行回調應用的網包處理函數，該種方法面臨著串行回調過程所帶來的消息冗余處理問題，特別是當控制器上部署越來越多的新應用，控制時延會不斷增大。該文采取控制器模塊解耦合機制，解決模塊耦合過重的問題。此外，采取應用對消息進行主動訂閱的機制并利用高性能Redis 數據庫對訂閱規則進行管理，實現控制模塊的無狀態水平擴展以及控制模塊與應用模塊之間消息的高效分發。消息的主動訂閱與高效分發結構如圖4 所示。

圖4 消息訂閱分發結構圖

K8S 集群內部DNS 支持對serviceName 的解析功能，各Service 之間通過serviceName 建立TCP 連接即可進行相互訪問。此外，交換機向控制器上報的packet-in 和flow-removed 消息中包含table id(數據流表標識)和entry id(流表項標識)字段?；谏鲜鰞身椞攸c，以table id 和entry id 組成key 值，以北向各應用模塊對應的serviceName 作為value 值，構成消息訂閱規則，并使用高可靠的Redis 集群對訂閱規則進行管理。

以下是控制模塊的初始流程描述，初始化流程中，啟動各應用模塊、各應用模塊將自身的serviceName以及消息訂閱規則下發至Redis 集群、控制模塊向Redis 集群獲取應用模塊下發的serviceName 集合并作為客戶端與各應用模塊建立TCP 連接；當流表初始化應用模塊檢測到交換機與協議和驅動模塊握手交互完成后，向新上線的交換機下發初始表項。整體工作流程見算法1。

算法1 中，1-7 行描述控制模塊與應用模塊之間的初始化過程以及交換機與協議和驅動模塊握手交互完成后，觸發流表初始化應用向交換機下發初始流表的過程。7-14 行描述了控制模塊接收協議和驅動模塊傳送的packet-in 或flow-removed 消息后，提取消息中table id 和entry id 字段作為key 值，通過key 值向Redis 集群查詢訂閱此消息的北向應用集合，并依據所查詢到的結果，將消息分發至相應的北向應用進行后續處理。算法1 中tid_svc 是指將流表標識作為訂閱規則的北向應用集合，而eid_svc 是指將流表標識和流表項標識同時作為訂閱規則的北向應用集合。

上述通過應用對消息進行主動訂閱，并通過高可靠Redis 數據庫集群對訂閱規則進行管理的方法，使得控制模塊可以進行無狀態水平擴展，并提升了控制模塊與應用模塊之間的通信效率。當網絡規模擴大需要存儲管理更多的訂閱規則時，可以對Redis 集群進行靈活地橫向擴展以解決內存容量不足的問題。

2.2.2 彈性伸縮機制

網絡流量的分布呈時間和空間上的動態分布，在控制面接收到的消息請求相對平緩的時間段，控制面所承受的負載相對較低，而在流量激增的時間段，控制面則面臨著很高的負載挑戰。因此，控制面進行彈性伸縮應對網絡流量靈活變化的能力顯得尤為重要。

在K8S 集群內，為各Service 配置水平自動縮放器(Horizontal Pod Autoscaling,HPA)[18]，以感知各Service的資源占用情況，并結合彈性伸縮規則，動態調整Pod 數量以支持服務的高可用。在所設計的控制器模塊化解耦方案中，協議和驅動模塊、控制模塊以及應用模塊被部署成相互獨立的Service，通過收集各模塊Service 的CPU 占用率，結合式（1）計算出當前負載情況下所期望的Pod 個數，并使用HPA 水平縮放器對Service 后端的Pod 副本個數進行調整。此外，當任務負載降低時，所期望的Pod 副本個數低于當前運行的Pod 副本數，會讓多余的Pod 副本緩沖一段時間后才進行銷毀，從而降低頻繁創建和銷毀Pod所帶來的抖動。

式（1）中，desiredReplicas 是擴容后所期望的Pod 副本數，currentReplicas 是當前運行的Pod 副本數，currentMetricValue 是指K8S 集群Service 對應的CPU 占用率，desiredMetricValue 是HPA 部署服務所配置的CPU 核使用門限值。

將HPA 應用于網絡控制器設計，滿足網絡控制器根據網絡流量進行彈性伸縮的需求，工作流程詳見算法2。

為解耦后的各控制器子模塊部署各自的HPA縮放器，從而對各模塊進行資源占用監測并進行水平伸縮，上述的算法2 中，水平縮放器根據模塊的CPU 占用率以及所配置的資源使用限制，動態伸縮網絡控制器各子模塊Service 后端的Pod 數量，從而提升了模塊處理能力，進而提升了控制面應對網絡流量動態變化所需的彈性管理能力。

3 仿真與評估

為評測所提的基于K8S 的網絡控制器的性能表現，該文在x86 服務器上搭建環境進行測試，測試環境所使用的操作系統為Anolis OS release 8.4，CPU 型號為Intel(R) Xeon(R) Silver 4210 CPU@2.20 GHz，物理內存128G，K8S 版本v1.21.1，Redis 版本v4.0.8。為測試方便，將K8S 的Master 和Worker 節點部署于同一臺物理服務器。采用NGINX 框架對控制器各組成模塊進行開發，在上述物理環境中測量得到表1數據。

表1 模塊性能與資源占用表

從表1 數據可以看出NGINX 框架具有吞吐性能好、物理內存占用低且穩定的特點，利用此框架開發控制器子模塊將能在一定程度上保障控制器系統性能。

3.1 交換機-控制器平均響應時延

文獻[19]指出控制通道的平均響應時延是衡量控制通道性能的重要指標，在此基礎上，該文對控制通道的響應時延分布進行測量，進一步衡量控制通道的穩定性。

該實驗通過自研交換機模擬工具連接控制器以滿足控制器零丟包的速率向控制器發送攜帶當前系統時間戳信息的packet-in 消息，控制器接收packetin 消息后，根據應用處理邏輯生成packet-out 響應消息，測試工具記錄從發起請求消息至接收到響應消息的時間差，從而得到消息響應時延，對每組消息的響應時延進行記錄，進而計算得到控制通道的平均響應時延以及時延分布情況。該實驗選取業界廣泛使用的ONOS[20]網絡控制器、扁平化擴展的ONOS 三節點集群控制器與該文所提的MHC(Micro Horizontal Controller)控制器進行性能對比，實驗結果如圖5 所示，圖中主縱坐標記錄發包速率與響應時延分布關系，副縱坐標記錄發包速率與平均響應時延的關系。

圖5 不同發包速率下控制器響應時延分布以及平均響應時延關系曲線

從圖5 的各測試結果獨立來看，控制器的平均響應時延隨著模擬工具發包速率的增大而逐漸上升，并且當速率超過某一門限值時，延遲迅速增大，從關系曲線可以看出，ONOS 三節點集群的門限值最低，其次是ONOS 單節點控制器，而該文所提的MHC控制器門限值遠高于兩者。

從圖5(a)和圖5(b)的主縱坐標軸實驗結果對比能夠看出，ONOS 單節點以及ONOS 三節點扁平化擴展的響應延遲主要集中在低于1 ms 和高于10 ms 的部分，說明控制通道的延遲波動較大。從副縱坐標軸的平均響應時延結果來看，ONOS 扁平化集群擴展方式相對于ONOS 單節點控制器，由于集群節點同步開銷，削弱了控制器實例的處理性能，出現了平均響應時延升高、控制實例吞吐性能下降的問題，說明該種扁平化多實例擴展方式并不能使得控制面處理能力線性增長。結合圖5(c)的測試結果，可以看出該文所提的控制器模塊化多Pod 水平擴展方案的響應時延集中分布在2 ms 以內且波動較小，說明控制通道的穩定性更高。此外，還可以對比看出該文所提方案具有更高的吞吐性能以及更低的平均響應時延，證明了該文所提MHC 控制器擴展性方案的有效性。

3.2 控制面控制通道容量

實際生產環境中一個控制器實例會連接管理多個交換機，因此控制器所能管理的交換機個數也是衡量控制面擴展性優劣的重要標準。該實驗使用多個模擬工具連接至控制器同時以恒定速率發送packet-in 消息，測試控制器在不丟包的情況下所能支持的最大交換機個數以及連接最大交換機個數時控制面的平均響應時延。該節測試ONOS 扁平化集群擴展方式與所提MHC 控制器擴展性方案進行性能對比，實驗結果如圖6 和圖7 所示。

圖6 控制通道容量曲線圖

圖7 發包速率與平均響應時延關系曲線圖

從圖6 的實驗結果能夠看出，隨著消息請求速率的增大，控制器所能管理的交換機數量逐漸減小，通過曲線還可以看出，該文所提的控制器解耦化擴展方案在每個服務部署單個Pod 的情況下所能管理的最大交換機數約為ONOS 三節點集群擴展方法的4～6 倍。此外，從服務單Pod 到雙Pod 部署的測試結果對比可以看出，該文所提MHC 控制器通過水平擴展服務Pod 數量，控制平面所能管理的交換機個數線性成倍增加，說明該文所提MHC 控制平面通道容量具有線性擴展能力。

從圖7 實驗結果可看出，在請求速率低的情況下出現控制通道平均響應時延高的現象，出現該現象的原因是控制通道容量有限，在低請求速率情況下連接管理更多的交換機，給系統帶來了額外開銷，導致控制面處理能力被削弱，從而出現平均響應時延高的問題，說明交換機連接數量和請求速率對控制面處理性能均有影響，這也符合曲線中發包速率增大而平均響應時延上下波動的現象。此外，橫向對比各實驗結果可以看出，MHC 控制器擴展機制在達到控制通道最大容量時對應的平均響應時延遠低于ONOS 三節點集群控制器，并且MHC 控制器模塊化水平擴展下的平均響應時延未發生顯著變化，說明所提擴展性方法未帶來明顯的延遲抖動。

綜合上述實驗結果表明，該文所提MHC 控制器模塊解耦并以模塊化水平擴展的方式，具有控制通道容量高、線性擴展能力強等特點。

4 結束語

為應對網絡流量增長而出現的控制面處理能力不足的問題，業界相關研究集中于扁平化以及層次型多控制實例擴展方式，但該類擴展性方法面臨著節點狀態同步開銷大、線性擴展能力差以及彈性控制能力弱的問題，該文提出控制器模塊化解耦合，并基于K8S 進行模塊化水平擴展的方法對控制面擴展性進行研究。最后，通過實驗對比ONOS 單節點控制器、ONOS 三節點集群控制器以及該文所提的MHC 控制器性能表現，結果表明該文所提基于K8S的MHC 控制器線性擴展能力強、平均響應時延低、控制通道穩定性好、系統吞吐高，驗證了所提SDN 控制器可擴展性優化方案的可行性以及有效性。