企业官网建设流程全解析

1. 为什么说 NodePort 是 ClusterIP 的“超集”

1.1 不要把包含关系理解成继承

刚接触 Kubernetes 的时候，我一度以为 NodePort 和 ClusterIP 是两种完全独立的 Service 类型，就像两个不同的网络插口。后来有一次排障，在节点上用iptables -t nat -L看规则，才真正意识到 NodePort 并不是在 ClusterIP 旁边另起炉灶，而是在 ClusterIP 这套路由规则之上多开了一道入口。说直白点：NodePort 本身就隐含了一个 ClusterIP，它们不是互斥关系，而是分层的包含关系。搞清楚这一点，很多 Service 的疑难杂症都能迎刃而解。

要特别说明的是，这里的“包含”不是编程语言里的继承，也不是对象嵌套。Kubernetes 的 Service API 对象从头到尾只有一个，没有为 NodePort 单独设计另一个对象类型。spec.type字段决定你创建的是 ClusterIP、NodePort、LoadBalancer 还是 ExternalName。默认不写 type 时，Kubernetes 会当成 ClusterIP。换句话说，创建 NodePort Service 的那一刻，你并没有丢掉 ClusterIP 的能力，clusterIP字段在 NodePort 类型下照样会被填充。从访问能力看，一个 NodePort Service 同时具备两种入口：集群内通过 ClusterIP:Port 访问，集群外通过 NodeIP:NodePort 访问。ClusterIP 是基础，NodePort 是加在基础上的外部入口。

我经常用一个生活类比来解释：ClusterIP 是公司内部分机号，NodePort 是公司总机号码。内部分机只能内部拨打，但总机接通后会自动转接到对应分机。你不可能只申请一个总机号码而没有内部分机号，同理，NodePort 也无法脱离 ClusterIP 独立工作。这个模型解释“包含关系”非常贴切：你想让外部能打进来，前提是内部转接体系存在。

注意：唯一的例外是 headless service（clusterIP: None），它主动放弃 ClusterIP，也就谈不上和 NodePort 的组合。后面会专门说明。

1.2 一个对象，两种入口

很多人初次部署时会在同一个 Deployment 旁边创建两个 Service：一个 ClusterIP 用于内部调用，一个 NodePort 用于外部访问。我在不少项目里都见过这种写法，但大多数情况下完全没必要。你只需要创建一个type: NodePort的 Service，集群内部通过它的 ClusterIP 访问，集群外部通过任意节点 IP 加 NodePort 访问，两个入口都在同一个 DNS、同一个 Endpoints 体系内。

新同事很容易被“两个 Service”搞乱。比如同一个 selector 下面，ClusterIP 的 port 写 80，NodePort 的 port 也写 80，后面改端口时漏改其中一个，外部访问正常，内部调用全部超时。理解了包含关系之后，这种设计应该被砍掉：一个业务用一个 NodePort Service 就够了，内部稳定访问用 Service 名（DNS）直接指向 ClusterIP，外部访问走 NodePort，没必要维护两份配置。

还有一层容易忽略：NodePort Service 的port字段始终存在，集群内部通过 ClusterIP:port 访问依然有效。也就是说，对外暴露 NodePort 的同时，集群内原有的服务发现能力一点没少。这也是“包含关系”在运行行为上的体现——你加的是外挂入口，不是替换原有入口。后来我排障时，经常直接拿同一个 Service 的 ClusterIP 在集群内做 curl，用来区分问题到底出在 NodePort 那一层，还是出在后端 Pod。

2. 从一份 yaml 看 NodePort 与 ClusterIP 的关系

2.1 最小化配置示例

直接看配置最直观。下面这个 yaml 是一个典型的 NodePort Service：

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

字段含义拆开讲：

• port：Service 对外暴露的端口，也是 ClusterIP 这边使用的主端口。无论 type 是 ClusterIP 还是 NodePort，port都必须设置。
• targetPort：后端 Pod 的容器端口，Kubernetes 会把流量转发到这个端口。如果不写，默认等于port。
• nodePort：节点上对外暴露的端口，手动指定时只能在 30000-32767 之间。不写的话，kube-apiserver 会在该范围内随机分配一个未占用端口。

如果想把它改回 ClusterIP，只需要删掉type: NodePort和nodePort: 30080两行，或者把 type 改成ClusterIP。其他字段几乎原封不动。这说明两者共用同一套 Service 模板，差异只在“是否打开节点端口”这一层。

2.2 创建后发生了什么

