在 K8s 跨集群網絡出現問題時，你會首先排查哪些常見的網絡層問題？如果這些都排除了，你會繼續如何深入排查？
作者：劉俊夏
開發團隊報告測試集群A的Pod（10.0.1.5）無法訪問生產集群B的Service（prod-svc.prod-ns:8080），運維團隊確認NetworkPolicy允許跨集群流量，安全團隊要求審計全鏈路日志。
引言
面對這樣的情況，你們公司的處理流程是怎么樣的呢，如果你還沒有遇到過，就先提前預防下。
最后有相關的群聊，有興趣可以加入。
開始
問題場景還原
背景：
開發團隊報告測試集群A的Pod（10.0.1.5）無法訪問生產集群B的Service（prod-svc.prod-ns:8080），運維團隊確認NetworkPolicy允許跨集群流量，安全團隊要求審計全鏈路日志。
核心矛盾：
技術層面：跨集群網絡策略、DNS解析、CNI插件兼容性問題協作層面：部門間信息孤島、排查流程不透明
一、場景深度拆解與拓撲分析
1.1 典型多集群架構拓撲圖
測試集群A（AWS EKS） 生產集群B（Azure AKS）
┌───────────────────────┐ ┌───────────────────────┐
│ Namespace: test │ │ Namespace: prod │
│ Pod CIDR: 10.0.1.0/24│ │ Pod CIDR: 10.1.1.0/24│
│ ┌───────────────┐ │ │ ┌───────────────┐ │
│ │ test-pod ├──┐ │ │ │ prod-svc │ │
│ │ 10.0.1.5 │ │ │ │ │ ClusterIP │ │
│ └───────┬───────┘ │ │ │ │ 10.96.1.123 │ │
│ │ │ │ │ └───────┬───────┘ │
│ │ │ │ │ │ │
│ ┌───────▼───────┐ │ │ │ ┌───────▼───────┐ │
│ │ Cilium CNI │ │ │跨云VPC對等連接 │ │ Calico CNI │ │
│ │ BGP Peer ?──┼─┼───────────────────────────? BGP Router │ │
│ └───────┬───────┘ │ │ │ └───────┬───────┘ │
│ │ │ │ │ │ │
└──────────┼───────────┘ └──────────┼───────────┘
│ │
▼ ▼
AWS VPC (vpc-123456) Azure VNet (vnet-7890)1.2 關鍵路徑分析
請求路徑：
test-pod (10.0.1.5) → Cilium CNI → AWS Transit Gateway → Azure ExpressRoute → Calico CNI → prod-svc (10.96.1.123)
潛在故障點：
1. 跨云網絡路由配置（BGP傳播狀態）
2. 集群間防火墻規則（安全組/NSG）
3. CNI插件MTU不匹配導致分片丟失
4. 服務網格mTLS強制策略
5. CoreDNS泛域名解析配置二、kubectl debug全流程實操（含20+診斷命令）
2.1 創建臨時調試容器（生產級技巧）
# 在測試集群A創建共享網絡命名空間的調試容器
kubectl debug -it test-pod-5dfd5d9f7c-abcde \
--image=nicolaka/netshoot:latest \
--copy-to=network-debugger \
--namespace=test \
--target=test-pod-5dfd5d9f7c-abcde \
-- sh
# 驗證容器網絡棧綁定
ip addr show eth0 | grep 'inet '
# 預期輸出：10.0.1.5/24（與目標Pod相同IP）2.2 分層診斷手冊（逐層排除）
第1層：物理網絡連通性
# 測試基礎ICMP連通性（注意生產環境可能禁用ICMP）
ping -c 4 10.96.1.123
mtr -n -t -4 10.96.1.123 -P 8080 --tcp --interval 1
# 檢查路由表
ip route get 10.96.1.123
# 期望輸出：via 10.0.1.1 dev eth0 src 10.0.1.5
# 驗證AWS VPC對等連接狀態
aws ec2 describe-vpc-peering-connections \
--filters Name=status-code,Values=active \
--query "VpcPeeringConnections[?RequesterVpcInfo.VpcId=='vpc-123456']"第2層：傳輸層驗證
# TCP端口連通性測試（替代telnet）
timeout 5 bash -c "</dev/tcp/10.96.1.123/8080" && echo "Success" || echo "Failure"
# 使用socat進行雙向握手驗證
socat -d -d -v TCP4:10.96.1.123:8080 STDIO 2>&1 | grep 'starting connect'
# 檢查conntrack表（排查NAT問題）
conntrack -L -d 10.96.1.123 -p tcp --dport 8080第3層：Kubernetes服務發現
# 解析生產集群Service DNS
dig +short prod-svc.prod-ns.svc.cluster.local @10.96.0.10
# 期望輸出：10.96.1.123
# 檢查CoreDNS配置映射
kubectl get configmap coredns -n kube-system -o yaml | grep 'forward .* /etc/resolv.conf'
# 跨集群DNS劫持測試
kubectl run dns-test --image=busybox:1.28 --rm -it --restart=Never -- \
nslookup prod-svc.prod-ns.svc.cluster.az1.cloudapp.azure.com第4層：網絡策略深度審計
# 導出兩集群所有NetworkPolicy
kubectl get networkpolicies -A -o yaml > clusterA-netpols.yaml
kubectl --context=clusterB get networkpolicies -A -o yaml > clusterB-netpols.yaml
# 使用Calico的calicoctl診斷工具
calicoctl get networkpolicy -o wide --all-namespaces
# 策略模擬測試（需Calico企業版）
calicoctl apply -f - <<EOF
apiVersion: projectcalico.org/v3
kind: PolicySimulation
metadata:
name: cross-cluster-test
spec:
source:
namespace: test
serviceAccountName: default
destination:
namespace: prod
podSelector: app=prod-svc
protocol: TCP
port: 8080
EOF第5層：服務網格攔截分析
# 檢查Istio Sidecar注入狀態
istioctl proxy-config listeners test-pod-5dfd5d9f7c-abcde.test
# 強制繞過Sidecar測試
curl -H "Host: prod-svc.prod-ns.svc.cluster.local" \
--connect-to "prod-svc.prod-ns.svc.cluster.local:8080:10.96.1.123:8080" \
http://prod-svc.prod-ns.svc.cluster.local:8080/api/test
# 解密mTLS握手過程
openssl s_client -connect 10.96.1.123:8080 -debug -state -tlsextdebug -cert client.crt -key client.key2.3 高級診斷工具鏈
# 使用Cilium Hubble進行實時流量追蹤
hubble observe --from-ip 10.0.1.5 --to-ip 10.96.1.123 --verdict DROPPED -o json
# 生成網絡策略沖突報告
kubectl get networkpolicy -o json | jq '[.items[] | {name: .metadata.name, rules: .spec}]' > netpol-audit.json
# 跨集群抓包分析（需特權模式）
kubectl debug --image=corfr/tcpdump -it capture-tool --namespace=prod -- \
tcpdump -i any -s 0 'host 10.0.1.5 and port 8080' -w /tmp/capture.pcap三、跨部門協作標準化模板（含30+字段說明）
3.1 《多集群網絡故障協同排查報告》模板
# 故障追蹤ID：[INC-20240220-001]
## 1. 故障概況
| 字段 | 填寫說明 |
|---------------------|--------------------------------------------------------------------------|
| 受影響服務 | prod-svc.prod-ns (v1.2.3) |
| 故障模式 | 持續性超時/間歇性中斷/認證失敗 |
| SLA影響等級 | P1（核心業務不可用） |
| 跨部門參與團隊 | 開發團隊（@dev-lead）、運維團隊（@ops-lead）、安全團隊（@sec-lead） |
## 2. 環境拓撲詳情
```yaml
network_topology:
clusterA:
cloud_provider: AWS
region: us-west-2
cni: Cilium 1.13.5
service_mesh: Istio 1.18.3
k8s_version: v1.27.4
network_policies:
- name: allow-cross-cluster
selector: app=test-pod
ports: 8080/TCP
clusterB:
cloud_provider: Azure
region: eastus
cni: Calico 3.25.0
service_mesh: Linkerd 2.12.4
k8s_version: v1.26.7
firewall_rules:
- name: allow-inbound-8080
source: 10.0.1.0/24
port: 80803. 多維度排查記錄
3.1 開發團隊輸入
{
"復現步驟": "kubectl exec -it test-pod -- curl -m 10 http://prod-svc.prod-ns:8080/health",
"錯誤日志": "curl: (28) Connection timed out after 10001 ms",
"業務影響面": ["訂單支付流程", "數據分析看板"]
}3.2 運維團隊發現
# ClusterB入口流量監控
$ kubectl logs -l app=prod-svc -n prod --since=5m | grep '10.0.1.5'
< 無結果輸出 >
# NetworkPolicy審計
$ calicoctl get networkpolicy -n prod -o yaml | grep '10.0.1.5'
- 10.0.1.0/24 # 確認允許測試集群CIDR3.3 安全團隊證據
Falco告警日志：
16:02:33.511: "Unexpected cross-cluster connection"
src_ip=10.0.1.5 dst_ip=10.96.1.123 protocol=TCP
WireShark解密流量：
Frame 1234: 78 bytes on wire
Ethernet II: 00:0d:3a:cd:02:01 -> 00:0d:3a:cd:02:02
Internet Protocol: 10.0.1.5 -> 10.96.1.123
Transmission Control Protocol: [SYN] Seq=0 Win=64240 Len=04. 根本原因分析（RCA）
圖片
5. 修復與驗證方案
5.1 緊急修復
# 調整Cilium MTU配置
helm upgrade cilium cilium/cilium -n kube-system \
--set global.mtu=1450 \
--set global.tunnel=disabled
# 臨時放寬Azure NSG規則
az network nsg rule create -g prod-rg --nsg-name prod-nsg \
--name allow-fragments \
--protocol '*' \
--source-address-prefixes 10.0.1.0/24 \
--destination-address-prefixes 10.96.1.0/24 \
--access Allow \
--priority 10005.2 驗證步驟
# 分階段驗證腳本
#!/bin/bash
validate_mtu() {
kubectl exec -it $1 -- ping -M do -s 1472 -c 4 $2 | grep "0% packet loss"
}
validate_mtu "test-pod" "10.96.1.123"
validate_mtu "prod-svc-pod" "10.0.1.5"6. 事后復盤與改進
6.1 技術債務清理
? CNI插件統一化（Cilium → Calico）
? 實施跨集群MTU自動探測機制
6.2 流程改進
新流程：
1. 建立跨集群通信預檢清單（含MTU/DNS/防火墻等20項）
2. 實施變更前的自動化冒煙測試
3. 每周跨部門網絡演練（Chaos Engineering）6.3 監控增強
# Prometheus監控規則新增
-alert:CrossClusterMTUMismatch
expr:increase(cilium_drop_bytes_total{reasnotallow="Fragmentationneeded"}[5m])>0
for:5m
labels:
severity:critical
annotations:
summary: "跨集群MTU不匹配導致分片丟失"四、跨部門協作SOP（含溝通機制設計）
4.1 協作流程圖
圖片
4.2 關鍵溝通話術模板
【緊急故障召集令】
標題：[P1] 跨集群網絡中斷 - 需立即響應
參與方：@dev-lead @ops-lead @sec-lead
會議時間：立即（15分鐘內）
準備材料：
1. 測試集群kubeconfig（有效期2小時）
2. 生產集群只讀審計賬號
3. 最近1小時網絡監控截圖
【跨部門爭議解決】
當出現責任歸屬爭議時：
"根據SLA第3.2條，網絡策略的生效驗證屬于運維團隊職責范圍，
建議立即執行以下命令驗證策略實際生效情況：
kubectl --cnotallow=clusterB get networkpolicy -n prod -o yaml | grep '10.0.1.0/24'"4.3 自動化協作工具鏈
# 使用Crossplane統一管理多集群配置
kubectl apply -f - <<EOF
apiVersion: networking.crossplane.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: cross-cluster-allow
spec:
forProvider:
sourceCluster: clusterA
destinationCluster: clusterB
port: 8080
protocol: TCP
providerConfigRef:
name: aws-azure-config
EOF
# 集成Jira自動化工作流
curl -X POST -H "Content-Type: application/json" \
-d '{"fields":{"project":{"key":"INFRA"},"summary":"網絡故障跟蹤","description":"詳見附件報告"}}' \
https://jira.example.com/rest/api/2/issue/五、專家級調試技巧（生產環境驗證）
5.1 eBPF深度觀測
# 使用Cilium監控TCP重傳
cilium monitor -t drop -t trace --related-to 10.0.1.5
# 捕獲TCP握手失敗事件
bpftool prog load kprobe:tcp_connect ./tcp_connect.bpf.o
bpftool prog tracelog
# 輸出示例：
[4026531993] test-pod-5dfd5d9f7c-abcde connect() to 10.96.1.123:8080 failed with ECONNREFUSED5.2 內核級問題定位
# 跟蹤iptables規則匹配
iptables -t nat -nvL CILIUM_OUTPUT --line-numbers
# 檢查conntrack表狀態
conntrack -L -d 10.96.1.123 -p tcp --dport 8080 -o extended
# 抓取SYN包但無ACK響應
tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' -vvv5.3 混沌工程驗證
# 使用chaos-mesh模擬網絡中斷
kubectl apply -f - <<EOF
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: cross-cluster-loss
spec:
action: loss
mode: one
selector:
namespaces: ["prod"]
loss:
loss: "100%"
direction: from
target:
mode: all
selector:
namespaces: ["test"]
EOF責任編輯：武曉燕
來源：
云原生運維圈
