世界即時：QCon高分演講：火山引擎容器技術(shù)在邊緣計算場景下的應(yīng)用實踐與探索

近日，火山引擎邊緣云原生團(tuán)隊的同學(xué)在QCon全球軟件開發(fā)大會上分享了火山引擎容器技術(shù)在邊緣計算場景下的應(yīng)用實踐與探索，并在一眾AIGC、LLM等當(dāng)下熱門議題中脫穎而出，入選觀眾滿意度投票中“叫好又叫座議題Top5”。

(相關(guān)資料圖)

以下是演講全文：

大家上午好！

我是來自火山引擎邊緣云原生團(tuán)隊的李志明。今天給大家分享的議題是關(guān)于容器技術(shù)在邊緣計算場景怎么去落地，以及我們在哪些場景下做了實踐。

首先做一下自我介紹。我自己一直在CDN和邊緣計算行業(yè)從事技術(shù)研發(fā)和架構(gòu)設(shè)計工作，個人比較擅長像比如Kubernetes、服務(wù)網(wǎng)格、容器網(wǎng)絡(luò)相關(guān)的云原生技術(shù)，對于高性能的Nginx和高性能緩存服務(wù)器也比較了解，目前主要是負(fù)責(zé)火山引擎邊緣容器平臺，以及邊緣容器實例產(chǎn)品的研發(fā)落地。

今天我的分享議題主要從四個方面。第一個給大家介紹什么是邊緣計算和邊緣容器。然后就是給大家講一下在邊緣計算場景下，我們落地邊緣容器這樣的云原生技術(shù)，面臨著什么樣的技術(shù)挑戰(zhàn)，然后我們在技術(shù)方案上是怎么去解決的。接下來也給大家分享一下我們邊緣容器技術(shù)在哪些內(nèi)外部場景進(jìn)行了落地，打造了什么樣的產(chǎn)品技術(shù)能力。最后給大家分享我們后續(xù)在云原生相關(guān)領(lǐng)域會做哪些探索。

邊緣計算主要就是在靠近客戶的終端放一些邊緣計算的算力資源，主要是給一些應(yīng)用開發(fā)和服務(wù)商提供IaaS的計算存儲網(wǎng)絡(luò)的資源，降低客戶的延時，降低客戶的帶寬。簡單理解，相對于中心云的產(chǎn)品，邊緣計算主要廣泛分布在二、三、四線城市，它從資源分布上肯定是比中心云分布得更廣，更靠近客戶。在規(guī)模上，它一般都是幾臺到幾十臺服務(wù)器，然后在一些區(qū)域中心上可能會有幾百臺服務(wù)器，就是規(guī)?？隙ū戎行脑聘　?/p>

邊緣計算主要有三個方面的價值：

第一個，相對于把服務(wù)部署在中心的場景，把服務(wù)部署在更靠近客戶的端上能夠大大降低客戶訪問的延遲。另外，比如提到像RTC、CDN、內(nèi)容分發(fā)這樣的一些場景，肯定比直接去訪問客戶中心要更短，響應(yīng)時延一般都會在100毫秒以內(nèi)。

第二個就是帶寬層面。傳統(tǒng)的RTC或者一些服務(wù)直接回源到中心，它的回源帶寬成本是比較高的。這個時候當(dāng)你把一些策略和執(zhí)行的算法放到邊緣上執(zhí)行的話，可以大大減少客戶的帶寬，可以降低客戶的成本。當(dāng)然因為我們邊緣的帶寬相對于中心的BGP帶寬肯定也是比較低的。

另外，還有一些本地計算的場景，有些客戶的數(shù)據(jù)有安全或者合規(guī)的要求，這種場景下是比較適合邊緣計算這樣一些場景的。

介紹完邊緣計算的介紹和邊緣計算的價值，接下來重點介紹我們的邊緣容器。

什么是邊緣容器呢？邊緣容器相對于當(dāng)前的中心容器，邊緣容器分布于剛才介紹的廣泛的邊緣計算的節(jié)點，主要分布在二、三、四線這樣的城市，依托于像Kubernetes這樣一些云原生的技術(shù)，給客戶提供場景化的解決方案。

我們邊緣容器主要是有以下的四個主要的特性，相對于中心容器，我們的資源覆蓋面肯定會更廣。因為廣泛分布在大量的邊緣節(jié)點上，所以說我們資源分布面更廣，離客戶更近。第二個，相對于邊緣虛機(jī)這樣的產(chǎn)品，因為傳統(tǒng)客戶之前在中心云使用，比如像一些函數(shù)的服務(wù)或者RTC的服務(wù)，這些場景如果直接下沉到邊緣，大部分的客戶會面臨一個問題就是如何去管理邊緣的這些節(jié)點和機(jī)房，以及原來傳統(tǒng)的發(fā)布系統(tǒng)也是基于中心或者單機(jī)房去設(shè)計的，當(dāng)服務(wù)下沉到邊緣機(jī)房的時候，怎么去運維。所以說邊緣容器第二個特性，就是相對于邊緣虛機(jī)的產(chǎn)品，能夠提供快速的彈性交付，客戶不需要去感知廣州有幾個機(jī)房，深圳有幾個機(jī)房，甚至華東區(qū)電信有幾個機(jī)房，怎么去開通，怎么去維護(hù)。

