Привет!

На связи Ваня Гулаков, DevOps из CloudMTS. Сегодня хочу рассказать про контейнерные ОС и как мы искали для сервиса Managed Kubernetes ту самую.

До недавнего времени мы использовали дедушку CentOS 7, который уже давно отжил свое. Основные причины переезда, соответственно, старое ядро и отсутствие поддержки. 

Раз уж переезд был неизбежен, появилась мысль присмотреться к так называемым Linux For Containers или Container Optimized OS дистрибутивам. 

Чем контейнерные ОС отличаются от обычных?

• Ориентация на работу в облачном окружении. В комплект поставки сразу входит система инициализации cloud-init/ignition. Подразумевается, что конфигурация ОС будет идти через нее.

• Образ ОС максимально «выпотрошен». Виртуальные машины из него максимально тонкие. При этом на борту уже установлен container runtime, благодаря чему можно сразу стартовать и запускать контейнеры.

• Вместе с «лишними» пакетами под нож уходит и пакетный менеджер. Обновление компонентов происходит по концепции immutable infrastructure. Запуск отладочных приложений рекомендуется делать в виде привилегированных контейнеров.

• Read-only корневой файловой системы ОС разной степени тяжести. Может распространяться как на часть системных разделов, так и почти на весь диск. Подразумевается, что это снижает поверхность атаки для злоумышленника.

• Часть дистрибутивов вообще ориентирована строго на запуск Kubernetes и управляется через API, что довольно необычно по сравнению с классическими Linux-системами.

Теперь бегло пробежимся по основным кандидатам, которых мы рассматривали. Список далеко не полный, сюда попали те дистрибутивы, которые, наверное, наиболее на слуху.

RancherOS

RancherOS интересный концепт дистрибутива, где init-процессом является не привычный для пользователей linux-супервизор вроде systemd, а Docker. Грубо говоря, реализовано это с помощью механизма DinD.

Rancher описывают свою архитектуру так:

есть так называемый system docker, в котором запущены минимально необходимые для работы системы компоненты, и, собственно, user docker. Благодаря этому достигается необходимая изоляция — user docker живет в другом наборе пространств имен.

Менеджмент системы осуществляется с помощью cloud-init и cli утилиты ros, поставляемой внутри образа ОС.

От кандидата отказались по следующим причинам:

• EOL в 2021 году, обновления выпускаются сугубо на критические уязвимости.

• Запуск Kubernetes подразумевается с помощью Rancher или утилиты rke, что не совместимо с текущей схемой работы наших управляющих сервисов Managed Kubernetes.

K3os

K3os еще один дистрибутив от Rancher. Его главное назначение — запуск кластеров k3s — легковесной версии Kubernetes, в которой все основные компоненты control-plane упакованы в единый бинарный файл. Init-процессом тут вместо Docker является сразу k3s. Менеджмент ОС — через kubectl и cloud-init.

Так как дистрибутив нацелен на запуск урезанного Kubernetes в ограниченных по ресурсам окружениях, не рассматривали его в качестве замены.

AWS Bottlerocket

Bottlerocket — контейнерная ОС от AWS. 

Из особенностей:

• Вырезаны командные оболочки, управление ОС идет через API либо так называемый control container.

• Почти все разделы на системном диске read-only. Обновляется через подгрузку дистрибутива целиком на отдельную партицию и последующим переключением на нее. Реализовано это с помощью фреймворка TUF. Присутствуют механизмы автоматического и ручного (через API-вызов) отката назад.

• Правильно приготовленный (так написано в документации) selinux из коробки. Авторы проекта утверждают, что безопасность для них цель № 1.

• Плотная завязка на инфраструктуру AWS. Присутствуют управляющие контейнеры для интеграции с облаком.

Навскидку дистрибутив выглядит очень перспективно. От пилота отказались по двум причинам — это ориентация на AWS и довольно сильно отличающийся от классического менеджмент ОС через toml-файлы + API-клиент. Слишком дорого бы встало переписывать сервисы под это дело.

Talos OS

Talos OS — очень похожий на предыдущего пациент. Еще более плотная ориентация на Kubernetes. Кажется, что больше нигде его и не используют.

Особенности:

• Авторы пошли еще дальше и не только порезали командные оболочки и условно спрятали ssh-демона в контейнер. Управление осуществляется только через gRCP API и больше никак. Внутрь экземпляра ОС попасть нельзя.

• Обновления, соответственно, тоже иммутабельные. Системные read-only-разделы в наличии.

• Файлы конфигурации системы в yaml, собственный формат, не cloud-init.

