Комментарии 21
Подскажите, а alpine является контейнерной ОС? Если нет, чего не хватает?
алпайн хорош для докера, но вообще он вполне себе полноценный дистрибутив способный жить и на железе и в виртуалке и в контейнере (не только в докере но и в остальных)
те же что упомянуты в статье как я понимаю за пределами докер песочницы не жизнеспособны
вот вопрос поинтереснее: нельзя ли для тех же задач применить buildroot?
На первую часть вопроса коллега уже ответил ниже, отвечу на вторую.
Вариантов что использовать масса, на самом деле. Помимо buildroot в заметке написал про LinuxKit, концептуально почти тоже самое.
У такого подхода есть одна большая проблема - это банально дорого. Если в случае с вендором, взять тот же kinovolk и flatcar, который мы выбрали, предоставляются уже готовые под ключ образа + закрытие CVE, то тут придется все делать самим. Придется отдельную команду собирать только на поддержку своего микро дистрибутива.
ИМХО, если человеческих ресурсов действительно много, и хочется что-то крутое и необычное - стоит присмотреться к концепции unikernel. Пакуем свои кусочки control-plane куба и запускаем либо в гипервизоре, либо на kata-containers каких-нибудь. Где-то слышал, что в гигантах вроде Google/AWS так и делают в gke и eks.
В статье речь про ОС, для запуска контейнерного рантайма (т.е. ОС для оркестратора).
А для запуска в контейнере конечно alpine норм, но можно и scratch юзать, особенно если у вас приложение компилируется в один бинарь и не тянет кучу системных зависимостей.
Такс, а чем дебиан с убунтой не вышел лицом? На них все привычно и все работает, как надо.
Если говорить сугубо с технической точки зрения - там во-первых слишком много всего лишнего (а это накладные расходы на размер ВМки и скорость ее создания/запуска), а во вторых, опять же, immutable infrastructure, про которую сейчас из каждого утюга кричат.
И дебиан, и убунта базово подразумевают классические апдейты пакетами и полностью доступный для записи корешок диска (/ и дочерние разделы). Дистрибы из статьи это заточенные сугубо под куб (редкий кейс, что сугубо докер там использовать будут) поделки. Они и какие-то фишечки свои для упрощенного бутстрапа предоставляют, и апдейтить их подразумевается через редеплой (привет, ClusterAPI).
RO разделы, в свою очередь, дают очень весомый буст с точки зрения ИБ. На куче докладов по безопасности в кубе рассматривают кейсы, когда злоумышленник запускает некий привелигированный под, монтирует туда что-то с помощью hostpath и проводит инъекцию в конфигурацию машины. Вот такая атака тут отсекается почти полностью. Примонтировал себе хакер раздел хостовой ОС (resolv.conf там или nssswitch.conf в etc, например, подменить захотел), а писать ничего нельзя и переконфигурить тоже.
Но это все, безусловно, достаточно сложно готовить, с условной убунтой приседаний по настройке системы будет поменьше.
а какой образ использовать в рамках "защиты от санкций" ? т.е. чтобы и для минцифры/росреестра подходил, и жить на нем можно было.
Честно говоря, не особо вникал в данный вопрос, ибо пока не настолько приперло.
Чутка тыкал Астру, конкретно cloud образа для запуска ВМ на VMware. Мне лично показалось странным, что образ вроде как cloud, а cloud-init там отсутствует и как машинку сконфигурировать перед запуском - непонятно. Документации по этому поводу особо не нашел, но может и плохо искал.
С docker образами, по крайней мере с год назад, вроде были какие-то проблемы. Они выкладывались в виде тарболов, причем были весьма пухлые. Соответственно, сперва их надо импортировать в рантайм и только потом перекладывать в реджистри.
Про Alt/РедОС ничего сказать не могу, не пользовался от слова совсем.
непосредственно в ВМ доставляется машинный конфиг в формате JSON, который генерирует специальная утилита из CLC/Butane yaml-файла
Вырвал из контекста, конечно, но резануло глаз - жуть какая. Возможно для тех, кто в этом варится долго уже примелькалось ?
Ну, я тут даже особо не выдумывал ничего, авторы документации +- так же и написали в оригинале. https://www.flatcar.org/docs/latest/provisioning/cl-config/#ignition-config
Тут суть в чем - json портянка в формате ignition не пишется руками, там куча меты, разделителей и прочего. Человек составляет куда более дружелюбный конфиг в yaml формате, а потом его конвертит специальной утилитой уже в ignition.
Red Hat Enterprise Linux CoreOS (RHCOS)
CoreOS была крутой OS, использовали долгое время, крутой механизм обновлений с откатом если что-то пошло не так на последнюю рабочую версию, синхронизация времени между машинами (etcd-кластер), протестированные докер/кубер из коробки и что самое главное - долгое время это была наиболее полная дока по работе с k8s на baremetal
А прчему не посмотрели в сторону оракл линукс 7? Тот же самий ридхет, но обновляется и плбс оракли пилят новое ядро к нему
Жить ему еще год , а там глядишь и чегото появится
Да история примерно такая же как с убунтой, выше отвечал уже
https://habr.com/ru/company/cloud_mts/blog/724368/#comment_25365706
Нужно продолжение. После просмотра документации по Flatcar не стало понятнее как туда поставить куб. Гугление говорит что кто-то ставил кубеспреем. Но кака тогда работают апдейты самого флаткара? Вобщем реквестирую продолжение.
Немного некрокомментинга (пришел из последний статьи про on-premise кубики на bare-metal).
Почему выбрали Flatcar? У него понравились релизные каналы образов системы и приятная документация.
Подозреваю, что у команды накопилась большая экспертиза по использованию flatcar. Чуть-чуть вопросов:
Полет нормальный?
Вы по-прежнему довольны его документацией?
Были ли какие-то проблемы при обновлении версии с мажорки на мажорку?
P.s. пойду что ли таблетками закинусь, а то увидел flatcar и пошли вьетнамские флешбэки (даже в одну мою статью попала - история номер 2)
Как мы выбирали open-source контейнерную ОС для Kubernetes?