1. Azure容器平台全景
Azure 的容器服务并不是“一个产品打天下”，而是围绕不同抽象层级、不同运维责任边界和不同运行位置形成的一组平台能力。理解它们的关键，不是背产品名，而是先回答三个问题：谁负责编排与伸缩、容器运行在哪里、团队愿意承担多少 Kubernetes 复杂度。本节把 AKS、ACI、Azure Container Apps、Azure Arc 与 Azure Container Registry 放在同一张全景图中，给出各自的定位、典型场景与选型依据。
一、五个组件的定位
Azure Kubernetes Service（AKS）是托管 Kubernetes 控制平面的集群服务。它把 etcd、API Server、调度器等控制面交给 Azure 维护，但节点池、工作负载、Ingress、网络插件、存储类、RBAC、升级节奏仍由使用者负责。AKS 适合需要完整 Kubernetes API、自定义控制器、Operator、CRD、DaemonSet、复杂网络策略或已有 Helm/Kustomize 资产迁移的场景。它的核心价值是控制力与生态兼容性，代价是运维面较大。
Azure Container Instances（ACI）是最轻量的“单容器/容器组”运行方式，不暴露 Kubernetes API，也没有节点概念。它按容器组（Container Group）计费，秒级启动，适合一次性任务、CI 构建步骤、批处理、事件触发的短时作业，以及需要快速验证镜像的场合。ACI 的定位是无编排的容器执行单元，不适合长期运行、需要复杂服务发现或自动扩缩的微服务系统。
Azure Container Apps（ACA）建立在 Kubernetes 与 KEDA、Dapr、Envoy 等开源能力之上，但把集群、节点、Ingress 控制器等细节隐藏起来。它提供基于 HTTP 流量、队列长度、事件源的自动伸缩，支持修订版本（Revision）与流量拆分，适合微服务、API、事件驱动后台任务。ACA 的定位是以应用为中心的 Serverless 容器平台，在“少运维”和“可伸缩”之间取得平衡。
Azure Arc不是运行容器的平台，而是把 Azure 的管理面延伸到 Azure 之外。对容器场景而言，Arc-enabled Kubernetes 可以把本地数据中心、其他云或边缘的 Kubernetes 集群接入 Azure，统一使用 Azure Policy、GitOps（Flux）、Azure Monitor、Microsoft Defender for Containers 等能力。它的定位是跨环境统一治理与合规，解决“集群不在 Azure，但希望用 Azure 工具管”的问题。
Azure Container Registry（ACR）是私有镜像与制品仓库，支持 OCI 镜像、Helm Chart、SBOM 等制品，提供基于 Entra ID 的认证、基于角色的访问控制、异地复制、任务（ACR Tasks）构建、内容信任与漏洞扫描。它是上述所有运行平台的镜像供给源，通常作为交付链路的起点。
二、全景关系图
三、选型依据：从需求反推平台
选型时建议按以下顺序判断，而不是先看产品功能表。
第一步，判断是否需要完整 Kubernetes。如果团队已有 Helm Chart、Operator、CRD、Istio/Linkerd 服务网格、自定义调度器，或需要 DaemonSet 采集节点日志，那么 AKS 是自然选择。反之，如果只是“把容器跑起来并自动伸缩”，ACA 往往更省事。
第二步，判断工作负载的生命周期。长期在线、需要稳定入口与多副本的微服务，适合 AKS 或 ACA；一次性、分钟级、事件触发的任务，ACI 或 ACA 的 Job 更合适。ACI 的容器组在任务结束后即释放，不会长期占用节点。
第三步，判断运行位置与合规边界。如果集群必须留在本地数据中心或边缘，且仍希望使用 Azure Policy、GitOps、Defender 统一管理，则用 Azure Arc 接入，而不是强行迁移到 Azure。Arc 让“运行位置”和“管理面”解耦。
第四步，判断镜像与制品治理需求。无论选哪个运行平台，只要涉及私有镜像、多环境复制、构建流水线或漏洞扫描，就应使用 ACR。ACR 的异地复制可以减少跨区域拉取延迟，ACR Tasks 可以在云端完成镜像构建，避免在 CI 代理上维护 Docker 环境。
四、一个可参考的选型对照
| 判断维度 | AKS | ACA | ACI | Arc |
|---|---|---|---|---|
| 抽象层级 | 集群 / 工作负载 | 应用 / 修订版本 | 容器组 | 集群治理面 |
| 是否暴露 K8s API | 是 | 否 | 否 | 取决于被纳管集群 |
| 自动伸缩 | HPA / KEDA / 集群自动伸缩 | 内置 KEDA 规则 | 无 | 不提供伸缩 |
| 典型场景 | 复杂微服务、迁移既有 K8s | API、事件驱动、微服务 | 批处理、CI 步骤、验证 | 本地/多云统一合规 |
| 运维责任 | 较高 | 较低 | 最低 | 治理层，不替代运行平台 |
五、组合使用才是常态
真实项目中，这些组件通常组合出现。一个常见的交付链路是：代码提交后由 CI 构建镜像并推送到 ACR；生产微服务部署到 AKS，使用 HPA 与 Ingress 对外提供服务；事件驱动的短任务交给 ACA 或 ACI；本地数据中心的 Kubernetes 集群通过 Azure Arc 接入，统一应用 Policy 与 GitOps。这样既保留了关键系统的控制力，又在边缘场景降低了运维成本。