记得我第一次在生产环境排一个“服务时而通时而不通”的问题时折腾了大半天最后发现根因出在Service的会话保持和负载均衡模式上。也是从那次开始我意识到Kubernetes里Service这个抽象层远比表面看起来复杂——它不只是给Pod一个稳定的访问入口更牵扯到kube-proxy的转发模式、DNS解析策略、集群内外网流量的边界等一系列问题。这篇继续写“运维实操”系列的K8s部分专门把Service的几种类型和背后的IPVS机制一次讲透。这篇文章适合正在维护K8s集群的运维同学也适合刚把应用容器化、想搞明白“为什么我的服务有时候能访问有时候不能”的开发者。内容不会停留在“创建个Service就行”的层面而是会把IPVS、NodePort、Headless、LoadBalancer、ExternalName这五类服务的工作方式、适用场景、真实测试方法和生产环境里的坑都过一遍。1. Service的本质解决Pod“临时工”问题的集群内网入口1.1 Pod IP天生不稳定Service才是真正的“对外身份”理解Service之前得先接受一个现实Pod的IP是临时的。Deployment滚动更新时老Pod销毁、新Pod创建IP会变节点宕机后重新调度的PodIP也会变甚至你手动删掉一个Pod重建出来的新Pod IP都和原来不一样。如果你在业务代码里直接写Pod IP做调用等于把系统构建在一堆随时可能离职的“临时工”之上。Service做的事很简单也很核心它提供一个稳定的虚拟IPClusterIP以及一个稳定的DNS名字无论背后Pod怎么更替这个入口都不变。应用的客户端只需要访问Service的IP或域名由Service把流量转发到当前健康的后端Pod上。这里有个概念要分清Service本身不运行任何进程它只是一组iptables规则或IPVS虚拟服务器的抽象描述真正干活的是每个节点上的kube-proxy组件。kube-proxy负责监听API Server中Service和Endpoint的变化然后把转发规则下发到本机内核的网络栈里。所以Service的转发规则是分布在每个节点上的无论你从哪个节点访问ClusterIP最终都能到达后端Pod。1.2 Service、Endpoint和Pod三者的关系Service通过Selector匹配一组Pod而匹配结果以Endpoint对象的形式保存。你可以把Endpoint理解成“当前这个Service背后到底有哪些Pod IP和端口”的一份实时名单。举个例子你创建了一个这样的ServiceapiVersion: v1 kind: Service metadata: name: myapp-service spec: selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 8080这里port: 80是Service对外提供服务的端口targetPort: 8080是Pod内容器实际监听的端口。K8s会自动创建同名的Endpoint对象里面罗列所有带appmyapp标签且Ready的Pod IP每个条目都是“IP:8080”。如果你手动管理Endpoint把selector去掉自己定义Endpoint就可以让Service指向集群外部的地址这在实际运维中也很常见后面讲ExternalName时还会关联到。1.3 Service的四种访问方式与type的关系Service的type字段决定了它对外暴露的方式ClusterIP默认值只在集群内部可访问分配一个虚拟IPNodePort在ClusterIP基础上在每个节点上开一个端口外部可通过“节点IP:NodePort”访问LoadBalancer在NodePort基础上集成云厂商的负载均衡器外部通过LB的IP或域名访问ExternalName特殊类型不创建ClusterIP而是返回一个CNAME记录指向集群外部的域名而Headless Service并不是一个独立的type它是通过把clusterIP设为None来实现的一种特殊ClusterIP服务。后面会单独开一节讲。2. kube-proxy三种工作模式为什么IPVS是生产环境的首选2.1 userspace、iptables与IPVS的演变逻辑K8s早期版本默认使用userspace模式kube-proxy本身作为一个代理进程监听一个随机端口把请求转发给后端Pod。这种方式性能很差因为所有流量都要经过用户态到内核态的切换现在已经基本见不到了。到K8s 1.2之后iptables模式成为默认项。kube-proxy把Service的转发规则写成一串iptables链流量进入内核后直接由netfilter框架匹配规则并转发。相比userspace模式iptables模式减少了用户态代理这一跳性能提升明显在中小规模集群里完全够用。但iptables模式有两个硬伤。第一规则是串行匹配的ClusterIP数量一多规则链会非常长。想象一下几百上千个Service每个Service的规则还要拆成多条链匹配一条流量可能要遍历大量规则延迟随之上升。第二iptables规则不支持复杂的调度算法它的默认行为近似于随机选择做不了加权、最小连接数这类的负载均衡策略。2.2 IPVS模式的优势与内核依赖IPVSIP Virtual Server是Linux内核自带的四层负载均衡模块LVSLinux Virtual Server项目的核心组件。它工作在内核态使用哈希表组织虚拟服务器和真实服务器映射不像iptables那样逐条遍历所以在Service数量大的情况下性能稳定得多。IPVS模式下kube-proxy会把Service和Endpoint信息同步为内核里的IPVS虚拟服务器和转发后端同时保留一小部分iptables规则用于处理一些IPVS覆盖不了的场景比如externalTrafficPolicy的流量伪装。转发行为由IPVS的调度算法控制支持rr轮询、wrr加权轮询、lc最少连接、sh源地址哈希等灵活度远高于iptables。让集群启用IPVS很简单修改kube-proxy的ConfigMap后重启即可apiVersion: v1 kind: ConfigMap metadata: name: kube-proxy namespace: kube-system data: config.conf: |- mode: ipvs改完之后把名为kube-proxy-xxx的DaemonSet Pod滚动重启一遍。验证是否生效可以在任意节点上执行ipvsadm -L -n如果能看到类似下面的输出说明IPVS已经接管了Service转发IP Virtual Server version 1.2.1 Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.96.0.10:53 rr - 10.244.2.5:53 Masq 1 0 0 - 10.244.1.7:53 Masq 1 0 0想查看某个Service对应哪条IPVS虚拟服务器记录可以用Service的ClusterIP和端口去grep。2.3 IPVS模式实测中的数据表现我在一个约200个Service的测试集群里做过简单对比。iptables模式下新建连接的转发延迟大概在1到3毫秒波动Service数量上去之后偶发5毫秒以上的尖刺切到IPVS模式后同样压测场景下延迟基本稳定在1毫秒以内波动小得多。如果你是那种动辄几十上百个微服务的集群强烈建议直接上IPVS。需要注意的是IPVS模式依赖节点内核加载ip_vs相关模块。大多数主流Linux发行版默认都带但为了保险可以在节点上提前确认lsmod | grep ip_vs如果没有输出用modprobe加载一下modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh然后把这些模块写入/etc/modules-load.d/下保证重启后自动加载。这一步很容易被忽略有些云主机镜像默认没加载这些模块kube-proxy切到IPVS模式后日志里会报错但Service创建又是成功的排查时容易绕弯路。3. ClusterIP与NodePort从集群内到集群外的第一道门3.1 ClusterIP的访问链路与规则细节ClusterIP是默认的服务类型它只在集群内部可达。你可以在任意一个节点上访问它也可以在集群内的Pod里通过三种方式访问ClusterIP:PortService名:Port同命名空间下Service名.命名空间:Port跨命名空间ClusterIP的分配范围由API Server启动参数--service-cluster-ip-range控制比如10.96.0.0/12。你创建Service时如果不指定clusterIPK8s会从这个网段里自动分配一个这个IP在Service的整个生命周期内都不变。从Pod内部访问ClusterIP的流量链路是Pod的eth0发出请求经过节点上的路由和IPVS规则被转发到目标Pod的IP。这里有个很多人忽略的点请求从源Pod出来后源IP会被改写为节点IP或者说经过NAT所以后端Pod看到的source IP不是发起请求Pod的IP而是所在节点的IP。如果应用需要拿到真实客户端IP就得另想办法比如给Service开externalTrafficPolicy: Local或者让业务层传X-Forwarded-For。3.2 NodePort的端口范围、yaml配置与访问路径NodePort是在每个节点上开一个固定端口让集群外部可以直接访问。端口范围默认是30000到32767可以在API Server的--service-node-port-range参数里调整。一个典型的NodePort Service配置如下apiVersion: v1 kind: Service metadata: name: myapp-nodeport spec: type: NodePort selector: app: myapp ports: - port: 80 targetPort: 8080 nodePort: 30080如果不手动指定nodePortK8s会自动分配一个范围内的端口但自动分配的结果不直观生产环境建议显式指定方便后续在防火墙和安全组里做放行。创建后可以这样验证kubectl get svc myapp-nodeport从集群外访问的路径是外部客户端访问任意节点的30080端口节点上的kube-proxy规则把流量转到ClusterIP再转发到后端Pod。整个过程有两层转发源IP在到达Pod时已经是节点IP了。我想强调的是NodePort并非只有一个节点可用。很多刚接触K8s的人以为NodePort只在某个特定节点上生效其实每个节点上的kube-proxy都同步了同样的规则所以访问任何一个节点IP加NodePort都能到达后端Pod前提是这个节点本身网络可达。3.3 NodePort踩坑从“配好了但不通”到“全链路排查”我踩过最经典的一个坑是Service创建成功、后端Pod也Running但从外部用“节点IP:NodePort”访问就是不通。当时我的排查链路大概是这样的先确认Service本身状态正常kubectl get endpoints myapp-nodeport kubectl describe svc myapp-nodeport再确认节点端口监听正常ss -tlnp | grep 30080这步能看到kube-proxy有没有在本机监听这个端口。如果没有大概率是kube-proxy没同步到规则去看kube-proxy日志或者检查API Server连通性。如果端口在监听就从节点本机访问一次curl http://127.0.0.1:30080通的话说明转发规则没问题问题出在节点到外部的链路上。接着看云厂商的安全组或防火墙有没有放行30080端口。那个项目最后就是安全组只放行了80和443NodePort怎么都进不来放行后立刻恢复。还有一次是多个Service不小心用了同一个nodePort创建第二个时API Server直接报错端口被占用。这就提醒我们生产环境NodePort的规划要做台账避免人工维护跟不上。3.4 externalTrafficPolicy对源IP的影响如果你希望后端Pod能看到真实客户端IP可以把Service的externalTrafficPolicy设为Localspec: externalTrafficPolicy: Local这表示节点收到外部请求后只把流量转发到本节点上运行的Pod不再转发给其他节点上的Pod。这样源IP保留了但代价是流量不一定会均匀分布。如果某个节点上没有对应的Pod请求就会被丢弃需要配合负载均衡器按节点维度做健康检查才行。Cluster模式默认则会把流量在所有后端Pod间转发甚至转发到其他节点的Pod源IP会被NAT改写。这个取舍在选型时要提前想清楚。4. Headless Service让客户端直接和Pod对话4.1 clusterIP: None到底意味着什么Headless Service的字面意思是“无头”精髓在于你创建它时不分配ClusterIPapiVersion: v1 kind: Service metadata: name: myapp-headless spec: clusterIP: None selector: app: myapp ports: - port: 80 targetPort: 8080没有ClusterIP意味着这个Service不承担流量转发功能它存在的意义是提供稳定的DNS记录。当你通过DNS查询这个Service名时返回的不是一个虚拟IP而是所有后端Pod的IP列表。举个例子集群里有三个appmyapp的PodPod的IP分别是10.244.1.10、10.244.1.11、10.244.2.8。在集群内另一个Pod里执行dig myapp-headless.default.svc.cluster.local你会看到A记录返回了这三个IP而不是一个ClusterIP。这样客户端拿到全部后端地址后可以自己决定连哪个。这就是Headless的核心思路把负载均衡的决定权交还给应用而不是由Service代劳。4.2 为什么StatefulSet需要HeadlessHeadless Service最经典的使用场景是和StatefulSet搭配。StatefulSet管理的Pod有稳定的网络标识每个Pod的名字和主机名都是固定的例如web-0、web-1、web-2。如果配合Headless Service每个Pod都会有自己的DNS记录web-0.myapp-headless.default.svc.cluster.local web-1.myapp-headless.default.svc.cluster.local这样其他组件就可以通过这种“有身份的域名”访问到某一个确定的Pod这在分布式数据库、主从复制、集群选主等场景里极其有用。例如某个数据库Pod需要找到web-1同步数据直接解析web-1这个域名就可以了即便Pod被重新调度、IP变了域名依然不变。有状态的场景不用Headless的话客户端拿到的是ClusterIP根本没法定位到具体某一个Pod。4.3 Headless的适用与不适用场景适合用Headless的场景包括StatefulSet的稳定网络标识客户端需要自己实现负载均衡策略比如gRPC的客户端侧负载均衡需要直接感知后端Pod列表变化做服务发现存在必须访问固定某个副本的业务需求不适合用Headless的场景也很明显如果你只是想给一组无状态Pod提供一个简单访问入口并且希望K8s自动做轮询或按连接数转发那就不要用Headless直接用普通ClusterIP服务。使用Headless后还要注意因为没有了ClusterIP某些依赖虚拟IP做请求转发的组件会失效比如集群外的系统如果想通过一个固定IP访问你的服务Headless给不了。4.4 实测从Pod里解析Headless服务的DNS在集群内起一个临时Pod来验证Headless最方便kubectl run -it --rm test-pod --imagebusybox -- sh然后在容器里执行nslookup myapp-headless.default.svc.cluster.local如果返回多个A记录说明Headless正常。如果只返回一个IP或者没有记录先检查这个Service的Endpoint是否存在kubectl get endpoints myapp-headless如果Endpoint是空的八成是Selector和Pod标签没匹配上。这也是我排查这类问题时第一个看的地方。5. LoadBalancer与ExternalName通往集群外的两条不同路径5.1 LoadBalancer是怎么把NodePort“包起来”的LoadBalancer类型的Service常见于公有云环境本质是“NodePort 云负载均衡器”的组合。你创建一个LoadBalancer类型Service后云平台会自动创建一个负载均衡实例并把所有节点的某个NodePort挂到这个负载均衡后端用户访问LB的IP或域名时流量被分发到各个节点的NodePort上再走一遍NodePort转ClusterIP的链路。一个典型的例子apiVersion: v1 kind: Service metadata: name: myapp-lb spec: type: LoadBalancer selector: app: myapp ports: - port: 80 targetPort: 8080创建后查看kubectl get svc myapp-lb你会看到EXTERNAL-IP那一列出现一个公网IP或负载均衡器的地址。这个地址由云厂商的控制器Cloud Controller Manager动态分配。LoadBalancer的价值在于把集群内部复杂的NodePort端口暴露方式包装成了一个对外统一、标准的入口。外部用户只需要记住一个80或443端口不用关心背后是哪个节点的哪个高端口。如果没有公有云环境也可以用MetalLB这类纯软件方案在裸金属集群里实现类似效果本质都是给Service分配一个外部可达IP然后把流量导入到NodePort或Pod网络。5.2 LoadBalancer的常见配置项与实际排错有几个配置在实际使用中很关键。一个是loadBalancerSourceRanges用来限制哪些来源IP可以访问负载均衡器spec: loadBalancerSourceRanges: - 10.0.0.0/8一个是把externalTrafficPolicy设为Local配合LB的节点健康检查可以尽量保留客户端源IP这也是许多Web应用获取真实用户IP的标准做法。还有一个是把LB的端口和NodePort直接绑定理解清楚。即使你创建的是LoadBalancer类型节点上依然会分配一个NodePort只是你平时不直接用它。用kubectl describe svc可以看到真实的NodePort是多少接入云厂商健康检查时有时候会用到。我在某项目里遇到过一次“LB显示健康但服务实际不可用”的情况。最后发现是后端实例的健康检查路径指向了一个不存在的端口。云厂商LB的默认健康检查端口是NodePort如果你手动改成了别的端口但没同步改防火墙规则就会出现这种诡异现象。排错时先检查LB后端实例的健康状态再逐层确认NodePort和Pod监听。5.3 ExternalName把集群外部的服务“映射”进集群ExternalName是Service里比较特殊的一类它不创建ClusterIP也不定义Pod选择器而是返回一个CNAME记录把Service名解析到集群外部的一个域名。配置示例apiVersion: v1 kind: Service metadata: name: external-db spec: type: ExternalName externalName: db.example.com这样集群内的应用访问external-db.default.svc.cluster.local时DNS解析会返回db.example.com的CNAME结果流量最终由应用直接打到外部域名对应的服务上。ExternalName适合哪些场景最典型的是“数据库迁移过渡期”或“依赖外部API但不想改代码”。比如你把某个自研系统从物理机迁到K8s但数据库还在老环境。应用代码里原本写的是数据库地址现在改成访问K8s里的Service名用ExternalName把这个名字指到老环境的数据库域名应用代码完全不用动。5.4 ExternalName的局限没有端口、没有健康检查ExternalName有几个地方容易让人踩坑。第一ExternalName不支持指定端口映射。Service定义里的port对ExternalName来说纯粹是给应用方约定用的实际连接时使用什么端口由应用自己决定DNS的CNAME本身不携带端口信息。如果你的外部服务跑在非标准端口需要应用侧自行处理。第二ExternalName不提供健康检查和负载均衡。它只是DNS层面的一个别名外部服务是否可用、是否有多个后端K8s完全感知不到。第三ExternalName依赖集群DNS解析。如果集群CoreDNS出问题ExternalName的解析也会一起挂掉。曾经有个项目把外部对象存储的域名配置成了ExternalName结果CoreDNS升级期间出现间歇性解析失败应用也报错排查到最后才发现是DNS组件的问题。所以说ExternalName适合做简单映射不适合承载强依赖的核心链路核心外部依赖还是建议通过Ingress或独立网关做转发更可控。6. 生产环境选型我总结的决策思路与关键经验6.1 五种类型的一页对照表Service类型是否分配ClusterIP外部访问方式负载均衡能力典型场景ClusterIP是仅集群内部kube-proxy转发微服务内部调用NodePort是节点IP:NodePortkube-proxy转发临时暴露、中小规模对外服务LoadBalancer是云LB IP或域名云LB kube-proxy两层生产环境对外门户Headless否无统一入口直接访问Pod无客户端自行负载均衡StatefulSet、服务发现ExternalName否DNS CNAME跳转无集群内访问外部服务6.2 决策思路先问自己三个问题第一个问题这个服务需要被集群外访问吗不需要就选ClusterIP这是最基础也最安全的选择。需要的话进入下一个问题。第二个问题集群部署在公有云还是裸金属公有云选LoadBalancer最省事裸金属可以考虑NodePort配合外部负载均衡或部署MetalLB方案。第三个问题应用对客户端IP和会话保持有要求吗有要求就得关注externalTrafficPolicy是否设为Local以及负载均衡器层面的会话保持策略是否支持。6.3 几个必须知道的经验细节第一生产环境创建Service时显式声明clusterIP和nodePort。自动分配在开发环境方便但在生产环境会让你连防火墙策略都没法写。显式指定后网络侧的白名单、安全组规则都能提前规划好。第二不要用ClusterIP去和集群外的系统交互。CluserIP默认仅在集群内可达外部系统访问它需要额外配路由规则而且Pod重建后后端地址变化外部系统无从感知。这种场景优先考虑NodePort或LoadBalancer。第三IPVS模式下查看转发状态可以用ipvsadm -L -n --stats看每个后端的连接数这对定位流量倾斜问题非常有帮助。如果连接数分布不均可以考虑把调度算法从rr改成wrr或lc。第四Service的端口命名。如果你的Service需要工作在多种协议上可以给ports里的每个端口起名例如name: http和name: https。多数情况下这不是刚需但当Service数量增长后统一的命名规范能降低人的认知负担。第五记得把Service和Deployment的selector标签对应清楚。很多“服务不通”的根因就是Service的selector选不到任何Pod导致Endpoint为空。操作习惯上建议创建Service后顺手检查一次kubectl get endpoints这比问题爆发后再排查要省力得多。6.4 我最后的体会从iptables切到IPVS再从ClusterIP一路摸到ExternalName我的整体感受是Service的本质是一个“流量控制面”的抽象它把网络决策从应用层剥离出来交给平台层统一管理。但反过来它也把复杂性转移到了运维侧——你可选的模式多了每个模式背后的行为差异、边界条件也就多了。在生产环境里我最常用的组合是集群内部微服务全靠ClusterIP互相调用对外入口统一走LoadBalancer接Ingress有状态组件用Headless配合StatefulSet保持稳定网络标识临时联调或灰度验证用NodePort外部遗留系统则用ExternalName做无侵入接入。这套组合在多个项目里验证过稳定性和可维护性都比较理想。当然具体取舍还得看你的集群规模、网络插件和云环境但先把原理和边界搞清楚再谈方案适配这才是运维该有的思路。
