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

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

阿里云容器服务的产品谱系

阿里云的容器产品体系围绕四个方向展开：

编排怎么托管：ACK 标准版、ACK Pro 版、Serverless Kubernetes，区别在于"控制平面谁管"和"节点谁管"这两个维度托管到什么程度
镜像怎么存放分发：容器镜像服务 ACR
服务通信怎么治理：服务网格 ASM，在网络层统一处理服务间的流量管理、安全和可观测性
场景怎么延伸：边缘容器服务 ACK@Edge，把 Kubernetes 的管理能力延伸到云端之外的边缘节点

ACK：标准版和 Pro 版

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

ACK 分两种形态：

	ACK 标准版	ACK Pro 版
SLA	99.9%，不支持赔付	99.95%，支持赔付
最大节点规模	较小	最大支持万级节点
增强能力	基础的控制面托管	在标准版基础上，增强了 etcd 容灾备份、管控组件可观测性、大规模调度性能
适用场景	中小规模、测试和一般生产场景	大规模、对稳定性和安全性要求高的核心生产场景（官方建议节点数超过 50 就该上 Pro）

选型的判断逻辑很直接：规模小、要求不苛刻用标准版；规模大或者是核心业务，直接上 Pro。

Serverless Kubernetes：连节点都不用管

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

它的核心特点：

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

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

三种形态本质上是"托管程度"的递进：

	控制平面	工作节点	计费方式
ACK 标准版 / Pro 版	阿里云托管	用户自己管	按购买的节点资源付费
Serverless Kubernetes	阿里云托管	阿里云托管	按 Pod 实际用量付费

容器镜像服务 ACR

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

分个人版和企业版：

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

安全扫描是个常考点：会做基线安全检查，也会检测容器里的恶意样本，默认使用开源的 Trivy 扫描引擎，企业版可以选配阿里云自己的云安全扫描引擎（SAS）获得更强的检测能力。

服务网格 ASM

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

工作方式：给每个 Pod 自动注入一个 Sidecar 代理（基于 Envoy），服务之间的所有网络通信都经过这层代理，由代理统一处理流量管理、安全策略、可观测性，业务代码完全不感知。

核心能力：

流量管理：灰度发布、按比例分流、故障注入（在网络层模拟故障，思路和混沌工程一致）
安全：服务间 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、直播

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