摘要：2022年9月29日，KubeEdge釋出1.12版本。新版本新增多個增強功能，在擴充套件性、穩定性、安全性上均有大幅提升。
本文分享自華為雲社群《KubeEdge 1.12版本釋出，穩定性、安全性、可延伸性均帶來大幅提升》，作者：雲容器大未來。
北京時間2022年9月29日，KubeEdge釋出1.12版本。新版本新增多個增強功能，在擴充套件性、穩定性、安全性上均有大幅提升。
KubeEdge v1.12 新增特性：
▪ 全新的邊緣裝置管理介面DMI
▪ 全新的Edged實現
▪ EdgeMesh支援高可用（HA）模式
▪ 支援批次遠端升級邊緣節點
▪ 邊緣原生介面支援認證鑑權
▪ CloudHub可靠性增強
▪ 新增攝像頭介面標準GigE的 Mapper實現
1.12版本中，對全新的雲原生邊緣裝置管理標準Device Management Interface（DMI），提供了Alpha版本支援。DMI讓裝置管理者可以用雲原生的方式對邊緣裝置進行管理，它的設計覆蓋了裝置生命週期管理、裝置資料管理，且解耦了管理面與資料面資料，使KubeEdge的邊緣裝置管理更穩定、易插拔、更具擴充套件性。目前本版本支援了邊緣裝置生命週期管理能力，邊緣裝置資料管理能力正在實現中。
北向依舊通過CRD使用Kubernetes擴充套件API來管理邊緣裝置生命週期；南向提供了統一的邊緣裝置生命週期管理相關的gRPC介面，包括裝置註冊、裝置更新、裝置刪除、裝置狀態更新等。邊緣裝置開發者可以以更統一、更靈活、更標準化的方式來開發Device Mapper。
解耦了裝置管理面與資料面，資料面資訊可以通過設定靈活地選擇在邊端被處理或通過資料面通道在雲端處理，管理面的雲邊通道僅傳輸少量的管控資訊，大幅降低了雲邊通道擁塞的風險，提高了KubeEdge系統的穩定性。
DMI支援使用者通過多種形式對邊緣裝置資料進行存取，包括：
1、Device as a Service（DaaS），通過Service的方式存取、拉取邊緣裝置資料；
2、通過設定規則的方式，將採集到的裝置資料推播到指定接收者
資料消費者包括：雲端裝置資料消費者應用、邊緣端裝置資料消費者應用、第三方資料消費者應用、資料流轉平臺broker、雲端或邊緣端資料持久化資料庫等。
通過DMI介面，開發者只需按照DMI介面標準實現對應協定的Mapper，並在雲上執行相應的API操作，就能夠將裝置接入到KubeEdge中來，享受KubeEdge邊緣計算平臺帶來的雲原生裝置管理體驗。
更多資訊可參考： https://github.com/kubeedge/kubeedge/pull/4013
Edged模組是邊緣側的輕量化容器應用引擎，用於實現邊緣Pod應用的生命週期管理，以及Node狀態收集與上報等能力。新版的Edged為了保證邊緣的輕量化，在原生Kubelet中做了優化與裁剪，並保留了裁剪歷史記錄(Commit History)，最終直接呼叫Kubelet入口的Run函數啟動以整合在EdgeCore中。
新版的Edged，由於保留了對Kubelet的裁剪歷史記錄(Commit History)，使用者和開發者可以根據歷史記錄瞭解裁剪點。直接呼叫Kubelet入口的Run函數啟動，減少了對Kubelet的侵入修改，將大大簡化後續K8s版本依賴升級，也可將上游K8s漏洞修復及時全量同步到KubeEdge版本。
新版Edged的設定引數也與Kubelet保持一致。為了保持KubeEdge可靠的雲邊訊息傳輸和邊緣自治能力，在新版Edged中，我們仍然通過通過雲邊可靠通道傳輸應用、節點相關元訊息，並將後設資料存入邊緣資料庫。
對Kubelet的優化與裁剪，在KubeEdge組織下的Kubernetes倉庫維護了裁剪後的版本，開發者可以通過commit提交記錄檢視裁剪記錄，後續也可以根據需求自主調整裁剪內容。v1.12版本主要裁剪了Kubelet中在邊緣不會使用到的特性、第三方內建儲存、Cloud Provider等，更多裁剪詳情可以參考：https://github.com/kubeedge/kubernetes/commits/v1.22.6-kubeedge1。
EdgeMesh作為KubeEdge叢集的資料面元件，為應用程式提供了服務發現與流量代理功能，穩定與高效的流量轉發是使用者對EdgeMesh的核心訴求。1.12版本的EdgeMesh新增了HA模式的部署方式，以支援EdgeMesh中繼節點的高可用性。
HA部署模式下的EdgeMesh可以避免中繼節點的單點故障問題，同時將中繼轉發與協助網路穿透的能力從edgemesh-server移入到edgemesh-agent中，使得具備中繼能力的edgemesh-agent能夠自動承擔起中繼節點的角色。因此使用者可以在合適的位置設定具備中繼能力的edgemesh-agent以分擔雲端中繼節點的負載，同時也能解決過遠的中繼節點帶來的長時延問題。在多中繼節點下，EdgeMesh系統執行時能夠自動選擇一個最優的中繼節點執行轉發流量或協助網路穿透的功能。
使用者在升級到v1.12.0版本的EdgeMesh時，預設無需再部署edgemesh-server，升級時需要設定中繼節點表relayNodes中的nodeName和advertiseAddress引數以指定中繼節點和其公網IP地址，通過Helm安裝命令範例如下：
helm install edgemesh --namespace kubeedge \ --set agent.psk=<your psk string> \ --set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \ --set agent.relayNodes[1].nodeName=ke-edge1,agent.relayNodes[1].advertiseAddress="{2.2.2.2,3.3.3.3}" \ https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz
中繼節點表relayNodes支援指定多箇中繼節點，每個中繼節點支援設定多個公網IP地址。如果後續有新的中繼節點加入，可以通過執行kubectl -n kubeedge edit configmap edgemesh-agent-cfg編輯中繼節點表relayNodes新增新的中繼節點，EdgeMesh能夠自動熱載入此設定。
更多資訊可參考proposal： https://github.com/kubeedge/edgemesh/pull/372
KubeEdge叢集常常管理數以萬計分散的遠端邊緣節點，如何對這些節點實現方便快捷的升級更新是一個不小的挑戰。1.12版本中新增了NodeUpgradeJob API及其Controller來實現雲上批次遠端升級邊緣節點。
使用者可以通過在雲上建立NodeUpgradeJob來建立升級任務，使用者可以指定升級的節點範圍以及升級版本號等內容。例如以下設定表示升級edge-node1及edge-node2兩個邊緣節點到版本v1.12.0，升級結果將會顯示在status欄位中，使用者可以通過執行kubectl get nodeupgradejob upgrade-example -oyaml命令來檢視升級結果。
apiVersion: operations.kubeedge.io/v1alpha1 kind: NodeUpgradeJob metadata: name: upgrade-example labels: description: upgrade-label spec: version: "v1.12.1" timeoutSeconds: 60 nodeNames: - edge-node1 - edge-node2
該特性處於alpha版本，使用者需要手動啟用該功能。如下所示在cloudcore.yaml組態檔中將nodeUpgradeJobController模組置為true以啟用該功能。
nodeUpgradeJobController: enable: true buffer: nodeUpgradeJobEvent: 1 updateNodeUpgradeJobStatus: 1024 load: nodeUpgradeJobWorkers: 1
更多資訊可參考proposal： https://github.com/kubeedge/kubeedge/pull/3822
在邊緣側，EdgeCore元件通過MetaServer模組對外提供邊緣原生介面能力。為了鞏固和加強邊緣側的安全，在使用者使用邊緣原生介面存取原生K8s API時，需要對使用者請求進行認證和鑑權。
新版本MetaServer可通過HTTPS方式啟動並提供服務，使用者的請求需要經過Token方式鑑權，未經過認證或鑑權的請求將無法存取。出於安全性考慮，Token鑑權方式在當前版本中要求邊緣節點保持線上狀態，離線場景下的鑑權請求將預設被拒絕。
新增的認證鑑權特性當前處於Alpha階段，通過特性開關（featuregate）requireAuthorization來控制，預設是關閉狀態，即使用者預設仍然可通過監聽在localhost的HTTP介面進行無鑑權存取。使用者可以在CloudCore、EdgeCore的組態檔中設定開啟該特性。
apiVersion: edgecore.config.kubeedge.io/v1alpha1 kind: EdgeCore featureGates: requireAuthorization: true ---------------- apiVersion: cloudcore.config.kubeedge.io/v1alpha1 kind: CloudCore featureGates: requireAuthorization: true
細節可參考 https://github.com/kubeedge/kubeedge/issues/4108
在大量KubeEdge使用場景中，邊緣裝置物理位置高度分散，並處於不穩定的物理環境中，因此雲邊通訊網路質量較差，面臨著高時延、網路中斷、閃斷閃連等問題。在KubeEdge中，CloudHub是雲邊之間通訊的橋樑，負責邊緣裝置的連線管理和分發上下行的雲邊訊息。在1.12版本中，我們重構了CloudHub模組，增強了在上述極端場景下CloudHub的穩定性和魯棒性。
更多資訊可參考： https://github.com/kubeedge/kubeedge/pull/4087
KubeEdge支援多種協定的邊緣裝置接入。GigE Vision是一種攝像頭介面標準，在工業機器視覺產品中有廣泛的應用。在這個版本中，我們提供了基於GigE協定開發的Mapper，GigE Mapper可以支援GigE視覺協定攝像機、工業相機裝置接入KubeEdge。它使用第三方開源攝像機SDK庫rc_genam_api，通過GeniCam協定存取不同廠商的攝像機。
每個GigE Mapper可以支援多個攝像頭同時連線，通過裝置SN來區分不同的攝像頭裝置，還可以通過KubeEdge北向介面，以CRD的形式來對攝像頭引數進行設定。通過GigE Mapper管理攝像頭，還支援攝像頭捕獲功能，支援匯出PNG和PNM影象格式。目前測試了兩種型號的攝像機，Basler acA640和HIKROBOT MV-CA050-12GC。
GigE Mapper是基於KubeEdge社群提供的Mapper開發框架Mapper-SDK-GO來開發實現的。使用Mapper-SDK-GO框架可以一鍵生成Mapper程式的主體內容，開發者只需要完成幾個關鍵介面的對應協定的實現，即可開發出對應協定接入的Mapper，非常方便。
感謝KubeEdge社群技術指導委員會(TSC)、各SIG成員對v1.12版本開發的支援與貢獻，未來KubeEdge將持續在新場景探索與支援、穩定性、安全性、可延伸性等方面持續發展與演進！
Release Notes：https://github.com/kubeedge/kubeedge/blob/master/CHANGELOG/CHANGELOG-1.12.md
GigE Mapper： https://github.com/kubeedge/mappers-go/tree/main/mappers/gige
Mapper-SDK-GO：https://github.com/kubeedge/mappers-go/tree/main/mapper-sdk-go
KubeEdge是業界首個雲原生邊緣計算框架、雲原生計算基金會內部唯一孵化級邊緣計算開源專案,社群已完成業界最大規模雲原生邊雲協同高速公路專案（統一管理10萬邊緣節點/50萬邊緣應用）、業界首個雲原生星地協同衛星、業界首個雲原生車雲協同汽車、業界首個雲原生油田專案，開源業界首個分散式協同AI框架Sedna及業界首個邊雲協同終身學習正規化，並在持續開拓創新中。
KubeEdge網站 : https://kubeedge.io
GitHub地址 : https://github.com/kubeedge/kubeedge
Slack地址 : https://kubeedge.slack.com
郵寄清單 : https://groups.google.com/forum/#!forum/kubeedge
每週社群例會 : https://zoom.us/j/4167237304
Twitter : https://twitter.com/KubeEdge
檔案地址 : https://docs.kubeedge.io/en/latest/