阿里云容器计算服务ACS ，更普惠易用、更柔性、更弹性的容器算力-阿里云开发者社区

【阅读原文】戳：阿里云容器计算服务ACS ，更普惠易用、更柔性、更弹性的容器算力

本文整理自瑶靖、智清在2024年云栖大会的演讲

更普惠易用、更柔性、更弹性的容器算力

ACS是容器服务团队面向Serverless场景推出的子产品。它基于K8s的使用界面，提供符合容器规范的CPU及GPU算力资源。容器算力交付模式为 Serverless形态，您无需关注底层节点及集群的运维管理。只需要按需申请使用，秒级按量付费。

我们期望打造更普惠易用、更柔性、更弹性的新一代容器算力，简化企业上云用云门槛，加速企业的业务创新。

ACS面向不同业务场景，定义了新的容器算力类型和算力质量，便于客户按需申请使用。

在在线业务场景，如微服务应用、Java web网站应用等，这些业务本身存在波动性，ACS推出了通用型容器算力；对于性能要求更高的业务场景，如高性能网关服务、游戏服务器等业务，ACS推出了性能更强劲的性能型容器算力。帮助客户更从容应对流量变化，提升业务稳定性。

那么在离线业务场景，如大数据计算、批处理任务等，这些业务本身具有容错性，ACS提供更经济实惠的BestEffort算力质量。帮助客户更充分利用潮汐算力，缩短计算任务排队时长，同时降低整体成本。

在客户的使用ACS的过程中，只需支付应用所实际消耗的容器算力，没有集群管理及核心系统组件费用。可以真正实现按需灵活使用，按秒计费。在客户典型业务场景下，最高降低55%的综合成本。

BestEffort取名和设计思路源于K8s原生的QoS等级定义。使用BestEffort算力质量申请通用型容器算力，对应性能基线与通用型保持一致，但是带有驱逐及驱逐前的事件通知。它的定价更便宜，价格是直接用默认算力质量申请通用型的20%。

在成本敏感且具有容错性的离线业务场景，如仿真计算、科学计算、批处理、持续集成等业务场景，更具性价比。

由于BestEffort库存有限，ACS也在集群的编排调度层，提供了灵活的策略支撑。比如，成本最优策略，支持单Region多AZ级别，更大范围寻找BestEffort 容器算力，降低您整体的成本。同时也支持灵活保障策略，优先调度BestEffort，如果无库存再降级为默认的算力质量，保障客户的业务正常运行。

除了默认按需使用，按量付费的普惠，ACS也为长期稳定运行的业务场景，创新性提供了按天承诺的节省计划。可以更好承载天级别的潮汐业务负载，避免业务波谷期间的成本浪费。

在之前节省计划或者包年包月的节点，本质都是按小时承诺消费，存在大量成本浪费。以左图小时级别的按量账单为例，蓝色柱形图是我们一天24小时的按量消费，潮汐现象非常明显。在夜晚0点 - 8点的消费金额会偏低，在白天8点后消费金额会偏高。我们以绿色的这条线作为节省计划消费承诺，可能存在绿色线之下的夜晚过渡承诺消费，客户没有实际按量业务，还需要支付对应的承诺消费金额；或者绿色线之上的白天，过于保守承诺，节省计划的折扣权益无法覆盖白天的按量账单。如果以绿色的这条线为指引，把按量付费的节点转成包年包月的节点话，也会遇到类似的问题。

为了解决这些问题，ACS提供了按天承诺的节省计划，可以看右边这幅图，ACS以24小时账单汇聚成天的账单，天级别的潮汐现象就不明显了，按天承诺覆盖的按量账单更多，相比之前更具经济性。此外，承诺消费金额可以同时抵扣通用型、性能型的按量账单，不锁定固定实例类型或者固定实例规格。相比包年包月，更具灵活性。

目前，ACS节省计划的一年全预付是5.7折，让您更经济、更从容应对业务的潮汐。

在对静态应用负载的供应维度，ACS提供了更精细化的步长，更匹配应用的真实需求。

