runc, crun или youki: выбор OCI runtime для Linux VDS

runc, crun и youki решают одну базовую задачу: получают OCI bundle с файловой системой и файлом config.json, создают пространства имён Linux, подключают cgroups, применяют ограничения и запускают процесс контейнера. Обычно администратор не вызывает их напрямую: команду runtime формирует Docker, Podman, containerd или другой высокоуровневый слой.

Поэтому выбирать OCI runtime только по языку разработки или одному опубликованному тесту скорости неправильно. На Linux VDS важнее совместимость с используемым движком, ядром, cgroups v2, systemd, rootless-режимом и конкретными функциями контейнеров. Также следует учитывать доступность пакетов и скорость получения исправлений безопасности.

Номера версий разных runtime нельзя напрямую сопоставлять как показатель качества: у проектов отличаются циклы разработки и правила версионирования. Важнее проверять поддержку нужных возможностей, качество интеграции с вашим контейнерным движком и результаты испытаний на собственной нагрузке.

Что именно сравнивается

Низкоуровневый OCI runtime не заменяет Docker, Podman или containerd. Он не скачивает образы, не ведёт их каталог, не предоставляет полноценный интерфейс для сетей и томов и не управляет распределённым кластером. Его зона ответственности — жизненный цикл отдельного контейнера на уровне операционной системы.

В типичной цепочке Docker или Podman подготавливает корневую файловую систему и OCI-конфигурацию, затем передаёт их runtime. В случае containerd между демоном и исполняемым OCI runtime обычно находится shim. Например, containerd-shim-runc-v2 может запускать OCI-совместимый бинарный файл, заданный его параметрами. Поэтому совместимость с containerd включает не только поддержку OCI, но и корректную настройку shim и его опций.

В этом обзоре сравниваются именно runc, crun и youki. Возможности контейнерных движков, сетевых плагинов, snapshotter, оркестраторов и средств изоляции на основе виртуальных машин остаются за рамками материала.

Краткий вывод

• runc — консервативный выбор, если приоритетом являются предсказуемость, широкая проверка в эксплуатации и отсутствие дополнительной работы по совместимости.
• crun — практичная альтернатива для Podman, rootless-контейнеров, небольших VDS и сценариев с частыми короткими запусками. Его ключевые преимущества — компактность и низкие накладные расходы.
• youki — OCI runtime на Rust для тестовых и контролируемых сред, а также команд, которым важны безопасность памяти и развитие Rust-стека. Перед назначением его runtime по умолчанию нужны собственные интеграционные испытания.

Для обычного Docker-сервера переход с runc только ради предполагаемого ускорения редко приносит заметную пользу. Для Podman на ограниченной по памяти VDS crun часто оказывается естественным выбором. Youki стоит рассматривать не как автоматическую замену runc, а как отдельный технологический выбор с более молодым жизненным циклом.

runc: консервативная база экосистемы

runc — распространённый низкоуровневый OCI runtime для Linux, развиваемый в рамках Open Container Initiative. Он запускает контейнеры в соответствии с OCI Runtime Specification и широко используется как стандартная реализация в контейнерной экосистеме. Сам проект подчёркивает, что runc предназначен прежде всего для вызова высокоуровневыми системами, а не для повседневной ручной работы администратора.

Сильные стороны runc

• широкая проверка в реальных установках;
• предсказуемая интеграция с Docker и containerd;
• большое число готовых пакетов в репозиториях Linux-дистрибутивов;
• поддержка rootless-контейнеров, cgroups v2, seccomp и основных механизмов Linux;
• широкая база известных сценариев диагностики и исправления ошибок;
• регулярные обновления безопасности и upstream-релизы.

Главное преимущество runc — не победа в отдельном микротесте, а низкий эксплуатационный риск. Его поведение хорошо знакомо разработчикам движков, авторам дистрибутивов и администраторам. Если приложение использует редкое сочетание mounts, namespaces, OCI hooks, seccomp или checkpoint/restore, вероятность того, что путь с runc уже проверен, обычно выше.

Ограничения runc

runc не ориентирован на минимально возможный размер процесса и в синтетических тестах запуска короткоживущих контейнеров может уступать crun. Это бывает важно при сотнях или тысячах последовательных созданий контейнеров, но почти не влияет на длительно работающий веб-сервер, базу данных или фоновый сервис.

