systemd 262 связывает Live Update Orchestrator, TDX и контейнеры

systemd 262-rc1 стал первым тестовым выпуском новой ветки, в котором заметная часть изменений касается не привычного управления сервисами, а сохранения состояния системы при обновлении и усиления изоляции виртуальных сред. В релизе появилась интеграция с Live Update Orchestrator, поддержка Intel TDX в systemd-vmspawn, возможность собрать systemd в единый статически связанный бинарник PID 1 и несколько изменений, рассчитанных на компактные контейнерные окружения.

На практике наиболее интересной здесь выглядит связка systemd и Live Update Orchestrator. LUO работает не как ещё один вариант systemctl restart. Это механизм обновления работающего Linux-ядра через специальный kexec-переход с сохранением выбранного состояния и отдельных ресурсов. Ядро Linux описывает LUO именно как специализированный процесс перехода от одной версии ядра к другой, при котором выбранные ресурсы могут пережить смену ядра.

Для Kubernetes это особенно любопытно на узлах, где обычный reboot означает необходимость вывести worker из эксплуатации, перераспределить нагрузку и дождаться полного запуска системы. LUO не отменяет эту процедуру для любого сценария, но меняет саму модель обновления там, где ядро и запущенные компоненты подготовлены к сохранению состояния.

systemd 262 получает собственный интерфейс для LUO сессий

В обычной конфигурации systemd знает сервис как unit и управляет его жизненным циклом. Команда systemctl restart останавливает сервис и запускает его заново. Состояние процесса при этом обычно не сохраняется: открытые файловые дескрипторы, память и внутренние структуры приложения остаются частью старого процесса.

LUO решает другую задачу. Пользовательский процесс может подготовить состояние таким образом, чтобы оно пережило переход ядра. В Linux kernel документации приведён характерный сценарий с in-memory cache: сервис помещает состояние в memfd, LUO сохраняет его при переходе на новое ядро, после чего состояние можно восстановить. Такой подход предназначен не только для виртуальных машин. Документация прямо указывает на возможность применения к контейнерам, базам данных, сетевым сервисам и другим workload.

systemd 262 добавляет для сервисных unit параметр LUOSession=. Он позволяет systemd создавать LUO-сессии для сервиса и передавать их через механизм FD Store. Это уже существенно ближе к нормальному управлению сервисами, чем ручное обращение приложения непосредственно к интерфейсу ядра.

Внутренняя реализация systemd предусматривает создание LUO-сессии для каждого настроенного LUOSession= и передачу соответствующего дескриптора сервису через FD Store, а затем через LISTEN_FDS. Сессии получают стабильные имена, сформированные на основе unit и имени сессии.

Это важная архитектурная деталь. Приложению не обязательно самостоятельно искать механизм LUO после запуска. systemd может создать сессию и передать её процессу как часть стандартной модели управления файловыми дескрипторами.

Чем LUO отличается от обычного systemctl restart

На уровне администратора разница выглядит простой, но последствия у неё серьёзные.

systemctl restart nginx означает завершение текущего процесса и запуск нового. Если процесс хранил состояние только в оперативной памяти, оно исчезает. Если состояние находится во внешнем хранилище, приложение восстанавливает его уже после нового запуска.

LUO предназначен для другой операции: обновить ядро, сохранив выбранные ресурсы пользовательского пространства. Сам механизм использует kexec-переход, поэтому это всё равно смена работающего ядра, а не магическое обновление каждого компонента без переходного этапа.

Упрощённо сравнение можно представить так:

Операция	Что происходит с сервисом	Что происходит с ядром
`systemctl restart`	Процесс останавливается и запускается заново	Остаётся прежним
`systemctl reload`	Процесс получает команду перечитать конфигурацию	Остаётся прежним
LUO	Выбранное состояние может быть передано через механизм live update	Выполняется переход на новое ядро через kexec

Отсюда следует важное ограничение. Нельзя воспринимать LUO как замену systemctl restart для всех обновлений приложений. Его главная задача связана с live update ядра и сохранением состояния, которое заранее подготовлено для такого перехода.

Если требуется просто применить новый конфигурационный файл, обычный reload останется значительно проще. Если нужно полностью перезапустить процесс после установки новой версии приложения, обычный restart тоже никуда не исчезает.

Преимущество LUO проявляется в другом месте: когда стоимость полного reboot системы слишком высока, а сервис способен сохранить критическое состояние и восстановиться после перехода ядра.

FileDescriptorStore становится частью механизма сохранения состояния