之前客户使用偏计划经济，上云用云前需要提前业务评估，提前购买1:2 1:4固定规格的VM，但是固定规格无法满足多样负载的灵活需求，很容易存在资源浪费。现在更像是市场经济，您只需要面向应用编程，显示申明对应用的资源需求，由ACS来为您的应用量体裁衣，提供最适合的资源供应。

ACS支持从0.25 vCPU 0.5 GiB起步，0.5 vCPU 1 GiB起始及步长递进。紧贴应用负载需求，降低资源浪费，以及规格评估复杂度。

但是随着时间的变化，应用负载的需求都是动态变化的。为了更柔性供给资源，ACS也提供了按需热变配能力，帮助您进一步降低资源浪费。

这里有两个关键点，一个是热变配的原子能力，ACS 支持秒级热变配，并且变配过程不中断业务；第二个点是自动化的按需热变配，ACS支持基于应用状态的实时检测，实现自动规格变更。我们在两个场景做了自动按需热变配的能力增强。

第一个业务场景是Java应用启动加速场景，Java初始化会消耗较多vCPU，而稳定运行后vCPU消耗会减少。为了避免流量损失，客户往往会调大CPU的资源分配确保Java启动加速，但运行后无法调小规格导致资源浪费。

目前ACS支持基于应用运行状态监控，在应用启动后自动降低CPU规格。

后续ACS也将支持应用在运行过程中，基于 CPU/Mem利用率等Metrics指标，实现原地VPA，并且VPA过程中不会重启Pod实例。以更柔性容器算力供给，保障游戏业务/中间件这样的有状态应用，同时降低资源成本及运维复杂度。

除了垂直方向的按需热变配，在水平伸缩方向ACS也提供更确定性的弹性体验。

基于阿里云的大弹性计算资源池，ACS支持对用户负载特征的预调度优化，可以实现单Region每分钟1万Pod的大规模弹性。

同时也内置了更灵活智能的弹性伸缩策略AHPA（advanced horizontal pod autoscaler），支持基于客户历史数据信息拟合，提前预测业务趋势进行扩容，避免弹性滞后性。

超大规模容器资源池的技术体系建设

ACS是基于国内最大规模的弹性资源池打造的、领先的容器算力解决方案。

首先，让我们关注ACS算力的基础，这就是安全合规、遍布全球、国内最大容量规模的阿里云云计算基础设施。

ACS已在中国地区公共云所有Region全面开服。

ACS基于阿里云云计算基础设施基座，完全复用阿里云超大规模的弹性计算大资源池。这也意味着ACS接下来将逐步覆盖阿里云遍布全球4大洲的数十个公共云地域，近九十个可用区等。

这样庞大的ACS算力规模为我们的客户提供了无与伦比的全面地域覆盖，也确保了客户使用ACS算力时，所需要的高韧性、多可用区、多Region的高可用性诉求。

让我们来看看ACS如何解决传统自建IDC和自建资源池面临的挑战。

ACS基于超大规模容量的阿里云资源池。这使得ACS相比客户自建体现出非常明显的优势。

企业在自建模式下，往往面临两个主要问题：日常闲时资源闲置，以及峰值时期的资源不足。

闲时资源闲置：在日常使用中，自建资源池往往需要保留大量闲置资源，这不仅占用成本，还可能导致资源分配的复杂性增加，需要建设复杂的的资源运营、资源运维能力、甚至是混部调度能力。

峰值资源准备：在流量高峰期，用户通常需要进行大量的节点规划和弹性准备，这个过程不仅耗时，还存在不确定性，一旦高峰结束，冗余节点又需归还，复杂度高和低效。

基于超大规模容量的阿里云资源池，ACS实现了：

第一个点是：按需供给。使用ACS的超大规模容器弹性供给，按需满足业务峰值流量，降低综合成本。

第二个点是：面向峰值和突发流量的高效弹性。使用ACS基于用户负载特征的预调度优化，秒级扩容，应对业务突发流量。

总之，ACS能为用户解锁阿里云超大规模弹性资源池的优势，从而规避自建带来的诸多难题。无论是安全性、合规性，还是弹性能力，ACS都将帮助企业轻松适应和快速成长。

