服务器突然卡死，某个进程吃光了所有CPU和内存，这种场景运维人员都不陌生。在Ubuntu系统上，我们可以使用cgroups（控制组）这个内核功能来精准地给进程“套上缰绳”，从根源上防止资源耗尽导致的拒绝服务（DoS）问题。具体来说，就是通过创建cgroup，设定CPU、内存等资源的使用上限，然后把目标进程放进去，让它只能在划定的资源范围内运行。

cgroups是什么？为什么它是资源限制的利器？

cgroups是Linux内核的一项功能，用于限制、记录和隔离进程组所使用的物理资源，如CPU、内存、磁盘I/O和网络。它不像传统工具（如ulimit）那样只能设置单个进程的粗略限制，而是能以“组”为单位进行精细化管理。其核心价值在于“隔离”与“可控”，你可以为特定的服务（比如一个Web应用或数据库）创建一个cgroup，设定它最多只能使用30%的CPU和2GB内存。这样，即使这个服务因bug或恶意攻击发生资源泄露，也不会拖垮整个系统，从而有效防止了内部或外部引发的DoS情况。

在Ubuntu上使用cgroups v2：现代且推荐的方式

较新的Ubuntu版本（如20.04 LTS及以后）默认使用cgroups v2。它的管理接口统一挂载在/sys/fs/cgroup下，结构更清晰。我们以限制一个进程的CPU和内存为例，演示完整操作流程。

第一步：创建用于限制的cgroup

首先，我们需要创建一个新的cgroup。假设我们要限制一个名为“myapp”的服务。

sudo mkdir /sys/fs/cgroup/myapp

创建后，系统会自动在该目录下生成一系列资源控制接口文件，如cpu.max、memory.max。

第二步：设定CPU使用上限

在cgroup v2中，cpu.max文件用于控制CPU配额。其格式为“$MAX $PERIOD”，表示在每个$PERIOD微秒周期内，该cgroup最多可以使用$MAX微秒的CPU时间。例如，要限制该组进程最多使用1个CPU核心的50%，可以这样设置：

echo "50000 100000" | sudo tee /sys/fs/cgroup/myapp/cpu.max

这表示在100000微秒（100毫秒）的周期内，最多使用50000微秒（50毫秒）的CPU时间，即50%的单个CPU核心。如果要限制使用两个完整核心，则设置为“200000 100000”。

第三步：设定内存使用上限

内存限制通过memory.max文件设置。值以字节为单位。例如，限制最大内存使用为1GB：

echo 1073741824 | sudo tee /sys/fs/cgroup/myapp/memory.max

当组内进程尝试使用超过此限制的内存时，内核会尝试通过回收内存来满足请求，如果无法回收，则会触发OOM（内存不足） killer，默认会终止组内试图超额分配内存的进程，而不会影响其他cgroup中的进程。

第四步：将目标进程纳入管控

创建并配置好cgroup后，只需将目标进程的PID写入该cgroup的cgroup.procs文件即可。例如，我们想限制一个正在运行的、PID为12345的进程：

echo 12345 | sudo tee /sys/fs/cgroup/myapp/cgroup.procs

此后，该进程及其创建的所有子进程都将自动继承此cgroup限制。如果想在启动时就直接将进程放入cgroup，可以使用systemd（如果服务由systemd管理）或使用cgexec命令（需安装cgroup-tools包）：sudo cgexec -g cpu,memory:myapp /path/to/your/command。

高级限制：磁盘I/O与进程数

一个全面的防DoS策略还需考虑其他资源。cgroups v2同样可以限制磁盘I/O和最大进程数。

1. 磁盘I/O限制：这需要针对具体的块设备进行设置。首先找到设备号（如主设备号8，次设备号0对应sda），然后设置io.max。例如，限制对设备8:0的写入速度不超过10MB/s：

echo "8:0 wbps=10485760" | sudo tee /sys/fs/cgroup/myapp/io.max

2. 进程数限制：通过pids.max文件，可以防止fork炸弹。限制该cgroup内最多同时存在100个进程：

echo 100 | sudo tee /sys/fs/cgroup/myapp/pids.max

自动化与管理：与systemd集成

对于通过systemd管理的服务，可以直接在service unit文件中集成cgroup限制，实现开机自动生效，这是生产环境的最佳实践。例如，编辑/etc/systemd/system/myapp.service，在[Service]部分添加：

[Service]
CPUQuota=50%
MemoryMax=1G
TasksMax=100

这些指令分别对应CPU配额、内存上限和最大任务数。修改后运行sudo systemctl daemon-reload和sudo systemctl restart myapp即可生效。这种方式比手动操作/sys/fs/cgroup目录更规范、更持久。

监控与验证：确保限制生效

设置完成后，必须验证限制是否生效。可以通过cgroup接口本身来监控：

  • 查看CPU使用：cat /sys/fs/cgroup/myapp/cpu.stat

  • 查看内存使用：cat /sys/fs/cgroup/myapp/memory.current 和 cat /sys/fs/cgroup/myapp/memory.events（关注OOM事件）

  • 查看进程列表：cat /sys/fs/cgroup/myapp/cgroup.procs

同时，使用top或htop命令时，可以看到进程的CPU使用率会被限制在你设定的阈值附近，无法突破。

策略与见解：超越简单限制的防御思维

仅仅配置cgroups并不等于高枕无忧。一个健壮的防DoS运维策略应该是多层次的：

1. 分层限制：不要只设置一个全局限制。可以建立层级化的cgroup。例如，在根目录下为每个重要服务（如nginx、mysql、自定义应用）创建独立的子cgroup，并为每个服务设置合理的资源上限。这样实现了服务间的资源隔离，一个服务被攻击不会波及其他。

2. 结合其他安全机制：cgroups应与系统其他安全特性结合使用。例如，使用ulimit设置用户级文件描述符限制作为第一道防线；结合systemd的PrivateTmp、ProtectSystem等指令增强文件系统隔离；对于网络应用，务必结合防火墙（如ufw）和网络策略来限制连接速率和并发连接数，从网络层面缓解DoS。

3. 动态调整与弹性：在云原生或容器化环境中，静态限制可能不够灵活。可以考虑使用更上层的编排工具（如Kubernetes），它基于cgroups提供了更智能的Requests和Limits机制，并能根据负载进行一定程度的弹性调度。但对于传统的、稳定的Ubuntu服务器运维，手动设置的、经过压力测试验证的静态cgroup限制是最可靠的基础。

4. 监控告警是关键：必须对cgroup的资源使用率进行监控（例如，通过Prometheus收集memory.current等指标）。当某个cgroup频繁触发内存上限或发生OOM事件时，这本身就是一种异常告警信号，提示你可能存在程序bug或正在遭受低流量资源耗尽型攻击，需要立即介入调查。

总而言之，Ubuntu下的cgroups是一个内核级别的、强大而直接的资源管控工具。通过为关键进程设置CPU、内存、I/O和进程数的上限，你能从系统架构层面构建起一道坚固的防线，有效遏制因单点资源失控而导致的系统级DoS风险。将它与systemd服务管理、系统监控和网络防火墙相结合，就能形成一套纵深防御体系，大幅提升服务器的稳定性和抗攻击能力。