企业官网建设流程全解析

第一次认真把 Service 的三种类型挨个研究透，是因为一次线上事故：某内部系统的流量通过 NodePort 接入，结果我在另一个服务里把健康检查配到了 ClusterIP 上，一次滚动扩容把后端 Pod 全部重建，整整一上午流量时断时续。虽然事后看原理一目了然，但实际踩了坑才发现，ClusterIP、NodePort、LoadBalancer 这三者的关系，远比文档里三张示意图复杂。

很多刚接触 Kubernetes 的人，都觉得 Service 不过是个“IP 加端口”的映射规则。实际上它背后牵出了 kube-proxy、Endpoints、CoreDNS、云负载均衡器一整条链路，选型稍有不慎，线上流量就可能在扩容或节点故障时“断粮”。这篇文章想用我实际调集群网络的经验，把三种 Service 类型从原理到选型、从配置到避坑完整讲一遍，适合正在调试集群网络、准备把应用接入生产环境的开发、运维和容器平台建设者。

1. 动辄整出“玄学故障”的 Service 到底是什么

1.1 为什么 Pod 的 IP 不能直接拿来用

Kubernetes 里最底层的调度单元是 Pod，每个 Pod 都有自己独立的 IP。但这个 IP 有两个致命问题：第一，Pod 是“一次性”的，被删除、被驱逐、触发滚动更新后，新 Pod 的 IP 会完全变化；第二，一个 Deployment 通常有多个副本，客户端该访问哪个副本？如果有副本挂了，流量又该怎么摘除？

这种场景很像公司突然搬了办公室，员工用的分机号码全部变了，外部客户还是照着老号码打，自然打不通。Service 要解决的，就是给这一组不稳定的 Pod 提供一个稳定的“总机号码”，同时把电话按规则分给背后的分机。无论后面的 Pod 怎么变，对外暴露的入口始终不变。

1.2 Service 提供给应用的三个核心能力

稳定入口是 Service 最基础的作用，它给一组 Pod 分配一个固定的虚拟 IP（ClusterIP），客户端只需要记住这个虚拟 IP 和应用端口，不需要关心背后 Pod 的创建、销毁和漂移。

第二个能力是负载均衡。通过 Labels 和 Selector，Service 会把请求转发到匹配标签的 Pod 上。默认情况下 kube-proxy 在转发时会做简单的负载均衡，把流量分配到多个副本上，虽然比不了专业负载均衡器的精细化，但对付绝大多数微服务调用场景足够了。

第三个能力是服务发现。集群内部可以通过 DNS 直接解析 Service 名称，比如在命名空间default里有一个名为demo-svc的 Service，任意 Pod 里访问http://demo-svc:8080就能连上。底层是 CoreDNS 在维护 Service 名到 ClusterIP 的映射，这让服务之间不需要硬编码 IP，配置管理省心很多。

1.3 一个 Service 背后站着多少组件

很多人只关注 Service 的 YAML 里type字段，但真正承载流量的是一整套组件链。首先是 kube-proxy，它运行在每个节点上，负责把 Service 的虚拟 IP 翻译成具体的 Pod IP。传统模式下它靠 iptables 规则做 DNAT；性能优化过的集群会切换到 ipvs 模式，转发效率和调度算法都更好。

然后是 Endpoints 和 EndpointSlice。Service 通过 Selector 匹配到的所有 Pod IP 会被持续收集到这里，每次 Pod 变化，这套数据都会更新，kube-proxy 再根据这份“通讯录”维护转发规则。如果 Selector 没匹配到任何 Pod，Service 就处于“空转”状态，请求全部会被丢弃，这是排查 Service 不通时要检查的第一项。

再就是 CoreDNS，它承担服务发现。如果某个 Pod 里解析 Service 域名失败，大概率是 CoreDNS 出问题，或者网络策略挡住了 DNS 端口。

理解了这些组件，再看三种 Service 类型就不会被 YAML 绕晕。三种类型本质上是在用不同的方式暴露同一组后端 Pod，区别只在于“入口开在哪儿”。

2. ClusterIP：集群内部的“虚拟 IP”，治好了我的连接漂移焦虑

2.1 ClusterIP 的工作方式：不是真实存在的 IP

ClusterIP 是 Service 默认的类型，也是最容易被低估的类型。很多人以为它是一个普通 IP，但实际上它是一个只存在于规则里的“虚拟 IP”，没有任何网卡真正绑定它。请求到达这个 IP 后，会被节点的 iptables 规则（或 ipvs 规则）重写，转发到后端的 Pod 上。