一般而言，企业的负载是多样化的，有微服务、数据库、大数据应用、AI任务等，这些负载对计算资源的需求是多样化的，包括CPU、GPU、NPU、RDMA 等，同时，业务的优化目标也是多样化的，比如微服务应用关注长尾延迟，大数据应用关注吞吐效率，AI 任务关注拓扑结构优化。

企业管理这些负载的过程就是资源调度，而这其中的调度算法实际上就是在求解这个NP问题的解，这个过程是非常复杂的，尤其是对容器有相当投入的企业可以在这其中寻找到自己的“最优解”。

而在ACS上，我们可以充分的看到不同企业的工作负载，也可以调配整个阿里云的算力资源，企业看到的“最优解”在ACS的视角可能只是一个局部最优解，而 ACS为用户提供的就是整个阿里云算力池范围内的最优解，这可以为企业在成本、效率以及应用稳定性上带来优势。

如果说调度是解决静态空间上的最优化问题，弹性解决的是时间尺度上的最优化问题。

在阿里云的超大资源池上，ACS为用户提供了Pod秒级拉起以及10000 Pod每分钟的弹性吞吐能力。

ACS根据用户的历史购买情况智能的预测用户的资源需求，为每个用户提供智能的、适配用户个性化诉求的弹性Quota保障能力，以最大化的满足用户的弹性资源诉求。

在底层，ACS通过智能的库存引擎来管理用户的资源需求，引擎根据动态库存情况以及用户的资源需求预测来调整资源的供应，让百万级物理机资源充分的使用起来，为用户提供充沛的算力供应和弹性的确定性。

使用ACS，用户最直观的视角，就是基于K8S API来使用ACS算力。

背靠阿里云海量弹性算力，ACS产品也致力为用户提供丝滑体验的K8S编排层，以及近乎可能“无限”弹性的容器算力交付层。

首先，ACS算力围绕K8S API构建交付和运维服务，ACS K8S集群服务与容器服务ACK产品集群托管服务深度集成，而ACK作为一直以来Forrester容器企业平台评测全球领导者，服务于众多企业客户，也经历过超大规模应用场景检验。在ACS中，应用开发者也无需过多关心K8s集群容量、性能、安全、稳定性等问题，这背后ACK、ACS针对K8s管控组件、etcd存储和容器网络，在保障原生K8s API兼容性的前提下，做过大量的性能调优改造和可用性风险加固。

关于ACS算力层，最核心要解决的问题是交付效率、交付吞吐、安全隔离、算力接入层架构的高可靠性、支持客户多可用区等助力客户高度韧性使用ACS算力的机制。ACS算力层面向用户屏蔽更底层基础设施，无缝对接多元异构算力，用户可以通过配置，灵活声明资源需求属性，ACS算力接入层快速编排、调度响应资源交付。它背后的支撑是从资源调度到生产策略优化的端到端链路打磨，从异步链路改造、预调度、多单元部署架构等多方面来实现。

柔性容器算力与技术揭秘

接下来是ACS推出的柔性容器算力与技术揭秘。

容器的算力类型丰富和具备多样性。

常见的容器算力类型包括延迟敏感型、批处理型、高吞吐量型、IO密集型、计算密集型等。

不同类型的工作负载，对算力的诉求不一样，这包括计算性能诉求、算力性价比诉求等众多诉求。

例如：在线电商交易场景是lantency sensitive业务，对延迟敏感，通常的做法是多副本多AZ冗余以确保稳定性，它能接受常规的算力价格。

而大数据批处理型的典型特征是利用率高、但延迟不敏感；也正是因为对延迟不敏感，大家普遍期望它的成本极低。业内的混部技术也都是为了达到类似的目的。

针对高吞吐量型，诉求是单位时间的多路并发量，它可能对单路请求瞬时延迟不敏感，这类业务对底层CPU的运行机制或硬件诉求会不一样。

IO密集型则对IO的输入输出有较多诉求，它对应的是对容器存储的诉求。

诸如科学计算等计算密集型，则对CPU的代数性能有较高的要求。

多样化工作负载的背后，是复杂的算力池建设、硬件供给、与差异化工作负载的技术适配差异。以及这些不同工作负载的混合部署对客户来说也具备较大的技术挑战。