火山引擎會基于云原生的技術(shù)屏蔽底層的整體資源覆蓋的差異，然后批量交付。舉個簡單的例子，廣東電信的客戶需要1000個幾核幾GB的算力資源，我們就可以進(jìn)行快速交付，而不需要客戶去針對于廣東電信100個邊緣節(jié)點逐個去開通，我們可以達(dá)到快速交付能力。

第二個，很多客戶，特別一些創(chuàng)新性場景，從中心下沉邊緣，或者某些新業(yè)務(wù)場景是沒有針對邊緣場景去部署和運維的能力的。因為邊緣機(jī)房太多了，節(jié)點也會面臨裁撤、下線。所以說我們邊緣容器會屏蔽這些差異，給客戶統(tǒng)一提供像邊緣應(yīng)用的部署、版本的管理，包括一些應(yīng)用的遷移等等一系列的Devops的全應(yīng)用生命周期管理的能力。另外相對于一些中心容器的調(diào)度，一般都是基于Region的調(diào)度，而邊緣的話，火山引擎有一個叫全局規(guī)劃調(diào)度。因為我們會把邊緣所有的邊緣機(jī)房的算力資源統(tǒng)一進(jìn)行管理和管控，按照客戶的算力需求來進(jìn)行批量交付。比如客戶說廣東電信需要1000個，這個時候我們就會看整個廣東電信整體的算力分布情況，給客戶進(jìn)行批量交付，所以我們有一個全局規(guī)劃調(diào)度的技術(shù)能力。

介紹完了邊緣容器，來講講火山引擎邊緣容器有哪些核心的產(chǎn)品技術(shù)挑戰(zhàn)，重點介紹以下幾個技術(shù)層面。

容器技術(shù)在邊緣計算場景落地會面臨什么樣的技術(shù)挑戰(zhàn)呢？因為傳統(tǒng)的就像Kubernetes這樣的技術(shù)，一般會去管理一個機(jī)房或者是管理多個Region，這樣是比較常見的。但是邊緣機(jī)房，第一個我們叫資源分散。因為邊緣的IDC機(jī)房分布太多了，有幾百個，甚至上千個IDC機(jī)房。而且不同的IDC機(jī)房物理環(huán)境、硬件環(huán)境，甚至服務(wù)器數(shù)目都不太一樣，有的只有幾臺，有的有幾百臺。怎么基于Kubernetes合理地去管理不同的業(yè)務(wù)以及不同的資源，其實就是我們會面臨的第一個問題。

第二個，相對于中心的一些機(jī)房，其實邊緣的網(wǎng)絡(luò)環(huán)境是比較差的。像弱網(wǎng)、中心跟邊緣斷網(wǎng)、邊緣機(jī)房裁撤割接，這樣的情況是比較頻繁的。當(dāng)客戶的業(yè)務(wù)下沉到邊緣的時候，特別是在邊緣跟中心斷網(wǎng)的時候，怎么解決客戶邊緣容器上的業(yè)務(wù)、保證不會出現(xiàn)被驅(qū)逐這樣的一些情況，這就是我們面臨的第二個問題，怎么去解決這樣的問題。

第三個，我們邊緣的機(jī)房規(guī)模太小了，不可能去做資源分池處理；不可能一部分機(jī)器去生產(chǎn)虛機(jī)，一部分去生產(chǎn)容器。有些機(jī)房可能總共就是幾臺服務(wù)器。那么如何去實現(xiàn)虛機(jī)、容器的混合生產(chǎn)，混合調(diào)度，達(dá)到資源高密的生產(chǎn)和使用。這是我們面臨的第三個技術(shù)問題。

最后，由于邊緣IDC機(jī)房太多，很多客戶，比如說我這個應(yīng)用，需要在廣州電信1發(fā)1.0.0的版本，在廣東電信2發(fā)1.0.2版本，不同的機(jī)房，要部署不同的版本。同時它在應(yīng)用升級的時候，要實現(xiàn)灰度發(fā)布。同時還有一種情況，很多客戶是多個應(yīng)用組合部署才可以對外提供服務(wù)。比如說它在一個機(jī)房內(nèi)同時要部署日志服務(wù)、監(jiān)控服務(wù)，以及它自己的一些計算服務(wù)。如何去幫客戶解決這種多應(yīng)用的組合部署  以及多應(yīng)用之間的版本灰度，其實也是我們面臨的另外一個技術(shù)問題。這些問題都是在單機(jī)房或者說單kubernetes場景下不會遇到的。

我接下來重點講一下火山引擎容器團(tuán)隊針對這四個技術(shù)難點，是選擇什么樣的技術(shù)方案解決的。

首先就是重點給大家介紹一下我們整體火山容器平臺的技術(shù)架構(gòu)，就是邊緣容器平臺架構(gòu)。

