K8s Service到Pod流量路径：kube-proxy与iptables/IPVS原理详解-北京尧图网络

先说结论K8s里Service到Pod的流量路径本质上就是一次“虚拟IP寻址”到“真实Endpoint”的精准转发。整个过程由kube-proxy、内核网络栈和一组名为Endpoints新版叫EndpointSlice的对象协同完成。你可以把它理解成公司前台的电话总机——你拨一个总机号码ClusterIP总机根据分机表Endpoints把电话转到某个具体座席Pod IP至于转给谁规则可以是轮询、随机也可以按来源IP“粘住”。这篇笔记我会从实际运维视角把这条链路彻底拆开讲清楚。读完你会明白为什么Service的ClusterIP在节点上压根ping不通但TCP却能访问、kube-proxy的iptables和IPVS模式到底差在哪、为什么有时候请求会“莫名其妙”跑到别的节点上以及排查Service访问异常时该往哪个方向看。内容主要面向正在学习K8s网络原理的初学者也适合被Service转发问题折磨过的集群维护者当作排查手册。1. Service与Pod之间的映射关系1.1 三个角色Service、Pod、Endpoints先明确三个最基础的对象搞不清它们的关系后面全都会糊。Pod真正跑容器的“计算单元”有独立的IP地址Pod IP但这个IP是“一次性”的——Pod被重建比如滚动更新、崩溃重启或者被人误删后IP就会变。这也是Service存在的根本原因不能指望用一个不断变化的IP去访问一组服务。Service为一组Pod提供一个稳定的访问入口这个入口的IP叫ClusterIP集群内虚拟IP。它不绑定任何真实网卡纯粹是“逻辑存在”。Endpoints / EndpointSlice把Service和Pod真正“绑”起来的那张分机表。里面记录的是这个Service背后当前到底有哪些Pod的IP和端口。举例来说如果你创建了这样一个ServiceapiVersion: v1 kind: Service metadata: name: myapp-svc spec: selector: app: myapp ports: - port: 80 # Service暴露的端口 targetPort: 8080 # Pod内容器实际监听的端口那么Controller Manager里的Service控制器会持续干一件事扫描带有appmyapp标签的Pod把它们收集起来写进Endpoints对象。用一句话概括三者的关系用户访问Service稳定Service通过Label Selector标签选择器找到Pod动态最后把流量交给具体的Pod IP和容器端口处理。1.2 为什么不用Pod IP直接访问很多人最开始会好奇既然Pod都有IP直接访问Pod IP不行吗单个Pod当然可以但一旦你有多个副本问题就来了Pod IP不持久 Deployment滚动更新时旧Pod被销毁、新Pod被创建IP全变客户端无法配置一个永远有效的地址。没有负载均衡 3个副本就想手动轮流访问服务端的Pod数量动态扩缩容客户端根本无从感知。没有健康检查剔除某个Pod因为OOM内存溢出或探针失败已经不能服务了谁会把它自动摘除Service把这些问题全解决了你只管访问一个固定ClusterIP背后的Pod列表由系统自动维护挂了就自动摘掉扩容了就自动加进来。这个“自动维护”功劳的一半得归给Service控制器另一半归给kube-proxy。2. 流量转发的真正执行者kube-proxy2.1 kube-proxy到底在干什么kube-proxy是跑在每个节点上的一个DaemonSet组件一般以static Pod或DaemonSet方式运行。它做的事概括起来就一句话Watch监听API Server上的Service和Endpoints变化然后同步到本节点的内核网络规则里。准确地说kube-proxy不处理实际数据包它只是规则的“搬运工”。真正的流量转发发生在Linux内核的数据通路上。kube-proxy把Service的ClusterIP、端口、后端Pod列表翻译成内核规则之后的数据包怎么走、走到哪全是内核的事。kube-proxy支持三种工作模式这个一定要分清因为排查问题时你首先得知道自己的模式模式实现机制性能/规模上限现状userspace用户态代理程序转发低已淘汰老古董版本用iptables内核Netfilter规则链中型规模几百~几千条规则性能可接受默认普及率最高ipvs内核IPVS模块哈希表调度算法高万级服务无压力生产推荐2.2 iptables模式的核心链路iptables模式是最经典的实现它利用Linux内核的NAT网络地址转换能力。当集群里的Pod发出一个目的IP为ClusterIP的请求时这个包在出口会经过一连串iptables链的检查。你可以用这个命令亲眼看到规则iptables -t nat -S | grep -A 20 KUBE-SERVICES这会在每个节点上生成类似下面的规则结构。我以最简方式描述这条链路PREROUTING / OUTPUT ↓ KUBE-SERVICES判断目的IP是否为ClusterIP端口是否匹配 ↓ KUBE-SVC-XXXXX这个Service专属链 ↓ KUBE-SEP-AAA转发到具体Pod默认情况下kube-proxy在iptables模式为每个Service生成一条KUBE-SVC-XXX链链中有几条KUBE-SEP-XXX规则就代表这个Service后面有几个Pod。每条规则带一个statistic mode random probability参数——这就是负载均衡的实现原理按概率随机挑一个Endpoints概率大体均等。2.3 从一台Pod侧发出的访问走哪条路径这里有一个细节很多刚学的朋友会忽略。K8s集群里的数据包可能经过这样一条路径客户端Pod A发起请求 → 目的IP是Service的ClusterIP:80包从Pod A的veth对进入节点A的根网络命名空间命中节点A上iptables的OUTPUT链因为是本机进程发出或PREROUTING链如果是外部流量进入节点在KUBE-SVC-XXX链里选一个后端Pod把目的IP从ClusterIP改成后端Pod IPDNAT如果后端Pod在本节点节点A包直接走本机路由通过veth进入目标Pod如果后端Pod在别的节点节点B节点A会把这个包转发给节点B的物理网卡IP节点B收到后再转给本节点的Pod这里就有K8s里的一个经典概念转发到其他节点时会经历一次额外的“跨节点跳转”这个跳转走的是节点之间的网络。这也是为什么Service访问会有额外的网络延迟而且如果后端Pod全在别的节点所有流量都存在跨节点开销。2.4 为什么ClusterIP在节点上ping不通这是几乎所有K8s初学者都会踩的坑在节点上输入ping 10.96.0.10永远ping不通但用curl它的端口却能通。原因在于第一ClusterIP是一个虚拟IP没有任何网卡绑定它。ICMPping使用的协议到内核后没有设备会认领这个IP的ARP请求所以它“不存在”。第二Service的iptables规则只匹配特定协议特定端口TCP/UDP/SCTP。你ping它用的是ICMP协议不在规则处理范围内所以包根本没有被DNAT翻译直接走的正常路由而正常路由没有这个IP自然就不可达。第三即使你在Service里指定了ICMP协议的端口比如NodePort类型ping通也是一种特例。在实践中请不要用ping来测试Service连通性用curl、telnet或自带的HTTP探测工具才是正路。2.5 浅谈IPVS模式的差异IPVS模式是目前生产环境推荐方案。它和iptables核心差别在于数据结构iptables靠的是线性链遍历每个包都要从头到尾匹配规则。Service数量一多规则膨胀到几万条性能下降很明显。IPVS维护的是一个哈希表查表匹配是O(1)复杂度即便Service上万转发性能依然稳定。IPVS的工作方式就好像给内核里塞了一张“转发表”每个Service对应一个IPVS virtual server每个Pod对应一个IPVS real server调度算法可配置rr轮询、wrr加权轮询、lc最少连接、sh源IP哈希等用IPVS模式后查规则的方式从“从头数链”变成“哈希找表”速度快了一个量级。在大型生产集群里Service数量超过5000时iptables模式的规则查找会造成明显的转发延迟波动而IPVS模式的曲线非常平稳。3. 验证与排查亲手追踪一次转发路径3.1 查看Service背后的Endpoint第一步永远先确认“这个Service背后到底挂了几个Pod”。三种命令三层视角# 1. 看Service基本信息 kubectl get svc myapp-svc # 2. 看Endpoints这是最直观的分机表 kubectl get endpoints myapp-svc # 3. 看EndpointSlice新版推荐承载了实际转发所需数据 kubectl get endpointslices -l kubernetes.io/service-namemyapp-svc -o yaml正常返回里Endpoints下面会列出若干个ip:port对。比如ADDRESSES PORTS 10.244.1.20:8080 8080 10.244.2.31:8080 8080 10.244.3.14:8080 8080这就代表这个Service背后有3个Pod在服务。如果查出来No endpoints那就是标签选择器没匹配上任何Pod。这是Service不通的“第一大嫌疑点”。3.2 用iptables命令实际追踪DNAT规则找一台节点登录上去先确认当前节点上的后端Pod情况然后执行# 找到Service对应的链 iptables -t nat -L | grep myapp-svc一般输出长这样KUBE-SVC-J5A2... tcp -- anywhere 10.96.0.10 tcp dpt:80然后进这个链看iptables -t nat -L KUBE-SVC-J5A2... -n -v你会看到有若干规则的destination是具体Pod IP同时带概率参数。-v参数会显示每条规则的包和字节计数这个信息极其有用如果某条规则的计数始终是0说明这个后端Pod从来没被选中过要么是概率太小要么是它本身不健康。还有一种更接近实际转发的验证手段用conntrack工具看连接跟踪表里面记录了真实的DNAT映射。# 列出当前NAT跟踪记录 conntrack -L | grep 10.96.0.10输出里你会看到类似这样的记录tcp 6 431999 ESTABLISHED src10.244.1.5 dst10.96.0.10 sport35672 dport80 src10.244.2.31 dst10.244.1.5 sport8080 dport35672这个记录本质上就是一次“访问ClusterIP被翻译成PodIP”的完整证据链原来的目的IP和端口dst10.96.0.10 dport80被替换成了后端Pod的IP和端口src10.244.2.31 sport8080。3.3 如何切换kube-proxy到IPVS模式如果你集群规模大想切IPVS模式操作并不复杂但需要确保节点上有内核模块# 检查内核模块 lsmod | grep ip_vs lsmod | grep nf_conntrack_ipv4如果没有就加载modprobe ip_vs modprobe ip_vs_rr modprobe nf_conntrack确认模块OK后修改kube-proxy的ConfigMapkubectl edit configmap kube-proxy -n kube-system把mode那一行从空或iptables改成ipvs保存后重启kube-proxy。提示切换IPVS后原来在iptables里的KUBE-SVC-XXX链会消失Service转发完全交给IPVS模块。曾经依赖iptables规则排查问题的手段在IPVS模式下全部失效你不能再查iptables了但可以查ipvsadm -Ln输出是一张清晰的服务与后端对应表。输出好的整理一下思路。这条问题的核心不是“K8s有什么”而是“K8s怎么做到的”。用户既然把热搜词里放了一堆“k8s学习笔记”“namespace”“redis集群”之类的内容大概率是个刚开始接触K8s、被Service转发绕晕了的新手。这篇文章得从底层链路逐步拆解不能只写概念要把“ClusterIP怎么变成PodIP”这条链路写实写透。我打算分四个章节第一节先讲Service和Pod的映射关系把Endpoints这个承上启下的关键对象讲明白第二节是重点拆解kube-proxy的三种模式尤其把iptables的NAT链和数据包路径写清楚第三节给出实操追踪方法让读者能亲手验证一次转发过程第四节收尾把生产环境中真正会踩的坑和排查思路整理出来。写作上要注意得用“打电话总机”这种生活化类比降低理解门槛但又不能丢掉关键技术细节。iptables的链名、conntrack的记录、ipvsadm的输出这些都要给真实的命令和真实样式的输出。段落尽量口语化但有信息密度避免AI式的“首先其次最后”和凭空总结。先说结论K8s里Service到Pod的流量路径本质上就是一次“虚拟IP寻址”到“真实Endpoint”的精准转发。整个过程由kube-proxy、内核网络栈和一组名为Endpoints新版叫EndpointSlice的对象协同完成。你可以把它理解成公司前台的电话总机——你拨一个总机号码ClusterIP总机根据分机表Endpoints把电话转到某个具体座席Pod IP至于转给谁规则可以是轮询、随机也可以按来源IP“粘住”。这篇笔记我会从实际运维视角把这条链路彻底拆开讲清楚。读完你会明白为什么Service的ClusterIP在节点上压根ping不通但TCP却能访问、kube-proxy的iptables和IPVS模式到底差在哪、为什么有时候请求会“莫名其妙”跑到别的节点上以及排查Service访问异常时该往哪个方向看。内容主要面向正在学习K8s网络原理的初学者也适合被Service转发问题折磨过的集群维护者当作排查手册。1. Service与Pod之间的映射关系1.1 三个角色Service、Pod、Endpoints先明确三个最基础的对象搞不清它们的关系后面全都会糊。Pod真正跑容器的“计算单元”有独立的IP地址Pod IP但这个IP是“一次性”的——Pod被重建比如滚动更新、崩溃重启或者被人误删后IP就会变。这也是Service存在的根本原因不能指望用一个不断变化的IP去访问一组服务。Service为一组Pod提供一个稳定的访问入口这个入口的IP叫ClusterIP集群内虚拟IP。它不绑定任何真实网卡纯粹是“逻辑存在”。Endpoints / EndpointSlice把Service和Pod真正“绑”起来的那张分机表。里面记录的是这个Service背后当前到底有哪些Pod的IP和端口。举例来说如果你创建了这样一个ServiceapiVersion: v1 kind: Service metadata: name: myapp-svc spec: selector: app: myapp ports: - port: 80 # Service暴露的端口 targetPort: 8080 # Pod内容器实际监听的端口那么Controller Manager里的Service控制器会持续干一件事扫描带有appmyapp标签的Pod把它们收集起来写进Endpoints对象。用一句话概括三者的关系用户访问Service稳定Service通过Label Selector标签选择器找到Pod动态最后把流量交给具体的Pod IP和容器端口处理。1.2 为什么不用Pod IP直接访问很多人最开始会好奇既然Pod都有IP直接访问Pod IP不行吗单个Pod当然可以但一旦你有多个副本问题就来了Pod IP不持久 Deployment滚动更新时旧Pod被销毁、新Pod被创建IP全变客户端无法配置一个永远有效的地址。没有负载均衡 3个副本就想手动轮流访问服务端的Pod数量动态扩缩容客户端根本无从感知。没有健康检查剔除某个Pod因为OOM内存溢出或探针失败已经不能服务了谁会把它自动摘除Service把这些问题全解决了你只管访问一个固定ClusterIP背后的Pod列表由系统自动维护挂了就自动摘掉扩容了就自动加进来。这个“自动维护”功劳的一半得归给Service控制器另一半归给kube-proxy。2. 流量转发的真正执行者kube-proxy2.1 kube-proxy到底在干什么kube-proxy是跑在每个节点上的一个DaemonSet组件一般以static Pod或DaemonSet方式运行。它做的事概括起来就一句话Watch监听API Server上的Service和Endpoints变化然后同步到本节点的内核网络规则里。准确地说kube-proxy不处理实际数据包它只是规则的“搬运工”。真正的流量转发发生在Linux内核的数据通路上。kube-proxy把Service的ClusterIP、端口、后端Pod列表翻译成内核规则之后的数据包怎么走、走到哪全是内核的事。kube-proxy支持三种工作模式这个一定要分清因为排查问题时你首先得知道自己的模式模式实现机制性能/规模上限现状userspace用户态代理程序转发低已淘汰老古董版本用iptables内核Netfilter规则链中型规模几百~几千条规则性能可接受默认普及率最高ipvs内核IPVS模块哈希表调度算法高万级服务无压力生产推荐2.2 iptables模式的核心链路iptables模式是最经典的实现它利用Linux内核的NAT网络地址转换能力。当集群里的Pod发出一个目的IP为ClusterIP的请求时这个包在出口会经过一连串iptables链的检查。你可以用这个命令亲眼看到规则iptables -t nat -S | grep -A 20 KUBE-SERVICES这会在每个节点上生成类似下面的规则结构。我以最简方式描述这条链路PREROUTING / OUTPUT ↓ KUBE-SERVICES判断目的IP是否为ClusterIP端口是否匹配 ↓ KUBE-SVC-XXXXX这个Service专属链 ↓ KUBE-SEP-AAA转发到具体Pod默认情况下kube-proxy在iptables模式为每个Service生成一条KUBE-SVC-XXX链链中有几条KUBE-SEP-XXX规则就代表这个Service后面有几个Pod。每条规则带一个statistic mode random probability参数——这就是负载均衡的实现原理按概率随机挑一个Endpoints概率大体均等。2.3 从一台Pod侧发出的访问走哪条路径这里有一个细节很多刚学的朋友会忽略。K8s集群里的数据包可能经过这样一条路径客户端Pod A发起请求 → 目的IP是Service的ClusterIP:80包从Pod A的veth对进入节点A的根网络命名空间命中节点A上iptables的OUTPUT链因为是本机进程发出或PREROUTING链如果是外部流量进入节点在KUBE-SVC-XXX链里选一个后端Pod把目的IP从ClusterIP改成后端Pod IPDNAT如果后端Pod在本节点节点A包直接走本机路由通过veth进入目标Pod如果后端Pod在别的节点节点B节点A会把这个包转发给节点B的物理网卡IP节点B收到后再转给本节点的Pod这里就有K8s里的一个经典概念转发到其他节点时会经历一次额外的“跨节点跳转”这个跳转走的是节点之间的网络。这也是为什么Service访问会有额外的网络延迟而且如果后端Pod全在别的节点所有流量都存在跨节点开销。2.4 为什么ClusterIP在节点上ping不通这是几乎所有K8s初学者都会踩的坑在节点上输入ping 10.96.0.10永远ping不通但用curl它的端口却能通。原因在于第一ClusterIP是一个虚拟IP没有任何网卡绑定它。ICMPping使用的协议到内核后没有设备会认领这个IP的ARP请求所以它“不存在”。第二Service的iptables规则只匹配特定协议特定端口TCP/UDP/SCTP。你ping它用的是ICMP协议不在规则处理范围内所以包根本没有被DNAT翻译直接走的正常路由而正常路由没有这个IP自然就不可达。第三即使你在Service里指定了ICMP协议的端口比如NodePort类型ping通也是一种特例。在实践中请不要用ping来测试Service连通性用curl、telnet或自带的HTTP探测工具才是正路。2.5 浅谈IPVS模式的差异IPVS模式是目前生产环境推荐方案。它和iptables核心差别在于数据结构iptables靠的是线性链遍历每个包都要从头到尾匹配规则。Service数量一多规则膨胀到几万条性能下降很明显。IPVS维护的是一个哈希表查表匹配是O(1)复杂度即便Service上万转发性能依然稳定。IPVS的工作方式就好像给内核里塞了一张“转发表”每个Service对应一个IPVS virtual server每个Pod对应一个IPVS real server调度算法可配置rr轮询、wrr加权轮询、lc最少连接、sh源IP哈希等用IPVS模式后查规则的方式从“从头数链”变成“哈希找表”速度快了一个量级。在大型生产集群里Service数量超过5000时iptables模式的规则查找会造成明显的转发延迟波动而IPVS模式的曲线非常平稳。3. 验证与排查亲手追踪一次转发路径3.1 查看Service背后的Endpoint第一步永远先确认“这个Service背后到底挂了几个Pod”。三种命令三层视角# 1. 看Service基本信息 kubectl get svc myapp-svc # 2. 看Endpoints这是最直观的分机表 kubectl get endpoints myapp-svc # 3. 看EndpointSlice新版推荐承载了实际转发所需数据 kubectl get endpointslices -l kubernetes.io/service-namemyapp-svc -o yaml正常返回里Endpoints下面会列出若干个ip:port对。比如ADDRESSES PORTS 10.244.1.20:8080 8080 10.244.2.31:8080 8080 10.244.3.14:8080 8080这就代表这个Service背后有3个Pod在服务。如果查出来No endpoints那就是标签选择器没匹配上任何Pod。这是Service不通的“第一大嫌疑点”。3.2 用iptables命令实际追踪DNAT规则找一台节点登录上去先确认当前节点上的后端Pod情况然后执行# 找到Service对应的链 iptables -t nat -L | grep myapp-svc一般输出长这样KUBE-SVC-J5A2... tcp -- anywhere 10.96.0.10 tcp dpt:80然后进这个链看iptables -t nat -L KUBE-SVC-J5A2... -n -v你会看到有若干规则的destination是具体Pod IP同时带概率参数。-v参数会显示每条规则的包和字节计数这个信息极其有用如果某条规则的计数始终是0说明这个后端Pod从来没被选中过要么是概率太小要么是它本身不健康。还有一种更接近实际转发的验证手段用conntrack工具看连接跟踪表里面记录了真实的DNAT映射。# 列出当前NAT跟踪记录 conntrack -L | grep 10.96.0.10输出里你会看到类似这样的记录tcp 6 431999 ESTABLISHED src10.244.1.5 dst10.96.0.10 sport35672 dport80 src10.244.2.31 dst10.244.1.5 sport8080 dport35672这个记录本质上就是一次“访问ClusterIP被翻译成PodIP”的完整证据链原来的目的IP和端口dst10.96.0.10 dport80被替换成了后端Pod的IP和端口src10.244.2.31 sport8080。3.3 如何切换kube-proxy到IPVS模式如果你集群规模大想切IPVS模式操作并不复杂但需要确保节点上有内核模块# 检查内核模块 lsmod | grep ip_vs lsmod | grep nf_conntrack_ipv4如果没有就加载modprobe ip_vs modprobe ip_vs_rr modprobe nf_conntrack确认模块OK后修改kube-proxy的ConfigMapkubectl edit configmap kube-proxy -n kube-system把mode那一行从空或iptables改成ipvs保存后重启kube-proxy。提示切换IPVS后原来在iptables里的KUBE-SVC-XXX链会消失Service转发完全交给IPVS模块。曾经依赖iptables规则排查问题的手段在IPVS模式下全部失效你不能再查iptables了但可以查ipvsadm -Ln输出是一张清晰的服务与后端对应表。4. 生产环境里围绕Service的坑与排查思路4.1 最常犯的错标签选择器写错Service找不到后端90%的案例都是标签问题。kubectl get endpoints myapp-svc显示No endpoints时从两方面查查Pod标签kubectl get pods -l appmyapp能搜到Pod吗搜不到说明Pod上没有这个标签。查Selectorkubectl get svc myapp-svc -o yaml | grep selector检查选择器里的key/value和Pod标签是否完全一致注意一个字符都不能差。最常见的问题就是Pod里写的是app: my-appService里写的是app: myapp看着差不多实际不匹配。4.2 健康检查与“不健康Pod”的移除机制只有当Pod处于Ready状态时它的IP才会出现在Endpoints列表里。具体来说如果Pod定义了readinessProbe就绪探针探针失败会让Pod变为NotReady控制器会立即把它从Endpoints中摘除但容器不会被杀掉。如果Pod没有定义readinessProbe那么只要容器进程起来它就会被认为是“健康的”。这就意味着应用内部依赖了数据库或配置中心虽然TCP端口能连上但无法真正处理业务流量照样会打过去然后报一堆5xx错。解决办法是给每个工作负载都写上有效的readinessProbe最好探测的是业务能对外提供服务的真实接口比如/healthz或/api/v1/ping而不是简单探测一个默认端口。4.3 外部流量进集群后的路径差异上面讨论的主要是集群内部的Pod访问Service。如果你通过NodePort或LoadBalancer从外部访问链路会多两段外部客户端 → NodeIP:NodePort → 节点iptables DNAT → ClusterIP:ServicePort → PodIP:targetPort这里有个K8s里讨论度极高的问题源IP到底保不保得住请求打到NodePort再转发Node节点做了SNAT源地址转换Pod里看到来源IP是节点IP而不是真实客户端IP。如果来自节点本机的请求默认不做SNAT因为返回路径不需要跨节点Pod里能看到节点IP。只有配置externalTrafficPolicy: Local时流量只会转发到本节点上的Pod同时保留客户端源IP代价是可能出现负载不均某些节点没Pod就接不到流量。所以生产环境遇到“客户端真实IP拿不到”的问题基本上都是externalTrafficPolicy没设置成Local或者是经过了一层SNAT。4.4 连接不均衡概率算法和长连接在iptables模式下做负载均衡它用的是随机概率不是真正意义上的平滑权重轮询。几个副本同时接到大量短连接时单个连接的分布看起来是均匀的但一旦涉及长连接比如只建立几个WebSocket连接所有连接可能恰好落在同一个Pod上另一台Pod完全空闲。这是iptables模式的天然缺陷它做不了每连接级别的智能调度。如果业务对负载均衡的准确性要求高建议直接上IPVS模式并且把调度算法改成lc最少连接。这是生产环境保证连接均衡最直接的办法。4.5 Service的DNS解析与集群域名集群里Pod访问Service还可以走DNS由CoreDNS负责解析。域名规则大概是service-name.namespace.svc.cluster.local这也是个出问题的高发区。几个常见症状应用部署好之后ping域名不通先检查Pod的resolv.conf里的nameserver是不是集群DNS的ClusterIP还有search domain有没有配对。跨namespace访问失败默认情况下一个namespace里的Pod不能直接用短域名访问另一个namespace的Service得写全service-name.namespace.svc。间歇性DNS解析失败看CoreDNS是否出现了OOM或replica太少尤其在高并发解析的场景下CoreDNS的副本数和资源限制都得预留足量。4.6 需要重点留意的NodePort端口冲突NodePort模式下Service暴露的端口范围默认是30000-32767。如果集群规模大、Service数量多这个区间很容易耗尽。管理时建议提前规划端口段每个Service尽量显式指定nodePort别全部靠自动分配。不然哪一天新上线一个Service得到的NodePort和防火墙已经开放的端口对不上查半天才发现是端口分配混乱。5. 写在最后Service是怎么把流量打到具体Pod上的拆开来看其实就三步kube-proxy监控API Server获取Service和Endpoints变化把数据翻译成内核转发规则数据包经内核Netfilter查表完成从ClusterIP到PodIP的DNAT转换最后按负载均衡规则选一个健康的后端Pod把请求送进去。在我实际排查过的大量案例里Service“不通”的问题根源往往不在网络模型本身而是集中在标签匹配、就绪探针、CoreDNS解析、跨节点转发这几类细节上。一句话总结就是K8s的网络原理并没有多玄乎关键是把每个环节里那一个“谁在看谁、谁在改谁的包”搞清楚。如果你还遇到过其他奇特的Service转发问题或者对某个环节的细节有疑问欢迎在评论里一起讨论。特别是你集群里如果用的是Calico、Flannel、Cilium这类不同CNI插件它们会影响跨节点转发那一层但Service到Pod的DNAT规则基本都遵循这套模型。搞清楚这一层后面再学Ingress、Gateway API、服务网格都会顺很多。

K8s Service到Pod流量路径：kube-proxy与iptables/IPVS原理详解

相关推荐

纯Java实现YOLOv5推理：算子复现与精度反超实战

MySQL执行计划possible_keys深度解析：从索引候选到优化器决策

Android Studio Inspection位置全解析：从菜单到结果面板

更多资讯

context-mode 上下文管理：从原理到实战的工程实践指南

SpringBoot+Vue员工管理系统：从数据库设计到前后端部署全解析

OMTP与CTIA耳机接口标准详解：线序差异、判断方法与兼容改造

分布式电源接入配电网影响分析：Matlab前推回代法仿真实现

直播APP全局美颜技术指南：从SDK原理到接入实战

C语言数据结构实验编译与调试实战指南

今日更新

Multisim仿真NE555 PWM控制器：从搭电路到调占空比全流程

S32K312 AUTOSAR BSW开发实战：从配置踩坑到烧录交付

双目视觉三维人脸重建：从视差图到点云粗配准全流程解析

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？