前阵子有个做电商的小团队找到我线上服务无故超时K8s 集群里 Service 显示正常、Pod 全部 Running、就绪探针也过了但流量就是偶发失败。当时我带着 tcpdump 和 ipvsadm 蹲了一下午。查到最后问题不是别的就是 ClusterIP 这个大家每天用、却很少有人真正吃透的虚拟 IP。其实很多人在入门 K8s 网络时对 Service 的第一印象就是“给 Pod 提供一个稳定的访问入口”ClusterIP 就是这个入口的地址。可是当真正出现流量不通、延迟抖动、DNS 解析失败这些问题时你会发现光会创建 Service 远远不够。搞不清 ClusterIP 在哪里生效、转发规则怎么生成、跟 Pod 的真实 IP 是什么关系排查起来就像大海捞针。这篇文章把我这些年踩过的 ClusterIP 相关的坑和拆解过程写下来。内容不图多都是实际集群里会遇到的事适合正在入门 K8s 网络、被 Service 流量搞得头疼的开发者也适合想在生产环境做调优的运维同学。1. 先纠正一个直觉ClusterIP 不是一台服务器1.1 ClusterIP 到底存在于哪里ClusterIP 是由 kube-apiserver 从集群的 service CIDR 段里分配出来的一个 IP比如 kubeadm 默认的 10.96.0.0/12 段。你创建一个 Service 时apiserver 会把分配结果写进 etcd然后所有节点上的 kube-proxy 根据这个信息去生成转发规则。但有意思的是在默认的 iptables 模式下你去所有节点上执行 ifconfig 或者 ip addr都看不到这个 ClusterIP。它不绑定在任何一块物理网卡、虚拟网卡、或者网桥上。它本质上只是一条存储在 etcd 里的记录加上一堆分散在各节点的 iptables 规则。只有在 IPVS 模式下kube-proxy 才会创建一个叫 kube-ipvs0 的 dummy 网卡把 ClusterIP 绑上去。即便如此这张网卡也不参与数据转发它只是为了让本地内核能识别这个 IP避免因为查无此地址而直接丢包。可以说ClusterIP 并不是一台服务器而是一段逻辑地址和一个转发约定。1.2 为什么需要这样一层虚拟 IPPod 是短暂易变的。一个 Deployment 滚动更新旧 Pod 被销毁、新 Pod 被创建Pod 的 IP 一定变了。如果前端直接写死 Pod IP每次发布都要改配置这在工程上完全不可接受。ClusterIP 的价值在于它把“服务访问地址”和“后端 Pod 集合”解耦。前端只需要记住一个固定的虚拟 IP或者一个固定的服务名后端 Pod 怎么漂移、扩容缩容都不影响调用方。同时 Service 天然具备简单的负载均衡能力kube-proxy 会把流量按照一定算法分发到多个后端 Pod。这个过程很像你去餐厅只认一个门牌号不需要知道今天后厨是哪几位师傅。ClusterIP 就是那个门牌号背后的人员变动被完全屏蔽掉了。1.3 先搞清楚 ClusterIP 的管辖范围很多新手把 ClusterIP 和公网 IP 或普通的局域网 IP 混为一谈然后出现在集群外部访问不到的问题。这里有一个清晰的表格可以参考。访问场景是否能直接使用 ClusterIP说明集群内 Pod 访问 Service可以走 kube-proxy 生成的转发规则节点宿主机访问 ClusterIP通常可以节点上也有转发规则但需要确认防火墙集群外浏览器、客户端访问不可以必须借助 NodePort、LoadBalancer、Ingress跨 Namespace 访问可以但要用完整域名直接用 service 名只能在同 Namespace 内解析ClusterIP 的地址空间只在集群内有意义出了集群它就像一串不存在的数字。所以排查外部访问问题时别盯着 ClusterIP 看要看 NodePort 和负载均衡那一层。2. Service 的转发链从 ClusterIP 到 Pod 要过几层关2.1 kube-proxy 才是那个幕后干活的当用户创建一个 Service 后apiserver 会生成对应的 EndpointSlice 对象里面记录了这个 Service 关联的所有 Pod IP 和端口。kube-proxy 运行在每一个节点上通过 watch 机制实时监听 Service 和 EndpointSlice 的变化然后把变化翻译成当前节点上的实际转发规则。所以 kube-proxy 不负责服务发现不负责 DNS它只负责数据平面的转发。你在节点上看到的所有和 ClusterIP 相关的转发规则都是 kube-proxy 干的活。这里有个容易被忽略的点如果 kube-proxy 没在运行或者它和控制平面之间网络有问题那么即使 Service 状态是正常的集群内也没有任何节点能转发到 ClusterIP。我遇到过一次误操作停掉了某个节点的 kube-proxy结果后续调度到该节点的 Pod 访问 Service 全部超时排查了半天才发现是 kube-proxy 没起来。2.2 iptables 模式下一条流量的完整旅程iptables 模式是 Kubernetes 1.2 以来的默认模式。在这个模式下Service 的转发依靠 NAT 链完成。我从一次请求的角度拆开看。假设客户端 Pod 访问 10.96.12.34:80 这个 ClusterIP流量首先在宿主机网络栈的 PREROUTING 链被捕获进入 KUBE-SERVICES 链。这条链里针对每个 Service 都有一条规则用来匹配“目的 IP 是 10.96.12.34 且目的端口是 80”的包。匹配成功后会跳转到该 Service 专属的 KUBE-SVC-XXXX 链。KUBE-SVC 链里通常有多个 DNAT 目标对应多个后端 Pod。iptables 默认用随机匹配的方式选择其中一条 KUBE-SEP-XXXX 链然后把数据包的目的地址改成具体某个 Pod 的 IP比如 172.17.4.5:8080。这一步就是网络地址转换。包到达 Pod 之前还需要经过路由判断因为目的地址已经变成了 Pod IP所以会按照集群网络的路由规则送到目标节点再由网桥或者隧道转发到目标 Pod。Pod 处理完请求后回包会按照 conntrack 记录的 NAT 映射自动还原成 ClusterIP 作为源地址客户端根本感知不到后端真实 IP。整个链路里最核心的就是 conntrack。正因为 conntrack 记住了这个五元组映射关系回包才能顺利走回来。如果 conntrack 表满了新的连接无法建立你就会看到偶发超时或者连接失败。2.3 IPVS 模式为什么更适合大规模在集群 Service 数量比较多时iptables 模式的问题会非常明显。因为 iptables 规则是按顺序匹配的几千条 KUBE-SVC 链串在一起新的连接匹配规则需要线性遍历规则越往后延迟越高。我自己测过在 3000 个 Service 的集群里iptables 模式下新建连接的延迟会比几十个 Service 时高出几个数量级。IPVS 在内核态使用哈希表来查找虚拟服务理论上不受规则数量影响。kube-proxy 会把每一个 ClusterIP 注册成一台 IPVS 虚拟服务器然后在虚拟服务器下挂多个真实后端 Pod。查看 IPVS 规则用 ipvsadm 即可ipvsadm -L -n -oIPVS 支持多种调度算法默认是 rr即轮询。还可以配置为 wrr、lc、wlc、sh 等。在实际使用中我觉得 wrr 适合后端性能不均的场景sh 适合做源地址哈希例如无状态服务不想引入额外缓存又想保证同一客户端尽量命中同一后端时就能用上。IPVS 模式下面还有一个细节值得注意kube-proxy 需要加载对应的内核模块比如 ip_vs、ip_vs_rr、ip_vs_wrr、ip_vs_sh。如果模块没加载kube-proxy 启动时会回退到 iptables 模式但日志里有明显提示不仔细看容易忽略。2.4 三种模式该怎么选先说 userspace 模式这是老古董了kube-proxy 把流量转发到用户态再转发给后端 Pod性能和延迟都很差早早就被废弃。现在也不需要关注它。iptables 模式适合中小规模集群设置简单、没有额外内核依赖绝大多数云环境开箱即用。但它的问题是规则更新时全量刷新几千条链一起重建对节点 CPU 扰动明显。流量模型越复杂越容易踩到性能瓶颈。IPVS 模式适合规模较大、Service 数量多、对转发性能有要求的集群。它把连接管理交给内核性能稳定调度算法可配置。代价是需要额外确保内核模块齐全并且概念上比 iptables 模式多了一个 IPVS 层队伍里至少要有人能看懂 ipvsadm 输出。还有新出现的 nftables 模式目前还在演进期我只在测试环境里玩过。思路是把 iptables 换成内核新的 nftables 框架语法更灵活、性能更好但生产环境还建议保持观望。3. 服务发现链路DNS 是怎么把服务名变成 ClusterIP 的3.1 CoreDNS 的角色集群内访问 Service一般不会直接写 ClusterIP而是用服务名。核心原因是服务名比一长串 IP 好记而且在服务重建后不会变。承担“服务名到 ClusterIP”转换工作的是集群内的 DNS 服务最常见的实现是 CoreDNS。CoreDNS 通过集成 Kubernetes 插件实时感知集群里的 Service 变化。只要创建了一个 ServiceCoreDNS 就会在集群域下生成对应的 A 记录和 SRV 记录。有了这条记录Pod 里通过服务名访问 Service 才能解析到 ClusterIP。如果 CoreDNS 挂了集群内所有通过服务名访问的流量都会失败但直接用 ClusterIP 访问反而正常。所以排查问题的时候要区分清楚“DNS 解析失败”和“网络链路不通”是两类完全不同的问题。3.2 一条完整解析流程假设在 default 这个 Namespace 下有一个名为 redis 的 ServicePod 里执行 redis-cli 连接 redis 时实际发起的是对 redis 的解析。由于 Pod 的 /etc/resolv.conf 里配置了 search 域解析顺序会是这样redis.default.svc.cluster.local. redis.svc.cluster.local. redis.cluster.local. redis.第一个查询一般就能命中因为 CoreDNS 知道 redis.default.svc.cluster.local 对应的 ClusterIP。但如果你的 Pod 配置了比较特殊的 dnsPolicy或者 Service 不在同一个 Namespace直接访问 redis 就会失败必须使用完整域名 redis.另一个namespace.svc.cluster.local。这里还要提一下 ndots 参数。默认情况下 Pod 的 resolv.conf 里 ndots 是 5意思是待解析名字中只要出现少于 5 个点就先用 search 域拼接查询。比如你访问一个外部域名 example.com它只有 1 个点会被自动拼上 search 域额外产生好几次无效 DNS 查询。在高并发场景下这个开销会被放大导致 DNS 超时。3.3 无头服务与普通 ClusterIP 服务的差异普通的 Service 有 ClusterIP访问时由 kube-proxy 做转发客户端看到的是一个虚拟 IP。但有一种特殊的 Service它的 ClusterIP 被设置成 None叫作 headless Service。无头服务不会分配 ClusterIPkube-proxy 也不会为它生成转发规则。DNS 解析这个服务名时返回的不是虚拟 IP而是背后所有 Pod 的真实 IP 列表。客户端拿到这些 IP 后需要自己决定怎么连接通常用于实现自定义的负载均衡或者是有状态应用的节点发现。例如 StatefulSet 配合无头服务每个 Pod 都能获得一个稳定的 DNS 名称类似 pod-0. .ns.svc.cluster.local对有状态的系统来说这个固定网络标识非常关键比如数据库主从节点互相感知就需要它。有一点容易混淆就是如果你把有状态应用配成了普通 Service解析到的是 ClusterIP永远只会连到某一个后端从而看不到其他副本。这不是 K8s 出 bug 了而是配置语义就错了。3.4 ExternalName 这个特殊角色还有一类 Service 类型叫 ExternalName它不分配 ClusterIP也不创建任何转发规则。它的作用更像一个 DNS 别名把集群内部的服务名映射到集群外部的一个真实域名。比如集群里的应用想访问某台自建机房里的数据库可以创建一个 ExternalName Service以后应用层只需要依赖集群内的服务名。ExternalName 的底层其实是一条 CNAME 记录。需要注意CNAME 只在 DNS 查询层面生效流量本身还是由应用直接发往外部地址。如果外部域名频繁变更还需要考虑 DNS 缓存带来的延迟。4. 实战排查ClusterIP 相关的高频故障与处理思路4.1 节点上 ping 不通 ClusterIP正常吗很多人刚接触 K8s 的时候拿到一个 ClusterIP第一件事就是 ping 一下。结果 ping 不通一下子就慌了怀疑 Service 坏了。实际上在 iptables 模式下ClusterIP 没有挂在任何网卡上ICMP 请求不会有人应答ping 不通太正常了。IPVS 模式下因为这个 IP 绑到了 kube-ipvs0 dummy 网卡某些场景下 ping 是能通的但这也只代表本机内核可以响应 ICMP不代表后端的 Pod 一定健康。所以正确的连通性检查方式是测试具体的 TCP/UDP 端口直接用 curl 或者 ncnc -vz 10.96.12.34 80这就是为什么我总是说K8s 环境下不要用 ping 来确认服务健康要通过业务端口去做验证。4.2 连接 ClusterIP 偶发超时问题出在哪偶发超时是最折磨人的故障之一。我在一个节点上排查过一次情况是同一集群里 A 服务调 B 服务大概有 1% 的请求会超时重试就正常。后来查内核日志才发现是 conntrack 表爆了。conntrack 是 Linux 内核的链接跟踪模块流量经过 NAT 时会记录连接状态。如果节点上的 nf_conntrack_max 设置得过小新建连接就会失败表现就是偶发超时。我在生产中会监控这几个指标nf_conntrack_count和nf_conntrack_max一旦 count 接近 max就要考虑调整参数或者排查是不是有大量短连接堆积。另一个常见原因是 Service 的 EndpointSlice 更新有延迟。滚动发布时kube-proxy watch 到旧的 Pod 删除需要几秒时间如果流量刚好打到了还在 Terminating 的 Pod就会连接失败。这个场景在 Deployment 频繁发布、副本数又很小的服务里特别明显。4.3 DNS 解析失败但 Service 状态正常如果 kubectl get svc 显示 Service 正常但在 Pod 里 nslookup 服务名失败先检查 CoreDNS 本身的状态。CoreDNS 副本数不足、CPU 被限流、上游转发配置错误都会导致解析失败。还有一种隐蔽情况是 Pod 的 dnsPolicy 被改成了 Default这时候 Pod 默认使用宿主机上的 DNS 配置而宿主机网络栈并不感知集群的 service 域名。结果就是 Pod 拿不到集群内任何服务的解析结果。我习惯进入 Pod 后先看 /etc/resolv.conf 的 search 和 nameserver 配置再手动针对完整域名解析一次kubectl exec -it pod -- /bin/sh cat /etc/resolv.conf nslookup redis.default.svc.cluster.local如果完整域名能解析但短域名超时那大概率就是 ndots 和 search 域导致的无效查询太多可以考虑在应用配置里使用完整域名或者谨慎调整 dnsConfig 的 ndots 值。4.4 误把无头服务当成普通 Service 访问有状态的组件比如主从架构的数据库在 K8s 里部署时经常要配合 headless Service这样每个 Pod 才能有唯一的 DNS 名称。但如果你把这种服务的类型配成了普通 ClusterIP那么解析服务名拿到的永远是 vip后面的流量会被 kube-proxy 随机转发到一个后端。对于需要主动连接某个特定副本的组件来说这会产生很隐蔽的问题客户端想连主节点结果流量被转发到了从节点或者出现连接被重置。排查时先看 Service 的 ClusterIP 字段到底是不是 None再决定该不该用这个 Service 做节点发现。4.5 ClusterIP 被手动指定后和其它组件撞车Service 的 spec.clusterIP 字段允许你手动指定 ClusterIP这功能适合某些需要预先规划 IP 的场景但也容易埋雷。我见过有人把 Service 的 ClusterIP 配成了 10.96.0.1正好撞上了某个部署方案里 kube-apiserver 的静态 ClusterIP结果应用访问这个 Service 时实际连到了 Kubernetes 控制平面表现是连接被拒绝或者证书错误。建议情况是不要手动指定 ClusterIP让集群自动分配除非你有强烈的网络规划需求并且确认过目标 IP 没有被使用。如果发生了地址冲突优先考虑删掉冲突的 Service 并重建。5. 生产环境调优与避坑建议5.1 什么时候切换 IPVS改之前注意什么当集群 Service 数量开始上千、iptables 规则刷新的 CPU 消耗变大、或者新建连接延迟显著增加时就应该考虑切换 IPVS 模式。切换前需要确保每个节点都加载了 IPVS 相关内核模块。可以写一个 DaemonSet 或者通过节点初始化脚本统一保证。模块缺失时kube-proxy 会自动回退到 iptables 模式你以为是 IPVS 实际没用上这才是最坑的地方。我一般这样确认当前生效模式在节点上执行kubectl logs -n kube-system kube-proxy-pod | grep Using日志里会明确打印 proxy mode。同时用 ipvsadm 看一下是否有转发规则如果只在 iptables 里看到规则而 ipvsadm 里空空的基本可以断定没生效。调度算法上默认的 rr 对后端规格一致的场景够用。如果后端 Pod 的处理能力差异明显可以改成 wrr给大规格 Pod 更高的权重。5.2 sessionAffinity 会话保持的坑有时业务希望同一个客户端的请求多次落到同一个后端K8s 的 Service 提供了 sessionAffinity 字段最常见的是 ClientIP 模式。相当于在 ClusterIP 这里做了一层简单的会话保持。设置方式很简单spec: sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 1800但这里有个副作用一旦后端数量变化某些会话会被重新哈希或者流量在短时间内容易集中到少数节点上。如果对负载均衡的均匀性要求很高不建议集群全局都在 Service 上开启会话保持只对有状态交互诉求的服务开启比较好。5.3 externalTrafficPolicy 该用 Cluster 还是 Local这个参数主要影响 NodePort 类型的 Service对纯 ClusterIP 访问基本无感。它决定外部流量进入 NodePort 后要不要经过第二次转发。Cluster 模式是默认值任意节点收到 NodePort 流量后都可以转发给任意节点的后端 Pod。优点是负载均衡好缺点是一来一回可能多一跳而且源 IP 被 SNAT 掉了。Local 模式下节点只会把流量转发到本节点上存在的 Pod这样保留客户端源 IP但如果有节点上没有 Pod流量就会落空。所以设置了 Local 之后要配合外部负载均衡的调度策略尽量把请求转到有副本的节点上。我第一次用 Local 模式的时候没注意某个节点副本太少结果那个节点上的 NodePort 请求大量失败教训很深刻。5.4 做好 Service CIDR 的地址规划Service CIDR 的规划在集群初始化时就定了改起来非常麻烦所以一定要提前想好。要让 service 网段、Pod 网段、节点物理网络三者在地址范围上完全隔离互不重叠。比如你本地办公网就用 10.96.0.0/12 这个段你搭的 K8s 集群又恰好使用这个段作为 service CIDR你会发现从办公网访问某些内部系统时出现诡异的路由冲突表现在服务时而通时而不通而且不同人现象还不一样排查起来极其痛苦。生产多集群环境下每个集群的 service CIDR 也建议分开规划避免后期做集群迁移或服务互通时出现难以调和的路由问题。这些规划看起来繁琐但能省掉后面一大堆网络排障的时间。6. 最后分享几个使用习惯我手动排障 ClusterIP 问题时习惯按照“服务定义 - 规则生成 - 数据转发 - DNS 解析”这条线索逐步推进避免一开始就去抓包。先看 kubectl get svc 确认是否分配了 ClusterIP再看 endpointslices 确认有没有可用的后端接着到节点上查 iptables 或 ipvs 规则最后才进入 Pod 内部解析服务名和测端口。排障的时候带上这三个工具会比较顺手kubectl、ipvsadm、tcpdump。别急着改配置先把流量路径上每一层的真相看清楚再动手。我在实际运维中的体会是K8s 网络层的问题 90% 都不是“玄学”而是某个环节的状态和数据面规则不一致导致的。ClusterIP 这个虚拟 IP 之所以让人头疼是因为它横跨了配置定义、数据面规则、DNS 等多个层面。只要愿意把这些层面一个个拆开摸清每个环节谁在干活、规则长什么样问题基本都能快速收敛。最后再分享一个小技巧每次创建 Service 后我习惯在任意一个节点上顺手执行一次 ipvsadm 或者 iptables 的规则查看花几秒钟确认转发规则已经同步。这个习惯看起来多余但在关键时候能帮你快速判断是规则没生成还是后端 Pod 有问题。搞清楚了 ClusterIP 的底层真相K8s 服务排查这条路你就已经走完一大半了。