单区域AKS集群中云负载均衡器与nginx-ingress配合的优势及必要性咨询

嗨，我特别理解你的困惑——不少刚上手AKS的朋友都会纳闷：既然已经用了nginx-ingress做路由和负载均衡，为啥AKS默认还要带个云负载均衡器？它们俩看起来功能重叠，但其实是分工协作的黄金搭档，在单区域场景下也有不少不可替代的优势：

• 底层流量的高可用兜底：nginx-ingress是运行在K8s Pod里的应用层组件，要是所有ingress Pod所在的节点故障，或者Pod本身出问题，云负载均衡器能第一时间检测到异常节点，自动把流量切到健康节点上。而且它是Azure原生的基础设施服务，故障恢复由Azure负责，比Pod级别的自愈更可靠。同时，它还能把外部流量均匀分发到运行ingress Pod的各个节点，避免单个节点被流量打满。

• 简化外部接入与IP管理：如果不用云负载均衡器，你得手动配置NodePort暴露nginx-ingress，但AKS的节点IP是可能变动的（比如节点被重新调度），外部用户访问的地址也得跟着变。而云负载均衡器可以绑定静态公网IP，给你一个固定的外部访问入口，不用操心背后节点的变化。另外，它会自动处理80/443端口的转发，不用你在每个节点上手动开放端口，减少了安全配置的麻烦。

• 集成云原生网络安全与功能：Azure的云负载均衡器能和AKS的Network Policy、Azure DDoS保护等组件无缝联动。比如它可以在网络层直接抵御DDoS攻击，这是nginx-ingress（应用层组件）做不到的；还能配合Network Policy实现更细粒度的流量隔离，让集群的网络安全更有保障。就算你现在是单区域，以后想扩展到多区域，保留云负载均衡器也能让迁移更顺畅。

• 健康检查的互补机制：云负载均衡器做的是节点级别的健康检测（比如检查节点的80/443端口是否正常响应），而nginx-ingress负责的是后端服务的健康检查。两者结合起来，形成了从外部网络到内部服务的完整健康检测链条，不会出现“节点已经宕机，但nginx还在把流量发过去”的尴尬情况。

至于必要性：严格来说，你可以通过NodePort模式绕过云负载均衡器，但这在生产环境里风险很高——节点IP不稳定、端口管理混乱、缺乏底层高可用保障。所以在单区域AKS的生产集群中，强烈建议保留并使用云负载均衡器，它和nginx-ingress各司其职：一个管底层网络的稳定接入，一个管应用层的路由规则，让你的集群更可靠、更易维护。

备注：内容来源于stack exchange，提问作者youngtoken