• Продвинутая консольная утилита управления talosctl. С помощью нее можно не только что-то сделать с ОС, но и сразу забутстрапить k8s-кластер.

А теперь о том, что не понравилось. Довольно схожая ситуация с Bottlerocket — слишком отличный от привычного концепт ОС, необходимо учиться дебажить систему и переделывать управляющие сервисы. Был и еще момент, на который жаловались коллеги из ИБ. Для того чтобы подгрузить какие-то модули в ядро, необходимо целиком пересобирать образ ОС, что довольно трудозатратно.

LinuxKit

Бонусный контент для красноглазиков. В отличие от всех примеров выше, LinuxKit —- это не полноценная хостовая ОС, а конструктор, который позволяет разработчикам собирать свои собственные минималистичные образы операционной системы на базе Linux.

Init- система и все служебные демоны пользовательского пространства вроде sshd представляют собой контейнеры, что позволяет выгружать одни компоненты и загружать другие. C LinuxKkit можно создавать экстремально легковесные дистрибутивы с минимальным набор компонентов, необходимых для запуска контейнеров: ядро Linux, библиотеки glibc, libcontainer, контейнерный runtime и минимальный набор утилит командной строки.

Сама ОС неизменяема (только если не сконфигурированы тома с данными) и может быть запущена везде, где есть гипервизор, или на голой железке.

CoreOS: Fedora CoreOS и Flatcar Linux

Прежде чем перейдем к последним двум контейнерным ОС, небольшой исторический экскурс. Пионером в области вот этих самых container optimized linux'ов была компания CoreOS. Параллельно Red Hat пилила свой похожий дистрибутив Project Atomic. В какой-то момент красная шляпа купила данную компанию и слила наработки обеих проектов в 1 флакон. В 2020 году проект был помечен как deprecated. А дальше, в лучших традициях open source, появилось два правопреемника — Fedora CoreOS и Flatcar Container Linux. Fedora CoreOS, соответственно, связан больше с компанией Red Hat и сообществом Fedora.

Второй проект делают ребята из Kinovolk, которые еще и пилят разный тулкит непосредственно для k8s. На данный момент Kinovolk находится в составе Microsoft. Оба проекта довольно похожи по функциональности. Подробнее остановлюсь на Flatcar Linux.

Ключевые функциональные особенности Flatcar OS:

• Для конфигурации системы при старте используется не cloud-init, а собственная разработка ignition. Основные отличия следующие — ignition намертво приклеен к initrd-образу системы и отрабатывает на момент передачи управления супервизору systemd. Это позволяет делать различные низкоуровневые штуки вроде переразметки партиций и настройки systemd-юнитов непосредственно до их загрузки.

• Конфигурация ignition возможна в двух форматах — CLC и Butane. Они довольно похожи, но есть некоторые различия в функциональности. Butane новее и считается основным стандартом на данный момент. Особенности конфигурации в том, что непосредственно в ВМ доставляется машинный конфиг в формате JSON, который генерирует специальная утилита из CLC/Butane yaml-файла.

• Часть разделов системы, а если конкретнее /usr, read-only. Это уменьшает поверхность атаки, при этом не накладывает настолько сильных ограничений, как, например, в Bottlerocket.

• Командные оболочки присутствуют в полной мере.

• Есть менеджер автоматических обновлений с различными каналами (stable/beta и т. д.). Возможно их отключить полностью. Пакетный менеджер все так же отсутствует.

Почему выбрали Flatcar? У него понравились релизные каналы образов системы и приятная документация. Был и есть потенциал для использования в формате immutable infrastructure, при этом менеджмент и дебаг проблем внутри ОС остались в относительно привычном для разработчиков формате. Накладные затраты при переезде были минимальны, по сравнению с остальными ОС из списка выше. Завести первую машинку у себя на стенде получилось довольно быстро, тестовый запуск куба через kubeadm тоже не особо добавил хлопот. Свое дело сыграла и вкусовщина: CoreOS мне всегда импонировал.

Вы можете опробовать работу ОС Flatcar в сервисе Managed Kubernetes, воспользовавшись приветственным грантом на 5000 рублей.

Данная статья имеет сугубо обзорный характер для того, чтобы понять основной контекст работы с контейнерными ОС. В следующих выпусках расскажу уже о технических подробностях переезда на flatcar: c какими проблемами сталкивались при сборе ignition-конфигураций, какие есть особенности в настройке компонентов куба при работе c ro-разделами и прочие интересные штуки.

А пока поделитесь в опросе / в комментариях, с какими контейнерными ОС был опыт?