阿里云原生容器服务产品体系

上一章结尾提到一个问题：自己从零维护一套高可用的 Kubernetes 集群，运维成本很高——etcd 要保证高可用、控制平面组件要打补丁升级、大规模节点下的调度性能要自己调优。这一章看阿里云怎么把这件事做成产品，让用户按不同程度"外包"运维负担。

容器编排可以托管到哪一层

这一章按四件事来认识产品：ACK 等服务负责容器编排，ACR 存放和分发镜像，ASM 管理服务间通信，ACK@Edge 把管理范围延伸到边缘节点。先看最容易混淆的托管边界。

图里按课程中的典型形态比较。实际使用时，ACK 的托管节点池还能分担部分节点运维，应用权限、镜像供应链和业务数据仍需自己负责。详见阿里云责任共担模型。

ACK 基础版与 Pro 版

ACK（Alibaba Cloud Container Service for Kubernetes，容器服务 Kubernetes 版）是阿里云托管的 Kubernetes 服务，核心思路是把控制平面（API Server、etcd、Scheduler、Controller Manager 这些 Master 组件）交给阿里云托管运维，用户不用操心这部分的高可用和升级，只需要管理自己的 Worker Node。

命名变更：2022年11月之前这两种形态叫"标准版"和"Pro 版"，之后"标准版"改名为"基础版"。ACA 课程或旧资料里可能还是"标准版"的叫法，考试里两种都可能出现。

ACK 分两种形态：

	ACK 基础版	ACK Pro 版
SLA	不支持 SLA，无赔付	区域级集群 99.95%、可用区级集群 99.50%，支持赔付
集群 / 节点上限	单账号最多 2 个集群，单集群最大 10 个节点	单账号最多 100 个集群，单集群默认 5000 节点（可申请提高）
增强能力	基础的控制面托管	在基础版基础上，增强了 etcd 容灾备份、管控组件可观测性，并集成了调度性能更强的 kube-scheduler 以支持多种智能调度算法
适用场景	个人学习与测试	企业生产环境（测试和正式都适用）

选型的判断逻辑很直接：学习测试用基础版（免费、限制多）；生产环境直接上 Pro。

补一个常考的背景事实：ACK 是全球首批通过 Kubernetes 一致性认证的容器服务平台。这个认证验证的是 API 和行为兼容性——通过认证意味着在标准 K8s 集群上能跑的应用，在 ACK 上也能跑。

ACK Serverless：免去节点管理

基础版和 Pro 版托管的只是控制平面，Worker Node 还是要用户自己规划、购买、维护。Serverless Kubernetes（这个产品早期简称 ASK = Alibaba Cloud Serverless Kubernetes，后来阿里云把它正式更名为"容器服务 Serverless 版 / ACK Serverless"——如果在官方课程或者旧资料里看到 ASK 这个名字，指的就是它，考试里两种叫法都可能出现）更进一步：连节点也不用管，用户只需要描述"我要跑什么 Pod"，阿里云在后台按需分配资源、直接把 Pod 跑起来。

它的核心特点：

• 无需管理节点：没有"节点"这个概念要用户操心，应用直接以 Pod 形式交付
• 按量付费：只为 Pod 实际使用的 CPU、内存资源付费，不用为闲置的节点资源买单
• 极致弹性：可以从 0 快速扩展到数千个实例，适合流量波动大的场景

适用场景集中在无状态、事件驱动的负载：CI/CD 构建、定时任务、数据计算、突发流量的业务托管——这些场景下，"常年占着一批节点等流量高峰"是浪费，Serverless 化能省下这笔闲置成本。

这里记录的是 ACA 课程中的产品形态。阿里云文档说明，ACK Serverless 自 2025 年 2 月 17 日起停止向新用户开放集群创建；需要动手时应查看当前可用的 ACS 或 ACK Pro Serverless 能力。

镜像如何存放与分发：ACR

回到第 2 章 Docker 的三大概念——镜像、容器、仓库。ACR（Alibaba Cloud Container Registry，容器镜像服务）就是阿里云版本的仓库，负责存放和分发镜像。

分个人版和企业版：

• 个人版：基础功能，镜像托管、镜像构建、安全扫描，个人项目或小团队够用
• 企业版：在个人版基础上，多了 Helm Chart 等 OCI 制品托管、SLA 保障、全球同步加速、大规模分发加速、网络访问控制、镜像加签、云原生交付链等，面向企业级的安全和分发规模需求

安全扫描是个常考点，两种引擎的能力范围别搞混：

能力	Trivy（默认，开源）	云安全引擎 SAS（选配）
系统漏洞 / 应用漏洞	✅	✅
基线检查	❌	✅
恶意样本检测	❌	✅
一键修复系统漏洞	❌	✅