Интеграция systemd с LUO особенно интересна из-за FD Store. В systemd уже существует механизм, позволяющий сервису сохранять открытые файловые дескрипторы независимо от обычного жизненного цикла процесса.

В systemd 262 этот механизм связывается с LUO. В изменениях ветки 262 описано сохранение FD Store через kexec и возврат именованных дескрипторов после перехода, если это поддерживает ядро. На текущем этапе отдельно отмечается поддержка memfd как типа дескриптора для этого сценария.

Для сервиса это может выглядеть следующим образом:

Сервис создаёт состояние, которое должно пережить переход;
Нужные дескрипторы помещаются в FD Store systemd;
Для unit задаётся FileDescriptorStorePreserve=yes;
Через LUOSession= создаётся соответствующая LUO-сессия;
Во время live update ядро выполняет переход через kexec;
После запуска нового ядра systemd возвращает сохранённые дескрипторы сервису;
Приложение восстанавливает рабочее состояние и продолжает выполнение.

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

Именно поэтому наиболее перспективными кандидатами становятся сервисы, у которых состояние уже отделено от основного процесса или может быть компактно сохранено через файловые дескрипторы и memfd.

В Kubernetes LUO лучше рассматривать как механизм обновления узла

Для Kubernetes есть важная концептуальная поправка. LUO не является альтернативным контейнерным runtime и не заменяет Deployment, StatefulSet или DaemonSet.

Kubernetes по-прежнему управляет Pod, контролирует их состояние и решает, где должен работать контейнер. LUO находится ниже этого уровня. Его интересует операционная система worker-ноды и возможность провести обновление ядра без обычного полного reboot.

Поэтому практическая архитектура выглядит примерно так:

Kubernetes
    |
    +-- Pod / Container
    |
systemd
    |
    +-- service unit
    |      |
    |      +-- LUOSession=
    |      +-- FD Store
    |
Linux kernel
    |
    +-- Live Update Orchestrator
    |
    +-- kexec

В такой схеме systemd выступает связующим слоем между сервисом и механизмом ядра. Kubernetes продолжает отвечать за workload, systemd за локальный жизненный цикл сервисов, а LUO за подготовленный переход между версиями ядра.

Это особенно удобно для инфраструктуры, где worker-ноды нельзя просто выключать одновременно. Узел сначала выводится из обычного потока новых задач, затем существующие нагрузки либо переносятся, либо используют механизм сохранения состояния, после чего выполняется live update.

Но здесь нельзя обещать нулевую недоступность для всего кластера. Реальная непрерывность зависит от конкретного workload, сетевых соединений, состояния приложений и того, какие ресурсы поддерживает выбранный сценарий LUO. Сам kernel-документ подчёркивает, что сохраняться могут выбранные ресурсы, а устройства могут продолжать DMA-активность во время перехода.

Минимальная настройка LUOSession начинается с systemd unit

На стороне systemd конфигурация может быть достаточно компактной. Для сервиса, который действительно умеет работать с LUO, unit может содержать соответствующие параметры:

[Service]
ExecStart=/usr/local/bin/agent
LUOSession=main
FileDescriptorStorePreserve=yes
FileDescriptorStoreMax=16

Здесь LUOSession=main задаёт имя сессии, которую systemd должен создать для сервиса. FileDescriptorStorePreserve=yes разрешает сохранять FD Store при соответствующих переходах.

Однако этого недостаточно для полноценной работы. Само приложение должно уметь принять дескриптор и использовать его после перехода. В systemd-интеграции LUO дескрипторы передаются сервису через стандартный механизм активации файловых дескрипторов. В исходном коде systemd это явно связано с LISTEN_FDS и именованными FD.

Проверить unit после изменения можно обычными средствами:

systemctl daemon-reload
systemctl cat agent.service
systemctl show agent.service \
    -p LUOSession \
    -p FileDescriptorStorePreserve \
    -p FileDescriptorStoreMax

Если systemd 262-rc1 распознаёт параметры, их значения появятся в выводе systemctl show.

После этого сам сервис можно запустить штатным способом:

systemctl enable --now agent.service
systemctl status agent.service

Эти команды не запускают LUO. Они только обеспечивают обычный жизненный цикл unit. Это важное различие, потому что наличие LUOSession= ещё не означает, что systemd самостоятельно выполнит live update при каждом обновлении сервиса.

Проверять наличие поддержки LUO нужно до эксперимента

Поскольку речь идёт о первом release candidate, тестировать новую функцию разумнее на отдельной ноде. Особенно это касается Kubernetes, где ошибки на уровне PID 1 или ядра могут затронуть не один процесс, а весь worker.