举个例子，我创建了一个带 Selector 的 Service，虚拟 IP 是10.96.0.100，后端有两个 Pod，IP 分别是10.244.1.5和10.244.2.8。在节点上查看 iptables 规则，能看到类似“目标 10.96.0.100 的流量，转发到 10.244.1.5 或 10.244.2.8”的规则。这个规则由 kube-proxy 自动维护，后端 IP 变了，规则会自动刷新。

所以你不能去 ping ClusterIP，也别指望它能响应 ICMP 包。它是专门给 TCP/UDP 流量做“地址翻译”用的，不是一块真正的网卡。

2.2 什么时候该用 ClusterIP

我在实践里总结，ClusterIP 的适用场景非常明确：集群内部服务之间的相互调用，或者那些不需要被集群外部直接访问的应用。比如配置中心、内部 API 网关、数据库代理、消息队列消费者，这些都是典型的内部服务。

这里要纠正一个很常见的误区：有人为了“保险”，不管什么服务都创建一个 NodePort。结果节点上开了几百个端口，安全组规则又长又乱，排查问题的时候光对应端口就够喝一壶。实际上内部调用的服务用 ClusterIP 就够了，既安全又省事。DNS 解析出来的也是 ClusterIP，服务间互相访问天然走这一层。

2.3 一个 YAML 看清 ClusterIP 的配置

apiVersion: v1 kind: Service metadata: name: internal-api namespace: app spec: type: ClusterIP selector: app: internal-api ports: - name: http protocol: TCP port: 8080 # Service 提供的端口，客户端访问这个 targetPort: 80 # 实际转发到 Pod 的容器端口

这里port和targetPort最容易搞混。port是客户端访问 Service 时使用的端口，targetPort是后端 Pod 内容器监听的端口。一个是“前台的对外号码”，一个是“分机的真实号码”，我对团队新人的要求永远是：先问清楚这两个字段，再动手写配置。

2.4 headless Service：ClusterIP 的一个特例

把clusterIP显式设置为None，就能创建 headless Service。这种 Service 没有虚拟 IP，DNS 解析会直接返回后端 Pod 的 IP 列表。什么时候需要它？典型场景是有状态应用，比如数据库主从架构，客户端希望直连某个固定的 Pod，而不经过虚拟 IP 转发。再比如需要自己实现负载均衡策略的场景，客户端拿到所有后端 IP 后按自己的规则挑选，而不是依赖 kube-proxy 的默认策略。

我用 headless Service 做过一套自研的 RPC 选主组件，客户端通过 DNS 查到所有副本 IP，再按自定义权重连接，接入层完全绕开了 kube-proxy 的随机转发。当然，这只是特例，大部分无状态服务老老实实用 ClusterIP 就行。

3. NodePort：把服务露出集群的第一扇“朴素大门”

3.1 原理很简单，但细节容易踩坑

NodePort 是让集群外部访问服务的最直接方式：在每个节点上开一个高位数端口（默认范围 30000-32767），外部流量访问“任意节点的这个端口”，都会被转发到对应 Service 的 ClusterIP，再继续转到后端 Pod。

注意“任意节点”这四个字。因为每个节点都监听同一个 NodePort，所以外部访问时，选哪台节点都行。即使某一台节点上的 Pod 不在本地，流量也会被转发到集群内其他节点的 Pod 上，前提是节点之间网络互通。

这个设计让 NodePort 在没有云负载均衡器的裸机环境中特别好用。我在自建的机房集群里，就用 Nginx 把几个节点的 NodePort 端口做了上游代理，对外统一暴露一个入口。外部流量进来后，Nginx 按权重转发到这些节点端口，再由 kube-proxy 转到 Pod。

配置方式如下：

apiVersion: v1 kind: Service metadata: name: web-gateway namespace: app spec: type: NodePort selector: app: web-gateway ports: - protocol: TCP port: 8080 targetPort: 80 nodePort: 30080

如果不写nodePort字段，Kubernetes 会从端口范围里随机分配一个，后面查起来会非常难受。所以生产环境我的习惯是：手动指定有意义的端口号，并把端口和服务的对应关系维护在一份文档或配置管理平台里。

3.2 端口范围与冲突处理

默认端口范围 30000-32767 是很多刚上手的人不理解的：为什么一个服务端口要那么高？原因很简单：避免和节点上的系统端口、应用端口冲突。但实际业务中这个范围往往不够用，尤其是微服务数量多、每个服务都要一个 NodePort 时，几千个端口很快会被耗尽。

