[Документация Yandex Cloud](../../../index.md) > [Yandex Cloud Stackland](../../index.md) > Концепции > [Компоненты](overview.md) > Managed Service for Trino

# Managed Service for Trino

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

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

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

## Архитектура кластера {#architecture}

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

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

Изменение части параметров приводит к пересозданию кластера и прерыванию активных запросов. Подробнее см. в разделе [Обновление кластера](#cluster-update).

## Создание кластера {#configuration}

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

```yaml
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. См. раздел [Управление доступом](#access-control).
* `deletionProtection` — защита кластера от случайного удаления. См. раздел [Защита от удаления](#deletion-protection).

## Обновление кластера {#cluster-update}

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

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

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

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

* `spec.worker.replicas`;
* `spec.accessControl`.

## Каталоги {#catalogs}

Каталог в 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`, активные запросы прерываются. Подробнее см. в разделе [Обновление кластера](#cluster-update).

### Хранилище данных для Iceberg {#iceberg-storage}

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

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

### Аутентификация REST catalog {#iceberg-auth}

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

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

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

## Управление доступом {#access-control}

Параметр `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 подставляет `.*` (правило распространяется на все значения).

## Сетевой доступ к кластеру {#network-access}

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

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

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

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

## Версии образов {#image-catalog}

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

## Защита от удаления {#deletion-protection}

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

* По умолчанию: `false` (защита выключена).
* Включение и отключение: задается в `spec.deletionProtection` при создании или при [редактировании кластера](../../operations/trino/edit-cluster.md).
* Ограничение: защита распространяется только на ресурс `TrinoCluster`. Созданные оператором ресурсы (Pod, Service, ConfigMap, Secret) защитой не охватываются.

## Состояния кластера {#states}

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

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

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