新形态助力Serverless容器快速落地原创

首先感谢一下室友的分享啊，室友开了一个好头，至于那个分享的精不精彩，我们就看今天有没有人睡着嘛，我在第一排，反正是没有听见呼噜声，所以应该还可以，所以我感觉我现在的压力也小了一点，然后希望大家也可以再接再厉保持一下，因为现在已经过了那个睡觉的那个时间了哈。呃。大家好啊，我是那个腾讯云TK service容器服务的产品负责人，我是陈明星，呃，很高兴今天有一个这样好的机会，能够在大在这里跟大家探讨那个service容器相关的内容，因为我今天分享的主题是新形态怎么助力service容器快速落地，我们之所以想要做这样一个选题啊，是因为其实我们呃，辉总也讲到了，是因为我们在实际服务客户的过程中，我们我们意识到service的价值传递其实已经做的很好了，包括在座的各位可能都已经听过或者是上手用过servicers的服务了，但是实际上呢，So在企业的落地仍然非常的困难，我们其实也深入的思考了我们这样一个原因啊，但是呃，并且我们在后续的产品设计里面也把我们思考的结论，然后融到了我们的产品设计里面，我今天呢会想要通过分享一款，呃。

呃，就是融合了我们思考的产品的，呃，Service容器服务的一个产品叫超级节点，来将我们做产品的思考分享给大家，其实今天的那个分享啊，我是希望大家有一些呃相关的service相关的一些经验，我不知道在座的有没有，呃有多少人维护过标准的K8S的集群啊，可以举下手吗？呃，然后有大家有有有真正用过service容器吗。

可以举下手吗？OK，我看感觉还还可以，就是那个，因为今天因为是希望通过从问题里面像那个带入到，然后带入到我们的产品设计，所以如果大家有相关的经验，可能会有一个比较深刻的体会啊。那接下来我们就开始今天的演讲，我会从五个方面带来我的分享。首先我们想要探讨一下service的需求是怎么样产生的，以及他在我们自研的场景下的一些成功的应用，以及在企业落地中的一些困境。为了应对这种困境呢，就是腾讯云是怎么从产品设计上去解决这样的一个问题，然后这种新形态的产品设计下面，我们是怎么保留service原有的一些价值，并且为它赋予了新的价值。此外我就会从我们的通用场景的出发，然后去介绍两个真实的一个案例。最后，因为今天是service加AI的主题嘛，我也想聊聊我们在service容器场景下运行AI类应用的一些优势。

好，接下来我们就进入第一个部分。其实随着云原生行业的普及，还有经济大环境的一个变化，企业用户其实对于基础设施提出了更高的要求，包括我们在GA的报告中也可以看到，在2025年，其实将有95%的企业应用会部署在原生平台上。在202022年，2021年，我们在服务的客户过程中也发现了我们大多数的客户其实已经直接选择了云原生上云的这种方式，并且对云原生的算力提出了一个新的需求。首先我们的客户是希望能够进一步的去降低他们的运维成本，然后提升他们的开发开发效率，去关注于自身的一个业务发展。

同时啊，面对那个复杂的一些用户行为，然后他们希望能够轻松的去应对突发的状况，然后保障一个业务的稳定，第三个就是在一个现在的大环境，就是大家都有一定的压力嘛，然后有一些降本增效的一些诉求啊，用户希望能够持续的去优化我们的运运运营的，呃，运营的成本，来塑造企业的长期的竞争力。嗯，所以其实在市面上有一个。有一个很好的解决方案出现了，其实针对这样的需求和趋势，行业给出的解决方案其实就是service容器服务，他全托管，然后自适应的弹性，按照按需付费的这样一个特性，就很好的契合了这样客户的诉求。在我们在其实在一八年的时候就已经推出了service容器服务，然后逐渐在内部的大规模进行落地，刚刚是有也有提到，其实腾讯会议通过使用service服务就已经实现了半个小时扩容十万多核规模，在疫情的期间，也就是呃服务了千万的客户，然后二三年至今，腾讯内部使用service容器服务的规模已经到了千万盒。

