在 K8s 跨集群网络出现问题时，你会首先排查哪些常见的网络层问题？如果这些都排除了，你会继续如何深入排查？-51CTO.COM

引言

面对这样的情况，你们公司的处理流程是怎么样的呢，如果你还没有遇到过，就先提前预防下。

最后有相关的群聊，有兴趣可以加入。

开始

问题场景还原

背景：

开发团队报告测试集群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.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

1.2 关键路径分析

请求路径：
test-pod (10.0.1.5) → Cilium CNI → AWS Transit Gateway → Azure ExpressRoute → Calico CNI → prod-svc (10.96.1.123)

潜在故障点：
跨云网络路由配置（BGP传播状态）
集群间防火墙规则（安全组/NSG）
CNI插件MTU不匹配导致分片丢失
服务网格mTLS强制策略
CoreDNS泛域名解析配置1.









二、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）1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

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']"1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

第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 80801.
2.
3.
4.
5.
6.
7.
8.

第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.com1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

第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
EOF1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

第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.key1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

2.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.pcap1.
2.
3.
4.
5.
6.
7.
8.
9.

三、跨部门协作标准化模板（含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: 80801.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.

3. 多维度排查记录

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",
  "业务影响面": ["订单支付流程", "数据分析看板"]
}1.
2.
3.
4.
5.

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  # 确认允许测试集群CIDR1.
2.
3.
4.
5.
6.
7.

3.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=01.
2.
3.
4.
5.
6.
7.
8.
9.

4. 根本原因分析（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 10001.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

5.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"1.
2.
3.
4.
5.
6.
7.
8.

6. 事后复盘与改进

6.1 技术债务清理

• CNI插件统一化（Cilium → Calico）

• 实施跨集群MTU自动探测机制

6.2 流程改进

新流程：
建立跨集群通信预检清单（含MTU/DNS/防火墙等20项）
实施变更前的自动化冒烟测试
每周跨部门网络演练（Chaos Engineering）1.




6.3 监控增强

# Prometheus监控规则新增
-alert:CrossClusterMTUMismatch
expr:increase(cilium_drop_bytes_total{reasnotallow="Fragmentationneeded"}[5m])>0
for:5m
labels:
    severity:critical
annotations:
    summary: "跨集群MTU不匹配导致分片丢失"1.
2.
3.
4.
5.
6.
7.
8.

四、跨部门协作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'"1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

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/1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

五、专家级调试技巧（生产环境验证）

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 ECONNREFUSED1.
2.
3.
4.
5.
6.
7.
8.
9.

5.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' -vvv1.
2.
3.
4.
5.
6.
7.
8.

5.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"]
EOF1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.