Вопрос проверяет понимание механизмов изоляции и ограничения ресурсов в контейнеризации, помимо namespaces, что важно для настройки безопасных и производительных контейнеров.
Контейнеры используют несколько уровней изоляции, чтобы процессы внутри контейнера не влияли на хост-систему и другие контейнеры. Помимо namespaces, которые изолируют видимость ресурсов (PID, сеть, файловая система), ключевую роль играют cgroups (control groups).
cgroups ограничивают, учитывают и изолируют использование ресурсов (CPU, память, диск I/O, сеть) для групп процессов. Например, можно задать максимальный объем памяти для контейнера или ограничить долю CPU.
# Пример ограничения памяти для процесса через cgroup v2
echo "100M" > /sys/fs/cgroup/mycontainer/memory.max
echo $$ > /sys/fs/cgroup/mycontainer/cgroup.procsLinux capabilities позволяют разбить привилегии root на мелкие единицы. Контейнеры запускаются с ограниченным набором capabilities (например, без CAP_SYS_ADMIN), что снижает риски эскалации привилегий.
# Docker по умолчанию удаляет опасные capabilities
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginxSeccomp (secure computing mode) фильтрует системные вызовы, разрешая только необходимые. Это предотвращает использование небезопасных системных вызовов из контейнера.
# Пример профиля seccomp, разрешающего только базовые syscalls
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [{"names": ["read", "write", "exit"], "action": "SCMP_ACT_ALLOW"}]
}Эти модули ядра реализуют мандатное управление доступом (MAC), накладывая дополнительные метки и правила на процессы и файлы. Контейнеры могут использовать политики, ограничивающие доступ к ресурсам хоста.
Вывод: Комбинация cgroups, capabilities, seccomp и MAC-модулей обеспечивает многоуровневую изоляцию, необходимую для безопасной работы контейнеров в production-средах. Эти механизмы позволяют запускать множество контейнеров на одном хосте с минимальным риском взаимного влияния и утечки данных.
