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