📚 课程目录第3章 AKS集群规划与网络设计

3. AKS集群规划与网络设计

生产级 AKS 集群的规划不是“先建集群再补网络”，而是从业务规模、可用性目标、合规边界和出站行为四个方向同时收敛。规格选型决定节点池的弹性上限与成本基线，VNet 与子网规划决定 Pod、Service 和节点能否共存与扩展，CNI 选型决定 IP 消耗模型与网络策略能力，私有集群与 API Server 访问控制决定控制面的暴露面，NAT 网关与出站设计决定集群访问外部依赖时的稳定性与可审计性。本节按“先定边界、再定地址、后定流量”的顺序展开。

一、节点池规格选型：从工作负载画像反推

选型的第一步不是看 VM 列表，而是把工作负载分成三类：通用 Web/API 类、内存密集类、突发批处理类。通用类通常选择 Standard_D4s_v5（4 vCPU / 16 GiB）作为系统节点池，配合 Standard_D8s_v5 作为用户节点池；内存密集类可选 Standard_E4s_v5（4 vCPU / 32 GiB）；批处理类可考虑可突发型 Standard_B4ms，但生产环境需谨慎，因为突发型 CPU 积分耗尽后性能会明显下降。

节点池规划要同时考虑三个约束：第一，系统节点池建议至少 3 个节点，跨 3 个可用区，承载 CoreDNS、metrics-server、CNI 等系统组件；第二，用户节点池按“单节点可承载 Pod 数 × 节点数 ≥ 峰值 Pod 数”反推，例如单节点最大 30 Pod、峰值 240 Pod，则至少 8 个节点；第三，节点池的 maxPods 与 CNI 模式强相关，Azure CNI 默认每节点 30 Pod，Kubenet 默认 110 Pod，但 Kubenet 受路由表条目限制。生产环境建议系统节点池与用户节点池分离，避免业务 Pod 挤占系统组件资源。

二、VNet 与子网规划：地址空间是硬约束

AKS 的地址规划必须同时覆盖节点子网、Pod 子网（若使用 Azure CNI Overlay 或 Kubenet）、Service CIDR、DNS Service IP 以及可能的 API Server 私有端点子网。一个常见的生产级规划示例如下：VNet 使用 10.20.0.0/16，节点子网 10.20.0.0/20（约 4091 个可用 IP），Pod 子网 10.20.16.0/20，Service CIDR 使用 10.21.0.0/16，DNS Service IP 固定为 10.21.0.10。若使用 Azure CNI 动态分配，Pod 直接从节点子网取 IP，此时节点子网必须按“节点数 × maxPods + 预留”计算，例如 20 节点 × 30 Pod = 600 IP，加上节点自身和升级预留，/22（约 1021 IP）更稳妥。

子网规划还要预留扩展空间：不要一次性把 VNet 切满，建议保留至少 50% 的连续地址段给未来新增节点池或对等互联。若集群需要与本地数据中心或其它 VNet 互通，应避免与现有网段重叠，并在规划阶段就确定 UDR 和 NSG 的归属。

三、CNI 选型对比：Kubenet、Azure CNI、Overlay

三种主流 CNI 的差异集中在 IP 来源、路由方式和网络策略能力上。Kubenet 使用独立 Pod CIDR，节点通过 UDR 转发，IP 消耗小但路由表条目有限，且不支持 Azure 网络策略；Azure CNI 让 Pod 直接使用 VNet IP，可与 VNet 内其它资源直接互通，但 IP 消耗大，适合地址充足且需要强互通的生产环境；Azure CNI Overlay 在 Azure CNI 基础上引入 Overlay 封装，Pod 使用独立 CIDR，节点仍使用 VNet IP，兼顾 IP 节省与网络策略支持，是当前新建生产集群的推荐选项。

四、私有集群与 API Server 访问控制

生产集群建议启用私有集群模式，使 API Server 只通过 Private Endpoint 暴露在 VNet 内。启用后，kubelet 与 kubectl 都通过私有 DNS 区域 privatelink.<region>.azmk8s.io 解析到 Private Endpoint IP。若运维人员需要从办公网访问，可保留“公共访问 + 授权 IP 范围”作为过渡，但应限制到具体出口 IP，并配合 Azure AD 集成与 Kubernetes RBAC。私有集群创建后无法直接改为公共，规划阶段就要确定访问路径：是走 VPN/ExpressRoute，还是通过跳板机，还是保留受限公共端点。

五、出站流量与 NAT 网关设计

AKS 默认出站使用负载均衡器公共 IP，但生产环境更推荐 NAT 网关或用户自定义路由（UDR）到防火墙。NAT 网关提供可预测的 SNAT 端口和固定出口 IP，便于外部系统做白名单。规划时需计算 SNAT 端口需求：每个节点默认约 64K 端口，若 Pod 并发连接数高，应增加公共 IP 前缀或使用多个 NAT 网关。若企业已有 Azure Firewall，可通过 UDR 将 0.0.0.0/0 指向防火墙，实现出站审计与 FQDN 过滤，但需确保防火墙规则放行 AKS 必需的 FQDN，如 mcr.microsoft.com、management.azure.com 等。

规划检查顺序建议：先确定私有集群与 API Server 访问方式，再划分 VNet/子网，然后根据 IP 消耗选择 CNI，最后设计 NAT 网关与 UDR。任何一步变更都可能反向影响前面的地址规划。

一个可落地的参数示例：VNet 10.20.0.0/16，节点子网 10.20.0.0/20，Pod 子网 10.20.16.0/20，Service CIDR 10.21.0.0/16，DNS IP 10.21.0.10，系统节点池 3 节点 Standard_D4s_v5，用户节点池 8 节点 Standard_D8s_v5，CNI 选择 Azure CNI Overlay，出站使用 NAT 网关绑定 /28 公共 IP 前缀。该组合在 IP 节省、网络策略支持和出站可审计性之间取得平衡，适合中等规模生产集群起步。