容器稳定性与异常流量控制的核心是cgroups资源约束：cgroups v2通过cpu.max、memory.max、io.max精确限制CPU、内存、IO；结合systemd可实现启动级绑定；联动tc或eBPF实现容器级网络限速；监控须直接采集cgroup fs原始指标。
容器稳定性与异常流量控制，核心在于对资源使用施加精确、动态的约束。cgroups（control groups）是 Linux 内核提供的底层机制，它让容器运行时（如 containerd、runc）能隔离、限制、计量和审计进程组的 CPU、内存、IO、网络等资源——这正是保障容器不因自身失控或外部冲击而拖垮宿主机或其他容器的关键基础。
用 cgroups 限制关键资源，防止单个容器吃光系统
cgroups v2 是当前推荐标准（统一层级、更简洁接口），需确保内核启用 cgroup v2（检查 /proc/filesystems 是否含 cgroup2）。实际限制通常由容器引擎自动配置，但理解其映射关系至关重要：
-
CPU 限流：通过
cpu.max（v2）设定配额/周期，例如100000 100000表示每 100ms 最多用 100ms CPU 时间（即 1 核）；超限后进程被 throttled，避免抢占其他容器 -
内存硬限制：设置
memory.max（如512M），超出立即触发 OOM Killer 杀掉容器内主进程；配合memory.low可为重要容器保留缓冲，减少被优先回收风险 -
IO 限速：用
io.max限制块设备读写带宽与 IOPS，防止慢盘容器引发全局 IO 延迟飙升
结合 systemd 管理容器服务，实现启动级资源绑定
若容器以 systemd service 方式部署（如 Podman 容器或自定义守护进程），可直接在 unit 文件中声明资源约束，比运行时参数更早生效且更稳定：
- 在
[Service]段添加MemoryMax=512M、CPUQuota=50%、IOWeight=50 - systemd 自动将服务进程加入对应 cgroup v2 路径（如
/sys/fs/cgroup/<service-name>.service/</service-name>），无需手动挂载或 chown - 重启服务即可刷新限制，且与系统启动顺序、依赖管理天然集成
识别并拦截异常流量，从内核层做第一道过滤
cgroups 本身不处理网络包，但可与 cls_cgroup（tc + cgroup cls）或 eBPF（如 Cilium）联动，实现按容器维度的网络策略：
- 传统方式：用
tc class add创建基于 cgroup 的 qdisc 类，再通过iptables -j CLASSIFY将匹配连接打上 cgroup classid，从而对某容器出口流量限速或标记丢弃 - 现代方式：eBPF 程序（如 Cilium 的 Bandwidth Manager）直接读取 cgroup ID，对属于某容器的 socket 施加速率限制（
bpf_skb_output或sk_msg程序），延迟更低、精度更高 - 关键动作：对突发 HTTP 扫描、DNS 放大请求等异常流量，不只靠应用层限流，应结合 conntrack 统计 + cgroup 关联，在 netfilter early-drop 阶段拦截
监控与告警必须覆盖 cgroups 指标，而非仅容器上报值
容器运行时（如 Docker stats）返回的 CPU/Mem 数据可能滞后或被缓存，真实压力要看 cgroup 接口原始值：
- 监控项应包括：
/sys/fs/cgroup/<path>/cpu.stat</path>中的nr_throttled和throttled_time（反映 CPU 抢占严重性） -
/sys/fs/cgroup/<path>/memory.current</path>与memory.max的比值，比容器内free -m更准 - 使用
node_exporter的node_cgroup_*指标，或 Prometheus 直接抓取 cgroup fs，设置阈值告警（如 throttled_time > 5s/分钟）
