大降本时代开启，谁来关心企业的云原生落地难题？

在云原生技术的发展历程中，我们正站在一个充满争议的转折点。过去几年，经济形势和市场环境的剧烈变化让大批企业改变了对创新技术的态度。曾几何时，新概念和新技术的涌现似乎总能轻易赢得企业的追捧，但现在，企业对这些炒作已经逐渐祛魅——他们的关注点直指一个核心问题：这些产品或服务，能否为我们带来成本的降低和利润的提升？

一个典型例子就是 Kubernetes。今年是 Kubernetes 诞生十周年，过去十年来业界见证了这一开源容器编排技术从羽翼未丰走向了一统天下，而 Kubernetes 的成功也印证了开源已成为 IT 行业最具影响力的技术潮流。

很多人曾认为 Kubernetes 是云原生的银弹，选择了 Kubernetes 仿佛就告别了上云的一切迁移、设置、运维难题。但随着 Kubernetes 愈加复杂，抱怨这一技术门槛高、不易用、投入巨大、回报缓慢的声音也越来越多。由 Kubernetes 与大热的 Serverless 结合而生的 Serverless Kubernetes 同样经历了开始备受瞩目，之后受到质疑的过程。无论如何，创新技术都必须向用户证明自身存在的价值。在这样的背景下，已经开始有云厂商瞄准企业最关注的成本痛点，试图对 Serverless Kubernetes 技术进行改良，推出能够满足用户当下迫切的降本增效需求的云原生产品，为产业探索一条更符合实际的升级路径。

技术趋势足够诱人，但仍需理性看待 Serverless Kubernetes 的落地

自云原生的概念诞生伊始，行业的目标就是尽可能地剥离云应用中的非业务代码，聚焦功能性业务，高效打造敏捷、智能的云计算服务，同时满足用户和应用程序对规模、可用性和敏捷性的需求。基于这一目标，行业诞生了容器化技术，以及可以自动部署、扩展和容器化应用程序的 Kubernetes 容器编排平台，使这些程序以容器为载体运行在多种类型的云端资源上。当前，基于 Kubernetes 的容器已成为云上新一代应用的主流载体，包括中间件、数据库、AI、大数据等各种类型的负载都在向 Kubernetes 迁移。

但随着 Kubernetes 承载的需求类型和规模不断扩张，其复杂性已经飞速增长到了很多用户和企业技术团队难以应对的水平。例如，Kubernetes 日常版本更新频繁，运维负担沉重；配置选项和功能丰富，令运维管理复杂度进一步上升；云端集群缩放困难，应对突发流量需要准备冗余资源；库存管理与调度装箱专业性较强等等。

这些因素共同推高了云上应用的成本，影响了企业的利润和竞争力。正因如此，行业在数年前就开始了基于 Kubernetes 实现 Serverless 架构的探索，Serverless 的出现，提高了容器应用部署的敏捷度和弹性能力，也被公认为是下一个十年的发展方向。

目前，基于 Kubernetes 实现 Serverless 架构是业界的主流路径，很多云提供商都提供了 Serverless Kubernetes 产品供用户选择。与 Kubernetes 相比，Serverless Kubernetes 可以让用户减少对基础设施的关注，聚焦业务应用本身，使企业用户进一步提升运维效率的同时，可以将宝贵的资源更多投入到业务层面。从宏观视角来看，Serverless Kubernetes 也更接近“打造敏捷、智能的云计算应用”的云原生目标，有望成为未来云原生领域的用云新范式。

然而，虽然 Serverless Kubernetes 解决了 Kubernetes 存在的很多问题，向着云原生的最终目标又前进了一大步，但企业决策层在当下更重视能够快速获得回报的技术升级方案， Serverless Kubernetes 要吸引企业用户的广泛认同仍需要跨越最重要的成本门槛。

8 月 21 日，阿里云飞天发布时刻正式商业化发布了容器计算服务 ACS。阿里云 ACS 是一款以 Kubernetes 为使用界面的容器服务产品，算力交付模式为 Serverless 形态。表面上来看，ACS 只是又一款基于 Serverelss Kubernetes 技术的云服务产品，但经过对其技术理念和设计思路的深度分析后，我们发现了它与以往同类产品的许多不同。

立足现状，Serverless Kubernetes 如何更快落地？

经过多年的探索和实践，今天无论是云提供商还是用户都更深刻地认识到，云计算产业竞争的关键点在于如何为用户带来更具成本效益的产品。尤其在当下的大环境中，降本的重要性几乎被排在了所有指标的最前面。正因如此，阿里云在去年推出 ACS 容器计算服务时，就意识到该产品要更关注成本要素，基于此，其技术创新和架构设计主要围绕降本目标来实施。

低成本 + 高弹性：节约有形费用与无形投入

