Каталог управляемых сервисов

Каталог — то, ради чего платформу обычно и берут. Вместо «поставьте нам PostgreSQL» человек открывает список и заказывает базу, как заказывают виртуалку.

Что в списке

Каталог поделён на четыре группы, и на экзамене их называют по-английски: базы данных Databases, обмен сообщениями Messaging, платформенные сервисы Platform services, сетевые сервисы Networking services.

Виртуальные машины и кластеры Kubernetes живут в той же группе API, но экзамен относит их к другим доменам — виртуализации и мультитенантности, — а не к каталогу.

Одна позиция в платформенных сервисах удивляет: Tenant — тоже приложение каталога. Вложенные тенанты именно так и создаются — администратор заказывает дочерний тенант из каталога, как заказал бы базу.

Список растёт от версии к версии, и заучивать его целиком незачем. Спрашивают другое — что все они устроены одинаково.

Один механизм на всё

Вот что стоит понять один раз и больше не возвращаться.

Вы создаёте объект. Платформа заводит на него HelmRelease, Flux разворачивает чарт — а уже из чарта приезжает оператор, который дальше и ведёт вашу базу: следит за репликацией, снимает копии, переключает главную копию при отказе.

Своих движков баз платформа не пишет — берёт известные операторы. Их имена спрашивают:

Порядок звеньев стоит запомнить именно так: оператор приезжает из чарта, а не предшествует ему.

Отсюда два практических вывода, которые попадают в вопросы. Первый: дашборд не делает ничего особенного — нажатие кнопки собирает ровно такой же объект и отправляет его в API. Второй: если сервис не поднялся, смотреть надо на HelmRelease, а не гадать по подам.

Какие типы приложений вообще есть на конкретном кластере, показывает одна команда:

kubectl api-resources | grep apps.cozystack

Результат работы платформа пишет обратно в сам объект — в status.conditions. У живого приложения там стоит Ready: True; если не стоит — дальше по цепочке, к HelmRelease.

Три пути к одному и тому же

Дашборд — форма с полями. Поля берутся из описания приложения, поэтому список параметров всегда соответствует версии платформы.

kubectl — тот же объект текстом. Этот путь важен не потому, что удобнее, а потому, что описание можно отревьюить, положить в Git и откатить. Кнопку откатить нельзя.

Terraform — для тех, у кого инфраструктура уже описана им. Официальный провайдер зовут cozystack/cozystack; имя стоит запомнить, его спрашивают.

И общее для всех трёх путей предупреждение: kubectl delete на объекте приложения сносит приложение целиком — вместе с подами и данными. Обращайтесь с этой командой так же, как с удалением базы.

Что задаётся при заказе

Набор полей у каждого сервиса свой, но три вещи есть почти всегда.

Размер (resourcesPreset) — сколько ресурсов дать. Задаётся не числами, а готовым набором вроде t1.micro или u1.medium: платформа подставляет за ним конкретные значения.

Хранилище (storageClass) — сколько места и какого класса. replicated держит несколько копий на разных узлах, local быстрее, но живёт на одном.

Пользователи и базы — платформа заводит их сама. Именно поэтому в файле схемы, который вы потом накатываете, нет команд создания базы и пользователя: они уже выполнены.

Пароли платформа генерирует сама и кладёт в секрет. В дашборде он виден на вкладке Secrets у самого приложения.

Отказоустойчивость не бесплатна

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

Здесь же живёт частая ловушка: отказоустойчивость сервиса и сохранность данных — разные вещи. Копии спасают от падения узла, но не от удалённой таблицы. Для второго нужны резервные копии, и о них отдельный урок.

Что принесла версия 1.5

Три факта из этого релиза спрашивают прямо. Шифрование клиентских подключений (TLS) появилось у четырёх сервисов: Kafka, NATS, Qdrant и PostgreSQL. Резервные копии управляемых приложений заработали из коробки — раньше администратору приходилось сначала настраивать хранилище под них. И появились ApplicationDefinition: механизм регистрирует в каталоге новый тип приложения поверх Helm-чарта, и у него сразу есть свой объект API, форма в дашборде и та же цепочка с HelmRelease. Так организации добавляют в общий каталог собственные сервисы — каталог не закрытый список.

Каталог мы прошли, но одну его позицию — виртуальные машины — стоит разобрать отдельно: у неё своя модель, и привычки из vSphere здесь подводят.

Подробнее: управляемые приложения · кластеры Kubernetes