Nginx Ingress Controller前置负载均衡器的作用与部署疑问

先明确每个组件的核心边界（避免认知混淆） #

很多人梳理不清链路的核心原因，是把不同层级组件的转发能力、感知范围混在了一起：

• 集群外侧的NLB是四层（TCP/UDP）转发层，完全不感知七层路由规则、不感知集群内部的服务/应用结构
• Nginx Ingress Controller是集群内部的七层（HTTP/HTTPS）路由层，负责域名、路径级别的流量拆分转发
• K8s Service是集群内部的负载抽象层，负责在同服务的多个Pod副本之间做流量分发
• Pod是实际的应用工作负载本身，IP地址是临时可变的

逐个解答核心疑问 #

1. /orders路径请求在order服务副本间的分发主体 #

这部分负载分发完全由K8s内部针对order服务创建的ClusterIP类型Service完成。
当请求从Ingress Controller转发到order服务对应的ClusterIP Service时，节点上的kube-proxy组件会根据预设的负载算法（随机、最少连接等），把请求转发到后端任意一个健康的order Pod副本上。这个过程和外部NLB没有任何关系——NLB甚至根本不知道集群内部存在order服务、以及这些服务的Pod副本信息。

2. 前置NLB的核心作用 #

NLB完全不参与七层路由逻辑，它的核心定位就是面向公网用户的稳定入口，具体作用只有三个：

• 提供全局固定的公网IP/域名，用户无需感知集群内部任何节点、Pod的IP变化，DNS直接解析到NLB地址即可发起请求
• 做四层流量转发，把用户发来的80/443端口请求，按照健康检查结果，转发到后面所有健康的Nginx Ingress Controller接入端点上
• 实现入口侧的故障冗余：如果某个接入端点故障，NLB会自动将其从转发列表中摘除，避免向故障点发送用户请求
  你之前认知里“NLB把example.com请求分发到多个处理节点”，这里的“处理节点”指的就是Nginx Ingress Controller的接入端点，不是直接面向后端的order、payment等业务服务。

3. 类型为LoadBalancer的Service的实际含义和功能 #

K8s里type: LoadBalancer的Service，本质是触发云厂商配套的cloud-controller-manager组件，自动在集群外部创建对应的云负载均衡实例（也就是前述NLB），不是在集群内部凭空生成一个负载均衡组件。
这类Service承担的功能包括：

• 作为Ingress Controller的流量承接层：云组件创建完外部NLB后，会自动把NLB的后端转发目标，指向这个LoadBalancer Service关联的所有Ingress Controller接入端点
• 本身具备K8s Service的通用能力：通过kube-proxy规则，在多副本的Ingress Controller Pod之间做内部流量分发，把从外部NLB转来的流量，转到健康的Ingress Controller Pod上
• 大幅简化运维成本：不需要管理员手动登录云控制台配置NLB的后端规则、健康检查策略，整个配置全流程通过K8s API自动化完成

4. 外侧NLB对集群内部状态的感知逻辑 #

NLB完全没有能力穿透网络边界感知集群内部的Pod、服务状态，所有的状态同步都是通过K8s内置的控制面组件完成的：

• K8s的apiserver会维护所有Service对应的EndpointSlice资源，实时记录当前哪些IP、端口是该Service的健康接入点
• cloud-controller-manager组件会持续监听EndpointSlice的变化，一旦有接入点新增、移除，就自动调用云厂商的API，更新外部NLB的后端转发列表和健康检查目标
• 整个过程的边界非常清晰：NLB能感知到的后端，最多就是K8s控制面告诉它的节点IP、节点端口，它完全不会接触到集群内部的业务服务Pod，更不会感知这些业务服务的运行状态

延伸疑问解答 #

是否仅需要通过NLB暴露Ingress Controller的Service即可？ #

对的，这是标准生产架构的设计模式：

• 外部NLB只需要对接Ingress Controller对应的LoadBalancer类型Service即可，不需要直接对接后端业务服务的内部ClusterIP Service
• 这种架构能最大化发挥Ingress的七层路由、TLS卸载、访问控制、限流等能力，如果把NLB直接对接后端业务Service，会完全丢失七层路由的核心能力，退回到原始的四层转发模式，违背Ingress的设计初衷

Ingress Controller重启时的链路变化、IP逻辑 #

首先要明确一个K8s的基础常识：所有Pod的IP都是临时虚拟IP，只要Pod重启、重新调度，就一定会分配新的IP——但这套临时IP的变化从设计上就和外部NLB完全隔离开，不会出现NLB找不到后端的问题：

• NLB的后端列表里存的永远是节点的固定宿主机IP：因为LoadBalancer类型的Service默认会通过NodePort模式，把服务端口绑定到每个集群节点的固定端口上，只要节点本身不重建，这个IP就不会变化
• Ingress Controller重启时的流程是：旧Pod被终止，对应的EndpointSlice条目在几秒内被移除，cloud-controller-manager会临时调整对应后端的流量权重；新Pod启动后，哪怕拿到了新的临时Pod IP，节点上的kube-proxy规则也会自动把节点固定端口上的流量转发到新Pod上——整个过程中NLB的后端列表根本不需要变更，因为它对接的是节点的固定IP和端口
• 如果采用的是支持Pod IP直接注册到NLB的云原生网络模式，Ingress Pod重启换了新IP后，cloud-controller-manager也会自动调用云API，把旧的故障IP从NLB后端摘除、把新的健康IP加入列表，整个过程完全自动，不需要人工干预

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