Managed Service for Trino

Managed Service for Trino — это управляемый сервис для работы с распределенным SQL-движком Trino. Сервис упрощает развертывание и обновление кластеров Trino, обеспечивает декларативное управление каталогами источников данных и интеграцию с Identity and Access Management.

С помощью Managed Service for Trino можно:

• создавать кластеры с помощью кастомного ресурса TrinoCluster;
• подключать к кластеру внешние источники данных с помощью кастомного ресурса TrinoCatalog;
• настраивать правила доступа к каталогам, схемам, таблицам, функциям, процедурам и запросам;
• управлять версиями образов Trino с помощью кастомного ресурса TrinoImageCatalog.

Архитектура кластераАрхитектура кластера

Кластер Trino состоит из двух типов узлов:

• Координатор — единственный узел, который принимает SQL-запросы, планирует их выполнение и распределяет задачи между воркерами. Координатор также отдает Trino UI и API.
• Воркеры — узлы, которые выполняют части SQL-запросов и возвращают результаты координатору. Количество воркеров можно изменять вручную через параметр spec.worker.replicas.

Изменение части параметров приводит к пересозданию кластера и прерыванию активных запросов. Подробнее см. в разделе Обновление кластера.

Создание кластераСоздание кластера

Пример минимальной конфигурации кластера:

apiVersion: trino.stackland.yandex.cloud/v1alpha1
kind: TrinoCluster
metadata:
  name: trino-min
spec:
  version: "480"
  coordinator:
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: "1"
        memory: 2Gi
  worker:
    replicas: 1
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: "1"
        memory: 2Gi

Где:

• version — версия Trino. Допустимые значения берутся из ресурса TrinoImageCatalog, установленного оператором.
• coordinator.resources — запросы и лимиты CPU и памяти для пода координатора.
• worker.replicas — количество воркеров в кластере (минимум 1).
• worker.resources — запросы и лимиты CPU и памяти для пода воркера.

Дополнительно в spec можно задать:

• config — дополнительные настройки Trino в формате «ключ–значение». Набор допустимых ключей и значений задаётся валидационной схемой для версии Trino кластера; оператор публикует схемы в ConfigMap trino-omdb-operator-<версия> в своём пространстве имён, где можно посмотреть актуальный список. Например, ключ io.trino задаёт уровень логирования (значения DEBUG, INFO, WARN, ERROR). Ключ или значение вне схемы валидация отклонит при создании или обновлении кластера.
• accessControl — правила доступа к ресурсам Trino. См. раздел Управление доступом.
• deletionProtection — защита кластера от случайного удаления. См. раздел Защита от удаления.

Обновление кластераОбновление кластера

При изменении части параметров Managed Service for Trino пересоздает кластер: на время применения новой конфигурации кластер переходит в состояние Updating, а активные запросы прерываются.

Пересоздание кластера происходит при изменении следующих параметров ресурса TrinoCluster:

• spec.version;
• spec.coordinator.resources;
• spec.worker.resources;
• spec.config;
• любых параметров связанных ресурсов TrinoCatalog.

Без пересоздания кластера применяются изменения следующих параметров:

• spec.worker.replicas;
• spec.accessControl.

КаталогиКаталоги

Каталог в Trino — это конфигурация подключения к внешнему источнику данных. Managed Service for Trino управляет каталогами через кастомный ресурс TrinoCatalog. Один ресурс описывает один каталог и привязан к конкретному кластеру через поле spec.cluster.

Поддерживаемые типы коннекторов:

• postgresql — подключение к PostgreSQL.
• clickhouse — подключение к ClickHouse®.
• iceberg — подключение к Apache Iceberg™ через REST catalog.

Учетные данные и сертификаты каталога хранятся в Kubernetes Secrets, на которые ссылаются поля credentialsSecretRef и certificateSecretRef.

При изменении любого каталога Managed Service for Trino пересоздает кластер. На время применения новой конфигурации кластер переходит в состояние Updating, активные запросы прерываются. Подробнее см. в разделе Обновление кластера.

Хранилище данных для IcebergХранилище данных для Iceberg

