面試官想聽的不僅是命令——如何結構化回答 “ 容器無 Shell 時如何測試外網 ” ？
引言
在我之前的面試中，有好幾次都問到了這個問題，但是回答的不是很好。但是，后面還挺不錯，面試官還幫我解釋了下，我們就直接面對吧。
我們后面有面試群，有興趣可以加入。
開始
場景背景
在 Kubernetes 集群中，某些容器鏡像（如基于 scratch 或 distroless 的鏡像）為了追求極簡化和安全性，移除了交互式 Shell（如 /bin/bash 或 /bin/sh）以及常見網絡工具（如 curl、ping）。當這類 Pod 出現外網訪問異常時，傳統調試方法失效，需要更高級的技巧。
解決方案
1. 直接調用容器內的網絡工具
適用場景
容器內預裝了 curl、wget、nc（netcat）等工具，但缺少交互式 Shell。
操作步驟
通過 kubectl exec 直接執行命令：
# 測試 HTTP 連通性（curl）
kubectl exec <pod-name> -- curl -Iv https://www.google.com
# 測試 TCP 端口連通性（netcat）
kubectl exec <pod-name> -- nc -zv www.google.com 443
# 下載內容驗證（wget）
kubectl exec <pod-name> -- wget -qO- http://example.com注意事項
? 若容器沒有這些工具，命令會返回 exec: command not found。
? 可嘗試檢查容器鏡像的文檔，確認是否內置其他工具（如 ncat、telnet）。
2. 臨時調試容器（Ephemeral Containers）
適用場景
容器無任何網絡工具，且 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）
ping 8.8.8.8原理解析
臨時容器會共享目標容器的 網絡命名空間，因此兩者的網絡棧（IP、端口、路由等）完全一致。退出臨時容器后，它會被自動銷毀，不會影響原 Pod。
注意事項
? 若集群版本低于 1.23，需啟用 EphemeralContainers 特性門控。
? 調試鏡像可能需要特權權限，需確保 Pod 的 SecurityContext 允許臨時容器運行。
3. 注入 Sidecar 容器共享網絡
適用場景
臨時容器功能不可用，但允許修改 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 測試網絡
kubectl exec -it my-pod -c network-debugger -- curl -v https://www.google.com原理解析
同一 Pod 內的所有容器共享同一個網絡命名空間，因此 Sidecar 可以直接訪問主容器的網絡環境。
注意事項
? 需重新部署 Pod，可能導致服務中斷。
? 生產環境中慎用，建議僅在調試階段添加 Sidecar。
4. 檢查 DNS 解析
適用場景
懷疑 DNS 配置錯誤導致外網訪問失敗。
操作步驟
方法 1：使用 nslookup（需容器支持）
kubectl exec <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。
5. 網絡策略與防火墻檢查
適用場景
懷疑網絡策略（NetworkPolicy）或云平臺安全組阻止外網訪問。
操作步驟
Step 1：檢查 NetworkPolicy
kubectl describe networkpolicy -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 -v6. 使用跳板機 Pod 代理測試
適用場景
無法修改目標 Pod，且需要模擬相同網絡環境。
操作步驟
Step 1：啟動跳板機 Pod
kubectl run jumpbox --image=nicolaka/netshoot --rm -it --restart=Never -- /bin/shStep 2：在跳板機中通過代理測試目標 Pod 網絡
假設目標 Pod 的 IP 為 10.244.1.5：
# 使用 curl 的 --proxy 參數
curl -x http://10.244.1.5:80 http://example.com
# 使用 nc 測試 TCP 連通性
nc -zv 10.244.1.5 80進階技巧與工具推薦
1. 調試鏡像選擇
鏡像名稱 | 特點 | 適用場景 |
| 包含完整網絡工具（curl, tcpdump, dig 等） | 通用網絡調試 |
| 輕量級，支持 nslookup、ping | 基礎連通性測試 |
| 包含 Shell 和包管理器（apk） | 需臨時安裝工具的場合 |
2. 自動化檢查腳本
編寫腳本批量測試多個 Pod 的外網連通性：
#!/bin/bash
PODS=$(kubectl get pods -o name | grep target-pod-prefix)
for POD in $PODS; do
echo "Testing $POD..."
kubectl exec $POD -- curl -Is https://www.google.com | head -n 1
done3. 使用 ServiceAccount 權限驗證
如果 Pod 使用自定義 ServiceAccount，檢查其是否被授予訪問外網的權限：
# 例：限制 Pod 僅可訪問集群內資源
automountServiceAccountToken: false總結表格：方法對比
方法 | 復雜度 | 侵入性 | 需重啟 Pod | 適用階段 |
| 低 | 無 | 否 | 開發/測試 |
臨時調試容器 | 中 | 低 | 否 | 生產/測試 |
Sidecar 注入 | 高 | 高 | 是 | 測試 |
DNS 檢查 | 低 | 無 | 否 | 所有階段 |
網絡策略/防火墻檢查 | 中 | 無 | 否 | 生產問題排查 |
跳板機代理 | 中 | 無 | 否 | 模擬生產環境 |
真實案例分享
案例 1：DNS 解析超時
- ? 現象：Pod 無法訪問外網域名，但 IP 直連正常。
- ? 排查：通過臨時容器執行
nslookup，發現 DNS 服務器無響應。 - ? 根因：CoreDNS Pod 被誤刪，導致集群 DNS 服務中斷。
案例 2：云平臺安全組限制
- ? 現象：Pod 內訪問特定外網端口超時。
- ? 排查：跳板機測試目標端口正常，但節點安全組禁止出站流量。
- ? 解決：調整安全組規則，允許目標端口出站。
