云邊一體 | 基于Kubernetes打造邊緣云計算
云原生的理念如今正如火如荼。它不僅僅是一種技術(shù)，更是隨著云生態(tài)的發(fā)展而被逐漸提煉出的一系列技術(shù)、最佳實踐與方法論的集合；它帶來了資源利用率提升、分布式系統(tǒng)的彈性擴展與可靠性等能力，能夠讓IT系統(tǒng)最大程度的享受云計算紅利，業(yè)界全面擁抱云原生就是最好的佐證。伴隨5G、IoT的發(fā)展，邊緣計算正在成為云計算的新邊界，而規(guī)模和復(fù)雜度的日益提升對邊緣計算的效率，可靠性，資源利用率等一系列能力又有了新的訴求。試想，如果能將云能力從中心往邊緣觸達(dá)，上述問題是不是將迎刃而解？那么在云原生時代構(gòu)建云到邊的觸達(dá)通路，保持云邊一致性體驗，我們的抓手又在哪里呢？本次分享將一一為你揭曉；
引言
云原生的理念如今正如火如荼。它不僅僅是一種技術(shù)，更是隨著云生態(tài)的發(fā)展而被逐漸提煉出的一系列技術(shù)、最佳實踐與方法論的集合；它帶來了資源利用率提升、分布式系統(tǒng)的彈性擴展與可靠性等能力，能夠讓IT系統(tǒng)最大程度的享受云計算紅利，業(yè)界全面擁抱云原生就是最好的佐證。
伴隨5G、IoT的發(fā)展，邊緣計算正在成為云計算的新邊界，而規(guī)模和復(fù)雜度的日益提升對邊緣計算的效率，可靠性，資源利用率等一系列能力又有了新的訴求。試想，如果能將云能力從中心往邊緣觸達(dá)，上述問題是不是將迎刃而解？那么在云原生時代構(gòu)建云到邊的觸達(dá)通路，保持云邊一致性體驗，我們的抓手又在哪里呢？本次分享將一一為你揭曉。
云原生概念
云原生的概念最早是在2013年被提出，經(jīng)過這幾年的發(fā)展，尤其是從 2015 年 Google 牽頭成立 CNCF 以來，云原生技術(shù)開始進(jìn)入公眾的視線并逐漸演變成包括 DevOps、持續(xù)交付、微服務(wù)、容器、基礎(chǔ)設(shè)施，Serverless，F(xiàn)aaS等一系列的技術(shù)，實踐和方法論集合。伴隨著技術(shù)的普及，與之相配套的團(tuán)隊建設(shè)，技術(shù)文化，組織架構(gòu)和管理方法也呼之欲出。越來越多的企業(yè)選擇云原生構(gòu)建其應(yīng)用來獲得更好的資源效率和持續(xù)的服務(wù)能力。相比較過往著力云原生概念的普及、理解和力求共識，云原生落地已經(jīng)成為現(xiàn)如今I/CT日常主旋律。
云原生的技術(shù)范疇包括了以下幾個方面：云應(yīng)用定義與開發(fā)、云應(yīng)用的編排與管理、監(jiān)控與可觀測性、云原生的底層技術(shù)（比如容器運行時、云原生存儲技術(shù)、云原生網(wǎng)絡(luò)技術(shù)等）、云原生工具集、Serverless。雖然，CNCF以目前200多個項目和產(chǎn)品（CNCF云原生全景https://github.com/cncf/landscape） 的巨大體量保持高速發(fā)展，不斷壯大云原生體系的技術(shù)集合，但所有項目基本都在上述技術(shù)范疇中，緊守云原生理念不放；
那么云原生的核心優(yōu)勢到底有哪些，能帶給我們真實體感又是什么？
引用CNCF的重新定義："Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."
云原生和邊緣基礎(chǔ)設(shè)施
在云計算真正普及之前，獲取基礎(chǔ)設(shè)施能力（比如服務(wù)發(fā)現(xiàn)、流量控制、監(jiān)控與可觀測性、訪問控制、網(wǎng)絡(luò)控制、存儲層抽象等）需要應(yīng)用通過某種抽象或接口方式，使得兩者之間是非常緊密的耦合關(guān)系，應(yīng)用本身的能力和演進(jìn)需要強依賴基礎(chǔ)設(shè)施。而在云原生時代，類似kubernetes這樣的標(biāo)準(zhǔn)化資源抽象、編排、整合平臺促進(jìn)基礎(chǔ)設(shè)施能力正在不斷下沉，云能力和應(yīng)用之間的隔閡也正在云原生技術(shù)體系下被不斷瓦解。“面向云架構(gòu)”、“面向云編程”的呼聲日漸高漲的同時，cloudnative的云基礎(chǔ)設(shè)施越來越“友好”。但是，云原生基礎(chǔ)設(shè)施概念遠(yuǎn)遠(yuǎn)超出公有云上運行的基礎(chǔ)設(shè)施范疇。
“軟硬件技術(shù)的成熟、巨大的社會價值和偉大的商業(yè)模式”造就了云計算的興起和蓬勃發(fā)展，迅猛的勢頭也催生了各種新型技術(shù)架構(gòu)的誕生，筆者認(rèn)為云原生的出現(xiàn)同樣是順應(yīng)了技術(shù)和商業(yè)的浪潮。
放眼當(dāng)下，隨著互聯(lián)網(wǎng)智能終端設(shè)備數(shù)量的急劇增加和數(shù)據(jù)、業(yè)務(wù)下沉的訴求增多，邊緣計算規(guī)模和業(yè)務(wù)復(fù)雜度已經(jīng)發(fā)生了翻天覆地的變化，邊緣智能、邊緣實時計算、邊緣分析等新型業(yè)務(wù)不斷涌現(xiàn)。傳統(tǒng)云計算中心集中存儲、計算的模式已經(jīng)無法滿足邊緣設(shè)備對于時效、容量、算力的需求，如何打造邊緣基礎(chǔ)設(shè)施成了一個新課題。
本次分享也是從這個問題出發(fā)，和大家一起探討云原生基礎(chǔ)設(shè)施在邊緣計算落地的可能性。
試想，從云到端，是否能將云計算的能力下沉到邊緣側(cè)、設(shè)備側(cè)，并通過中心進(jìn)行統(tǒng)一交付、運維、管控，通過粘合云計算核心能力和邊緣算力，構(gòu)筑在邊緣基礎(chǔ)設(shè)施之上的云計算平臺？在回答這個問題之前，我們先梳理一下邊緣計算可能面臨的一些挑戰(zhàn)：
云邊端協(xié)同：缺少統(tǒng)一的交付、運維、管控標(biāo)準(zhǔn)。
安全：邊緣服務(wù)和邊緣數(shù)據(jù)的安全風(fēng)險控制難度較高。
網(wǎng)絡(luò)：邊緣網(wǎng)絡(luò)的可靠性和帶寬限制。
異構(gòu)資源：對不同硬件架構(gòu)、硬件規(guī)格、通信協(xié)議的支持，以及基于異構(gòu)資源、網(wǎng)絡(luò)、規(guī)模等差異化提供標(biāo)準(zhǔn)統(tǒng)一的服務(wù)能力的挑戰(zhàn)。
這些問題云原生模式能解嗎，云原生的技術(shù)底座kubernetes能撐起大梁嗎？眾所周知，以Kubernetes為基礎(chǔ)的云原生技術(shù)，核心價值之一是通過統(tǒng)一的標(biāo)準(zhǔn)實現(xiàn)在任何基礎(chǔ)設(shè)施上提供和云上一致的功能和體驗：那么借助云原生技術(shù)，可以實現(xiàn)云-邊-端一體化的應(yīng)用分發(fā)，解決在海量邊、端設(shè)備上統(tǒng)一完成大規(guī)模應(yīng)用交付、運維、管控的訴求是不是就有可能；同時在安全方面，云原生技術(shù)可以提供容器等更加安全的工作負(fù)載運行環(huán)境，以及流量控制、網(wǎng)絡(luò)策略等能力，能夠有效提升邊緣服務(wù)和邊緣數(shù)據(jù)的安全性；而依托云原生領(lǐng)域強大的社區(qū)和廠商支持，云原生技術(shù)對異構(gòu)資源的適用性逐步提升，在物聯(lián)網(wǎng)領(lǐng)域，云原生技術(shù)已經(jīng)能夠很好的支持多種CPU架構(gòu)(x86-64/arm/arm64)和通信協(xié)議，并實現(xiàn)較低的資源占用。k8s雖好，但落地邊緣計算場景好像還有一段路要走。
Kubernetes概念
基本概念
“Kubernetes——讓容器應(yīng)用進(jìn)入大規(guī)模工業(yè)生產(chǎn)，已然成了容器編排系統(tǒng)的事實標(biāo)準(zhǔn)；”下圖是kubernetes架構(gòu)圖（圖文引用自https://jimmysong.io/kubernetes-handbook/cloud-native/from-kubernetes-to-cloud-native.html）
核心層：Kubernetes最核心的功能，對外提供API構(gòu)建高層的應(yīng)用，對內(nèi)提供插件式應(yīng)用執(zhí)行環(huán)境
應(yīng)用層：部署（無狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、批處理任務(wù)、集群應(yīng)用等）和路由（服務(wù)發(fā)現(xiàn)、DNS解析等）
管理層：系統(tǒng)度量（如基礎(chǔ)設(shè)施、容器和網(wǎng)絡(luò)的度量），自動化（如自動擴展、動態(tài)Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口層：kubectl命令行工具、客戶端SDK以及集群聯(lián)邦
生態(tài)系統(tǒng)：在接口層之上的龐大容器集群管理調(diào)度的生態(tài)系統(tǒng)，可以劃分為兩個范疇
Kubernetes外部：日志、監(jiān)控、配置管理、CI、CD、Workflow、FaaS、OTS應(yīng)用、ChatOps等
Kubernetes內(nèi)部：CRI、CNI、CVI、鏡像倉庫、Cloud Provider、集群自身的配置和管理等
Kubernetes落地形態(tài)
隨著kubernetes的普及，越來越來的上層系統(tǒng)開始搭建在kubernetes底座之上，比如CICD、Serverless、IoT、PaaS等業(yè)務(wù)。過往經(jīng)驗告訴我們，在享受kubernetes帶來的方便快捷集成體驗的同時，kubernetes的自身運維也帶來了額外的巨大工作量：kubernetes的升級、高可用部署，資源對接、監(jiān)控、事件告警、多租管理等等。因此，專門的運維團(tuán)隊，運維工具，以及公有云托管服務(wù)就應(yīng)運而生了，這也是當(dāng)前業(yè)界kubernetes幾種常見的服務(wù)形態(tài)。
先說說公共云托管kubernetes服務(wù)，目前主流云廠商基本上都推出了XKS/XCK的服務(wù)，雖然底層實現(xiàn)各異，但是都有著類似的用戶體驗。用戶只需要在云廠商界面提交集群配置，點擊購買按鈕，一個高可用的，無縫對接各種云資源，云服務(wù)的kubernetes集群就能夠在3-5分鐘內(nèi)被創(chuàng)建出來；且后續(xù)的集群升級、運維、擴縮容等等運維操作都是動動小手的白屏化操作，體驗簡潔到極致。kubernetes強大接口能力也能夠讓用戶快速便捷的按需使用上各廠商的IaaS資源。綜合各種因素，公共云托管kubernetes服務(wù)正成為大多數(shù)用戶的選擇。但往往也有出于各種數(shù)據(jù)安全、集群規(guī)模、價格因素等等考慮，部分用戶也會選擇自建或者使用云廠商的專有云kubernetes版本、混合云版本。如果從kubernetes層面考量，三者本質(zhì)都大同小異，依賴第三方提供一個穩(wěn)定、兼容、安全可以持續(xù)發(fā)展的商業(yè)化kubernetes底座，以期得到規(guī)模化、標(biāo)準(zhǔn)化的k8s服務(wù)能力。
重新回到前面的問題，邊緣計算基礎(chǔ)設(shè)施既要云原生，又要云邊一體，還要一致性體驗，那么使用云端托管、邊緣定制會不會是一個很好的選擇呢？接下來展開敘述。
云端管控、邊緣自治
“云邊端一體化協(xié)同”作為標(biāo)準(zhǔn)化的一個構(gòu)想，將標(biāo)準(zhǔn)化的云原生能力向邊緣端復(fù)制，需要分為三個層次：
第一個層次是能夠在云端提供標(biāo)準(zhǔn)化的接口、管控能力，或者是標(biāo)準(zhǔn)的云服務(wù)和云資源的接入能力。其中我們能夠看到 Kubernetes 的身影；
第二個層次是能夠高效的管理處在整個邊緣端的眾多資源，其中包括在邊緣端應(yīng)用的效率問題。
第三層次是典型的 IoT 場景中的端設(shè)備，例如智慧樓宇智能停車設(shè)備，藍(lán)牙設(shè)備、人臉識別設(shè)備等。
云端托管原生k8s
先看最核心的云端托管層，在云邊一體的設(shè)計理念中，自然而然的能夠聯(lián)想到將原生的標(biāo)準(zhǔn)k8s托管在公共云上，開箱即用各種被集成的云能力必定是不二之選。幾點原因，k8s免運維上面已經(jīng)談到，原生的k8s便于被上層業(yè)務(wù)系統(tǒng)集成卻常常被忽視，通過云廠商將kubernetes和其他云能力（彈性、日志監(jiān)控、應(yīng)用市場，鏡像服務(wù)等）打通，無論是終端用戶直接使用，還是做新業(yè)務(wù)創(chuàng)新，復(fù)雜度都大大降低；此外，將云管控作為中心式服務(wù)，通過提供統(tǒng)一管控能力，反而非常適合管理邊緣場景中零散分布的計算資源和應(yīng)用，比如CDN服務(wù)、IoT業(yè)務(wù)等；最后，云原生的方式又可以讓用戶以往K8s經(jīng)驗用于新的邊緣計算業(yè)務(wù)。
上圖所示的管控架構(gòu)也符合前文提到的云邊分層結(jié)構(gòu)：“分而自治，中心管控”。
適度定制適配邊緣場景
k8s除了上述諸般特征之外，還有一個強大的插件機制，CxI自不必說，CRD、Operator更是讓k8s如虎添翼。在面向邊緣場景，自然而然會有一些別樣的邏輯需要適配，例如：邊緣節(jié)點和云端管控走弱連接公網(wǎng)交互帶來的管理邏輯適配；邊緣節(jié)點應(yīng)用驅(qū)逐邏輯適配；邊緣節(jié)點支持原生運維接口適配等等。插件化的非侵入方式可以讓原生k8s在免受任何一丁點的沖擊的同時，擴展更多的邏輯，比如用來做邊緣單元化管理的EdgeUnit Operator，再比如做邊緣節(jié)點自治管理的EdgeNode Operator。
前文提到，邊緣托管集群要將運維能力統(tǒng)一收編到云端，中心式的運維能力高效又便捷；所以，除了各種控制器之外，云端還有各種運維控制器來做日志、監(jiān)控數(shù)據(jù)等請求的轉(zhuǎn)運，如：日志控制器，MetricServer等；EdgeTunnelServer提供了一條穩(wěn)健的反向數(shù)據(jù)通道，很多云到邊的請求都要從此經(jīng)過，至于它的用途后面分解；
自治
如上圖所示，每個Edge節(jié)點上配備了一個EdgeHub組件，邊緣節(jié)點自治離不開它。
先說說背景，眾所周知k8s原生設(shè)計為數(shù)據(jù)中心內(nèi)部的容器編排系統(tǒng)（DCOS），默認(rèn)網(wǎng)絡(luò)可靠、可信。管控端（apiserver、調(diào)度器，資源控制器）源源不斷收集節(jié)點心跳做相應(yīng)的調(diào)度決策，若worker節(jié)點和管控斷鏈，原生k8s管控就要將節(jié)點置為不可用、并驅(qū)逐應(yīng)用（容忍時間到了之后）。而這些看似再正常不過的業(yè)務(wù)邏輯，在邊緣場景確是萬萬不可接受的。
在“分而自治，中心管控”的設(shè)計理念下，woker節(jié)點和中心管控走弱鏈接的公網(wǎng)交互，各種環(huán)境、網(wǎng)絡(luò)、人為因素都會帶來網(wǎng)絡(luò)的抖動，甚至不可用。但是此時，邊緣節(jié)點上的業(yè)務(wù)和agent卻要能夠持續(xù)提供服務(wù)，這就是自治。概括起來還包括，worker節(jié)點和云端斷連后：
節(jié)點上agent（kubelet、proxy等）無感知持續(xù)運行，就像還穩(wěn)穩(wěn)的連著master（其實是要騙騙它們）
節(jié)點間東西向流量持續(xù)穩(wěn)定交互（老師不在，同學(xué)們自己上自習(xí)）；
節(jié)點重啟后，節(jié)點上管控元信息和應(yīng)用原信息能夠恢復(fù)原樣，因為沒法通過管控配置中心同步（郵局關(guān)門，我不能給你寫信，我就在原地等你--mac地址保持、podIP保持等）；
EdgeHub作為節(jié)點上的臨時配置中心，在斷鏈情況下，持續(xù)為節(jié)點上所有設(shè)備提供斷網(wǎng)前一刻的配置服務(wù)。數(shù)據(jù)持久化在本地磁盤，和節(jié)點共存亡。EdgeHub上實現(xiàn)了諸多k8s api，除了給agent用，節(jié)點上承載的業(yè)務(wù)pod也可以使用，輕量又便捷；
原生運維支持
說完邊緣端，再來說說云邊鏈接的“臍帶”--EdgeTunnel。用過k8s命令行工具--kubectl的同學(xué)，肯定會對“kubectl exec，kubectl logs， kubectl attach，kubectl top”等運維命令直呼過癮，原理也很簡單，大致就是apiserver建聯(lián)到kubelet提供長鏈接支持。但是在邊緣場景，由于大多數(shù)邊緣節(jié)點沒有暴露在公網(wǎng)之上，主動的云到邊的網(wǎng)絡(luò)建鏈突然變成不可能，所有的原生運維api黯然失效。
EdgeTunnel的設(shè)計目的就是為了彌補這份缺失，它通過在管控與邊緣worker節(jié)點之間建立反向通道，并和worker節(jié)點的生命周期完整聯(lián)動，支持證書配置，支持websocktet等等。我們看到最終apiserver通過它按需中轉(zhuǎn)，metricserver（k8s原生運維工具）通過它按需中轉(zhuǎn)......至此，這條寬似太平洋的通道讓運維接口又轉(zhuǎn)動起來，既安全又高效，皆大歡喜。
邊緣單元
在真實落地過程中，我們發(fā)現(xiàn)邊緣場景還真的是新奇又多彩。先賣個關(guān)子：
客戶A，IoT廠商，它們負(fù)責(zé)交付安防設(shè)備到商場，機場、火車站等；但是各場所的資源、應(yīng)用管理訴求不同，客戶希望能夠一次提交，單元化管理，且要有“邏輯多租能力”：流量單一場地閉環(huán)，部署按場地調(diào)度；客戶B，CDN廠商，機房遍布世界各地，海外和國內(nèi)業(yè)務(wù)部署差異明顯，資源規(guī)格各異；希望能夠?qū)①Y源分組，為后續(xù)開展不同業(yè)務(wù)鋪墊。
單元化，單元化流量管理，單元化調(diào)度、批量管理？k8s好像沒有這個能力。千真萬確，是沒有，但是k8s的自定義資源控制器（CRD&Operator）提供了一條方便的解決途徑。
通過k8s的擴展機制，在原生k8s基礎(chǔ)上我們增加了edgeunit的管控邏輯，簡言之：
分屬同一個edgeunit的worker節(jié)點，可以批量控制節(jié)點上的標(biāo)簽、annotation，設(shè)置節(jié)點調(diào)度狀態(tài)等等；
用戶提交應(yīng)用，可以按照單元化部署；如用戶提交一份“deployment”配置，通過邊緣單元的調(diào)度控制，可以在每個edgeunit中被克隆部署；除了批量管理之外，也可以賦予“單元”的獨立控制能力，靈活高效。
用戶的服務(wù)流量控制，可以在單元內(nèi)閉環(huán)。大家都知道，原生k8s service提供的集群內(nèi)東西流量交互是不會感知邊緣場景下節(jié)點位置屬性而做額外處理的，但是出于數(shù)據(jù)安全考慮或天然的網(wǎng)絡(luò)隔離等原因，我們需要將東西流量限制在一個邊緣單元內(nèi)，這也是edgeunit在service管理上需要額外設(shè)計的邏輯；
輕量化
上文提到，邊緣算力的涵義頗廣，包括：規(guī)模較大的CDN資源，通常被稱之為“另一朵云”的邊緣基礎(chǔ)設(shè)施；也有浩如煙海的IoT的邊緣設(shè)備，算力規(guī)模小但是數(shù)量龐大。在處理IoT場景云原生轉(zhuǎn)型問題上，輕量化是繞不開的一環(huán)。我們知道，IoT業(yè)務(wù)場景充斥著大量的異構(gòu)、小規(guī)格的邊緣算力，像各種智能終端、設(shè)備，它們對資源的約束是極致的，難于接受額外的過多資源占用。所以，首當(dāng)其沖的必然是管控層面的輕量化，簡單介紹下目前常見的技術(shù)嘗試：
管控組件的輕量化替代和壓縮，如containerd替代docker，以及減少額外node sidecar的部署和開銷的方案等等；
管控組件的裁剪，在k8s體系下對kubelet相關(guān)功能的裁剪和模塊化，社區(qū)也有類似方案；
邊緣k8s用在哪里
那么回頭再看，似否還有一個問題我們還沒有討論到，邊緣容器/k8s到底用在哪里？一言以蔽之，Edge kubernetes適用于需要通過中心統(tǒng)一管控遠(yuǎn)端機房、服務(wù)器、設(shè)備的場景，輕松實現(xiàn)云、邊、端一體的應(yīng)用交付、運維、管控能力。
在IOT領(lǐng)域，可用于工廠、倉庫、樓宇、園區(qū)、高速收費站等場景。
在CDN領(lǐng)域，可以支持視頻直播、視頻監(jiān)控、在線教育等行業(yè)客戶就近計算和存儲的需求。
在ENS邊緣計算產(chǎn)品上，提供了針對ENS邊緣實例的DevOps能力，方便針對邊緣的應(yīng)用分發(fā)及部署運維。
阿里云容器服務(wù)邊緣托管ACK@Edge
人們常說“技術(shù)的發(fā)展有其自身的內(nèi)在直接動力”，而阿里云邊緣云原生的產(chǎn)品化落地動力確是實實在在的客戶場景催生。大致分幾個階段：
眾所周知，阿里云在兩大邊緣計算領(lǐng)域CDN和IoT深耕已久，邊緣規(guī)模和業(yè)務(wù)復(fù)雜度的日益攀升帶來了不小的效能問題。在云原生大有爆發(fā)之勢的2018年，阿里云容器服務(wù)先是和IoT業(yè)務(wù)團(tuán)隊聯(lián)合推出Kubernetes Edge定制版本，作為云上IoT邊緣托管服務(wù)底座，支持海量邊緣網(wǎng)關(guān)節(jié)點接入，深度融合IoT云端市場、云端FaaS、消息、運維等服務(wù)，
云邊一體概念萌生
在這個過程中，云原生讓IoT托管如虎添翼，持續(xù)落地智慧樓宇、智慧工廠、智慧倉儲項目，云邊端分層結(jié)構(gòu)也日益顯現(xiàn)，這里和大家分享兩個案例：親橙里和XX倉儲：
隨著IoT業(yè)務(wù)規(guī)模增長，Kubernetes Edge定制版作為獨立底座的維護(hù)成本越來越高，產(chǎn)品化勢在必行。在2019年4月，阿里云容器服務(wù)ACK推出EdgeKubernetes的托管服務(wù)（ACK@Edge），就是上文提到的k8s的托管服務(wù)，只不過兼具了滿足邊緣計算場景的能力補齊，云邊一體威力初現(xiàn)。
而這一次，ACK@Edge又在產(chǎn)品化之初選擇和CDN聯(lián)姻。阿里云有著國內(nèi)最大體量的CDN業(yè)務(wù)，并正在從以內(nèi)容分發(fā)服務(wù)為主轉(zhuǎn)變?yōu)檫吘売嬎悖訟CK@Edge為依托構(gòu)建云原生的EdgePaaS服務(wù)，而CDN的海量節(jié)點也考驗了
ACK@Edge的大規(guī)模服務(wù)能力。
隨著ACK@Edge的技術(shù)成熟，越來越多的內(nèi)外部客戶選擇云邊一體的云原生標(biāo)準(zhǔn)k8s托管服務(wù)。這里有一個優(yōu)酷的case，優(yōu)酷是國內(nèi)最大的視頻平臺，隨著業(yè)務(wù)的快速發(fā)展，需要將原來部署在若干 IDC 內(nèi)的集中式架構(gòu)，演進(jìn)到云+邊緣計算的架構(gòu)。這就勢必需要業(yè)務(wù)方能夠有一種方式來統(tǒng)一管理阿里云十幾個 region 和眾多的邊緣節(jié)點。通過邊緣k8s架構(gòu)，統(tǒng)一管理云與邊緣的節(jié)點，實現(xiàn)了應(yīng)用發(fā)布和彈性擴縮容的統(tǒng)一。通過彈性能力，節(jié)省了機器成本 50%以上；用戶終端就近訪問邊緣節(jié)點，讓端到端網(wǎng)絡(luò)延遲降低了 75%
邊緣云原生未來
云原生的未來是共同的期待和技術(shù)演進(jìn)，在消除邊緣和云的差異之后，云邊一體的架構(gòu)體系會在未來將邊緣計算牢牢堅定在“云計算新邊界”的理念之上。新業(yè)務(wù)的開展將和云上保持高度一致：serverless，安全沙箱技術(shù)，函數(shù)計算等新的業(yè)務(wù)形態(tài)都將在不遠(yuǎn)的將來落地。ACK@Edge將和大家一起見證。
- END -
推薦閱讀 Kubernetes 安全專家認(rèn)證（CKS） 運維的工作邊界，這次真的搞明白了！ 最強整理！常用正則表達(dá)式速查手冊 加速 Nginx 響應(yīng)的 5 個措施！效果明顯~ ZooKeeper、Eureka、Consul、Nacos 微服務(wù)注冊中心對比 Linux 系統(tǒng)安全強化指南 從零開始搭建創(chuàng)業(yè)公司DevOps技術(shù)棧 2021年的DevOps趨勢預(yù)測 搭建一套完整的企業(yè)級 K8s 集群（v1.20，二進(jìn)制方式） 60道常見的 Kubernetes 面試題總結(jié)
點亮，服務(wù)器三年不宕機
