从 AKS 到混合云：用 Azure 构建可扩展的容器管理体系

2026-09-11 19 预计阅读时间: 1 分钟
来源: azure.microsoft.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

Microsoft 被评为 2026 年 Gartner® 容器管理魔力象限™领导者。这个消息的重点不只是一个市场评价，更在于企业如何把容器平台用于 AI、混合云和大规模应用交付：在 Azure 上运行 Kubernetes 工作负载，在本地或其他云环境中保持一致的治理能力，并为不需要直接管理 Kubernetes 的团队提供更简单的容器运行方式。

Azure Kubernetes Service（AKS）、Azure Arc 和 Azure Container Apps 分别覆盖了不同的运行场景。理解它们的边界，比单纯选择一个平台名称更重要。

三种运行模型，覆盖不同复杂度

AKS：需要 Kubernetes 控制力时

AKS 适合需要 Kubernetes 原生能力的团队，例如复杂微服务、GPU 加速 AI 工作负载、细粒度网络策略、自定义调度，以及与现有 Kubernetes 工具链深度集成的场景。

企业通常需要自行设计节点池、资源请求与限制、发布策略、可观测性和成本控制。AKS 可以减少控制平面的运维负担，但应用团队仍要对 Kubernetes 对象和工作负载行为负责。

Azure Arc：把治理能力带到混合环境

当容器集群分布在数据中心、边缘位置或其他云平台时，Azure Arc 可以作为统一管理入口。实践中，它的价值不在于把所有环境变成完全相同，而在于让策略、清单、资源视图和运维流程更容易跨环境复用。

混合云设计仍然需要面对网络延迟、身份认证、数据驻留、版本差异和离线运行等问题。统一管理并不意味着消除这些约束，平台团队应把它们明确记录在部署和灾备设计中。

Azure Container Apps：减少平台操作负担

对于希望部署容器化 API、后台任务或事件驱动服务，但不想直接维护 Kubernetes 资源的团队，Azure Container Apps 提供了更高层的应用运行模型。它更适合以应用交付速度、自动伸缩和较低平台复杂度为主要目标的场景。

这类抽象也意味着较少的底层控制权。需要复杂调度、特殊网络拓扑或 Kubernetes 扩展生态的系统，仍然更适合 AKS。

AI 和混合工作负载的共同挑战

AI 工作负载让容器平台的要求变得更具体。模型推理服务可能需要 GPU、快速扩缩容和稳定的模型缓存；训练任务可能需要批处理调度、专用节点和大量数据访问。平台选择之外，还要处理以下问题：

  • 用节点池或工作负载配置隔离 CPU、内存和 GPU 资源。
  • 为服务设置明确的 requests 和 limits，避免单个容器挤占节点资源。
  • 将模型、密钥和连接字符串放在专门的配置或密钥系统中，而不是写入镜像。
  • 为跨环境部署定义一致的身份、网络和审计策略。
  • 用指标、日志和追踪验证扩缩容是否真的改善了延迟和成本。

“可以运行容器”只是起点。规模化运行要求平台团队把部署、治理和故障处理做成可重复的流程。

一个可改造的 AKS 部署示例

下面的示例假设已经安装 Azure CLI，并完成 az login。它创建一个 AKS 集群，部署一个带资源边界的 Web 服务，并通过 Kubernetes Service 暴露出来。生产环境中应进一步补充私有集群、镜像签名、网络策略、密钥管理和监控配置。

#!/usr/bin/env bash
set -euo pipefail

LOCATION="eastasia"
RESOURCE_GROUP="rg-container-demo"
CLUSTER_NAME="aks-container-demo"

az group create \
  --name "$RESOURCE_GROUP" \
  --location "$LOCATION"

az aks create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$CLUSTER_NAME" \
  --node-count 2 \
  --enable-managed-identity \
  --generate-ssh-keys

az aks get-credentials \
  --resource-group "$RESOURCE_GROUP" \
  --name "$CLUSTER_NAME" \
  --overwrite-existing

kubectl apply -f - <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
  labels:
    app: web-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
        - name: web-api
          image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: web-api
spec:
  selector:
    app: web-api
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
YAML

kubectl get deployment web-api
kubectl get service web-api

这个例子展示了几个值得保留的工程习惯：部署副本数写入声明式配置，容器设置资源边界，服务通过标签选择工作负载，集群凭据通过 CLI 获取。改造到真实项目时，可以把镜像替换为企业镜像仓库中的版本，并把 YAML 纳入 GitOps 或 CI/CD 流程。

如何选择和落地

可以按以下问题确定起点：

  1. 团队是否需要直接使用 Kubernetes API、调度规则和扩展生态？如果需要，优先评估 AKS。
  2. 工作负载是否跨越 Azure、本地数据中心或其他云？如果是，应评估 Azure Arc 的统一管理能力，同时单独设计网络和身份方案。
  3. 团队是否更关注快速交付容器应用，而不是管理 Kubernetes 细节？可以从 Azure Container Apps 开始。
  4. 工作负载是否使用 GPU、批处理或大规模数据？应在平台评估中加入节点类型、调度、存储和成本测试，而不是只做功能验证。
  5. 是否能用同一套发布、审计和回滚流程覆盖开发、测试与生产？如果不能，平台复杂度会很快转移到应用团队。

结语

Microsoft 被评为 2026 年 Gartner® 容器管理魔力象限™领导者，反映了 Azure 在容器管理、AI 工作负载和混合环境方面的产品组合。真正的采用价值取决于企业能否根据工作负载复杂度选择合适的运行模型，并把资源治理、身份安全、观测和交付流程纳入平台基线。

建议从一个边界清晰的服务开始验证：记录部署耗时、发布失败率、资源利用率、扩缩容延迟和运维工作量，再决定哪些能力需要 AKS 的控制力，哪些应用可以交给更高层的容器平台运行。

# AI # Azure # 云原生 # 云平台

相关推荐