最底層我們定義為整個IaaS、PaaS的資源層。在資源層面，邊緣的資源覆蓋差異性是非常多的，我們有自建的IDC資源，甚至有一些CDN的自建機(jī)房資源，包括多云的虛機(jī)資源以及其他場景的一些異構(gòu)資源、三方資源。這些資源，我們會按照節(jié)點、屬性、位置、區(qū)域，按照標(biāo)簽進(jìn)行統(tǒng)一的管理，進(jìn)行區(qū)分和分類。

當(dāng)資源被標(biāo)準(zhǔn)化之后，我們會引入一層PaaS的資源管控層，這一層我們重點構(gòu)建了第一個能力，就是解決第一個問題：海量資源的納管問題。整個技術(shù)其實我們也是基于Kubernetes技術(shù)打造的。后面我會重點去解釋一下我們整個PaaS資源層，怎么基于Kubernetes進(jìn)行設(shè)計。當(dāng)我們把整個資源都納入Kubernetes體系之后，再上一層我們就需要對這些邊緣的資源進(jìn)行編排、進(jìn)行應(yīng)用的管理、進(jìn)行鏡像的管理，這一層叫metakubernetes，就是我們的管控集群，我們叫PaaS管控層。這一層會統(tǒng)一給客戶提供，比如說像一些邊緣的Kubernetes集群的管理，像集群聯(lián)邦這樣的一些能力，以及比如說客戶業(yè)務(wù)部署的時候怎么基于Kubernetes幫客戶主動熔斷業(yè)務(wù)，或者我們平臺自身導(dǎo)致的一些故障，能夠自動去熔斷，我們叫風(fēng)控，就是風(fēng)控的能力建設(shè)。

此外，因為邊緣的環(huán)境比較差，當(dāng)客戶的容器大量升級的時候，怎么去解決一個鏡像分發(fā)的問題。

針對于海量納管的資源之后，我們需要給客戶提供調(diào)度以及高密的生產(chǎn)，我們怎么去解決這種融合調(diào)度、融合生產(chǎn)的問題呢？

最后就是一些監(jiān)控計費的通用能力。

當(dāng)我們整個PaaS管控層，整體建設(shè)了這些系統(tǒng)之后，容器平臺側(cè)就會提供不同語義來使用整個火山引擎邊緣計算的資源；比如基于應(yīng)用維度的，客戶完全不去感知底層的資源差異，叫應(yīng)用托管的形式。另外一種，用戶可能只希望使用容器算力資源，它有自己的發(fā)布系統(tǒng)，我們就可以直接交付邊緣容器實例，就是類似于中心ECI的資源形態(tài)。此外，我們也支持一種彈性的資源交付形態(tài)，比如按照分時、或者容器的負(fù)載自動擴(kuò)縮容，我們叫邊緣Serverless這種形態(tài)。此外，有些用戶已經(jīng)基于Kubernetes去建設(shè)運維發(fā)布平臺了，他希望基于Kubernetes的語義來使用容器資源，那么針對這種場景，我們也會支持基于Kubernetes語義接口來使用邊緣容器資源的能力。最上層就是我們面對不同的業(yè)務(wù)場景，像一些點播、直播、RTC、動態(tài)加速、邊緣函數(shù)、撥測、壓測這樣的場景，我們基于PaaS整個服務(wù)層，針對不同用戶提供不同的使用形態(tài)。這是我們整個邊緣容器的技術(shù)架構(gòu)。

接下來重點講講針對于以上的技術(shù)問題，我們到底怎么去設(shè)計和落地的。

第一個問題是我們怎么去解決邊緣海量資源的納管問題，以及像邊緣這種弱網(wǎng)關(guān)系下，我們怎么去解決斷網(wǎng)情況下客戶的pod不驅(qū)逐，達(dá)到邊緣自治的能力。

針對第一個，因為邊緣資源比較分散，其實我們這邊也是分兩種場景進(jìn)行解決的。第一種叫邊緣計算的資源，就是說我們自建IDC資源。我們自建的IDC資源，相對而言是比較穩(wěn)定的，然后基本上規(guī)模相對比較穩(wěn)定。這種情況下，因為它要去混合生產(chǎn)虛機(jī)和容器，在這種場景下，我們采用的是Kubernetes下沉的方案，在邊緣機(jī)房內(nèi)部內(nèi)置一個Kubernetes集群。第二種就是相對于一些單臺服務(wù)器就是一個結(jié)點，或者是多云的一些異構(gòu)機(jī)器，這種機(jī)器，它的網(wǎng)絡(luò)環(huán)境不太標(biāo)準(zhǔn)，機(jī)型也不太標(biāo)準(zhǔn)，容易出現(xiàn)一些硬件的故障。這樣一些特殊的機(jī)器，我們是采用了一個叫邊緣托管kubernetes的方案。在這個時候，我們在資源入庫存的時候，我們會針對不同的節(jié)點和機(jī)器進(jìn)行標(biāo)簽管理，最上層的有一個叫異構(gòu)資源納管的容器管控平臺。這個時候我們自動會根據(jù)當(dāng)前的一個節(jié)點的規(guī)模和機(jī)器的形態(tài)，根據(jù)自動規(guī)劃的結(jié)果納入到不同的像邊緣托管的kubernetes集群或者說是節(jié)點內(nèi)部的一個kubernetes集群。而我們異構(gòu)納管平臺，它就會自動去感知不同區(qū)域的資源分布情況，自動去管控邊緣托管kubernetes集群，自適應(yīng)的去納管不同區(qū)域的資源?，F(xiàn)在我們落地一般都是按照大區(qū)維度去規(guī)劃。一個邊緣托管kubernetes，我們大概會去納管2000-3000臺服務(wù)器。

