摘要：為保證高速公路上門架系統的落地項目的成功落地，選擇K8s和KubeEdge來進行整體的應用和邊緣節點管理。
本項目是在高速公路ETC聯網和推動取消省界收費站的大前提下，門架系統的落地，也就是要把門架部署在覆寫全國範圍的高速公路上，收集車輛通行的牌示資訊，以及相應的交易資訊。
整體的情況是在邊緣側，即高速公路上會部署大量的門架和相應的控制器，相應的邊緣終端，這些終端大概10萬台，其上部署了相關的應用以收集相關資訊。超過50萬個應用部署到邊緣節點，收集到資訊後，通過收費專網向省中心以及路網中心上傳對應的資料。
本次項目的工作挑戰主要有兩個方面：
将近10萬台異構裝置的管理，包括arm，x86等異構裝置。
50餘萬個應用的生命周期管理
為保證項目的成功落地，我們對整體架構做了選型，最終選擇了K8s和KubeEdge來進行整體的應用和邊緣節點管理。
在項目裡，雖然說是部署在邊緣側的應用，但它的複雜程度已經和雲上是類似的了，在邊緣側部署的應用已經是由很多個微服務組成的。是以Kubernetes對于支撐這種微服務化的、雲原生化的應用部署和大規模管理的能力，同樣也适用于這個項目在邊緣側的使用。
具體來說，有一些典型的部署需求：
雙機熱備
多機多活互備
有關聯的應用同節點部署以提升應用間互動效率
同一應用的不同執行個體跨節點部署以提升可用性
依據邊緣節點的不同屬性将應用部署于不同分組中
定義獨立于節點的應用部署以及實作滿足條件的新邊緣節點上線後自動安裝應用
這些需求，用K8s的這些Deployment、Pod、ReplicaSet、DaemonSet等核心對象來表示，是非常适合的。是以我們就選擇了Kubernetes。
當然，還有一些重要的邊緣側特有的需求是原生的Kubernetes不具備的，但Kubernetes的架構是非常好的，易于擴充，靈活性很高，可以基于原生Kubernetes架構基礎，根據邊緣管理的特殊需求進行擴充。
一是業務自身的特點來決定的。這個業務的量非常大，涉及的邊緣節點分布在全國各地，是以它的邊緣側是多硬體架構、多廠家的，我們需要異構的支援； 邊緣工控機低至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萬邊緣節點？》，原文作者：技術火炬手。
點選關注，第一時間了解華為雲新鮮技術~