--kernel-memory 参数已废弃，无法防范内核级 dos；应通过禁用危险 capabilities、限制命名空间、启用内核保护机制及 seccomp 过滤等组合措施加固。
直接限制容器的“内核内存”（Kernel Memory）并不能防范内核级拒绝服务（Kernel DoS），因为 Docker 的 --kernel-memory 参数在现代内核和 Docker 版本中已被废弃且默认禁用，它既不控制内核代码段、模块或 slab 分配器的内存，也不影响内核自身运行所需的内存空间。
为什么 --kernel-memory 不起作用
Docker 早期（1.12–17.06）曾支持 --kernel-memory，用于限制 cgroup v1 中 memory.kmem.limit_in_bytes，即容器内进程触发的内核内存分配（如 socket buffers、dentry、inode 缓存等）。但该功能存在严重问题：
- 无法隔离不同容器对全局内核资源（如 page cache、slab objects）的共享竞争；
- 启用后显著降低网络和文件 I/O 性能；
- Linux 内核自 4.8+ 起已将 kmem accounting 合并进 memory controller，cgroup v2 默认关闭独立 kmem tracking；
- Docker 20.10+ 完全移除了该参数，尝试使用会报错或静默忽略。
真正有效的内核级 DoS 防护方向
容器共享宿主机内核，因此防范内核级 DoS 的关键不是“限制内核内存用量”，而是收缩攻击面、阻断滥用路径、加固内核自身：
-
禁用危险 capabilities：移除
CAP_SYS_ADMIN、CAP_NET_ADMIN、CAP_SYS_MODULE等，防止挂载伪文件系统、修改网络栈、加载恶意模块； -
限制命名空间暴露：禁用
--privileged，避免挂载/proc/sys、/sys/fs/cgroup、/dev/kmsg等敏感路径； -
启用内核自我保护机制：确保宿主机内核编译开启
CONFIG_STRICT_KERNEL_RWX、CONFIG_SLAB_FREELIST_HARDENED、CONFIG_PAGE_TABLE_ISOLATION，防御内存篡改与侧信道攻击； -
使用 seccomp 过滤高危系统调用：拦截
open_by_handle_at、userfaultfd、perf_event_open、clone（带 CLONE_NEWUSER 外的 namespace 标志）等易被滥用于提权或耗尽内核资源的调用。
内存相关参数仍需合理配置，但目标是用户态资源隔离
虽然不能靠它防内核 DoS，但以下参数对防止容器引发宿主机 OOM 或内存耗尽仍至关重要：
-
--memory=512m：硬限制用户态内存，避免大量 malloc 导致内核回收压力剧增； -
--memory-swap=512m：禁用 swap，防止页面换入换出放大 I/O 压力； -
--pids-limit=128：限制进程数，防止 fork bomb 耗尽 pid 数或 task_struct 内存； -
--ulimit memlock=-1:-1要慎用——不限制 mlock 内存可能让容器锁定大量页，干扰内核内存管理。
归根结底，内核级拒绝服务防护不在容器运行时参数里，而在宿主机内核配置、容器最小权限设计与运行时行为约束的组合落地中。
