一、问题现场：当限速配置突然"失灵"
去年我们团队在部署AI训练平台时，发现某个Docker容器明明配置了10Mbps的带宽限制，实际测试却飙到了100Mbps。就像给水管装了个虚设的阀门，水流丝毫不受影响。经过三天排查，最终发现是内核模块缺失导致的。这个经历让我意识到，Docker网络限速失效可能隐藏着多个"陷阱"。
二、技术栈选择：为什么用tc而不是iptables？
我们选用Linux原生流量控制工具tc（Traffic Control）作为示例技术栈。相较于iptables的标记+限速方案，tc可以直接在虚拟网卡上实现精细化的流量整形，更适合容器场景。
示例1：基础限速配置
# 创建容器时设置带宽限制（Ubuntu 20.04 + Docker 23.0）
docker run -itd --name test_container \
--network bridge \
--sysctl net.core.somaxconn=1024 \
--ulimit nofile=1024:1024 \
alpine sh
# 在宿主机配置tc规则（限制容器veth网卡的上行带宽）
tc qdisc add dev veth1234 root tbf rate 10mbit burst 32kbit latency 400ms
注：veth1234需要替换为实际的veth网卡名称，可通过ip link命令查看
三、五大常见失效场景及解决方案
3.1 幽灵规则：tc配置被意外覆盖
现象：重启容器后限速失效，但配置脚本明确执行了tc命令
排查步骤：
# 查看指定网卡的队列规则（关键在是否有幸存规则）
tc -s qdisc show dev veth1234 | grep -A 3 tbf
# 预期输出应包含：
# qdisc tbf 8001: root refcnt 2 rate 10Mbit burst 16Kb lat 560.0ms
注：若输出为空或显示pfifo_fast，说明规则未被正确应用
解决方案：
使用tc qdisc replace代替tc qdisc add，避免规则冲突：
tc qdisc replace dev veth1234 root tbf rate 10mbit burst 32kbit latency 400ms
3.2 Cgroup的"叛变"：双重限制的陷阱
现象：同时使用cgroup和tc限速时，实际带宽低于预期值
技术原理：
Docker默认通过net_cls cgroup实现带宽限制，当与tc混用时会产生叠加效果。就像两个串联的水阀，总流量由更严格的限制决定。
优化方案： 在docker daemon.json中禁用cgroup限速：
{
"exec-opts": ["cgroupdriver=systemd"],
"bip": "172.17.0.1/24",
"default-ulimits": {
"net_prio": "-1"
}
}
3.3 网卡迷局：选错战场全盘皆输
典型错误：在错误的网络命名空间执行tc命令
排查示例：
# 错误做法：在宿主机直接操作veth网卡
tc qdisc add dev veth1234 root tbf rate 10mbit
# 正确做法：进入容器的网络命名空间
nsenter --net=/proc/$(docker inspect -f '{{.State.Pid}}' test_container)/ns/net \
tc qdisc add dev eth0 root tbf rate 10mbit
注：eth0是容器内的主网卡，需在容器的网络命名空间操作
3.4 内核模块的"消失"
隐蔽问题：缺少sch_tbf模块导致规则失效
诊断命令：
# 检查内核是否加载TBF模块
lsmod | grep sch_tbf
# 若输出为空，需要手动加载
modprobe sch_tbf
持久化方案： 在/etc/modules-load.d/tbf.conf文件中添加：
sch_tbf
3.5 时间粒度的暗战
异常现象：突发流量突破限制阈值
参数调优：
tc qdisc add dev veth1234 root tbf \
rate 10mbit \
burst 15kb \
latency 50ms \
peakrate 12mbit \
minburst 1500
burst值建议为rate/8，latency不要超过500ms
四、技术方案选型指南
4.1 适用场景分析
- 开发测试环境：适合使用tc直接配置，快速验证
- 生产环境：推荐结合Kubernetes NetworkPolicies
- 混合云部署：考虑Calico的带宽管理插件
4.2 方案优缺点对比
| 方案 | 优点 | 缺点 |
|---|---|---|
| tc原生方案 | 细粒度控制，支持复杂流量整形 | 配置复杂，依赖内核版本 |
| cgroups | Docker原生支持，配置简单 | 仅支持简单限速，无法处理突发流量 |
| 第三方插件 | 提供可视化界面，支持动态调整 | 引入额外组件，增加运维复杂度 |
五、避坑指南：六个必须检查的清单
- 确认内核版本 >=4.9（旧版本有TC BUG）
- 检查ifb虚拟网卡是否启用（用于入口流量限制）
- 避免在Swarm模式下使用--ulimit参数
- 定期运行
tc -s qdisc查看计数器 - 注意docker-compose的network参数覆盖
- 测试时使用iperf3的--reverse参数模拟真实流量
六、总结：限速不是目的而是手段
排查Docker网络限速失效的过程，就像在迷宫中寻找隐藏的机关。通过本文的五步排查法，我们不仅能解决当前问题，更能深入理解Linux网络栈的工作机制。记住，有效的带宽限制应该是动态的、可观测的、有弹性的。下次当你的容器开始"飙车"时，不妨按照这个路线图开启你的排查之旅。