System Design Space
Граф знанийНастройки

Обновлено: 24 марта 2026 г. в 11:23

Контейнеризация

medium

Как устроены контейнеры, слоенная файловая система, cgroups/limits и сравнение с VM.

Глава про контейнеризацию полезна тем, что снимает главный миф: контейнер - не «легкая виртуальная машина», а упаковка и изоляция процесса на базе примитивов ядра.

В реальной работе она помогает понимать, как namespaces, cgroups, layered filesystem и образ приложения превращаются в повторяемую поставку и более предсказуемый runtime.

В интервью и design review материал полезен тем, что дает зрелое объяснение, где контейнеры действительно упрощают архитектуру, а где просто добавляют новый слой операционной сложности.

Практическая польза главы

Container primitives

Формирует понимание namespaces/cgroups как основы predictability и resource control.

Deploy consistency

Помогает снижать environment drift между локальной разработкой и production.

Operational limits

Учит учитывать ограничения контейнерной модели: state, network overlay, observability, security.

Interview readiness

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

Источник

Containerization

Определение контейнеризации и ключевые принципы.

Перейти на сайт

Контейнеризация — это виртуализация на уровне ОС: приложения изолируются, но разделяют ядро хоста. Это делает контейнеры лёгкими, быстрыми и удобными для масштабирования.

Как устроена контейнеризация

  • Namespaces изолируют процессы, сеть, файловую систему и пользователей.
  • Cgroups ограничивают и распределяют CPU, память, I/O и количество процессов.
  • Union/overlay FS обеспечивает слои образов и быстрый запуск контейнеров.
  • Container runtime управляет жизненным циклом контейнеров (create/start/stop).
  • Registry и образы позволяют переносить приложения между окружениями.
Host machine (Linux)
Physical resources
CPURAMDiskNIC
Container runtime

runtime управляет namespaces и cgroups, запускает контейнеры и ограничивает ресурсы.

Containers inside host

Isolation via namespaces + cgroups

Container A

  • Nginx
  • App
CPU: 2 coresRAM: 512MBIO: limited

Container B

  • Worker
  • Queue
CPU: 1 coreRAM: 256MBIO: limited

Container C

  • DB
  • Backup
CPU: 2 coresRAM: 1GBIO: priority
Layered filesystem (overlay)
Base imageRuntime layerApp layerWritable layer
Cgroups & limits

Контролируют CPU, память и I/O для каждого контейнера, не позволяя одному процессу съесть все ресурсы.

Shared kernel

Все контейнеры разделяют ядро хоста, поэтому контейнеризация легче и быстрее VM, но требует совместимого ядра.

Слоенная файловая система

Образы контейнеров строятся из нескольких слоев, а контейнер добавляет свой writable слой.

  • Базовый слой: минимальный образ ОС или runtime.
  • Промежуточные слои: зависимости, библиотеки, конфигурации.
  • Верхний слой: приложение и его файлы.
  • Writable layer: изменения на уровне конкретного контейнера.

Визуальная модель слоенной файловой системы

У каждого контейнера свой writable слой, а read-only слои образа переиспользуются.

Writable слои контейнеров

Container A: изменения, временные файлы, логи

RW

Container B: изменения, временные файлы, логи

RW
Shared image layers

Application layer

RO

Код приложения и статические артефакты.

Dependencies layer

RO

Библиотеки, runtime и системные пакеты.

Base image layer

RO

Минимальная ОС или базовый runtime.

Copy-on-write

При записи меняется только writable слой конкретного контейнера. Базовые слои образа не переписываются.

Layer cache

Нижние слои часто кэшируются между сборками, поэтому изменения в верхних слоях собираются и деплоятся быстрее.

Cgroups и limits

  • CPU limits: квоты/шары для процессов контейнера.
  • Memory limits: жесткие пределы и OOM-killer.
  • IO limits: контроль дисковых операций.
  • PIDs limits: ограничение количества процессов.

Контейнеры vs виртуальные машины

Связанная глава

Виртуализация и виртуальные машины

Гипервизоры, типы виртуализации и сценарии, где VM лучше контейнеров.