其实我们可以看一下service服务在在腾讯自研的应用的情况，其实最初自研大规模的去上service容器，其实有两个方面的原因，第一个考虑其实是稳定性的考虑，在标准的KS模式下，大家可能可能知道就是pod之间它是共享内核的，然后隔离性也天然就不足，然后有一些资源争抢的问题，因此带来业务的稳定性问题。

然后最严重的时候，我记得当时我们有一个专门的。就是负责内部自研客户接入的容器平台，然后他们每个月要接十几起的那个稳定性的工工单，然后业务也严重的诟病平台的稳定性，然后都不愿意签上来，然后这个是一个稳定性问题的大前提，然后第二个问题其实是从平台的角度出发的，就是呃，资源的利用率很低，在腾讯云的大盘上，大盘的碎片母机持有大量的碎片资源，然后碎片资源没有办法很好的去。利用起来，然后K8S集群本身的装箱率也不高，在保证，因为要保证业务的稳定性嘛，在保证稳定的前提下，资源的利用率的上限就天然被限制了。在这样的背景下。我们就选择了service容器的方案，让自研的业务全部都切换到service容器上，然后可以大家可以看到中间那个图，就通过呃，使用轻量化的虚拟化的隔离技术，然后我们用统一的调度技术和nonu的架构，不仅极大的提升了业务的稳定性，还解放了专门的节点运维。从平台侧的。

角度出发，呃service容器消耗了大盘差不多2000万盒的呃碎片资源，然后一年为整个腾讯云节省了五个亿，在服务自研的过程中，腾讯云service产品也快速的呃，产品能力也快速的成熟，同时解决了很多兼容性的问题，因为我们有很多就是千奇百怪的自研的业务，大概有100多个吧，就那个每个自研业务大概就是一个小公司，大家可以理解所有的小公司全部上到容器平台上，我们要解决的呃兼容性的问题，为了保证这些呃各种各样的资源业务能够无损的接进来，我们就体会到。

我们体会到S的容器啊，其实它是一个好东西，但是它能呃，它能够实实在在的去提升稳定性，还有帮助用户去降低他们的资源成本。但是啊，我们把这些在自研的场景中积累到的相关的经验，对于外面推广的时候却发现了瓶颈，嗯，他发现发现他在自在那个客户的场景中很难落地，用户使用的效果其实是跟预期不相符的，我记得我们在接入的时候，呃，大概是二一年的时候，我们有一家头部客户，其实当他们当时就是在一个激烈的行业竞争的状态嘛，为了加速他们的业务发展，需要快速的去响应用户的需求，去提升他们的经营效率，然后经过调研之后呢，他们就认可了service的价值，然后并且认同service的能力，然后决定去做这样一个大规模的使用。

但是立即他们就面临的一个问题，因为他们之前的那个架构比较老旧，然后他们的业务运行在多个KPS集群上，如果要切换到service集群的这种这种架构下，它需要新建service集群，实现跨集群的这样一个服务，发现配置同步，数据迁移，还有等等的日志啊，监控的解决方案的对齐，然后他们的对于他们来讲就是风险很大，然后挑战也很高，然后投入很多，当时耗时了数月，终于就是咔咔咔就把那个业务全部迁移到那个service的架构上面，然后决定深入的去使用service的特性，然后很快的他们就迎来了第二个问题，其实第二个问题主要是因为呃，Service的一个优势带来的就是service。其实。

嗯，全托管嘛，然后自主弹性，但是维护的维护的负担变小了，但是因为没有节点，他们不能登录机器，排账也比较困难，然后自动的弹性伸缩，虽然不用预购资源了，解决了buffer的问题，但是有弹性的突发扩容没有成功，就影响到了业务，然后他们又要退回到刚开始的那种手动的那种弹性的那个模式。然后到了一直使用，就是这样磨合兼容的使用，到了年年末的时候，客户又发现了新的问题，其实成本优化的效果也没有想象的那么好，那为什么呢？因为是service，使用service后，业务去随意的进行扩缩容，每一次业务变动会导致成本的变化，然后运维和财务对成本的控制力就变低了，然后最终导致，呃，就是service带来的成本优化的效果不及预期，甚至是不可控。这个就是一个典型的从service，传统的service，就是采用传统service去实现service架构的一个案例。service确实它能够帮助客户去提升他们的经营效率，优化成本，但是本身因为它的应用存在一个局限性，其实并不是非常完美的一个这样一个一个架构。