企业采购云端计算资源时面临的一大门槛就是令人眼花缭乱的定价机制，很容易造成付费陷阱，使用户付出额外费用。而阿里云 ACS 的定价模型非常简单直接，只提供了通用型、性能型（定价为通用型 1.3 倍）规格，通用型又分为默认和 BestEffort 两种算力质量。其中，通用型默认规格适合网站应用、微服务应用等常见场景，性能型适合需求更高的网关、游戏等业务，BestEffort 质量则专门面向批处理、音视频和数据分析等离线业务。

阿里云 ACS 的一大创新，就是在 Kubernetes 软件层的基础上加入了由阿里云支撑的算力层，从而使这款产品从单纯的容器编排服务转变为全新理念的容器计算产品。用户购买的不仅是容器编排软件，还包括了容器算力资源。但在使用过程中，用户只需支付算力费用，无需为管理组件占用的资源付费。

与此同时，ACS 的算力为按秒计费，容器算力起步规格只有 0.25 核 vCPU + 0.5 GiB 内存，支持 1：1 ～ 1：8 随机资源配比。相比之下，市面上其他 Serverless Kubernetes 方案都存在管理支出，用户需要为 Serverless 基础设施的运维管理组件占用的算力单独付费，实际获得的算力小于购买到的算力，因此成本更高，计费机制也更复杂。很多企业用户在考察 Serverless Kubernetes 方案时，会因为这种额外付费机制而打消购买念头，阿里云 ACS 的这一改进无疑解决了用户一大痛点。

此外，ACS 还引入了许多可以增强服务弹性的创新和特性。例如，其智能化弹性伸缩方案 AHPA 支持基于历史数据的主动学习，可以基于最佳实践自动整合并调度资源，提前扩缩容，快速响应流量变化。应对突发流量冲击时，ACS 可实现高达 7000 Pod/ 分钟的扩容能力。另外，ACS 底层与神龙 CIPU 融合，POD 与云盘、网卡、异构、本盘直通，虚拟化性能开销被控制在了最低水平。ACS 的网络、存储侧也提供了多种选项，方便用户根据自身情况选择成本最低的方案。

易用性：降低使用门槛，缩减软性成本

云计算服务的易用性实际上也与运维成本息息相关，IT 团队为学习新技术投入的精力，适应新方法和技术栈经历的磨合都会带来软性成本。举例来说，市面上很多 Serverless 产品会引入许多与供应商绑定的技术细节，不仅需要用户重新学习，接入新的 API，使用新的格式，而且还会阻止用户未来转向其他厂商的服务。

但阿里云 ACS 对 Kubernetes 技术栈完全兼容，且支持开源生态和自研产品无缝迁移上云，用户可以继续使用熟悉的 Kubernetes 管理方法、文件格式。例如，用户依旧可以使用熟悉的 YAML 文件或控制台，获取 KubeConfig 并通过 kubectl 工具连接集群，也支持资源管理 RAM 授权和 RBAC 授权管理。ACS 还采用了超大规模的多负载差异化 SLO 增强的调度系统，并提供了开源版本，即 Koordinator，支持社区生态无缝对接到 ACS 产品上，实现各类差异化硬件的兼容。

而在关键的运维可观察性和安全性层面，ACS 默认集成并开启 Prometheus 服务，集成了日志服务、报警功能、集群巡检、一键故障诊断、API Server 审计日志等能力，并增强了对用户自建可观测性的支持。此外，用户无需预先购买节点，仅需声明负载需求并配置应用层弹性策略，即可由 ACS 匹配负载与底层计算资源；在运维使用阶段，ACS 用户无需运维管理底层节点，也简化了版本升级工作。

此外，阿里云 ACS 同样提供了丰富、详尽、易懂的社区文档，即便是刚刚接触 Kubernetes 的运维开发人员也能通过自学文档快速掌握 ACS 的使用方法，为自己的应用构建云端算力。

我们可以看到，ACS 的产品思路更加关注“为用户带来快速可见的回报率”，而非“设法将用户绑定在自身生态中”。

写在最后：云原生普及之路的转折点已经出现？

每一种新技术的诞生都会经历一段炒作期，泡沫破裂后才是技术真正稳步发展的开始。以 Serverless Kubernetes 为载体的云原生技术架构，也在面临这样的转折点。而阿里云 ACS 选择率先以更加务实的态度面对市场的审视，这样的转变无疑是符合市场需求的。

当然，并不是所有的企业都是阿里云 ACS 最合适的用户群体。相比之下，ACS 更加适合资金和人力都比较紧张，未来不确定性较大的中小企业用户。他们更需要通过 ACS 这样的产品快速实现降本增效目标，并为业务的长期演进打下一个牢固的基础。当业务规模迎来扩张，IT 团队就可以在 ACS 的基础上，无缝引入更多阿里云体系内的云端产品和服务资源，满足更高的业务需求。

未来，我们也希望能看到更多像阿里云 ACS 一样的云原生产品出现在市场上，让云原生技术以更落地的形态提供给千行百业。当这样的做法成为主流，云原生应用无处不在的未来也就离我们更近一步。