Каталог Iceberg использует объектное хранилище для файлов данных. Поддерживаются два режима:

• s3 — произвольное S3-совместимое хранилище. Параметры подключения и учетные данные задаются в spec.iceberg.s3.
• stackland-storage — управляемое объектное хранилище Stackland. Параметры подключения и учетные данные оператор получает и обслуживает автоматически на основе ссылки на бакет в spec.iceberg.stacklandStorage.bucketRef. Режим доступен, только если в кластере включен компонент Object Storage.

Аутентификация REST catalogАутентификация REST catalog

REST catalog поддерживает аутентификацию OAuth2 в двух вариантах:

• Статический токен — токен хранится в Secret, на который ссылается spec.iceberg.rest.oauth2.accessTokenSecretRef.
• Client credentials — оператор обменивает идентификатор и секрет клиента на токен через сервер авторизации. Параметры задаются в spec.iceberg.rest.oauth2.clientCredentials.

Можно использовать только один способ аутентификации в одном каталоге.

Управление доступомУправление доступом

Параметр spec.accessControl ресурса TrinoCluster задает правила доступа к ресурсам Trino. Правила разделены по типу ресурса:

• catalogs — доступ к каталогам. Привилегии: all, read-only, none.
• schemas — доступ к схемам. Поле owner определяет, является ли пользователь владельцем схемы.
• tables — доступ к таблицам и отдельным столбцам. Привилегии: SELECT, INSERT, DELETE, UPDATE, OWNERSHIP, GRANT_SELECT. Можно задать фильтр по строкам и маски для столбцов.
• functions — доступ к функциям. Привилегии: EXECUTE, GRANT_EXECUTE, OWNERSHIP.
• procedures — доступ к процедурам. Привилегии: EXECUTE, GRANT_EXECUTE.
• queries — управление запросами. Привилегии: execute, view, kill. Если задано поле queryOwner, привилегию execute использовать нельзя.

Поля сопоставления (user, catalog, schema, table, function, procedure, queryOwner) задаются как регулярные выражения. Если поле не задано, Trino подставляет .* (правило распространяется на все значения).

Сетевой доступ к кластеруСетевой доступ к кластеру

После создания кластера адреса для подключения доступны в поле status.fqdn ресурса TrinoCluster:

kubectl get trinocluster <имя_кластера> -n <пространство_имен> -o jsonpath='{.status.fqdn}'

Структура ответа:

• external — FQDN координатора для подключения через клиенты Trino (CLI, JDBC).
• webUI — FQDN для доступа к Trino UI.

Версии образовВерсии образов

Список доступных версий Trino определяется ресурсом TrinoImageCatalog. Оператор создает его автоматически при установке компонента. Версия, заданная в spec.version ресурса TrinoCluster, должна присутствовать в TrinoImageCatalog — иначе валидация отклонит создание или обновление кластера.

Защита от удаленияЗащита от удаления

Параметр spec.deletionProtection в ресурсе TrinoCluster предотвращает случайное удаление кластера через API Kubernetes. При включенной защите (spec.deletionProtection: true) оператор отклоняет удаление ресурса; команда kubectl delete и удаление через консоль управления не выполнятся, пока защита не будет отключена.

• По умолчанию: false (защита выключена).
• Включение и отключение: задается в spec.deletionProtection при создании или при редактировании кластера.
• Ограничение: защита распространяется только на ресурс TrinoCluster. Созданные оператором ресурсы (Pod, Service, ConfigMap, Secret) защитой не охватываются.

Состояния кластераСостояния кластера

Текущее состояние кластера отображается в поле status.state ресурса TrinoCluster. Допустимые значения:

• Running — кластер работает, все узлы готовы.
• Updating — оператор применяет новую конфигурацию (изменены воркеры, координатор или каталоги).
• Warning — кластер работает, но есть некритичные ошибки. Подробности — в status.conditions.
• Failed — кластер не запустился или потерял работоспособность. Причина — в status.conditions с reason: NodesFailed.
• Deleting — кластер удаляется.

Полный список условий реконсиляции доступен в status.conditions.