同时客户要转型的话，就天然面临了一个比较高的一个迁移的代价。嗯，我们希望的service是什么样子呢？就是用户可以很轻易的用起来，然后给客户创造收益的时候，不要为客户带来新的束缚，然后。其实对于企业而言，他们从标准的KS到service的架构是有一个巨大的鸿沟的，我们希望把这个鸿沟给他抹去，我们希望能够对service的形态进行重新的思考，让他更能够契合我们，呃，真正的企业客户。

其实，呃。句子我们可以畅想一下哈，我们畅想一下理想的so形态应该是什么样子的，其实我们期望它是超越现有的产品形态的一个局限的一个产品，因为我们其实刚刚是有分享了，也也有聊到，就是我们整个原生做so产品的理念啊，就是我们不希望拘泥于某一个既定的产品形态，而是想要聚聚焦于客户的业务，去真正的让客户能够使用起来。然后我们希望他不仅仅有service的优势，也有服务器形态的优势，我们希望用户可以轻易的使用，给客户创造收益的同时不要带来束缚。希望可以向我们理想的。

就是最终理想化的那个service一样去灵活使用，然后也可以呃成本可控，去能够稳定和弹性高效的去使用我们的service。嗯，腾讯其实呃就给了一个答案，其实我们叫它有节点的service，也是我们全新推出的一个产品形态，叫超级节点，它是嗯作为TK集群中的一个节点的类型，用户只需要在标准的TK class集集群里面去添加一个超级节点，就可以开启service容器服务的能力。这个标准的集群的意思啊，就是它是遵循标准的KS规范的，无论是呃，无论是云上的标准的集群，还是说云下的IDC的集群，呃，纳管的集群都可以去呃以这样的方式开启service的服务，我们去把任意规格的service容器打包成了一个超节点去进行管理和付费。

用户的使用，用户的使验，使用体验就比较像管理一台超级大的CVM一样，去管理我们的service的资源，他可以像像CVM一样购买扩容，保持有服务器的一个管理体验，但是呢，他们这个这个节点内调度的pod其实是一个子集，它实际上会直接将容器调到我们底层的so的资源池，然后其实是大家看到跟noe其实是持平的一个物理机上。然后同时去实现了无服务器的这样一个免运维的能力，而且支持有服务器形态下的一个管理体验，嗯，单个超节点上我们现在支持呃，5万盒的资源，然后在单个节点上我们也支持了混合计费的模式，可以去打包购买预付费的资源，也可以弹性使用后付费的资源。这样的设计有一些好处，我们可以在下面的内容中提到。

其实这样的形态有什么优势呢？在大家都知道，在标准的有节点的KPS模式下，节点的运维很复杂，弹性扩缩容的效率很低，其实资源争抢也导致了稳定性的问题。但是节点维度有一个好处，它就是它的管理是清晰可控的，它的成本核算也很简单。在传统的SRS模式下，迁移变得很困难了，成本也变得不可控了。但是它使用灵活，就。

就传统的note模式跟传统的service模式都各有优，优势也也各有劣势，在超级的这种模式下呢，我们期望去融合呃，传统no模no no，传统node架构的一些优势，然后去融合service的一个一个优势，然后减轻运维负担的同时啊去嗯。给大家带来了四个新的一个特性，首先其实在我们这个架构上可以做到自由切换，在兼容性和统一调度上我们去做了很多工作，能够让他拆掉迁移的门槛，让所有对so感兴趣的用户都能够无缝丝滑的从传统的架构自由的切换到service架构上，享受新service的技术。其次，这样一个节点的设计能够让资源管理和成本管理变得可控起来，我们进一步赋予了它任意维度一键启停的一个可观测性的能力。然后。