ACS为客户提供了极简的算力定义，并结合不同的算力QoS。包括实例定义：通用型、性能型；算力QoS：Default默认型、BestEffort型。

通过不同的组合和搭配，客户就能极简、快速地满足差异化特征负载对资源的多样性诉求。

传统的serverless算力缺乏柔性能力，我举两个例子来讲解容器用户所受到的挑战，我相信大家在日常工作中本来就会深有体会。

第一个例子是：

通用类场景，我以大家正广泛使用的Java类应用为例。

部分JAVA类应用，存在着启动慢，弹性慢的问题。

我们来看Oracle在JavaOne大会上展示过的一个典型Java应用的启动阶段。可以看到Java应用在启动阶段需要经历类加载，字节码编译和优化的一个显著的阶段，这个阶段对于一些复杂的应用而言，可能要持续分钟甚至十多分钟的时间。

在这个阶段Java应用有超过一半的资源使用，都是在执行非应用代码的加载、编译的逻辑。在应用预热完成进入稳定运行态后，会有一半以上的资源可以空闲出来。

使用容器的JAVA客户，就会处于两难的困境。要么是扩大容器规格，保证应用的启动时间，但扩大容器规格意味着启动后需要持续付出运行时资源闲置的成本。另一个思路就是降低规格，但是需要付出启动慢、弹性慢的代价，实际上这会降低业务的稳定性。总之就是鱼和熊掌不可兼得。

尽管Java社区对于Java应用启动慢，进入峰值性能慢的问题，也提出了非常多的解决方案，但都有一定的限制和使用代价，例如对于JVM的版本有更新的要求。再比如，在容器领域，Java社区也提出了提前编译的技术想法，希望将JVM的启动工作，提前到编译阶段执行。但是AOT相对于更广泛使用的JIT技术而言，在峰值性能上可能存在明显的劣势，因此在使用上有很大局限。

第二个例子是：

对于一些带内存状态的应用，例如存在缓存、存在较长运行时间的任务、或者存在网络长连接的应用，客户在使用serverless容器弹性算力时，也会处于两难的困境。

在应用闲置时，客户为了降本就会去缩容，但缩容可能会导致运行的任务中断，例如终端服务用户的网络连接被断开这样的问题。也就是如果应用的优雅下线方式不是非常完美的话，就会非常影响终端用户的体验、以及重跑任务时算力的浪费；

而在应用负载升高时，如果要通过水平扩展的方式来触发弹性扩容，新创建的Pod往往需要分钟甚至更长的时间来预热，包括加载缓存数据等；未经充分预热的实例还会造成应用响应的高延时，从而导致用户体验的恶化，流量的损失，甚至有可能导致集群的雪崩。

ACS提供柔性的算力，能非常好地解决上述问题。ACS柔性算力，不仅支持灵活精细的规格配比，也支持实例规格的原地热变配基础能力。基于这个基础能力，ACS新提供了应用启动加速、应用自动变配的产品能力。

通过应用启动加速，我们可以在应用实例创建的时候为实例分配更大的CPU资源，从而提高应用、特别是Java类应用的启动速度，并在应用启动后完成后，通过热变配将实例规格降配到应用正常运行所需要的规格。

应用启动加速功能也可以结合水平弹性技术，提高应用弹性的效率；

通过自动变配功能，可以根据应用的资源和业务指标，根据预设值的变配规则，对闲置的应用实例进行原地热降配，从而降低应用资源成本，对负载较高的应用实例进行原地热升配，保证应用的稳定性；也可以按规则进行原地升配，以应对流量增长。

对于有状态应用，以及包含缓存、长连接，包含较长任务处理的无状态应用，水平弹性往往无法满足业务的稳定性和弹性速度要求，自动热变配技术的帮助会更大。

应用画像对柔性规格的推荐也有非常大的帮助，在后面的内容我会展开描述一下。

