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