Когда контейнер поднимается, он использует какое ядро?

Контейнер и его ядро: разделение иллюзии и реальности

Когда контейнер «поднимается», он использует ядро хостовой операционной системы (host OS kernel), на котором запущен контейнерный runtime (например, Docker или containerd). Это фундаментальный принцип контейнеризации, отличающий её от виртуализации. Контейнер не имеет собственного независимого ядра.

Архитектурные детали

Контейнер — это изолированный процесс (или группа процессов) в пространстве пользователя (user space). Он создаётся с помощью механизмов ядра Linux:

• Namespaces (пространства имён): Обеспечивают изоляцию. Например, PID namespace изолирует дерево процессов, Network namespace — сетевые интерфейсы.
• Cgroups (control groups): Ограничивают и отслеживают использование ресурсов (CPU, память, I/O).
• Union filesystems (OverlayFS, AUFS): Позволяют создавать слоистые образы контейнеров.

Поскольку эти механизмы являются частью ядра Linux, контейнер напрямую взаимодействует с ним через системные вызовы (syscalls).

Практическая демонстрация

Запустим контейнер и проверим информацию о ядре.

1. Смотрим ядро внутри контейнера:

# Запускаем контейнер на основе Alpine Linux (легковесный дистрибутив)
docker run --rm -it alpine:latest uname -a

Вывод будет выглядеть примерно так:

Linux 5a2b3c4d0e1f 5.15.0-91-generic #101-Ubuntu SMP ... x86_64 Linux

• 5a2b3c4d0e1f — это hostname, присвоенный контейнеру.
• 5.15.0-91-generic — это версия ядра хостовой машины.

2. Сравниваем с ядром на хосте: На самой хост-машине выполните:

uname -a

Вы увидите ту же самую версию ядра, что и внутри контейнера.

3. Более наглядный пример: Создадим простой скрипт, который покажет, что контейнер «видит» системные вызовы к единому ядру.

# Запускаем контейнер и смотрим информацию из /proc (виртуальная файловая система ядра)
docker run --rm -it alpine:latest cat /proc/version

Вывод покажет компилятор и версию ядра, использованные для сборки хостового ядра.

Ключевые следствия и ограничения

• Совместимость: Контейнеры Linux не могут работать на Windows или macOS без слоя виртуализации (как это делает Docker Desktop). И наоборот, контейнеры Windows требуют ядра Windows Server.
• Монолитное ядро: Все контейнеры на одном хосте разделяют одни и те же системные вызовы и драйверы ядра. Уязвимость в ядре затрагивает все контейнеры.
• Требования: Для запуска контейнеров с новыми функциями (например, определенные syscalls или типы cgroups v2) требуется обновление ядра хоста, а не образов контейнеров.
• Иллюзия изоляции: Несмотря на использование единого ядра, изоляция через namespaces очень эффективна на процессном уровне, сетевом и файловом.

Сравнение с виртуальными машинами (ВМ)

Итог

Контейнер — это высокооптимизированный, изолированный процесс, который делит ядро Linux с хостом и другими контейнерами. Это обеспечивает беспрецедентную плотность развертывания и скорость запуска по сравнению с ВМ, но накладывает архитектурные ограничения. Для полной изоляции ядра и ОС необходима виртуализация. В современных гибридных средах (например, Kubernetes) эти технологии часто комбинируются: контейнеры работают внутри виртуальных машин в облаке для обеспечения дополнительных уровней безопасности и управления.