conntrack 表打满后新连接全被丢：K8s iptables 集群里一次「服务还活着但谁都连不上」的排障复盘

结论先行：K8s 上有一类故障长得很像「服务挂了」，其实服务、Pod、Service 全活，只是节点的内核连接跟踪表（conntrack）满了——新连接被内核直接丢弃，已建连的长连接还能跑。它的特点是按节点分布、只影响新建连接、kubectl 侧一切正常。这篇文章把现象、内核机制、定位命令和容量参数一次讲透。

一、现象与背景：Pod 全 Running，但业务全超时

事故发生在一条 K8s 1.28.4 / containerd 1.6.20 的自建集群，16 台 worker（16C32G），kube-proxy 跑在默认 iptables 模式。一个对外的网关服务（约 3000 QPS，客户端约 4000 个独立来源 IP）在某个周四下午 14:02 开始告警：

• 客户端侧：新发起的请求全部 30s 超时（客户端超时配置），已持有的 HTTP/2 长连接上的请求正常返回 200；
• 服务端侧：kubectl get pods 全 Running、ready，服务日志没有任何报错，本机 ss -s 显示 ESTAB 连接数正常；
• 网络侧：tcpdump 在节点上抓包，看到客户端的 SYN 包确实到达了节点，但没有 SYN-ACK 出去——包进来了，内核没回；
• 最迷惑的一点：重启 Pod 没用，把流量切到集群外另一台机器立刻恢复——问题在「节点」不在「Pod」。

14:02 到 14:31 共 29 分钟，累计失败新建连接约 4 万次，期间没有任何 OOM、没有任何 Pod 重启。这类故障在 kubectl 的世界里是「不可见」的：kubelet、kube-proxy、CNI 都没事，坏的是更底层的 netfilter。

二、根因：conntrack 是怎么「顺手」吃掉新连接的

先讲机制，否则后面的参数都是玄学。

Linux 为了支持 NAT，用 conntrack 表跟踪每条连接的元组（五元组 + 协议状态）。kube-proxy iptables 模式依赖这个机制做 SNAT（MASQUERADE）：Pod 访问 ClusterIP 时，源地址被改写，回包要靠 conntrack 里的条目才能还原回 Pod IP。所以 K8s 节点上 conntrack 几乎是「每条流经节点的网络流都要登记」。

表的容量由 net.netfilter.nf_conntrack_max 决定（默认 65536，很多发行版内核默认值）。表满时的行为是静默丢包 + 打内核日志：

• 新建连接：SYN 进来，插入新条目失败 → 包被 drop，不回 RST，客户端只能等超时（这就是「全超时」而不是「连接被拒绝」的原因）；
• 已建连：条目还在表里，状态机正常推进 → 长连接不受影响；
• 内核日志出现 nf_conntrack: table full, dropping packet（rate-limited，dmesg | grep conntrack 能看到）。

这次事故的触发链：上游一个定时任务从 14:00 开始把一批短连接（每次请求新建 TCP、用完即关）打到网关，来源 IP 分散在约 3800 个，每秒新建连接约 1200 条；而 conntrack 每条连接的条目要等连接真正终结（FIN/RST）后才开始 30s 左右的 TIME_WAIT 跟踪期（nf_conntrack_tcp_timeout_time_wait 默认 120s，实际按状态递减）。表从 13:58 的 61% 一路涨到 14:02 的 100%，之后 29 分钟里表一直贴着上限——新建连接全丢，短连接任务自己「连不上、不占条目」，反而把表里的僵尸条目占满了，形成死锁式的雪崩。

三、具体做法：定位四连 + 参数调优 + 长期方案

1）四步定位（这套顺序可以复用）

# ① 看当前水位：used / max
conntrack -S
# entries: 65536/65536  drop: 128431   ← used 顶满 + drop 非零，基本实锤

# ② 看内核是否记了账
dmesg -T | grep -i conntrack | tail
# nf_conntrack: table full, dropping packet

# ③ 看是谁在占条目（按源 IP 聚合，找短连接大户）
conntrack -L | awk '{print $6}' | sort | uniq -c | sort -rn | head

# ④ 看新建速率是否异常
watch -n1 "conntrack -S"   # 观察 insert / drop 的增速

2）应急：先抬上限止血（治标）

# 当前表上限
sysctl net.netfilter.nf_conntrack_max
# 临时调到 262144（16C 节点，conntrack 条目内存开销约 300B/条，
# 262144 × 300B ≈ 75MB，完全可承受）
sysctl -w net.netfilter.nf_conntrack_max=262144
# 同时确认 hashsize 有足够分片（经验值 max/8 起步）
sysctl -w net.netfilter.nf_conntrack_buckets=32768

写进 /etc/sysctl.d/99-conntrack.conf 持久化。注意：抬上限只买时间，不解决「条目不释放」的根因，短连接风暴再来还会满。

