容器技术基石命名空间与 cgroup底座认知 · 第 01 篇容器的「隔离」与「限制」到底是如何实现的目 录一、容器的本质二、命名空间实现隔离三、cgroup实现限制3.1 cgroup v1 与 v23.2 生产要点cgroup v2 与容器运行时四、容器如何组合使用它们五、与 K8s 的衔接5.1 内存限制与 OOMKilled5.1.1 区分两种内存耗尽5.1.2 与 QoS 等级的关系5.1.3 排查与解决一、容器的本质容器并不是「一个更轻的虚拟机」。它的本质是一个运行在宿主机上的普通进程只是被操作系统施加了两类机制从而呈现出「独立」的外观。命名空间Namespace让进程「看不到」宿主机的其他资源实现隔离cgroup让进程「用不了」超过配额的系统资源实现限制二者相辅相成共同构成了容器的基础。本篇逐个拆解它们的工作原理与生产意义。二、命名空间实现隔离命名空间把全局系统资源「各切一份」给不同进程组使每个命名空间内的进程只看到属于自己的那一份就像住进独立房间。命名空间隔离的资源典型效果PID进程编号容器内 PID 1 是应用进程看不到宿主其他进程Mount挂载点容器有自己的根文件系统Network网络栈独立的网卡、IP、路由UTS主机名与域名容器可有自己的 hostnameIPC进程间通信独立的信号量、消息队列User用户与 UID容器内可映射非 root 权限对运维最重要的是 PID、Mount、Network 三者它们分别决定了进程隔离、文件系统隔离和网络栈隔离也是排障时最常涉及的层面。三、cgroup实现限制cgroup 是 Linux 内核的资源控制器用于对一组进程做 CPU、内存、磁盘 IO、网络带宽等资源的配额与统计。它决定了「容器最多能用多少资源」。3.1 cgroup v1 与 v2cgroup 有两个版本结构差异显著。主流新系统如 Rocky Linux 9、CentOS Stream、Ubuntu 22.04默认使用 v2。对比维度cgroup v1cgroup v2层次结构每个子系统独立树统一树单层次控制器CPU/内存等各有独立挂载点统一在 /sys/fs/cgroup 下线程控制不支持仅进程支持线程级细分并发安全较弱原生原子写、更安全代表系统CentOS 7、Ubuntu 20.04Rocky 9、Ubuntu 22.043.2 生产要点cgroup v2 与容器运行时在 cgroup v2 系统上使用 containerd必须把 runc 配置为使用 systemd cgroup 驱动否则可能资源隔离失效。验证命令确认系统是 v2cat /sys/fs/cgroup/cgroup.controllers确认运行时 cgroup 驱动crictl info | grep cgroupDriver应输出 systemd四、容器如何组合使用它们当 runc 启动一个容器时会依次创建所需的命名空间把进程「关」进隔离环境再将其放入 cgroup 树中分配资源限额。一个典型流程是创建命名空间 → 挂载 rootfs → 设置 cgroup 限额 → 执行容器入口进程这意味着隔离让容器「像独立机器」限制让容器「吃不下超出的资源」二者结合才形成可安全共存的资源环境。五、与 K8s 的衔接K8s 并不直接操作这些内核机制而是通过容器运行时containerd间接使用。但理解它们对排查有直接价值Pod 中容器「看不到」宿主其他进程 → 正常现象源于 PID 命名空间容器被限制内存后 OOMKilled → 与 cgroup 内存限制有关kubelet 的资源 requests/limits 最终通过 cgroup 落地5.1 内存限制与 OOMKilled容器被限制内存后出现 OOMKilled正是 cgroup 内存限制与内核 OOM 机制共同作用的结果。完整链路容器内存使用量超过 cgroup 内存上限 → cgroup 无法再分配内存 → 内核 OOM Killer 介入把超限容器进程杀掉SIGKILL→ K8s 检测到容器退出状态记为 OOMKilled。触发条件是容器的 limits.memoryK8s 会把它落到容器的 cgroup 上。当容器实际内存超过上限即触发 OOM Killerkubectl get pod 中 STATUS 显示 OOMKilledLAST STATE 的 Exit Code 为 137等于 128 9即被 SIGKILL 信号杀死。
容器技术基石命名空间与 cgroup底座认知 · 第 01 篇容器的「隔离」与「限制」到底是如何实现的目 录一、容器的本质二、命名空间实现隔离三、cgroup实现限制3.1 cgroup v1 与 v23.2 生产要点cgroup v2 与容器运行时四、容器如何组合使用它们五、与 K8s 的衔接5.1 内存限制与 OOMKilled5.1.1 区分两种内存耗尽5.1.2 与 QoS 等级的关系5.1.3 排查与解决一、容器的本质容器并不是「一个更轻的虚拟机」。它的本质是一个运行在宿主机上的普通进程只是被操作系统施加了两类机制从而呈现出「独立」的外观。命名空间Namespace让进程「看不到」宿主机的其他资源实现隔离cgroup让进程「用不了」超过配额的系统资源实现限制二者相辅相成共同构成了容器的基础。本篇逐个拆解它们的工作原理与生产意义。二、命名空间实现隔离命名空间把全局系统资源「各切一份」给不同进程组使每个命名空间内的进程只看到属于自己的那一份就像住进独立房间。命名空间隔离的资源典型效果PID进程编号容器内 PID 1 是应用进程看不到宿主其他进程Mount挂载点容器有自己的根文件系统Network网络栈独立的网卡、IP、路由UTS主机名与域名容器可有自己的 hostnameIPC进程间通信独立的信号量、消息队列User用户与 UID容器内可映射非 root 权限对运维最重要的是 PID、Mount、Network 三者它们分别决定了进程隔离、文件系统隔离和网络栈隔离也是排障时最常涉及的层面。三、cgroup实现限制cgroup 是 Linux 内核的资源控制器用于对一组进程做 CPU、内存、磁盘 IO、网络带宽等资源的配额与统计。它决定了「容器最多能用多少资源」。3.1 cgroup v1 与 v2cgroup 有两个版本结构差异显著。主流新系统如 Rocky Linux 9、CentOS Stream、Ubuntu 22.04默认使用 v2。对比维度cgroup v1cgroup v2层次结构每个子系统独立树统一树单层次控制器CPU/内存等各有独立挂载点统一在 /sys/fs/cgroup 下线程控制不支持仅进程支持线程级细分并发安全较弱原生原子写、更安全代表系统CentOS 7、Ubuntu 20.04Rocky 9、Ubuntu 22.043.2 生产要点cgroup v2 与容器运行时在 cgroup v2 系统上使用 containerd必须把 runc 配置为使用 systemd cgroup 驱动否则可能资源隔离失效。验证命令确认系统是 v2cat /sys/fs/cgroup/cgroup.controllers确认运行时 cgroup 驱动crictl info | grep cgroupDriver应输出 systemd四、容器如何组合使用它们当 runc 启动一个容器时会依次创建所需的命名空间把进程「关」进隔离环境再将其放入 cgroup 树中分配资源限额。一个典型流程是创建命名空间 → 挂载 rootfs → 设置 cgroup 限额 → 执行容器入口进程这意味着隔离让容器「像独立机器」限制让容器「吃不下超出的资源」二者结合才形成可安全共存的资源环境。五、与 K8s 的衔接K8s 并不直接操作这些内核机制而是通过容器运行时containerd间接使用。但理解它们对排查有直接价值Pod 中容器「看不到」宿主其他进程 → 正常现象源于 PID 命名空间容器被限制内存后 OOMKilled → 与 cgroup 内存限制有关kubelet 的资源 requests/limits 最终通过 cgroup 落地5.1 内存限制与 OOMKilled容器被限制内存后出现 OOMKilled正是 cgroup 内存限制与内核 OOM 机制共同作用的结果。完整链路容器内存使用量超过 cgroup 内存上限 → cgroup 无法再分配内存 → 内核 OOM Killer 介入把超限容器进程杀掉SIGKILL→ K8s 检测到容器退出状态记为 OOMKilled。触发条件是容器的 limits.memoryK8s 会把它落到容器的 cgroup 上。当容器实际内存超过上限即触发 OOM Killerkubectl get pod 中 STATUS 显示 OOMKilledLAST STATE 的 Exit Code 为 137等于 128 9即被 SIGKILL 信号杀死。
方法)