遇到这种情况，可以调整 API Server 的启动参数--service-node-port-range。比如改成 20000-40000，但要注意：改完范围后，所有旧端口只要在 20000-40000 之内就不会受影响；如果改成比原来更小的范围，原有超出范围的 NodePort 服务会创建失败。调整之前一定先在测试集群演练一遍，别在生产环境上直接动。

端口冲突也是高频问题。两个 Service 不能在同一节点上使用同一个 NodePort，所以分配端口前最好先查一遍集群现状：

kubectl get svc -A | grep NodePort

如果创建时提示端口冲突，kubectl 会直接报错，把nodePort改成一个没用过的端口即可。

3.3 externalTrafficPolicy 是 NodePort 的灵魂参数

这是我在生产环境中踩过最多坑的地方。NodePort 的externalTrafficPolicy有两个值：Cluster和Local。

默认值是Cluster，意思是流量到达某个节点的 NodePort 后，可能会被转发到集群内其他节点的 Pod 上。这样做的好处是负载均衡效果好，即使某个节点的 Pod 全挂了，流量也不会失败。但坏处也很明显：跨节点转发会做 SNAT（源地址转换），客户端真实 IP 会被抹掉。同时每个节点的转发都会加一层额外开销，链路变长。

Local则意味着只把流量转发到当前节点上的 Pod。如果当前节点上没有对应 Pod，连接可能会被拒绝，负载不均衡的问题更严重。但它在两个场景下无可替代：一是服务端需要拿到客户端真实 IP，比如日志、风控、审计系统；二是对延迟极其敏感的类型，不想多一跳跨节点延迟。

取舍方式我做了个小表格：

我负责的一个日志采集服务，原来用 Cluster 策略，所有访问日志里的客户端 IP 都变成了节点 IP，排查线上问题根本定位不到来源。改成externalTrafficPolicy: Local之后，源 IP 终于准了。但随后我又遇到新问题：某些节点上没有那个服务的 Pod，外部请求打到这些节点上直接被拒，需要依靠上层负载均衡器做健康检查，只把流量转发到有 Pod 的节点。

解决方式是把健康检查端口配置到上层负载均衡器的探测列表里。NodePort 模式下，Service 会自动生成一个healthCheckNodePort，比如 32230。上层 LB 探测这个端口是否健康，不健康就从负载池里剔除。不同云厂商的配置方式不一样，但思路是通用的：健康检查要选对目标，不要只探测 TCP 端口而忽略了 app 层状态。

3.4 裸机环境下的 NodePort 用法

没有云负载均衡器的环境里，NodePort 几乎是外部访问集群的唯一标配方案。但直接暴露节点的任意端口给终端用户很危险，生产环境我通常加一层 Nginx 或 HAProxy 做统一入口。这样最外面的暴露面被收敛成了一个 80/443 端口，内部再通过 upstream 指向一组节点的 NodePort。

还要做好安全组或防火墙策略：只放行外层入口的端口，节点上的 NodePort 范围不要对全公网开放。否则你的集群看起来就像是“满身都是洞”，扫描工具一上来就能发现一大批可趁之机。

4. LoadBalancer：云环境下按需分配的“贵价方案”

4.1 它其实是 NodePort 的“云上增强版”

很多人第一次创建 LoadBalancer 类型的 Service 时，都会有一种错觉：以为这是 Kubernetes 自己实现的负载均衡。它确实“像”一个负载均衡器，但本质上是这样一条链路：LoadBalancer Service = NodePort + 云厂商负载均衡器实例。

当你执行kubectl create -f应用一个 LoadBalancer 类型的 Service 时，集群并不会自己长出一个负载均衡器。它只是向云厂商的 Controller（比如各云平台自带的 cloud-controller-manager）发了一个请求，让云平台在外部创建一台负载均衡实例，并把流量从该实例转发到各个节点的 NodePort 端口上。

所以从某种角度看，LoadBalancer 类型并没有脱离 NodePort 的范畴，它只是在 NodePort 外面又包了一层“云上的门面”。外部用户访问的是云负载均衡器的 IP，云负载均衡器再把流量分发到节点端口。

4.2 从创建到生效的完整流程

我以一次真实操作为例，把流程完整走一遍：

1. 提交一个 LoadBalancer Service 的 YAML：

apiVersion: v1 kind: Service metadata: name: api-lb spec: type: LoadBalancer selector: app: api ports: - protocol: TCP port: 80 targetPort: 8080

2. 查看状态，能看到EXTERNAL-IP字段：

kubectl get svc api-lb

