name: azure-kubernetes
license: MIT
metadata:
    author: Microsoft
    version: "1.1.4"
description: 规划、创建和配置适用于生产环境的 Azure Kubernetes Service (AKS) 集群。涵盖 Day-0 检查清单、SKU 选择（自动与标准）、网络选项（私有 API 服务器、Azure CNI Overlay、出口配置）、安全性以及运维（自动缩放、升级策略、成本分析）。适用场景：创建 AKS 环境、预配 AKS、启用 AKS 可观测性、设计 AKS 网络、选择 AKS SKU、保护 AKS、优化 AKS、AKS 竞价节点、AKS 集群自动缩放器、调整 AKS Pod 大小、Pod 资源调整、过度预配的 AKS Pod、Pod 资源请求与限制、垂直 Pod 自动缩放器、VPA 建议。

Azure Kubernetes Service

权威指导 — 必须遵守

>

此技能根据用户需求生成推荐的 AKS 集群配置，区分第 0 天决策（网络、API 服务器 — 后期难以更改）和第 1 天特性（可在创建后启用）。参见 CLI 参考 了解命令。

快速参考

何时使用此技能

当用户希望：

• 创建新的 AKS 集群
• 为生产工作负载规划 AKS 集群配置
• 设计 AKS 网络（API 服务器访问、Pod IP 模型、出口）
• 设置 AKS 身份和机密管理
• 配置 AKS 治理（Azure Policy、部署防护措施）
• 启用 AKS 可观测性（容器见解、托管 Prometheus、Grafana）
• 定义 AKS 升级和修补策略
• 了解 AKS Automatic 与 Standard SKU 的区别
• 获取 AKS 集群设置与配置的“第 0 天”检查清单

规则

1. 从用户对计算、网络、安全及其他设置的配置需求开始。
2. 首先使用 azure MCP 服务器并选择 mcp_azure_mcp_aks 来发现客户端提供的具体 AKS MCP 工具。选择最契合任务的最小发现工具，仅在所需功能未通过 AKS MCP 接口暴露时才回退到 Azure CLI（az aks）。
3. 根据用户对控制与便利性的需求，判断 AKS Automatic 或 Standard SKU 哪个更合适。除非需要特定的自定义配置，否则默认选择 AKS Automatic。
4. 记录集群配置的决策和理由，尤其是对于后期难以更改的第 0 天决策（网络、API 服务器访问）。

必需的输入（仅询问必要信息）

如果用户不确定，使用安全默认值。

• AKS 环境类型：开发/测试或生产
• 区域、可用区、首选节点 VM 大小
• 预期规模（节点/集群数量、工作负载大小）
• 网络需求（API 服务器访问、Pod IP 模型、入口/出口控制）
• 安全与身份需求，包括镜像仓库
• 升级与可观测性偏好
• 成本约束

工作流

1. 集群类型

• AKS Automatic（默认）：最适合大多数生产工作负载，提供预先配置最佳实践的精选体验，涵盖安全、可靠性和性能。除非您有节点自动配置（NAP）不支持的网络、自动缩放或节点池配置等特定自定义需求，否则使用此类型。
• AKS Standard：如果您需要完全控制环境配置（需要额外开销进行设置和管理），则使用此类型。

2. 网络（Pod IP、出口、入口、数据平面）

Pod IP 模型（关键的第 0 天决策）：

• Azure CNI Overlay（推荐）：Pod IP 来自私有覆盖范围，不可从 VNet 路由，可扩展至大型环境，适合大多数工作负载
• Azure CNI（VNet 可路由）：Pod IP 直接从 VNet（Pod 子网或节点子网）分配，当 Pod 必须能从 VNet 或本地直接寻址时使用
• 文档：https://learn.microsoft.com/azure/aks/azure-cni-overlay

数据平面与网络策略：

• Azure CNI 由 Cilium 驱动（推荐）：基于 eBPF，用于高性能数据包处理、网络策略和可观测性

出口：

• 静态出口网关用于稳定、可预测的出站 IP
• 对于受限出口：使用 UDR + Azure Firewall 或 NVA

入口：

