28 июля 2026 г. Sergei Ozeranskii

Kata Containers 4.0: рантайм переписали на Rust — что меняется внутри

20 июля 2026 вышел Kata Containers 4.0 (открывается в новой вкладке). Релиз мажорный: рантайм Kata переписали с Go на Rust — теперь дефолтом идёт runtime-rs, а прежний Go-рантайм объявлен устаревшим (deprecated).

Первая статья объясняла, почему каждый CI-job стоит исполнять в отдельной micro-VM (аппаратная граница вместо общего ядра). Здесь — про то, как это устроено на стороне хоста и что 4.0 меняет внутри: рантайм, модель хранилища, гарантии целостности rootfs.

Оговорка про границу: всё ниже — свойства самой технологии Kata (по официальным нотам и документации), не конфигурация tempus.build.

Что такое runtime-rs и почему это не «порт с Go»

Со стороны хоста Kata — это -рантайм: один процесс обслуживает все контейнеры одной VM и общается с container manager (containerd) через сокет. Этот контракт в 4.0 не изменился — изменилась реализация.

runtime-rs собран из отдельных крейтов с чёткими зонами ответственности (дерево src/runtime-rs/crates на теге 4.0.0):

Многоуровневая архитектура: ресурсы и гипервизоры спрятаны за общими интерфейсами. Firecracker (пунктир) — в коде runtime-rs, но не в официальном списке гипервизоров 4.0.

shim — точка входа containerd shim v2: команды start / delete / run.
service — расширяемый service-framework; сейчас в нём TaskService по протоколу containerd shim.
runtimes — обработчики: VirtContainer (дефолт, VM), LinuxContainer и WasmContainer (экспериментальные). Управляют жизненным циклом sandbox/контейнера.
resource — единый слой абстракции ресурсов: sandbox-уровень (network, share_fs) и container-уровень (rootfs, volume, cgroups, cpu_mem).
hypervisor — абстракция VMM: бэкенды qemu, ch, dragonball, firecracker, remote за общим интерфейсом; работа с устройствами вынесена в отдельный модуль.
agent — связь с гостевым kata-agent по (KataAgent).
persist — сериализация состояния sandbox на диск (state.json) для восстановления после рестарта.

Из-за такого разделения новую модель хранилища или сети добавляют в одном слое (resource или соответствующий бэкенд), и она работает на всех VMM сразу — отсюда «унифицированные» улучшения 4.0 ниже.

Чтобы не путать версии: в 3.x по умолчанию работал Go-рантайм, а runtime-rs шёл экспериментальным — его собственный README на теге 3.2.0 предупреждал «avoid using it in critical system» и что реализован в нём только встроенный Dragonball. Rust в Kata появился раньше рантайма: с v2 на него переводили ключевые компоненты (тот же kata-agent). 4.0 завершает многолетний переход: становится рантаймом по умолчанию, а Go-рантайм — deprecated (новые фичи не принимаются, исправляют только критические баги и CVE, пока рантайм не удалят).

Почему Rust — и что это даёт безопасности

Официальная мотивация Kata из релизного превью — три пункта: меньший memory footprint, выше безопасность («leveraging Rust’s memory safety to further harden the container sandbox») и производительность (ниже латентность, быстрее старт). Численных бенчмарков проект сознательно не приводит — поэтому и мы никаких цифр не называем.

Рантайм/shim — это host-side процесс, который принимает и парсит вход от недоверенной стороны: ttRPC-сообщения от агента внутри гостя, описания устройств, ответы VMM API. Memory-safety Rust (в safe-подмножестве, за счёт borrow checker и отсутствия ручного управления памятью) снимает на уровне языка целый класс багов в этом коде: use-after-free, double-free, выход за границы буфера, гонки данных. Для компонента, который разбирает недоверенный ввод, это выигрыш по поверхности атаки.

Важно не переоценить масштаб:

Rust не убирает логические баги: ошибки авторизации, валидации, TOCTOU остаются возможны.
Граница VM держится не рантаймом, а гипервизором. Memory-safety самого VMM зависит от выбора: QEMU написан на C, Cloud Hypervisor и Dragonball — на Rust. «Весь стек стал memory-safe» — неверно; безопаснее стал host-side рантайм, а не эмуляция железа.
В Rust остаются unsafe-блоки (FFI, работа с устройствами) — гарантии языка действуют только на safe-часть.

Rust снимает класс memory-corruption багов в рантайме и парсерах на хосте — ещё один слой поверх аппаратной границы, не её замена.

Хранилище: от DAX + virtio-fs к блочной модели

4.0 меняет саму модель. В Go-эпоху гостевой образ VM монтировался через /NVDIMM (/dev/pmem*), а rootfs контейнера пробрасывался через /9p. В 4.0 появляется единая блочная модель устройств (внутреннее имя BlockModern), общая для QEMU, Cloud Hypervisor и Dragonball: слои образа отдаются гостю как блочные устройства, минуя virtio-fs/9p.

Новый EROFS-snapshotter для containerd работает так:

Слои OCI-образа конвертируются в -blob’ы (read-only, сжатые).
Готовятся монтирования: RW-слой на ext4, RO-слои на EROFS и объединяющий их overlay.
Если RO-слоёв несколько, runtime-rs генерирует VMDK-дескриптор (формат twoGbMaxExtentFlat), конкатенирующий файлы слоёв в одно виртуальное блочное устройство — это и есть та самая «VMDK» из релизных нот.
Устройства цепляются к гостю через virtio-blk; внутри VM kata-agent монтирует их и собирает overlay в единый rootfs контейнера.

Ещё в блочной модели 4.0: надёжный hot-plug/unplug блочных устройств с rollback при сбое, поддержка thin-provisioning (discard/unmap, если умеет гипервизор) и улучшенный как драйвер rootfs.

У перехода к блочным устройствам есть и вторая причина — верифицируемый rootfs.

Верифицированный rootfs: dm-verity + EROFS

Раз rootfs теперь read-only блочное устройство, его целостность можно проверять криптографически. 4.0 добавляет integrity-verified rootfs через (+ GPT/VMDK), а в deployment-конфигах dm-verity включён по умолчанию.

Путь верификации rootfs: слои OCI → EROFS-blob (read-only, сжатый) → VMDK-конкатенация → virtio-blk в гостя → dm-verity считает хеши по Merkle-дереву до доверенного root hash; при совпадении rootfs монтируется только-для-чтения, при подмене данных — ошибка I/O. — Блочный RO-rootfs проверяется по Merkle-дереву dm-verity: любое расхождение с доверенным root hash — ошибка ввода-вывода, а не тихая подмена.

Механика dm-verity (по документации ядра Linux, не по нашей интерпретации):

Над блоками фиксированного размера строится Merkle-дерево хешей: лист — хеш блока данных, внутренний узел — хеш дочерних узлов.
Корень доверия — root hash; всё, что выше него, доверенным не считается.
Таргет read-only, проверка прозрачна при каждом доступе к диску.
Если хеш не сходится по дереву до корня, операция ввода-вывода завершается ошибкой — любая модификация данных обнаруживается (tamper-evidence).

EROFS дополняет это как носитель: по документации ядра это «modern, efficient, and secure read-only» ФС для неизменяемых образов — блочно-выровненная, со сжатием (LZ4, MicroLZMA, DEFLATE, Zstandard). Неизменяемая, блочная, сжатая — удобный носитель под dm-verity.

Что это даёт мультитенантному, недоверенному CI: гость не стартует с подменённым rootfs, а хост не модифицирует образ незаметно. Для supply-chain это тот же класс гарантий, что даёт подпись образа, но на уровне рантайма и в момент исполнения.

VMM: Dragonball встроенный — и что с Firecracker