也没有像之前一样是一个黑盒的状态。最后一点是我们在稳定、安全性上所做的保证。这个是我们当前service的一些价值，然后新的这个形态是怎么样兑现service的价值呢？下面我从四个方面，就刚刚提到的四个优势，从四个方面向大家解释我们新的产品形态是怎么样兑现价值的。在前面的案例中，其实客户选service的容器的时候，最大的挑战其实不是本身能力的问题，是迁移成本的问题。我们发现大多数客户没有能够成功的使用service容器，是因为巨大的迁移成本导致的。比如传统使用service容器服务，它需要新建一个集群，然后迁移它所有的应用，还要考虑一些兼容性的问题，客户使用标准的传统的service容器里面是没有节点的嘛，因为没有节点，所以它天然不支持原生的，呃，比如说set啊，或者是特权容器，一些依赖节点的能力。

而客户使用标准的K8S的时候，往往又依赖这些特性，所以他们就没有办法去做到无缝的迁移。超级节点是集群中的一种节点的形态，所以它支持在任意的K8集群中添加。前面的图里面其实我们也有看到，只要标准的K8集群，无论是t ke的、IDC的、云上的注册集群都可以添加我们的超节点。然后这个节点的形态能够让service以一个呃一键加入的方式进到集群里面，那么我们的统一调度的能力就能够让呃，Service真正的。

让一个pod真正在serve和server，呃，Server for之间去做一个自由的切换，其实我们一直在思考，就是serveness到serve four到serveness，是一个a and b的关系，还是说是一个A货B的关系，其实最后解答的时候，我们发现它其实是一个and的关系，就是包括我们对统一调度的思考也是这样的，我们认为调度器其实是一个资源选择的方式，就是这个调度去会去选择那个对。无论是成本也好，或者是对资源的那个呃部署也好，是一个最优的方式，我们希望调度去起这样一个作用，而无论是调度的底层的资源本身是怎么样构成的，而调度是一个统一的一个规则，这个时候。

嗯，我们就在，呃。我们我们在标准，在那个标准的集群里面去做了统一的调度，能够让用户选择pod，在service和server中间去切换，然后。当然这个切换有一个前提啊，这个前提就是我们这个超级节点的兼容性跟标准的K8S是一致的，这种时候呢，Pod才可以，我们的业务才可以在这个不同的资源上去做漂移，然后我们针对于呃最佳的K8兼容性去做哪些工作呢？其实第一个就是呃，我们发现用户对DS的依赖比我们想象的更高一点，之前我们在做用户迁移的时候，发现他们总是因为set去有有有上云或者是有上service的顾虑，所以我们在KS上原生去支持了DEMO部署的方式。

嗯，特权容器还有更多的一些KS的特性，都是为了能够统一调度去去做的一个设计，就客户不需要任何的改造，只需要对po进行重建和调度，就可以完成service到serve的架构的切换，如果原来的，比如说他从原来的服务器调到service模式上，如果云服务器上有资源空闲，他又可以再调回去，然后。超级点去通过统一的这样一个调度技术，还有业界最佳的一个KS的兼容性，能够让企业去随意的选择service和service的资源，然后我们认为这个才是service能力真正应该去具备的，就是去随意的选择资源，基于统一的调度去给到最优的资源，这个最优的资源可能是成本上的最优，也可能是资呃资源供给上的最优。

第二个点其实。其实是管理上的，这个管理包含了运维的管理，还有财务的管理，在嗯，在超级节点上，我们希望让运维和财务的管理变得更简单和可控，呃，之所以会想要去做这样一个事情，主要是在传统的有服务器模式下面，我们通常需要去预估节点维度的一个资源消耗，用户的资源的使用也是不灵活的，有一些业务洪峰的时候，他们需要添加节点，然后拉起泡的扩容艰难，然后业务流量下去的时候，缩容的时候要去把节点退掉，然后节点上的资源需要全部驱逐才能去退还。然后为了保障业务的稳定性，在。