Использование Go не означает, что каждый контейнер постоянно удерживает отдельный большой процесс runc. Низкоуровневый runtime выполняет операции создания или изменения контейнера и завершает вызов. В устойчивом состоянии расход памяти определяется прежде всего приложением внутри контейнера, процессами shim, средствами мониторинга и компонентами движка. Поэтому экономию памяти runtime нельзя умножать на число всех работающих контейнеров без анализа реального дерева процессов.

crun: компактность и быстрый жизненный цикл

crun реализован на C и ориентирован на небольшой расход памяти. Его ядро также может использоваться как библиотека libcrun, что отличает проект от модели, в которой управляющая программа всегда запускает отдельный внешний бинарный файл. Проект заявляет соответствие OCI Runtime Specification.

Где crun особенно уместен

• Podman и связанные с ним инструменты;
• rootless-контейнеры на современных системах с cgroups v2;
• VDS с небольшим объёмом оперативной памяти;
• CI-задачи и сборочные среды с большим числом коротких контейнеров;
• сервисы, часто создающие и удаляющие изолированные процессы;
• встраиваемые решения, способные использовать libcrun.

Время работы runtime составляет лишь часть полного запуска. Движок также проверяет конфигурацию, подготавливает overlay filesystem, подключает тома, настраивает сеть и обращается к хранилищу образов. При холодном скачивании образа или тяжёлом entrypoint разница между runtime теряется на фоне остальных операций. Преимущество crun лучше проявляется на уже загруженном небольшом образе с простой командой и частыми повторными запусками.

Что учитывать перед переходом

Код на C сам по себе не делает runtime небезопасным, но ошибки управления памятью относятся к характерным рискам этого языка. На практике безопасность зависит от архитектуры, качества проверок, используемых системных вызовов, библиотек, скорости выпуска исправлений и своевременного обновления пакета на VDS.

Также нельзя считать любую сборку crun функционально одинаковой. Поддержка systemd, seccomp и других возможностей зависит от параметров сборки и библиотек дистрибутива. Статический бинарный файл из upstream и пакет из системного репозитория могут отличаться зависимостями и включёнными функциями. Для рабочего сервера предпочтительнее пакет, сопровождаемый поставщиком дистрибутива, если его версия и возможности отвечают требованиям.

Если для контейнерной нагрузки нужен полный административный контроль над runtime, cgroups и настройками движка, выбирайте VPS-сервер. На виртуальном хостинге пользователь обычно не может устанавливать системные пакеты, менять OCI runtime или перезапускать Docker, Podman и containerd.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

youki: OCI runtime на Rust

Youki реализует OCI Runtime Specification на Rust. Основной технический аргумент проекта — сочетание системного программирования с гарантиями безопасности памяти, предоставляемыми языком для безопасного Rust-кода. Проект также стремится снизить расход ресурсов и стоимость запуска по сравнению с традиционными реализациями.

Преимущества подхода youki

• защита от значительной части ошибок управления памятью в безопасном Rust-коде;
• модульная кодовая база из Rust crates;
• активное развитие поддержки OCI и механизмов Linux;
• rootful- и rootless-режимы;
• возможность интеграции с Docker и Podman;
• интерес для инфраструктурных команд, уже использующих Rust.

Безопасность памяти не равна полной безопасности контейнера. Runtime взаимодействует с ядром, файловой системой, namespaces, cgroups, seccomp и внешними библиотеками. Логическая ошибка, неверная проверка пути, гонка при mount-операциях или небезопасный системный интерфейс возможны независимо от языка. Rust сокращает важный класс рисков, но не отменяет аудит, обновления и ограничение привилегий.

Зрелость youki

Youki заметно моложе runc и crun, а его функциональные возможности продолжают развиваться. Это полезно для команд, которым важен Rust-стек, но означает, что отдельные функции могут меняться на уровне реализации. Историю изменений необходимо изучать перед обновлением runtime.

Статус версии ниже 1.0 не запрещает эксплуатацию, но требует осторожной политики обновлений. Администратору следует проверять не только успешный запуск простого образа, но и весь профиль рабочей нагрузки: bind mounts, read-only root filesystem, capabilities, seccomp, терминалы, сигналы, exec, лимиты ресурсов, остановку по тайм-ауту и очистку после аварии.

Совместимость с OCI: одинаковый стандарт не гарантирует одинаковое поведение