执行kubectl apply -f web-svc.yaml之后，kube-apiserver 会在后台做几件关键的事：

1. 校验ports.nodePort是否合法且未被占用；
2. 从 Service 网段中分配一个 ClusterIP；
3. 更新 Service 对象，把clusterIP和nodePort写回；
4. 通过 watch 机制触发所有节点上的 kube-proxy 更新规则；
5. Endpoints controller 根据 selector 找到后端 Pod，维护 Endpoints 对象。

你执行kubectl get svc web-svc -o yaml，会看到类似clusterIP: 10.96.10.10和nodePort: 30080的字段同时存在。从 API 对象角度，NodePort 类型下clusterIP字段不是空的，这就是“包含关系”在数据上最直接的证据。Kubernetes 并没有为 NodePort 建立一套独立的数据结构，只是同一个对象多填了两个字段。

如果你在托管 K8s 集群里创建 LoadBalancer 类型的 Service，往往也会看到nodePort字段被自动分配，因为很多负载均衡器实现是以 NodePort 为底座，云上 LB 后端的节点池本质上就是各节点的 NodePort。虽然各家实现有差异，但这种“上层类型包含下层类型”的分层思想是通用的。理解 NodePort 包含 ClusterIP，对理解 LoadBalancer 也很有帮助。

2.3 无头服务例外

clusterIP: None的 Service 不会分配 ClusterIP，也没有 ClusterIP:Port 这个入口。它主要用于 StatefulSet 的 DNS 解析，让 DNS 直接返回后端 Pod IP。这种情况下，本文说的“包含关系”不适用。如果你真的在一个 Service 上同时写clusterIP: None和type: NodePort，很可能会得到无法预期的结果，因为无头服务放弃了稳定虚拟 IP，外部直接通过 NodePort 访问也就失去了统一入口的意义。生产环境一般不会这么组合，这里提出来只是避免你拿着“NodePort 包含 ClusterIP”这个模型去套所有 Service。

3. 数据链路拆解：流量到底是怎么从 NodePort 走到 Pod 的

3.1 iptables/ipvs 下的链路

理解了对象层面的包含关系，还要看数据链路。一个完整的外部访问链路是这样的：

Client -> NodeIP:NodePort -> kube-proxy 规则 -> ClusterIP:Port（虚拟入口）-> Endpoints -> Pod IP:targetPort

很多人会问：为什么流量到节点端口后不能直接转到 Pod IP，非要经过 ClusterIP 这个虚拟 IP？答案在于 Service 的核心机制：负载均衡和健康检查都建立在 Endpoints 和 kube-proxy 的规则链上。ClusterIP 是这条规则链的“主键”，NodePort 只是给主键又开了一个外部入口。

在 iptables 模式下，请求到达 NodePort 后，会先进入KUBE-NODEPORT链，再跳转到以 ClusterIP 命名的KUBE-SVC-XXX链；而从集群内部访问 ClusterIP 时，也是跳到同一个KUBE-SVC-XXX链。换句话说，不管流量从哪里进来，最终负载均衡的选择逻辑是同一套，都由同一个 Service Endpoints 决定转发到哪个 Pod。这就是 NodePort 和 ClusterIP 在实现层面“共享大脑”的本质。

在 ipvs 模式下，kube-proxy 会创建多个 virtual server：一个是 ClusterIP:Port，一个是 NodeIP:NodePort，两者配置的后端 real server 集合是相同的。用ipvsadm -Ln查看的时候，你能看到同一个 Service 的 ClusterIP 和 NodePort 指向同一个后端 Pod 列表。所以在 ipvs 模式下，“包含关系”也一样成立：NodePort 入口进入后，走的是和 ClusterIP 完全一样的负载均衡规则。

3.2 externalTrafficPolicy：决定是否跨节点

NodePort 有一个 ClusterIP 没有的特殊配置，叫externalTrafficPolicy，默认值是Cluster。在 Cluster 模式下，请求到达某个节点，kube-proxy 可能把流量转发到其他节点上的 Pod，此时通常会产生一次 SNAT，源 IP 变成当前节点的 IP，客户端真实 IP 会丢失。Local 模式下，kube-proxy 只把流量转发到本节点上的 Pod，不再跨节点转发，能够保留客户端源 IP。但这个模式的前提是：当前节点上必须有健康的后端 Pod。如果一个节点上没有对应 Pod，从这台机器的 NodePort 访问就会失败，而其他有 Pod 的节点正常。

