Kubernetes如何在集群节点间实现请求负载均衡？

开发者阿泽

2026-8-30

Kubernetes 集群跨节点请求负载均衡机制解答

首先明确核心认知边界：Kubernetes的流量转发是分层解耦的，不存在全局统一的负载决策模块，不同组件负责不同流量阶段的转发逻辑，你提到的LoadBalancer、Ingress本身只是规则/入口抽象，实际转发逻辑完全依赖底层实现，和K8s核心原生能力没有强绑定。

针对三个问题的具体解答

原生K8s核心链路的组件默认完全不基于实时资源余量、网络延迟做转发决策，具体规则如下：

核心控制面组件（EndpointSlice控制器、kube-proxy）只会维护后端Ready状态的Pod列表，不采集任何CPU、内存、延迟、负载类指标，只要Pod通过就绪探针检查，就会被加入转发后端列表。
注意不要混淆调度和运行时转发的区别：kube-scheduler确实会在Pod创建阶段参考节点资源余量、亲和性规则选择调度节点，但这个决策只发生在Pod启动瞬间，和Pod运行后的请求转发没有任何关系。
LoadBalancer、IngressController是否支持基于负载的转发，完全取决于具体实现：
- 公有云托管的LoadBalancer是云厂商自身的LB实现，部分支持按后端负载加权，属于云厂商能力，不是K8s原生提供的
- 常见的开源IngressController（Nginx Ingress、Traefik等）默认也不做负载感知转发，只有额外对接监控系统、配置对应策略后，才会基于采集到的指标调整转发权重
- 只有专门的扩展负载组件（比如服务网格Sidecar、eBPF增强的网络插件）才会主动采集后端负载、延迟指标做智能转发，这类都属于第三方扩展能力，不在原生默认部署范围内。

K8s原生确实内置了Service层的负载均衡能力，由每个节点上运行的kube-proxy组件实现，但能力非常基础，完全不感知节点/Pod实时负载、网络延迟：

首先明确原生负载均衡的作用范围：只负责「流量已经到达某台集群节点后，转发到对应Service的后端Ready Pod」这个环节，不负责“外部流量第一跳打到哪个节点”的决策——第一跳流量到哪个节点，完全取决于你的入口配置（比如LB的转发规则、DNS解析结果、客户端访问的节点IP）。
不同kube-proxy模式的默认策略差异：
- iptables模式（1.29版本前的长期默认模式）：默认采用随机选择策略，不存在严格轮询逻辑，所有Ready Pod被命中的概率均等，无权重、无负载感知。
- ipvs模式：默认采用**简单轮询（Round Robin）**策略，额外内置了加权轮询、最小连接数、源地址哈希等几种静态可选策略，同样不感知实时资源余量、网络延迟，其中最小连接数策略仅统计本机记录的连接数，不做全局统计。
- nftables模式（1.29及以后版本的默认模式）：逻辑和iptables模式基本一致，默认随机选择后端Pod，转发性能更高，同样无负载感知能力。
原生能力仅在1.21版本后新增了*拓扑感知提示（Topology Aware Hints）*特性，开启后可以优先将流量转发到同节点、同可用区的后端Pod，减少跨节点/跨可用区网络开销，但这个策略仅基于节点拓扑标签，依然不感知实时负载。

原生kube-proxy的自定义能力极弱，仅支持切换ipvs模式下预设的几种静态策略、开启拓扑感知路由，不支持用户编写自定义转发逻辑（比如按请求特征路由、基于负载动态调整权重等）。
如果需要个性化转发能力，可以通过扩展方案实现，生产环境常见的成熟方案包括：

替换入口控制器：使用APISIX、Kong、Envoy Gateway等增强型Ingress实现，支持基于请求路径、Header、Cookie、源IP等维度的自定义转发，部分支持对接监控指标实现基于负载的加权转发。
替换kube-proxy：使用Cilium等基于eBPF的网络插件替换原生kube-proxy，支持更丰富的负载策略，包括一致性哈希、拓扑优先路由、自定义过滤规则等，转发性能也优于原生kube-proxy。
接入服务网格：部署Istio、Linkerd等服务网格组件，通过Sidecar代理拦截服务间所有流量，可以实现基于延迟、错误率、实时负载的智能负载均衡，支持灰度发布、流量镜像、按用户特征路由等完全自定义的转发规则，是目前复杂场景下的主流方案。

补充认知纠偏：默认部署的K8s集群不会因为某个节点/Pod负载高就主动切走流量，哪怕节点CPU已经跑满，只要上面的Pod还能通过就绪探针检查，就依然会被转发流量。如果需要“负载高的节点少分流、负载低的节点多分流”的能力，必须通过上述扩展组件实现，原生不提供这个能力。

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