OCI Runtime Specification описывает формат конфигурации и операции жизненного цикла контейнера. В Linux-конфигурации присутствуют namespaces, mounts, устройства, capabilities, seccomp и параметры cgroups. Для cgroups v2 предусмотрено поле unified, через которое передаются параметры единой иерархии.

Все три рассматриваемых runtime стремятся реализовать OCI, но практическая совместимость не является бинарным свойством «да» или «нет». Различия могут появляться в следующих областях:

• поддерживаемая версия спецификации и недавно добавленные поля;
• проверка спорных или ошибочных значений в config.json;
• порядок выполнения OCI hooks и обработка их ошибок;
• mount options, idmapped mounts и защита от символьных ссылок;
• особенности терминала, console socket и наследования файловых дескрипторов;
• checkpoint/restore через CRIU;
• работа с systemd cgroup manager;
• поведение команд exec, kill и delete в пограничных состояниях.

Для стандартного контейнера с обычной файловой системой и сетевым сервисом разница может быть незаметна. Чем больше нестандартных mount-операций, OCI hooks и специальных требований к ядру, тем важнее интеграционное тестирование.

cgroups v2

На современной Linux VDS основной целевой режим — единая иерархия cgroups v2. runc и crun давно используются в таких конфигурациях. Youki также поддерживает cgroups v2, включая rootless-сценарии.

Однако наличие поддержки в runtime не гарантирует, что непривилегированный пользователь сможет назначать лимиты. Для rootless-режима требуется делегирование cgroup со стороны systemd или другого менеджера. На некоторых VDS пользовательский экземпляр systemd не запущен, lingering отключён либо провайдер ограничивает доступ к отдельным контроллерам.

Режим и доступные контроллеры можно проверить без изменения системы:

stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers
cat /proc/self/cgroup

Значение cgroup2fs в первой команде указывает на cgroups v2. Вторая команда показывает доступные контроллеры, но не доказывает, что все они делегированы текущему пользователю. Проверять лимиты нужно фактическим запуском контейнера с ограничениями CPU, памяти и числа процессов. Подробнее о принципах лимитов можно прочитать в материале о cgroups v2 и systemd.

Если runtime выдаёт permission denied при работе с cgroup, замена runc на crun или youki не всегда решит проблему. Причиной может быть конфигурация systemd, отсутствие пользовательской сессии, ограничения вложенной виртуализации или политика хоста.

Rootless-режим

runc, crun и youki способны запускать rootless-контейнеры, но итоговый результат зависит от всей системы. Необходимы user namespaces, диапазоны subordinate UID и GID, корректное хранилище образов, разрешённые mount-механизмы и доступная схема rootless-сети.

Runtime отвечает только за часть этой цепочки. Например, отсутствие записей пользователя в /etc/subuid и /etc/subgid нельзя исправить выбором другого OCI runtime. Аналогично runtime не включит запрещённые провайдером user namespaces и не предоставит делегирование cgroup.

Общие проверки выглядят так:

sysctl user.max_user_namespaces
id
command -v newuidmap
command -v newgidmap
grep "^$(id -un):" /etc/subuid /etc/subgid

Значимые sysctl и правила отличаются между дистрибутивами. Не следует копировать устаревшие рекомендации по включению непривилегированных user namespaces без проверки текущего ядра и политики безопасности сервера. Практические особенности такого запуска разобраны в статье о rootless Docker.

Для Podman в rootless-среде crun часто удобен благодаря тесной практической совместимости и небольшим накладным расходам. runc остаётся надёжной альтернативой. Youki можно тестировать, но после обновлений особенно важно проверять cgroup limits, bind mounts, stop-сигналы и удаление завершённых контейнеров.

Расход памяти: что действительно измерять

crun обычно рассматривают как наиболее компактный вариант, а youki также ориентируется на эффективность. Но термин «расход памяти runtime» может обозначать разные показатели:

• пиковую память бинарного файла во время create или run;
• память процесса, остающегося в контейнере как init;
• память shim, который поддерживает связь с containerd;
• суммарный расход движка, runtime и служебных процессов;
• минимальный лимит, при котором запускается тестовый контейнер.

