1. 为什么需要限制Docker容器带宽

在微服务架构和容器化部署越来越普及的今天，我们经常会在同一台宿主机上运行多个Docker容器。想象一下这样的场景：某个容器突然开始疯狂下载更新包，或者某个服务出现异常导致网络流量暴增，结果就是整个宿主机的网络带宽被占满，其他容器的网络请求全部卡死。这就像是在一条高速公路上，突然有几辆大卡车占满了所有车道，其他车辆只能干等着。

我去年就遇到过这样的情况：一个日志收集容器因为配置错误，开始疯狂上传日志文件，直接把生产环境的带宽打满，导致整个系统响应变慢。从那以后，我就养成了给关键容器设置带宽限制的习惯。

Docker本身提供了CPU和内存的限制功能，但奇怪的是，它并没有内置网络带宽限制的能力。这时候就需要请出Linux系统的**tc(Traffic Control)**工具了。tc是Linux内核提供的流量控制工具，它可以对网络接口的流量进行精细化管理，包括限制带宽、设置优先级、模拟网络延迟等。

2. tc工具基础入门

2.1 tc的工作原理

tc的工作原理有点像自来水厂的水压控制。它通过**队列规则(qdisc)**来管理网络数据包的发送。常见的队列规则有：

• TBF(Token Bucket Filter)：令牌桶算法，适合精确控制带宽
• HTB(Hierarchy Token Bucket)：分层令牌桶，可以设置带宽层级
• SFQ(Stochastic Fairness Queueing)：随机公平队列，防止单个连接独占带宽

这里我们主要使用TBF，因为它配置简单，效果直接。TBF的工作原理是：系统按照设定的速率生成令牌，数据包发送前必须获取令牌，没有令牌的数据包就要排队等待。

2.2 基本tc命令

先看一个最简单的限速命令：

# 将eth0网卡的上传带宽限制为1Mbps
tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

这个命令包含几个关键参数：

• rate：限制的带宽速率，可以用mbit(兆比特)或kbit(千比特)为单位
• burst：突发流量的大小，建议设置为rate的1/10到1/5
• latency：数据包最大延迟时间

要查看当前的限速规则：

tc qdisc show dev eth0

删除限速规则：

tc qdisc del dev eth0 root

3. 为Docker容器配置带宽限制

3.1 直接进入容器配置

最简单的方法是直接进入容器内部配置tc规则。首先需要确保容器内安装了iproute2工具包（包含tc命令）：

docker exec -it 容器名 /bin/bash
apt-get update && apt-get install -y iproute2  # Ubuntu/Alpine用apk add iproute2

然后在容器内执行tc限速命令。但这种方法有个明显缺点：容器重启后规则就丢失了。

3.2 使用tc-docker工具

更优雅的方案是使用专门的tc-docker工具。这是一个预配置好的Docker镜像，可以自动为其他容器设置带宽限制。

首先启动tc-docker服务容器：

docker run -d \
  --name tc-docker \
  --network host \
  --privileged \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /var/run/docker/netns:/var/run/docker/netns:shared \
  codyguo/tc-docker

然后启动需要限速的业务容器时，通过label指定限速参数：

docker run -it \
  --label "org.label-schema.tc.enabled=1" \
  --label "org.label-schema.tc.rate=1mbps" \
  --label "org.label-schema.tc.ceil=10mbps" \
  ubuntu sh -c "apt-get update && apt-get install -y iperf && iperf -s"

这里有几个关键label：

• tc.enabled：设为1启用限速
• tc.rate：保证的最小带宽
• tc.ceil：最大可用带宽

3.3 手动通过容器网络命名空间配置

如果想更精细控制，可以手动操作容器的网络命名空间。每个Docker容器都有自己的网络命名空间，我们可以通过容器的PID找到对应的网络接口。

首先获取容器PID：

docker inspect -f '{{.State.Pid}}' 容器名

然后进入容器的网络命名空间配置tc：

nsenter -t 容器PID -n tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms

这种方法适合需要动态调整限速规则的场景。

4. 测试限速效果

配置完限速后，我们需要验证是否生效。常用的网络测试工具有：

4.1 使用iperf测试

iperf是专业的网络性能测试工具。在一台机器上启动服务端：

iperf -s

在另一台机器或容器中运行客户端测试：

iperf -c 服务器IP -i 1 -n 100M

如果限速1Mbps，测试结果应该接近：

[ ID] Interval       Transfer     Bandwidth
[  3] 0.0-100.0 sec  12.5 MBytes  1.05 Mbits/sec

4.2 使用speedtest-cli

对于外网带宽测试，可以使用speedtest-cli：

apt-get install -y speedtest-cli
speedtest

4.3 实际文件传输测试

最直观的还是实际文件传输测试。可以用curl测试下载速度：

curl -o /dev/null http://example.com/largefile

或者用wget：

wget -O /dev/null http://example.com/largefile

5. 常见问题与解决方案

5.1 限速不生效的可能原因

1. 容器没有NET_ADMIN权限：启动容器时需要添加--cap-add=NET_ADMIN
2. tc命令不存在：容器内需要安装iproute2包
3. 网卡名称不对：有些容器内网卡不是eth0，需要用ip addr查看实际名称
4. 规则被覆盖：检查是否有其他进程修改了tc规则

5.2 动态调整限速

如果需要临时调整限速，可以这样修改现有规则：

tc qdisc change dev eth0 root tbf rate 2mbit burst 64kbit latency 400ms

5.3 限制特定端口的带宽

如果想只限制某个端口的流量，可以结合iptables和tc的filter：

# 标记80端口的流量
iptables -A OUTPUT -t mangle -p tcp --dport 80 -j MARK --set-mark 1

# 对标记的流量限速
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

5.4 多容器公平带宽分配

当需要为多个容器分配公平带宽时，可以使用HTB队列：

tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30mbit ceil 100mbit
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 70mbit ceil 100mbit

6. 生产环境最佳实践

在实际生产环境中使用tc限速时，我有几点经验分享：

1. 设置合理的突发值：burst值太小会导致带宽利用率低，太大会导致延迟波动。我一般设置为rate的1/5左右。

2. 监控带宽使用：配合监控工具如Prometheus+Granfa，实时查看带宽使用情况。可以配置alertmanager在带宽接近上限时告警。

3. 重要服务预留带宽：使用HTB为关键服务预留带宽，确保即使在高负载时也能保证基本服务质量。

4. 容器重启处理：通过init容器或启动脚本自动重新应用tc规则，避免容器重启后限速失效。

5. 文档记录：详细记录每个容器的带宽限制值，方便后续容量规划和问题排查。

7. 其他替代方案

除了tc，还有其他几种容器限速方案：

1. cgroup v2带宽控制：Linux 4.15+内核支持通过cgroup直接限制网络带宽，但目前功能还比较基础。

2. Open vSwitch QoS：如果使用OVS作为容器网络，可以利用其内置的QoS功能。

3. CNI插件：一些CNI网络插件如Calico、Cilium提供了带宽限制功能。

但综合来看，tc仍然是目前最灵活、最可靠的方案，特别是在需要精细控制带宽的场景下。