目录标题
Cilium
在开启了 Cilium 作为 CNI / Service 代理后,NodePort 并不像 iptables/ipvs 那样由 kube-proxy 管理,而是全部通过 eBPF map 在内核里做转发。要查看 Cilium 下的 NodePort,常用几条命令:
-
查看所有服务及其对应的 ClusterIP/NodePort/LB IP 列表
cilium service list这个命令会给出一个表格,里面有:
ID:Cilium 给每个 Service 分配的内部标识Frontend:ClusterIP:Port、NodePort(0.0.0.0:NodePort)或外部 LB IPBackends:对应的 Pod IP:Port
-
查看底层 eBPF LB 路由(相当于 “iptables -t nat”)
cilium bpf lb list输出里,你可以看到所有 Service frontend(包括 NodePort)和它们的后端节点分布情况。
-
如果想直接看 eBPF map
-
列出所有 map:
bpftool map list -
找到与 Service LB 相关的 map(一般名字里带
cilium_lb4_*或cilium_services_v4),然后:bpftool map dump name cilium_services_v4或者
bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_services_v4
这样可以看到 key(VIP、Port、Proto)到 value(Backend IDs)的映射。
-
-
Kubernetes 原生视角(仅做配置核对)
kubectl get svc -A -o wide或者
kubectl describe svc my-service -n my-namespace这里能确认为 Service 分配了哪个 NodePort。
示例:
假设你有一个在 default 命名空间下叫 web 的 Service,NodePort 是 30080,可以这样做:
# 列出所有 Service,看 ID 和 Frontend
cilium service list | grep web
# 查看 eBPF LB 详情,确认 NodePort 30080 映射到哪些后端
cilium bpf lb list | grep 30080
通过上述命令,就能在 Cilium 的 eBPF 层面,准确看到 NodePort 的转发规则,以及它被转发到哪些 Pod 上。


kube-proxy
在 Kubernetes 的 NodePort 模式下,其实并没有一个进程在宿主机上“直接” listen 这个端口,所以用 ss/netstat 是看不到的。NodePort 的流量是通过 kube-proxy 在 netfilter(iptables/IPVS)层面做 DNAT/NAT 转发的,你要看的是那里的规则:
-
iptables 模式下
# 列出 nat 表中所有的 NodePort 转发规则 iptables -t nat -L KUBE-SERVICES -n --line-numbers | grep <NodePort>或者更全一点:
iptables -t nat -L -n | grep <NodePort>你会看到类似:
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:30080 to:10.244.1.5:80这就说明所有到宿主机 30080 的 TCP 请求都会被转发到 Pod 的 IP:Port。
-
IPVS 模式下(kube-proxy
--proxy-mode=ipvs)
如果你的 kube-proxy 用的是 IPVS,就要用:ipvsadm -Ln | grep <NodePort>会看到类似:
TCP 0.0.0.0:30080 rr -> 10.244.1.5:80 Masq 1 100% -
Kubernetes 原生命令
如果你只是想快速确认哪个 NodePort 对应哪个 Service,也可以直接:kubectl get svc -A -o wide或者:
kubectl describe svc my-service -n my-namespace里边都会列出
NodePort: <port>。
小结:
- ss/netstat 只看进程级别的 listening socket,NodePort 并不是某个进程 bind 的端口;
- iptables-save/ipvsadm 能查看 kube-proxy 在内核层面设置的 DNAT/IPVS 规则;
- kubectl get/describe svc 则是最高层面查看配置和映射。
1688

被折叠的 条评论
为什么被折叠?