特别的，对于Java应用，还可以借助JVM的检查点协调恢复技术（CRaC），在应用启动的时候做一个快照，从而保证在应用进程崩溃重启的时候，也能够快速启动；在实例启动的过程中制作独立的快照，相比在构建时制作快照，也可以有效地规避机型等环境配置带来的快照不兼容的问题。

ACS容器柔性背后的技术支撑，是融合基于神龙CIPU高性能计算、龙蜥OS的内核变配支持、内核级算力柔性超分、热迁移，进而为用户提供极具性价比的容器算力。

为什么说“Serverless容器是开启算力柔性的捷径”呢？

ACS通过龙蜥轻量容器OS，从虚拟化、内核、驱动紧密兼容支持热变配，相对用户自己在ECS上或物理机上构建热变配能力，极大降低地实施的复杂性。

ACS基于CIPU软硬件协同的热迁移底座，包括直通设备的容器原本是不支持热迁移的，但我们通过CIPU自研软硬件系统解决了直通设备的热迁移，以及跨多种hypervisor平台上互相迁移，以及自适应热迁移，根据负载情况做迁移参数的调整、以降低迁移的性能损失和迁移时长。通过强大的热迁移能力，进一步提升柔性变配成功率，过程中也让用户无感。而这些都是用户自建时很难做到的。

自研的cpu调度器和内存管理系统是弹性cpu和弹性内存的基座，这两项技术提升了单机资源利用效率，从而降低算力成本，再结合ACS管控引入的一些公摊机制，实现了单机对资源的最大化复用，并实现了指数级降低ACS各类overhead开销的同时，依旧保持好的性能。这也是我们对ACS客户交付可见即可得算力的技术基础。

基于这些技术，神龙CIPU实现了阿里云ACS容器的算力交付。也包括为ACS实现的通用型、性能型算力供给，以及更进一步的ACS容器不同算力QoS定义。

ACS充分复用ACK infra包括Finops成本套件的能力，为用户带来成本洞察、成本优化、成本控制三大产品能力，帮助用户优化云资源的使用成本。

成本洞察，ACS为用户提供资源使用分析、费用分摊报表、费用趋势预测、预算配额管理等工具，帮助用户对企业资源使用情况有一个全方位的掌握，企业可以根据成本洞察能力提供的费用支出预测，来提前规划预算，降低预算偏差，控制成本支出。

这里的重点在于讲解应用画像。应用画像为客户智能推荐更合适的容器规格，这些建议也将帮助用户更好地使用柔性，从而实现更高效的降本。

和ACK类似，用户在启用应用画像后，koordinator组件将根据工作负载的历史运行，做资源使用的智能预测；

ACS根据智能预测生成画像建议，智能推荐建议的容器规格，比如这张图中的建议降配、建议升配。

客户可以根据画像推荐的规格，调整工作负载的资源配置，确保应用运行在最佳的资源规格上，避免资源规格配置过大造成的成本浪费，以及资源规格配置过小导致的稳定性风险。

ACS产品技术能力

客户视角这里是体现了ACS无缝集成了阿里云生态、易用免运维的容器基础设施。

大家都知道，以容器为核心的云原生技术已经极大简化了应用开发、部署和运维的复杂度，K8s API对IaaS层的抽象，使应用开发者真正可以做到面向目标编程，然而在API之下，仍然潜藏着不可忽视的“冰山”，包括：

整个基础设施生态的建设和运维，从应用运维，到K8s集群，到存储、计算、网络，再到节点、OS，要全部满足业务生产对可用性、成本、安全、性能的要求，需要端到端技术储备，且有丰富的运维经验，而为此就需要付出大量人力和时间成本。

ACS产品的其中一个核心价值即“无服务器”化算力交付，企业及个人开发者，可以最大限度的专注于应用开发，K8s API及以下交由ACS做托管运维。

面向应用开发者，ACS提供基础设施全托管服务，使开发者只需简单配置，即可通过标准化API体验基于ACS产品的Serverless容器整套阿里云解决方案，同时享有高可用性、安全、高性能、极简运维的极致产品体验。

ACS充分复用阿里云容器服务近10年积累的技术优势，充分无缝集成阿里云生态，利用Kubernetes API扩展机制，与十几款阿里云产品无缝集成，形成完整Serverless Container阿里云解决方案。

