Из чего собран Cozystack

Начнём с вопроса, который на экзамене задают чаще любого другого: что такое Cozystack по своей природе? Не «для чего он», а именно из чего сделан.

Ответ короткий: это Kubernetes, которому добавили новые типы объектов. Не форк, не надстройка над чужим API, не отдельный сервер управления. Когда вы просите платформу завести базу данных, вы создаёте объект — такой же, как под или сервис, только называется он Postgres. Дальше за ним следит программа-оператор и делает всё остальное.

Это стоит уложить в голове до всего прочего, потому что из этого следует почти всё остальное. Работает kubectl? Работает. Работает Terraform? Работает. Права раздаются обычным RBAC? Да, обычным.

Три слоя

Платформа собрана из трёх этажей, и путать их порядок — самая частая ошибка на экзамене.

Talos Linux — операционная система узлов (node OS). Её особенность в том, что у неё нет командной строки: ни SSH, ни консоли, ни пакетного менеджера. Настраивается она декларативно, через свой API: вы отправляете описание желаемого состояния, узел приводит себя к нему. Корневая файловая система при этом только для чтения.

Для администратора, привыкшего зайти на сервер и что-нибудь поправить, это поначалу неуютно. Смысл в другом: если зайти и поправить нельзя, то и состояние узла не расползается со временем. Два узла, собранные по одному описанию, останутся одинаковыми через год.

Ставят при этом не стоковый Talos, а собственный образ платформы: в него добавлены модули ядра DRBD — на нём держится репликация LINSTOR — и ZFS. В обычном образе их нет.

Kubernetes — управляющий кластер (management cluster), который работает поверх Talos. Обычный, не переделанный: тот же API, те же контроллеры.

Здесь легко смешать два разных понятия. Управляющий кластер один — это и есть платформа. А кластеры, которые заказывают тенанты (tenant clusters), — уже её продукт: их управляющий слой работает подами внутри управляющего кластера.

Cozystack — набор компонентов, устанавливаемых в этот кластер. Именно они добавляют новые типы объектов и следят за ними.

Установка в три этапа

Экзамен спрашивает не команды, а порядок и смысл этапов.

1. Talos на узлах. Машины загружаются с образа платформы и получают машинное описание. Способов три: boot-to-talos — установщик пишет Talos на диск из уже запущенного Linux, загрузка с ISO и сетевая загрузка PXE. PXE держат два временных контейнера: Matchbox отдаёт образ по HTTP, dnsmasq раздаёт DHCP и TFTP.
2. Kubernetes. Из этих узлов собирается управляющий кластер. Рекомендованный инструмент — Talm, собственный менеджер конфигураций Talos с шаблонами в духе Helm.
3. Cozystack. В кластер ставится сама платформа, дальше она разворачивает свои компоненты сама. Ставят её чартом cozy-installer в пространство имён cozy-system, а затем применяют один YAML — Platform Package. Это единственная точка настройки: домен платформы, адрес apiserver, диапазоны адресов и выбранный вариант установки.

Третий этап устроен любопытно: платформа не устанавливает компоненты по списку, а описывает желаемый состав и передаёт его FluxCD. Дальше Flux сам приводит кластер к описанию и продолжает следить, чтобы состав не расходился. Обновление платформы — это смена версии в описании, а не пересборка руками.

Каждый компонент платформы Flux ставит отдельным релизом — объект называется HelmRelease, в командах сокращается до hr. Поэтому вопрос «встала ли платформа» — это вопрос о релизах, а не о подах:

kubectl get hr -A

Все в состоянии READY True — установка завершена.

Четыре варианта установки

Платформу ставят не целиком, а одним из четырёх наборов. Названия надо знать дословно — и вот почему это не придирка: в версии 1.5 их переименовали, а старые имена (paas-full, distro-full и подобные) остались жить в чужих статьях. Перепутать легко.

Запомнить проще через одну фразу: isp-full — всё на Talos, -generic — то же на других дистрибутивах, -hosted — только платформа, инфраструктура снизу чужая, default — с нуля и вручную.

Выбирают один раз, при установке. Сменить набор на работающей платформе — это не переключатель, а переустановка.

Вариант задаёт состав по умолчанию, а тонкая настройка идёт пакетами (package). Каждый компонент платформы — пакет с именем вида cozystack.<компонент>, и посмотреть их состояние можно одной командой:

kubectl get package

Подправить набор дают два ключа в Platform Package: bundles.enabledPackages добавляет пакеты сверх варианта, bundles.disabledPackages — убирает. Оговорка, которую спрашивают: отключать пакеты можно только до установки. С работающей платформы компонент так не снимется — убирать придётся руками через Helm.

Из чего она состоит

Компонентов много, но на экзамене спрашивают, кто за что отвечает, а не полный список. Держите в голове такую карту:

Строку про Kamaji стоит запомнить отдельно: он поднимает управляющий слой тенантских кластеров подами прямо в управляющем кластере — отдельных машин под мастера тенанту не надо.

Обратите внимание, чего в списке нет: Prometheus и Loki. Их часто подставляют в варианты ответа как ловушку — метрики и журналы здесь собирают VictoriaMetrics и VictoriaLogs.

Что нужно от железа

Цифры спрашивают дословно, так что минимальный профиль придётся выучить как есть: три узла, на каждом 8 ядер, 24 ГБ памяти и два диска — 50 ГБ системный и 256 ГБ под данные. Два диска здесь не прихоть: второй отдаётся под LINSTOR. Меньше трёх узлов не даёт отказоустойчивости ни хранилищу, ни управляющему слою.

Сеть нормирована не слабее: все узлы в одном сегменте L2, задержка между ними — меньше 10 мс по времени обращения (RTT).

Если узлы сами виртуальные — стенд в vSphere или Proxmox, — включите вложенную виртуализацию и проброс флагов процессора. На железе это не нужно. Домашний стенд по этому минимуму — законный способ пройти весь getting-started целиком.

Платформа собрана. Дальше её надо между кем-то поделить — этим и займётся следующий урок.

Подробнее: обзор платформы · установка · первые шаги