摘要：為保證高速公路上門架系統的落地專案的成功落地，選擇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萬邊緣節點？》，原文作者：技術火炬手。