<think>我们正在处理一个关于在
Kubernetes Flannel host
-gw模式下进行抓包分析的问题。根据引用[1]和[2]的内容，我们知道host
-gw模式使用路由表来实现Pod之间的通信，每个
节点上的路由表将其他
节点的Pod CIDR指向对应
节点的IP地址。
用户的问题是：在
Kubernetes中使用Flannel作为CNI并配置为host
-gw模式时，如何对Pod之间的通信进行抓包分析？
思路：
1. 在host
-gw模式下，
节点之间的通信是通过
节点上的路由表直接路由的，没有隧道封装（如VXLAN或IPIP），所以抓包时看到的是原始IP包。
2. 抓包的位置很关键，我们需要根据通信场景选择抓包点：
a. 同
节点内的Pod通信：通过cni0网桥，在cni0接口或Pod的veth接口上抓包。
b. 跨
节点Pod通信：在源
节点和目的
节点的出口
网卡（如eth0）上抓包，因为数据包是通过
节点间的网络直接传输的。
3. 由于Flannel host
-gw模式下没有隧道封装，所以抓包时看到的是原始Pod IP之间的通信。
具体步骤：
场景1：同
节点内Pod到Pod的通信
- 通信路径：Pod1
-> cni0
-> Pod2
- 抓包点：
1. 在Pod1的eth0（即veth的一端）上抓包
2. 在Pod2的eth0上抓包
3. 在cni0网桥上抓包（可以同时看到两个Pod的流量）
场景2：跨
节点Pod到Pod的通信
- 通信路径：Pod1（
节点A）
->
节点A的eth0
->
节点B的eth0
-> Pod2（
节点B）
- 抓包点：
1. 在
节点A的eth0上抓包（源IP是Pod1的IP，目的IP是Pod2的IP）
2. 在
节点B的eth0上抓包（同样可以看到Pod1到Pod2的包）
3. 注意：在
节点B上，数据包会通过路由表转发到cni0，然后到达Pod2，所以也可以在
节点B的cni0上抓包。
另外，根据引用[2]中的内容，我们还可以分析
Node到其他
Node上的Pod、Pod访问Service等场景。
抓包工具选择：
- 在
节点上使用tcpdump
- 在Pod内也可以使用tcpdump（如果Pod内有权限和工具）
具体命令示例：
1. 在
节点上抓取特定接口的包（以eth0为例）：
```bash
tcpdump
-i eth0
-nn 'net 10.244.0.0/16'
-w host
-gw.pcap
```
这里使用`net 10.244.0.0/16`来过滤Pod的IP网段（假设Flannel的Pod网段是10.244.0.0/16）。
2. 在cni0网桥上抓包：
```bash
tcpdump
-i cni0
-nn
-w cni0.pcap
```
3. 在Pod内抓包（需要进入Pod）：
```bash
kubectl exec
-it <pod
-name>
-- tcpdump
-i eth0
-nn
-w pod.pcap
```
注意：Pod内可能没有tcpdump，需要提前安装。
4. 抓取特定Pod的流量（比如源IP或目的IP是某个Pod）：
```bash
tcpdump
-i any
-nn 'host 10.244.1.10'
```
5. 分析Service流量：由于host
-gw模式下，Service的ClusterIP是通过kube
-proxy的iptables或ipvs规则转发的，所以抓包时需要注意：
- 当Pod访问Service时，在Pod的网络栈上看到的是Service的ClusterIP，但经过
节点上的iptables规则后，会被DNAT成Pod的IP。
- 在源Pod所在
节点的出口
网卡上抓包，将看到目标IP是Service ClusterIP的包（但实际在
节点间传输时已经被转换成具体Pod IP，所以抓包看到的是Pod IP）。
- 为了抓取Service的流量，可以在源Pod所在
节点上抓取cni0接口的包（此时还未做DNAT，可以看到ClusterIP），或者在目的Pod所在
节点上抓取cni0接口的包（此时已经做了DNAT，看到的是Pod IP）。
注意：在host
-gw模式下，跨
节点通信时，数据包不会经过隧道封装，所以抓包看到的就是原始Pod IP包。
总结抓包步骤：
步骤1：确定要分析的通信场景（同
节点Pod通信、跨
节点Pod通信、Pod访问Service等）
步骤2：根据通信路径选择抓包点（源Pod
节点、目的Pod
节点、中间路由设备如果有权限）
步骤3：使用tcpdump在选定的接口上抓包，并保存为pcap文件
步骤4：将pcap文件下载到本地，使用Wireshark进行详细分析
另外，由于host
-gw模式依赖路由表，在抓包前可以检查相关
节点的路由表：
```bash
ip route
```
确保有到其他
节点Pod CIDR的路由，且下一跳是对应
节点的IP。
引用[2]中详细分析了不同场景下的流量路径，我们可以参考这些场景进行抓包。
相关问题：
1. 在Flannel host
-gw模式下，如何验证
节点之间的路由是否正确？
2. 当Pod访问Service时，在哪些位置可以抓取到ClusterIP？
3. 如何分析跨
节点Pod通信中的网络延迟问题？
4. 在
Kubernetes中，如何在不进入Pod的情况下抓取Pod的流量？
5. Flannel host
-gw模式与VXLAN模式在抓包分析上有何不同？
注意：在回答中，我们引用了用户提供的引用[1]和[2]，所以在末尾添加引用标识。</think>在
Kubernetes 中使用 Flannel 的 host
-gw 模式进行抓包分析时，需要根据不同的通信场景选择抓包点。以下是详细的抓包方法和分析步骤：
### 🔧 一、抓包位置选择
在 host
-gw 模式下，不同通信场景需在不同网络接口抓包：
| **通信场景** | **抓包接口** | **关键特征** |
|
------------------------------|
---------------------|
--------------------------------------|
| 同
节点 Pod 间通信 | `cni0` 或 Pod 的 veth 接口 | 直接通过网桥转发，不经过物理
网卡 |
| 跨
节点 Pod 间通信 |
节点物理
网卡 (如 `eth0`
) | 原始 IP 包，无隧道封装[^1] |
| Pod 访问 Service ClusterIP | `cni0` 接口 | 可看到 DNAT/SNAT 转换过程 |
|
节点访问 Service ClusterIP | `cni0` + `eth0` | 涉及 kube
-proxy 规则处理 |
|
NodePort 服务外部访问 | `eth0` + `cni0` | 入口流量和 backend 选择过程 |
### 📡 二、关键抓包命令示例
#### 1. 跨
节点 Pod 通信抓包（核心场景）
```bash
# 在源
节点抓包（查看出站流量）
tcpdump
-i eth0
-nn 'src net 10.244.1.0/24 and dst net 10.244.2.0/24'
-w pod
-cross
-node.pcap
# 在目标
节点抓包（查看入站流量）
tcpdump
-i eth0
-nn 'src net 10.244.1.0/24 and dst net 10.244.2.0/24'
-w pod
-inbound.pcap
```
**分析要点**：
- 确认路由跳转：数据包应直接发送到目标
节点 IP（非隧道封装）[^1]
- 检查 TTL 变化：正常跨
节点通信 TTL 会减 1
- 验证 MAC 地址：目标 MAC 应为下一跳
节点的 MAC
#### 2. 同
节点 Pod 通信抓包
```bash
# 在 cni0 网桥抓包
tcpdump
-i cni0
-nn 'host 10.244.1.10 and host 10.244.1.20'
-w same
-node.pcap
```
**分析要点**：
- 确认无物理
网卡流量
- 检查 ARP 请求是否在本地解析
#### 3. Service 流量抓包分析
```bash
# 查看 ClusterIP DNAT 过程（在源 Pod 所在
节点）
tcpdump
-i cni0
-nn 'port 80 and
(host 10.244.1.10 or host 10.96.0.10
)'
-w service
-dnat.pcap
# 查看
NodePort 流量（在 backend
节点）
tcpdump
-i eth0
-nn 'tcp port 30080'
-w
nodeport
-inbound.pcap
```
### 🔍 三、路由表验证（host
-gw 核心）
抓包前务必检查路由表，确认 host
-gw 路由规则生效：
```bash
# 查看
节点路由表
ip route show | grep '10.244'
# 预期输出示例：
10.244.1.0/24 via 192.168.0.101 dev eth0
10.244.2.0/24 via 192.168.0.102 dev eth0
```
每个其他
节点的 Pod 子网都应有对应的 `via <
节点IP>` 路由[^1]
### 📊 四、典型问题分析
#### 1. 跨
节点通信失败
- **抓包现象**：源
节点 `eth0` 有出包，目标
节点 `eth0` 无入包
- **可能原因**：
- 节点间防火墙阻断
- 路由配置错误（`ip route` 验证）
- ARP 解析失败（检查 `arp
-an`）
#### 2. Service 访问异常
- **抓包现象**：ClusterIP 请求未 DNAT
- **检查项目**：
```bash
# 查看 kube
-proxy 规则
iptables
-t nat
-L KUBE
-SERVICES
-v
-n
```
### ⚠️ 五、注意事项
1. **权限要求**：
节点抓包需 `sudo` 权限
2. **抓包影响**：生产环境使用 `
-c 100` 限制包数量
3. **时间同步**：跨
节点抓包前用 `ntpdate` 同步时间
4. **封装检查**：host
-gw 模式**不应**出现 VXLAN 或 IPIP 封装
5. **路由跟踪**：跨
节点通信可用 `traceroute
-n <目标PodIP>` 验证路径
### 💻 六、Wireshark 分析技巧
1. 使用 `ip.dst == 10.244.0.0/16` 过滤 Pod 流量
2. 通过 **Statistics > Conversations** 分析通信矩阵
3. 使用 **TCP Stream** 重组 HTTP 等应用层协议
4. 检查 **Expert Info** 识别重传/乱序问题
```mermaid
graph LR
A[抓包需求]
--> B{通信类型}
B
-->|Pod to Pod| C{同
节点?}
C
-->|是| D[cni0接口]
C
-->|否| E[eth0接口]
B
-->|Service访问| F[cni0接口]
B
-->|
NodePort| G[eth0接口]
D
--> H[分析网桥转发]
E
--> I[验证路由跳转]
F
--> J[跟踪DNAT转换]
G
--> K[检查负载均衡]
```
### 📚 相关问题
1. 如何区分 Flannel host
-gw 模式和 VXLAN 模式的数据包特征？
2. 当跨
节点 Pod 通信失败时，如何结合路由表和抓包结果进行诊断？
3. 在 Service 访问场景中，如何通过抓包验证 kube
-proxy 的 iptables 规则是否生效？
4. 为什么 host
-gw 模式在公有云环境中可能受限？如何解决？
5. 如何捕获和分析
Kubernetes 中的 DNS 查询流量？
[^1]: Flannel host
-gw 模式路由机制
[^2]:
Kubernetes 网络流量分析实践
本文讲述了在重启挂起的Node.js节点后，遇到ens33网卡丢失的问题，通过关闭NetworkManager服务并重启网络配置，成功解决了问题，恢复了网卡。
最低0.47元/天 解锁文章
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