默认使用开源的 Trivy 扫描引擎（漏洞库每日更新），企业版可以选配阿里云自己的云安全扫描引擎（SAS）获得基线检查、恶意样本检测和一键修复能力。

服务通信如何治理：ASM

第 1 章提过，微服务之间的 RPC、限流熔断这些中间件能力如果以 SDK 形式嵌入业务代码，每次升级都要跟着重新发布。Mesh 化的思路是把这些能力下沉到 Sidecar 代理里。ASM（Alibaba Cloud Service Mesh，服务网格）是阿里云对这个思路的产品化，基于开源 Istio，控制面由阿里云托管。

课程采用的是 Sidecar 模式：在加入网格、启用注入的业务 Pod 中放入 Envoy 代理，由代理执行治理规则。控制平面下发规则，实际请求经过数据平面的代理：

这是 ASM 支持的一种工作模式，不是所有网格都必须给每个 Pod 放一个 Sidecar。代理可以接管通信策略，但应用仍要正确传播链路上下文，业务层语义也不会自动交给代理解决。

核心能力：

• 流量管理：灰度发布、按比例分流、故障注入（在网络层模拟故障，思路和混沌工程一致）
• 安全：服务间 mTLS 双向认证、细粒度的访问控制，身份验证不用写在业务代码里
• 可观测性：自动采集服务间调用指标和链路追踪数据，和第 5 章的 ARMS 打通

ASM 和第 4 章要讲的 EDAS 区别在哪？EDAS 是应用托管平台，偏重微服务的生命周期管理，主要服务 Java 生态；ASM 工作在网络层，不限语言和框架，Java、Go、Python 的服务都能纳管。两者可以配合使用。

云边断连后如何运行：ACK@Edge

前面几种形态管的都是云端资源。但有些场景，计算节点本身就不在云端机房里——CDN 节点、连锁门店的本地服务器、IoT 网关、音视频直播的边缘推流节点，这些散布在各地、靠近终端用户的设备也需要被纳管。

ACK@Edge 把边缘节点和云端节点纳入同一个 Kubernetes 管理体系。边缘自治（Edge Autonomy）关心的是：云边连接不稳定时，已经下发到本地的工作负载能否继续服务。

节点自治需要启用，已有工作负载根据本地缓存的配置运行，若设置了自治时长还受该时长约束；网络自治让边缘区域内的服务通信减少对云端网络的依赖。图中延续的是本地能力，依赖云端接口的业务不会因此变成可离线运行。连接恢复后再同步云端状态。条件可对照节点自治说明与边缘节点管理。

典型场景就是延迟敏感、需要就近处理、网络不一定稳定的那几类：CDN 边缘计算、IoT 设备管理、音视频直播、门店零售的本地化服务。

产品选型与弹性伸缩

产品选型速查

把课程中出现的几种形态放在一起看：

	控制面谁管	节点谁管	核心卖点	典型场景
ACK 基础版	阿里云	用户	免费、门槛低	个人学习、测试
ACK Pro 版	阿里云（增强）	用户	高 SLA、大规模	核心生产业务
Serverless Kubernetes	阿里云	阿里云	免运维、按量付费	无状态、突发流量、CI/CD
ACK@Edge	阿里云（云边一体）	用户纳管云端与边缘节点，平台提供管理能力	云边协同、配置自治后应对断连	CDN、IoT、直播

ECI：直接运行容器实例

补充一个对照表里没列但考试会出的产品：ECI（弹性容器实例，Elastic Container Instance）。ACK 和 Serverless Kubernetes 管的是"集群"，ECI 比它们更轻——用户直接提交一个容器实例的规格，阿里云在后台按需分配资源跑起来，连集群的概念都没有，适合临时性、一次性的容器任务。可以理解为容器版的"按量付费虚拟机"。ACK 集群里也可以把 ECI 作为弹性资源池，在流量突增时把超出常驻节点承载力的 Pod 调度到 ECI 上运行。

Pod 伸缩与资源伸缩

ACK 的弹性伸缩能力从两个维度理解：

维度	做什么	对应机制
调度层弹性	Pod / 工作负载级别的伸缩——根据 CPU、内存等指标自动增减 Pod 副本数	HPA（水平 Pod 自动伸缩）、CronHPA（定时伸缩）
资源层弹性	节点 / 计算资源级别的伸缩——Pod 调度不上去时自动加节点，空闲时缩节点	Cluster Autoscaler（节点自动伸缩）、虚拟节点（弹性调度到 ECI）

调度层管"要跑多少个 Pod"，资源层管"有多少台机器给 Pod 跑"，两层配合才是完整的弹性能力。

容器这一层的产品到这里都过了一遍。下一章往上走，看应用架构怎么从单体走向微服务。