Первый шаг состоит в проверке версии systemd:

systemd --version

Для тестирования нужен systemd 262-rc1 или более новый вариант ветки 262, в котором соответствующая интеграция присутствует. Phoronix указывает systemd 262-rc1 как первый тестовый выпуск новой ветки и перечисляет среди изменений LUOSession= и интеграцию с Live Update Orchestrator.

Затем проверяется наличие устройства LUO:

test -e /dev/liveupdate && echo "LUO device found"

Внутренняя логика systemd 262 при создании LUO-сессии также проверяет наличие /dev/liveupdate. Если устройство отсутствует, systemd не выдаёт сервису LUO-сессию.

Следующий шаг зависит от ядра. LUO является функцией ядра, поэтому одного обновления systemd недостаточно. Kernel должен поддерживать соответствующий механизм live update и kexec handover. Документация ядра прямо связывает LUO с kexec и сохранением состояния выбранных ресурсов.

В контейнерном окружении это особенно важно. Контейнер не имеет собственного ядра, поэтому LUO должен работать на уровне host. Обновление ядра worker-ноды потенциально затрагивает все контейнеры, размещённые на этой машине.

Для Kubernetes сначала нужен отдельный тестовый worker

Безопаснее всего начинать не с production-кластера, а с одной выделенной worker-ноды.

Ноду можно сделать недоступной для новых Pod:

kubectl cordon worker-01

Если требуется освободить её от обычных workload, используется drain:

kubectl drain worker-01 \
    --ignore-daemonsets \
    --delete-emptydir-data

После этого на узле остаются только те компоненты, которые администратор намеренно оставляет для тестирования. Это снижает количество переменных во время эксперимента.

Далее на самой ноде проверяется systemd:

systemd --version

и состояние LUO:

ls -l /dev/liveupdate

После этого устанавливается тестовый unit с LUOSession= и проверяется его запуск.

Для контейнеров есть принципиальный момент: не следует пытаться установить systemd 262-rc1 только внутри обычного прикладного контейнера и ожидать, что это даст live update host. PID 1 внутри контейнера управляет процессами контейнера, но само ядро принадлежит host. Возможность LUO для worker-ноды определяется host kernel и его системным менеджером.

Именно поэтому интереснее всего тестировать systemd 262 на самой Kubernetes-нODE, а контейнер использовать как workload, состояние которого должно корректно взаимодействовать с инфраструктурой сохранения.

LUO и systemctl решают разные проблемы

В практической эксплуатации полезно не противопоставлять эти технологии напрямую. У них разные уровни.

systemctl работает с unit и процессами:

systemctl restart agent.service

Это классический вариант. Процесс завершён, новый процесс запускается с нуля.

Для изменения конфигурации:

systemctl reload agent.service

Если приложение поддерживает reload, процесс может продолжить работу без полного завершения.

LUO начинается значительно ниже. Он нужен тогда, когда требуется перейти на другое состояние ядра и сохранить выбранное состояние системы. Linux kernel описывает механизм как специализированный kexec-based reboot, предназначенный для обновления ядра с сохранением выбранных ресурсов.

Поэтому практическое правило получается простым:

Изменился конфиг
        |
        +-- systemctl reload

Нужен новый процесс
        |
        +-- systemctl restart

Нужно обновить ядро с сохранением подготовленного состояния
        |
        +-- Live Update Orchestrator

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

Для контейнерных кластеров важнее всего состояние приложения

В Kubernetes можно добиться высокой доступности на уровне оркестратора даже без LUO. Например, несколько реплик Deployment позволяют пережить перезапуск одной ноды. Поэтому live update нужен не потому, что Kubernetes вообще не умеет переживать reboot.

Ситуация становится интереснее у stateful workload. Большие in-memory структуры, высокие требования к задержке, долгий прогрев кэша, состояние сетевых соединений и дорогая инициализация могут сделать обычный restart ощутимым.

Представим worker с сервисом, который держит в памяти несколько гигабайт подготовленных данных. При обычном reboot процесс завершается, память исчезает, а после запуска сервису приходится заново загружать данные и прогревать внутренние структуры.

При подходящем дизайне LUO состояние может быть подготовлено для сохранения. Linux kernel в качестве примера приводит именно in-memory cache, который размещается в memfd и восстанавливается после kexec-перехода.

Это уже совершенно другой профиль отказа. Вместо цепочки:

stop → reboot → boot → start → restore → warm-up

появляется:

