gVisor 如何启用 systemd cgroup 驱动并映射 OCI 资源限制【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor默认情况下runsc自己创建 cgroup 并设置 cgroup 限制这种模式称为 fs cgroup 驱动。如果你希望容器的 cgroup 由宿主机的 systemd 管理——例如让容器资源出现在 systemd 的单元树中、由 systemd 负责记账——需要为runsc启用 systemd cgroup 驱动。该功能要求宿主机 systemd 版本至少为 244并且启用统一 cgroupscgroup v2。本文基于 g3doc/user_guide/systemd.md 说明启用方式、单元命名规则以及 OCI runtime spec 资源如何映射为 systemd 单元属性。前提条件systemd 版本与 cgroup v2按 g3doc/user_guide/systemd.md 的说明使用 systemd cgroup 驱动前需满足宿主机 systemd 版本 ≥ 244可用systemctl --version查看当前版本宿主机启用统一 cgroups即 cgroup v2。这两条是硬性要求不满足时该驱动不可用。启用 systemd cgroup 驱动--systemd-cgroup是runsc的全局选项在命令前加上即可切换驱动文档给出的示例形式是runsc --systemd-cgroup run ...需要说明的是这个标志在 runsc/config/flags.go 中被标记为 EXPERIMENTALEXPERIMENTAL. Use systemd for cgroups.属于实验性功能。在 Docker 场景下同样通过给 runsc 运行时附加该标志实现。快速入门指南 g3doc/user_guide/quick_start/docker.md 说明runsc install可以在--之后传递运行时参数文档中的示例sudo runsc install --runtime runsc-debug -- \ --debug \ --debug-log/tmp/runsc-debug.log \ --strace \ --log-packets仿照该形式把--systemd-cgroup放在--之后即可安装一个始终使用 systemd cgroup 驱动的运行时runsc-systemd是示例运行时名可自定。仓库 Makefile 中也注册了一个带--systemd-cgroup标志的运行时runsc-systemd-d可作为参照。runsc 如何决定单元名称和 slice创建容器时runsc 会通过 dbus 请求 systemd 为该容器创建一个 transient unit并将其放入指定 slice。单元名和 slice 由 OCI runtime spec 中的Linux.CgroupsPath推导若Linux.CgroupsPath已设置期望其格式为[slice]:[prefix]:[name]slice是容器所在的 systemd slice。为空时默认system.slice但在 cgroup v2 下创建 rootless 容器时默认user.slice。slice可以用短横线表示子 slice如user-1000.slice表示user.slice的子 slice但不能包含斜杠user.slice/user-1000.slice是非法的。-表示根 slice。prefix和name组成单元名prefix-name.scope如果name以.slice结尾则忽略prefixname原样使用。若Linux.CgroupsPath未设置或为空等价于设置为:runsc:container-id最终得到system.slice下的runsc-container-id.scope。创建出的单元是 systemd scoperunsc 通过Slice属性指定父 slice并设置Delegatetrue。OCI 资源限制到 systemd 属性的映射runsc 会无条件启用所有控制器的记账即为创建的 systemd 单元设置CPUAccountingtrueIOAccountingtrueMemoryAccountingtrueTasksAccountingtrue资源限制本身由 runsc 将 runtime spec 资源翻译为 systemd 单元属性来实现。需要注意这种翻译并不完整因为有些 cgroup 属性无法通过 systemd 设置——因此 systemd cgroup 驱动由 fs 驱动兜底先通过 systemd 单元属性设置再通过直接写 cgroupfs 文件设置。可翻译的资源取决于内核 cgroup 版本v1/v2和宿主机 systemd 版本如果使用了较旧的系统d版本runsc 不会设置它不支持的资源。g3doc/user_guide/systemd.md 给出的映射表如下runtime spec resourcesystemd property namemin systemd versionmemory.limitMemoryMaxmemory.reservationMemoryLowmemory.swapMemorySwapMaxcpu.sharesCPUWeightpids.limitTasksMaxcpu.cpusAllowedCPUscpu.memsAllowedMemoryNodesunified.cpu.maxCPUQuota, CPUQuotaPeriodSecunified.cpu.weightCPUWeightunified.cpu.idleCPUWeightv252unified.cpuset.cpusAllowedCPUsunified.cpuset.memsAllowedMemoryNodesunified.memory.highMemoryHighunified.memory.lowMemoryLowunified.memory.minMemoryMinunified.memory.maxMemoryMaxunified.memory.swap.maxMemorySwapMaxunified.pids.maxTasksMax上表是文档原文的映射关系其中仅unified.cpu.idle标注了最低 systemd 版本 v252。各属性的含义可参考systemd.resource-control(5)man page。验证检查 scope 单元与翻译后的属性按上述规则验证可以落在两点上均为文档描述的行为可据此核对单元放置位置以默认Linux.CgroupsPath等价:runsc:container-id为例容器对应的单元应为system.slice下的runsc-container-id.scope若你设置了自定义CgroupsPath则按 slice/前缀规则推导出预期单元名确认 transient scope 出现在对应 slice 中。属性翻译检查该 scope 的记账属性CPUAccounting、IOAccounting、MemoryAccounting、TasksAccounting均为 trueDelegatetrue以及资源属性是否反映了 OCI spec 中的设置例如 OCI 的unified.memory.max对应MemoryMax、cpu.shares对应CPUWeight。在带资源参数的场景下g3doc/user_guide/quick_start/docker.md 展示了docker run --runtimerunsc ... --cpus0.5这类用法这些参数进入 runtime spec 后即按上表翻译。限制与边界标志本身标记为 EXPERIMENTAL行为以 g3doc/user_guide/systemd.md 描述为准。翻译不完整无法通过 systemd 设置的 cgroup 属性会回退到直接写 cgroupfsfs 驱动兜底而不是报错。较旧版本的 systemd 会静默跳过它不支持的资源而不是报错。资源限制的生效范围按 g3doc/user_guide/compatibility.md 的说明sandbox 内部的 cgroupCPU、内存只用于资源记账限制不在 sandbox 内部强制执行把 gVisor 放入宿主机的 cgroup 可以限制整个 sandbox 的资源但 gVisor 目前无法在同一 sandbox 内竞争进程之间强制资源限制。【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考