通過這樣的模式，從這里看到我們這個架構(gòu)是分布式的架構(gòu)，當(dāng)邊緣機(jī)器越多的時候，我們會自動規(guī)劃出更多的kubernetes集群來納管資源。這樣其實是能夠做到像邊緣數(shù)萬級別的機(jī)器，甚至數(shù)十萬級別機(jī)器基于邊緣的kubernetes進(jìn)行納管的。

第二個，當(dāng)我們解決了第一個問題之后，解決了資源管理的問題之后，我們必然要解決第二個問題。弱網(wǎng)環(huán)境下，我們怎么去解決不會因為邊緣跟中心的網(wǎng)絡(luò)斷連，導(dǎo)致用戶的Workload或者pod被驅(qū)逐。在我們這個方案里面就解決了這個問題。第一個，比如說像一些異構(gòu)的資源池里面，我們采用的是邊緣托管kubernetes的方案，邊緣托管kubernetes這個方案，當(dāng)出現(xiàn)異構(gòu)的機(jī)器跟中心的托管kubernetes斷連的時候，它原生的一些機(jī)制是會把原先的一些Workload，包括一些關(guān)鍵的網(wǎng)絡(luò)資源維護(hù)到邊緣節(jié)點上。這個時候它并不會影響已經(jīng)生效的策略，從而也不會去驅(qū)逐在這些機(jī)器上的pod和關(guān)鍵的用戶網(wǎng)絡(luò)配置、存儲的一些配置。

針對于邊緣計算節(jié)點，就是我們自建比較穩(wěn)定的IDC機(jī)房，因為我們采用的是邊緣kubernetes下沉的方案。這個方案里面，當(dāng)中心跟邊緣斷網(wǎng)了之后，邊緣的kubernetes，它原生就已經(jīng)緩存了原先中心已經(jīng)下發(fā)的各種Workload，各種的一些客戶的網(wǎng)絡(luò)配置，所以說它也是能夠達(dá)到邊緣自治的效果的。我們主要是通過這樣的一個技術(shù)架構(gòu)來解決剛才講的面臨的資源分散管理以及像弱網(wǎng)環(huán)境下的資源管控問題、弱網(wǎng)環(huán)境下的邊緣自治的問題

接下來我們主要講一下第二個問題。剛才講邊緣的機(jī)房很少，當(dāng)然行業(yè)的解決方案也很多，有很多采用分池的方案，我們整體的技術(shù)架構(gòu)都是基于Kubernetes來設(shè)計的。因為我們需要達(dá)到高密生產(chǎn)，就是需要在一臺機(jī)器上直接去融合生產(chǎn)容器和虛機(jī)。第二個，我們需要在調(diào)度層面融合去調(diào)度容器和虛機(jī)。先講第一個問題，我們怎么去解決在一臺服務(wù)器上融合去生產(chǎn)容器和虛機(jī)，同時在底層的網(wǎng)絡(luò)和存儲能力上是能夠統(tǒng)一使用的。因為我們整體的設(shè)計方案都是按照超融合這樣的技術(shù)方案去設(shè)計。在虛機(jī)場景下，原生的Kubernetes是沒法生產(chǎn)虛機(jī)的，我們這里是引入了kubevirt這樣一個技術(shù)架構(gòu)。kubevirt這個技術(shù)架構(gòu)里面，它是可以通過kubelet這樣一個方案去拉起客戶的虛機(jī)，這樣我們就可以把虛機(jī)的生產(chǎn)納入到整個Kubernetes的體系里面。

第二個在容器場景，我們需要在一臺機(jī)上混合生產(chǎn)容器和虛機(jī)，就要解決一個安全的問題。在這里面我們采用的是安全容器的方案。安全容器現(xiàn)在發(fā)展是比較成熟的，就是直接基于Kubernetes可以生產(chǎn)。底層像我們自研的VPC、基于DPDK自研的EVS網(wǎng)絡(luò)、基于Ceph的塊存儲，或者基于SPDK的本地盤，由于安全容器和虛擬機(jī)底層采用的是統(tǒng)一虛擬化方案，所以我們Iaas層的存儲和網(wǎng)絡(luò)能力是可以統(tǒng)一復(fù)用的。兩種計算形態(tài)，像虛機(jī)和容器，底層的技術(shù)方案、實現(xiàn)體系是一致的，這里完全可以進(jìn)行復(fù)用，這樣就可以達(dá)到我們在一臺物理機(jī)上去混合生產(chǎn)容器、虛機(jī)這樣的能力。

