Configuração do Trino

ChartVersion3.0.1TypeapplicationAppVersion478

CompatibilidadeKubernetes1.32+OpenShift4.19+Rancher2.10.x+

Suporte a recursosLDAPsuportadoS3suportadoIngresssuportadoGateway APIsuportado

O que é o Trino?

O Trino é o motor de consulta SQL distribuida do TDP Kubernetes.
Ele consulta múltiplas fontes de dados com um único SQL, como ClickHouse, PostgreSQL, Hive, Iceberg, Kafka e dados em storage S3/Ozone, sem mover os dados para dentro do Trino.

O Trino não armazena dados próprios: ele é um query engine federado.
As fontes de dados são expostas por catálogos configurados no chart.

Para saber mais

Consulte Trino - Conceitos para uma visão completa da ferramenta, sua arquitetura e funcionamento.

Estrutura de valores (Helm)

Todos os valores do Trino devem ficar sob a chave tdp-trino: (alias da dependência no Chart.yaml).

Respeitar esse prefixo garante que o Helm aplique os valores no subchart correto:

tdp-trino:
  server:
    workers: 3
  service:
    port: 8080

Arquitetura coordinator-worker

O chart tdp-trino implanta um coordinator e um conjunto de workers:

Componente	Função
Coordinator	Recebe a consulta SQL, cria o plano de execução e distribui o trabalho
Workers	Executam as etapas do plano em paralelo, processando dados nas fontes externas

O coordinator é único.
Para aumentar paralelismo, ajuste tdp-trino.server.workers ou os mecanismos de autoscaling dos workers.

Visão geral

Propriedade	Valor
Chart	tdp-trino
Versão do Trino	478
Versão do Chart	3.0.1
Registry	oci://registry.tecnisys.com.br/tdp/charts/tdp-trino
AppVersion do chart	478

Páginas relacionadas

• Integrações - Trino: catálogos, conectores e dependências de fontes externas.
• Segurança - Trino: LDAP, HTTPS, certificados, Secrets e Ranger.
• Exposição externa - Trino: exposição HTTP/HTTPS via Ingress ou Gateway API.

Pré-requisitos

Antes de instalar ou customizar o chart tdp-trino, confirme:

• Kubernetes 1.32+, Red Hat OpenShift 4.19+ ou Rancher Manager 2.10.x+.
• Helm 3.2.0+.
• StorageClass disponível quando usar certificados, PVCs ou recursos que precisem de volume persistente.
• Registry OCI da Tecnisys acessível pelo ambiente de instalação.
• Requisito de CPU: Os nós workers do cluster devem suportar o conjunto de instruções x86-64-v3 (Intel Haswell 2013+ ou AMD Zen 2+). O Trino 478+ exige as extensões AVX2, BMI1, BMI2 e FMA.
• Fontes externas acessíveis a partir do namespace do Trino quando usar catálogos adicionais.
• Metrics Server e resources.requests dos workers configurados para HPA; para KEDA, KEDA instalado e Prometheus disponível com métricas JMX do Trino.
• Certificados e Secrets preparados quando usar HTTPS, LDAP ou Ranger.

Instalação

Instalação

Exemplo

helm install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-trino -n <NAMESPACE> --create-namespace

Exemplo:

helm upgrade tdp-trino oci://registry.tecnisys.com.br/tdp/charts/tdp-trino \
  --namespace tdp-project \
  --values values.yaml

Os nomes dos recursos derivam do release Helm por padrão.
Use tdp-trino.fullnameOverride, tdp-trino.coordinatorNameOverride e tdp-trino.workerNameOverride apenas quando precisar evitar conflitos de nomes, por exemplo ao implantar múltiplos releases no mesmo namespace.

Parâmetros principais

Parâmetros principais

Parâmetro	Descrição	Padrão no chart
tdp-trino.enabled	Habilita a implantação do Trino	true
tdp-trino.image.tag	Tag da imagem Trino	478
tdp-trino.server.workers	Quantidade inicial de workers	2
tdp-trino.server.node.environment	Rótulo de ambiente do cluster Trino	environment
tdp-trino.service.type	Tipo do Service Kubernetes	ClusterIP
tdp-trino.service.port	Porta HTTP do Service	8080
tdp-trino.server.config.https.enabled	Habilita HTTPS no Trino	false
tdp-trino.server.config.authenticationType	Tipo de autenticação	""
tdp-trino.catalogs	Definições de catálogos/connectors	tpch, tpcds, memory
tdp-trino.accessControl	Configuração de controle de acesso	{}
tdp-trino.server.autoscaling.enabled	HPA para workers	true
tdp-trino.server.keda.enabled	KEDA para workers	false
tdp-trino.jmx.enabled	Habilita JMX	true
tdp-trino.serviceMonitor.enabled	Cria ServiceMonitor	false
trinoCerts.pvc.enabled	PVC para certificados	false
trinoCerts.secret.enabled	Secret com certificados	false
trinoCerts.copyJob.enabled	Job de cópia de certificados para PVC	false
TDP-Settings.gateway.ingress.enabled	Renderiza Ingress TDP	false
TDP-Settings.gateway.gatewayApi.enabled	Renderiza HTTPRoute Gateway API	false

Detalhes de configuração

Catálogos

Catálogos são a forma como o Trino registra fontes de dados externas.
Cada catálogo define um connector e as propriedades de acesso necessárias para o Trino localizar schemas, tabelas e objetos dessa fonte.