Эти показатели нельзя смешивать. Малый пик OCI runtime полезен при массовых параллельных запусках и на VDS с жёстким лимитом RAM. Для нескольких постоянно работающих сервисов экономия может быть несопоставима с памятью базы данных, интерпретатора приложения или page cache.

Дополнительно Linux учитывает разделяемые страницы, файловый cache и анонимную память разными способами. Простое суммирование RSS процессов способно завысить реальное потребление. Для решения о миграции следует анализировать cgroup-показатели всего сервиса и пиковое использование VDS под характерной нагрузкой.

Скорость запуска

Upstream-тесты crun и youki показывают, что crun способен запускать простые контейнеры быстрее runc, а результаты youki в отдельных конфигурациях могут располагаться между ними. Такие цифры полезны для понимания потенциала, но не являются универсальным рейтингом: опубликованные тесты используют конкретные версии, ядро, аппаратную платформу и сценарий.

На практике полное время запуска включает:

1. обращение клиента к движку;
2. проверку и распаковку образа;
3. подготовку snapshot и mount points;
4. создание сетевого namespace и интерфейсов;
5. работу OCI runtime;
6. старт приложения и его собственную инициализацию.

Для веб-приложения, запускающего JVM, интерпретатор или миграции базы данных, выигрыш нескольких десятков миллисекунд на уровне runtime практически незаметен. Для функции, выполняющей /bin/true, или CI-системы с тысячами коротких задач он может быть существенным.

Сравнивать runtime нужно на одной VDS, с одним ядром, одинаковым движком, заранее загруженным образом и отключённым автоматическим обновлением контейнера. Следует отдельно измерять холодный и прогретый запуск, а также последовательный и параллельный режим. Один результат после очистки page cache не описывает обычную эксплуатацию.

Совместимость с Docker, Podman и containerd

Docker

Для Docker наиболее консервативный выбор — runc. Альтернативный OCI runtime можно зарегистрировать в конфигурации демона и выбирать параметром --runtime. Youki документирует такой вариант использования, а crun совместим с OCI-интерфейсом, но конкретное сочетание версий Docker и runtime всё равно необходимо проверять.

Не стоит сразу менять runtime по умолчанию. Сначала добавьте его под отдельным именем, запустите тестовые контейнеры и проверьте журналы. Перед изменением конфигурации Docker сохраните копию файла настроек и проверьте его синтаксис. Ошибка может помешать запуску демона и остановить все управляемые им сервисы.

Podman

Podman рассчитан на работу с OCI-совместимыми runtime и позволяет выбрать бинарный файл в конфигурации или командной строке. crun часто используется с Podman и особенно хорошо соответствует его rootless-сценариям. runc подходит, когда нужна максимальная консервативность или единообразие с Docker-хостами. Youki следует сначала подключать как дополнительный runtime, не заменяя рабочий вариант.

Фактически выбранный runtime и его путь можно увидеть в подробном выводе:

podman info --debug

Точное расположение системного и пользовательского containers.conf зависит от дистрибутива и способа установки. Перед изменением нужно изучить вывод podman info и существующие конфигурационные файлы, а не создавать настройки по случайному пути.

containerd

containerd использует Runtime v2 и shim. Стандартный io.containerd.runc.v2 вызывает containerd-shim-runc-v2, который может получить путь к OCI runtime через параметр бинарного файла. Поэтому crun или youki можно интегрировать через подходящий shim и его настройки, но формат секций зависит от поколения containerd и подключённых плагинов.

Перед изменением config.toml необходимо создать резервную копию, получить текущую конфигурацию и проверить установленные плагины:

containerd config dump
ctr plugins ls

Не следует копировать конфигурацию containerd одной основной версии в другую без проверки. Названия секций CRI и доступные параметры могут меняться. Безопаснее добавить именованный runtime, проверить его отдельно и только затем рассматривать изменение варианта по умолчанию.

Зрелость и эксплуатационный риск

По зрелости и масштабу эксплуатации runc остаётся лидером. Это не означает отсутствия уязвимостей: низкоуровневый runtime работает на чувствительной границе между конфигурацией контейнера и ядром. Преимущество заключается в широком тестировании, большом числе пользователей и быстром обнаружении несовместимостей.

crun — зрелый рабочий проект с сильной практической позицией в экосистеме containers и Podman. Его разумно использовать на production-серверах, если пакет поддерживается дистрибутивом и рабочая нагрузка прошла проверку.

