K8s服务发现原理与排障实战：从Pod IP到CoreDNS-北京尧图网络

先讲一个我翻车的事。那是一个内部系统的上线日。前端服务要调用后端的新版本接口代码里写的还是后端老Pod的IP。后端发版后Deployment滚动重建新Pod被调度到了另一台工作节点IP自然变了。前端服务配置里写死的地址彻底失效整个系统登不进去。排查了大半天最后才发现问题不是代码逻辑不是网络策略就是那个被我当成“固定不变”的Pod IP。后来我把项目里的服务间调用全部改成了K8s Service域名问题才算根除。这个经历让我意识到理解K8s的Service发现机制不是K8s面试题里的冷知识而是部署任何多服务应用都绕不开的生存技能。这篇文章我围绕K8s Service发现这件事把原理、实践和排障经验完整摊开讲一遍。内容覆盖Service对象的运作机制、CoreDNS的解析细节、Headless Service的适用场景以及我在实际集群里遇到过的五类故障案例。适合正在学习K8s的开发者也适合集群里服务间调用总出问题、但一直没找到根因的运维和平台工程师。1. 为什么K8s里不能直接用Pod IP做服务调用1.1 Pod IP的宿命谁在动它新手最容易产生的误解就是把Pod IP当成一台虚拟机或物理机的固定IP。K8s里完全不是这个逻辑。Pod是K8s调度的最小单元而调度器的工作原则是“哪里有资源Pod就去哪”。节点故障、资源紧张触发的驱逐、Deployment滚动升级、副本数扩缩容甚至有人手滑删了一个Pod这些操作都会导致Pod被销毁重建。每次重建Pod都会从节点所在的网段里重新申请IP新IP和老IP大概率不相等。就算没有任何操作Pod也未必安全。节点上的kubelet定期对Pod做健康检查如果容器探针失败会杀掉容器重启如果整个节点NotReady控制平面会把Pod重新调度到其他节点。也就是说K8s的Pod默认就不可信它是“短暂且可替换的”。1.2 动态IP时代稳定的入口才是一切用Pod IP做服务间调用会面临三个具体问题。第一是配置无法收敛。微服务架构里面少则十几个服务多则上百个。每个服务可能有好几个副本你不可能把十几个甚至上百个Pod IP一个一个写进其他服务的配置文件。就算用配置中心管理Pod一变你就得跟着改配置变更频繁到让人崩溃。第二是客户端侧的负载均衡没人管。一个Service后端有5个Pod客户端总得有个办法把请求分散到这5个Pod上去。如果直接用Pod IP客户端就得自己实现一套负载均衡逻辑。每个语言一套实现每个团队维护一套完全是重复造轮子。第三是健康检查机制缺失。Pod IP列表里如果有一个Pod已经挂了调用方根本不知道。没有一层抽象来感知后端的存活状态请求就会持续打到故障Pod上造成大量超时和报错。1.3 K8s给出的解法Service作为抽象层K8s引入了Service资源就是为了解决这一整类问题。Service给一组Pod提供一个稳定的虚拟IPClusterIP和稳定的DNS域名。客户端只需要记住这个域名或虚拟IP后端Pod怎么漂移、怎么扩缩容、怎么重建都是平台层面自动处理的。Service永远不变后端的Pod列表则通过标签选择器动态维护。服务间的调用关系从“点对点Pod IP直连”变成了“面对稳定入口后端自动切换”。这套机制就是“服务发现”在K8s里的落地形态。它解决的核心问题就是让调用方不需要预先知道服务实例在哪里、去哪找。2. Service三件套Selector、Endpoint、ClusterIP的协同链路2.1 一个最常见的Service定义看一个最简单的Service配置apiVersion: v1 kind: Service metadata: name: nginx-svc namespace: default spec: selector: app: nginx ports: - name: http port: 80 targetPort: 80 protocol: TCP type: ClusterIP这里有三处关键配置很多人初次使用容易搞混。selector是Service找Pod的规则。它根据Pod上的标签labels来匹配比如app: nginx就会匹配所有带这个标签的Pod。port是Service对外暴露的端口访问方用的是这个端口targetPort是后端Pod容器实际监听的端口。也就是说请求打到Service的80端口最终会被转给Pod的80端口。如果后端容器监听的是8080这里targetPort就要写成8080。2.2 Endpoint是怎么被自动维护的创建Service之后K8s控制面里有一个名为Endpoint Controller的组件会持续监听Service和Pod的变化。一旦发现Service的selector匹配到新的Pod无论Pod新建、删除、IP变化它就会自动更新Endpoint对象。Endpoint对象长这样NAME ENDPOINTS AGE nginx-svc 10.244.1.23:80 5m每个符合selector条件的Pod IP都会出现在这里端口对应targetPort。这里要特别注意Endpoint里没有IP就说明Service没有匹配到任何Pod。这是服务间调用不通最常见的原因之一。检查排障顺序时第一步永远是kubectl get endpoints。较新版本的K8s已经把Endpoint升级为EndpointSlice格式和API不同但逻辑完全一致动态维护后端Pod IP列表。2.3 流量转发的最后一公里kube-proxyService创建好了Endpoint也维护了接下来谁来真正把流量从Service的ClusterIP转发到后端Pod IP答案是每台工作节点上的kube-proxy组件。kube-proxy通过API Server监听Service和Endpoint的变化然后把转发规则写入当前节点的网络规则。具体有两种实现模式iptables和ipvs。以iptables模式为例客户端访问10.96.1.10:80时数据包进入内核网络栈命中kube-proxy写入的KUBE-SVC-XXX链再经过KUBE-SEP-XXX链最终完成DNAT转换目标地址变成某个Pod的IP和端口。整个转发过程全部在Linux内核里完成不需要用户态进程介入效率很高。2.4 iptables和ipvs怎么选我曾经在测试环境直接用了iptables的默认模式后来服务多了才发现规则数量增长很快性能开始不稳定。改成ipvs之后问题解决了。两者对比如下维度iptablesipvs规则匹配方式链式遍历规则数越多耗时越长哈希表查找规则规模对性能影响小负载均衡策略默认随机策略有限支持rr、wrr、lc、wlc、sh等调试方式iptables-save直接看规则需要ipvsadm查看适用场景小规模集群、简单拓扑中大规模生产集群如果集群规模不大iptables够用。生产环境如果担心持久连接和负载均衡能力优先切到ipvs。在kube-proxy启动参数里加--proxy-modeipvs即可或者通过ConfigMap配置。3. 用DNS做服务发现CoreDNS与解析细节全解3.1 先说说环境变量这种“老办法”K8s早期的服务发现机制是通过环境变量注入实现的。新创建的Pod会被自动注入当前namespace下所有Service的地址信息。比如你在default命名空间创建了一个名为nginx-svc的Service那么之后创建的Pod里会自动多出这些环境变量NGINX_SVC_SERVICE_HOST10.96.1.10 NGINX_SVC_SERVICE_PORT80应用代码直接读环境变量就能拿到Service地址。这个机制看起来简单但有一个很严重的坑环境变量只在Pod创建的那一刻注入。如果Service在Pod创建之后才创建或者Service被删除重建Pod里的环境变量不会自动更新。应用只能拿到创建时的旧地址一旦Service变化就只能重启Pod。所以现在绝大多数集群都已经放弃环境变量方式改用DNS。DNS的好处是实时解析Service的IP变化都由CoreDNS自动维护调用方完全感知不到。3.2 CoreDNS与服务名的解析规则K8s集群默认部署CoreDNS作为DNS解析服务它通常运行在kube-system命名空间下对应的Service叫kube-dns。每个Pod的/etc/resolv.conf都会指向这个DNS服务的ClusterIP。Service创建后CoreDNS会自动注册一条A记录完整域名规则是service名称.namespace.svc.cluster域名默认集群域名是cluster.local所以default命名空间下的nginx-svc对应完整域名是nginx-svc.default.svc.cluster.local在同一个namespace内部可以直接用Service名访问curl http://nginx-svc:80但在跨 namespace 访问时必须写完整域名curl http://nginx-svc.prod.svc.cluster.local:80在容器内部执行nslookup或者dig可以直观看到解析过程$ nslookup nginx-svc.default.svc.cluster.local Server: 10.96.0.10 Name: nginx-svc.default.svc.cluster.local Address: 10.96.1.10解析出来的地址就是Service的ClusterIP。之后客户端连接这个ClusterIP再走上一章的kube-proxy转发链路。除了A记录CoreDNS还会为带端口的Service生成SRV记录格式为_端口名._协议.service.namespace.svc.cluster域名比如_http._tcp.nginx-svc.default.svc.cluster.localSRV记录配合工具如Consul等做服务发现时很有用但在K8s原生的调用链路上用到的人不多。大多数客户端只需要A记录就够了。3.3 Headless Service把“发现”交给调用方普通Service用ClusterIP做稳定入口转发逻辑全部由kube-proxy承担。但有些场景下客户端希望直接拿到后端Pod的真实IP列表自己决定连哪一台。比如有状态应用如MongoDB、Kafka、Elasticsearch每个Pod都有自己的身份和状态不能随意通过负载均衡转发。需要自行实现灰度或流量策略的中间件。这时候就用Headless Service。配置很简单apiVersion: v1 kind: Service metadata: name: mongo-svc namespace: default spec: clusterIP: None selector: app: mongo ports: - port: 27017 targetPort: 27017关键在于clusterIP: None。设置了None之后K8s会创建一个不分配ClusterIP的Service。DNS解析会直接返回所有后端Pod的IP列表$ nslookup mongo-svc.default.svc.cluster.local Name: mongo-svc.default.svc.cluster.local Address: 10.244.1.23 Address: 10.244.2.15 Address: 10.244.3.31配合StatefulSet使用时还会自动生成每个Pod独立的DNS域名格式为pod名称.service名称.namespace.svc.cluster域名比如mongo-0.mongo-svc.default.svc.cluster.local客户端可以直接通过mongo-0.mongo-svc...连到指定的Pod。这对数据库集群搭建特别重要因为每个节点需要知道其他节点的确切地址。3.4 ExternalName把集群外的服务也纳入发现有些服务不在K8s集群里比如遗留系统里的数据库或者第三方API。K8s提供一个叫ExternalName的Service类型可以把一个外部域名包装成集群内的Service。apiVersion: v1 kind: Service metadata: name: legacy-db namespace: default spec: type: ExternalName externalName: db.legacy.internal创建之后集群内的Pod可以直接通过legacy-db.default.svc.cluster.local访问外部数据库域名。CoreDNS返回的是外部域名的CNAME记录不会经过kube-proxy转发流量直接走外部域名解析。这样做的好处是应用代码不需要关心目标服务到底在集群内还是集群外统一用Service名。哪天外部数据库迁到了集群里只需要把这个Service改成普通ClusterIP类型应用代码一行不用改。3.5 ndots与搜索域DNS解析性能的隐形杀手这是我在实际项目里吃过大亏的地方。K8s生成的/etc/resolv.conf默认长这样nameserver 10.96.0.10 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5ndots:5的意思是域名中包含的点数少于5个时解析器会先用search列表里的域名轮番拼接后查询最后才查询原始域名。访问集群内部Service名这个机制没问题。但访问外部域名时问题就来了比如访问api.example.com它只有2个点小于5解析器就会先依次去拼api.example.com.default.svc.cluster.localapi.example.com.svc.cluster.localapi.example.com.cluster.local每次拼接都是一次DNS查询这些查询大概率会失败超时。如果DNS响应慢一个简单的外部域名解析可能拖到好几秒应用表现就是“偶尔卡顿过一会儿又恢复”。解决办法有两个。第一是给Pod单独设置dnsConfig把ndots改成2spec: dnsConfig: options: - name: ndots value: 2第二是调整search列表减少不必要的搜索域。我个人建议所有需要大量访问集群外部域名的服务都显式配置ndots:2。集群内服务调用不受影响外部域名解析也能快很多。4. 服务发现故障排查从解析失败到流量转发异常的实战链路4.1 现象一服务名根本解析不出来这是服务间调用最常见的问题之一。表现为应用日志里报错类似could not resolve host: nginx-svc。排查链路如下先确认Service是否存在kubectl get svc -A | grep nginx-svc如果Service不存在回查是不是部署文件没apply成功或者Service被删了。Service存在解析还是失败就要看Pod的DNS配置和CoreDNS状态。确认CoreDNS Pod是否正常kubectl get pods -n kube-system -l k8s-appkube-dns然后进入一个Pod手动用nslookup测试kubectl exec -it pod名称 -- nslookup nginx-svc.default.svc.cluster.local如果测试报错看CoreDNS日志kubectl logs -n kube-system -l k8s-appkube-dns --tail100还有一种情况是Pod的dnsPolicy被改过。默认是ClusterFirst表示集群内解析走CoreDNS如果被改成Default则直接使用宿主机DNS解析不到集群内的Service名。配置回ClusterFirst即可。4.2 现象二解析成功但Endpoints为空Service存在域名也能解析出ClusterIP但请求就是超时。这时候重点检查Endpoint列表kubectl get endpoints nginx-svc如果显示ENDPOINTS列为空说明selector没有匹配到任何Pod。常见原因有两个。一个是标签没对齐。Service的selector是app: nginx但Pod的labels写的却是app: nginx-web。逐个检查Pod标签kubectl get pods --show-labels另一个是Pod没有Ready。K8s只把处于Ready状态的Pod加入Endpoint列表。查看Pod状态kubectl get pods | grep nginx如果是ImagePullBackOff或者CrashLoopBackOff先把Pod本身的问题解决了Endpoint自然就有值了。4.3 现象三转发规则或网络策略导致不通Endpoints有IP但从应用里访问Service就是不通。这时候就需要分两层排查。先绕过Service直接访问Pod IP确认Pod本身及网络插件是否正常curl http://某个Pod的IP:80Pod IP能通而Service不亮问题大概率出在kube-proxy或网络策略层面。确认kube-proxy运行状态kubectl get pods -n kube-system | grep kube-proxy查看iptables模式下的规则是否生成iptables-save | grep KUBE-SVCipvs模式下则用ipvsadm -Ln | grep 10.96.1.10如果规则正常再看是否有NetworkPolicy拦截了流量。K8s默认允许所有Pod互访但一旦有NetworkPolicy定义未放行的流量会被丢弃。检查命名空间下是否有生效策略kubectl get netpol -A曾经在一个生产环境里服务端Pod的namespace下有一条NetworkPolicy只放行了来自特定标签Pod的流量新上线的服务没打对应标签结果所有请求全被丢弃排查了一整天才发现是策略问题。4.4 现象四环境变量注入带来的历史遗留问题之前遇到过一个问题某个服务明明ConfigMap里已经改了新的Service地址但应用运行一段时间后突然连不上数据库。查了应用日志发现它一直连的是旧地址。追根溯源是因为这个服务通过环境变量方式使用Service地址而环境变量在Pod创建的时候就固化了。Service重建之后IP变了环境变量却还指向旧IP直到Pod重启才会刷新。这类问题在DNS机制普及后很少出现但老集群里还有存量应用在跑。排查时看应用日志里报错地址和当前Service的ClusterIP做对比如果对不上多半就是环境变量污染。这种场景下没有太好的实时修复手段只能重启Pod让它重新注入。根治方案还是迁到DNS解析。5. 服务发现的集群边界从NodePort到Ingress再到服务网格5.1 南北向流量也需要“服务发现”以上讲的服务发现解决的是集群内服务如何互访也就是“东西向流量”。但业务系统都免不了要接收外部访问比如浏览器打开页面、App调用接口。这部分流量叫“南北向流量”。K8s对南北向流量的处理同样是围绕Service展开的。Service的type字段可以配置成NodePort或LoadBalancer把ClusterIP映射到节点端口或云厂商负载均衡器上外部流量就能进入集群访问到Service。NodePort方式最直接每个节点开放一个高位端口默认30000-32767外部访问节点IP:端口进入集群然后被转发到对应的Service上。但这种方式在云环境下很不优雅因为需要知道节点IP节点变化后入口也会变。LoadBalancer则更适合云环境。云厂商会在你创建LoadBalancer类型Service时自动创建一个负载均衡器把外部流量引到集群内的Service上。对使用者来说入口是一个固定的负载均衡器地址背后Service的变化完全透明。5.2 Ingress如何衔接内部Service如果外部访问的域名和路径很多每个服务都单独搞一个LoadBalancer成本太高。此时一般用Ingress。Ingress是K8s里的一个API对象定义了外部HTTP/S请求如何路由到集群内的Service。它本身不承载流量真正干活的是Ingress Controller比如nginx-ingress、traefik。Controller根据Ingress规则做请求转发请求 api.example.com - Ingress Controller - backend-service:8080Ingress规则示例apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: api.example.com http: paths: - path: /v1 pathType: Prefix backend: service: name: backend-svc port: number: 8080Ingress Controller部署在集群里本身也是一个或一组Pod对外暴露为一个LoadBalancer类型的Service。整个链路是外部流量 - 云负载均衡器 - Ingress Controller Pod - 集群内Service - 后端Pod5.3 服务发现的下一个形态服务网格转发决策服务网格比如Istio进一步把服务发现和流量管理做深了一层。在服务网格架构里每个应用Pod会多一个Sidecar代理容器。应用发出的请求不再直接走kube-proxy的iptables规则而是被劫持到Sidecar。Sidecar从控制平面拿到全量服务注册信息和转发规则自己决定请求该发给哪个Pod。这样做的好处是转发决策从“网络层规则”上升到了“应用层路由”。你可以做精细的按权重灰度、按header分流、故障自动重试等操作这些用原生Service是很难实现的。但对大多数中小型集群来说K8s原生的Service发现已经完全够用。服务网格引入之后运维复杂度和资源开销都会明显上升属于“能力过剩”的选择。如果只是需要稳定的服务间互访原生机制反而是最优解。从Endpoints到EndpointSlice、从iptables到ipvs再到eBPFK8s的服务发现机制一直在演进但底层的设计思想没有变让应用之间不关心彼此在哪里只关心稳定入口后端的变化交给平台消化。整个链路跑通之后我在实际项目中得到的最大体会是服务间的互访配置一定要用K8s DNS域名千万不要图省事去写IP或环境变量。一旦规模上来维修成本会指数级上升。排障顺序也慢慢形成了一套肌肉记忆先看Service是否存在再看Endpoint有没有IP紧接着验证DNS解析最后查kube-proxy规则和NetworkPolicy。另外一个小技巧新建Pod后习惯性先去看一眼/etc/resolv.conf确认nameserver指向正确、search和ndots符合预期。很多间歇性超时问题根源都藏在这个文件里。K8s服务发现这东西出了故障不可怕怕的是没有一套固定的排查顺序。把这套链路记熟了出了问题基本都能快速定位。

K8s服务发现原理与排障实战：从Pod IP到CoreDNS

相关推荐

Mantine Vanilla Extract 集成指南：用 themeToVars 将 Mantine 主题转换为类型安全的 CSS 变量

基于Python的热门游戏推荐系统设计与实现：从算法到部署全解析

SAP PS项目类型与编码方案匹配：OPSK/OPSJ配置与排查实战

更多资讯

py-eddy-tracker中尺度涡识别原理与参数校准实战指南

地信专业就业方向全解析：从GIS开发到三维可视化，职业规划路线指南

纯NumPy实现的可调试BP神经网络工程模板

BC40双轮铣履带行走装置设计：从接地比压到液压驱动的关键参数解析

TradingAgents-CN 的 LangGraph stream_mode 双模策略：节点级进度跟踪与状态累积的实现剖析

用 Aliasing XOR Mutability 强化 API 不变量：comprehensive-rust 课程中的借阅检查器设计模式

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

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