Namespace 和 Cgroups 是 Docker 容器的底层双支柱：Namespace 实现视图隔离（PID、Network、Mount、UTS、IPC、User 六类），使容器进程彼此“看不见”；Cgroups 实施资源限制（内存、CPU、进程数等），确保容器“用不了那么多”。二者缺一不可，协同构成完整容器。
Namespace 和 Cgroups 是 Docker 容器运行的底层双支柱：一个管“看不见”，一个管“用不了那么多”。不理解它们，就只能停留在 docker run 的表层；真正掌控容器行为、排查资源争抢或隔离失效问题，必须从这两个内核机制入手。
Namespace：让每个容器活在自己的“小世界”里
Namespace 不是虚拟出一套硬件，而是对现有系统资源做逻辑封装和视角过滤。同一个物理 CPU、同一块内存条，不同 Namespace 下的进程彼此“视而不见”——这不是权限控制，而是视图隔离。
Linux 提供六类核心 Namespace，Docker 启动容器时默认启用全部：
-
PID：容器内
ps aux只看到自己进程，PID 从 1 开始；宿主机上它只是普通子进程 - Network：独占网络栈，有自己 lo、eth0、IP、端口、iptables 规则，与宿主机网络完全不重叠
-
Mount：文件系统挂载点独立，
/proc、/sys、/dev等均被重新挂载为容器视角 -
UTS：可设独立主机名（
hostname）和域名（domainname），不影响宿主机 - IPC：消息队列、信号量、共享内存等进程间通信资源互不可见
- User：用户/组 ID 映射隔离，容器内 root（UID 0）可映射为宿主机非特权用户，提升安全性
验证方式很简单：进容器执行 ls -l /proc/self/ns，能看到六个符号链接，指向不同 inode；再对比宿主机同路径，inode 值完全不同——说明已处于不同 Namespace 实例中。
Cgroups：给容器套上“资源紧箍咒”
Namespace 解决“能不能看见”，Cgroups 解决“能不能用够”。它不阻止进程存在，但能硬性掐断超额资源供给。比如内存超限会触发 OOM Killer 杀掉容器内进程；CPU 配额耗尽后，进程只能等待下一轮调度周期。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
Docker 启动时通过 --memory=512m、--cpus=1.5 等参数，最终落地为对 Cgroups v2 接口的写入：
-
/sys/fs/cgroup/docker/<container-id>/memory.max：设为536870912（即 512MB） -
/sys/fs/cgroup/docker/<container-id>/cpu.max：设为150000 100000（1.5 核配额） -
/sys/fs/cgroup/docker/<container-id>/pids.max：限制最大进程数，防 fork 炸弹
所有容器内派生的子进程自动继承这些限制——这是 Cgroups 的关键特性：资源控制按进程组（cgroup.procs）生效，且父子进程天然继承。你可以用 cat /proc/1/cgroup 查看容器主进程所属 cgroup 路径，再读对应 memory.max 或 cpu.stat 获取实时限额与使用统计。
二者协同，才叫一个“容器”
单独 Namespace = 一个视野受限但资源无约束的进程（可能把宿主机内存吃光）；单独 Cgroups = 一个受控但全局可见的进程组（能看到所有 PID、能访问宿主机网络）。只有两者叠加，才构成 Docker 定义的容器：既看不见别人，也动不了太多。
举个典型问题场景：容器内 top 显示内存用了 400MB，但宿主机 free -h 看整体内存没涨——这是因为 Mount + PID + Network Namespace 让它只看到自己视图；而 cat /sys/fs/cgroup/memory.docker/xxx/memory.usage_in_bytes 才反映真实占用，这个值若接近 memory.max，就说明真快撑不住了。
不复杂但容易忽略
