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