关于容器技术:QCon高分演讲火山引擎容器技术在边缘计算场景下的应用实践与探索

近日，火山引擎边缘云原生团队的同学在 QCon 寰球软件开发大会上分享了火山引擎容器技术在边缘计算场景下的利用实际与摸索，并在一众 AIGC、LLM 等当下热门议题中怀才不遇，入选观众满意度投票中“叫好又叫座议题 Top5”。

以下是演讲全文：

大家上午好！

我是来自火山引擎边缘云原生团队的李志明。明天给大家分享的议题是对于容器技术在边缘计算场景怎么去落地，以及咱们在哪些场景下做了实际。

首先做一下自我介绍。我本人始终在 CDN 和边缘计算行业从事技术研发和架构设计工作，集体比拟善于像比方 Kubernetes、服务网格、容器网络相干的云原生技术，对于高性能的 Nginx 和高性能缓存服务器也比拟理解，目前次要是负责火山引擎边缘容器平台，以及边缘容器实例产品的研发落地。

明天我的分享议题次要从四个方面。第一个给大家介绍什么是边缘计算和边缘容器。而后就是给大家讲一下在边缘计算场景下，咱们落地边缘容器这样的云原生技术，面临着什么样的技术挑战，而后咱们在技术计划上是怎么去解决的。接下来也给大家分享一下咱们边缘容器技术在哪些内外部场景进行了落地，打造了什么样的产品技术能力。最初给大家分享咱们后续在云原生相干畛域会做哪些摸索。

01 边缘计算和边缘容器

边缘计算次要就是在凑近客户的终端放一些边缘计算的算力资源，次要是给一些利用开发和服务商提供 IaaS 的计算存储网络的资源，升高客户的延时，升高客户的带宽。简略了解，绝对于核心云的产品，边缘计算次要宽泛散布在二、三、四线城市，它从资源散布上必定是比核心云散布得更广，更凑近客户。在规模上，它个别都是几台到几十台服务器，而后在一些区域核心上可能会有几百台服务器，就是规模必定比核心云更小。

边缘计算次要有三个方面的价值：

• 第一个，绝对于把服务部署在核心的场景，把服务部署在更凑近客户的端上可能大大降低客户拜访的提早。另外，比方提到像 RTC、CDN、内容散发这样的一些场景，必定比间接去拜访客户核心要更短，响应时延个别都会在 100 毫秒以内。
• 第二个就是带宽层面。传统的 RTC 或者一些服务间接回源到核心，它的回源带宽老本是比拟高的。这个时候当你把一些策略和执行的算法放到边缘上执行的话，能够大大减少客户的带宽，能够升高客户的老本。当然因为咱们边缘的带宽绝对于核心的 BGP 带宽必定也是比拟低的。
• 另外，还有一些本地计算的场景，有些客户的数据有平安或者合规的要求，这种场景下是比拟适宜边缘计算这样一些场景的。

介绍完边缘计算的介绍和边缘计算的价值，接下来重点介绍火山引擎边缘云的边缘容器。

什么是边缘容器呢？绝对于以后的核心容器，边缘容器散布于方才介绍的宽泛的边缘计算的节点，次要散布在二、三、四线这样的城市，依靠于像 Kubernetes 这样一些云原生的技术，给客户提供场景化的解决方案。

火山引擎边缘云的边缘容器次要是有以下的四个次要的个性：

资源笼罩广

绝对于核心容器，咱们的资源覆盖面必定会更广。因为宽泛散布在大量的边缘节点上，所以说咱们资源分布面更广，离客户更近。

疾速弹性交付

绝对于边缘虚机这样的产品，因为传统客户之前在核心云应用，比方像一些函数的服务或者 RTC 的服务，这些场景如果间接下沉到边缘，大部分的客户会面临一个问题就是如何去治理边缘的这些节点和机房，以及原来传统的公布零碎也是基于核心或者单机房去设计的，当服务下沉到边缘机房的时候，怎么去运维。所以说边缘容器第二个个性，就是绝对于边缘虚机的产品，可能提供疾速的弹性交付，客户不须要去感知广州有几个机房，深圳有几个机房，甚至华东区电信有几个机房，怎么去开明，怎么去保护。火山引擎会基于云原生的技术屏蔽底层的整体资源笼罩的差别，而后批量交付。举个简略的例子，广东电信的客户须要 1000 个几核几 GB 的算力资源，咱们就能够进行疾速交付，而不须要客户去针对于广东电信 100 个边缘节点一一去开明，咱们能够达到疾速交付能力。

