kube-proxy 打开的端口有什么用途，为什么监听多个端口？
结论
这些端口并不是“每个 ClusterIP Service 都对应一个 kube-proxy 监听端口”。
从输出看，它们主要有以下几类：
127.0.0.1:10249：kube-proxy 的指标接口。[::]:10256：kube-proxy 的健康检查接口。10.0.0.154:59638 -> 10.0.0.154:6443：kube-proxy 连接 Kubernetes API Server 的客户端连接。59638是临时源端口，不是服务端监听端口。31860、11989、26879、8100、10055...：很可能是集群各命名空间中的 NodePort。kube-proxy 会创建监听 socket 来占用或保护这些端口，实际的数据转发通常仍由 iptables 或 IPVS 规则完成。
你执行的命令是：
kubectl get svc -o wide该命令默认只列出当前命名空间中的 Service，所以只能查到当前命名空间里的 31860。要核对 kube-proxy 的所有监听端口，需要查询全部命名空间。
各类端口的用途
1. 10249：指标接口
127.0.0.1:10249 LISTEN kube-proxy
这是 kube-proxy 的 metrics 接口，通常供 Prometheus 或节点上的诊断工具采集运行指标。具体的监听地址和端口取决于 kube-proxy 配置，不同集群可能会有差异。
可以在节点上检查：
curl http://127.0.0.1:10249/metrics这个端口与 Kubernetes Service 的 port、targetPort、nodePort 没有对应关系。
2. 10256：健康检查接口
[::]:10256 LISTEN kube-proxy
这是 kube-proxy 的健康检查端口，通常提供 /healthz 等端点：
curl http://127.0.0.1:10256/healthz[::] 表示绑定 IPv6 通配地址。如果没有设置 IPV6_V6ONLY，或者系统允许双栈映射，它也可能接受 IPv4 连接。因此，不能只看 tcp6 就认定该端口只能通过 IPv6 访问。
3. 到 6443 的连接：访问 API Server
10.0.0.154:59638 -> 10.0.0.154:6443 ESTABLISHED
这不是 kube-proxy 在监听 59638，而是一条已经建立的出站连接：
6443是 API Server 的服务端端口。59638是操作系统分配给 kube-proxy 的临时客户端源端口。
kube-proxy 需要连接 API Server，监听 Service、Endpoints 或 EndpointSlice 等对象的变化，并据此更新当前节点上的转发规则。
4. 其余端口：重点检查 NodePort
例如：
[::]:31860 LISTEN kube-proxy
[::]:11989 LISTEN kube-proxy
[::]:26879 LISTEN kube-proxy
[::]:8100 LISTEN kube-proxy
在部分 Kubernetes 版本和 kube-proxy 实现中，kube-proxy 会为 NodePort 创建监听 socket，用于占用端口，防止普通进程抢占。这个 socket 不一定承担应用层代理工作，流量通常会先经过 netfilter 或 IPVS 规则，再转发到后端 Pod。
应先查询整个集群，而不是只看当前命名空间：
kubectl get svc --all-namespaces -o wide更准确的办法是直接列出所有 NodePort：
kubectl get svc -A \
-o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,PORT:.spec.ports[*].port,TARGET_PORT:.spec.ports[*].targetPort,NODE_PORT:.spec.ports[*].nodePort'也可以搜索某个具体端口：
kubectl get svc -A -o yaml | grep -B 8 -A 8 'nodePort: 11989'如果集群支持 JSONPath，可以列出完整映射：
kubectl get svc -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.ports[*]}{.port}{":"}{.nodePort}{" "}{end}{"\n"}{end}'需要特别注意，8100 出现在当前命名空间某个 ClusterIP Service 的 port 中，并不代表 kube-proxy 的 [::]:8100 就属于这个 Service。另一个命名空间中的某个 Service 也可能使用了 nodePort: 8100，两者只是端口号相同。
为什么 NodePort 会低于 30000
Kubernetes 常见的默认 NodePort 范围是 30000-32767，但可以通过 API Server 的 --service-node-port-range 参数修改。
当前输出中有以下端口：
4303
8100
10055
11989
21201
这些端口低于常见的默认范围。如果它们确实是 NodePort，说明集群很可能调整或扩大了 NodePort 范围。问题中没有提供 API Server 配置和 Kubernetes 版本，因此无法仅根据端口号判断具体配置。
可以在控制平面节点上检查 API Server 参数，例如查看静态 Pod 清单：
grep service-node-port-range /etc/kubernetes/manifests/kube-apiserver.yaml也可以检查 API Server 的进程参数：
ps -ef | grep '[k]ube-apiserver' | grep service-node-port-range如果所有命名空间中仍然查不到
如果执行 kubectl get svc -A 后仍找不到某些端口，可以继续检查以下几种情况。
1. kube-proxy 状态尚未收敛
Service 刚被删除时，监听 socket 和转发规则可能还没有清理完成。可以检查 kube-proxy 日志：
kubectl -n kube-system get pods -o wide | grep kube-proxy
kubectl -n kube-system logs <kube-proxy-pod-name>如果 kube-proxy 不是以 DaemonSet 方式运行，则需要查看系统服务日志：
journalctl -u kube-proxy2. 查询的集群上下文不一致
确认 kubectl 当前查询的集群就是该节点所属的集群：
kubectl config current-context
kubectl get nodes -o wide还要确认输出中包含节点 runsdata-test-0001。
3. 检查 kube-proxy 的工作模式和配置
kubectl -n kube-system get configmap kube-proxy -o yaml重点查看：
mode: iptables或者：
mode: ipvs不同 Kubernetes 版本，以及 iptables、ipvs、旧版 userspace 模式，对 socket 的使用方式并不完全相同。不能把所有显示为 kube-proxy 的监听端口都理解成“kube-proxy 在用户态接收并转发业务流量”。
4. 直接核对转发规则
iptables 模式下可以检查：
iptables-save | grep -E '31860|11989|26879|8100'如果系统使用 nftables 后端，也可以检查：
nft list rulesetIPVS 模式下可以检查：
ipvsadm -Ln与单独查看 ss 相比，这些结果更能说明端口最终被转发到了哪个 Service 或 Endpoint。
为什么大多数 ClusterIP 端口不会出现在 ss 中
ClusterIP 是虚拟 IP。kube-proxy 通常通过 iptables、nftables 或 IPVS 在内核中实现 Service 转发，不需要为每个 ClusterIP:port 创建普通的用户态监听 socket。
因此，下面这种情况完全正常：
ClusterIP 10.0.6.70:80
该地址可以正常访问，但执行：
ss -lntp不会看到 kube-proxy 监听 80。
ss 和 netstat 主要显示进程创建的 socket，无法完整展示 netfilter 或 IPVS 中的虚拟服务与转发规则。
注意事项
- 使用
kubectl get svc -A查询所有 Service，不要只看当前命名空间。 - 注意区分
port、targetPort和nodePort，三者的含义不同。 ss中的ESTAB表示已经建立的连接，不是监听端口。[::]:PORT不一定表示该端口只能通过 IPv6 访问。- 不要仅凭端口号相同，就把 kube-proxy 的监听 socket 与某个 ClusterIP Service 关联起来。
- 不建议手动终止这些监听 socket，也不要直接删除 kube-proxy 生成的规则。这些内容会被重新同步，手动修改还可能导致 Service 流量异常。
综合来看，10249 和 10256 是 kube-proxy 自身的管理接口，59638 -> 6443 是 kube-proxy 访问 API Server 的客户端连接，其余端口很可能是整个集群范围内的 NodePort。当前查询只覆盖了一个命名空间，所以才会出现“大部分监听端口找不到对应 Service”的现象。
备注：内容仅供参考。