Kubernetes-узел без SSH: как портировали Talos на ALT Linux

У «Базальт СПО» есть три способа развернуть Kubernetes на пакетной базе ALT Linux. Все они используют одни и те же образы, собранные из RPM-пакетов репозитория Sisyphus и стабильных веток p10/p11 (плюс сертифицированные ФСТЭК c10f и планируемая c11f). Отличаются режимы тем, сколько прав остаётся у контейнера и у администратора на узле.

Три режима: rootful, rootless и immutable-ОС

Rootful — обычная схема, на ней работает около 90% установок. Часть контейнеров Kubernetes (init-контейнеры, компоненты с доступом к ресурсам хоста) работает от root, и этот root совпадает с root хост-системы. Если такой контейнер примонтирует корень хоста, rm -rf удалит с узла всё. Злоумышленнику даже не нужно ничего ломать: достаточно попасть в контейнер и тихо наблюдать за системой с повышенными привилегиями.

Rootless (PodSec, Podman Security) появился в 2023 году. Root внутри контейнера отображается на обычного пользователя хоста, например с uid 453. В этом режиме можно запускать и сами компоненты control plane: kubelet, scheduler, controller-manager, etcd. Внутри контейнера они работают от root, на хосте у них права непривилегированного пользователя. Первая версия поднималась только на одном сервере внутри Docker и годилась для отладки. Через три месяца её довели до многоузловой установки стандартным kubeadm.

Альт Оркестрация — специализированная ОС, единственная задача которой — запускать Kubernetes. Она построена на Talos от Sidero Labs, и процедура развёртывания у них совпадает.

Как выглядит узел Talos

Главное свойство узла — на нём нет SSH-демона. В классической схеме на каждый узел заходят по SSH и запускают kubeadm, и этот же канал становится точкой входа для атакующего: через него он попадает прямо в хост-систему. В Talos всё управление идёт через API утилитой talosctl.

Остальные ограничения:

корневая файловая система загружается в оперативную память только для чтения, поэтому удалить или подменить системные файлы не получится даже с доступом к узлу;
пакетного менеджера нет, на узел попадают только ядро и нужные образы;
разметка диска фиксирована, администратор не выбирает разделы под /, /home и прочее;
поддерживаются Flannel, Cilium, Calico, доступ через Virtual API и Discovery-сервис, который отслеживает, какие узлы появляются в кластере и какие уходят.

Развёртывание по шагам

Узел загружается с ISO или по PXE в maintenance-режим и слушает API.
talosctl подключается к нему и командует скачать инсталлятор из сети.
Инсталлятор инициализирует узел, перезагружает его, создаёт разделы EFI, BOOT, META, STATE, EPHEMERAL и другие, записывает загрузочный образ на диск и перезагружает узел ещё раз. В EPHEMERAL хранятся и запускаются контейнеры, в BOOT лежит загрузчик.
Из двух registry подтягиваются два набора образов: системные образы Talos/Альт Оркестрации для самого узла и образы Kubernetes.
Конфигурация задаётся двумя манифестами, controlplane.yaml и worker.yaml. Каждому узлу через talosctl передаётся его роль и список extensions.
Команда bootstrap запускает синхронизацию etcd и собирает кластер. На выходе получается kubeconfig для обычного kubectl.

Минимальный образ по умолчанию не содержит драйверов NVIDIA, Btrfs, ZFS и прочего. Их добавляют через extensions, например чтобы запускать ИИ-задачи на серверах с GPU.

Что пришлось переделать при портировании

Ядро и rootfs

Ядро дистрибутива общего назначения весило около 20 МБ, у Talos — 10 МБ. После чистки всего, что не нужно Kubernetes при начальном развёртывании, и kernel hardening ALT-ядро ужали до 11 МБ. Корневая ФС: было около 200 МБ, у Talos 76 МБ, в Альт Оркестрации получилось 90–150 МБ. Этого хватает, чтобы всё влезло в фиксированные разделы.

Для talosctl, installer, imager и Kubernetes-компонентов собраны RPM-пакеты. Образы выпускаются в двух вариантах: development для внутренней проверки развёртывания и production для пользователей.

Константы, вшитые в код

В исходниках talosctl, extensions и Image Factory были жёстко прописаны адреса, имена образов и registry Sidero Labs. Их заменили на параметры: по умолчанию поведение остаётся как у оригинального Talos, но можно подставить свои значения. Большую часть этих правок приняли в upstream.

Попутно нашлось расхождение с «ванильным» Kubernetes: в собственных образах ALT бинарники лежали в /bin, а в официальных образах Kubernetes — в /usr/local/bin. При обычном развёртывании это ни на что не влияло. Ошибка всплыла только при переходе на модель Talos, и её пришлось учесть.

Extensions из одной пакетной базы

В Talos расширения собраны из разных мест: CRI копировали готовыми бинарниками с GitHub, часть компилировали из Go-исходников, часть брали из сторонних пакетов. Для быстрого старта это работает, но сертифицировать такой набор практически невозможно: происхождение каждого бинарника приходится доказывать отдельно, а исходники во многом лежат на зарубежных серверах.

В Альт Оркестрации CRI, Btrfs, ZFS, драйверы NVIDIA и остальные extensions собираются из той же пакетной базы, что и платформы c10/c11. Если платформа сертифицирована, расширения из неё наследуют сертификат.

Discovery-сервис

Оригинальный Discovery-сервис в Talos коммерческий. Его написали заново на Rust по спецификациям, не заглядывая в исходный Go-код, чтобы исключить претензии к копированию. Новый сервис распространяется под GPL.

Image Factory: образы по требованию

Image Factory — веб-сервис, который собирает артефакты под конкретную конфигурацию. Пользователь выбирает:

платформу: bare metal, виртуальная машина или облако (Azure, AWS, GCP, Yandex Cloud). Одноплатники, которые поддерживает Talos, в ALT-версии пока не поддерживаются из-за низкого спроса;
ветку (Sisyphus, p10, p11), версию и архитектуру: amd64 или arm64;
набор extensions из одного-двух десятков доступных;
параметры загрузки ядра.

Из этого набора вычисляется идентификатор схемы. Если ничего не менять, получается стандартный ID. По нему выдаются ссылки на ISO, дисковые образы, PXE-загрузчик, отдельно ядро и rootfs.

Артефакты собираются лениво. При первом запросе Factory проверяет кэш, при промахе строит образ, кладёт его в кэш и отдаёт. Повторный запрос с той же схемой, от того же или другого пользователя, обслуживается из кэша. Для 20 extensions число комбинаций исчисляется миллионами, и собрать их все заранее невозможно.

После параметризации Factory удалось развернуть в двух экземплярах. На внутреннем разработчики собирают и тестируют сборки, проверенная версия одной командой переносится на внешний. Ту же установку можно поднять у клиента. Для закрытых кластеров без доступа в интернет это важно: артефакты весят по несколько гигабайт, и собирать их удобнее внутри периметра. В свежих версиях Talos у Sidero Labs тоже появилась команда переноса между экземплярами Factory.

Локализацию интерфейса и динамическую подстановку своих образов upstream принял. Часть остальных правок по параметризации отклонили, и они остались в форке.

Как смотреть на узел без SSH

Оборотная сторона модели: администратор не может зайти на узел и посмотреть, что съело память или какой процесс завис. В talosctl около 50 команд и примерно 300 подкоманд, и держать их в голове тяжело. Для Talos существует GUI Omni, но он закрытый и его сложно купить.

Поэтому с января 2026 года разрабатывается Maestro — интерфейс поверх talosctl, встроенный в Headlamp. В нём видно, какие сервисы запущены на каждом узле, доступны их логи, можно создавать кластеры и переносить узлы между ними. Не выходя из того же окна, можно переключиться на Headlamp и посмотреть DaemonSet, ReplicaSet, поды и хранилище.

Следующий шаг — Cozystack поверх Альт Оркестрации. На уровне развёртывания Kubernetes он одинаково работает с Talos и с ALT-версией и добавляет KubeVirt для виртуальных машин, свою сеть, хранилище и мониторинг.

Что это значит для своего кластера

Если Talos уже работает в домашней лаборатории или в проде, переходить на ALT-форк ради технических возможностей незачем: процедура развёртывания и манифесты у них одинаковые. Форк нужен, когда требуется сертифицированная цепочка поставки: все бинарники из одной пакетной базы, свои registry, Image Factory внутри периметра. Лицензия при этом отличается: компоненты распространяются под MPL и GPL-3, но сам дистрибутив физические лица используют бесплатно, а организациям нужна платная лицензия.

Модель без SSH стоит опробовать в любом случае. Read-only rootfs в памяти, отсутствие пакетного менеджера и управление только через API убирают целый класс проблем: ручные правки на узлах, дрейф конфигурации, вход через SSH. Цена — придётся заранее разобраться с диагностикой через talosctl или подобрать для неё UI.