cgroups 本身不直接限速，需结合 tc、net_cls/net_prio（v2）或 eBPF 实现网络带宽控制；Docker/K8s 依赖 CNI 插件（如 Cilium）间接支持，验证需检查 cgroup 关联、classid 设置及 tc 规则。
cgroups 本身不直接限制网络流量，网络带宽控制主要由 Linux 内核的 traffic control（tc） 子系统配合 cgroups v2 的 net_cls 和 net_prio 控制器实现。cgroups v1 中的 net_cls 只能打标，不能限速；真正做速率限制的是 tc + iptables/ebpf + cgroup 关联规则。
net_cls + tc 实现容器出向限速（经典方案）
该方法适用于 Docker 旧版本或手动管理容器网络的场景，依赖内核 net_cls 控制器为进程打上 classid 标签，再通过 tc 在网卡根队列上匹配该标签并限速：
- 启用 net_cls 控制器：echo +net_cls > /sys/fs/cgroup/cgroup.subtree_control（cgroups v2）
- 创建子 cgroup 并设置 classid：mkdir /sys/fs/cgroup/myapp && echo 0x00110011 > /sys/fs/cgroup/myapp/net_cls.classid
- 将容器进程加入该 cgroup：echo $PID > /sys/fs/cgroup/myapp/cgroup.procs
- 在宿主机网卡（如 eth0）上配置 tc qdisc 和 filter：tc qdisc add dev eth0 root handle 1: htb default 30 && tc class add dev eth0 parent 1: classid 1:1 htb rate 5mbit && tc filter add dev eth0 parent 1: protocol ip handle 0x00110011 flowid 1:1
cgroups v2 + tc + eBPF（更现代、灵活）
cgroups v2 引入了统一层级和更安全的接口，结合 eBPF 可以实现细粒度、可编程的网络策略。例如使用 tc + cls_bpf 过滤 cgroup 关联的 socket 流量：
- 编译并加载 eBPF 程序，用 bpf_get_cgroup_classid() 获取当前 socket 所属 cgroup 的 classid
- 在 tc ingress/egress 挂载 cls_bpf，并根据 classid 分流或限速
- 优势：支持 per-socket 策略、动态更新、绕过传统 tc class/filter 配置复杂性
Docker/Kubernetes 中的实际配置方式
用户通常不直接操作 cgroup+tc，而是通过高层工具间接生效：
- Docker：使用 --network=host 时无法限速；仅对桥接网络（docker0）有效，且需额外配置 tc 规则。原生只支持 --blkio-weight 等，--network-bandwidth 并非标准选项（需插件如 libnetwork bandwidth plugin）
- Kubernetes：通过 CNI 插件实现，如 Cilium 支持基于 eBPF 的 cgroup-aware 带宽整形；Calico 结合 tc 实现 NetworkPolicy 限速；需在 Pod annotation 或 CRD 中声明 kubernetes.io/egress-bandwidth: "10M"（依赖具体 CNI 支持）
- 推荐路径：使用支持 eBPF 的 CNI（如 Cilium），开启 bandwidthManager，并在 Pod spec 中配置 k8s.v1.cni.cncf.io/networks 或使用 Bandwidth CRD
验证与调试关键点
限速是否生效不能只看配置，需逐层确认：
- 检查进程是否在目标 cgroup：cat /proc/$PID/cgroup | grep net_cls
- 确认 classid 是否写入：cat /sys/fs/cgroup/myapp/net_cls.classid
- 查看 tc 规则是否加载：tc qdisc show dev eth0 && tc class show dev eth0 && tc filter show dev eth0
- 测试时避免本地回环（lo）干扰，使用跨节点或外部 client 测试；注意容器内默认路由出口是否经过被限速的网卡
