量化指標(biāo)是與非：挽救被量化指標(biāo)扼殺的技術(shù)團(tuán)隊
作者 | 劉新翠整理 | 徐杰承本文整理自快狗打車技術(shù)總監(jiān)劉新翠在WOT2023大會上的主題分享，更多精彩內(nèi)容及現(xiàn)場PPT，請關(guān)注51CTO技術(shù)棧公眾號，發(fā)消息【W(wǎng)OT2023PPT】即可直接領(lǐng)取
本文來源于《華為云 DTSE?》第五期開源專刊，更多文章請查看：https://bbs.huaweicloud.com/blogs/435823
作者：徐飛華為云高級軟件工程師，KubeEdge 社區(qū) TSC
摘要：由于邊緣計算場景需求的日益增長，傳統(tǒng)架構(gòu)面臨諸多問題，KubeEdge 將云原生應(yīng)用擴(kuò)展到邊緣計算，利用 Kubernetes 的能力來高效的管理和調(diào)度邊緣設(shè)備上的工作負(fù)載。通過提供邊緣設(shè)備的本地計算、存儲和網(wǎng)絡(luò)能力，減少云與邊緣之間的數(shù)據(jù)傳輸延遲，提升應(yīng)用的效率和響應(yīng)速度。未來，KubeEdge 將持續(xù)創(chuàng)新，進(jìn)一步加強(qiáng)可擴(kuò)展性、安全性和多樣化的場景支持，推動云原生邊緣計算領(lǐng)域的發(fā)展。
1.背景與挑戰(zhàn)
傳統(tǒng)邊緣計算行業(yè)多層級獨(dú)立控制、設(shè)備缺乏開放性，系統(tǒng)集成復(fù)雜等問題，導(dǎo)致邊緣應(yīng)用開發(fā)成本高，上線速度慢，缺乏智能。華為從 2016 年開始研究如何將易擴(kuò)展、易遷移的云原生技術(shù)架構(gòu)運(yùn)用到邊緣計算領(lǐng)域。
華為云于 2018 年 11 月開源業(yè)界首個云原生邊緣計算項目 KubeEdge，并在 2019 年 3 月捐獻(xiàn)到云原生計算基金會（CNCF）。KubeEdge 將 Kubernetes 原生的容器編排和調(diào)度能力拓展到邊緣，完整的打通了邊緣計算中云、邊、設(shè)備協(xié)同的場景，為用戶提供一體化的云邊端協(xié)同解決方案。
自開源以來，社區(qū)一直秉承開源開放的治理模式，在開放協(xié)作的理念下蓬勃發(fā)展，目前已被廣泛應(yīng)用于智能交通、智慧園區(qū)、工業(yè)制造、金融、航天、物流、能源、智能 CDN 等行業(yè)，本文結(jié)合天翼云大規(guī)模 CDN 場景，介紹 KubeEdge 社區(qū)行業(yè)落地實踐。
創(chuàng)新使能，開放共治的云原?邊緣計算社區(qū)
2.KubeEdge 的布局和核心技術(shù)
KubeEdge 基于 Kubernetes 原生的容器編排和調(diào)度能力之上，擴(kuò)展實現(xiàn)了邊云協(xié)同、計算下沉、海量邊緣設(shè)備管理、邊緣自治等能力，完整的打通了邊緣計算中云、邊、設(shè)備協(xié)同的場景。將云原生技術(shù)延伸到了邊緣計算領(lǐng)域，實現(xiàn)了云原生生態(tài)與邊緣計算生態(tài)的互通。
KubeEdge 基于 Kubernetes 之上，在 100% 兼容 Kubernetes API 的基礎(chǔ)上，結(jié)合邊緣計算中網(wǎng)絡(luò)不穩(wěn)定、資源受限、海量邊緣設(shè)備等場景，實現(xiàn)的技術(shù)點(diǎn)包括：
1、基于 Kubernetes 構(gòu)建平臺，提供云-邊-端一致的業(yè)界標(biāo)準(zhǔn)云原生應(yīng)用管理框架，解決云邊協(xié)同架構(gòu)中云平臺廠商綁定問題；
2、大幅優(yōu)化邊緣節(jié)點(diǎn)組件資源占用，支持管理小規(guī)格邊緣網(wǎng)關(guān)節(jié)點(diǎn)；
3、在云邊之間引入雙線多路復(fù)用通道，重新實現(xiàn) K8s 控制面與節(jié)點(diǎn)通信機(jī)制，引入可靠校驗機(jī)制，解決邊緣節(jié)點(diǎn)與云上組件連接帶寬受限、網(wǎng)絡(luò)質(zhì)量不可靠等問題；
4、邊緣節(jié)點(diǎn)支持?jǐn)?shù)據(jù)本地持久化，支持邊緣節(jié)點(diǎn)離線自治；
5、北向基于 Kubernetes CRD 引入設(shè)備管理 API，支持以 Kubernetes 的 API 標(biāo)準(zhǔn)管理邊緣設(shè)備；
6、南向提供物聯(lián)網(wǎng)設(shè)備接入框架，內(nèi)置多種主流物聯(lián)網(wǎng)通信協(xié)議實現(xiàn)，并支持用戶自定義擴(kuò)展，解決異構(gòu)設(shè)備接入復(fù)雜性問題。
3.多領(lǐng)域、多行業(yè)生產(chǎn)落地
KubeEdge 目前已被應(yīng)用于廣泛應(yīng)用智能交通、智慧園區(qū)、工業(yè)制造、金融、航天、物流、能源、智能 CDN 等行業(yè)，完成業(yè)界最大規(guī)模云原生邊云協(xié)同高速公路項目（統(tǒng)一管理 10 萬邊緣節(jié)點(diǎn) / 50 萬邊緣應(yīng)用）、業(yè)界首個云原生星地協(xié)同衛(wèi)星、業(yè)界首個云原生車云協(xié)同汽車、業(yè)界首個云原生油田等行業(yè)代表項目。
3.1 天翼云基于 KubeEdge 的大規(guī)模 CDN 場景落地實踐
3.1.1 天翼云 CDN 業(yè)務(wù)背景
中國電信以“2+4+31+X”的資源布局加速云網(wǎng)融合。“X”是接入層面，把內(nèi)容和存儲放到離用戶最近的地方，實現(xiàn)網(wǎng)隨云動、入云便捷、云間暢達(dá)，滿足用戶按需選擇和低時延需求。目前天翼云基本的 CDN 功能已一應(yīng)俱全，且資源儲備豐富，支持精準(zhǔn)調(diào)度，秉承質(zhì)量優(yōu)先，整體業(yè)務(wù)發(fā)展正步入快車道。
3.1.2 邊緣服務(wù)容器化背景
與其他云廠商和傳統(tǒng)的 CDN 廠商不同，天翼云 CDN 起步較晚，但也恰逢云原生理念大行其道。因此，我們選擇了通過容器與 Kubernetes 編排技術(shù)構(gòu)建 CDN PaaS 平臺，但是 CDN 邊緣服務(wù)尚未完成云原生改造。
存在的問題：1）如何納管大規(guī)模分布在邊緣的 CDN 節(jié)點(diǎn)？2）如何對 CDN 邊緣服務(wù)進(jìn)行可靠的部署和升級？3）如何構(gòu)建統(tǒng)一、可擴(kuò)展資源調(diào)度平臺？
3.1.3 基于 KubeEdge 的邊緣節(jié)點(diǎn)管理
CDN 物理節(jié)點(diǎn)架構(gòu)
CDN 提供的緩存加速服務(wù)，解決最后一公里加速問題。為了滿足就近接入和快速響應(yīng)，大部分 CDN 節(jié)點(diǎn)需要部署到近用戶側(cè)，通過 CDN 全局流量調(diào)度系統(tǒng)將用戶訪問接入到就近節(jié)點(diǎn)。通常 CDN 節(jié)點(diǎn)具有呈離散分布的特點(diǎn)，大部分以各地區(qū)域 IDC 和地市級別 IDC 機(jī)房資源為主，每個邊緣機(jī)房根據(jù)出口帶寬和服務(wù)器資源規(guī)劃，搭建多個 CDN 服務(wù)集群。
邊緣服務(wù)容器化技術(shù)選型
在考慮做容器化的過程中，我們前期進(jìn)行了技術(shù)選型和研究，主要是三個方向：標(biāo)準(zhǔn) K8s：邊緣節(jié)點(diǎn)以標(biāo)準(zhǔn) worker 節(jié)點(diǎn)加入到 master，但這種方式也會存在問題，如果連接過多容易造成 Relist，K8s master 端負(fù)載壓力大；網(wǎng)絡(luò)波動，造成 pod 被驅(qū)逐，導(dǎo)致不必要重建；分節(jié)點(diǎn)接入 CDN 邊緣節(jié)點(diǎn)：分集群部署 K8s 或 K3s。這種方式的控制面與集群過多，無法構(gòu)建統(tǒng)一的調(diào)度平臺，而且每個 KPI 集群若按高可用方式部署也至少需要 3 臺，會過度占用機(jī)器資源；云邊接入：通過 KubEedge 方式接入，按照這種方式，可以收斂邊緣節(jié)點(diǎn)連接，接入統(tǒng)一的 K8s 集群，并且提供云邊協(xié)同，邊緣自治等能力，還保留了大部分 K8s 的原生能力。
3.1.4 基于 KubeEdge 邊緣節(jié)點(diǎn)納管方案
上圖是我們目前架構(gòu)的示意圖，我們在各區(qū)域中心及數(shù)據(jù)中心建若干個 K8s 集群，K8s 集群下面是邊緣按就近規(guī)劃的接入到區(qū)域的集群。為了避免單點(diǎn)接入，以及單 K8s 集群 CloudCore 負(fù)載過大的問題，在各大區(qū)建設(shè) K8s 集群，用于邊緣節(jié)點(diǎn)的接入和應(yīng)用編排管理。但在社區(qū)早期 1.3 版本中，當(dāng)時提供的高可用方案只是單組多重這種高可用方式，而實際是無法滿足我們大規(guī)模納管的性能要求，因此我們后面在社區(qū)推出多組部署方式。這種部署方式在早期使用的過程中并沒有問題，但當(dāng)接入的邊緣節(jié)點(diǎn)，還有部署的容器數(shù)量過多時，這個問題就逐漸暴露出來：
CloudCore 多副本部署連接不均衡問題
上圖為 hub 到 upstream 最終提交到 apiserver 的示意圖。中間 upstream 模塊有一部分的分發(fā)，它是用單線程的方式來運(yùn)行，中間 upstream 模塊，因為只有單線程，會導(dǎo)致消息提交過慢，邊緣節(jié)點(diǎn)的一些 node 無法及時提交給 apiserver，最終引起我們部署方面的一些異常。后面我們把 CloudCore 按多副本去部署，又出現(xiàn)了在 CloudCore 進(jìn)行升級或者一些意外重啟過程中，會發(fā)現(xiàn)連接不均衡的問題。為了解決這個問題，我們在多副本之前，部署了 4 層的 lb，并在 lb 上配置了諸如 listconnection 的負(fù)載均衡策略，但實際上像 ls 這種負(fù)載 4 層的負(fù)載平衡，它都有一些篩選的緩存機(jī)制，并不能保證連接的均衡的分配。基于以上背景我們進(jìn)行了優(yōu)化：
CloudCore 多副本均衡優(yōu)化方案
①CloudCore 每個實例在啟動后各自通過 Configmap 的方式上報實時的連接數(shù)等信息；②CloudCore 結(jié)合本地實例與其他實例的連接數(shù)，計算每個機(jī)器的期望連接數(shù)③計算本地連接數(shù)與期望連接數(shù)的相差比例，相差比例大于最大可容忍連接數(shù)差，進(jìn)入連接待釋放階段，并進(jìn)入一個 30s 觀察周期；④觀察過后，進(jìn)入下一個檢測周期，直到連接均衡。
3.1.5 邊緣應(yīng)用服務(wù)部署
CDN 加速服務(wù)整體流程
CDN 它主要分為兩大核心系統(tǒng)：調(diào)度系統(tǒng)和緩存系統(tǒng)。調(diào)度系統(tǒng)會實時采集全網(wǎng)的 CDN 鏈路情況，實時的節(jié)點(diǎn)的情況，以及節(jié)點(diǎn)的帶寬成本的情況，從而決策出最優(yōu)調(diào)度的覆蓋數(shù)據(jù)，將這個數(shù)據(jù)推給 Local Dns 或 302 或 hds 的一個的調(diào)度器。Local Dns 拿到最優(yōu)數(shù)據(jù)后，來進(jìn)行 Dns 的解析響應(yīng)，用戶端通過解析響應(yīng)可就近接入到邊緣集群，邊緣集群因為涉及到緩存，有可能涉及到 miss，如果 miss 后，它會回到上一層的緩存，一般會有兩層或者三層的中轉(zhuǎn)的緩存，最終回到原狀。
如果中轉(zhuǎn)的緩存也沒有，數(shù)據(jù)會再回到云站，這是 CDN 服務(wù)的整體流程。在緩存系統(tǒng)，一般不同產(chǎn)品的緩存會使用不同的服務(wù)，比如面向直播的流媒體的加速服務(wù)和一些靜態(tài)的加速會有一些區(qū)別。這也給開發(fā)和維護(hù)造成了一些成本，后面它們的融合可能也是一個趨勢。CDN 緩存服務(wù)的特點(diǎn)：
1、資源獨(dú)占：緩存服務(wù)是要最大利用存儲，機(jī)器上的存儲和帶寬的資源的一個服務(wù)，所以說它需要獨(dú)占
2、大規(guī)模高服用：規(guī)模很大，覆蓋廣，同個軟件或同一臺機(jī)器的緩存服務(wù)，可能要承接上萬個域名，甚至 10 萬域名
3、容災(zāi)分區(qū)故障：容忍組內(nèi)小部分節(jié)點(diǎn)的緩存丟失，或者是全局有少量的節(jié)點(diǎn)緩存失效，緩存過多會造成擊穿，反之擊穿就回到上層的緩存，造成訪問延遲變大，最終引起服務(wù)異常。
4、高可用：4/7 層 LB 具備實時探測和切流、引流能力；L4 LB 保證組內(nèi)主機(jī)間的流量均衡；L7 LB 通過一致性哈希盡量保證讓每個 url 在組內(nèi)只存一份副本
從以上的特征，我們看到 CDN 在部署中，要解決以下問題：1）如何讓節(jié)點(diǎn)容器有序和可控的升級？2）如何進(jìn)行版本的 A / B 測試？3）如何對升級過程進(jìn)行校驗？
我們的升級部署方案包括
分批升級與組內(nèi)升級并發(fā)控制：創(chuàng)建分批升級任務(wù)；
控制器按指定機(jī)器進(jìn)行升級、細(xì)粒度版本設(shè)置：創(chuàng)建主機(jī)粒度版本映射；
控制器增加 pod 版本選擇邏輯，優(yōu)雅升級：通過 lifecycle 的 prestop / postStart 實現(xiàn)常規(guī)切流與恢復(fù)，特殊場景聯(lián)動 GSLB 進(jìn)行切流；
升級校驗：Controller 與監(jiān)控系統(tǒng)聯(lián)動，升級過程發(fā)現(xiàn)服務(wù)異常，及時終止與回滾；
編排安全防護(hù)：Workload 粒度與 pod 粒度通過 Adminsion Webhook 增加校驗是否符合期望修改與刪除；
3.1.6 基于 KubeEdge CDN 邊緣容器容災(zāi)與遷移
遷移步驟：
1.備份 etcd，在新集群中 restore；
2.切換接入 DNS；
3.重啟 CloudCore 斷開云邊 hub 連接；
優(yōu)點(diǎn)：1、成本低，由于 KubeEdge 的邊緣自治特性，邊緣容器無重建，服務(wù)無中斷；2.流程簡單，可控，服務(wù)安全性高；
3.1.7 CDN 大規(guī)模文件分發(fā)
需求場景：?CDN 邊緣服務(wù)配置?GSLB 調(diào)度決策數(shù)據(jù)?容器鏡像預(yù)熱任務(wù)
3.1.8 未來架構(gòu)演進(jìn)方向思考
邊緣計算挑戰(zhàn)
資源管理：分布廣泛，種類多，架構(gòu)、規(guī)格不統(tǒng)一
網(wǎng)絡(luò)時延、可靠：異構(gòu)網(wǎng)絡(luò)，移動網(wǎng)絡(luò)等弱網(wǎng)環(huán)境，帶寬受限，穩(wěn)定性不足
安全：邊緣服務(wù)更難形成統(tǒng)一的安全防護(hù)體系
業(yè)務(wù)多樣：場景、業(yè)務(wù)種類多樣
基于 CDN 的邊緣計算平臺基礎(chǔ)能力
資源：CDN 節(jié)點(diǎn)覆蓋廣、潮汐特性特性資源冗余；通過 Kubeedge 提供了云邊協(xié)同；可延伸端側(cè)，具有異構(gòu)資源部署與管理能力；
調(diào)度與網(wǎng)絡(luò)：專用 EDNS 支持地市級精準(zhǔn)調(diào)度，實現(xiàn)真正就近接入；CDN 服務(wù)與邊緣計算服務(wù)統(tǒng)一調(diào)度；云邊專用網(wǎng)絡(luò)，管理通道、數(shù)據(jù)回傳、動態(tài)加速網(wǎng)絡(luò)更可靠；大規(guī)模 V6 支持；
安全能力：CDN Waf 抗 D、流量清洗、近源攔截等; 證書加速與安全，SSL 硬件卸載、keyless 無私鑰方案，提供邊緣安全接入；
網(wǎng)關(guān)：邊緣調(diào)度與豐富的負(fù)載均衡能力；通用協(xié)議處理能力，常規(guī)流媒體協(xié)議，滿足大多互聯(lián)網(wǎng)加速場景。
業(yè)務(wù)探索
未來將在離線計算類、視頻編轉(zhuǎn)碼、視頻渲染、批量作業(yè)、撥測、壓測類持續(xù)探索實踐。
4.總結(jié)
作為業(yè)界首個云原生邊緣計算社區(qū)，KubeEdge 社區(qū)目前已完成包括業(yè)界最大規(guī)模云原生邊云協(xié)同高速公路項目（統(tǒng)一管理 10 萬邊緣節(jié)點(diǎn) / 50 萬邊緣應(yīng)用）、業(yè)界首個云原生星地協(xié)同衛(wèi)星、業(yè)界首個云原生車云協(xié)同汽車、業(yè)界首個云原生油田項目等在內(nèi)的諸多行業(yè)代表項目。截至目前，KubeEdge 在全球已有超 1600 名開發(fā)者參與代碼貢獻(xiàn)，覆蓋中國、美國、德國、韓國、日本、土耳其、意大利、波蘭、墨西哥、俄羅斯、英國、西班牙、印度、尼加拉瓜等國家，100 余家企業(yè)與科研機(jī)構(gòu)參與項目合作。
在未來，KubeEdge 社區(qū)將在固定邊緣、移動邊緣、邊緣 AI 等領(lǐng)域不斷探索，KubeEdge 社區(qū)期待與你協(xié)作創(chuàng)新，共同促進(jìn)云原生邊緣計算發(fā)展！
附：KubeEdge 社區(qū)貢獻(xiàn)和技術(shù)交流地址
網(wǎng)站:https://kubeedge.io
GitHhub 地址:https://github.com/kubeedge/kubeedge
本文鏈接：http://www.tebozhan.com/showinfo-26-125108-0.htmlKubeEdge：云原生邊緣計算賦能多行業(yè)、多場景的智能化升級
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 物聯(lián)網(wǎng)平臺如何支持億級設(shè)備、海量租戶推送？從消息中間件架構(gòu)發(fā)展趨勢看華為云 IoT 的思考
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號