Контейнеры — это процессы. И точка.
Вот та самая правда ОС, за которой инженеры гоняются в маркетинговой мишуре: процесс или дерево процессов, которому Linux подсовывает фальшивую реальность — урезанные неймспейсы для его собственного уголка, cgroups, давящие ресурсы потолками вроде квот CPU и лимитов памяти. Никакого гостевого ядра. Никаких трат на гипервизор. Просто хитрые ограничения, превращающие одну машину в десятки изолированных приложений. И вот почему они рулят в облачных операциях: AWS, GCP, Azure — все запихивают 80% нагрузок в эти пареньки, по свежим опросам CNCF, потому что ресурсы они жрут минимально по сравнению с VM.
Смотрите, podman run доказывает это наголо. Запустите команду — прямо из окопов:
podman run -d \
--name my-limited-httpd \
--replace \
--memory=512m \
--memory-swap=512m \
--cpus=1.5 \
--cpu-shares=512 \
--pids-limit=100 \
--blkio-weight=500 \
-p 8081:80 \
registry.access.redhat.com/ubi8/httpd-24
Бам. Получили HTTPD-контейнер, зажатый в 512 МБ RAM (без подмены свопом), 1,5 ядра CPU, максимум 100 PID. Загляните в pstree — и всё ясно.
systemd(1)─┬─… ├─conmon(13669)───httpd(13684)─┬─cat(13727) … httpD плодит детей, все под conmon — нянькой-процессом.
Podman не рождает httpd в одиночку. Он зовёт crun — шуструю переписанную на C версию runc, дефолтную на SLES 16 и сородичах. Crun клонирует с флагами неймспейсов (PID, net, mount, что угодно), вбивает лимиты cgroups в /sys/fs/cgroup, накладывает слои образа как rootfs, запускает execve() вашего приложения. И пуф — crun испаряется. Conmon остаётся для I/O и кодов выхода. Цепочка простая: podman → crun → ядро → ваш httpd в изоляции.
Ловушка жаргона, которую обожают вендоры
Но. Термины размываются нарочно — Docker на $9 млрд рыночной капитализации оседлал эту волну, слив ядро, ОС, процессы и образы в размытое «контейнер». Ни черта не проясняет, когда ваше приложение OOMит.
Ядро? Рефери для железа: планирует CPU, раздаёт память, навязывает неймспейсы и cgroups.
ОС? Ядро плюс юзерленд (libc, bash, systemd) — RHEL как полный обед.
Процесс? Слайс программы с PID, заглядываете через /proc.
Образ? Схема в слоях — только чтение + JSON-конфиг. Рантайм крутит инстансы; один образ — десять контейнеров, каждый с приватным оверлеем для записи.
«Образ = что запускать. Спецификация рантайма = как запускать. Контейнер = процесс, который выходит.»
Вбийте это — и отладка пойдёт как по маслу.
Образ против контейнера: фатальная путаница?
Образы лежат мёртвым грузом. Контейнеры бегут. Спецификация OCI требует: распакуйте слои, примените спек, запустите процесс. Crun (или тяжёлый Go от runc) тянет лямку. Много запусков? Общая база на чтение, приватные записи — магия хранения, спасающая терабайты в проде.
Миф умирает здесь: никакого мини-Linux внутри. PID 1? Фокус неймспейса — хост видит ваш PID 42 контейнера как 1 внутри. Глобальный init? Всё тот же systemd(1) снаружи.
Почему контейнеры душат VM в 2024-м?
Рыночные цифры кричат. VM виртуализируют железо — 10–20% оверхеда по бенчмаркам Red Hat. Контейнеры? Менее 1% — то же ядро, порезанные неймспейсы. Kubernetes-кластеры жужжат на этом; Datadog фиксирует 70%+ контейнеризированных приложений в мониторинге.
Моё мнение — свежее: это эхо chroot-турем 1979-го, первобытного хака Unix на изоляцию. Контейнеры? Просто неймспейсы (2000-е) + cgroups (2007) на стероидах. Docker переупаковал для венчурного золота, но ядро потянуло основное. Прогноз: eBPF набирает — добавит точный контроль без смены рантаймов, толкая долю контейнеров за 90% к 2026-му. Вендорский спин зовёт это «революцией»; нет, эволюционная экономия.
Совет для проды: уперлись в ресурсы? Статистика cgroups в /sys/fs/cgroup покажет удушение — pids-limit=100 морит многопоточные приложения. Подкрутите blkio-weight при I/O-бутылочных горлышках; это ваш рычаг.
Предупреждение в одну фразу: игнорируйте — и будете гоняться за призраками.
Переходим на Podman — без рута, без демона, убийца демонов. Red Hat давит им после Docker-драмы (н