Открыть главу

Контейнеры

  • Разделяют ядро хоста, поэтому стартуют быстро.
  • Меньше накладных расходов и выше плотность размещения.
  • Требуют совместимого ядра и делят его с другими контейнерами.

Виртуальные машины

  • Каждая VM имеет собственную гостевую ОС.
  • Выше изоляция, но больше накладные расходы.
  • Подходит для разных ОС и строгих границ безопасности.

Таймлайн контейнерной эволюции

2008

LXC в Linux

LXC объединяет namespaces и cgroups в прикладной формат: впервые появляется массово используемая Linux-контейнеризация.

2013

Docker делает контейнеры массовыми

Docker упрощает UX: image layers, Dockerfile, registry и portable workflow для разработчиков и платформенных команд.

2015

OCI стандартизирует форматы

Open Container Initiative фиксирует спецификации runtime и image, чтобы экосистема не была привязана к одному вендору.

2016

CRI в Kubernetes

Kubernetes вводит Container Runtime Interface и отделяет оркестратор от конкретного runtime.

2017–2022

containerd/CRI-O и отказ от dockershim

Контейнерные runtime становятся зрелыми; Kubernetes переходит на прямую работу через CRI, а dockershim удаляется.

2023+

Эра безопасных и специализированных runtime

Для multi-tenant и sensitive-нагрузок усиливается использование gVisor, Kata Containers и microVM-подходов.

Сравнение VM-подложки для контейнеров

Полная виртуализация

  • Где сильна: Максимальная совместимость гостевых ОС.
  • Влияние на контейнеры: Больше overhead на I/O и CPU для контейнерных узлов внутри VM.
  • Типичный сценарий: Legacy и mixed-OS сценарии.

Паравиртуализация

  • Где сильна: Оптимизированные драйверы для сети и диска.
  • Влияние на контейнеры: Лучше latency/throughput для контейнерных workloads в VM.
  • Типичный сценарий: Cloud VM с paravirt-драйверами (virtio, VMXNET3, PVSCSI).

Аппаратно-ускоренная

  • Где сильна: Дефолтная модель для production-кластеров.
  • Влияние на контейнеры: Лучший баланс изоляции и производительности под Kubernetes/containers.
  • Типичный сценарий: Основной путь в публичных облаках и enterprise DC.

Какие решения используют сейчас

Runtime и low-level слой

  • containerd и CRI-O — основной runtime для Kubernetes через CRI.
  • runc/crun — OCI-исполнители контейнеров.
  • gVisor и Kata Containers — усиленная изоляция для multi-tenant.

Dev-среда и локальная эксплуатация

  • Docker Desktop — самый распространённый локальный стек.
  • Podman/Desktop — daemonless-подход и rootless-сценарии.
  • Colima/OrbStack (macOS) — альтернативы для локальных Linux VM + containers.

Оркестрация и платформенный уровень

  • Kubernetes — индустриальный стандарт оркестрации контейнеров.
  • Nomad и Docker Swarm — более компактные альтернативы для части сценариев.
  • Managed Kubernetes в AWS/GCP/Azure — основа большинства production-платформ.

Путь запроса к nginx внутри контейнера

Путь запроса схож с виртуальными машинами, но без отдельного гипервизора — контейнер использует ядро хоста.

Путь запроса до nginx в контейнере

Путь запроса: интернет → хост → runtime → контейнер

External

Слой 1
ClientInternet

Host Linux

Слой 2
NICKernel network

Container runtime

Слой 3
Bridge/NATNamespaces

Container

Слой 4
NginxApp

Service

Слой 5
HTTP handlerBusiness logic
Путь запроса

Активный шаг

Нажмите «Старт», чтобы пройти путь запроса.

Почему это важно для системного дизайна

  • Контейнеры ускоряют доставку и упрощают окружения (dev/test/prod).
  • Понимание cgroups помогает выставлять лимиты и избегать noisy neighbor.
  • Сетевая модель контейнеров влияет на latency и правила безопасности.
  • Контейнеры стали базовой единицей деплоя в Kubernetes и облаках.

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки