用户访问k8s的svc后流量是怎么打到具体的某一个pod上的？

当用户访问 Kubernetes Service 时流量是如何精准路由到某一个具体 Pod 的这背后的机制非常精妙可以拆解为“地址簿 负载均衡”的组合。核心流程三层转发整个过程可以概括为Service 的 VIP 是入口Endpoints/EndpointSlice 是动态名单实际转发工作由每个节点的“小管家”kube-proxy完成。第 1 步建立动态“服务地址簿”当你创建一个 Service 时Kubernetes 会自动创建并维护一个名为Endpoints或更高效的 EndpointSlice的对象。作用这个对象里实时记录着所有匹配该 Service 标签选择器的、且处于就绪状态Readiness Probe 通过的 Pod 的 IP:Port 列表。动态更新Pod 被创建、销毁、或健康状态变化时这个列表会被自动更新。这是流量能正确转发的数据基础。查看命令kubectl get endpoints service-name第 2 步节点“小管家”接收转发任务集群每个节点上运行的kube-proxy是这个过程的执行者。它一直监听 API Server 的 Endpoints 和 Service 变化。一旦 Service 或它的 Endpoints 发生变化kube-proxy 就会采取行动将“如何将流量发往 Pod”的规则写入到本机操作系统的网络层。kube-proxy 主要支持三种模式三种转发模式原理不同这是理解的关键kube-proxy 将“地址簿”信息转化为具体的网络规则。模式 1iptables 模式默认最常用原理kube-proxy 不转发流量只当“规则配置员”。它在每个节点的 Linux 内核中设置一大堆iptables 规则链。当访问 Service 的ClusterIP:Port时iptables 规则会自动对目标 IP 和端口进行DNAT目标网络地址转换。DNAT 的结果是将目标Service 的虚拟IP随机地替换为 Endpoints 列表中的一个Pod 的实际 IP:Port。特点纯内核态转发高效稳定。负载均衡是随机的有概率权重。流量路径短。查看规则iptables-save | grep service-name模式 2IPVS 模式适合超大规模服务原理kube-proxy 使用更专业的IPVSIP Virtual Server内核模块来配置规则。它仍然不转发数据但配置的规则更高效。支持更多负载均衡算法轮询rr、最短连接lc、目标哈希dh等。特点性能极高连接数很大时比 iptables 更省 CPU调度算法丰富。是生产环境大规模集群的推荐模式。模式 3userspace 模式已过时仅作了解原理kube-proxy 自己真的开一个本地端口来代理流量。流量会从内核 - 用户态的 kube-proxy - 再回到内核 - Pod。路径很长。特点性能差基本不再使用。完整流程示例以默认 iptables 模式为例客户端在 Pod A 内访问服务名curl http://my-svc.default.svc.cluster.local:8080系统 DNS或 CoreDNS将其解析为 Service 的ClusterIP如 10.96.0.12。Pod A 发起的流量目标变为10.96.0.12:8080。流量进入 Pod A 所在节点的网络栈iptables 规则被匹配。iptables 的KUBE-SVC-XXX链执行DNAT从my-svc对应的 Endpoints 列表中随机选一个 Pod IP如 172.16.1.5将目标改为172.16.1.5:8080。节点内核根据本机路由规则将数据包转发到目标 Pod172.16.1.5所在的节点可能跨节点。目标 Pod 收到请求并回复。关键总结Service 本身不转发它只是一个虚拟的、稳定的访问入口和抽象层。kube-proxy 是关键组件它负责将“访问 Service IP”的规则配置到每个节点的内核中。Endpoints 是灵魂是它建立了 Service 和真实 Pod 的动态映射关系。流量路径是“分布式负载均衡”流量在发起请求的客户端所在节点的网络层就被 iptables/IPVS 转发到目标 Pod 了并不是由一个中心化的负载均衡器转发。