在 Azure 上规划与创建生产级 AKS 集群时，如何做…

当你需要创建或规划生产级 Azure Kubernetes Service (AKS) 集群（网络、SKU、安全、可观测性、升级、成本）时使用。

适用场景

解决思路

1. 先收集用户对计算、网络、安全等配置的需求，再开始规划。
2. 优先使用 `azure` MCP server 并选择 `mcp_azure_mcp_aks` 来发现客户端暴露的具体 AKS MCP 工具；选择能满足任务的最小 AKS 工具，仅当 AKS MCP 未暴露所需功能时才回退到 Azure CLI（`az aks`）。
3. 根据用户对控制力与便利性的需求，判断使用 AKS Automatic 还是 Standard SKU；除非需要特定自定义，默认使用 AKS Automatic。
4. 记录集群配置决策及其理由，尤其是后期难以更改的 Day-0 决策（网络、API server 访问）。
5. 按需询问必要输入（环境类型 dev/test 或 production、区域与可用区、首选节点 VM 规格、预期规模、网络需求、安全与身份需求含镜像仓库、升级与可观测性偏好、成本约束）；用户不确定时使用安全默认值。
6. 集群类型：默认选 AKS Automatic（适合多数生产负载，预置安全/可靠性/性能最佳实践）；若需要 Node Auto-Provisioning (NAP) 不支持的特定网络、自动扩缩或节点池自定义，则选 AKS Standard。
7. Pod IP 模型（关键 Day-0 决策）：推荐 Azure CNI Overlay（pod IP 来自私有 overlay 网段，不路由到 VNet，可大规模扩展）；当 pod 必须能从 VNet 或本地直接寻址时使用 Azure CNI (VNet-routable)（pod IP 直接来自 VNet 的 pod 子网或节点子网）。
8. 数据面与网络策略：推荐 Azure CNI powered by Cilium（基于 eBPF，高性能包处理、网络策略与可观测性）。
9. Egress：使用 Static Egress Gateway 获得稳定可预测的出站 IP；受限出站时使用 UDR + Azure Firewall 或 NVA。
10. Ingress：HTTP/HTTPS 工作负载默认推荐 App Routing addon with Gateway API；需要高级流量管理、mTLS、金丝雀发布时用 Istio service mesh with Gateway API；需要带 WAF 集成的 L7 负载均衡时用 Application Gateway for Containers。
11. DNS：在所有节点池启用 LocalDNS，以获得可靠、高性能的 DNS 解析。
12. 安全：全面使用 Microsoft Entra ID（控制面、pod 的 Workload Identity、节点访问），避免静态凭据；通过 Secrets Store CSI Driver 使用 Azure Key Vault 管理密钥；启用 Azure Policy + Deployment Safeguards；为 etcd/API server 启用静态加密、为节点间通信启用传输加密；仅允许已签名且经策略批准的镜像（Azure Policy + Ratify），优先使用 Azure Container Registry；通过命名空间、网络策略、范围化日志实现隔离。
13. 可观测性：使用 Managed Prometheus 与 Container Insights 配合 Grafana 采集日志与指标；启用 Diagnostic Settings 将控制面日志与审计日志收集到 Log Analytics 工作区用于安全监控与排障；其他监控排障工具可用 Agentic CLI for AKS、Application Insights、Resource Health Center、AppLens detectors、Azure Advisors。
14. 升级与补丁：配置 Maintenance Windows 控制升级时间；为控制面和节点 OS 启用 auto-upgrades 以获取安全补丁与 Kubernetes 版本更新；通过升级到 Premium tier 使用 LTS 版本（2 年支持）获得企业级稳定性；跨测试到生产的分阶段发布使用 AKS Fleet Manager。
15. 性能：使用 Ephemeral OS disks（`--node-osdisk-type Ephemeral`）加快节点启动；选择 Azure Linux 作为节点 OS（占用更小、启动更快）；启用 KEDA 实现超越 HPA 的事件驱动自动扩缩。
16. 节点池与计算：设置专用系统节点池（至少 2 个节点，打上 `CriticalAddonsOnly` 污点仅供系统工作负载）；在所有池启用 Node Auto Provisioning (NAP) 以节省成本并快速扩缩；使用最新一代 SKU（v5/v6）获得主机级优化；避免 B-series VM（突发型 SKU 会导致性能/可靠性问题）；生产工作负载使用至少 4 vCPU 的 SKU；设置 topology spread constraints 按 SLO 将 pod 分布到主机/可用区。
17. 可靠性：跨 3 个可用区部署（`--zones 1 2 3`）；使用 Standard tier 获得区域冗余控制面与 API server 99.95% SLA；启用 Microsoft Defender for Containers 提供运行时保护；为所有生产工作负载配置 PodDisruptionBudgets；使用 topology spread constraints 确保 pod 跨故障域分布。
18. 成本控制：批处理/可中断工作负载使用 Spot node pools（最高节省 90%）；dev/test 集群用 `az aks stop/start` 停止/启动；稳态工作负载考虑 Reserved Instances 或 Savings Plans。
19. 按场景加载对应参考文件：Pod Rightsizing（过度配置的 pod、CPU/内存 requests、rightsize 工作负载）→ azure-aks-rightsizing.md；VPA Setup（vertical pod autoscaler、VPA 建议、启用 VPA）→ azure-aks-vpa.md；Cluster Autoscaler（空闲节点、CAS 关闭、启用 autoscaler、scale-down profile、节点利用率）→ azure-aks-autoscaler.md；Spot Node Pools（Spot VM、Spot 节点、批处理工作负载、更便宜的节点）→ azure-aks-spot.md；若提示匹配多行，优先最具体的匹配，仍不明确则先向用户澄清意图再加载参考文件。
20. 安全护栏：不要请求或输出密钥（token、key）；不要让用户粘贴 subscription ID，应通过 MCP 工具（列出订阅、列出资源组）或 `az account show` / `az account list` 发现订阅与资源范围，避免暴露标识符；Day-0 关键决策需求不明确时向用户提问澄清，Day-1 功能则提出 2–3 个带权衡的安全选项并选保守默认；不要承诺零停机，应建议工作负载保护措施（PDB、探针、副本）与分阶段升级。
21. 错误处理：MCP 工具调用失败或超时 → 验证 `az login`、用 `az account show` 确认活动订阅上下文、检查目标资源组（不要向用户回显订阅标识符）；配额超限 → 申请配额增加或选择其他区域/VM SKU；网络冲突（IP 耗尽）→ 重新规划 IP 范围，可能需重建集群（Day-0）；Workload Identity 不工作 → 启用 `--enable-oidc-issuer --enable-workload-identity` 并配置 federated identity。

适用边界 · 注意事项

• 只是要把应用部署到已有集群（应使用 azure-kubernetes-app-deploy 子技能）。
• 需要排查 AKS 故障（应使用 azure-diagnostics）或做就绪检查（azure-validate）。
• 需要把已有集群迁移到 AKS Automatic（应使用 azure-kubernetes-automatic-readiness）。