prepare state → kexec transition → restore state → continue

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

Intel TDX расширяет тот же подход на confidential computing

Вторая заметная возможность systemd 262-rc1 связана с Intel TDX. В systemd-vmspawn добавлена поддержка Intel TDX в параметре --coco= наряду с уже поддерживаемым AMD SEV-SNP.

TDX относится к confidential computing и предназначен для создания защищённых виртуальных машин, в которых память гостя изолируется от недоверенного уровня хоста. Для инфраструктуры с виртуализированными рабочими нагрузками это означает дополнительный аппаратный уровень защиты данных гостя.

Здесь systemd выступает не как реализация TDX внутри процессора. Его задача заключается в интеграции механизма confidential computing с инструментом запуска виртуальных машин.

Запустить тестовую TDX VM через systemd-vmspawn можно в окружении, где аппаратная и программная инфраструктура действительно предоставляет TDX. Само наличие systemd 262-rc1 не создаёт TDX на машине, которая его не поддерживает.

Проверка поэтому должна начинаться с аппаратной платформы и kernel, а затем уже переходить к systemd-vmspawn.

Условная команда выглядит так:

systemd-vmspawn --coco=tdx ...

Но конкретные параметры образа, памяти, сети и диска зависят от конфигурации тестовой VM. Важно именно наличие tdx как варианта confidential computing в systemd-vmspawn, которое появилось в новой ветке.

Статический PID 1 особенно интересен для маленьких контейнеров

Ещё одно изменение systemd 262-rc1 может показаться второстепенным, хотя для контейнерных сред оно вполне практично. systemd теперь можно собрать как единый статически связанный бинарник PID 1 и executor.

Phoronix отдельно отмечает этот режим как возможность для очень маленьких контейнеров. При отсутствии unit-файлов на диске менеджер также получил встроенный базовый набор unit в памяти. Речь идёт о fallback для reboot.target, shutdown.target, systemd-poweroff.service и multi-user.target.

Для контейнеров это означает меньше зависимости от традиционной файловой структуры полноценной Linux-системы. Там, где systemd используется как PID 1 в минимальном окружении, встроенные unit позволяют системе сохранить базовую функциональность даже без полного набора unit-файлов на диске.

Это хорошо ложится на общую тенденцию к минимальным специализированным образам. Чем меньше файлов и компонентов необходимо для запуска PID 1, тем проще контролировать окружение.

При этом статический бинарник и LUO решают совершенно разные задачи. Первый уменьшает зависимости и упрощает маленькое окружение. Второй связан с сохранением состояния при live update. Они оказались в одном release candidate, но не образуют обязательную единую конфигурацию.

Что реально можно автоматизировать в кластере

Самый практичный вариант для Kubernetes состоит из нескольких независимых стадий. Нода сначала переводится в состояние, при котором новые workload на неё не назначаются. Затем проверяется готовность host к live update. После этого обновление выполняется на одном узле, а Kubernetes контролирует состояние workload.

Условный workflow:

1. cordon worker
2. drain workload при необходимости
3. проверить kernel и /dev/liveupdate
4. проверить systemd 262
5. проверить LUOSession для нужного unit
6. подготовить состояние приложения
7. выполнить live update
8. проверить systemd и сервисы
9. проверить Kubernetes node
10. uncordon worker

После восстановления узла:

kubectl get nodes
kubectl get pods -A -o wide

Затем:

kubectl uncordon worker-01

Такой процесс позволяет отделить системную операцию от Kubernetes-операции. Даже если LUO позволяет избежать традиционного полного reboot, кластер всё равно должен понимать, что node проходит через специальное окно обслуживания.

Особенно полезно автоматизировать проверки до и после операции. Например, перед обновлением скрипт может проверять наличие /dev/liveupdate, версию systemd, состояние нужного unit и доступность Kubernetes API. После обновления он проверяет те же параметры и только после успешного результата разрешает вернуть node в scheduler.

Это гораздо надёжнее, чем запускать live update сразу после установки нового kernel.

Где LUO может дать наибольший эффект

Главная выгода появляется там, где reboot является дорогой операцией не из-за нескольких секунд загрузки, а из-за последствий.

Для stateless HTTP-сервиса обычный Kubernetes rollout зачастую уже решает проблему. Реплика заменяется другой репликой, запросы перенаправляются, старая Pod завершается. В таком случае сложность LUO может не оправдывать выигрыш.

У stateful сервисов ситуация другая. Если процесс держит большой кэш, долго загружает модель или выполняет дорогостоящую инициализацию, потеря состояния превращает reboot в заметный downtime или длительный период сниженной производительности.