ACS产品覆盖计算、存储、网络、可观测、应用管理等维度托管16个核心组件，托管组件用户无需关心部署、升级、版本管理、容量、安全、性能等所有运维操作过程，复杂度由ACS全托管。

托管组件也支持自定义配置，例如今年新增的CoreDNS配置能力，可通过组件配置来定义更灵活的自定义配置。

ACS集群服务基于ACK Pro集群托管服务核心能力，包括K8s master性能、自运维、安全风控等。

基于阿里云的弹性计算资源池，ACS在资源交付、容器环境部署和镜像拉取三个方面进行了深度的优化，为应用带来极致的弹性效率。

在资源交付链路，我们采用了MicroVM技术减少虚拟化的开销和启动耗时，实现秒级的容器启动。

在容器环境部署链路，Serverless Pod相比传统k8s架构避免了用户视角的购买节点，加入集群，部署节点管控组件的冗长流程，用户对资源的使用做到即用即走，彻底解决了CA弹性场景节点部署效率带来的体验问题。

镜像加载我在后面会专门展开讲解。

在弹性控制链路上，ACS为用户提供丰富的弹性伸缩策略，包含HPA、CronHPA、AHPA、VPA、基于KEDA事件驱动的弹性伸缩等，充分满足企业应用差异化的弹性诉求。

ACS在Serverless k8s领域内，最大化的兼容了社区k8s的调度语意，比如k8s社区的AZ亲和性调度，AZ拓扑打散等原生资源调度能力，满足应用的运行效率、高可用等诉求。

在大数据任务调度领域，ACS为用户提供了增强的co-scheduling/Gang调度，Capacity调度等，满足Spark，flink，tensorflow等任务调度场景的诉求。

原生的调度能力叠加上增强的任务调度能力，可以支撑企业的绝大多数微服务、大数据计算应用等。

ACS为用户提供了ResourcePolicy以支持灵活的资源调度编排，通过ResourcePolicy可以实现灵活的库存调度，比如：

1、可以配置优先使用可用区A的资源，在A资源不足时再使用B可用区的资源。

2、可以配置优先使用普通的按量类型资源，不足时使用BestEffort类型资源，以获得最大的弹性空间。

3、可以配置优先使用BestEffort类型资源，不足时使用普通的按量类型，从而获得极致的资源成本优化。

在AIGC时代当下，企业用户对异构计算资源的需求越来越大，ACS针对AI负载设计了非常丰富的优化调度策略，满足AI负载的运行需求。比如：

1、针对AI场景典型的Master/Worker架构设计了增强的Gang调度能力，满足pytorch/tensorflow任务的联合任务调度的诉求。

2、针对单机多卡的推理、训练场景，设计了针对GPU pice/nvswitch拓扑的优化调度策略，提升Pod的运行效率。

3、针对多机训练和推理场景，设计了优化的网络拓扑感知以及任务的rerank调度优化策略，提升任务内的集合通行效率。

在k8s应用层，ACS与社区典型的Kubeflow/kubeDL AI任务框架保持高度的兼容，满足企业级AI任务调度编排的能力。

ACS支持了多种业务接入方式和公网访问方式。特别的，对于7层的接入，ACS的应用市场提供了nginx ingress，适用于依赖开源生态和构建多云的用户；ACS的组件中心里也提供了阿里云的7层网关产品，包括应用型负载均衡ALB，MSE云原生网关。

其中ALB Ingress基于阿里云洛神平台，网络流量基于VPC和ENI弹性网卡直通，具备高性能自动弹性的特点；MSE云原生网关基于阿里云开源的Higress企业版，适用于微服务场景，新增的serverless实例会按请求量计费，对于中小规模使用成本更低；

ACS支持多种服务发现方式，特别的，在域名解析方面，ACS不仅支持托管的CoreDNS，也支持非托管的CoreDNS。托管CoreDNS组件降低了用户使用和运维成本，ACS新增强了CoreDNS支持upstream等常见的自定义配置，增强了用户的可定制性，适用于大多数用户的使用场景；而非托管CoreDNS支持用户对CoreDNS配置的完整定制能力，适用于对CoreDNS有非常大定制的使用场景。

