作者：CNStack 容器平臺、龍源電力：張悅超 、黨旗
龍源電力容器雲項目背景
龍源電力集團是世界第一大風電運營商， 隨着國家西部大開發戰略推進，龍源電力已經把風力發電場鋪設到全國各地，甚至是交通極不便利的偏遠地區，這使龍源電力成爲全球裝機容量、風電佔比最大的運營商，但與此同時企業也面臨諸多基礎設施建設和維護的挑戰。分設在全國 30 多個省的 240 多座風電場站有近千臺服務器，因爲大多地理位置偏僻，所以中心到邊、端維護不便；另外，風電場站計算資源有限，網絡 IP、帶寬等資源稀缺給 IT 架構規劃、管理帶來較高成本。同時，運行在省中心、風電場站的不同業務應用對計算、存儲、網絡資源需求差異性大，也需要兼顧存量資源的統一管理，場站應用系統的維護更新需要大量重複性工作，管理成本高、難度大等問題逐漸成爲企業發展的瓶頸。
CNStack 應用與龍源電力的最佳實踐
CNStack（雲原生技術中臺）是阿里云云原生最佳實踐的輸出載體，它可以在多雲、混合雲場景下集中納管基礎設施資源，統一編排和調度工作負載，幫助客戶高效構建高性能、高可用、高可靠和安全合規的現代化應用，提升企業數字化轉型的整體效能。CNStack 致力於幫助企業 IT 架構重組升維，提供用最低的成本構築業務發展護城河，產生更大的市場利潤技術原動力。CNStack 在過去兩年持續打造企業級分佈式基礎設施 OS，幫助應用開發者屏蔽底層計算、網絡複雜拓撲，和異構差異性，並通過適應性優化 IaaS+ 服務，向以業務爲中心的企業提供更多目標爲導向的組合效用輸出。
2.1 分佈式雲計算和服務
2.1.1 基於 OpenYurt 的雲邊協同
龍源項目是典型的邊緣場景，雖然雲中心到省中心架設專線實現了全網算力節點的網絡互通，但是由於廣袤的地理分佈，導致網絡帶寬資源稀缺，網絡傳輸質量無法保障。省中心、風電場站不僅是地理上的概念，也是業務多租戶隔離的獨立單元，在這些單元內部，由於地理上相對靠近，其網絡質量及帶寬限制相對寬鬆。基於 OpenYurt的 CNStack 雲邊協同服務（CNStack EdgePaaS）很好地解決弱網環境下雲邊協同和邊緣自治問題。OpenYurt 是阿里雲開源的業界首個以無侵入方式將 Kubernetes 擴展到邊緣計算領域的項目，於2020年9月成爲 CNCF 沙箱項目。OpenYurt 針對邊緣場景中網絡不穩定、雲邊運維困難等問題，對原生 Kubernetes 無侵入增強，重點提供了邊緣節點自治、雲邊運維通道、邊緣單元化的能力。
OpenYurt 提出的“節點池”概念，對應龍源項目的組織拓撲，實現了下圖的部署結構：
“節點池”帶來的可不僅僅是資源分組管理這麼簡單，OpenYurt 還提供了更多專門針對邊緣場景的特性：
- 應用單元化
區別於傳統的應用多單元管理，邊緣場景下的業務單元數量會顯著增加。如果採用傳統的分發模式，邊緣UnitedDeployment 部署模型將用戶的工作負載部署在不同的節點池中，業務的實例數、版本、鏡像、配置等信息都可以按照節點池的維度進行統一管理、統一分發，而不是每個單元獨立管理。
- 服務拓撲
在邊緣場景下，業務負載會按照站點的維度創建多實例。不同站點之間的應用，只能通過本站點的應用訪問，而不能由相鄰站點訪問。爲此，OpenYurt 提供了服務拓撲的能力，確保邊緣節點應用只能由相同節點池的節點訪問，或者只能由本節點訪問。
- 邊緣自治
傳統的 Kubernetes 對網絡有着很高的要求，一但發生了網絡中斷，Kubernetes 會基於可用性的原因，將工作負載調度到別的可以聯通的節點上。這個特性在中心化的集羣是很棒的特性，但是這個特性在邊緣場景下反倒會帶來很大的負面影響。因爲這種中斷通常只會發生在邊緣與中心之間，這種中斷一但發生，用戶期望的結果是邊緣側的工作負載繼續工作，待網絡恢復後，中心側恢復對比邊緣業務負載的管理即可。通過 OpenYurt，中心側會在邊緣節點不可用的情況下，阻止工作負載的驅逐，同時確保和中心斷聯的節點上的工作負載繼續運行。
2.1.2 雲邊網絡優化
部署在邊緣節點上的 CRD Controller，或者 DaemonSet 類型的管控組件都可能對集羣不同範圍的資源做list/watch，可能造成邊緣節點到中心節點較多開銷的網絡 I/O 負擔。爲此設計的 OpenYurt Pool-Coordinator 組件，會爲節點池維度的資源提供邊緣側緩存，從而降低因爲這些資源的大量 list/watch 請求造成的雲邊網絡帶寬問題，相比原生 Kubernetes 雲端出口流量峯值降低90%。
待 Pool-Coordinator 實例啓動，會由選主機制選出的 Leader YurtHub 將 Pool-Scope 資源，例如 endpoints/endpointslice 拉取至邊緣，進而同步至 Pool-Coordinator 組件，緩存起來，以供節點池內全部節點使用。節點池內全部節點上運行的 Yurthub，將 Pool-Scope 資源讀請求代理至 Pool-Coordinator。理論上，針對一個資源的全量請求，一個節點池只需要一條雲邊長鏈接即可，節點池內的這些資源的讀請求，都交由 Pool-Coordinator 向下提供服務，從而很大程度降低雲邊網絡消耗。特別是在具有帶寬要求的弱網絡場景，Pool-Coordinator 可以削弱由於邊緣基礎容器啓動/重建導致的大量請求，以及減少運行時期的雲邊資源下發量，因此適配於龍源電力部分弱網絡邊緣節點。Pool-Scope 資源默認定義爲 endpoints 和 endpointslices 兩種資源。這兩種資源在 Yurthub 代理的雲邊流量中佔比較高，這在規模較大集羣中體現的更爲明顯；另外 Pool-Scope 資源要求爲節點池內公用的資源，與調用方所屬節點無關，這也適配於上述兩者。Pool-Scope 資源可由用戶配置其他資源，例如 Pods，Node，以及 CR，以應對在特定資源量大的網絡優化場景。
該功能已在 Openyurt 最新版本（v1.2）中發佈，近期將應用到龍源項目中。
除此以外，CNStack 管控組件經過一系列優化升級，已經將單個邊緣節點到中心 master 節點單向實時網絡 I/O 從32Mb/s控制在200Kb/s以內。
2.1.3 分佈式內容分發服務
在邊緣場站除了算力節點以外，還有很多 IOT 設備，例如攝像機，交換機，無線 AP 等等。這些設備並不是安裝後就不管，而是同樣有升級的需要。以無線 AP 爲例，一個 AP 的系統升級包有幾十 mb，但是龍源的一個場站就可能存在幾個甚至是幾十個無線 AP，如果這些 AP 的升級操作全部從雲中心或者省中心獲取升級包，將會產生極大的流量開銷。我們採用了，以站點粒度統一分發，再通過站點內共享的方式，實現對雲邊之間網絡流量的節約：
首先在雲中心打包需要分發的內容，以內容服務的方式分發到各個場站。此步驟只需要花費"內容分發服務*站點數"的流量。內容分發服務在邊緣側部署以後，無線 AP 再通過 ftp 協議訪問本站點的服務端點，這樣，無論邊緣側有多少無線 AP，雲端之間只需要花費一份內容流量即可。
通過此套方案，獲得瞭如下的效果：
- 以龍源場站26000臺無線 AP 的 IOT 升級計算，AP 升級工期從6個月縮短至1個月，全國專線網絡帶寬佔用降低98%
- 提升了邊緣側訪問的響應速度
- 提升邊緣側訪問的可用性
- 對數據的訪問者無侵入
CNStack EdgePaas 還將對內容分發服務進一步升級，大幅提升內容分發能力：
- 動態推送分發內容
- 精確到單個內容+站點的分發控制能力
- 邊緣側提供更多的訪問協議支持（http、ftp、sftp）
- 完善的訪問控制
在邊緣站點側，CNStack EdgePaas 提供站點維度的訪問代理，數據消費者只需要使用標準協議（http、ftp、sftp）即可獲取關注的數據。同時依託於服務協同中就近訪問的特性，用戶無需爲每個站點的應用做單獨的配置，全部共享一個服務即可實現內容的獲取。
同時，此方案還具備預熱的能力。由於內容分發的流程是獨立於數據消費流程的，所以可以在消費行爲發生之前，提前將消費者需要使用的數據主動對送到業務單元，進而實現數據預熱。
2.1.4 邊緣鏡像倉庫加速
龍源項目遍佈在全國各地的省中心及邊緣場站節點雖然網絡鏈路上與雲中心打通，但是邊雲網絡帶寬資源稀缺，應用鏡像數量、規格都較大給容器鏡像分發造成了巨大挑戰。中心化鏡像倉庫服務極易造成雲邊網絡擁塞。
基於 Harbor 的鏡像複製能力，提供兩級鏡像倉庫服務方案，實現邊緣鏡像加速。在各個區域分別部署各自的 docker registry 實例，跟雲端的 harbor 服務一起形成一主多從的架構。基於 Harbor 的複製功能配置同步關係，讓雲端的鏡像自動同步到各個區域中的 docker registry 實例。各個區域內的邊緣節點直接從本區域的 docker registry 實例拉取鏡像。
該方案達成的效果：
- 極大減少了對中心 Harbor 服務的大量併發
- 一個區域對於一個鏡像只需要從中心拉取一次，減少了對雲邊網絡帶寬的消耗
- 區域內的邊緣節點就近訪問鏡像倉庫服務，獲取鏡像更快，應用更新更快
2.2 多類型應用資源共池調度和管理
2.2.1 虛擬化超融合
龍源管理平臺除了需要承載容器化的業務系統之外，還需部署管理運行在虛擬機內的業務系統，容器化應用與虛擬化應用間還需要互相訪問。
CNStack 虛擬化服務（CNStack Virtualization）基於 KubeVirt、hybridnet、open-local 等雲原生軟件構建了雲原生虛擬化產品能力，使用一套控制平面同時管理容器和虛擬機，爲用戶提供虛擬機資源的管理能力，實現容器與虛擬機的資源共池管理、靈活分配、統一調度。
雲原生虛擬化基於容器來管理運行 KVM 虛擬機，通過 Kubernetes 自定義資源（CRD）的形式使得虛擬機資源可被視爲 Kubernetes 集羣的“一等公民”，提供了不同於容器的虛擬機生命週期管理接口，通過與標準的 CNI 容器網絡插件和 CSI 容器存儲插件對接，使得虛擬機與容器可複用 Kubernetes 集羣內的網絡與存儲資源：
- 通過阿里雲自研的 hybridnet 容器網絡插件將虛擬機網絡與 underlay 物理網絡打通，使得虛擬機內的視頻監控應用可以直接訪問管理場站節點的攝像頭設備。
- 通過阿里雲自研的 open-local 容器存儲插件將節點的本地存儲資源池化，以保存虛擬機磁盤數據。
2.2.2 GPU調度和隔離
龍源項目多類型業務分別還包括 CPU 和 GPU 應用，CNStack 可以運維和調度其分佈在各邊緣場站的異構GPU 節點。CNStack 提供了豐富的 GPU 友好的管理界面，如導入、識別、GPU 設備故障檢測等。爲了更有效地利用 GPU 並實現成本效益，CNStack 還提供了 GPU 共享調度和 GPU 隔離功能。
通常情況下，Nvidia GPU 容器調度將一個 GPU 卡分配給一個容器。然而，在圖像和視頻推理場景中，一個容器中的算法模型可能無法充分利用一張 GPU 卡的算力，導致資源浪費。在成本效益的背景下，GPU 共享是一個必然的需求。爲了實現 GPU 容器層面的共享，需要對一張 GPU 卡進行細粒度資源劃分，將 GPU 的細粒度資源上報到 Kubernetes，然後由調度器進行精細化調度和分配，實現 GPU 的共享使用。CNStack 通過如下核心組件實現了 GPU 共享調度和 GPU 隔離能力：
- 通過阿里雲自主研發的 GPU-Share Device Plugin 和強化的調度器，可以實現細粒度的 GPU 資源上報、調度和綁定，從而實現 GPU 的共享調度。
- 通過阿里雲自主研發的 AMP eGPU 組件，可以實現各個容器間共享 GPU 的隔離，避免了共享 GPU 中業務的相互干擾。
2.3 適配複雜 IT 架構的容器雲底座
除了需要適配複雜業務模型的異構應用生命週期管理外，龍源項目的網絡要求適配和多 ISV 基於大規模研發的風控問題也面臨諸多挑戰。
2.3.1 基於 hybridnet 的複雜網絡模型適配
關於龍源項目的網絡需求，經過與客戶、業務方的溝通確認，總結了以下幾點：
- 平臺部署在以 IPv6 網絡爲主的基礎機器環境之上，機器是無法保證具備 IPv4 地址的，並且機器地址申請困難，遍佈在全國各地的場站、省站與雲中心會通過 IPv6 的主機鏈路進行通信。2. 部分業務應用當前沒有完成 IPv6 適配，存在使用 IPv4 地址進行通信的需求，由於 IPv4 地址資源限制，這部分業務無法使用 IPv4 鏈路通信。3. 省站中，業務應用所在的虛擬機需要使用獨立的機器網段 IPv4/IPv6 地址與集羣外部通信（如上所述，虛擬機和容器使用的是相同網絡實現）。綜上來看，整體網絡架構是非常複雜的，“IPv4/IPv6 雙棧” 以及 “overlay/underlay 鏈路混合部署” 兩種場景在需求上交疊了起來，對於容器網絡實現的靈活性和健壯性提出了巨大挑戰。
Hybridnet 網絡插件是阿里自研的通用開源 CNI 實現，旨在提供全場景下的 Kubernetes 容器網絡部署能力。
目前 hybridnet 已經全面支持了 IPv4/IPv6 雙棧場景以及 VXLAN（overlay）、VLAN（underlay）、BGP（underlay）網絡的混合部署，並且通過精簡的架構設計，實現了不輸於 flannel 的穩定性（控制組件和數據面解藕）。
基於 hybridnet 的能力，CNStack 通過如下設計滿足了龍源場景訴求：
-
所有 Pod 默認部署爲 overlay 形態（hybridnet 實現的 VXLAN 網絡），容器只有 IPv6 地址，使用 IPv6 鏈路進行通信，這樣，平臺本身只依賴底層 IPv6 網絡通信，並且不佔用額外的底層網絡地址。2. 對於部分存在 IPv4 通信訴求的 Pod，hybridnet 基於底層 IPv6 網絡虛擬出 IPv4 的 overlay 容器網絡地址，提供給沒有完全適配 IPv6 網絡的應用 Pod 使用，不佔用額外的底層網絡地址，並且不依賴底層 IPv4 網絡。
-
結合每個省站的網絡規劃，增量爲省站配置 IPv4/IPv6 的 underlay 網絡（hybridnet 實現的 VLAN 網絡），與物理交換機協同工作，實現容器網絡和底層網絡直接打通，並且爲虛擬機分配對應 underlay 網絡的地址。
2.3.2 多 ISV 場景下規模集羣運維
基於 User-Agent 的限流能力
在龍源項目中，業務系統由多 ISV 協同開發，各 ISV 選擇的 Kubernetes 擴展開發框架不盡相同，操作Kubernetes 資源規模和頻率也無法控制，所以極易產生到 Kubernetes apiserver 超出預期的調用量，可能造成雪崩效應。所以，首先爲 apiserver 開啓限流，kube-apiserver 支持 MaxInflight 和 APF（API Priority and Fairness）兩種限流能力：
- MaxInflight 限流能力可以限制 API Server 同時處理的讀和寫的請求總量，但是粒度較粗無法對請求來源做限流，不能很好地對 API Server 起到防護作用。
- APF 限流能力可以用來細化限流的管理，比如按照核心控制、一般控制器、節點組件等將總併發量按照比例進行劃分，避免某一個用戶或組件的異常行爲影響全局，但是維護成本較高，目前在業內深度使用的案例並不多。
另外，針對 MaxInflight 和 APF，它們都是通過 User 來做限流，也就說它們需要先經過認證。但是，認證並不是廉價的，在大量請求到來時，API Server 將消耗大量 CPU 來解 x509 證書或 ServerAccount Token 的驗證。在應對大量請求的時候，應該通過最小開銷來決定是否放行請求。綜上來說，已有的限流能力並不能方便、有效地對不同客戶端的請求進行不同程度的限流，並且在判斷是否放行請求時會存在較大的開銷。爲此，CNStack容器服務 （ACK Distro）在 API Server 中增加了基於 UA（User-Agent） 的限流能力，UA 限流能力可以根據請求中的 User-Agent、請求的操作類型，請求的資源，在 API Server 認證之前就決定是否放行該請求，實現以最小的開銷來對請求進行區分限流。
如圖所示，是 UA 限流判斷的時間點。它會從 HTTP 請求中取出 User-Agent、resource、verb 等內容組成一個三元組，如果該三元組與用戶設置的 UA 規則中的三元組相匹配的話（User-Agent 支持正則表達式），則會使用令牌桶算法根據 UA 規則的中 QPS/Burst 值判斷是否放行該請求。如果放行該請求，則會進入認證階段；如果拒絕該請求，則會返回 429 狀態碼，並允許請求的客戶端在 1 秒後進行重試。
綜上，UA 限流可以方便、有效地針對不同客戶端的請求進行不同程度的請求，並且以最小開銷來決定是否放行請求，同時精確 UA 匹配，避免誤傷。
etcd 集羣拆分
鑑於龍源集羣的規模，以及多 ISV 業務應用需要頻繁、大量創建 deployment/pod 等集羣資源的業務需要，對 etcd 性能要求較高。針對 event 資源來說，頻繁創建、刪除的操作會產生大量該資源，但該資源對集羣的正常運行影響並不大，因此爲了降低單 etcd 集羣的壓力，該資源可以被存儲到其他 etcd 集羣中。針對 lease 資源來說，如果該資源請求超時，則會導致許多控制器選舉失敗。一旦控制器被重啓，則會重新發起全量的 List 操作，進一步加劇對 etcd 和 apiserver 的壓力。因此，該資源不適合存儲於壓力較大的 etcd 集羣中，但是該資源相比 Pod 等資源是可以重新生成的。所以，該項目中 CNStack ACK Distro 將 event、lease 兩種資源存儲到獨立的 etcd 集羣中，減少了單 etcd 集羣的壓力，最終減小了單 etcd 集羣壓力大帶來的影響，保證集羣的穩定性。
總結
阿里雲 CNStack 應用於龍源電力項目的分佈式雲解決方案已於近期完成測試上線，實現中心到240多個風電場服務器的統一可視化管理，支持同一個平臺對運行於虛擬化、容器上的 CPU、GPU 多類型應用資源共池調度，多租戶資源隔離應用開發和運維等，部分雲化能力對邊緣場景提供就近服務，極大降低邊雲網絡傳輸開銷。該解決方案利用容器及雲原生技術幫助企業完成一次 IT 架構的躍遷，實現邊緣資源、應用運維效率10倍提升，邊緣場站資源利用率3倍提升，斬獲雲原生技術實踐聯盟（CNBPA）頒發的2022年度公共事業行業最佳雲原生實踐獎。 2023年，阿里雲 CNStack 繼續深層解決企業生產環境實際問題，已在邊雲網絡帶寬優化，雲化能力邊緣就近服務，中心化 NoOps 運維等方面規劃多項能力，持續打造智慧新能源最佳實踐。
參考資料：
CNStack：
https://www.aliyun.com/product/aliware/cnstack
https://github.com/alibaba/CNStackCommunityEdition
ACK Distro：
https://www.aliyun.com/product/aliware/ackdistro
https://github.com/AliyunContainerService/ackdistro
Hybridnet：
https://github.com/alibaba/hybridnet
Open-Local：