容器网络带宽限速的突发余量，本质是令牌桶算法里允许短时超发的“备用令牌”，设置过小会直接压垮TCP连接速度，设置过大则限速几乎失效。
下面从tc命令、Docker单机、Kubernetes集群和云服务器四个场景拆解这个参数，多数性能问题不是rate给得不够,而是burst配错了。
容器网络带宽限速怎么设置：先理解rate和burst的关系
容器网络限速通常发生在宿主机veth接口上，Linux内核的tc（traffic control）工具配合tbf队列规则，可以同时控制平均速率和突发余量，tbf全称是Token Bucket Filter,令牌桶Filter。
tc命令下的令牌桶参数
一条典型的限速命令长这样：
tc qdisc add dev veth1234 root tbf rate 1mbit burst 32kbit latency 400ms三个参数各管一摊：
- rate：长期平均带宽，也就是用户常说的“限速多少”
- burst：桶的容量，决定短时间内最多能发出多少数据
- latency：包在队列里允许等待的最大时间
burst不是独立存在的，它和rate共同决定令牌桶的深度，桶里没令牌时，包就要排队；排队超过latency，包就被丢弃，所以burst太小,连TCP握手后的第一个数据窗口都发不完整。
定位容器veth接口的实操步骤
Docker容器没有直接的“限速”启动参数,要先找到容器在宿主机侧对应的veth接口。
第一步,获取容器进程PID：
docker inspect -f '{{.State.Pid}}' 容器名第二步,进入容器网络命名空间查看接口：
nsenter -t PID -n ip link第三步，回到宿主机,用容器IP反查veth：
ip link | grep veth匹配到接口后,执行限速：
tc qdisc add dev vethXXXX root tbf rate 10mbit burst 100kbit latency 50ms验证配置是否生效：
tc -s qdisc show dev vethXXXX输出里的drop计数和backlog会直接反映burst是否够用，drop增长快,就是桶太浅。
Docker容器限速和突发余量区别在哪
Docker容器限速和突发余量区别,要从作用位置和理解方式两层去看。
限速位置不在容器内部
Docker容器的网络接口是veth对，一端在容器里，一端在宿主机，tc命令只能加在宿主机那一端，容器内部执行ethtool或tc往往看不到宿主机施加的限速规则,也不具备直接调整能力。
对比虚拟机限速，云平台在hypervisor层直接限制网卡，burst通常由平台预设，用户能调的幅度有限，Docker单机则刚好相反：burst完全由手工指定,灵活但更容易配错。
限速和突发余量不是一回事
限速回答“平均能跑多快”，突发余量回答“短时间能冲多高”，实际流量不是匀速的，TCP慢启动、TLS握手、HTTP大请求都会产生突发，burst太小,平均速率再高也用不上。
可以用一个具体场景理解：限速10Mbit/s，burst只有10kbit，TCP初始拥塞窗口约15KB，也就是约120kbit，第一个窗口直接超出桶容量，大量包被丢弃，连接速度可能只有2-3Mbit/s，rate没变,体验已经崩了。
Kubernetes Pod带宽限制突发流量配置
Kubernetes Pod带宽限制突发流量，官方提供了两个注解,但实际支持情况取决于CNI插件。
注解方式与CNI支持
对Pod施加带宽限制可以使用：
kubectl annotate pod nginx-test
kubernetes.io/ingress-bandwidth=2M
kubernetes.io/egress-bandwidth=2M注解值支持M、Mi、G等单位，CNI插件读取注解后，在Pod对应的veth上生成tc tbf规则，据Kubernetes官方文档,这些注解只对声明支持带宽管理能力的CNI生效。
Calico与Cilium的突发余量差异
- Calico：支持ingress和egress带宽注解，底层使用tc tbf，burst值通常由插件按固定逻辑计算，用户无法直接指定，对于冷启动明显的业务,默认burst往往偏小。
- Cilium：基于eBPF实现带宽管理，粒度更细，但需要较新内核版本,部分版本允许通过配置调整突发缓冲。
- Flannel：本身不处理带宽限制,需要额外叠加工具或手工对veth操作。
如果Pod跑的是大文件传输或音视频推流，建议先确认CNI是否暴露burst参数，不支持时，可以绕过注解，直接在宿主机对Pod的veth手工执行tc命令,临时调大burst验证效果。
验证Pod限速是否生效
kubectl exec nginx-test -- cat /sys/class/net/eth0/iflink拿到iflink号后，在宿主机上匹配veth接口,再执行：
tc -s qdisc show dev vethXXXX观察drop计数和实际速率，Pod内用iperf3打流，前1-2秒峰值应该高于平均速率,否则burst没有发挥作用。
容器网络限速突发余量多少合适
容器网络限速突发余量多少合适，没有统一答案,但可以按TCP行为估算。
从TCP拥塞窗口估算
Linux内核默认初始拥塞窗口通常为10个MSS，以MTU 1500、MSS约1460字节计算，10个MSS约15KB，也就是说，哪怕限速1Mbit/s,burst也不应低于15KB。
这只是底线，真实业务还要考虑RTT和重传，业内专家指出，生产环境建议把burst设置成rate的1到2秒流量,再结合RTT和drop计数微调。
不同场景的参考思路
| 场景 | rate设置思路 | burst参考思路 |
|---|---|---|
| 普通API容器 | 按历史流量均值 | 取1秒流量 |
| 大文件传输 | 按带宽成本上限 | 取5秒以上流量 |
| 实时音视频 | 按单路码率 | 取0.5秒流量 |
“取几秒流量”的意思是：burst = rate × 秒数，例如rate为10Mbit/s，burst取1秒流量就是10Mbit，即约1.25MB。
验证突发余量是否生效
先不加限速，用iperf3跑基线。
加限速后，再跑同样测试,观察前2秒速率是否明显高于rate。
查看tc -s qdisc show dev vethXXXX，drop计数如果大幅增长,说明burst偏小。
抓包看TCP重传，重传率高且集中在连接建立初期,基本可以确认burst不足。
云服务器容器限速价格与地域选择
云服务器容器限速价格，不在限速功能本身，而在带宽计费方式，容器内的tc限速是软限制，云实例的物理带宽是硬限制,两者叠加时实际突发余量取更小的那个值。
带宽计费方式影响突发余量配置
固定带宽实例通常允许一定程度的短时突发，按流量计费实例则更容易在峰值时丢包，包年包月固定带宽的成本更可控，适合需要稳定burst的业务，按量流量计费灵活,但突发流量可能带来额外费用。
具体价格因地域和计费周期差异较大，不同云厂商策略也不同，选择固定带宽还是按流量,需要先评估业务流量波动。
地域与网络质量对burst的实际影响
以华东1（杭州）和华北2（北京）为例，跨地域公网流量通常比同地域延迟更高，RTT从同地域的几毫秒增加到几十毫秒，burst必须跟着调大,否则TCP拥塞窗口增长会被频繁打断。
- 同地域：RTT较小,burst取1秒流量通常够用。
- 跨地域：RTT较大，burst建议按RTT × rate再乘2到3倍。
- 跨境链路：丢包和抖动明显，burst设置过大反而加剧拥塞，需要配合TCP BBR使用。
云厂商的实例带宽上限是硬限制，容器内tc配置的burst再大，也不能超过实例物理带宽，限速被云平台二次限速时,优先优化容器与云实例的带宽匹配。
容器网络带宽限速突发余量常见问题
容器网络限速突发余量设置太小会怎样？
会出现TCP连接建立慢、大请求超时、吞吐量远低于rate，令牌桶很快见底，发送方进入重传等待，拥塞窗口难以增长，解决办法是逐步调大burst，观察tc -s中的drop计数变化，drop计数停止增长或增长缓慢,说明burst已经够用。
Docker容器限速和突发余量区别是什么？
Docker容器限速是对veth接口施加的发送速率限制，突发余量是同一个tc tbf规则里的桶深参数，前者回答“平均能跑多快”，后者回答“短时间能冲多高”，实际配置中，限速可以独立存在，但如果突发余量为0或极小,限速效果会表现为频繁丢包而不是平滑降速。
容器网络限速怎么测试突发流量有没有生效？
用iperf3连续打流，观察前1秒输出速率是否显著高于平均速率；再用tc -s qdisc show dev vethXXXX查看backlog和drop计数，若前1秒峰值接近rate，说明突发余量未生效或太小；若峰值明显高于rate且drop很少,说明burst配置正常。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/640552.html
