使用Ingress做负载分发是否需要kube-proxy？相关机制疑问

问题1：使用Ingress进行负载分发时是否需要kube-proxy？是否仅在使用LoadBalancer和NodePort时才需要kube-proxy，而Ingress直接获取endpoint分发到pod？ #

• 答案取决于Ingress Controller的实现方式：
  • 主流Ingress Controller（如NGINX Ingress、Traefik）默认会直接通过K8s API获取Service对应的Endpoint列表，直接将流量转发到Pod的IP和端口，这种场景下不需要kube-proxy参与Ingress到Pod的流量路径。
  • LoadBalancer和NodePort类型的Service确实依赖kube-proxy，因为kube-proxy负责在节点上维护Service的ClusterIP到Pod的转发规则（如iptables、IPVS）。
  • 特殊情况：如果手动配置Ingress将流量转发到Service的ClusterIP，此时流量会先到Service，再由kube-proxy转发到Pod，这种场景就需要kube-proxy，但这不是Ingress的典型用法。

问题2：若认为Ingress仅负责路由到Service的负载，Service到Pod的负载仍由kube-proxy完成的理解有误，正确机制是什么？ #

• 这个理解不是完全错误，但只覆盖了一种特殊场景，正确的机制分两种：
  • 直接转发到Pod（主流场景）：Ingress Controller会监听K8s的Service、Endpoint、Pod资源变化，实时更新自身的转发规则。当请求进入时，直接根据Ingress定义的路由规则，将流量分发到对应Pod的IP和端口，负载均衡由Ingress Controller自身实现（比如NGINX的upstream配置），完全绕开kube-proxy。
  • 转发到Service ClusterIP（特殊场景）：若配置Ingress指向Service的ClusterIP，流量会先到达Service，再由kube-proxy通过iptables/IPVS规则转发到Pod，此时Service到Pod的负载由kube-proxy完成。这种方式通常用于需要利用Service特定特性（如会话保持）的场景。

问题3：此前查到Ingress不使用kube-proxy做负载，对此存疑，想了解原因及Ingress如何实现kube-proxy相关功能？ #

• Ingress不依赖kube-proxy的核心原因：Ingress Controller本身具备负载均衡能力，无需借助kube-proxy的转发规则。

• Ingress Controller实现类似kube-proxy功能的方式：

  1. 监听K8s资源变化：通过K8s API持续监听Ingress、Service、Endpoint、Pod的状态变更，实时同步后端Pod的信息。
  2. 直接管理后端Pod：将获取到的Endpoint列表（即Pod的IP和端口）配置为自身的后端服务器，通过内置的负载均衡算法（如轮询、加权轮询）分发流量。
  3. 替代kube-proxy的转发逻辑：kube-proxy的核心是维护Service到Pod的转发规则，而Ingress Controller直接跳过Service层，直接对接Pod，相当于自行实现了流量从入口到Pod的负载分发，不需要依赖kube-proxy的iptables/IPVS规则。

• 补充说明：Ingress本身只是K8s的路由规则定义资源，真正处理流量、实现负载分发的是Ingress Controller，所有核心逻辑都由Controller完成。

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