conntrack 与 Service 转发
kube-proxy 在 iptables/IPVS 模式下依赖内核连接跟踪表（conntrack）记录「客户端到 Service 虚拟 IP」与「真实 Pod」的映射：连接建立时写入表项，后续数据包按表项直接转发，不必逐包重算规则。表项数量受 nf_conntrack_max 限制，连接多、回收慢时会被写满，内核开始丢包并打印 nf_conntrack: table full, dropping packet，外部表现就是间歇性连接超时。
基本信息
| 适用平台 | Linux 节点，kube-proxy 的 iptables/IPVS 模式 |
|---|---|
| 关键参数 | net.netfilter.nf_conntrack_max（上限）、nf_conntrack_count（当前用量） |
| 查看方式 | sysctl、/proc/sys/net/netfilter/ 目录、conntrack 工具 |
| 调整方式 | 节点侧写入 /etc/sysctl.d/ 下的配置文件后 sysctl --system |
| 关联超时 | nf_conntrack_tcp_timeout_established 决定空闲连接占用表项多久 |
典型使用场景
- 大流量节点出现无规律超时、偶发丢包，需要在节点侧确认会话表是否写满
- 短连接高并发业务：探针、健康检查、短请求频繁建连，表项创建回收压力大
- 长连接服务做容量评估：数据库代理、消息队列客户端长期占用表项
- 节点扩容前后对比会话表用量，区分业务真实增长与连接泄漏
- 排查内核丢包类故障时，把 conntrack 与网卡、整流规则一起对照
检查会话表
检查会话表
sysctl net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_count # 上限与当前用量
cat /proc/sys/net/netfilter/nf_conntrack_count # 未装工具时的替代读法
conntrack -C # 统计表项总数（需 conntrack-tools）
dmesg | grep -i conntrack | tail # 查是否有表满丢包记录
ss -s | head -3 # 从套接字角度交叉核对连接规模调整示例（节点上执行）
调整示例（节点上执行）
sysctl -w net.netfilter.nf_conntrack_max=262144 # 临时调整，重启失效
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400 # 让空闲长连接更快回收
# 持久化写入 /etc/sysctl.d/99-k8s-conntrack.conf 后执行 sysctl --system参数读法
| 参数 | 含义 | 异常信号 |
|---|---|---|
| nf_conntrack_count | 当前表项数 | 长期贴近上限说明随时会丢包 |
| nf_conntrack_max | 表项数量上限 | 默认值随节点内存推算，与业务峰值无关 |
| nf_conntrack_tcp_timeout_established | 空闲已建立连接的保活时长 | 过长会让空闲连接长期占表 |
| nf_conntrack_buckets | 哈希桶数量 | 桶过少时查找变慢，转发延迟上升 |
调大上限要按节点内存评估：每条表项占用的内存不可忽略，盲目调到百万级会挤占业务内存并拖慢哈希查找，应先按实测连接峰值留出余量。
kube-proxy 的 nftables 模式与 IPVS 模式对 conntrack 的依赖程度不同，排查前先看 kubectl -n kube-system get cm kube-proxy -o yaml 确认当前模式与配置来源。