Администрирование

Kata Containers 4.0 меняет runtime по умолчанию: как проверить кластер до обновления

Дмитрий Потоцкий 1 мин чтения
Kata Containers 4.0 меняет runtime по умолчанию: как проверить кластер до обновления

В июле ты обновляешь Kata Containers и получаешь другой runtime по умолчанию: вместо Go-реализации — runtime-rs. Старый runtime останется в поставке, но смена дефолта затронет новые установки и конфигурации, которые не закрепляют обработчик явно.

До релиза нужно проверить каждый пул нод: RuntimeClass, VMM, архитектуру процессоров и GPU passthrough. На выходе будет одно из трёх решений — перевести пул на runtime-rs, оставить на Go или отложить обновление.

Go-рантайм останется, но развивать его перестанут

Kata Containers 4.0.0 завершает переход проекта к Rust-first архитектуре. runtime-rs станет рантаймом по умолчанию, а Go-реализация получит статус deprecated.

Deprecated здесь не означает «удалён». После выхода 4.0 разработчики продолжат принимать исправления ошибок и уязвимостей для Go-рантайма, но перестанут добавлять в него функции.

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

Сначала проверь, где runtime задан явно:

kubectl get runtimeclass
kubectl get runtimeclass -o yaml

Затем найди поды, которые выбирают RuntimeClass:

kubectl get pods -A \
 -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RUNTIMECLASS:.spec.runtimeClassName'

Пустое поле не доказывает, что под использует Go или Rust. Оно показывает, что выбор делает конфигурация CRI на ноде. Её и нужно сопоставить с настройками RuntimeClass перед обновлением.

Первый фильтр — VMM и архитектура нод

runtime-rs поддерживает QEMU, Cloud Hypervisor, Firecracker и Dragonball. В список архитектур входят ARM64, x86_64, IBM s390x и IBM PowerPC; поддержка RISC-V пока экспериментальная.

Сними фактическую архитектуру по всем нодам:

kubectl get nodes \
 -o custom-columns='NODE:.metadata.name,ARCH:.status.nodeInfo.architecture,RUNTIME:.status.nodeInfo.containerRuntimeVersion'

VMM придётся проверить на самих нодах или в конфигурации Kata. Например, для containerd:

sudo grep -R -nE 'runtime_type|configuration|hypervisor' \
 /etc/containerd /etc/kata-containers 2>/dev/null

Если пул работает на одном из четырёх заявленных VMM и поддерживаемой архитектуре, его можно включать в тест. Это только входной фильтр: совпавшие названия не подтверждают работу сети, томов, устройств и lifecycle hooks.

Kubernetes и Docker совместимы с Rust-рантаймом. Установить его можно из исходников или через kata-deploy. Для проверки не нужен новый оркестратор — достаточно отдельного пула нод в существующем кластере.

GPU-пулы требуют отдельного допуска

Оба runtime поддерживают NVIDIA GPU passthrough при использовании QEMU. Из этого нельзя вывести поддержку прежней GPU-конфигурации с Firecracker, Cloud Hypervisor или Dragonball.

Не смешивай GPU-пулы с обычными worker-нодами в одном результате теста. Даже если образы и сеть проходят одинаково, доступ к устройствам создаёт отдельную точку отказа.

Запусти на тестовом пуле ту же GPU-нагрузку, которая работает в продакшене. Проверяй не только обнаружение устройства внутри гостя, но и полный сценарий: инициализацию драйвера, выполнение задачи, завершение пода и повторный запуск на другой ноде.

Если текущая схема GPU passthrough зависит не от QEMU, зафиксируй это как блокер. Анонс 4.0 не даёт оснований считать остальные VMM взаимозаменяемыми для NVIDIA-нагрузок.

Заявления о памяти и cold start нужно перемерить

Разработчики связывают Rust-реализацию с меньшим потреблением памяти, улучшенной безопасностью и более низкой задержкой запуска. В опубликованном превью нет конфигурации стенда и абсолютных результатов, по которым можно рассчитать эффект для твоего кластера.

Сравнивай runtime-rs со своим Go-baseline. Возьми одинаковые ноды, образы, лимиты ресурсов, VMM и версии гостевого ядра. Иначе разницу между runtime и окружением не отделить.

Для каждого класса нагрузки прогони:

  • cold start от создания пода до Ready;
  • память ноды до запуска и после выхода на steady state;
  • последовательный и случайный дисковый I/O;
  • сетевой throughput и задержку;
  • удаление, повторный запуск и эвакуацию пода;
  • подключение PVC, Secret, ConfigMap и service account;
  • GPU-задачу через QEMU — для пулов с NVIDIA.

Сохраняй сырые результаты, а не только среднее. Один зависший старт из 100 может быть важнее выигрыша в медиане, если SLO ограничивает p99.

Миграцию стоит закончить до июльского релиза

По плану проекта Kata Containers 3.30.0 должна выйти в мае, 3.31.0 — в июне, 4.0.0 — в июле. Значит, проверку можно провести на текущем кластере до смены дефолта.

Выдели тестовый пул и поставь runtime-rs через kata-deploy. Создай для него отдельный RuntimeClass, не меняя обработчик у рабочих подов. Затем перенеси копии нагрузок по одной: stateless, PVC, сетевые политики, рестарты, GPU.

Не переключай RuntimeClass всего кластера одним коммитом. Разные пулы могут зависеть от разных VMM, архитектур и устройств, поэтому им нужны отдельные решения.

Пул допускается на runtime-rs, если выполнены четыре условия:

  1. VMM и архитектура входят в заявленную матрицу поддержки.
  2. Образы, сеть, хранилище и lifecycle-сценарии прошли на тестовом пуле.
  3. Cold start, память и I/O укладываются в твой SLO.
  4. Для NVIDIA-пула отдельно прошёл passthrough через QEMU.

Если тест провалился, оставь этот пул на Go-рантайме и запиши точную несовместимость: образ, VMM, устройство, шаг воспроизведения и лог. После выхода 4.0 Go-реализация продолжит получать исправления ошибок и уязвимостей, а удалить её могут не раньше 5.0.0. Это даст время исправить конкретный блокер, не задерживая миграцию остальных нод.

Похожие материалы