刚提交时EXTERNAL-IP会是<pending>，等云厂商 Controller 创建完负载均衡器并绑定到集群节点，才会变成外网 IP。

3. 云厂商负载均衡器创建完成后，会把流量转发到集群所有节点的 NodePort 上，再由 kube-proxy 转到真正 Pod。

这里的“等”有时候会很折磨人。如果集群用的不是云厂商的托管环境，集群里根本没有 cloud-controller-manager 插件，那这个 Service 会永远pending。很多人在自建集群里执行type: LoadBalancer之后发现没有外网 IP，就是这个原因。

4.3 没有云厂商 Controller 时怎么办

自建机房和裸机集群想用 LoadBalancer 也不是没有办法，社区方案一般是接入裸金属负载均衡器，比如开源的 MetalLB。它通过 ARP 或 BGP 协议把 Service 的外部 IP 广播到局域网，相当于在裸机环境里模拟了一台“软件负载均衡器”。

我建议在以下场景使用 MetalLB：

• 机房环境已经具备基础网络条件，需要给 Service 分配一个外部可路由的 IP；
• 团队不想在外面再专门搭一套 Nginx 做转发，希望直接用type: LoadBalancer统一管理；
• 已经习惯云上 LoadBalancer 的开发流程，希望自建集群有一致的体验。

配置 MetalLB 核心是 IP 地址池：

apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 203.0.113.10-203.0.113.50

地址池要避开局域网里已经在用的 IP 段，否则会出现地址冲突。我用 MetalLB 时踩过一次坑：地址池里塞了一个网关占用的 IP，结果整个局域网部分设备网络闪断，排查了半天才定位到。

另外，自建集群里也可以简单利用externalIPs字段，手动为 Service 指定一个外部 IP。但这个方式的灵活性和自动化程度都比较弱，只适合临时测试或者网络环境特别简单的场景，生产环境我更推荐 MetalLB 这类完整方案。

4.4 LoadBalancer 与四层、七层的延伸

LoadBalancer Service 提供的是四层（TCP/UDP）转发能力，它本身不感知 HTTP 头、URI 等七层信息。如果你希望按路径分发流量、做 TLS 终结、按域名做路由，那就得在 LoadBalancer 前面再接一套 Ingress Controller，比如 Ingress-Nginx 或自建网关。

从架构上常见的流量链路是：

用户流量 -> 云负载均衡器（或裸机 LB） -> 集群 NodePort -> Ingress Controller Pod -> 对应 Service -> 后端 Pod

这样设计的好处是：云 LB 只负责端口转发和高可用，集群内的路由规则由 Ingress 负责，职责分离、扩展性好。不要把业务路由规则都压在 LoadBalancer 上，否则每加一个域名就要改一遍云资源，完全是自找麻烦。

5. 三类 Service 怎么选：给刚接手集群的人一份务实清单

5.1 一句话判断逻辑

很多教程喜欢用“内网选 ClusterIP，外网选 NodePort，云上选 LoadBalancer”来总结，这话大方向没错，但到了真实场景往往不够用。我的判断逻辑稍微细化一点：

5.2 不要为了“统一”而统一

有些团队为了让 YAML 模板看起来整齐，所有服务一律用 NodePort 或一律用 LoadBalancer。这样做表面省事，实际上是在给后续运维埋雷。

我接手过一个集群，里面几十个服务全部是 NodePort。节点防火墙安全组不得不放行整段 30000-32767 的端口，等于把一个巨大的端口段暴露给了潜在风险。然后服务一多，端口冲突、安全组规则爆炸、流量路径不可控这些问题接踵而来。

正确做法是按流量入口类型分类：集群内部调用的全部 ClusterIP；需要对外暴露的再按网络环境单独选择 NodePort 或 LoadBalancer。外部入口统一收敛到一层网关，不要让每个服务各自把端口捅到外面去。

5.3 三种类型其实常常“叠着用”

ClusterIP、NodePort、LoadBalancer 不是互斥关系，而是逐层嵌套的关系。一个 LoadBalancer 类型的 Service 内部必然有 ClusterIP，也必然有 NodePort 作为云 LB 转发到 Pod 的中间层。只是这些细节通常被封装在 YAML 里，不意味着你可以忽略它。

所以排查问题时，从外往内一层层看：先看外部流量有没有到节点端口，再看节点的 kube-proxy 规则是否把流量转到了 Service 的 ClusterIP，最后看 Endpoints 是否为空。按这条链路排查，90% 的 Service 不通问题都能快速定位。

6. 踩坑实录：这些年我在三种 Service 类型上翻过的车