Официально поддерживаемые в рантайме по умолчанию (Rust) 4.0 гипервизоры: QEMU, Cloud Hypervisor, Dragonball (архитектуры x86_64, aarch64, s390x).

Dragonball в 4.0 позиционируется как встроенный (built-in) : по README runtime-rs он «deeply integrated into shim lifecycle, eliminating IPC overhead», а по описанию сообщества — Rust-VMM (от Ant Group), исполняющийся в том же процессе, что и shim. Смысл «in-process»: нет отдельного процесса VMM → нет IPC-границы между рантаймом и гипервизором → меньше накладных расходов и одна граница процесса вместо двух.

С Firecracker сложнее — источники расходятся. В кодовой базе runtime-rs 4.0 есть и модуль (hypervisor/src/firecracker/), и конфиг (configuration-rs-fc.toml.in), и README упоминает его как внешний гипервизор. Но в разделе «Supported Hypervisors» релиза 4.0 Firecracker не перечислен — там только QEMU, Cloud Hypervisor и Dragonball. Значит, в коде он есть, а в официальном списке поддерживаемых гипервизоров 4.0 — нет; уровень его зрелости в 4.0 первоисточником не подтверждён. (Отличие от первой статьи, где Firecracker был в ряду VMM для 3.x.)

Память, сеть, VFIO, overhead

Память. Hotplug через (память добавляется работающей VM блоками, тоньше классического DIMM-hotplug); лучше memory-менеджмент на QEMU; меньше overhead на IBM Secure Execution.
Сеть. Multi-queue проброшен через все VMM (QEMU/CH/Dragonball); улучшен hot-plug сетевых интерфейсов на QEMU (в т.ч. под SR-IOV); сетевые устройства можно размещать в host network namespace при QEMU.
VFIO / passthrough. Поддержка cold-plug VFIO-устройств (устройство назначается до старта VM — проще и надёжнее hot-plug, но без динамики); s390x VFIO-AP для крипто/акселераторов IBM Z; для standalone-контейнера — автоматический CDI-based cold-plug.
Учёт overhead. Статический сайзинг sandbox теперь точнее учитывает runtime overhead. Это про Kubernetes Pod Overhead: RuntimeClass.overhead добавляется шедулером к запросам пода при бин-пэкинге, и если рантайм резервирует ресурсы иначе, чем заявленный overhead, планирование сбивается. 4.0 приводит фактический сайзинг в соответствие с учтённым overhead.

Что это значит при переходе

Go-рантайм deprecated: исправляют только критические баги и CVE, новых фич не будет. (Прогноз релизного превью — удаление «не ранее 5.0.0», но это прогноз, не обязательство.)
Для Kubernetes kata-deploy выставляет RuntimeClass = runtime-rs — рекомендуемый путь.
У runtime-rs отдельное дерево конфигов (суффикс -runtime-rs), включая варианты для CoCo/TDX/SNP/SE.
EROFS-путь требует пре-валидации (kata-deploy проверяет prerequisites), dm-verity включён в deployment-конфигах по умолчанию, EROFS-snapshotter подключается через Helm.
Тулчейн: Rust 1.95, containerd shim 0.11, ttrpc 0.9.
Релиз предупреждает про «minor differences in configuration and behavior»; поимённого списка нет — при миграции сверьтесь с docs/how-to и Limitations.md на теге 4.0.0.

Как это соотносится с нашим подходом

Мы не раскрываем версии компонентов у себя — держим стек изоляции на актуальном security-floor и обновляем при выходе исправлений класса guest→host. Но направление 4.0 совпадает с нашими принципами: memory-safe host-side рантайм (меньше класс уязвимостей у кода, который разбирает недоверенный ввод) и криптографически верифицируемый rootfs (целостность и supply-chain в момент исполнения) — оба усиливают ту же аппаратную границу между job-ами, о которой была первая статья.

Как устроены остальные слои нашей изоляции и как самостоятельно проверить образ раннера — на странице «Безопасность и изоляция».