全生命周期治理

很多客户，特地一些创新性场景，从核心下沉边缘，或者某些新业务场景是没有针对边缘场景去部署和运维的能力的。因为边缘机房太多了，节点也会面临裁撤、下线。所以说火山引擎边缘容器会屏蔽这些差别，给客户对立提供像边缘利用的部署、版本的治理，包含一些利用的迁徙等等一系列的 Devops 的全利用生命周期治理的能力。

全局布局调度

另绝对于一些核心容器的调度，个别都是基于 Region 的调度，而边缘的话，火山引擎有一个叫全局布局调度。因为咱们会把边缘所有的边缘机房的算力资源对立进行治理和管控，依照客户的算力需要来进行批量交付。比方客户说广东电信须要 1000 个，这个时候咱们就会看整个广东电信整体的算力散布状况，给客户进行批量交付，所以咱们有一个全局布局调度的技术能力。

02 火山引擎边缘容器技术挑战与应答

火山引擎边缘容器技术挑战

介绍完了边缘容器，来讲讲火山引擎边缘容器有哪些外围的产品技术挑战，重点介绍以下几个技术层面。

容器技术在边缘计算场景落地会面临什么样的技术挑战呢？

因为传统的就像 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 被删除的状况，就认为是客户本人误操作或者平台本身呈现了问题，这个时候容器平台就会被动触发熔断，并且触发告警，从而解决客户规模故障的问题。

03 边缘容器的利用摸索与实际

讲了咱们整个稳定性计划之后，接下来重点给大家讲一下咱们在边缘的场景下，咱们怎么去落地的，有哪些典型的案例。

边缘函数场景的利用实际

第一个案例，重点给大家介绍一下创新型业务。什么叫做创新型业务呢？比方边缘函数的业务，只有两个左右的研发同学，在边缘函数的业务场景下，他心愿应用边缘的资源去升高整个边缘的提早，它须要在边缘给客户提供一些相似 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 业务。它原生的业务，包含自有的一些利用和模块装置都是能够兼容的，这样就能够达到像这种基于物理机运维的传统场景也能够应用容器资源。

APM 业务场景的利用实际

最初一个场景就是弹性场景，像拨测、压测，他们的次要需要就是心愿在大促流动的时候，或者说有一些非凡场景的时候，心愿疾速交付，比方全国 1000 个容器，然而具体散布在哪些节点，客户并不关怀，散布在哪些城市，客户也不关怀，另外客户可能就只用一天或者半天，用完之后就要疾速开释掉，因为这样能够大大减少他们的老本。这样的场景就是基于容器实例产品间接托管他们的利用，应用边缘容器实例的批量资源交付这样一个计划就能够达到这样的成果。

04 总结与瞻望

最初给大家讲一讲前面整个云原生在边缘计算场景上，咱们有什么样的产品技术布局。

因为刚刚讲了，第一个就是很多业务从核心下沉到边缘的时候，可能须要去跟核心做一些协同，它没法脱离核心齐全在边缘就能够对外提供服务，可能须要和核心的管控服务或者信令服务做一些协同。当它的服务部署在多个边缘节点之后，它也心愿做一些协同。这样的场景下，咱们会联合 servicemesh 的技术，给客户提供云边、边边协同的产品技术能力。

另外就是弹性调度场景，比方分时调度，就是不同工夫片算力资源需要不一样，心愿依照不同工夫片动静调度进去算力资源，这样能够大大减少老本，或者某些场景须要跨节点容灾调度，咱们后续也会重点建设弹性调度的产品技术能力。

此外像 AI、推理，这些场景，须要对应的 GPU 容器实例，这个时候咱们也会在这个技术方向做一些技术的落地。此外，咱们也会针对不同场景的需要去打磨对应场景的解决方案。这是火山边缘容器团队在前面会做的一些产品技术布局。

接下来就是咱们火山引擎微信公众号、飞书交换群，大家感兴趣能够退出，有问题能够在外面问，咱们也会在外面进行答复，谢谢大家！