Что не так с CoreOS?

13 июня 2018 Автор: Роман Татауров

В последнее время много экспериментирую с Kubernetes и одним из вопросов, которые я для себя пытаюсь разрешить это выбор «правильного» дистрибутива для запуска кластера на голом железе. Дело в том, что на сегодняшний день есть целый ряд дистрибутивов, позиционирующих себя как заточенные на построение кластеров. Одним из таких, я бы даже сказал одним из пионеров в этой области является CoreOS.

Изначально я нацелился использовать CoreOS как типа ось, специально заточенную под кластеризацию и kubernetes в частности. Собственно поглядывал в эту сторону одним глазом уже давно и вот наконец решил попробовать.

Чем она хороша?

Для начала давайте разберёмся что-же такого есть в операционной системе особенного, чтоб называть её cluster friendly? Ну должно-же быть что-то, чтобы променять дистрибутив общего назначения на CoreOS.

Предустановленный софт

Прямо из коробки у нас есть etcd, docker, rkt — т. е. основные компоненты построения любого кластера. Ну вообще слабый аргумент, ибо ставится всё это сравнительно легко на любой дистрибутив.

Менеджер перезагрузок

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

Думаю, что полезная штука.

Автоматические обновления

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

Предварительная настройка

CoreOS долгое время поддерживала традиционный для кластерных систем cloud-config — набор конфигурационных команд в YAML формате, передаваемых в систему в момент установки. Но разработчики системы пошли ещё дальше и представили свою систему — ignition, которая в сущности делает то-же самое, но имеет гораздо более широкие возможности — от создания новых пользователей, до переразбивки дисков и формирования RAID-ов.

Физически это json файл или строка или URL с JSON контентом, в котором и прописаны все директивы. Вручную его набирать нереально, ибо JSON хорош для машин, а не для людей. Поэтому есть транспилер для конвертации традиционного cloud-config YAML файла в ignition JSON.

С помощью ignition добавлять новые узла в кластер становится просто элементарно — скармливаем установщику готовый ignition файл и всё — узел сконфигурируется и поключится к кластеру сам. Ну в общем так оно в теории. Думаю на практике всё не так просто.

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

Что же с ней не так?

Ignition работает не везде

Как ни странно, один из ключевых элементов системы — ignition сходу подложил мне свинью. Как оказалось работает он на списке заранее предустановленных провайдеров. И если вы запускаете его в среде, которая ему не известна, то получите облом. Именно это я и получил пытаясь поднять тестовый кластер через Vagrant и libvirt. C Vagrant оказывается ignition работает только если в качестве провайдера использовать VirtualBox. Собственно вот доказательства https://github.com/coreos/ignition/blob/9796484de2dd06b39691c4021b6bbd8f51431d42/internal/oem/oem.go#L128 — как мы видим для Vagrant ignition использует noop.FetchConfig, что означает «не знаю откуда брать данные»

С другой стороны ignition работает под большинство основных и наиболее распространённых платформ. Конкретно моя проблема тут скорее исключение.

Обновления и софт

В CoreOS нет как такового менеджера пакетов. Оно само как-то умеет обновлять свои основные компоненты, а установить что-то дополнительно непонятно как. С одной стороны концепция дистрибутива она именно такова и есть — это просто запускалка контейнеров и ничего лишнего там быть не должно. С другой стороны образ весит почти гиг, что мягко говоря весьма не мало для дистрибутива, гордо называющего себя «легковесным».

Более того я достаточно порылся в кишках этой системы, включая сборку кастомного варианта CoreOS. И этот опыт принёс мне немало удивительных открытий. Как оказалось CoreOS основана на известном дистрибутиве Gentoo. Как человек несколько лет сидевший на ней и знающий не по наслышке, что это такое я мягко говоря удивлён. Стабильность это отнюдь не конёк Gentoo.

Ну да ладно — почему бы и нет, но я например в ходе сборки с удивлением обнаружил, что включен т. н. USE флаг usb, что означает собирать весь софт с поддержкой USB. Зачем USB на чисто серверной запускалке контейнеров мне не совсем понятно. Возможно подразумевается подключение какого-то железа типа UPS-ов.

Опять же при сборке (благодаря ошибке при сборке) обнаружил в составе дистрибутива пакет texinfo — зачем оно на кластере опять же остаётся только гадать.

Можно предположить, что сторонний софт можно установить используя Gentoo-шные ebuild-ы, но сам я не проверял.

Вообще выбор как базового дистрибутива так и набор софта лично мне не нравятся. Это субъективно, но это так.

Проблемы с Kubernetes

Собственно залез я в эту тему с CoreOS в контексте моих экспериментов с Kubernetes, а конкретно выбора дистрибутива под кластер. Вышеописанные проблемы меня не остановили и я таки решил довести дело до какого-то логического конца и установит-таки кластер на эту систему. Но и тут меня ждало некоторое разочарование.

Установку Kubernetes я проводил с помощью kubeadm. Первым начал ругаться kubelet заявивший при старте, что версия docker-а слишком новая и типа «используйте на свой страх и риск». Блин — это немного не то, чего я ожидал от стабильной системы заточенной на запуск kubernetes.

Вторым и финальным косяком стала ругань kubeadm при попытке поднять мастера — ему не понравилась текущая версия etcd. Ну и как вариант он предложил мне запустить команду с отключенным preflight check, чего я делать уже не стал, ибо в этой точке моё терпение окончательно лопнуло.

На этом месте я задумался — если операционная система сама по себе, а кластер сам по себе и в то-же время ОС отвечает за обновление ключевых компонентов кластера (docker и etcd), то о какой вообще надёжности тут можно говорить? В любой момент CoreOS обновит etcd на несовместимую с текущей версией kubernetes версию и всё — наш кластер просто развалится.

Итоги

В общем и целом CoreOS оставил какие-то смешанные чувства. С одной стороны довольно известная система продвигаемая как одно из лучших решений для kubernetes. С другой стороны очень мало информации с описанием реальных примеров внедрения kubernetes на этой системе. Плюс собственный опыт который лишь добавил опасений.

Рискну заявить, что я бы не рекомендовал использовать CoreOS для серьёзных применений как минимум с Kubernetes точно.

Это крайне субъективное мнение, но по крайней мере основанное хотя и на небольшом, но реальном опыте работа с этой системой.

WebHive