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

【資料圖】

以下是演講全文：

大家上午好！

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

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

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

邊緣計算主要就是在靠近客戶的終端放一些邊緣計算的算力資源，主要是給一些應用開發和服務商提供IaaS的計算存儲網絡的資源，降低客戶的延時，降低客戶的帶寬。簡單理解，相對于中心云的產品，邊緣計算主要廣泛分布在二、三、四線城市，它從資源分布上肯定是比中心云分布得更廣，更靠近客戶。在規模上，它一般都是幾臺到幾十臺服務器，然后在一些區域中心上可能會有幾百臺服務器，就是規模肯定比中心云更小。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后就是一些監控計費的通用能力。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

穩定性設計主要是三塊，監控、告警，還有當平臺發現客戶的業務出現問題的時候，我們要能夠熔斷。在監控、告警上，跟通用的Kubernetes方案差不多，我們也是將邊緣托管Kubernets集群以及邊緣的kubernetes集群，像事件、一些日志、指標統一都收集到中心，再去構建我們整個監控大盤，再基于我們自己的告警中心，當發現客戶的異常指標的時候，進行業務告警。比如說客戶某個關鍵的網絡資源被刪除掉了，客戶自己的應用被刪除掉了，我們會觸發一些告警。

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

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

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

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

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

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

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

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

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

最后給大家講一講后面整體云原生在邊緣場景上，我們有什么樣的規劃。因為剛剛講了，第一個就是很多業務從中心下沉到邊緣的時候，可能需要去跟中心做一些協同，它沒法脫離中心完全在邊緣就可以對外提供服務，可能需要和中心的管控服務或者信令服務做一些協同。當它的服務部署在多個邊緣節點之后，它也希望做一些協同。這樣的場景下，我們會結合servicemesh的技術，給客戶提供云邊、邊邊協同的產品技術能力。另外就是彈性調度場景，比如分時調度，就是不同時間片算力資源需求不一樣，希望按照不同時間片動態調度出來算力資源，這樣可以大大減少成本，或者某些場景需要跨節點容災調度，我們后續也會重點建設彈性調度的產品技術能力。此外像AI、推理，這些場景，需要對應的GPU容器實例，這個時候我們也會在這個技術方向做一些技術的落地。此外，我們也會針對不同場景的解決方案去打磨場景解決方案。這是火山邊緣容器團隊在后面會做的一些產品技術規劃。謝謝大家！（作者：朱哲琪）

關鍵詞：