當(dāng)我們達(dá)到了混合生產(chǎn)虛機(jī)和容器的技術(shù)能力之后，其實也面臨著另外一個問題。舉個例子，比如說我在廣東電信1這個節(jié)點上，我總共就有10000核vcpu，這時候來了一個虛機(jī)大客戶，他要8000核vcpu，來了一個容器客戶，他要5000核vcpu，這個時候必然就會超過整個kubernetes可以調(diào)度的資源，其實就是超過了我們整個資源的售賣情況。在這種情況下，如果直接調(diào)度到邊緣的kubernetes集群，其實會出現(xiàn)很多客戶的虛機(jī)或者很多客戶的容器出現(xiàn)大量生產(chǎn)失敗的情況。在這個情況下，我們針對大客戶，提出資源需求比較多的時候，其實我們在中心層面是做了統(tǒng)一調(diào)度的，我們叫全局規(guī)劃調(diào)度。

怎么去理解這個事情呢？當(dāng)我們要在某個IDC機(jī)房去給某個客戶擴(kuò)容資源的時候，我們在調(diào)度體系里面可以通過一定的資源運營策略來實現(xiàn)這樣一個能力，我們叫資源預(yù)占的方案。當(dāng)這個節(jié)點，虛機(jī)需要8000核vcpu，但是客戶又不一定立馬部署。在這個時候，在整個資源調(diào)度，在生產(chǎn)之前，就會針對這個節(jié)點把庫存進(jìn)行預(yù)占，我們叫預(yù)占的方案。這個時候容器有一個客戶來進(jìn)行生產(chǎn)的時候，因為資源在中心層面已經(jīng)被預(yù)占掉了，所以說這個時候就會反饋失敗，這樣就可以解決當(dāng)一個節(jié)點同時生產(chǎn)虛機(jī)和容器，資源沒有做規(guī)劃之前，導(dǎo)致大量客戶生產(chǎn)失敗的情況。我們這個方案叫基于全局維度的資源預(yù)占。

除了剛才解決三個問題之外，我們面臨另外一個問題，很多客戶從中心部署到邊緣的時候，其實是沒有邊緣的運維能力的。比如說我們之前接了一些HttpDns的服務(wù)或者函數(shù)的場景，因為他們之前都是基于中心服務(wù)去部署的，只需要去管理一個Region或者兩個Region，但是邊緣的節(jié)點太多了，讓客戶直接去下沉維護(hù)，其實維護(hù)的復(fù)雜度非常高。另外因為邊緣不同的機(jī)房，在能力上會存在一定的差異，因為不同的機(jī)房服務(wù)器數(shù)目不一樣，有的機(jī)房可能提供正常的7層LB，有的可能不提供7層LB，其實這個標(biāo)準(zhǔn)能力是不一樣的，包括有的機(jī)房可能提供本地盤，有的機(jī)房只提供云盤。因為我們沒法像中心那樣每個機(jī)房都提供全套標(biāo)準(zhǔn)云產(chǎn)品能力，這種情景對于客戶的運維復(fù)雜度是非常高的。就算他的業(yè)務(wù)想下沉邊緣，對他原生的業(yè)務(wù)系統(tǒng)改造也是非常大的。所以在這里面，客戶就希望我們能夠把邊緣的資源這些能力進(jìn)行一個高度的抽象，他不需要去感知底層的差異，產(chǎn)品層面可以統(tǒng)一解決像邊緣應(yīng)用編排、針對集群的發(fā)布、針對集群的版本管理等問題。

在這個里面，我們首先講第一個，我們怎么去解決應(yīng)用的多功能編排以及應(yīng)用的版本管理呢？針對不同的集群去管理客戶不同的版本。這里面IDC1，客戶需要發(fā)布V1.0.1版本，同時在IDC1上肯定只提供了本地盤，在IDC2上提供了云盤，客戶可能只有存儲需求，他不想感知這些差異，同時客戶又需要配套的LB、負(fù)載均衡的能力，甚至包括一定服務(wù)發(fā)現(xiàn)能力。這個里面我們主要是引入了兩層抽象的概念。第一個叫應(yīng)用集群，一個叫應(yīng)用，就是我們整體一個應(yīng)用編排的體系設(shè)計是基于這兩個維度在設(shè)計的，在應(yīng)用集群里面有幾個關(guān)鍵的語義，就是把我們云產(chǎn)品的能力會融合到應(yīng)用集群描述的語義里面。比如說網(wǎng)絡(luò)的LB、ALB、Nat、PIP、存儲的本地盤、云盤等，包括算力規(guī)格，針對集群級別，我們抽象出來了一個叫應(yīng)用集群的概念。這個應(yīng)用集群里面會把這些網(wǎng)絡(luò)和存儲能力融合進(jìn)去。這樣的話，我們針對于IDC1和IDC2做應(yīng)用生產(chǎn)的時候，其實是打包生產(chǎn)的模式，當(dāng)我們要部署到IDC1的時候，我們會把客戶配套需要的LB、Workload、存儲，統(tǒng)一會下發(fā)下去，然后在邊緣IDC1上再進(jìn)行真正的一個基于Kubernetes的生產(chǎn)，生產(chǎn)Pod的同時，然后把LB的配置生產(chǎn)出來，把存儲的配置給它生產(chǎn)出來。