6.1 NodePort 端口随机分配导致安全组配置形同虚设

第一次让开发同事自己创建 NodePort 服务，我忘了强调必须指定nodePort。结果他提交的应用随机分配了 31050 端口，我提前在安全组里放行的 30080 端口完全没有生效，外部访问直接超时。

排查的时候用kubectl get svc -A才看到实际端口，那一刻才意识到：运维规范要写进流程，而不是靠大家自觉。后来我要求所有 NodePort 服务必须在提交前填写端口，并且在 CI 检查里加了一行脚本，检测 YAML 里没有nodePort字段就直接卡住构建。

6.2 LoadBalancer 类型在自建集群里永远 pending

有段时间我们自建了一套 Kubernetes 集群，有同事从云上环境的模板复制了一份 LoadBalancer 类型的 Service 过来，创建之后EXTERNAL-IP一直是 pending。查了半天，才发现集群里根本没有安装支持 LoadBalancer 的 Controller。于是那个 Service 既没有外网 IP，也没有实际转发能力，看起来像存在，实际上就是个“空壳”。

这个教训让我养成了一个习惯：用 LoadBalancer 之前，先确认集群里有没有对应的 cloud-controller-manager 或者 MetalLB。裸机环境没有相关组件，老老实实用 NodePort 或者先部署 MetalLB。

6.3 externalTrafficPolicy: Local 导致部分节点连接被拒

上面提到过，这个参数改为 Local 后，如果客户端流量被分发到一台没有对应 Pod 的节点，连接会被直接拒绝。我当时是在一个三节点集群里做了这个配置，所有外部请求经过上层 Nginx 按轮询算法分发到三个节点，但只有两个节点上有目标 Pod，结果三分之一的请求直接失败。

幸好当时流量没有太大，看到告警后我迅速定位到健康检查端口，把上层 Nginx 的上游服务器调整成只指向有 Pod 的节点，才恢复稳定。这个坑再次验证了：Local 模式必须配合上层健康检查，否则你只是把问题从“流量打偏”变成了“连接被拒”。

6.4 Service 的 Endpoints 为空时，一切配置都白搭

还有一次，一个 ClusterIP 服务突然不通，我排查了 kube-proxy、iptables、DNS，最后才发现问题出在 Selector 写错了。Service 里的标签和 Pod 的标签对不上，Endpoints 列表一直是空的。没有 Endpoints，Service 就像一个没有接线员的总机，所有来电都是忙音。

这个问题的排查最快的方法：

kubectl get endpoints <service-name>

如果看到<none>，先检查 Selector：

kubectl get svc <service-name> -o yaml | grep selector kubectl get pods -l app=xxx

只要 Selector 和 Pod 标签匹配上，Endpoints 就会自动填充，Service 也就通了。

6.5 修改 Service 类型时的平滑过渡

从 NodePort 改成 LoadBalancer，或者反过来，在生产环境尽量不要直接删除重建 Service。虽然 Service 本身不持有业务数据，但 DNS 记录、会话保持、底层依赖方都会受影响。正确做法是先建一个新 Service（比如xxx-v2），等依赖方切换流量到新服务名或新端口后，再删除旧 Service。如果同一个 Service 名称必须保留，就修改它的type字段，Kubernetes 会尽量保持 ClusterIP 不变，但涉及 LoadBalancer 的云资源重新创建速度取决于云厂商。

实测经验是：能平滑就平滑，别贪图一时省事直接删。

7. 最后分享一个我自己常用的“三层验证法”

排查 Service 网络问题，我习惯按照“服务发现层 -> 转发规则层 -> 后端可用层”三层来验证。

第一层，验证 DNS。进入任意 Pod 执行nslookup或dig，确认 Service 名称能解析到 ClusterIP；第二层，验证转发规则。登到节点上看 kube-proxy 是否正常，或者用ipvsadm/iptables查看规则是否存在；第三层，验证后端 Pod。直接访问 Pod IP 和 targetPort，确认应用本身是好的。

按这个顺序走，绝大多数问题都能在十分钟内定位。不要一上来就去翻 kube-proxy 的日志，那通常是最耗时间的一种方式。

Service 的三种类型其实只是同一套“总机 + 分机 + 外线”机制的不同呈现方式。把链路拆开看，每一层都不复杂；难的是在真实集群里把各种边界条件、策略参数和组件状态同步考虑进来。希望这些经验能帮你少走点弯路，至少在下次扩容或者迁移流量的时候，不用像我一样对着 ClusterIP 干瞪眼一上午。