协同和工作过程：
当使用 kubectl创建一个 Service 时，这个 Service 的规范（包括它的名称、ClusterIP、标签选择器等）会被作为一个 API 对象保存到 Master 节点的 etcd 存储中
。
分发与同步：每个 Worker 节点上运行的 kube-proxy组件会持续地监控（watch）API Server，以便及时发现 Service 和其后端 Pod（通过 Endpoints 或 EndpointSlice 对象跟踪）的变化
。
本地规则生效：一旦 kube-proxy感知到变化，它就会在本节点上更新相应的网络规则（通常是 iptables 或性能更优的 IPVS 规则）
。这些规则的核心作用是："当有数据包发往 Service 的 ClusterIP 和端口时，将其负载均衡地转发到某个健康 Pod 的 IP 和端口上"。
总结意义：
一致的访问体验：正因为每个节点都有完整的转发规则，所以无论你的客户端 Pod 运行在集群中的 任何一个节点 上，它都可以通过 Service 的 ClusterIP 或 DNS 名称访问到后端服务。请求到了某个节点，该节点上的规则就会负责将其正确转发。
高可用性：即使某个 Worker 节点宕机，只要 Service 的后端 Pod 还在其他健康的节点上运行，那么从存活节点发起的服务访问就不会受到影响。因为每个节点的转发规则是独立的。
与 Ingress 的分工：需要注意的是，Service 默认是四层（TCP/UDP）的抽象
。而通常处理七层（HTTP/HTTPS）路由的 Ingress 控制器本身也以一个或多个 Pod 的形式运行在 Worker 节点上，它需要依赖一个类型为 ClusterIP或 NodePort的 Service 来接收流量
。所以，Ingress Controller Pod 和 kube-proxy 是分别独立的两个 Pod