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

以下是演講全文：

(資料圖片僅供參考)

大家上午好！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當我們整個PaaS管控層，整體建設(shè)了這些系統(tǒng)之后，容器平臺側(cè)就會提供不同語義來使用整個火山引擎邊緣計算的資源；比如基于應(yīng)用維度的，客戶完全不去感知底層的資源差異，叫應(yīng)用托管的形式。另外一種，用戶可能只希望使用容器算力資源，它有自己的發(fā)布系統(tǒng)，我們就可以直接交付邊緣容器實例，就是類似于中心ECI的資源形態(tài)。此外，我們也支持一種彈性的資源交付形態(tài)，比如按照分時、或者容器的負載自動擴縮容，我們叫邊緣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ū)逐，達到邊緣自治的能力。

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

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

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

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

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

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

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

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

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

在這個里面，我們首先講第一個，我們怎么去解決應(yīng)用的多功能編排以及應(yīng)用的版本管理呢？針對不同的集群去管理客戶不同的版本。這里面IDC1，客戶需要發(fā)布V1.0.1版本，同時在IDC1上肯定只提供了本地盤，在IDC2上提供了云盤，客戶可能只有存儲需求，他不想感知這些差異，同時客戶又需要配套的LB、負載均衡的能力，甚至包括一定服務(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ò)和存儲能力融合進去。這樣的話，我們針對于IDC1和IDC2做應(yīng)用生產(chǎn)的時候，其實是打包生產(chǎn)的模式，當我們要部署到IDC1的時候，我們會把客戶配套需要的LB、Workload、存儲，統(tǒng)一會下發(fā)下去，然后在邊緣IDC1上再進行真正的一個基于Kubernetes的生產(chǎn)，生產(chǎn)Pod的同時，然后把LB的配置生產(chǎn)出來，把存儲的配置給它生產(chǎn)出來。

在這一層主要是在PaaS層實現(xiàn)。第二層抽象，我們叫應(yīng)用(Application)。客戶只需要針對應(yīng)用去配置他的LB、配置他的Workload、配置他的EIP、配置他的存儲。這樣的話，當客戶需要部署到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版本。當我們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)用的思路。當客戶要選擇多應(yīng)用編排的時候，他需要去選擇一個主應(yīng)用(master application)，當客戶創(chuàng)建完成多個子應(yīng)用之后，在部署之前需要去配置哪些子應(yīng)用和主應(yīng)用去綁定。在這個時候我們整個PaaS調(diào)度體系里面就會去感知到這樣的主應(yīng)用跟子應(yīng)用之間的綁定關(guān)系，在資源調(diào)度和業(yè)務(wù)部署的時候就會按照客戶的綁定關(guā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)控、告警，還有當平臺發(fā)現(xiàn)客戶的業(yè)務(wù)出現(xiàn)問題的時候，我們要能夠熔斷。在監(jiān)控、告警上，跟通用的Kubernetes方案差不多，我們也是將邊緣托管Kubernets集群以及邊緣的kubernetes集群，像事件、一些日志、指標統(tǒng)一都收集到中心，再去構(gòu)建我們整個監(jiān)控大盤，再基于我們自己的告警中心，當發(fā)現(xiàn)客戶的異常指標的時候，進行業(yè)務(wù)告警。比如說客戶某個關(guān)鍵的網(wǎng)絡(luò)資源被刪除掉了，客戶自己的應(yīng)用被刪除掉了，我們會觸發(fā)一些告警。

重點講一下我們的整個風控。什么叫風控呢？我們做風控的本質(zhì)原因，是因為很多客戶上容器平臺的時候，之前客戶在虛機的運維模式下或者裸機的運維模式下不會面臨虛機資源被批量刪除的問題，因為是比較穩(wěn)定的IaaS資源，它是不會出現(xiàn)批量釋放、批量銷毀、批量宕機的情況的。但是當客戶去使用容器的場景下，可能因為客戶自己的誤操作，或者容器平臺自身的一些問題，導(dǎo)致客戶的容器或者一些關(guān)鍵的資源被錯誤的批量刪除掉。我們?yōu)榱私鉀Q這個問題，引入了一個風控熔斷的設(shè)計思路。我們這里實現(xiàn)的方案就是基于Kubernetes的webhook?；趙ebhook的這個架構(gòu)體系進行設(shè)計的，把客戶的事件進行統(tǒng)一的收集和處理，在策略層面，我們引入了兩個策略，一個叫靜態(tài)策略，一個叫動態(tài)策略。靜態(tài)策略比較簡單，就是針對一些大客戶或者一些關(guān)鍵的，比如像網(wǎng)絡(luò)、存儲，我們會進入封禁，當發(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被刪除的情況，就認為是客戶自己誤操作或者平臺自身出現(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負載均衡產(chǎn)品，結(jié)合類似ingress controller的實現(xiàn)機制，在邊緣上會動態(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)度域，這個時候就會達到什么效果呢？當容器平臺把函數(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這樣的場景，它本身是有邊緣資源的運維能力的。但是在一些大促活動的時候，希望能夠使用一些邊緣容器算力資源，能夠快速擴容一批資源出來。但是它并不需要使用容器一些更高階的產(chǎn)品能力，比如應(yīng)用部署、版本發(fā)布等。因為他們已經(jīng)基于邊緣的物理機或者虛擬機進行部署，有一套自有的調(diào)度體系和發(fā)布體系。所以他們使用邊緣容器更希望什么效果呢？首先希望能夠用到容器的快速彈性調(diào)度能力，在大促活動的時候、春節(jié)活動的時候能夠快速部署。另外又能兼顧老的運維能力和發(fā)布系統(tǒng)，希望你的容器能夠支持遠程ssh、systemd，甚至能夠支持內(nèi)核協(xié)議棧優(yōu)化、支持TOA、UOA等內(nèi)核模塊安裝，這類場景其實我們也是做了一套技術(shù)方案。

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

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

最后給大家講一講后面整體云原生在邊緣場景上，我們有什么樣的規(guī)劃。因為剛剛講了，第一個就是很多業(yè)務(wù)從中心下沉到邊緣的時候，可能需要去跟中心做一些協(xié)同，它沒法脫離中心完全在邊緣就可以對外提供服務(wù)，可能需要和中心的管控服務(wù)或者信令服務(wù)做一些協(xié)同。當它的服務(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ù)的落地。此外，我們也會針對不同場景的解決方案去打磨場景解決方案。這是火山邊緣容器團隊在后面會做的一些產(chǎn)品技術(shù)規(guī)劃。謝謝大家?。ㄗ髡撸褐煺茜鳎?/p>

關(guān)鍵詞：