呃，用户不得不去提前去储备一些buffer的资源，然后就会造成一些资源的浪费，其实所以这种有节点的模式下的问题，导致了传统的模式的诞生，它解决了比如说资源浪费的问题啊，还有解决了使用灵活性的问题啊，但这种模式下，因为只能按照po的维度去规划资源和预算，对企业的运维啊和财务都带了很大的挑战。首先其实按量计费模式下，财务就不可控了，业务的变动就直接影响了财务的核算，业务没有使用，没有约束。其次就那个计费的对象从pod变成了呃，从那个node，传统node变成了pod，然后这个资源数量就膨胀了十倍百倍，其实带来了很大的管理成本。然后我们就意识到，其实传统的service中，资源管理的精细度与资源管理复杂度其实是相悖的，嗯，他们有一些不可调和的矛盾。

精细化的资源力度其实必然会带来沉重的管理负担。对此，我们其实将资源规划和配置管理上移到了节点的维度。指数级的降低了资源运维的复杂度。此外，我们将海量的pod进行打包去管理，同时在超级连上实现了全新的节点混合计费的模式，让资源管理灵活可控的同时又有最优的成本。业界常规的service，呃，通常是按需计费的嘛，按量计费的。前面提到的案例中，企业原本有数十个、数千个业务容器运行在数百台的主机上，迁移到service容器后，他们的计费对象从主机变成容器，计费模式也从预付费变成按量计费了，然后费用账单每个月膨胀了几万，膨胀到数十万条，业务的每一次发布都会引起成本的变化，导致成本失控。为了解决这样的问题呢，我们在超级点中实现混合计费的模式，既支持对超节点进行打包预付费，也支持对超出的那一部分啊进行按量计费。然后对于预付费和按量计费的规格，我们有配额的，配额的控制，在资源的实际规划和使用中，业务去对稳态的业务去进行预付费的配置，对。

与弹性的业务去进行后，呃弹性资源的配置，其实在这个配置到达一个平衡的时候，他其实就会拥有一个呃最优的成本。这个其实我们给他起了一个名字啊，叫黄金分割线，就是你使用每个月使用资源多少。去买包月多少买按量是对于你企业是最优的，其实这个是一个数学题，但其实很多企业客户是算不明白的，因为他们的数据是不断的变化的。

然后我们去做了一个能力。就我们会基于funos去基于你的历史附带去做一个呃，你的资源的一个呃观测，然后基于你不断观测的值，去帮你去计算这个黄金分割线，然后去。推荐这个黄金分割线，然后你可以去基于你购买的包月和按量资源的配合进行一个动态的调整，这个动态调整是什么意思呢？就你每个月可以调一次这个额度，但调这个额度并不会影响你实际在跑的所有的业务，它是动态无感的。嗯，我们不需不需要重建你的任何的业务。其实整个的设计我们是希望从呃在灵活可用的基础上去帮助用户能够进行最优的资源配比，然后能够达到成本最优，然后这个也是我们在财务管理，还有呃运维管理上去做的一些工作。

超节点的另外一个优势其实是可观测性增强，其实我们在前面有提到，嗯，为了快速的去应对市场的变化，企业往往会选择微服务的架构。但其实。微服务架构的改造，框架的维护，还有故障的定位，就对企业来讲有很大的一个负担，传统的service容器，它其实没有办法去帮用户解决这方面的问题，或者是他可以解决这方面问题，但是它的成本非常的高，他需要去额外的对接一些比如说可观的性的一些产品，然后去自己做一些这方面的能力。

然后我们超级点商就看到了这样的一个诉求，以及看到这样一个对接的问题，我们在超级点内置的unit agent内去集成了service的能力，然后我们能够让业务不需要任何改造就可以在任意力度去完成这个。呃，服务治理的那个能力的开启，然后这个细力度就是说我们可以控制到呃，Workload或者是po的维度去开启这个能力，然后我们在这个调节点上支持了四层和七层的可观测性，呃。而且四期层是分离的，然后治理能力也和观测能力都是独立化拆分的。比如说如果你想看各个word的之间的调用信息，可以去默认打开我们的四层的能力，呃，此时产生的性能开销很小，我们内置的就是内置的这个面比比传统的通过s car主的面性能要好40%以上，其实可以足以的支撑日常的开启。然后在一些特殊的调试，还有排账的场景中，我们也可以在破运行的过程中临时的去开启这个七层的能力，提供丰富的一个应用层的信息，辅助我们去发现和解决问题，然后在任务结束之后再关闭，这个过程完全不影响po的运行，不会带来额外的开销。

