Как мы выбирали open-source контейнерную ОС для Kubernetes?
Привет!
На связи Ваня Гулаков, 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 или утилиты клуб, что не совместимо с текущей схемой работы наших управляющих сервисов 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-разделами и прочие интересные штуки.
А пока поделитесь в опросе / в комментариях, с какими контейнерными ОС был опыт?