在這一層主要是在PaaS層實現(xiàn)。第二層抽象，我們叫應(yīng)用(Application)?？蛻糁恍枰槍?yīng)用去配置他的LB、配置他的Workload、配置他的EIP、配置他的存儲。這樣的話，當(dāng)客戶需要部署到IDC1、IDC2的時候，這個時候客戶只需要在應(yīng)用描述他針對于網(wǎng)絡(luò)存儲以及自己應(yīng)用的描述。描述之后，我們整個PaaS調(diào)度就會針對我們的應(yīng)用集群去打包部署到IDC1、IDC2，這樣客戶就不需要感知到底層不同網(wǎng)絡(luò)、不同存儲的情況。同時針對這個架構(gòu)，我們就可以實現(xiàn)客戶針對不同集群的版本管理能力。比如剛剛講的客戶在應(yīng)用里面就可以去描述，我需要在IDC1里面部署V1.0.1版本，我要在IDC2里面部署V1.0.2版本。當(dāng)我們PaaS平臺打包部署到IDC1和IDC2的時候，這個時候我們就會感知客戶到選擇的對應(yīng)版本，然后去部署對應(yīng)的版本。通過這樣一個應(yīng)用集群以及面向客戶的應(yīng)用的設(shè)計概念，我們解決了客戶多集群的部署以及版本管理的問題。

其實還會面臨另外一個問題，就是說很多客戶業(yè)務(wù)部署到邊緣的時候，不止有一個應(yīng)用，會面臨什么問題？其實他會部署多個應(yīng)用，客戶需要部署一個日志服務(wù)，同時要部署一個計算服務(wù)，還要部署一個監(jiān)控服務(wù)。它只有多個服務(wù)同時在一個IDC上生產(chǎn)出來之后，才可以真正對外提供服務(wù)，這個叫多應(yīng)用的編排。在多應(yīng)用的編排場景下，我們這里引入了一個新的設(shè)計思路，叫主從應(yīng)用的思路。當(dāng)客戶要選擇多應(yīng)用編排的時候，他需要去選擇一個主應(yīng)用(master application)，當(dāng)客戶創(chuàng)建完成多個子應(yīng)用之后，在部署之前需要去配置哪些子應(yīng)用和主應(yīng)用去綁定。在這個時候我們整個PaaS調(diào)度體系里面就會去感知到這樣的主應(yīng)用跟子應(yīng)用之間的綁定關(guān)系，在資源調(diào)度和業(yè)務(wù)部署的時候就會按照客戶的綁定關(guān)系進(jìn)行整體的一個資源調(diào)度以及整體應(yīng)用的部署。同時針對剛剛講的，我們基于應(yīng)用集群，客戶可以配置部署的版本，基于應(yīng)用集群的版本管理也可以同時實現(xiàn)客戶就算在多個應(yīng)用綁定部署的情況下，也可以去實現(xiàn)不同的應(yīng)用在不同的集群，部署不同的版本。主要就是通過應(yīng)用集群、應(yīng)用和主從應(yīng)用，在我們設(shè)計里面引入這樣的幾個設(shè)計思路，最終能夠解決客戶在使用邊緣算力資源的時候面臨的版本管理、應(yīng)用管理的問題。

另外一個就是給大家講一下我們整個邊緣容器平臺在穩(wěn)定性上是怎么去設(shè)計和落地的。

穩(wěn)定性設(shè)計主要是三塊，監(jiān)控、告警，還有當(dāng)平臺發(fā)現(xiàn)客戶的業(yè)務(wù)出現(xiàn)問題的時候，我們要能夠熔斷。在監(jiān)控、告警上，跟通用的Kubernetes方案差不多，我們也是將邊緣托管Kubernets集群以及邊緣的kubernetes集群，像事件、一些日志、指標(biāo)統(tǒng)一都收集到中心，再去構(gòu)建我們整個監(jiān)控大盤，再基于我們自己的告警中心，當(dāng)發(fā)現(xiàn)客戶的異常指標(biāo)的時候，進(jìn)行業(yè)務(wù)告警。比如說客戶某個關(guān)鍵的網(wǎng)絡(luò)資源被刪除掉了，客戶自己的應(yīng)用被刪除掉了，我們會觸發(fā)一些告警。