在基础设施层面，ACS新增了IPv6的支持，包括了IPv6的私网和公网访问能力；

在网络运维和可观测性领域，新集成了阿里云开源的KubeSkoop，能够提供更多的深度网络指标，可供用户排查网络相关的问题。

ACS的实例默认包含免费的30Gi临时存储空间，并且最大可以配置为512Gi，另外，对于大模型等镜像非常大的应用，ACS支持为实例开启独立且自适应的镜像存储空间，保证应用可用临时存储空间的确定性。

ACS实例提供的临时存储IO性能接近于PL0级别的云盘，可以满足微服务日志读写等通用的场景。

如果客户有更大的的存储速率的要求，或者存算分离的要求，客户可以自行为实例配置块存储作为云盘。

云盘也新增支持了Autopilot能力，也就是能够根据配置，自适应地调整云盘速率，以满足应用性能突发的需求。

另外，云盘正式支持了云盘快照功能，可以支持为有状态应用做存储的备份，或者存储的变配。

ACS也支持了其他ACK集群支持的存储选项，包括oss对象存储，以及NAS和CPFS这类共享的文件存储，可以满足高性能计算、深度学习，数据/模型缓存等场景的需求。

基于云盘的扩容和快照能力，大家也可以借助我们开源的OpenKruise，提供工作负载级别的云盘扩容以及编排操作支持，大幅简化有状态应用的运维。

ACS为容器镜像拉取也提供了完善的镜像加速产品能力。

大家都知道，在AI大模型时代，一个容器镜像超过30-40GB已经是非常常见的事情。即使在网络带宽相对稳定的情况下，我们拉取一个40GB的容器镜像的时间开销也需要花费20分钟以上，这个极大降低了容器弹性的效率。这个效率在实际生产中完全不可接受。

应对这些更高要求的场景诉求，ACS提供了完善且丰富的镜像加速能力。

针对三方公开仓库或者是三方自建仓库，我们提供了镜像缓存和P2P数据分发的加速机制。但我们更建议您使用阿里云的ACREE。

镜像缓存能提前在ACS集群内做好镜像的预拉取工作，保障了在应用弹性时镜像拉取效率的确定性。

集群内P2P的数据分发能力有效降低了镜像仓库的数据拉取的存储网络的压力，减少了网络带宽与流量成本。

ACS还提供了镜像按需加载的加速能力。镜像按需加载的使用，无需让你增加额外的资源成本；尤其是通过镜像内容索引的方式来实现镜像数据的按需加载，既平衡了镜像拉取的效率，也折中了资源成本的开销。

结合业务更好地使用ACS

第1个例子是使用ACS算力构建企业级复合应用。

在这个例子中，企业有长在线Web、微服务、离线作业、mysql、redis等复合场景。

用户使用ACS提供的极简资源模型，定义不同实例类型、不同QoS组合，例如：长在线web、微服务负载需求选择通用型，mysql、redis、网关业务选择性能型，大数据批处理任务选择成本最优的BestEffort。

更进一步：大数据业务可以使用成本优先策略，优先使用极致成本的BE实例，当资源不足时降级至默认实例。在线业务可以使用库存感知资源策略，根据库存健康度自动切换可用区。

从企业整体而言，无需对企业内的算力使用进行削峰填谷，也无需在离线、离在线混部，使用ACS供给的算力即可达到最优的成本和性能模型。

第2个例子是ACK使用ACS算力。

业务已经整体上云并使用了ACK，此时使用ACS算力来满足业务的弹性需求。结合弹性、使用极简极灵活的网络存储配置，来应对业务波峰和突发流量。

另外一个典型的业务场景是企业内有差异化安全隔离等级的需求。例如业务部门涉及到资金，或者面向外部客户，需要做强隔离。此时客户不需要新建独立资源池、也不需要引入复杂的裸金属和安全沙箱技术。直接使用基于安全沙箱的ACS容器算力技术，对不同工作负载可以设置不同的VPC和安全组，配合网络策略（NetworkPolicy），可以在同一个集群内提供安全强隔离能力。