这个配置经常让人困惑，特别是第一次看到“部分节点 NodePort 不通”时。如果你在 Service 上设置了externalTrafficPolicy: Local，那么节点上没有 Pod 的那台机器“不通”是预期行为，不是故障。ClusterIP 内部访问没有这个问题，因为 ClusterIP 流量本身就限定在集群内部网络，源 IP 的丢失影响不大。NodePort 直接面对外部流量，真实源 IP 经常是业务刚需，所以才会单独有这么一档配置。

注意：externalTrafficPolicy只影响从 NodePort/LoadBalancer 进入的流量，不影响集群内通过 ClusterIP 访问的流量。

4. 什么时候用 ClusterIP，什么时候用 NodePort

4.1 典型使用场景对照

我摸过不少集群，各种 Service 类型都有。简单总结一张对照表：

如果你已经上了 Ingress，业务 Service 直接建 ClusterIP 就够了。Ingress Controller 本身是跑在集群里的 Pod，它访问后端 Service 时用的是 ClusterIP 或者 Service DNS，不需要每个业务额外开 NodePort。NodePort 更适合基础设施层，比如给某些不支持 HTTP 协议的服务做裸端口暴露，或者临时演示、调试。

4.2 端口规划与安全注意事项

NodePort 默认端口范围是 30000-32767，只有 2768 个端口。如果每个业务都是 NodePort，很容易冲突。我在实际操作中会建一张端口分配表，或者约定分区：比如 30000-31000 给核心业务，31001-32000 给测试环境，32001-32767 给临时调试。每次创建 Service 时显式指定nodePort，避免随机分配导致后续排查困难。

安全方面要特别提醒：NodePort 会监听所有节点，只要节点 IP 可达，服务就暴露到了整个网络。Kubernetes 不会帮你做白名单，你必须依赖防火墙/安全组限制来源 IP。云环境里，安全组不要只放行 master 节点，要放行需要对外提供服务的工作节点。如果你在云上使用 LoadBalancer，很多实现是云负载均衡器后端挂载各节点的 NodePort，这时候节点之间的安全组也必须放行 NodePort，否则负载均衡健康检查会失败，表现为部分节点健康检查超时，流量时通时不通。

另外，不要随手把nodePort指定成 80 或 443，默认范围不允许。想暴露标准端口，正确姿势是 Ingress 或外部负载均衡器，而不是去改 kube-apiserver 的--service-node-port-range。除非你真的知道代价，否则不建议乱改这个范围。

5. 实战排查：NodePort 不像 ClusterIP 那么好排

5.1 三个高频问题速查表

实战里 NodePort 的坑比 ClusterIP 多得多。这里整理一个速查表：

列出占用端口的命令我经常用：

kubectl get svc --all-namespaces -o jsonpath='{range .items[*]}{.spec.ports[?(@.nodePort)].nodePort}{" "}{end}'

这样能一次性看到集群里所有被占用的 NodePort，比逐个 namespace 翻要快很多。

5.2 我自己的排查套路和坑

我自己踩过最深的坑，是“端口通但 HTTP 超时”。第一次遇到时，我在节点上用 telnet 测 NodePort，发现端口是通的，说明防火墙和 kube-proxy 都没问题。接着在集群内 curl 这个 Service 的 ClusterIP，发现也是通的。最后一看 Endpoints 是空的，因为后端 Pod 一直没 Ready，selector 打歪了。这个案例非常典型：NodePort 和 ClusterIP 共享同一个 Endpoints，只要你验证了 ClusterIP 通，问题大概率就出在 NodePort 那一层；反过来，如果 ClusterIP 都不通，那就别折腾 NodePort 了，先把后端 Pod 搞定。

另一个容易忽略的点是 kube-proxy 本身。节点状态正常不代表 kube-proxy 正常。排查时先kubectl get pods -n kube-system | grep kube-proxy，再登录节点看相关进程状态。我遇到过内存被撑满导致 kube-proxy 被 OOM Kill 的情况，当时表现就是部分节点 NodePort 不通，而 ClusterIP 访问也时通时不通。这种问题如果不看进程状态，很容易以为是网络插件故障。

最后分享一个小技巧：我会在每个 NodePort Service 的 yaml 里加 annotations，写清楚业务名和负责人。看某个 nodePort 被占时，一条kubectl describe svc就能知道是谁的业务，比翻聊天记录省太多时间。NodePort 包含 ClusterIP 这个概念，平时可能感觉不到，但真正排障的时候，它能帮你快速缩小问题范围：先验 ClusterIP，再验 NodePort，链路立刻清晰。