Ещё интереснее сценарии с виртуальными машинами. Kernel документация прямо называет cloud hypervisor одним из основных вариантов использования LUO. При этом сам framework сделан workload-agnostic и может использоваться не только в гипервизоре.

Для Kubernetes можно получить похожую экономию на инфраструктурном уровне, если host содержит workload, который сложно быстро пересоздать. Но здесь всегда нужно сравнивать стоимость внедрения LUO с альтернативой в виде обычного rolling update.

Если новая нода запускается за несколько минут, а сервис имеет несколько реплик и быстро восстанавливает состояние, LUO может оказаться избыточным. Если же восстановление занимает десятки минут из-за больших объёмов памяти и дорогого прогрева, смысл становится гораздо очевиднее.

Главный риск заключается в предположении о полной бесшовности

Название Live Update легко создаёт неправильное ожидание. Пользователь может решить, что новая версия ядра просто появляется поверх старой, а приложения вообще ничего не замечают.

На самом деле механизм намного точнее. LUO выполняет специальный переход через kexec и сохраняет именно те ресурсы, которые подготовлены и поддерживаются этим механизмом. Linux kernel отдельно указывает, что во время перехода определённые устройства могут продолжать DMA, а состояние выбранных ресурсов передаётся между версиями ядра.

Следовательно, вопрос при внедрении должен звучать не "может ли LUO обновить эту ноду без reboot", а "какое состояние этой ноды способно корректно пережить переход ядра".

Для одного приложения ответ может быть положительным. Для другого потребуется внешний state store. Для третьего понадобится обычный restart. Для четвёртого проще будет вывести Pod на соседнюю ноду.

Такая проверка должна выполняться для каждого критичного workload отдельно.

systemd 262 делает live update частью привычной модели управления

Самое интересное изменение в systemd 262-rc1 заключается не в появлении ещё одной команды администратора. Важнее то, что LUO начинает встраиваться в существующую модель unit и FD Store.

Сервис получает LUOSession= вместо необходимости полностью самостоятельно управлять интеграцией. systemd создаёт сессию, связывает её с unit и передаёт дескриптор через уже знакомую инфраструктуру. В исходном коде systemd предусмотрено сохранение LUO-сессий через FD Store и передача их обратно сервису после перехода.

Это хороший пример того, как новая функция постепенно становится частью стандартной архитектуры Linux. Администратор по-прежнему работает с unit, а разработчик сервиса получает определённый интерфейс для сохранения состояния.

Одновременно systemd 262-rc1 расширяет возможности systemd-vmspawn для Intel TDX и добавляет статическую сборку PID 1 для небольших контейнерных сред. В результате одна версия systemd движется сразу в нескольких направлениях: live update, confidential computing и более компактные окружения.

Для Kubernetes особенно интересна первая часть. Если LUO продолжит развиваться в kernel и systemd, у Linux-инфраструктуры появляется более естественный путь к обновлению host без классического полного reboot. Это может сократить стоимость обслуживания крупных кластеров, где worker-ноды обновляются постоянно.

Но технология ещё находится на стадии release candidate. Сам systemd 262-rc1 является тестовым выпуском, а план разработки ветки 262 предусматривал дальнейшие release candidate перед стабильным релизом.

Поэтому для production сейчас разумнее воспринимать LUO-интеграцию как возможность для контролируемых экспериментов, а не как универсальную замену стандартной процедуре обслуживания.

В итоге systemd 262-rc1 интересен тем, что соединяет несколько уровней Linux-инфраструктуры. Live Update Orchestrator получает интеграцию с unit через LUOSession=, FD Store становится механизмом передачи подготовленного состояния, systemd-vmspawn получает Intel TDX, а сам systemd можно собрать единым статическим бинарником для небольших контейнеров.

Для Kubernetes наиболее практичная идея выглядит достаточно конкретно: не пытаться заменить systemctl на LUO, а использовать каждый механизм на своём уровне. systemctl продолжает управлять сервисами, Kubernetes управляет Pod и node, а LUO используется для специального перехода ядра с сохранением подготовленного состояния.

Если приложение и инфраструктура действительно рассчитаны на такой переход, обновление worker-ноды перестаёт быть обычной операцией "остановить, перезагрузить, запустить". Система получает возможность перенести выбранное состояние через kexec и быстрее вернуть workload в рабочее состояние. Именно это, а не простое отсутствие команды reboot, является главным практическим смыслом интеграции LUO в systemd 262.