在我之前的面试中，有好几次都问到了这个问题，但是回答的不是很好。但是，后面还挺不错，面试官还帮我解释了下，我们就直接面对吧。
我们后面有面试群，有兴趣可以加入。
在 Kubernetes 集群中，某些容器镜像（如基于 scratch 或 distroless 的镜像）为了追求极简化和安全性，移除了交互式 Shell（如 /bin/bash 或 /bin/sh）以及常见网络工具（如 curl、ping）。当这类 Pod 出现外网访问异常时，传统调试方法失效，需要更高级的技巧。
容器内预装了 curl、wget、nc（netcat）等工具，但缺少交互式 Shell。
通过 kubectl exec 直接执行命令：
# 测试 HTTP 连通性（curl）kubectlexec<pod-name>-- curl -Iv https://www.google.com# 测试 TCP 端口连通性（netcat）kubectlexec<pod-name>-- nc -zv www.google.com 443# 下载内容验证（wget）kubectlexec<pod-name>-- wget -qO- http://example.com
• 若容器没有这些工具，命令会返回 exec: command not found。
• 可尝试检查容器镜像的文档，确认是否内置其他工具（如 ncat、telnet）。
容器无任何网络工具，且 Kubernetes 版本 ≥1.23（支持临时容器功能）。
Step 1：注入临时容器
kubectl debug-it<pod-name>--image=nicolaka/netshoot --target=<container-name>
• --image：选择一个调试镜像（推荐 nicolaka/netshoot，内置完整网络工具链）。
• --target：指定共享网络命名空间的目标容器。
Step 2：在临时容器中测试外网
# 测试 HTTP 访问curl-I https://www.google.com# 测试 DNS 解析nslookup google.com# 测试 ICMP（ping）ping8.8.8.8
临时容器会共享目标容器的 网络命名空间，因此两者的网络栈（IP、端口、路由等）完全一致。退出临时容器后，它会被自动销毁，不会影响原 Pod。
• 若集群版本低于 1.23，需启用 EphemeralContainers 特性门控。
• 调试镜像可能需要特权权限，需确保 Pod 的 SecurityContext 允许临时容器运行。
临时容器功能不可用，但允许修改 Pod 配置（如测试环境）。
Step 1：编辑 Pod 定义，添加 Sidecar
apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers:-name: main-app image: my-minimal-image:latest# 主容器无 Shell 和网络工具...-name: network-debugger image: nicolaka/netshoot command:["sleep","infinity"]# 保持 Sidecar 运行securityContext: runAsUser:0# 以 root 用户运行（可选）
Step 2：进入 Sidecar 测试网络
kubectlexec-it my-pod-c network-debugger-- curl -v https://www.google.com
同一 Pod 内的所有容器共享同一个网络命名空间，因此 Sidecar 可以直接访问主容器的网络环境。
• 需重新部署 Pod，可能导致服务中断。
• 生产环境中慎用，建议仅在调试阶段添加 Sidecar。
怀疑 DNS 配置错误导致外网访问失败。
方法 1：使用 nslookup（需容器支持）
kubectlexec<pod-name>-- nslookup google.com
方法 2：查看 DNS 配置
kubectl exec <pod-name> -- cat /etc/resolv.conf
预期输出示例：
nameserver 10.96.0.10 # Kubernetes DNS Service IP search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5
• 若 nslookup 失败，检查 CoreDNS 或 kube-dns 是否正常运行：
kubectl get pods-n kube-system-l k8s-app=kube-dns
• 确认 Pod 的 DNS 策略（dnsPolicy）是否为 ClusterFirst。
怀疑网络策略（NetworkPolicy）或云平台安全组阻止外网访问。
Step 1：检查 NetworkPolicy
kubectldescribenetworkpolicy-n<namespace>
重点关注是否有策略限制出站流量（egress）。
Step 2：验证云平台安全组/防火墙规则
• AWS：检查安全组的出站规则是否允许目标端口（如 443、80）。
• GCP：查看防火墙规则中的“出站流量”配置。
• Azure：检查网络安全组（NSG）的出站规则。
Step 3：检查节点 IPtables 规则
登录到 Pod 所在节点，查看 NAT 表和过滤规则：
iptables-t nat-L-n-v iptables-L-n-v
无法修改目标 Pod，且需要模拟相同网络环境。
Step 1：启动跳板机 Pod
kubectl run jumpbox--image=nicolaka/netshoot --rm -it --restart=Never -- /bin/sh
Step 2：在跳板机中通过代理测试目标 Pod 网络
假设目标 Pod 的 IP 为 10.244.1.5：
# 使用 curl 的 --proxy 参数curl-x http://10.244.1.5:80 http://example.com# 使用 nc 测试 TCP 连通性nc-zv10.244.1.580
镜像名称 | 特点 | 适用场景 |
| 包含完整网络工具（curl, tcpdump, dig 等） | 通用网络调试 |
| 轻量级，支持 nslookup、ping | 基础连通性测试 |
| 包含 Shell 和包管理器（apk） | 需临时安装工具的场合 |
编写脚本批量测试多个 Pod 的外网连通性：
#!/bin/bashPODS=$(kubectl get pods-o name|grep target-pod-prefix)forPODin$PODS;doecho"Testing $POD..."kubectlexec$POD-- curl -Is https://www.google.com | head -n 1done
如果 Pod 使用自定义 ServiceAccount，检查其是否被授予访问外网的权限：
# 例：限制 Pod 仅可访问集群内资源automountServiceAccountToken:false
方法 | 复杂度 | 侵入性 | 需重启 Pod | 适用阶段 |
| 低 | 无 | 否 | 开发/测试 |
临时调试容器 | 中 | 低 | 否 | 生产/测试 |
Sidecar 注入 | 高 | 高 | 是 | 测试 |
DNS 检查 | 低 | 无 | 否 | 所有阶段 |
网络策略/防火墙检查 | 中 | 无 | 否 | 生产问题排查 |
跳板机代理 | 中 | 无 | 否 | 模拟生产环境 |
• 现象：Pod 无法访问外网域名，但 IP 直连正常。
• 排查：通过临时容器执行 nslookup，发现 DNS 服务器无响应。
• 根因：CoreDNS Pod 被误删，导致集群 DNS 服务中断。
• 现象：Pod 内访问特定外网端口超时。
• 排查：跳板机测试目标端口正常，但节点安全组禁止出站流量。
• 解决：调整安全组规则，允许目标端口出站。
