前言
在Kubernetes环境中，容器网络问题往往是最让运维和开发人员头疼的排查场景之一。当业务服务出现无法访问、请求超时等问题时，我们通常需要沿着"容器内应用 → 容器网络命名空间 → 宿主机网络 → K8s Service/Ingress"这条链路逐段排查。本文以一次真实的排查过程为例，详细记录如何通过宿主机命令穿透容器隔离，最终定位并解决端口监听与网络转发问题。
一、问题背景：容器内端口"隐身"
在一次日常巡检中，我们发现名为 backend 的业务服务无法正常响应请求。通过 docker ps 命令，我们确认该容器（ID: d5850912aa2f）处于运行状态，且启动参数中明确指定了 --server.port=80。
然而，当我们尝试在宿主机上排查端口监听情况时，却遇到了障碍：
- 使用
ss -tulnp | grep pid=...过滤该容器主进程PID时，没有任何输出。 - 使用
docker port命令查看端口映射关系时，同样返回为空。
容器明明在运行，启动参数也指定了端口，为什么在宿主机上却看不到任何端口监听的痕迹？
二、破局关键：nsenter穿透网络命名空间
2.1 为什么宿主机看不到容器端口？
要理解这个问题，首先需要明白Docker和Kubernetes的网络隔离机制。容器拥有独立的网络命名空间（Network Namespace），容器内的网络连接、端口监听对宿主机是完全隔离的。在宿主机上直接运行 ss 或 netstat，只能看到宿主机自身的网络栈，无法直接通过PID看到容器内的网络状态。
2.2 获取容器主进程PID
排查的第一步是获取容器主进程在宿主机上的真实PID：
bash
docker inspect -f '{{.State.Pid}}' d5850912aa2f
# 输出: 15524通过 ps -ef | grep 15524 可以确认，该进程确实是一个Java应用，启动参数中包含 --server.port=80。
2.3 使用nsenter进入容器网络命名空间
既然容器内没有 bash 等调试工具，我们可以利用Linux的 nsenter 命令，在宿主机上直接进入容器的网络命名空间，借助宿主机的网络工具进行排查：
bash
nsenter -t 15524 -n ss -tulnp参数说明：
-t 15524：指定目标进程的PID-n：进入该进程的网络命名空间ss -tulnp：列出所有TCP/UDP监听端口及对应进程信息
执行结果如下：
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:36976 *:* users:(("java",pid=15524,fd=25))
tcp LISTEN 0 128 *:1883 *:* users:(("java",pid=15524,fd=42))
tcp LISTEN 0 128 *:80 *:* users:(("java",pid=15524,fd=43))真相大白！ Java进程已经成功监听了80端口（tcp LISTEN *:80），同时还监听了MQTT协议的1883端口和一个UDP端口（36976）。容器内部的网络状态完全正常。
三、问题转移：从容器内到K8s网络层
既然容器内的端口监听没有问题，那么故障点必然在容器外部。结合容器名 k8s_backend-... 可以看出，这是一个由Kubernetes管理的Pod。接下来的排查方向应从"容器内"转移到"K8s网络层"。
3.1 检查K8s Service配置
容器内监听了80端口，但K8s的Service必须正确配置才能将流量转发进来：
bash
# 查看该Pod对应的Service及其端口映射
kubectl get svc -n dev -o wide
# 查看具体某个Service的详情
kubectl describe svc <service-name> -n dev检查重点：
- Service的
targetPort是否配置为80 selector标签是否能正确匹配到该Pod- Service的
ENDPOINTS是否为<none>（如果为空，说明Service没有匹配到任何健康的Pod）
3.2 验证Pod网络连通性
在宿主机上直接测试该Pod IP的连通性，确认CNI网络插件是否工作正常：
bash
# 获取Pod的IP
kubectl get pod k8s_backend-5c444b6494-j44bq -n dev -o wide
# 在宿主机上测试Pod IP的80端口
curl -v http://<Pod-IP>:80- 如果
curl能正常返回，说明容器网络完全正常，问题在于Service或Ingress配置。 - 如果
curl不通，可能是CNI网络插件（如Flannel、Calico）出现了异常，或者节点间的网络路由存在问题。
3.3 检查Ingress路由规则
如果服务是通过域名对外暴露的，还需要检查Ingress配置是否正确：
bash
# 查看Ingress资源
kubectl get ingress -n dev
# 查看Ingress详情
kubectl describe ingress <ingress-name> -n dev确认Ingress的 backend.service.name 和 backend.service.port 是否与目标Service匹配，以及TLS证书（如果有）是否配置正确。
四、排查思路总结
本次排查过程可以提炼为一条通用的K8s网络故障排查路径：
容器内应用监听 → 容器网络命名空间 → 宿主机网络 → K8s Service → Ingress/外部访问| 排查阶段 | 关键命令 | 关注点 |
|---|---|---|
| 确认容器状态 | docker ps |
容器是否Running |
| 获取容器PID | docker inspect -f '{``{.State.Pid}}' |
宿主机上的真实PID |
| 穿透网络命名空间 | nsenter -t <PID> -n ss -tulnp |
容器内端口是否正常监听 |
| 检查Service | kubectl get/describe svc |
targetPort、selector、Endpoints |
| 验证网络连通性 | curl http://<Pod-IP>:<Port> |
CNI网络是否正常 |
| 检查Ingress | kubectl get/describe ingress |
路由规则、后端Service配置 |
五、实用工具推荐
5.1 nsenter：宿主机排查利器
nsenter 是排查容器网络问题的核心工具，它允许你在不进入容器shell的情况下，直接进入容器的各种命名空间（网络、PID、Mount等）。即使容器是精简镜像（如Alpine），没有安装任何调试工具，也能借助宿主机的工具完成排查。
5.2 netshoot：K8s网络调试瑞士军刀
如果需要在容器内进行更深入的网络诊断（如抓包、路由追踪等），推荐使用 nicolaka/netshoot 镜像：
bash
# 以临时容器方式启动，共享目标Pod的网络命名空间
kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot
# 或使用kubectl debug（K8s 1.23+）
kubectl debug -it <pod-name> --image=nicolaka/netshoot --target=<container-name>netshoot内置了 tcpdump、mtr、ss、dig、nmap 等常用网络工具，是K8s网络排障的必备利器。
六、常见坑点提醒
- 应用只监听127.0.0.1 ：如果应用配置了
server.listen(127.0.0.1, 8080)，只接受本机回环地址的连接，集群内其他Pod通过Pod IP访问时会被拒绝。正确做法是监听0.0.0.0。 - Service Endpoints为空：这是Service不通的最高频原因。通常是因为Selector标签不匹配，导致Service无法找到后端Pod。
- 端口映射缺失 ：在Docker单机环境下，如果没有使用
-p参数进行端口映射，外部无法通过宿主机IP访问容器。但在K8s环境中，Pod之间通过ClusterIP或Pod IP直接通信，不依赖端口映射。 - MTU问题：跨节点通信时，如果使用了隧道模式（如Flannel VXLAN），MTU设置不当可能导致大包被丢弃，表现为间歇性网络抖动。
结语
K8s容器网络排查的核心在于逐段定界 ------明确问题出在哪一层，然后针对性地使用工具验证。nsenter 帮助我们穿透容器隔离，kubectl 帮助我们检查K8s网络配置，两者结合基本能覆盖绝大多数网络故障场景。希望本文的排查思路和命令能为你在遇到类似问题时提供参考。