基于Headless Service实现自定义负载均衡，如何避免LB作为代理？

方案一：基于Ingress Controller扩展自定义负载均衡逻辑 #

放弃额外的负载均衡代理组件，直接在Ingress层面实现自定义负载均衡规则：

• 选择支持扩展的Ingress Controller（比如NGINX Ingress），通过自定义Annotations或者嵌入Lua脚本，对接Headless Service获取的Pod列表，实现你需要的负载均衡算法（比如轮询、加权、自定义哈希等）。
• 配置Ingress直接指向Worker的Headless Service，Ingress Controller会根据你的自定义规则，直接将外部请求转发到选定的Worker Pod，无需中间代理转发，同时外部客户端只需要访问Ingress的统一入口地址，不会暴露Pod的内部IP。

方案二：借助Service Mesh实现透明化自定义负载均衡 #

用Service Mesh（如Istio、Linkerd）的流量管理能力替代独立负载均衡代理：

• 部署Service Mesh后，Worker Pod会注入Sidecar代理，Mesh的入口网关作为外部客户端的唯一访问入口。
• 通过Mesh的DestinationRule或自定义策略配置，对接Headless Service的Pod列表实现自定义负载均衡逻辑，客户端的请求会由网关根据规则直接路由到目标Worker Pod，全程不需要额外的代理组件，且Pod的内部IP对外部完全透明。

方案三：优化Redirect方案，给Pod分配可外部访问的Ingress路径 #

改造Redirect逻辑，避免直接返回Pod内部IP：

• 基于Headless Service获取的Pod列表，通过K8s API自动为每个Worker Pod创建对应的Ingress路径规则（比如/worker/{pod-name}），将路径与Pod绑定。
• 负载均衡器不再返回Pod的IP:Port，而是返回对应的Ingress路径URL。客户端重定向到该路径后，Ingress会将请求转发到对应的Worker Pod，既实现了负载均衡器的调度作用，又避免了代理转发，同时确保外部能正常访问。

方案四：结合NodePort Service实现客户端直连Pod #

利用NodePort的特性让客户端直接访问Pod所在节点的外部地址：

• 将Worker Service配置为NodePort类型，负载均衡器通过Headless Service获取每个Pod所在的Node信息以及对应的NodePort。
• 负载均衡器返回Node的外部IP+NodePort给客户端，客户端直接发起请求到该地址，流量会通过NodePort转发到目标Pod。此方案需要确保集群节点的外部IP对客户端可访问，且NodePort的端口范围提前规划。

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