在单个AKS集群中部署内部与公开工作负载的方案咨询

更优方案：Ingress Controller + Kubernetes Network Policy #

这是最轻量化且易维护的方案，无需改动集群网络模式或拆分节点池：

• 对于需要暴露至互联网的工作负载，直接通过公网类型的Ingress Controller配置Ingress规则，对外提供访问入口
• 对于仅允许特定公网IP访问的工作负载，同样通过Ingress暴露，但在Ingress规则中添加IP白名单限制；同时配合Kubernetes Network Policy，限制Pod仅接收来自Ingress Controller的流量，双重保障访问安全
• 若使用Azure原生的Application Gateway Ingress Controller（AGIC），还能直接在Application Gateway层面配置IP白名单或WAF规则，完全贴合Azure生态，管理更便捷

现有方案对比 #

方案1：Azure CNI + Pod层面NSG #

• 优势：能实现Pod级别的细粒度访问控制，每个Pod可单独配置规则
• 劣势：操作复杂度极高，Pod生命周期短，NSG与Pod的绑定需要额外自动化工具（如自定义Operator）来维护；且Azure CNI下Pod会占用VNet的IP地址，大规模集群场景下IP资源容易耗尽，扩展性差

方案2：拆分internal/public节点池 + VMSS NIC层面NSG #

• 优势：节点池级别的隔离逻辑清晰，NSG配置在VMSS层面，规则相对稳定
• 劣势：节点池维护成本高，升级、扩容等操作需分开执行；工作负载必须通过nodeSelector、taint/toleration严格调度到对应节点池，配置失误会直接导致访问异常；且同一节点池内的所有Pod共享NSG规则，无法实现Pod级别的差异化控制

选型建议 #

• 优先选择Ingress Controller + Network Policy方案：适配绝大多数场景，操作简单、维护成本低，且能灵活支持不同粒度的访问控制需求
• 若工作负载可明确按访问类型划分为两组，且团队能接受多节点池的维护成本，方案2可以作为备选，但长期灵活性不如前者
• 方案1不推荐，除非有极端特殊的Pod级隔离需求，否则过高的管理成本会成为集群维护的负担

内容的提问来源于stack exchange，提问作者Will