1. 这不是一堆端口名词解释，而是K8s网络流量的“交通指挥图”
你刚在K8s集群里部署了一个Web服务，kubectl get svc看到Service状态是Running，但浏览器死活打不开；或者你改了个nodePort值，集群里所有节点都报错说端口被占用；又或者明明Pod日志显示服务监听了8080，Service却一直提示Connection refused——这些不是玄学，是K8s网络模型里四个端口参数没理清导致的典型“堵车现场”。nodePort、targetPort、port、containerPort、hostPort，这五个词在官方文档里加起来可能就占两页纸，但它们共同构成了K8s流量从外部用户到容器进程的完整路径。我带过十几期K8s实操训练营，90%的学员卡在第一个Service调试环节，问题全出在这几个端口的映射逻辑上。这不是配置错误，是理解断层：把port当成容器端口、把nodePort当成Pod端口、把hostPort和nodePort混为一谈……结果就是反复删yaml、查日志、重启kube-proxy，最后靠“试出来”而不是“想明白”。这篇文章不讲抽象概念，只拆解真实场景下的每一步流量走向：当用户在浏览器输入http://192.168.10.50:30080时，数据包如何穿过Node防火墙、经过kube-proxy重写、命中Service ClusterIP、再转发到Pod IP，最终抵达容器内那个net.Listen("tcp", ":8080")的监听句柄。我会用一张手绘级流程图（文字版）还原整个链路，并告诉你每个端口参数在哪一级生效、改它会动哪一段路、为什么targetPort必须和容器实际监听端口一致、为什么hostPort在生产环境几乎等于“禁用开关”。如果你正在调试一个怎么都访问不了的Service，或者正准备考CKA认证，又或者只是想搞懂K8s网络为什么比Docker Compose复杂十倍——这篇就是为你写的。它不教你怎么复制粘贴yaml，而是让你合上电脑后，能对着白板画出流量路径。
2. 端口五兄弟的本质与分工：谁管入口、谁管中转、谁管出口
K8s里这五个端口参数，本质是同一根流量管道上的五个控制阀门，各自负责不同层级的地址转换。它们不是并列关系，而是嵌套式责任链：外层阀门开得再大，内层阀门关着，水照样流不出去。下面我用一个真实调试案例切入——某次给某高校实验室部署AI推理API服务时，学生反复遇到curl: (7) Failed to connect to 10.0.2.15 port 30080: Connection refused，排查三天才发现containerPort写成了8081，而容器内程序只监听8080。这个错误背后，是五个端口参数的职责完全错位。我们逐个掰开：
2.1 containerPort：容器进程的“耳朵”，必须和代码监听端口严丝合缝
containerPort是Pod模板里定义的端口，写在containers[].ports[]下。它的唯一作用是声明容器内进程实际监听的端口号，仅用于文档化和健康检查（liveness/readiness probe），K8s本身并不强制校验它是否真实监听。但它是整个链条的起点——如果这里写错，后续所有转发都是空中楼阁。比如你的Python Flask应用启动命令是gunicorn --bind :5000 app:app，那containerPort就必须是5000；如果写成8000，Service即使配置正确，流量也会在Pod层面被拒绝。注意：containerPort可以省略，但强烈不建议。省略后K8s无法做端口冲突检测，且kubectl describe pod输出里看不到端口信息，排查时多一层障碍。实操中我习惯把它和代码里的监听端口用同一个常量管理，比如在Dockerfile里定义ENV APP_PORT=5000，然后在deployment.yaml里用{{ .Values.app.port }}引用，避免硬编码不一致。
2.2 port：Service的“虚拟门牌号”，集群内部通信的统一入口
port是Service对象的核心字段，定义在spec.ports[].port下。它代表该Service在集群内部暴露的端口号，也是ClusterIP模式下其他Pod访问此服务时使用的端口。关键点在于：这个端口是虚拟的，只存在于kube-proxy维护的iptables/ipvs规则里，宿主机上根本不存在这个端口的监听进程。比如你定义port: 80，那么在集群内任何Pod执行curl http://my-service:80都能通，但你在Node上netstat -tuln | grep :80绝对找不到对应进程。port的设计哲学是解耦——上游Pod不需要知道下游容器实际监听什么端口（可能是8080/3000/5000），只要认准Service的port即可。这也是为什么K8s推荐用Service名而非Pod IP通信：port提供了稳定的抽象层。常见误区是认为port必须和containerPort一致，其实完全不必。比如后端Java服务监听8080，前端Nginx反向代理它，你可以让Service的port设为80，这样前端Pod只需proxy_pass http://backend-service:80，而不用关心后端到底是8080还是9090。
2.3 targetPort：Service的“精准制导导弹”，决定流量最终打向哪个容器端口
targetPort是Service里最易被忽视却最关键的字段，定义在spec.ports[].targetPort下。它的作用是将Service的port接收到的流量，精确转发到Pod的containerPort上。可以是数字（如targetPort: 8080）或字符串（如targetPort: http，需与containerPort.name匹配）。为什么需要它？因为port是Service对外的抽象端口，而containerPort是容器真实的监听端口，两者经常不一致。比如一个微服务架构中，订单服务Pod监听9090，但Service统一对外暴露80端口供网关调用，这时targetPort就是9090。如果省略targetPort，K8s默认将其设为与port相同值——这正是90%配置错误的根源。我见过太多人写port: 80, containerPort: 8080却忘了写targetPort: 8080，结果流量被错误转发到容器的80端口（而那里根本没服务）。调试时有个速查技巧：kubectl get endpoints <service-name>，如果输出里ENDPOINTS列为空，90%是targetPort和containerPort不匹配；如果显示<none>，基本可断定targetPort指向了不存在的端口。
2.4 nodePort：Node节点的“公共大门”，让集群外流量能敲开K8s的大门
nodePort是Type为NodePort的Service才有的字段，定义在spec.ports[].nodePort下。它的作用是在集群每个Node节点的物理IP上，开放一个固定端口，将外部流量引入Service。比如你设置nodePort: 30080，那么访问http://<any-node-ip>:30080就能触达该Service。技术实现上，kube-proxy会在每个Node上创建iptables规则，将30080端口的流量DNAT到Service的ClusterIP+port。注意：nodePort范围默认是30000-32767，这是Linux内核保留的“非特权端口”区间，普通用户进程不能监听。如果要自定义范围，需修改kube-apiserver启动参数--service-node-port-range。生产环境中nodePort的坑主要在端口冲突：比如Node上已有nginx监听80，你又创建nodePort: 80的Service，kube-apiserver会直接拒绝创建。更隐蔽的问题是防火墙——很多云厂商安全组默认只放行22/80/443，nodePort必须手动添加规则。我给某公司做K8s迁移时，运维同事坚持要用nodePort: 8080，结果发现他们云服务器的iptables里有一条-A INPUT -p tcp --dport 8080 -j DROP，默默拦截了所有流量，查了两天日志才发现。
2.5 hostPort：容器的“直连通道”，绕过K8s网络栈的危险捷径
hostPort是Pod模板里containers[].ports[].hostPort字段，它让容器端口直接绑定到宿主机的指定端口，完全绕过kube-proxy和Service。比如hostPort: 8000, containerPort: 8000，那么访问http://<node-ip>:8000会直接到达该Pod容器，不经过任何K8s网络组件。它的存在意义很窄：主要用于运行DaemonSet类型的系统组件（如日志收集器fluentd、监控代理node-exporter），这些组件需要在每个Node上监听固定端口，且不依赖Service发现。但hostPort有严重缺陷：首先，它破坏了K8s的网络抽象，导致端口在Node间无法复用（一个Node上只能有一个Pod用hostPort: 8000）；其次，它让Pod调度受端口约束——如果Node A的8000端口被占，调度器不会把Pod调度到Node A，可能导致资源浪费；最致命的是安全风险：hostPort等同于在Node上直接暴露容器，一旦容器漏洞被利用，攻击者可直接获得Node权限。因此，在某金融客户审计中，hostPort被列为P0级高危配置，所有使用hostPort的Deployment都被要求立即整改。替代方案永远是：用NodePortService +hostNetwork: true（仅限必要场景），或彻底放弃直连，走标准Service路由。
3. 流量路径全解析：从浏览器URL到容器进程的七步穿越
现在我们把五个端口参数放进真实流量场景，用一次完整的HTTP请求来验证理解。假设你要部署一个简单的Nginx服务，目标是让用户通过http://192.168.10.50:30080访问。以下是数据包从发出到被容器接收的每一步细节，我按时间顺序拆解，每步标注涉及的端口参数和底层动作：
3.1 第一步：用户发起请求，敲下回车键
用户在浏览器输入http://192.168.10.50:30080并回车。这里192.168.10.50是集群中某台Worker Node的物理IP，30080是Service的nodePort。注意：这个IP必须是Node的真实IP（非Pod IP或ClusterIP），且该Node必须处于Ready状态。如果用户误输成http://10.96.0.1:30080（ClusterIP），请求会失败，因为ClusterIP是虚拟IP，只在集群内部路由有效，Node物理网卡根本不响应这个IP的ARP请求。
3.2 第二步：Node防火墙放行，流量抵达kube-proxy
数据包到达Node的eth0网卡，首先经过Linux内核的netfilter框架。此时iptables的INPUT链检查目标端口30080是否允许进入。如果Node启用了firewalld或ufw，必须确保30080端口在允许列表中。放行后，流量进入PREROUTING链，由kube-proxy安装的规则捕获。kube-proxy（以iptables模式为例）在此处执行DNAT（目标地址转换）：将目标IP从192.168.10.50:30080改为Service的ClusterIP（如10.96.123.45:80）——注意端口也从30080变成了Service的port值80。这一步的关键是：nodePort在此完成使命，它只是打开了一扇门，真正的路由决策由port触发。
3.3 第三步：kube-proxy选择后端Pod，执行第二次DNAT
kube-proxy根据Service的Endpoint列表（通过kubectl get endpoints nginx-service可查），用轮询或随机算法选择一个健康的Pod IP（如10.244.1.3）。然后在POSTROUTING链添加第二条DNAT规则：将目标IP从10.96.123.45:80改为10.244.1.3:8080。这里8080来自targetPort的值。如果targetPort未设置，kube-proxy会默认用port的值80，导致DNAT到10.244.1.3:80——而如果容器实际监听8080，这次转发就失败了。这就是为什么targetPort必须显式声明：它告诉kube-proxy“别猜，就打这个端口”。
3.4 第四步：流量穿越CNI网络，抵达Pod所在Node
DNAT后的数据包目标是10.244.1.3:8080，这是一个Pod IP。此时流量需经过CNI插件（如Calico/Flannel）的网络隧道。以Flannel的VXLAN模式为例：Node A（请求入口）的flanneld进程将数据包封装进UDP包，目标地址是Node B（Pod所在Node）的物理IP，UDP端口8472。这个过程完全透明，不涉及任何端口参数，但要求Node间UDP 8472端口互通。如果云服务器安全组未放行此端口，你会看到Connection timed out而非Connection refused——因为包根本发不到Node B。
3.5 第五步：Node B解封装，流量送达Pod网卡
Node B的flanneld收到UDP包，解封装取出原始IP包（目标10.244.1.3:8080），将其注入cni0网桥。cni0通过ARP广播找到10.244.1.3对应的veth pair（如vethabc123），将数据包推送到该veth的另一端——即Pod的网络命名空间。此时Pod的eth0网卡收到目标为10.244.1.3:8080的数据包。注意：Pod IP是集群内路由可达的，但宿主机上netstat看不到对10.244.1.3:8080的监听，因为这是Pod命名空间内的地址。
3.6 第六步：容器内进程监听，containerPort终于登场
数据包到达Pod eth0后，进入容器的网络协议栈。此时内核检查是否有进程在监听0.0.0.0:8080（或127.0.0.1:8080）。这个端口必须与Pod模板中定义的containerPort一致。如果containerPort: 8080，且容器内Nginx配置了listen 8080，则连接建立成功；如果containerPort写成8000，而Nginx监听8080，连接会被内核拒绝，返回Connection refused。这里有个重要细节：containerPort在Pod YAML里只是声明，真正起作用的是容器运行时（如containerd）启动容器时传递的--publish参数，它会调用net.Listen()绑定端口。所以containerPort必须和应用代码/配置文件里的监听端口严格一致。
3.7 第七步：应用处理请求，返回HTTP响应
Nginx进程接收到HTTP请求，读取URI、Header等信息，从文件系统或上游服务获取响应内容，构造HTTP响应包。响应包的目标IP是客户端IP（192.168.10.50），源端口是8080。这个响应包原路返回：经veth → cni0 → flanneld封装 → UDP发送到Node A → Node A flanneld解封装 → kube-proxy SNAT（源地址转换）将源IP从10.244.1.3改为Node A的IP → 最终抵达用户浏览器。整个过程耗时通常在毫秒级，但任一环节配置错误都会导致超时或拒绝。
4. 实操配置与避坑指南：一份可直接抄作业的yaml模板
光说不练假把式。下面我给出一个经过生产环境验证的Nginx Service完整yaml，包含所有端口参数的最佳实践配置，并附上每行的实操注释。这不是示例，是我在某电商大促前夜紧急修复Service故障时用的同一份模板，已去掉所有敏感信息。
# nginx-deployment.yaml - 部署Nginx Pod apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21.6 # 使用明确版本，避免镜像漂移 ports: - name: http # 必须命名，便于targetPort引用 containerPort: 8080 # 关键！容器内Nginx监听8080 protocol: TCP # 注意：这里不配hostPort！生产环境禁用 livenessProbe: httpGet: path: /healthz port: 8080 # 健康检查端口必须和containerPort一致 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /readyz port: 8080 # 就绪检查同理 initialDelaySeconds: 5 periodSeconds: 5 --- # nginx-service.yaml - 暴露Nginx服务 apiVersion: v1 kind: Service metadata: name: nginx-service labels: app: nginx spec: type: NodePort # 必须显式声明，ClusterIP是默认值 ports: - port: 80 # Service集群内端口，前端Pod访问用 targetPort: http # 关键！引用containerPort.name，比数字更安全 nodePort: 30080 # 外部访问端口，30000-32767范围内 protocol: TCP selector: app: nginx # 必须和Deployment的label完全匹配 # 可选：指定SessionAffinity，避免负载不均 # sessionAffinity: ClientIP4.1 配置执行四步法：从apply到验证的完整闭环
第一步：应用配置
kubectl apply -f nginx-deployment.yaml kubectl apply -f nginx-service.yaml执行后观察状态：
kubectl get deploy,po,svc,ep -l app=nginx。理想状态是Deployment READY 3/3，Pod STATUS Running，Service TYPE NodePort，Endpoints显示三个Pod IP（如10.244.1.3:8080,10.244.2.4:8080,10.244.3.5:8080）。如果Endpoints为空，立刻检查targetPort和containerPort是否匹配。第二步：验证NodePort可达性
在集群外部机器（如你的笔记本）执行：curl -v http://192.168.10.50:30080如果返回Nginx欢迎页，说明
nodePort链路通畅。如果超时，检查Node防火墙和云安全组；如果Connection refused，检查Endpoints是否为空或targetPort错误。第三步：验证集群内访问
进入任意Pod（如kubectl exec -it <pod-name> -- sh），执行：curl -v http://nginx-service:80这测试
port和Service DNS是否正常。如果失败，检查CoreDNS是否运行、Service名称拼写、port值是否被其他Service占用。第四步：终极验证——抓包看流量
在Node上用tcpdump抓取nodePort流量，确认是否被kube-proxy重写：# 在Node A上执行（192.168.10.50是Node A IP） tcpdump -i any port 30080 -w nodeport.pcap # 同时在另一台机器curl http://192.168.10.50:30080 # 用Wireshark打开pcap，过滤tcp.port==30080，查看目标IP是否变为ClusterIP如果看到目标IP是
10.96.x.x，说明kube-proxy DNAT生效；如果还是192.168.10.50，说明iptables规则未加载，需重启kube-proxy。
4.2 五个高频致命错误及修复方案
我把过去三年踩过的坑浓缩成一张速查表，按发生频率排序，每条都附带kubectl命令快速定位：
| 错误现象 | 根本原因 | 快速诊断命令 | 修复方案 |
|---|---|---|---|
curl: (7) Failed to connect to <node-ip> port <nodePort>: Connection refused | targetPort与containerPort不匹配，或容器未监听该端口 | kubectl get endpoints nginx-service（看ENDPOINTS是否为空）kubectl logs <pod-name>（看启动日志是否报端口占用） | 检查targetPort值，确保等于containerPort；检查容器内netstat -tuln | grep <port> |
curl: (7) Failed to connect to <node-ip> port <nodePort>: No route to host | Node防火墙或云安全组未放行nodePort | iptables -L INPUT -n | grep <nodePort>（Node上执行）telnet <node-ip> <nodePort>（从外部机器执行） | iptables -I INPUT -p tcp --dport <nodePort> -j ACCEPT云平台控制台添加安全组规则 |
curl: (7) Failed to connect to <node-ip> port <nodePort>: Connection timed out | CNI网络不通，Node间VXLAN/UDP端口被阻断 | nc -u <other-node-ip> 8472（测试Flannel端口）ping <pod-ip>（测试Pod IP连通性） | 检查CNI插件日志（kubectl logs -n kube-system <flannel-pod>）确保Node间UDP 8472/6783等端口开放 |
kubectl get endpoints显示<none> | Service selector标签与Pod标签不匹配 | kubectl get pods -l app=nginx（看Pod是否有对应label）kubectl describe svc nginx-service（看Events是否有no endpoints available） | 修改Service的selector或Pod的metadata.labels，确保key-value完全一致 |
curl http://nginx-service:80在Pod内失败，但curl http://<pod-ip>:8080成功 | CoreDNS异常或Service ClusterIP未生效 | kubectl get svc nginx-service（看CLUSTER-IP是否为10.96.x.x）nslookup nginx-service（在Pod内执行） | kubectl rollout restart deployment coredns -n kube-system检查kube-proxy日志是否有 Failed to update service |
4.3 生产环境端口配置黄金法则
基于上百个K8s集群的运维经验，我总结出三条铁律，违反任何一条都可能引发线上事故：
containerPort必须和应用代码监听端口100%一致，且必须显式声明
理由：containerPort是targetPort的唯一依据，也是健康检查的基础。我曾因CI/CD流水线自动替换containerPort值（从8080变成8000），导致所有Pod就绪探针失败，滚动更新卡在50%，业务中断2小时。解决方案：在Dockerfile中用EXPOSE 8080声明，并在CI脚本中加入校验步骤grep "containerPort: 8080" deployment.yaml || exit 1。nodePort必须在30000-32767范围内，且全局唯一，禁止硬编码
理由：超出范围kube-apiserver拒绝创建；重复使用导致端口冲突。某次灰度发布，两个团队同时申请nodePort: 30080，第二个Service创建失败，但第一个Service的Endpoints被意外清空（bug），导致线上服务雪崩。解决方案：用Helm Chart的rand函数生成随机nodePort，或用K8s的NodePort自动分配（不指定nodePort字段，让K8s从可用池中选）。永远不要在Production Deployment中使用
hostPort
理由：hostPort破坏调度器能力，导致Node资源碎片化。某次大促前扩容，新Node因hostPort: 9100被旧Pod独占，无法调度新Pod，CPU利用率飙升至95%。解决方案：用NodePortService替代，或对DaemonSet使用hostNetwork: true（需评估安全风险）。
5. 常见问题深度排查：从日志、事件到内核态追踪
当标准kubectl命令无法定位问题时，你需要深入到更底层。下面是我处理过的三个经典疑难案例，每个都附带完整的排查路径和命令，不是理论，是血泪教训。
5.1 案例一：Endpoints明明有值，curl却返回Connection refused
现象：kubectl get endpoints nginx-service显示10.244.1.3:8080,10.244.2.4:8080，但curl http://192.168.10.50:30080始终Connection refused。
排查路径：
- 先确认Pod是否真在监听8080：
kubectl exec nginx-deployment-5c7b8d9d4-abcde -- netstat -tuln | grep :8080
→ 发现无输出，说明容器内没监听。 - 查容器日志：
kubectl logs nginx-deployment-5c7b8d9d4-abcde
→ 发现nginx: [emerg] bind() to 0.0.0.0:8080 failed (13: Permission denied)
→ 原因：Nginx在非root用户下运行，而8080端口需要CAP_NET_BIND_SERVICE能力。
终极解决：在Deployment中添加securityContext：
securityContext: capabilities: add: ["NET_BIND_SERVICE"] runAsUser: 101或改用大于1024的端口（如8080没问题，但80需要特权）。
5.2 案例二：nodePort在部分Node上失效，部分Node正常
现象：访问Node A的30080正常，访问Node B的30080超时。
排查路径：
- 检查Node B的kube-proxy状态：
kubectl get pods -n kube-system | grep kube-proxy
→ 发现Node B的kube-proxy Pod处于CrashLoopBackOff。 - 查日志：
kubectl logs -n kube-system kube-proxy-xyz
→F0321 10:23:45.123456 1 server.go:474] listen tcp :10256: bind: address already in use
→ 原因：Node B上已有进程占用了kube-proxy的metrics端口10256。
终极解决：lsof -i :10256找到进程kill掉，或修改kube-proxy启动参数--metrics-bind-address=127.0.0.1:10256。
5.3 案例三：curl在Node上成功，从外部机器失败
现象：在Node A上执行curl http://localhost:30080返回Nginx页，但从公司办公网curl http://192.168.10.50:30080超时。
排查路径：
- 检查Node A的iptables：
iptables -t nat -L KUBE-NODEPORTS -n
→ 发现规则存在：DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:30080 to:10.96.123.45:80 - 用tcpdump抓包：
tcpdump -i eth0 port 30080 -w debug.pcap
→ Wireshark分析发现：外部机器的SYN包到达Node A，但Node A未回复SYN-ACK。
终极解决：检查Node A的sysctl设置：sysctl net.ipv4.ip_forward
→ 值为0，关闭了IP转发。echo 1 > /proc/sys/net/ipv4/ip_forward临时修复，永久方案是修改/etc/sysctl.conf。
5.4 终极武器：eBPF实时追踪kube-proxy行为
当传统方法失效，我用eBPF工具bpftool直接观测kube-proxy的DNAT行为。以下命令在Node上执行，实时显示每次DNAT操作：
# 加载eBPF程序追踪iptables sudo bpftool prog load ./trace_kube_proxy.o /sys/fs/bpf/kubeproxy_trace # 查看追踪日志 sudo cat /sys/fs/bpf/kubeproxy_trace输出类似：[2023-03-21T10:30:45] DNAT from 192.168.10.100:54321 to 10.96.123.45:80 via nodePort 30080
这能100%确认kube-proxy是否执行了DNAT，避免“我以为它该工作”的猜测。
6. 性能与安全加固：让端口配置不止于“能用”
端口配置的终点不是curl通了，而是“稳定、高效、安全”。下面这些加固措施，是我给金融、政务类客户交付K8s集群时的标配。
6.1 性能优化：从iptables到ipvs的平滑升级
kube-proxy默认iptables模式在大规模集群（>100节点）下性能堪忧：每新增一个Service，iptables规则增加O(N)条，导致规则链过长，连接建立延迟升高。某省级政务云集群有2000+ Service，iptables规则超5万条，curl平均延迟从5ms升至200ms。切换到ipvs模式后，延迟稳定在8ms以内。切换步骤：
- 确保Node内核支持ipvs：
modprobe ip_vs && modprobe ip_vs_rr - 修改kube-proxy ConfigMap：
mode: ipvs ipvs: strictARP: true # 防止ARP广播风暴 - 重启kube-proxy：
kubectl rollout restart ds kube-proxy -n kube-system - 验证：
ipvsadm -Ln应显示Service的Virtual Server和Real Server。
6.2 安全加固：限制nodePort范围，杜绝端口滥用
默认nodePort范围30000-32767过于宽泛，攻击面大。某次渗透测试中，安全团队用nmap -p 30000-32767 <node-ip>扫出20个开放的nodePort，其中3个是测试环境遗留的Redis服务（nodePort: 30001），存在未授权访问漏洞。加固方案：
- 缩小
nodePort范围：修改kube-apiserver启动参数--service-node-port-range=30080-30089（只开放10个端口） - 创建PodSecurityPolicy（或PodSecurity Admission）限制
nodePort使用：apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted-nodeport spec: privileged: false allowedHostPaths: [] allowedCapabilities: - NET_BIND_SERVICE # 关键：限制nodePort只能在指定范围 defaultAllowPrivilegeEscalation: false
6.3 监控告警：用Prometheus盯死端口健康状态
端口问题必须前置发现。我在Grafana中配置了三个核心看板：
- Endpoints空闲率：
count(kube_endpoint_addresses{job="kube-state-metrics"}) by (service) == 0，触发告警表示Service无后端。 - NodePort连接失败率：
rate(node_network_receive_errs_total{device=~"eth.*"}[5m]) > 0.1，网络层错误突增。 - 容器端口监听状态：用Blackbox Exporter探测
http://<pod-ip>:<containerPort>/healthz，失败即告警。
这套监控在某次凌晨数据库主从切换时提前15分钟发现targetPort配置错误，避免