Na configuração do chart, os catálogos ficam em tdp-trino.catalogs.
Cada chave vira um catálogo no Trino e passa a ser usada nas consultas no formato catalog.schema.objeto.

O chart já traz catálogos de referência para tpch, tpcds e memory.
Em produção, adicione os catálogos necessários ao seu ambiente, como ClickHouse, PostgreSQL, Hive, Iceberg ou Kafka.

Consulte Integrações - Trino para exemplos e pré-requisitos por connector.

Recursos de CPU e memória

Workers executam o processamento das consultas e normalmente precisam de mais recursos que o coordinator.
Ajuste os valores conforme a complexidade das consultas e o volume de dados.

Parâmetro	Descrição	Padrão no chart
tdp-trino.coordinator.resources.requests.cpu	CPU reservada para o coordinator	1
tdp-trino.coordinator.resources.requests.memory	Memória reservada para o coordinator	2Gi
tdp-trino.coordinator.resources.limits.cpu	Limite de CPU do coordinator	2
tdp-trino.coordinator.resources.limits.memory	Limite de memória do coordinator	4Gi
tdp-trino.worker.resources.requests.cpu	CPU reservada para cada worker	1
tdp-trino.worker.resources.requests.memory	Memória reservada para cada worker	2Gi
tdp-trino.worker.resources.limits.cpu	Limite de CPU de cada worker	2
tdp-trino.worker.resources.limits.memory	Limite de memória de cada worker	4Gi

tdp-trino:
  coordinator:
    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "8Gi"
  worker:
    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "8Gi"

Autoscaling e observabilidade

O chart suporta HPA nativo por tdp-trino.server.autoscaling e KEDA por tdp-trino.server.keda.
Não combine HPA nativo e KEDA para os mesmos workers.

O HPA nativo (tdp-trino.server.autoscaling.enabled) e o JMX (tdp-trino.jmx.enabled) já vêm habilitados por padrão no chart, com maxReplicas: 5, targetCPUUtilizationPercentage: 50 e targetMemoryUtilizationPercentage: 80.
Para usar KEDA no lugar do HPA nativo, defina tdp-trino.server.autoscaling.enabled: false e tdp-trino.server.keda.enabled: true.

Para KEDA, o cluster deve ter KEDA instalado, Prometheus disponível com métricas JMX do Trino e tdp-trino.serviceMonitor.enabled: true quando usar Prometheus Operator.

O HPA usa métricas de CPU e memória do Kubernetes para ajustar a quantidade de workers.
O KEDA é usado quando a escala precisa responder a métricas externas; neste chart, o exemplo usa Prometheus consultando métricas JMX do Trino.
O JMX expõe métricas internas do Trino e o ServiceMonitor orienta o Prometheus Operator a coletá-las.

Exemplo de HPA:

tdp-trino:
  server:
    workers: 2
    autoscaling:
      enabled: true
      maxReplicas: 10
      targetCPUUtilizationPercentage: 70
      targetMemoryUtilizationPercentage: 80
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 300
        scaleUp:
          stabilizationWindowSeconds: 0

  worker:
    resources:
      requests:
        cpu: "2"
        memory: "8Gi"
      limits:
        cpu: "4"
        memory: "16Gi"

Exemplo de KEDA:

tdp-trino:
  server:
    autoscaling:
      enabled: false

    keda:
      enabled: true
      pollingInterval: 30
      cooldownPeriod: 300
      minReplicaCount: 1
      maxReplicaCount: 10
      triggers:
        - type: prometheus
          metricType: Value
          metadata:
            serverAddress: "http://prometheus-server.monitoring.svc.cluster.local"
            threshold: "1"
            metricName: required_workers
            query: >-
              sum(avg_over_time(trino_execution_ClusterSizeMonitor_RequiredWorkers{
                service="tdp-trino"
              }[1m]))

  jmx:
    enabled: true
    exporter:
      enabled: true

  serviceMonitor:
    enabled: true

Acesso & Segurança

Segurança

O chart ajusta HTTPS e autenticação conforme ldap.enabled:

Modo	Comportamento
ldap.enabled: false (padrão)	Usa apenas HTTP na porta 8080, sem autenticação obrigatória, sem volumes de certificado e sem shared secrets.
ldap.enabled: true	Habilita HTTPS na porta 8443, autenticação PASSWORD, montagem de certificados, shared secrets e integração LDAP completa.

Ranger usa tdp-trino.accessControl e arquivos adicionais no coordinator, além de certificados quando o ambiente exige HTTPS.
Consulte Segurança - Trino para os exemplos completos.

Exposição externa

Ingress e Gateway API são mutuamente exclusivos, controlados por TDP-Settings.gateway.*. O Trino é exposto na porta 8080 (ou 8443 com HTTPS/LDAP).

Para os exemplos completos de values (Ingress e Gateway API), consulte Exposição externa.

Acesso local

kubectl -n <NAMESPACE> port-forward service/<RELEASE_NAME> 8080:8080

Com LDAP/HTTPS, use a porta 8443 conforme a configuração aplicada.

Solução de problemas

Solução de problemas

kubectl -n <NAMESPACE> get pods
kubectl -n <NAMESPACE> get svc
kubectl -n <NAMESPACE> get events --sort-by=.lastTimestamp

Desinstalação

Desinstalação

helm uninstall <RELEASE_NAME> -n <NAMESPACE>

Para a lista completa de parâmetros, consulte o values.yaml do chart ou execute helm show values para a versão instalada.