РЕД ОС 8.2: тестируем как базу для нод Deckhouse и смотрим на сетевой стек

РЕД ОС 8.2 вышла на прошлой неделе. Главное в анонсе - нативная поддержка Kubernetes и обновлённые пакеты SELinux/PAM/auditd. Мы как раз искали базовую ОС для новой группы нод под Deckhouse в одном проекте, где клиент настаивает на отечественном системном слое. Совпадение по времени подходящее, поэтому сразу взяли 8.2 в тест.

Что изменилось в ядре

РЕД ОС 8.1 шла с ядром 5.15 LTS. В 8.2 перешли на 6.1 LTS. Это не просто номер версии - между ними накопилось немало существенного для нашей задачи.

Несколько наблюдений по теме сетевого стека:

• eBPF в 6.1 значительно стабильнее для задач, которые Deckhouse решает через Cilium или аналогичные CNI. В 5.15 у ряда операций с BPF-картами были ограничения по верификатору, которые в 6.1 расширены. На практике это означает, что сложные network policy применяются без workaround-ов в конфиге CNI.
• io_uring и AF_XDP - оба механизма в 6.1 получили серьёзные доработки. Для нод Kubernetes прямого значения это не имеет, но если на тех же нодах живут задачи с интенсивным сетевым вводом-выводом, разница заметна.
• Планировщик. В 6.1 CFS получил ряд улучшений для latency-чувствительной нагрузки. Для контейнерных задач с короткими интервалами изменение в целом позитивное, хотя при наших нагрузках мы пока не видели драматической разницы - скорее улучшение на уровне шума.

РЕД ОС 8.2 также обновила SELinux-политики и пакеты auditd. Это важно: при дефолтном профиле SELinux в 8.1 нам периодически приходилось добавлять кастомные контексты для volume-маунтов и cgroup-интерфейсов контейнеров. В 8.2 политики скорректированы - ряд ранее нужных вручную исключений теперь закрыт из коробки.

Как тестировали

Стенд: три ноды на серверах отечественной сборки, 10 GbE между ними. На каждой - чистая установка РЕД ОС 8.2 без дополнительных ручных патчей. Поверх - Deckhouse через стандартный инсталлятор, CNI - Cilium.

Установка прошла без проблем. Deckhouse определил ОС корректно, все preflight checks прошли. Для сравнения: на 8.1 один из preflight-ов по kernel parameters ругался на значение net.ipv4.conf.all.rp_filter - в 8.2 дефолты изменены и это прошло без касания.

Нагрузочный тест гонялся через iperf3 и внутри кластера через netperf между подами. Пропускная способность между нодами ожидаемо упирается в 10 GbE и ни в 8.1, ни в 8.2 не меняется. Интереснее latency: при сравнении p99 задержки на тех же тестовых потоках 8.2 показывала результаты немного лучше. Разрыв не огромный, но стабильный - воспроизвелось на нескольких прогонах. Точные числа приводить не будем, потому что стенд не production-железо и не репрезентативен для чужой нагрузки.

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

Честно говоря, одна вещь слегка раздражает: документация по Kubernetes в репозитории РЕД ОС пока скудная. Анонс говорит о «нативной поддержке», но под этим имеется в виду наличие пакетов kubeadm/kubelet/kubectl в репозитории дистрибутива, а не какой-то специальной интеграции. Для Deckhouse это не проблема - он привозит свои компоненты - но кто рассчитывал на готовый решённый кейс «Kubernetes из коробки», будет разочарован: это всё равно нужно настраивать руками или через инсталлятор платформы.

Ещё момент: при установке 8.2 на серверах с конкретными NIC (не буду называть вендора, чтобы не обобщать) потребовалось загрузить модуль вручную - он есть в системе, но не подтянулся автоматически. Возможно, это специфика железа, возможно - что-то в udev-правилах дистрибутива. Разобрались быстро, но заметили.

Итог на сейчас

РЕД ОС 8.2 как база для нод Deckhouse выглядит рабочим вариантом. Переход на 6.1 LTS убирает несколько неудобных граблей с SELinux и eBPF-верификатором, которые были в 8.1. Сетевой стек субъективно ведёт себя чище, хотя в реальной production-нагрузке это надо проверять на своём железе - лабораторный стенд не врёт, но и не гарантирует.

Для клиентов в managed-сопровождении, которым нужна именно отечественная ОС под ноды - 8.2 имеет смысл. До этого мы чаще смотрели в сторону Astra Linux SE, опыт с которой описывали недавно. РЕД ОС - альтернатива, особенно там, где клиент уже использует RHEL-совместимый стек и хочет минимального расхождения в пакетном менеджменте.

Пилот на нескольких production-нодах планируем в марте. Напишем по итогам, если обнаружится что-то нетривиальное.