重點講一下我們的整個風(fēng)控。什么叫風(fēng)控呢？我們做風(fēng)控的本質(zhì)原因，是因為很多客戶上容器平臺的時候，之前客戶在虛機(jī)的運維模式下或者裸機(jī)的運維模式下不會面臨虛機(jī)資源被批量刪除的問題，因為是比較穩(wěn)定的IaaS資源，它是不會出現(xiàn)批量釋放、批量銷毀、批量宕機(jī)的情況的。但是當(dāng)客戶去使用容器的場景下，可能因為客戶自己的誤操作，或者容器平臺自身的一些問題，導(dǎo)致客戶的容器或者一些關(guān)鍵的資源被錯誤的批量刪除掉。我們?yōu)榱私鉀Q這個問題，引入了一個風(fēng)控熔斷的設(shè)計思路。我們這里實現(xiàn)的方案就是基于Kubernetes的webhook?；趙ebhook的這個架構(gòu)體系進(jìn)行設(shè)計的，把客戶的事件進(jìn)行統(tǒng)一的收集和處理，在策略層面，我們引入了兩個策略，一個叫靜態(tài)策略，一個叫動態(tài)策略。靜態(tài)策略比較簡單，就是針對一些大客戶或者一些關(guān)鍵的，比如像網(wǎng)絡(luò)、存儲，我們會進(jìn)入封禁，當(dāng)發(fā)現(xiàn)客戶做了這樣一些刪除操作，或者我們自己的系統(tǒng)出現(xiàn)問題了，在執(zhí)行刪除之前，我們會直接熔斷，或者客戶做了刪除，我們會直接給他返回失敗，這樣客戶的操作就會失敗，這時候客戶就不會因為誤操作出現(xiàn)規(guī)模故障。

第二個時間維度的，我們叫動態(tài)策略。動態(tài)策略主要是做了基于時間維度的管控策略。最終實現(xiàn)的效果就是客戶可以配過去的某一個時間段，客戶的容器或者某個關(guān)鍵的資源不允許被刪除，比如客戶配置過去5分鐘不允許刪除超過100個Pod，如果發(fā)生了超過100個Pod被刪除的情況，就認(rèn)為是客戶自己誤操作或者平臺自身出現(xiàn)了問題，這個時候容器平臺就會主動觸發(fā)熔斷，并且觸發(fā)告警，從而解決客戶規(guī)模故障的問題。

講了我們整個穩(wěn)定性方案之后，接下來重點給大家講一下我們在邊緣的場景下，我們怎么去落地的，有哪些典型的案例。

第一個案例，重點給大家介紹一下創(chuàng)新型業(yè)務(wù)。什么叫做創(chuàng)新型業(yè)務(wù)呢？比如邊緣函數(shù)的業(yè)務(wù)，只有兩個左右的研發(fā)同學(xué)，在邊緣函數(shù)的業(yè)務(wù)場景下，他希望使用邊緣的資源去降低整個邊緣的延遲，它需要在邊緣給客戶提供一些類似SSR渲染的產(chǎn)品能力。這個時候讓它去開發(fā)一個針對邊緣的資源管控和發(fā)布平臺肯定是不現(xiàn)實的。針對函數(shù)場景，它需要如下幾個能力，因為它是多個應(yīng)用部署，就需要提供多應(yīng)用部署的能力，同時它的應(yīng)用之間是要支持服務(wù)發(fā)現(xiàn)的，就是函數(shù)的日志服務(wù)、計算服務(wù)、配置服務(wù)等是需要互相交互的。

針對這個場景，我們主要是讓他們使用我們邊緣容器應(yīng)用托管的解決方案。一個就是針對于應(yīng)用的部署，我們提供了多應(yīng)用編排部署的能力，可以滿足函數(shù)的多應(yīng)用部署編排需求。同時在集群內(nèi)，我們是支持基于kubernetes的coredns服務(wù)發(fā)現(xiàn)產(chǎn)品能力的。此外，它的函數(shù)場景也要支持http、https這樣的7層接入能力。這種場景下，我們基于自研的ealb負(fù)載均衡產(chǎn)品，結(jié)合類似ingress controller的實現(xiàn)機(jī)制，在邊緣上會動態(tài)感知客戶在這個節(jié)點部署的pod，這個7層LB就會把函數(shù)的請求轉(zhuǎn)發(fā)給函數(shù)的容器里面。通過這樣一個方案可以讓函數(shù)業(yè)務(wù)基于邊緣容器快速部署起來，從而實現(xiàn)對外產(chǎn)品化。

另外針對函數(shù)場景，因為它其實是需要做就近接入的，它本身是沒有dns接入調(diào)度能力的，我們結(jié)合GTM產(chǎn)品能力給函數(shù)提供相應(yīng)的邊緣dns接入調(diào)度能力?？蛻魧⒑瘮?shù)的業(yè)務(wù)部署到邊緣的節(jié)點之后，拿到了整個邊緣節(jié)點的部署情況，這個時候就會通過火山的GTM產(chǎn)品生成出它的調(diào)度域，這個時候就會達(dá)到什么效果呢？當(dāng)容器平臺把函數(shù)的業(yè)務(wù)部署到廣東電信的時候，廣東電信的客戶去訪問函數(shù)服務(wù)的時候，就只會解析到廣東電信的節(jié)點。同樣的道理，深圳的就會解析到深圳，西北的解析到西北，海外的解析到海外。通過這樣一套解決方案，就可以使函數(shù)的業(yè)務(wù)對外快速產(chǎn)品化，可以把整個產(chǎn)品快速孵化出來。

