Cluster IP Service请求路由与Pod选择逻辑技术问询

问题1：当请求发送至ClusterIP Service时，若对应多个Pod，服务如何选择目标Pod？由什么组件控制决策？ #

• 核心控制组件是kube-proxy，它运行在集群的每个节点上，负责维护ClusterIP到后端Pod的路由转发规则。
• 前置逻辑：kube-controller-manager会实时监听Pod的生命周期变化，维护EndpointSlice（或旧版Endpoints）资源，该资源记录了当前与Service关联的所有健康Pod的IP地址和端口信息。
• 具体选择逻辑由kube-proxy在节点层面实现：
  • 若使用默认的iptables模式：kube-proxy会在节点上生成对应的iptables规则，默认采用随机策略选择后端Pod；你也可以通过配置Service的spec.sessionAffinity字段开启会话保持，让同一客户端的请求持续路由到同一个Pod。
  • 若使用IPVS模式：支持更多负载均衡策略（如轮询、最小连接数、加权轮询等），kube-proxy会在节点上配置IPVS虚拟服务器，根据预设策略分配请求到后端Pod。

问题2：选定Pod并发送请求后，Pod内部是否存在kube-proxy添加的iptables规则？Pod会再次转发/负载均衡请求，还是直接处理？ #

• Pod内部不存在kube-proxy配置的iptables规则，所有转发规则都部署在Pod所在的集群节点上。
• 当请求通过节点的iptables/IPVS规则转发到目标Pod的IP和端口后，Pod会直接接收并处理请求，不会进行二次转发或负载均衡——因为路由和负载均衡逻辑已经在节点层面完成，Pod只需要处理业务请求本身。

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