然后在超级眼中去内置的能力，其实是传统的service容器没有做过的事情，我们通过可以随意随意开关的一个设计，其实也是想要把这些呃产品化的能力能够以更低的成本带给用户，我们不希望用户使用了一个service产品之后，还要通过去呃技术性的去对接另外一些产品，才能够达到在呃一些可观测性的效果。

这个是服务的能力，最后其实我看大家其实也很关心，嗯，今天也很关心安全的问题啊，其实我也想额外强调一下安全稳定，其实保障业务的全方位的稳定，才能够让物，让用户没有后顾之忧的去放心的把业务放在云上，因此其实我们围绕稳定安全也做了很多的设计，其实可以说一开始我们就把安全放在了整体的架构的设计里面，在标准的嗯，有有服务器的KPS模式下，其实很易很容易发生资源争抢，还有容器逃逸啊，然后包括像网络安全，容器安全都是需要额外的自行集成的，然后不稳定也不安全。传统的service模式下，我们只支持了pod级的资源隔离，如果要想进一步提升网络啊容器的安全性，需要自行的集成一些相关的组件，相关的呃，云商相关的产品能力。其实在超级链模式下，我们通过了多维度的技术优化去实现了零干扰和零逃逸，也为业务带来了全方位的稳定。

这也是为什么当时自研的业务上到service之后稳定性有很大提升的一个重要的原因。在基础设施的安全层面，呃超级点其实依托于沉淀多年的强隔离的虚拟化技术，然后我们自研了一个容器沙箱叫黑了，嗯，这个沙箱的运行其实是完全不依赖嗯母机文件的，不依赖内核，然后也没有泄露的风险，比开源的一个沙箱是更安全的。然后在应用的安全层面，我们也无感集成了呃腾讯云的呃容器安全的服务，然后有数十年的安全服务经验去为业务的安全去负责。

嗯，在流量的安全层面，其实超节点我们后续通过无感支持零零信任网络去保障接入层的安全，包括我们在呃以EBPF实现单个pod的控制面网络和业务网络完全隔离，互不影响，这也这也对于我们网络的安全性做了一个很好的保障。然后在稳定性层面，超节点我们刚刚其实前面的架构里面也提到，我们单个pod对应的是独立的子机，其实资源是完全隔离的，然后业务间也是零干扰。刚刚其实。呃，通过落地上面的这些产品特性，我们逐渐突破了service容器落地很困难的这样一个困境，在过去两年我们也落地了数百家的企业客户，然后我在这里也想就各就我们典型的场景给大家介绍两个案例。

第一个是在线稳态的场景下，这个是呃，搜狐集团的案例，然后搜狐和手机搜狐在2021年的时候就已经规划切换到service容器服务，他们的诉求其实是免运维，然后降低成本，然后他们自上而下去推动落地的时候，嗯，最初。就进展很缓慢，遇到了运维团队，比如说呃，顾虑很多，比如监控日志啊，DS组件不兼容啊，然后业务团队他们无法接受他们核心业务的中断，然后财务团队也无法按照已有规范的审批预算和费用的问题，然后他们找到了腾讯，然后我们通过。

呃，Service的方案就是通过超级眼的方案，然后让运维团队并不需要在重建集群，而是在原有的TK集群里面去添加一个超级节点，然后他们用两人天就完成了整个架构的适配。然后并且将业务容器逐步的。渐进式的调度到超级点上来，实现了核心的服务零中断这样一个诉求。在成本上呢，客户同时使用了超级人的混合计费的模式，他们包月的部分对应文态的需求，按量的部分对应弹性的需求，整体成本大概降低了25%左右，同时他们的流程管理也变得很简单了，客户的财务主要是当时取得了客户的财务还有运维团队两边的认可，所以这个这个case还是很就是很有借鉴的意义。这个事其实因为因为为什么首先想讲在线和文态场景啊，就大家大家对于service有一个有一个误解，总觉得它好像只适合弹性的场景，但是其实service的稳定性啊，还有包括低成本的资源，其实对于在线稳态场景也依然的很适用，然后第二个在弹性场景下，其实超件对用户而言，它的价值就是免运维，然后弹性的成本很低一点，然后弹性能力很高效，在我们接入的客户中，其实比如说他有一些呃有规律的波风波谷业务的时候，就使用了我们呃弹性的呃service的资源，那它问题之前问问之前使用前的问题是什么，就是用户。

