2. AKS架构与核心组件

Azure Kubernetes Service（AKS）并不是把原生 Kubernetes 原封不动地搬到云上，而是把集群拆成“托管部分”和“用户自管部分”两层。理解这条分界线，是后续做节点池规划、网络选型、身份接入和故障排查的前提。本节围绕控制平面托管机制、节点池类型、kubelet 与容器运行时、Azure CNI 与 kubenet 网络模型、集群身份与 Azure AD 集成五条主线展开。

控制平面托管机制

在 AKS 中，API Server、etcd、Scheduler、Controller Manager 以及 cloud-controller-manager 由 Azure 托管，运行在微软管理的区域资源中，用户不直接登录这些节点，也不为它们打补丁或升级。用户侧真正持有的是节点池中的工作节点（Agent Node），以及节点上的 kubelet、容器运行时和网络组件。控制平面与节点之间通过 Konnectivity 隧道通信：kubelet 主动向 API Server 建立反向连接，因此节点不需要暴露公网入站端口，这也是 AKS 能保持节点私密性的关键设计。

托管不等于不可观测。控制平面日志（kube-apiserver、kube-controller-manager、kube-scheduler、cluster-autoscaler 等）可以通过诊断设置导出到 Log Analytics 工作区；API Server 的访问则通过 az aks get-credentials 获取 kubeconfig 后由 kubectl 完成。控制平面有独立的 SLA，但用户仍需为节点池的可用性、Pod 的调度策略和网络策略负责。一个常见的误解是“控制平面托管了，集群就高可用”——实际上如果只有一个节点池且副本数为 1，业务依然会因节点故障中断。

节点池类型：系统节点池与用户节点池

AKS 把节点池分为两类。系统节点池（System Node Pool）承载 CoreDNS、metrics-server、konnectivity-agent 等关键系统 Pod，必须至少存在一个，且建议至少 2 个节点、使用 Standard_DS2_v2 及以上规格，并通过污点 CriticalAddonsOnly=true:NoSchedule 限制普通业务 Pod 调度。用户节点池（User Node Pool）承载业务负载，可以按需创建多个，支持不同的 VM 规格、操作系统（Linux/Windows）、节点镜像和标签。

节点池还支持可用性区域分布、自动扩缩容（cluster autoscaler）和节点镜像升级。例如创建一个跨三个可用区、开启自动扩缩容的用户节点池：

az aks nodepool add \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod \
  --name userpool01 \
  --node-count 3 \
  --min-count 3 --max-count 12 \
  --enable-cluster-autoscaler \
  --zones 1 2 3 \
  --node-vm-size Standard_D4s_v5 \
  --labels workload=general \
  --mode User

执行后可用 kubectl get nodes -L topology.kubernetes.io/zone 观察节点是否均匀落在三个可用区。若某个可用区节点数为 0，说明该区域容量受限或配额不足，需要检查订阅配额。

kubelet 与容器运行时

每个工作节点上运行 kubelet，它从 API Server 接收 PodSpec，调用容器运行时创建容器，并周期性上报节点状态与资源使用。AKS 默认使用 containerd 作为容器运行时（早期 Docker 运行时已弃用），containerd 通过 CRI 接口与 kubelet 交互，镜像拉取、容器生命周期、日志轮转都由它负责。节点上还可以看到 kube-proxy（负责 Service 转发）和 CNI 插件进程。

kubelet 的关键参数包括 --max-pods（单节点最大 Pod 数）、--node-status-update-frequency 和资源预留（kube-reserved、system-reserved、eviction-hard）。AKS 会根据 VM 规格自动设置 max-pods，例如 Standard_D4s_v5 在 Azure CNI 下默认约 30 个 Pod，在 kubenet 下可到 110 个。如果业务需要更高密度，可以在创建节点池时通过 --max-pods 调整，但要注意 IP 消耗和节点稳定性。

Azure CNI 与 kubenet 网络模型

AKS 提供两种主要网络模型。kubenet 是“覆盖式”模型：节点从 VNet 子网获得一个 IP，Pod 使用独立的内部网段（如 10.244.0.0/16），通过节点上的路由和 NAT 访问外部，Pod 之间跨节点通信依赖 UDR 或 Azure 路由表。它的优点是节省 VNet IP，缺点是 Pod IP 不可直接路由、需要额外跳数、不支持 Windows 节点池和网络策略的部分能力。

Azure CNI 则让每个 Pod 直接从 VNet 子网分配 IP，Pod 与 VNet 内其他资源（VM、数据库、负载均衡）可直接互通，支持网络策略、Windows 节点池和更细粒度的控制。代价是 IP 消耗大：若子网为 /24（254 个可用 IP），节点数 10、每节点 30 个 Pod，则需 10×(1+30)=310 个 IP，已超出 /24 容量，必须规划更大的子网或使用 Azure CNI Overlay。选择时可参考下表：

集群身份与 Azure AD 集成原理

AKS 涉及两类身份：控制平面身份（用于创建和管理 Azure 资源，如负载均衡器、路由表、磁盘）和 kubelet 身份（节点拉取 ACR 镜像、访问 Key Vault 等）。控制平面身份推荐使用托管标识（Managed Identity），避免服务主体密钥过期。kubelet 身份同样使用托管标识，并通过节点池的 --assign-identity 或 --enable-managed-identity 配置。

Azure AD 集成解决的是“谁能访问集群”的问题。启用 AKS-managed Azure AD 后，用户通过 az aks get-credentials 获取 kubeconfig，kubectl 请求携带 Azure AD token，API Server 校验 token 并映射到 Kubernetes 的 RBAC 角色。管理员可以用 kubectl create rolebinding 把 Azure AD 用户或组绑定到 ClusterRole，实现“用 Azure AD 账号登录、用 RBAC 授权”的闭环。例如把组 aks-dev-team 绑定为命名空间 dev 的编辑者：

kubectl create rolebinding dev-edit \
  --clusterrole=edit \
  --group="<Azure AD Group Object ID>" \
  --namespace=dev

执行后，该组成员使用自己的 Azure AD 账号执行 kubectl get pods -n dev 应成功，而访问 kube-system 应被拒绝。若返回 403，需检查组对象 ID 是否正确、RBAC 绑定是否生效，以及 kubeconfig 是否使用了正确的用户上下文。

把上述五部分串起来看：控制平面托管让用户免于运维 etcd 和 API Server，但节点池、kubelet 参数、CNI 选型和身份绑定仍需用户决策。实际落地时，建议先确定网络模型（是否用 Azure CNI Overlay 以缓解 IP 压力），再规划系统节点池与用户节点池的规格和可用区，最后启用托管标识与 Azure AD 集成，并用 RBAC 把权限收敛到命名空间级别。这样集群在扩容、升级和故障时才有清晰的边界和可预期的行为。