闯关预计 30 分钟
闯关：Pod 之间不通
同一个 Service 有些副本能访问、有些不行。在模拟终端里一层层剥开。
学完这节你能做到
- 按 Pod → 节点 → CNI → Service → 策略的顺序收敛问题
- 区分 DNS 失败、策略拦截、路由缺失三类症状
- 定位到具体节点或具体规则，而不是停在"网络不通"
建议先学
跳过这几节会看不懂本节的部分推导
接手
业务群里在吵：
前端调后端
api三次里有两次超时，重试能成功。今天上午还是好的，我们没发版。
已知信息：
frontend有 1 个副本，跑在k8s-work-101api有 3 个副本，分别在k8s-work-101、102、103- 集群用 Cilium，VXLAN overlay 模式
- 运维说今天上午安全团队批量下发过一批主机加固规则
✓怎么玩
按 L1 的排障顺序来：DNS → Endpoint → 连通性 → 隧道 → 策略。
输入 goals 看目标，hint 要提示。四个目标全达成即过关。
"三次里两次失败"这个比例本身就是线索 —— 先想想它意味着什么。
- 1.确认 Endpoint 里有几个就绪的后端
- 2.分别直连三个 Pod IP，确认失败是否与节点相关
- 3.排除 NetworkPolicy：看数据平面有没有策略拒绝事件
- 4.确认封装后的隧道流量到底走到哪一步
- 5.找出根因：谁把隧道流量丢了
frontend 调 api 三次里有两次超时，未发版。 api 有 3 个副本分布在 101 / 102 / 103 三台节点上。
[root@k8s-work-101 ~]#
结论应该长什么样
| 证据 | 排除 / 确认了什么 |
|---|---|
nslookup api 正常 | 排除 DNS |
| Endpoint 里有 3 个后端 | 排除就绪探针与应用侧 |
| 直连三个 Pod IP：同节点通、跨节点全超时 | "间歇性"是假象，真相是跨节点不通 |
cilium-dbg monitor --type drop 无事件 | 排除 NetworkPolicy（包没走到策略判定） |
| Cilium Pod 健康、路由存在、MTU 1450 正确 | 排除 CNI 自身与 MTU 配置 |
| 抓包：本机在发 UDP 8472，无任何回包 | 确认封装流量出得去、回不来 |
iptables -nvL INPUT 有 DROP udp，计数在涨 | 根因：主机加固规则丢弃了 VXLAN 隧道流量 |
根因：安全团队批量下发的加固规则里有一条"丢弃所有 UDP"，
而 Cilium 的 VXLAN overlay 走 UDP 8472。三台节点都被下发了这条规则，
于是所有跨节点的 Pod 流量在对端 INPUT 链上被丢弃。同节点通信不出物理网卡，所以不受影响。
修法：在 DROP 之前放通隧道端口。
# 立刻恢复（临时）
iptables -I INPUT 1 -p udp --dport 8472 -s 10.0.12.0/24 -j ACCEPT \
-m comment --comment "cilium vxlan"
# 验证：跨节点应该立刻通
kubectl exec frontend-7d9c4b8f6-x2klm -- curl -m 3 -sS 10.244.2.9:8080/health
# 持久化交给加固规则的下发渠道，别只改运行时!主机加固与 CNI 的端口清单
这类事故的根本预防是把 CNI 需要的端口写进加固规则的白名单。常见的几个：
| 端口 | 用途 |
|---|---|
| UDP 8472 | VXLAN（Cilium / Flannel 默认） |
| UDP 6081 | Geneve |
| UDP 4789 | VXLAN（部分实现用标准端口） |
| TCP 4240 | Cilium 健康检查 |
| UDP 51871 | Cilium WireGuard 加密 |
| IP 协议 4 | IP-in-IP（Calico 的一种模式） |
改主机防火墙前先问一句"CNI 用什么封装"。原生路由模式没有隧道端口， 但需要放通 Pod CIDR 的转发——同样不能一刀切。
×「间歇性」几乎总是「某个维度上的确定性」
这一关最重要的方法论：遇到"三次里两次失败"，先把它变成确定性问题。
做法是绕开负载均衡、逐个直连后端。这次的比例是 1/3 成功、3 个后端 1 个同节点—— 一算就对上了。同类比例的含义：
| 成功比例 | 通常意味着 |
|---|---|
| 1/N（N = 后端数） | 只有一个后端可用，且往往与节点相关 |
| 约一半 | 双活的一侧有问题（两台 LB、两个可用区、双上行链路） |
| 完全随机、比例不固定 | conntrack 表满、连接数上限这类资源型问题 |
先看比例、再算它等于什么，比反复重试快得多。
检查点
Service 有 3 个后端，访问成功率稳定在三分之一。第一步该做什么？
cilium-dbg monitor --type drop 一条事件都没有，但跨节点确实不通。说明什么？
改主机防火墙规则前，为什么必须先确认 CNI 的封装方式？
这一关的落点
- 排障顺序：DNS → Endpoint → 逐个直连 → 数据平面 drop → 隧道抓包 → 主机防火墙
- "间歇性"几乎总是某个维度上的确定性：先看成功比例，再算它等于什么
- 1/N 成功率 = 只有一个后端可用；约一半 = 双活的一侧坏了；完全随机 = 资源型问题
- 绕开 Service 直连 Pod IP，是把间歇性变确定性最快的一招
drop事件为空是排除性证据：包没走到策略判定，要往更早的位置查- overlay 的跨节点流量在物理网卡上是 UDP 8472（Geneve 是 6081），抓它能定位到"发出去了但没回来"
- 主机加固规则必须给 CNI 端口留白名单，改防火墙前先问清封装方式
- 同节点通、跨节点不通 = 问题一定在物理网络这一段（隧道、防火墙、路由），不在 Pod 里