弹性伸缩很慢，然后扩容的稳定性也比较差，然后弹性伸缩慢，主要是因为它弹no的时候，因为要受首先起节点嘛，然后在节点里面去拉起服务，它弹性伸缩就会C会更慢一点，然后再。在在切到service架构之后，他们就不需要运维节点，我们也不需要首先启动节点，直接就弹出来就是pod，然后弹性的速度是提升了200%的，然后弹性伸缩效率也提升了，然后同时也提到我们架构的稳定性，也保证了他们业务的业务的一个稳定性，然后扩容之前因为扩缩容。

在运维手动操作的前提下，他们的扩容也经常的出问题，然后自从切到service的场景下，他们的扩容造成的稳定性问题就已经降到零了，然后包括在整个弹性资源的使用上，呃，通过合理的弹性资源配置之后，他们整体的成本是降低了30%左右的，就在高峰期的时候也不需要添加node，然后我们的极致的弹性伸缩能力去可以快速的扩容pod，保证用户的业务高峰没有受到影响，然后低峰期的时候就可以直接把这些pod销毁，相较于长之前的需要去呃驱逐业务然后退掉机器来说，这里是有一个很大的时间差的。

这个是弹性场景的一些呃落地案例，其实今天后续可能会有很多AI相关的分享，在现在大火的AI场景下，Service容器服务其实也有一些独特的优势。其实我们将AI的流程去进行了一个梳理啊，大概简单的可以划分成这几这几个阶段，然后各个阶段service容器都可以做一些事情，首先我们AI需要去提交一个任务嘛，在service容器平台上，呃，它的任务部署是很简单的，管理也很方便，我们也提供完整的教程去完成，用户在控制台上或者是通过么去部署常见的应用，嗯，让它的应用跑在S容器上面，然后在资源的创建层面，然后service能够保证用户部署批量任务的时候能够做到极致的弹性，在资源的供给上，我们支持1/6卡到八卡的多种的资源规格，以及多种的资源类型，比如TA100、A10等等不同的资源类型。然后在。

为在在资源的保障上，我们也在资源的稳定性上，我们为每个pod也提供了虚拟机级别的隔离，在完全无需运维底层GPU资源的前提前提下，能够稳定的享受GPU的服务，我们也额外支持了，比如说像坏卡检测，还有多破的帧，呃，通过rdma通信这些额外的能力来保证我们的。我们的训练是我们的资源使用的效率是很高的。

然后第三个就是镜像拉取，我们在因为AI的镜像一般很大，镜像拉取的时间一般耗时很长，这个时候如果是呃。呃，需要光是拉取镜像其实就要耗费很久的时间，嗯，在超级上我们的支持了账号维度的全域的镜像缓存，然后通过去提前把制作镜像缓存下来，然后训练过程中可以直接使用镜像缓存，然后有一个免拉取的能力，能够呃极大的降低训练时长，这个经验缓存还支持呃自动更新，然后也能够降低训练的时间，节省我们的成本。呃，在业务启动阶段，超级点上GPU pod是按pod申请资源付费的，整个业务是独享申请的资源，可以做到强隔离，保障业务的稳定运行。在整个运行的过程中，我们也支持可视化的一个监控指标的，然后可以清晰的看到业务的状态以及资源的消耗，最后我们的pod是按量计费的，业务完成训练去释放资源，Pod秒级销毁，然后计费就停止了，然后这个也无需要再进行资源的退还，没有资源浪费。

当然如果是想要长期的持有这个这部分GPU的资源，我们也支持预留券的包月模式，不仅能够降低按量使用的成本，也能够灵活的进行资源抵扣，这个就是我们在AI场景下的一些应用，呃，以上就是今天带来的所有的分享，嗯，感谢大家的时间。