第二個，舉個例子，比如動態(tài)加速場景，是一種典型的傳統(tǒng)VCDN業(yè)務(wù)場景。什么叫傳統(tǒng)業(yè)務(wù)呢？有些業(yè)務(wù)，像CDN、RTC這樣的場景，它本身是有邊緣資源的運維能力的。但是在一些大促活動的時候，希望能夠使用一些邊緣容器算力資源，能夠快速擴(kuò)容一批資源出來。但是它并不需要使用容器一些更高階的產(chǎn)品能力，比如應(yīng)用部署、版本發(fā)布等。因為他們已經(jīng)基于邊緣的物理機(jī)或者虛擬機(jī)進(jìn)行部署，有一套自有的調(diào)度體系和發(fā)布體系。所以他們使用邊緣容器更希望什么效果呢？首先希望能夠用到容器的快速彈性調(diào)度能力，在大促活動的時候、春節(jié)活動的時候能夠快速部署。另外又能兼顧老的運維能力和發(fā)布系統(tǒng)，希望你的容器能夠支持遠(yuǎn)程ssh、systemd，甚至能夠支持內(nèi)核協(xié)議棧優(yōu)化、支持TOA、UOA等內(nèi)核模塊安裝，這類場景其實我們也是做了一套技術(shù)方案。

首先我們基于客戶原生物理機(jī)使用的內(nèi)核，定制了滿足客戶需求的安全容器內(nèi)核，此外，將ntp、systemd、ssh等組件集成到基礎(chǔ)鏡像里面，提供了一個類似富容器的基礎(chǔ)鏡像?；谶@個富容器，我們可以給客戶提供一系列跟虛機(jī)持平的技術(shù)能力。這樣達(dá)到一個什么效果呢？像動態(tài)加速這樣的場景，比如說我需要廣東電信擴(kuò)充100個32C96G的容器實例，這時候我們給它調(diào)度出來之后，相對DCDN的SRE而言，他就可以把這些資源直接納入到原生的運維發(fā)布平臺里面，從而他可以基于他原來的發(fā)布平臺去部署對應(yīng)的DCDN業(yè)務(wù)。它原生的業(yè)務(wù)，包括自有的一些應(yīng)用和模塊安裝都是可以兼容的，這樣就可以達(dá)到像這種基于物理機(jī)運維的傳統(tǒng)場景也可以使用容器資源。

最后一個場景就是彈性場景，像撥測、壓測，他們的主要需求就是希望在大促活動的時候，或者說有一些特殊場景的時候，希望快速交付，比如全國1000個容器，但是具體分布在哪些節(jié)點，客戶并不關(guān)心，分布在哪些城市，客戶也不關(guān)心，另外客戶可能就只用一天或者半天，用完之后就要快速釋放掉，因為這樣可以大大減少他們的成本。這樣的場景就是基于容器實例產(chǎn)品直接托管他們的應(yīng)用，使用邊緣容器實例的批量資源交付這樣一個方案就可以達(dá)到這樣的效果。

最后給大家講一講后面整體云原生在邊緣場景上，我們有什么樣的規(guī)劃。因為剛剛講了，第一個就是很多業(yè)務(wù)從中心下沉到邊緣的時候，可能需要去跟中心做一些協(xié)同，它沒法脫離中心完全在邊緣就可以對外提供服務(wù)，可能需要和中心的管控服務(wù)或者信令服務(wù)做一些協(xié)同。當(dāng)它的服務(wù)部署在多個邊緣節(jié)點之后，它也希望做一些協(xié)同。這樣的場景下，我們會結(jié)合servicemesh的技術(shù)，給客戶提供云邊、邊邊協(xié)同的產(chǎn)品技術(shù)能力。另外就是彈性調(diào)度場景，比如分時調(diào)度，就是不同時間片算力資源需求不一樣，希望按照不同時間片動態(tài)調(diào)度出來算力資源，這樣可以大大減少成本，或者某些場景需要跨節(jié)點容災(zāi)調(diào)度，我們后續(xù)也會重點建設(shè)彈性調(diào)度的產(chǎn)品技術(shù)能力。此外像AI、推理，這些場景，需要對應(yīng)的GPU容器實例，這個時候我們也會在這個技術(shù)方向做一些技術(shù)的落地。此外，我們也會針對不同場景的解決方案去打磨場景解決方案。這是火山邊緣容器團(tuán)隊在后面會做的一些產(chǎn)品技術(shù)規(guī)劃。謝謝大家?。ㄗ髡撸褐煺茜鳎?/p>

推薦DIY文章

我對創(chuàng)新創(chuàng)業(yè)的認(rèn)識和理解：創(chuàng)新和創(chuàng)業(yè)是相輔相成、不可分割的_天天熱議

兒童滑梯室內(nèi)價格大全 木制的兒童滑梯配套設(shè)施會不一樣嗎

滔滔不絕的竇文濤：是一位非常著名的主持人 深受觀眾的喜愛

發(fā)電廠設(shè)備接地的詳細(xì)方法 科普與接地設(shè)計相關(guān)的基本概念

君生我未生 我生君已老全文與作者：這首詩是唐代銅官窯瓷器上的銘文

我出門總是帶著五瓶藥水 來自歌曲《藥水歌》 是藥水哥的原創(chuàng)歌曲