• 带有 Gateway API 的 App Routing 插件 — HTTP/HTTPS 工作负载的推荐默认方案
• 带有 Gateway API 的 Istio 服务网格 — 用于高级流量管理、mTLS、金丝雀发布
• 适用于容器的应用程序网关 — 用于与 WAF 集成的第 7 层负载均衡

DNS：

• 在所有节点池上启用 LocalDNS，以实现可靠、高性能的 DNS 解析

3. 安全

• 全面使用 Microsoft Entra ID（控制平面、Pod 的工作负载标识、节点访问）。避免使用静态凭据。
• 通过 Secrets Store CSI 驱动程序使用 Azure Key Vault 管理机密
• 启用 Azure Policy + 部署防护措施
• 启用 etcd/API 服务器的静态加密；节点间通信的传输中加密
• 仅允许签名的、策略批准的镜像（Azure Policy + Ratify），优先使用 Azure Container Registry
• 隔离：使用命名空间、网络策略、作用域日志记录

4. 可观测性

• 使用托管 Prometheus 和容器见解（搭配 Grafana）实现 AKS 可观测性（日志 + 指标）。
• 启用诊断设置，将控制平面日志和审计日志收集到 Log Analytics 工作区，用于安全监控和故障排除。
• 对于其他监控和故障排除工具，可使用 AKS 的 Agentic CLI、Application Insights、资源健康中心、AppLens 检测器和 Azure Advisor 等功能。

5. 升级与修补

• 配置 维护窗口 以控制升级时机
• 启用控制平面和节点 OS 的自动升级，以保持安全补丁和 Kubernetes 版本的最新状态
• 考虑使用 LTS 版本实现企业级稳定性（2 年支持），将 AKS 环境升级到 Premium 层
• Fleet 升级：使用 AKS Fleet Manager 实现从测试到生产环境的分阶段部署

6. 性能

• 使用临时 OS 磁盘（--node-osdisk-type Ephemeral）加快节点启动速度
• 选择 Azure Linux 作为节点 OS（占用空间更小、启动更快）
• 启用 KEDA 实现基于事件的自动缩放（超越 HPA）

7. 节点池与计算

• 专用系统节点池：至少 2 个节点，仅污点用于系统工作负载（CriticalAddonsOnly）
• 在所有池上启用节点自动配置（NAP） 以节省成本并实现响应式缩放
• 使用最新一代 SKU（v5/v6） 获得主机级优化
• 避免使用 B 系列 VM — 可突增 SKU 会导致性能和可靠性问题
• 为生产工作负载使用至少 4 个 vCPU 的 SKU
• 设置拓扑分布约束，按 SLO 将 Pod 分布到主机/可用区

8. 可靠性

• 跨 3 个可用区 部署（--zones 1 2 3）
• 使用 Standard 层实现区域冗余控制平面，并为 API 服务器可用性提供 99.95% 的 SLA
• 启用 Microsoft Defender for Containers 实现运行时保护
• 为所有生产工作负载配置 PodDisruptionBudgets
• 使用拓扑分布约束确保 Pod 跨故障域分布

9. 成本控制

• 对批处理/可中断工作负载使用抢占式节点池（最高节省 90% 成本）
• 开发/测试集群的停止/启动：az aks stop/start
• 对稳定状态工作负载考虑预留实例或节省计划

深度场景 — 仅加载相关参考文件：

消歧： 如果提示匹配多行（例如“更便宜的节点”可能同时指向抢占式节点池和自动缩放器），优先选择最具体的匹配。如果不明确，请先询问用户澄清意图，然后再加载参考文件。

防护栏 / 安全

• 不要请求或输出机密（令牌、密钥）。
• 不要要求用户粘贴订阅 ID。通过 MCP 工具（例如列出订阅、列出资源组）或 az account show/az account list 发现订阅和资源范围，以便代理可以解析上下文，而无需暴露标识符。
• 如果需求在第 0 天关键决策上不明确，请用户询问澄清问题。对于第 1 天启用的功能，提出 2-3 个带有权衡的安全选项，并选择保守的默认值。
• 不要承诺零停机；建议工作负载防护措施（PDB、探针、副本）以及分阶段升级，同时提供可靠性和性能方面的最佳实践。

MCP 工具

错误处理