前言 ：在Kubernetes环境中，telnet能连通NodePort端口但ss命令无法查看到该端口的监听状态，属于正常现象。根本原因在于Kubernetes NodePort的实现机制与常规端口监听方式不同：
一、核心原因分析
-
NodePort的工作原理
NodePort服务并非通过标准的TCP监听进程暴露端口，而是由每个节点上的 kube-proxy 组件在Linux内核的 netfilter层（iptables/IPVS） 创建转发规则。当流量到达节点的NodePort端口时，内核网络栈会根据转发规则直接路由到目标Pod。
-
ss/netstat工具的局限性
这些工具仅能显示用户空间进程监听的端口（如LISTEN状态）。而NodePort的流量转发由内核处理，不涉及用户空间进程监听，因此
ss -tln等命令无法检测到该端口。 -
telnet的验证本质
telnet连接的只是内核网络栈的转发能力。它能成功仅证明内核层已建立正确的NAT规则，并不要求用户空间存在监听程序。
二、补充说明与排查建议
-
跨节点访问差异
若Master节点自身无法访问NodePort（但Worker节点可访问），需排除以下问题：
- 安全组/防火墙限制：确保NodePort端口范围（默认30000-32767）在所有节点的防火墙中放行。
- Master节点隔离策略：某些云平台（如腾讯云TKE）默认禁止Master节点承载工作负载，导致其不处理NodePort流量。此时需通过节点标签调整调度策略。
-
若实际访问失败 （尽管telnet通）
应检查：
- Pod健康状态及端点（
kubectl get endpoints <service>） - kube-proxy日志（
journalctl -u kube-proxy）是否有规则同步错误 - 节点间的网络互通性（如Calico/Flannel网络插件状态）
- Pod健康状态及端点（
结论 ：
ss无法显示NodePort端口属预期行为，实际流量传输由内核层规则控制。若服务访问异常，需聚焦kube-proxy配置、防火墙规则及网络插件排查。