上一篇我们把ClusterIP聊透之后有个朋友跑来问我我在集群里跑的服务集群内部访问一切正常一到集群外面就抓瞎了总不能每次测试都跳进容器里curl一下吧。这个问题特别典型Kubernetes里大多数Service默认类型就是ClusterIP它只能在集群内部网络里用想暴露出去就得换类型。而所有暴露方式里最基础、最好理解、也最方便排查的就是NodePort。无论你拼成kubernetes还是kubenetes手滑输错单词这事我也没少干但NodePort这个概念值得你认真搞明白。这篇就把NodePort从原理到实操到踩坑一次讲透。1. 先搞明白NodePort到底解决了什么问题1.1 ClusterIP的边界只能在集群内部打转Kubernetes里Service的基础形态是ClusterIP它在集群内部有一个虚拟IPPod通过这个IP访问Service再由Service把流量负载均衡到后端的Pod上。这套机制在集群内非常好用所有内部服务都能通过一个稳定IP互相访问不关心后端Pod漂到了哪个节点也不关心Pod的IP换没换。但是ClusterIP有一个天然边界它的虚拟IP只在集群网络里生效。你在集群外网机器上无论如何都ping不通这个IP也没法通过它发HTTP请求。原因很简单——ClusterIP是虚拟的它只存在于kube-proxy生成的规则里并不真实挂在某块网卡上集群外根本没有路由能到达它。这就带来了一个很现实的痛点开发团队在集群里起了个服务产品经理想在浏览器里看看效果测试同学想跑一轮接口用例你总不能让所有人都去学kubectl port-forward更不能让他们随便跳进容器里操作。这时候就需要一个让集群外流量能进来的入口NodePort就是最朴素、最直接的一种。1.2 NodePort适用场景测试暴露、临时入口、混合网络NodePort做的事情一句话就能说清在集群的每一个节点上开一个固定的端口任何外部请求只要打到“任意节点的IP 这个端口”就会被转发到对应的Service再由Service负载均衡到后端Pod。这个设计思路听着简单但非常实用。我实际用下来NodePort最常见的场景大概是这么几类。第一测试环境快速暴露服务。开发自测或者QA验证功能时光有ClusterIP大家都访问不了用NodePort把服务暴露出来把“节点IP:NodePort”发给同事浏览器直接就能打开整个过程行云流水比配什么网关、域名都快得多。第二临时 debug 入口。线上环境出了疑难杂症需要临时暴露一个端口抓包或者看监控面板又不想大动干戈改Ingress规则临时起一个NodePort Service验证完再删干净利落。第三混合网络环境下的互通。比如你有一部分服务跑在Kubernetes集群里另一部分还在传统VM上两边要联调通过NodePort让VM那侧直接访问“集群节点IP端口”很省事不需要额外搭专线或者做复杂的网络打通。当然NodePort不是生产环境对外开放流量的“终级答案”这后面我会专门讲它和LoadBalancer、Ingress的取舍。但先把NodePort吃透后面理解其他类型会轻松很多。2. 十分钟从零创建一个NodePort Service2.1 先起一个演示用的Deployment纸上谈兵没意思直接动手创建一个。先准备一个最小化的Deployment用nginx镜像充当业务Pod方便验证访问是否成功。我在这里用不同节点数量来模拟真实场景但就算你只有一个节点也能复现整个过程。apiVersion: apps/v1 kind: Deployment metadata: name: webapp-deploy spec: replicas: 3 selector: matchLabels: app: webapp template: metadata: labels: app: webapp spec: containers: - name: webapp image: nginx:alpine ports: - containerPort: 80replicas设置成3是为了后面能清楚看到Service把请求分发到了不同Pod上。ngin x容器默认监听80端口所以我们后面的targetPort直接用80。保存为deploy.yaml执行kubectl apply -f deploy.yaml kubectl get pods -o wide正常情况下你会看到3个Pod分布在不同的节点上各自有独立的Pod IP。记住这些Pod IP后面讲转发链路时会用上。2.2 Service的YAML长什么样Service的YAML才是今天的重头戏。下面这个就是最典型的NodePort类型ServiceapiVersion: v1 kind: Service metadata: name: webapp-svc spec: type: NodePort selector: app: webapp ports: - port: 80 targetPort: 80 nodePort: 30080关键点就在spec里面这几项type明确写成NodePortselector负责把带有appwebapp标签的Pod归入后端ports里面有三个端口概念很容易搞混这里先记住nodePort是30080也就是集群每一个节点上都要开出来的端口。保存为svc.yaml执行kubectl apply -f svc.yaml kubectl get svc -o wide输出大概长这样NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE webapp-svc NodePort 10.96.123.45 none 80:30080/TCP 10s注意PORT(S)这一列写的是80:30080/TCP。冒号左边是Service的portClusterIP上跑的端口右边是NodePort节点上暴露的端口。这说明这个Service同时在两个维度上提供服务集群内部可以通过ClusterIP:80访问集群外部可以通过任意节点IP:30080访问。2.3 用kubectl验证访问链路创建完成后验证是必须的。先验证集群内部的ClusterIP访问是否正常kubectl run curl-test --imagecurlimages/curl --rm -it --restartNever -- curl http://10.96.123.45然后验证集群外的NodePort访问。只要你的机器能访问到其中一个节点的地址直接curl“节点IP:30080”就行curl http://192.168.1.11:30080 curl http://192.168.1.12:30080不管打哪个节点的IP只要该节点能正常和集群通信都会返回nginx的欢迎页。这里值得多做一步反复访问十几次再从kubectl get endpoints观察后端Pod的IP变化能很直观看到负载均衡效果。提示如果集群只有minikube这类单节点环境NodePort端口有时候默认只暴露在特定网络接口上可以先用kubectl cluster-info确认控制面地址再拼上NodePort端口去访问。3. 底层原理三个端口与数据包流转3.1 port、targetPort、nodePort的分工很多人第一次写Service都会被三个端口绕晕其实拿日常生活类比一下就完全懂了。port是Service对外亮出的“服务总机号码”集群内部的人打这个号码就能找到服务targetPort是后端Pod上真正运行的“分机号码”总机接通后要把电话转到这个分机nodePort则是小区大门的“访客通道号”外部的人先通过通道进小区再由保安转接到总机。具体到这个例子里外部请求走“节点IP:30080”nodePort30080是入口到了集群内部kube-proxy会把流量转向Service的ClusterIP:80这里port80是虚拟IP上挂的端口最终再由转发链转到某个后端Pod的80端口targetPort80是容器里nginx监听的端口。三个端口的关系可以整理成下面这张表端口代表含义访问位置默认行为portService在ClusterIP上监听的端口集群内部访问用“ClusterIP:port”必填项targetPort后端Pod容器内实际监听的端口每次转发时的最终目的地默认与port相同nodePort每个节点对外开放的端口集群外部访问用“节点IP:nodePort”默认随机30000-32767在创建NodePort Service时nodePort其实可以不写系统会从30000到32767之间自动分配一个端口。但生产环境我一般建议显式指定因为自动分配的端口每次重建Service都可能变客户端那边的防火墙规则、安全组策略就可能对不上显式指定反而省心。3.2 kube-proxy和iptables是怎么干活的NodePort能工作的核心是kube-proxy在集群每个节点上写入了一系列iptables规则。你可以在任意节点上执行iptables-save找到和webapp-svc相关的链里面大致会有三类规则。第一类是NodePort入口规则匹配目的端口是30080的流量把它导流到对应的Service链-A KUBE-NODEPORTS -p tcp -m comment --comment default/webapp-svc -m tcp --dport 30080 -j KUBE-SVC-XXXX第二类是ClusterIP入口规则匹配目的IP是ClusterIP且端口是80的流量也导到同一个Service链-A KUBE-SVC-XXXX -d 10.96.123.45/32 -p tcp -m comment --comment default/webapp-svc -m tcp --dport 80 -j KUBE-SEP-XXXX第三类是分发规则Service链会按权重把流量随机送到不同的后端。每个后端会对应一条KUBE-SEP链-A KUBE-SVC-XXXX -m comment --comment default/webapp-svc -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-AAAA -A KUBE-SVC-XXXX -m comment --comment default/webapp-svc -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-BBBB -A KUBE-SVC-XXXX -m comment --comment default/webapp-svc -j KUBE-SEP-CCCC看到没当请求打到某个节点的30080端口时这个节点上的iptables规则会先做一轮DNAT把目标从“节点IP:30080”改写成“Pod的IP:80”然后再把包送进集群网络里最终到达某个nginx容器。这里有个很多人忽略的细节如果你添加或删除了Service后端Podiptables规则会立刻变化。因为kube-proxy通过API Server监听Service和Endpoint的变化一旦发现变动马上重写规则。这也解释了为什么Pod重启之后IP变了但Service访问依然正常——规则里的后端IP会跟着更新。3.3 externalTrafficPolicy保不保留源IP的分岔路NodePort部署到一定规模后你会碰到一个隐藏选项externalTrafficPolicy。这个字段默认是Cluster还有一个可选值是Local。别小看这个字段它决定了流量进来后会不会丢失客户端的真实源IP也关系到转发效率。默认Cluster模式下流量进入某个节点后如果这个节点上没有对应Podkube-proxy会把包再转发给其他节点上的Pod。这个“跨节点转发”的过程会做一次SNAT把源IP改写成当前节点的IP。好处是负载均衡非常均匀任何节点上的NodePort都能访问服务坏处是你后端的Pod只能看到节点IP看不到真实客户端IP。有些日志分析类应用需要真实源IP这就有点尴尬了。换成externalTrafficPolicy: Local后NodePort流量只在本机流转节点上如果本来就有后端Pod就转发给本机Pod如果本机没有Pod请求直接拒绝。这样做的好处是保留了源IPPod日志里能看到真实的客户端地址同时少了一层转发性能略好。坏处也明显你访问一个没有Pod的节点服务就不可用了。所以设置为Local时接入层前面最好再加一层负载均衡只把流量转发给那些确实运行了Pod的节点。注意实际生产里如果需要真实客户端IP又不想牺牲高可用一般不会光靠NodePort加Local而是选用LoadBalancer配合对应的负载均衡产品或者在Ingress层处理。NodePort适合快速调试场景Local模式更适合You明确知道流量只会打到特定节点时再用。4. 实战踩坑常用问题与排查实录4.1 nodePort超出范围或端口冲突NodePort最常犯的错就是端口号不在允许范围内。默认情况下Kubernetes只允许30000到32767之间的端口作为nodePort你可以通过API Server的启动参数--service-node-port-range调整但绝大多数情况下不应该改这个范围是官方为了避免和宿主机常用端口冲突特意划出来的。我之前就见过有人在Service里写nodePort: 8080apply时报错The Service webapp-svc is invalid: spec.ports[0].nodePort: Invalid value: 8080: provided port is not in the valid range. The range of valid ports is 30000-32767这个报错写得很明白照着改就行。另一种情况是端口本身在范围内但和宿主机上已经运行的进程冲突了kube-proxy在尝试监听这个端口时会失败Service状态看起来异常NodePort一直访问不了。排查时可以登录节点执行ss -tlnp | grep 30080先看看端口有没有被占用。有一点需要特别提醒哪怕这台节点当前没有后端PodnodePort端口也会被kube-proxy监听所以有些节点看似空闲端口仍然不能用。4.2 怎么排查“curl不通”NodePort建好了curl请求却一直超时或者connection refused这种事情太常见了。别慌按照下面这个思路一层层往后排查通常几分钟就能定位问题。先看Service本身有没有后端kubectl get endpoints webapp-svc如果endpoints列表是空的说明selector没匹配到任何Pod。最常见的两种原因一是Deployment的label写错了二是Service和Pod不在同一个namespace。前者用kubectl get pods --show-labels对比一下就能看出来端倪。再看Pod是否Ready。如果Pod一直处于CrashLoopBackOff或者Pending状态Service即使有endpoints也不可能正常转发用kubectl get pods看看状态再kubectl logs看容器日志。如果Service和Pod都没问题那就要判断是不是iptables规则没生效。可以登录节点执行iptables -t nat -L KUBE-NODEPORTS -n | grep 30080有对应的规则就说明规则层面到位了。如果规则缺失多半是kube-proxy异常检查kube-proxy Pod状态或者直接重启对应节点的kube-proxy组件。最后还要检查一下防火墙和安全组。很多云平台默认会在安全组里挡住非标准端口你在集群内部怎么测都通一换外部机器就不行十有八九是安全组没放行3万以上的端口。这种问题纯靠折腾Kubernetes是解决不了的。4.3 NodePort的一些天然短板用多了NodePort你会慢慢感受到它的几个先天限制。第一个就是端口数量有限默认只有30000到32767共2768个端口。如果服务数量多或者单个Service开了多个端口端口迟早会不够用。第二个是全节点监听每个Service的NodePort会占用集群内每一个节点的同端口节点多了以后端口利用率很低。第三个是外层缺少七层能力NodePort本质上只能做四层TCP/UDP转发没法根据域名、路径做路由如果要在同一个端口上挂多个域名不同服务NodePort做不了。还有一点很少被提到NodePort的访问体验依赖节点本身的网络健康。某个节点宕机或者网络分区了你拿这个节点IP去访问NodePort自然失败。所以在生产环境如果用NodePort对外提供服务前面一般都会配一个负载均衡器做节点健康检查把故障节点自动摘掉。5. 到了该问的问题NodePort和LoadBalancer、Ingress怎么选5.1 一张表看懂三种暴露方式同一个“让集群外访问”的需求Kubernetes给了好几套方案NodePort只是最底层的那一个。与其每次都纠结不如把它们的定位搞清楚。暴露方式工作层级访问入口典型场景成本ClusterIP四层/虚拟IP集群内部IP服务间调用无NodePort四层/节点端口每个节点固定端口测试暴露、临时入口无LoadBalancer四层/云负载均衡云厂商LB实例IP云上生产服务有一定云资源费用Ingress七层/HTTP路由域名或LBHTTP/S服务统一路由分发需要额外部署控制器一个容易混淆的点LoadBalancer类型并不是凭空多出来一套机制它实际上是在NodePort外面包了一层云厂商的负载均衡器。你创建一个type为LoadBalancer的Service时kube-proxy照样会在每个节点上开NodePort端口然后云平台创建一个LB实例把流量转发到各节点的NodePort上。所以理解了NodePortLoadBalancer的原理也就能猜个八九不离十了。Ingress则是更高层的抽象它不看IP和端口而是根据域名和URL路径来做转发把流量路由到不同的Service上。它适合HTTP服务比较多的场景因为一个入口能通向所有Service还方便挂HTTPS证书、做限流和灰度发布。5.2 我的一般性建议我自己实际选型时基本遵循这样的思路集群内部服务互调一律用ClusterIP别为了图省事全都上NodePort——Internal traffic不需要也不应该暴露到外部。开发测试环境或者临时排查问题NodePort是最快的选择三分钟搞定访问链路。云上生产环境对外提供服务优先考虑LoadBalancer类型的Service交给云平台处理负载均衡和健康检查。如果服务是HTTP/HTTPS为主尤其还要做域名区分、证书管理、灰度路由那就把Ingress控制器优先考虑让Service保持ClusterIP模式由Ingress统一入口转发。这里提醒一点很多人在生产环境图省事直接创建NodePort然后防火墙只放行某一个节点IP这个做法也挺危险容易形成单点还是要遵循合理方案的思路让流量先经过一层能感知节点健康状态的负载均衡机制。最后再分享一个小细节。我平时排查网络问题时会特意创建一个临时的NodePort Service来快速验证某个Pod端口是否正常。比如想知道某个应用容器的端口是不是真的在监听就直接起一个Service指向它然后从外部curl一下节点端口。如果通了说明容器和网络链路都正常如果不通再深入排查容器本身。这个办法省了无数次kubectl exec进去敲命令的麻烦。NodePort这东西看着简单但在日常运维里顺手程度远远超出你的预期。