3）根因处理：把短连接改长连接 + 按状态调超时

# 对确实无法改长连接的上游，缩短各类超时的条目驻留时间
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30   # 默认 120
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close=10       # 默认 10
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600 # 默认 432000，
# 我们网关有长连接，保持宽松；纯短连接服务可激进调小

真正解掉这次事故的是业务侧：把那个定时任务从「每请求新建 TCP」改成 HTTP keep-alive 连接池（客户端连接池上限 64、单连接复用），新建连接速率从 1200/s 降到接近 0，表水位从 100% 回落到 40% 以下，之后一周没有再满过。

4）长期：把 conntrack 纳入容量监控

# 用 node_exporter 的 node_nf_conntrack_entries / node_nf_conntrack_entries_limit
# 告警规则（PromQL）：
#   node_nf_conntrack_entries / node_nf_conntrack_entries_limit > 0.8 持续 2m
# 这次事故 13:58 水位 61%、14:00 达 88%——有这条告警，14:00 就该介入而不是 14:02 等业务超时

如果集群里新建连接速率长期 >500/s，认真评估把 kube-proxy 切到 ipvs 模式：IPVS 路径对 conntrack 的依赖更轻，且对高并发 Service 的性能开销更低（官方 benchmark 里同规模下 iptables 的 iptables 规则数随 Service×Endpoint 线性膨胀，ipvs 是 O(1) 查表）。

四、踩过的坑与反直觉之处

1. 「服务活着」和「能被连上」是两件事。这次 29 分钟里 CPU、内存、Pod 状态全绿，如果只盯 Pod 指标会一直查错方向。判断口诀：SYN 到了节点但不回 SYN-ACK + 长连接正常 + 新连接全超时 = 先查 conntrack。
2. conntrack 满不会报「拒绝」，只会静默丢。因为内核选择 drop 而不是回 RST，客户端表现为超时（我们侧 30s），这让它看起来像「网络抖动」或「服务端慢」，极易误诊到应用层。
3. 短连接是 conntrack 的头号杀手，而且会自我强化：连接建不上 → 重试 → 更多半开条目 → 表更满。事故期间上游重试逻辑把压力放大了一倍，表满时加重试等于往火上浇油。
4. conntrack -S 的 drop 字段会随表满持续增长，但很多机器上 dmesg 被 rate-limit 成几行日志，用 dmesg 判断「满没满」会漏判，以 conntrack -S 的 drop 计数和 used/max 水位为准。
5. 抬 nf_conntrack_max 不是免费午餐：条目越多，hash 查找和内存开销越大，且它只是把「满」推迟。我们调到 262144 后水位长期 40% 以下才敢停手，调之前先算过内存账（约 75MB）。
6. TIME_WAIT 类条目是「隐形占位」：连接已经对业务无意义，但内核还要跟踪 30~120s 才释放。评估容量时不能只看「当前活跃连接数」，要按「新建速率 × 平均驻留时间」估算稳态条目数——这次估算值 1200/s × 约 45s ≈ 5.4 万，恰好把 6.5 万的默认表顶满。

五、结论与可复用清单

conntrack 是 K8s iptables 集群里最容易被忽略的内核层瓶颈：它按节点分布、只杀新建连接、kubectl 世界完全不可见。可复用清单：

• [ ] 定位四连：conntrack -S（used/max/drop）→ dmesg | grep conntrack → conntrack -L 按源 IP 聚合 → 观察 insert/drop 增速；
• [ ] 指纹识别：SYN 到达但无 SYN-ACK + 长连接正常 + 新连接全超时 + 重启 Pod 无效 = 优先查 conntrack；
• [ ] 应急抬 net.netfilter.nf_conntrack_max（先算内存账：条数 × 约 300B），nf_conntrack_buckets 给 max/8 起步；
• [ ] 根因永远是「短连接 + 高频新建」：能改 keep-alive 连接池就改，改不了再调 nf_conntrack_tcp_timeout_time_wait 等状态超时；
• [ ] 容量公式：稳态条目数 ≈ 新建连接速率 × 平均条目驻留时间，用它反推 max 该给多少；
• [ ] 上 node_nf_conntrack_entries / limit > 0.8 的 Prometheus 告警，别等业务超时才发现；
• [ ] 高并发 Service（新建速率长期 >500/s）的集群，评估 kube-proxy 切 ipvs 模式；
• [ ] 表满期间不要加重试，先止血（抬上限/切流）再查源头。

这次事故从 14:02 告警到 14:31 恢复，29 分钟里我们走了弯路：先怀疑网关应用、再怀疑 CNI，最后才是 conntrack -S 一行命令实锤。如果那套「四连定位」和容量公式当时就在手边，14:00 水位告警时介入，业务损失能少 20 分钟。