Youki активно развивается и реализует основные операции OCI runtime, но его функциональная поверхность и совместимость продолжают меняться. Для production это означает необходимость закреплять проверенную версию, изучать заметки о выпусках и иметь простой откат на runc или crun.

При оценке зрелости полезно учитывать не только возраст проекта, но и следующие факторы:

• наличие пакета в репозитории используемого дистрибутива;
• регулярность security-релизов;
• подпись и проверяемость загруженных бинарных файлов;
• покрытие нужных архитектур, например amd64 или arm64;
• совместимость с текущим ядром и systemd;
• поведение при аварийном завершении и перезапуске демона;
• возможность быстро вернуть прежний runtime.

Как выбрать runtime для Linux VDS

Оставляйте runc, если

• Docker или containerd уже работают стабильно;
• контейнеры живут долго и запускаются редко;
• нет подтверждённой проблемы с памятью или скоростью создания;
• используются сложные mounts, hooks или checkpoint/restore;
• важны предсказуемые обновления из репозитория дистрибутива;
• у команды нет ресурсов на отдельную матрицу тестирования.

Выбирайте crun, если

• основным инструментом является Podman;
• на VDS активно используется rootless-режим;
• часто запускаются короткоживущие контейнеры;
• оперативная память ограничена и измерения показывают значимый выигрыш;
• пакет crun доступен и сопровождается вашим дистрибутивом;
• требуется встраивание runtime как библиотеки.

Рассматривайте youki, если

• команде принципиален Rust-стек и безопасность памяти;
• есть тестовая среда, повторяющая production;
• используется ограниченный и хорошо известный набор OCI-функций;
• можно закрепить версию и отслеживать изменения проекта;
• runc или crun остаётся доступен для быстрого отката;
• решение принимается по собственным тестам, а не только по языку разработки.

Что проверить перед заменой runtime

Сначала зафиксируйте текущие версии и сохраните конфигурацию движка. Выполняйте команды, доступные в вашем окружении:

uname -r
runc --version
crun --version
youki --version
docker info
podman info --debug
containerd --version

Команды отсутствующих программ завершатся ошибкой — это нормально. Не нужно устанавливать все три runtime на рабочий сервер только ради вывода версии.

Затем создайте набор проверок, отражающий реальные контейнеры:

1. обычный запуск и корректный exit code;
2. остановка по SIGTERM с ожидаемым тайм-аутом;
3. exec в работающий контейнер;
4. лимиты памяти, CPU и PIDs через cgroups v2;
5. rootless-запуск, если он используется;
6. bind mounts, read-only mounts и tmpfs;
7. пользователь и группы внутри контейнера;
8. capabilities и профиль seccomp;
9. перезапуск Docker или containerd при работающем контейнере;
10. очистка состояния после принудительного завершения.

На VDS дополнительно проверьте ограничения виртуализации. В полноценной виртуальной машине администратор обычно управляет собственным окружением в рамках предоставленных возможностей, тогда как в системном контейнере часть namespaces, mounts или cgroup-контроллеров может ограничиваться хостом. Ошибка runtime в таком случае не обязательно является дефектом самого проекта.

Новый runtime сначала следует назначать отдельным контейнерам. После теста проверьте журнал движка, отсутствие оставшихся процессов и каталогов состояния. Если меняется runtime по умолчанию, запланируйте окно обслуживания: уже запущенные и новые контейнеры могут управляться разными бинарными файлами, что усложняет диагностику.

Итоговая рекомендация

Для большинства Linux VDS runc остаётся оптимальной отправной точкой: он зрел, широко поддерживается и не требует обоснования специальным сценарием. Если сервер использует Podman, rootless-контейнеры или часто создаёт короткие задачи, crun является практичной альтернативой и может быть выбран по умолчанию после тестирования.

Youki нельзя считать только экспериментальной демонстрацией Rust: проект реализует OCI runtime на Rust и делает акцент на безопасности памяти и эффективности. Но по эксплуатационной зрелости он требует более внимательной проверки, закрепления версий и готового пути отката.

Универсальный порядок выбора выглядит так: runc — для минимального риска, crun — для эффективности и Podman/rootless-сред, youki — для контролируемого внедрения Rust-runtime. Окончательное решение должно подтверждаться тестом на том же ядре, движке, файловой системе и профиле контейнеров, которые используются на конкретной VDS.