摘要：為保證高速公路上門架系統的落地項目的成功落地，選擇K8s和KubeEdge來進行整體的應用和邊緣節點管理。
一、項目背景
本項目是在高速公路ETC聯網和推動取消省界收費站的大前提下，門架系統的落地，也就是要把門架部署在覆蓋全國范圍的高速公路上，收集車輛通行的牌示信息，以及相應的交易信息。
整體的情況是在邊緣側，即高速公路上會部署大量的門架和相應的控制器，相應的邊緣終端，這些終端大概10萬台，其上部署了相關的應用以收集相關信息。超過50萬個應用部署到邊緣節點，收集到信息后，通過收費專網向省中心以及路網中心上傳對應的數據。
本次項目的工作挑戰主要有兩個方面：
將近10萬台異構設備的管理，包括arm，x86等異構設備。
50余萬個應用的生命周期管理
為保證項目的成功落地，我們對整體架構做了選型，最終選擇了K8s和KubeEdge來進行整體的應用和邊緣節點管理。
二、為什么選擇Kubernetes
在項目里，雖然說是部署在邊緣側的應用，但它的復雜程度已經和雲上是類似的了，在邊緣側部署的應用已經是由很多個微服務組成的。所以Kubernetes對於支撐這種微服務化的、雲原生化的應用部署和大規模管理的能力，同樣也適用於這個項目在邊緣側的使用。
具體來說，有一些典型的部署需求：
- 雙機熱備
- 多機多活互備
- 有關聯的應用同節點部署以提升應用間交互效率
- 同一應用的不同實例跨節點部署以提升可用性
- 依據邊緣節點的不同屬性將應用部署於不同分組中
- 定義獨立於節點的應用部署以及實現滿足條件的新邊緣節點上線后自動安裝應用
這些需求，用K8s的這些Deployment、Pod、ReplicaSet、DaemonSet等核心對象來表示，是非常適合的。所以我們就選擇了Kubernetes。
當然，還有一些重要的邊緣側特有的需求是原生的Kubernetes不具備的，但Kubernetes的架構是非常好的，易於擴展，靈活性很高，可以基於原生Kubernetes架構基礎，根據邊緣管理的特殊需求進行擴展。
三、為什么選擇KubeEdge
一是業務自身的特點來決定的。這個業務的量非常大，涉及的邊緣節點分布在全國各地，所以它的邊緣側是多硬件架構、多廠家的，我們需要異構的支持； 邊緣工控機低至4核ARM SOC、1G可用內存，我們需要低資源占用的方案來管理邊緣側的節點；管理運維復雜，從路網中心到最終路段，分為6級管理層次，管理成本高，我們需要高集成度邊緣的方案，讓邊緣足夠簡單，把出問題的概率降到最低，降低運維成本。
二是從邊緣環境的特點來看的。從網絡的角度來看，網絡分為部省、省站兩層，多次轉發，我們需要邊緣接入具有高靈活性，可支持專線、代理、公網、有線和無線接入等多種方式；各地基礎設施的建設不同，有些省份的網絡帶寬低至3M，我們需要邊緣和雲之間的管理帶寬占用降到最低；有些高速公路上的網絡條件是非常差的，經常出現斷網的情況。我們需要邊緣方案有離線自治的能力。
四、整體方案
接下來我會把整體方案打開成幾層來分別介紹。
應用部署
首先是應用部署，就像我剛才說的，在邊緣側要部署的業務非常復雜，它是由多個微服務所構成的雲原生化的架構。所以我們這些微服務以及中間件都容器化之后可以非常好的適應各種不同的異構操作系統，方便統一管理。
如下圖所示，微服務架構分成前端和后端，前端主要把業務通過Deployment的方式部署到門架上，與后端之間是通過EdgeMesh實現的。通過這種服務發現的方式，實現微服務前后端業務的通信。而后端業務容器本身是無狀態的，可以通過Deployment來部署。
后面的Redis包括MySql就可以通過Statefulset的方式來進行部署。通過這樣的部署模型，我們可以很完美的進行封裝和自動化管理高可用的邊緣側的整套業務系統。
但如果僅僅是用原生的K8s部署方式，並不能完全滿足我們的需求，因為在項目里要部署的量非常大，左圖的環境只是應用於一個收費站，而一個路段要管理幾百上千個收費站，逐個部署成本過高。所以我們基於K8s之上又構建了一個任務工作流的引擎系統，把每一個部署微服務的步驟定義為一個job。用批量的方式大量、快速部署成百上千個同樣的微服務系統和環境。
大規模節點接入
除了上面提到的挑戰，在應對大規模節點接入的情況下也遇見過一些問題：
每個省有自己的管理權限，我們按K8s集群的配置配了多個K8s集群來進行管理，一個省對應一個K8s集群，然后在K8s之上通過統一的管理層處理復雜跨集群數據統計等操作，從中心側管理每個省的邊緣側，這就是多集群的管理手段。
我們曾遇見一種現象，路網中心或省中心做網絡升級等動作之后，網絡有時候會出現問題，所有省的邊緣節點，失去與K8s的連接，等網絡恢復之后，又會發生所有節點同時連接中心側的K8s集群，引起大量的並發連接,對中心側的系統造成沖擊，導致應用異常。為了應對這種情況，我們通過動態退避算法緩解節點同時接入所形成的流量沖擊。
需要精簡NodeStatus和PodStatus上報的信息。就前文所提到的，各地基礎設施的建設不同，有些省份的網絡帶寬低至3M，所以我們需要減小狀態信息的大小，降低上報流量的沖擊，降低對網絡的影響。
鏡像倉庫Mirror分級加速，有效降低了對網絡的沖擊，提高大批量部署的部署效率。
邊緣業務高可用
接下來的是邊緣業務高可用，按照原生K8s的升級狀態，它會先刪除舊版本Pod，再創建新Pod並在這個過程中去拉取新版本鏡像。這種操作在公有雲網絡條件較好的情況下，是沒太大問題的。但在邊緣側，這樣就會造成業務長時間的中斷，收費數據缺失。所以針對這一個流程，我們也是做了相應的升級和優化。
我們先把升級下載鏡像的通知下發做預下載，下載成功之后再刪除已有的舊Pod，啟動新應用，優化了應用升級對服務中斷的時間的影響，將業務升級時整體業務中斷的時間從分鍾級縮減到了10s內。
同時，考慮到邊緣設備有主備部署的情況，而邊緣側又不像雲上有ELB服務。我們又在邊緣節點中容器化部署了Keepalived，通過VIP，為門架的攝像頭等設備提供對應的K8s集群內的容器服務。
五、總結
當前基於KubeEdge的邊緣管理系統管理着全國29個省、市 、自治區的將近100,000個邊緣節點，超過500,000邊緣應用的部署。支撐了高速公路門架業務的不斷調整、更新，滿足了每日3億條以上的信息采集。
為日后車路協同、自動駕駛等創新業務的發展提供了良好的平台支撐。
K8s提供的通用部署和調度模型很適合部署大規模邊緣應用。
單純原生K8s不能滿足邊緣側業務的所有需求，KubeEdge集成K8s雲原生管理能力，同時對邊緣業務部署和管理提供了很好的支持。
本文分享自華為雲社區《如何使用Kubernetes管理中國高速公路上的10萬邊緣節點？》，原文作者：技術火炬手。