在K8S环境中，telnet nodePort端口是通的，但是 ss 获取不到端口号原因解析

前言：在Kubernetes环境中，telnet能连通NodePort端口但ss命令无法查看到该端口的监听状态，属于正常现象。根本原因在于Kubernetes NodePort的实现机制与常规端口监听方式不同：

一、核心原因分析

1. NodePort的工作原理
   NodePort服务并非通过标准的TCP监听进程暴露端口，而是由每个节点上的 kube-proxy 组件在Linux内核的 netfilter层（iptables/IPVS） 创建转发规则。当流量到达节点的NodePort端口时，内核网络栈会根据转发规则直接路由到目标Pod。

2. ss/netstat工具的局限性
   这些工具仅能显示用户空间进程监听的端口（如LISTEN状态）。而NodePort的流量转发由内核处理，不涉及用户空间进程监听，因此ss -tln等命令无法检测到该端口。

3. 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网络插件状态）

结论：ss无法显示NodePort端口属预期行为，实际流量传输由内核层规则控制。若服务访问异常，需聚焦kube-proxy配置、防火墙规则及网络插件排查。