Versão 3.0

Exposição externa: Ingress e Gateway API

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

Objetivo da página

Esta página explica como expor interfaces HTTP/HTTPS de componentes do TDP Kubernetes para fora do cluster, usando Ingress ou Gateway API.

Os dois modelos resolvem o mesmo objetivo — publicar tráfego HTTP/HTTPS com hostname estável — mas usam recursos Kubernetes diferentes, dependem de controladores distintos e têm blocos de configuração separados nos charts TDP.

Quando expor um componente externamente

Exponha um componente quando ele precisa ser acessado por usuários, navegadores, ferramentas externas ou integrações HTTP/HTTPS fora do cluster Kubernetes — por exemplo, quando você quer um endereço estável como https://superset.empresa.com em vez de depender de comandos temporários ou portas locais.

Modo	Quando usar
Service interno (`<SERVICE_NAME>.<NAMESPACE>.svc.cluster.local`)	Comunicação entre componentes dentro do cluster
`kubectl port-forward`	Acesso temporário para teste ou diagnóstico — depende do terminal, não é compartilhado
Ingress	Exposição estável com hostname HTTP/HTTPS usando um Ingress Controller
Gateway API	Exposição estável com hostname HTTP/HTTPS usando um Gateway Controller e recurso `Gateway`

Ingress vs Gateway API

Ingress e Gateway API são alternativas para publicar tráfego HTTP/HTTPS para fora do cluster. A escolha do modo é feita no bloco TDP-Settings.gateway, mas a configuração detalhada não é igual nos dois modelos.

Aspecto	Ingress	Gateway API
Recurso Kubernetes criado	`Ingress`	`HTTPRoute` (e opcionalmente `Gateway`)
Controlador necessário	Ingress Controller (NGINX, Traefik…)	Gateway Controller (Envoy Gateway, Istio…)
Recurso de entrada no cluster	Gerenciado pelo Ingress Controller	Recurso `Gateway` (criado pelo chart ou pré-existente)
Associação ao controlador	`ingressClassName`	`gatewayApi.gatewayClassName` e `gatewayApi.parentRefs`
Hostname	`hosts[].host` ou `hostname`	`hostnames[]`
Caminhos	`paths[]`	`rules[].matches[]`
Backend	Definido pelo template do chart ou pelos paths	`backendRefs[]`
TLS	`ingress.tls` ou bloco equivalente do componente	No `Gateway` ou em `certificateRefs`

Regra de exclusividade

Use apenas um modo por componente

TDP-Settings.gateway.ingress.enabled e TDP-Settings.gateway.gatewayApi.enabled são mutuamente exclusivos.

Ingress: TDP-Settings.gateway.ingress.enabled: true e gatewayApi.enabled: false
Gateway API: TDP-Settings.gateway.gatewayApi.enabled: true e ingress.enabled: false

Nunca habilite os dois ao mesmo tempo para o mesmo componente.

Pré-requisitos

Comuns a ambos os modos:

Namespace do componente criado e chart instalado (ou arquivo de valores preparado).
DNS ou /etc/hosts apontando o hostname para o endereço do controlador de entrada.

Ingress:

Ingress Controller instalado no cluster (NGINX, Traefik ou equivalente).
ingressClassName conhecido (kubectl get ingressclass).

Gateway API:

Gateway Controller instalado no cluster.
GatewayClass disponível (kubectl get gatewayclass).
CRD gateways.gateway.networking.k8s.io instalada.

Para testes locais, adicione o hostname ao /etc/hosts:

# /etc/hosts
<CONTROLLER_IP>   <COMPONENT_HOSTNAME>

Padrão comum de configuração

A chave de controle é TDP-Settings.gateway. A estrutura detalhada varia por chart — consulte a tabela abaixo, a página de configuração do componente ou o values.yaml:

Terminal input

helm show values oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> > values-padrao.yaml

Exemplo:

Terminal input

helm show values oci://registry.tecnisys.com.br/tdp/charts/tdp-cloudbeaver > values-cloudbeaver.yaml

Ingress
Gateway API

Como funciona

No modo Ingress, o chart cria um recurso Ingress no cluster. Um Ingress Controller recebe o tráfego externo e o encaminha para o Service do componente com base no hostname e no path configurados.

Aplicar os valores

Adicione a configuração desejada ao seu arquivo de values e aplique via Helm:

Terminal input
helm upgrade --install <RELEASE_NAME> \
  oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> \
  -n <NAMESPACE> --create-namespace --timeout 10m \
  -f <VALUES_FILE>

Substitua <CHART_NAME> pelo nome do chart do componente (ex.: tdp-jupyter, tdp-airflow). O caminho OCI completo está na tabela de suporte acima ou na página de configuração do componente.

Teste local sem DNS

Se o hostname ainda não tiver entrada DNS, obtenha o IP do Ingress Controller e adicione ao /etc/hosts:

Terminal input
# Exemplo para ingress-nginx — ajuste namespace e nome do Service se diferente
kubectl get svc -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

# Adicione ao /etc/hosts (substitua pelos valores reais)
echo "<CONTROLLER_IP> <COMPONENT_HOSTNAME>" | sudo tee -a /etc/hosts

Acesse em seguida: http://<COMPONENT_HOSTNAME>

Padrão comum (Jupyter, Kafka UI, ClickHouse, Airflow)

Componentes com ingress.* top-level seguem este modelo:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  ingressClassName: <INGRESS_CLASS>
  hosts:
    - host: <COMPONENT_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
  tls: []

JupyterHub

Para sessões longas de notebook, adicione as anotações de timeout ao Ingress:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  ingressClassName: <INGRESS_CLASS>
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
  hosts:
    - host: <JUPYTER_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
  tls: []

Sem as anotações de timeout, a execução de células demoradas pode resultar em timeout do gateway (504).

Airflow

Além do Ingress, configure proxy e CORS no subchart:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  ingressClassName: <INGRESS_CLASS>
  annotations: {}
  hosts:
    - host: <AIRFLOW_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
  tls: []

tdp-airflow:
  config:
    webserver:
      base_url: "http://<AIRFLOW_HOSTNAME>"
      x_forwarded_proto: "http"
      x_forwarded_host: "<AIRFLOW_HOSTNAME>"
      x_forwarded_port: "<SERVICE_PORT>"
    api:
      cors_enabled: "True"
      cors_allow_origin: "*"

Argo CD

Usa estrutura própria em tdp-argo.server.ingress — não o bloco ingress top-level:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-argo:
  configs:
    params:
      server.insecure: "true"
    cm:
      url: http://<ARGOCD_HOSTNAME>
  server:
    ingress:
      enabled: true
      controller: generic
      hostname: <ARGOCD_HOSTNAME>
      ingressClassName: <INGRESS_CLASS>
      annotations: {}
      path: /
      pathType: Prefix

OpenShift

No OpenShift, utilize ingressClassName: openshift-default e o hostname segue o padrão de rotas do cluster:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-argo:
  configs:
    params:
      server.insecure: "true"
    cm:
      url: http://argocd-<NAMESPACE>.apps.<CLUSTER_DOMAIN>
  server:
    ingress:
      enabled: true
      controller: generic
      ingressClassName: openshift-default
      hostname: argocd-<NAMESPACE>.apps.<CLUSTER_DOMAIN>
      path: /
      pathType: Prefix
      annotations: {}

ClickHouse

Ingress expõe a interface HTTP (8123). Configure extraUsers para permitir conexões da rede do Ingress:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-clickhouse:
  clickhouse:
    extraUsers: |
      <yandex>
        <profiles>
          <default>
            <query_cache_system_table_handling>ignore</query_cache_system_table_handling>
          </default>
        </profiles>
        <users>
          <default>
            <networks>
              <ip>::/0</ip>
            </networks>
          </default>
        </users>
      </yandex>

ingress:
  ingressClassName: <INGRESS_CLASS>
  annotations: {}
  hosts:
    - host: <CLICKHOUSE_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
  tls: []

TCP nativo (porta 9000)

A porta TCP nativa do ClickHouse não pode ser exposta via Ingress. Use port-forward, LoadBalancer ou NodePort para acesso TCP.

Após a exposição, aceda às interfaces web do ClickHouse:

Play UI: http://<CLICKHOUSE_HOSTNAME>/play
Dashboard: http://<CLICKHOUSE_HOSTNAME>/dashboard

CloudBeaver

Use tdp-cloudbeaver.ingress para publicar a interface web do CloudBeaver:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-cloudbeaver:
  ingress:
    ingressClassName: <INGRESS_CLASS>
    annotations:
      nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    hosts:
      - host: <CLOUDBEAVER_HOSTNAME>
        paths:
          - path: /
            pathType: Prefix
    tls: false

Exemplos de hostname:

Kubernetes padrão: cloudbeaver.tdp.local
OpenShift: cloudbeaver-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Kafka UI

Expõe apenas a Kafka UI — não os brokers Kafka:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  ingressClassName: <INGRESS_CLASS>   # ex.: nginx, openshift-default
  annotations: {}
  hosts:
    - host: <KAFKA_UI_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
  tls: []

Exemplos de hostname:

Kubernetes padrão: kafka-ui.tdp.local
OpenShift: kafka-ui-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Kafka UI ≠ brokers Kafka

O Ingress publica a interface web da Kafka UI. Produtores e consumidores externos continuam precisando de configuração adicional para acessar os brokers (listeners Kafka), que não é coberta por Ingress/Gateway API neste chart.

NiFi

O NiFi usa ingress.rules (não ingress.hosts) como estrutura de Ingress, e requer anotações de afinidade de sessão.

Kubernetes padrão (HTTP)

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  enabled: true
  ingressClassName: <INGRESS_CLASS>
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/affinity-mode: "persistent"
    nginx.ingress.kubernetes.io/session-cookie-name: "INGRESSCOOKIE"
    nginx.ingress.kubernetes.io/session-cookie-path: "/"
  rules:
    - host: <NIFI_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: tdp-nifi-service
              port:
                number: 8080
  tls: []

Kubernetes padrão (HTTPS)

Quando nifiCluster.security.protocol: "https", altere a anotação e a porta:

ingress:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
  rules:
    - host: <NIFI_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: tdp-nifi-service
              port:
                number: 8443

OpenShift

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  enabled: true
  ingressClassName: openshift-default
  annotations:
    haproxy.router.openshift.io/balance: "cookie"
    haproxy.router.openshift.io/cookie_name: "INGRESSCOOKIE"
  rules:
    - host: nifi-<NAMESPACE>.apps.<CLUSTER_DOMAIN>
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: tdp-nifi-service
              port:
                number: 8080
  tls: []

Exemplos de hostname:

Kubernetes padrão: nifi.tdp.local
OpenShift: nifi-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Nome do ficheiro de valores

Use o nome que preferir para o ficheiro de valores de Ingress e passe com -f <VALUES_FILE>.

OpenMetadata

O OpenMetadata utiliza TDP-Settings (não TDP-Settings) e a configuração de Ingress fica sob tdp-openmetadata.ingress.* (dentro do subchart), não no ingress.* raiz.

Kubernetes padrão

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-openmetadata:
  ingress:
    className: <INGRESS_CLASS>
    annotations: {}
    hosts:
      - host: <OPENMETADATA_HOSTNAME>
        paths:
          - path: /
            pathType: Prefix
    tls: []

OpenShift

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-openmetadata:
  ingress:
    className: openshift-default
    annotations: {}
    hosts:
      - host: openmetadata-<NAMESPACE>.apps.<CLUSTER_DOMAIN>
        paths:
          - path: /
            pathType: Prefix
    tls: []

Exemplos de hostname:

Kubernetes padrão: openmetadata.tdp.local
OpenShift: openmetadata-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Ozone

O Ozone expõe quatro endpoints independentes: S3 Gateway REST, S3 Gateway Web UI, Ozone Manager UI e SCM UI. Cada endpoint tem seu próprio bloco de Ingress:

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-ozone:
  ingress:
    s3g:
      rest:
        enabled: true
        ingressClassName: <INGRESS_CLASS>
        annotations: {}
        hosts:
          - host: <OZONE_S3_REST_HOSTNAME>
            paths:
              - path: /
                pathType: Prefix
        tls: []
      web:
        enabled: true
        ingressClassName: <INGRESS_CLASS>
        annotations: {}
        hosts:
          - host: <OZONE_S3_WEB_HOSTNAME>
            paths:
              - path: /
                pathType: Prefix
        tls: []
    om:
      enabled: true
      ingressClassName: <INGRESS_CLASS>
      annotations: {}
      hosts:
        - host: <OZONE_OM_HOSTNAME>
          paths:
            - path: /
              pathType: Prefix
      tls: []
    scm:
      enabled: true
      ingressClassName: <INGRESS_CLASS>
      annotations: {}
      hosts:
        - host: <OZONE_SCM_HOSTNAME>
          paths:
            - path: /
              pathType: Prefix
      tls: []

Exemplos de hostname:

Kubernetes padrão: ozone-s3.tdp.local, ozone-s3-ui.tdp.local, ozone-om.tdp.local, ozone-scm.tdp.local
OpenShift: ozone-s3-<NAMESPACE>.apps.<CLUSTER_DOMAIN>, ozone-s3-ui-<NAMESPACE>.apps.<CLUSTER_DOMAIN>, ozone-om-<NAMESPACE>.apps.<CLUSTER_DOMAIN>, ozone-scm-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Ranger

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  ingressClassName: <INGRESS_CLASS>
  annotations: {}
  hosts:
    - host: <RANGER_HOSTNAME>
      paths:
        - path: /
          pathType: Prefix
  tls: []

Exemplos de hostname:

Kubernetes padrão: ranger.tdp.local
OpenShift: ranger-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Superset

No Superset, a configuração de Ingress fica sob tdp-superset.ingress.* (dentro do subchart), não no ingress.* raiz.

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

tdp-superset:
  ingress:
    enabled: true
    ingressClassName: <INGRESS_CLASS>
    annotations: {}
    path: /
    pathType: Prefix
    hosts:
      - <SUPERSET_HOSTNAME>
    tls: []

Exemplos de hostname:

Kubernetes padrão: superset.tdp.local
OpenShift: superset-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Trino

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

ingress:
  enabled: true
  ingressClassName: <INGRESS_CLASS>
  annotations: {}
  path: /
  pathType: Prefix
  hosts:
    - <TRINO_HOSTNAME>
  tls: []

Exemplos de hostname:

Kubernetes padrão: trino.tdp.local
OpenShift: trino-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Spark

O Spark requer parâmetros adicionais de reverse proxy para que a UI funcione corretamente via Ingress. A configuração fica em spark.ingress.* (não no ingress.* raiz).

TDP-Settings:
  gateway:
    ingress:
      enabled: true
    gatewayApi:
      enabled: false

spark:
  ingress:
    enabled: true
    ingressClassName: <INGRESS_CLASS>
    hostname: <SPARK_HOSTNAME>
    path: /
    pathType: Prefix
  master:
    configOptions: "-Dspark.ui.reverseProxy=true -Dspark.ui.reverseProxyUrl=http://<SPARK_HOSTNAME>"
  worker:
    configOptions: "-Dspark.ui.reverseProxy=true -Dspark.ui.reverseProxyUrl=http://<SPARK_HOSTNAME>"
  sparkConf:
    "spark.ui.reverseProxy": "true"
    "spark.ui.reverseProxyUrl": "http://<SPARK_HOSTNAME>"

Exemplos:

Kubernetes padrão: <INGRESS_CLASS>: nginx, <SPARK_HOSTNAME>: spark.tdp.local
OpenShift: <INGRESS_CLASS>: openshift-default, <SPARK_HOSTNAME>: spark-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

TLS com Ingress

Nos exemplos anteriores, tls: [] indica que nenhuma entrada TLS foi definida. Para habilitar HTTPS no Ingress, substitua o array vazio por uma lista no formato de spec.tls do Kubernetes:

ingress:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  tls:
    - secretName: <SECRET_NAME>
      hosts:
        - <COMPONENT_HOSTNAME>

Use o mesmo formato no bloco equivalente do componente quando o chart não usa ingress.* top-level, por exemplo tdp-ozone.ingress.s3g.rest.tls ou tdp-openmetadata.ingress.tls.

Se o Secret TLS for criado manualmente, ele deve existir no namespace do componente antes da instalação ou actualização. Com cert-manager, a anotação do Ingress solicita a emissão/renovação automática e o controlador grava o Secret indicado em secretName.

Validação

Terminal input
kubectl get ingress -n <NAMESPACE>
kubectl describe ingress <INGRESS_NAME> -n <NAMESPACE>
curl -I http://<COMPONENT_HOSTNAME>

Resolução de problemas

Problema	Diagnóstico	Solução
Ingress não criado	`kubectl get ingress -n <NAMESPACE>` não lista	Verifique `TDP-Settings.gateway.ingress.enabled: true` e reaplique o Helm
`ingressClassName` incorreto	`kubectl describe ingress` mostra eventos de erro	Execute `kubectl get ingressclass`
Hostname não resolve	`curl` falha com DNS lookup error	Configure `/etc/hosts` ou DNS para o IP do Ingress Controller
404 Not Found	Ingress criado mas retorna 404	Verifique `path` e `pathType`
502 Bad Gateway	Ingress criado mas serviço não responde	Execute `kubectl get endpoints -n <NAMESPACE>`
ClickHouse `AUTHENTICATION_FAILED`	Acesso via Ingress rejeitado	Configure `tdp-clickhouse.clickhouse.extraUsers` com `<ip>::/0</ip>`
Airflow providers não carregam	UI abre mas recursos falham	Verifique `tdp-airflow.config.webserver.base_url` e headers `x_forwarded_*`
Argo CD redirect loop	UI não carrega corretamente	Verifique `server.insecure: "true"` e `configs.cm.url`

Como funciona

No modo Gateway API, o chart cria um recurso HTTPRoute e, quando gatewayApi.gateway.enabled: true, também um recurso Gateway. Um Gateway Controller processa esses recursos e encaminha o tráfego para o Service do componente.

Aplicar os valores

Adicione a configuração desejada ao seu arquivo de values e aplique via Helm:

Terminal input
helm upgrade --install <RELEASE_NAME> \
  oci://registry.tecnisys.com.br/tdp/charts/<CHART_NAME> \
  -n <NAMESPACE> --create-namespace --timeout 10m \
  -f <VALUES_FILE>

Substitua <CHART_NAME> pelo nome do chart do componente (ex.: tdp-jupyter, tdp-airflow).

Acesso via Gateway API

Após o deploy, obtenha o IP do Gateway Controller e adicione ao /etc/hosts para teste local:

Terminal input
# Verifique o nome e namespace do Gateway criado
kubectl get gateway -A

# Obtenha o IP do LoadBalancer do Gateway Controller (ajuste namespace/nome)
kubectl get svc -n <GATEWAY_NAMESPACE> <GATEWAY_SERVICE> \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

# Adicione ao /etc/hosts (substitua pelos valores reais)
echo "<CONTROLLER_IP> <COMPONENT_HOSTNAME>" | sudo tee -a /etc/hosts

Acesse em seguida: http://<COMPONENT_HOSTNAME>

Padrão comum de Gateway API

Quando o chart cria o Gateway automaticamente, a estrutura base é:

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <COMPONENT_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
  <APPLICATION_NAME>:
    enabled: true
    hostnames:
      - <COMPONENT_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - port: <SERVICE_PORT>
    tls:
      certificateRefs: []

Substitua <APPLICATION_NAME> pela chave do chart (airflow, server, clickhouse, cloudbeaver, jupyter, kafkaUi).

Airflow

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <AIRFLOW_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
  airflow:
    enabled: true
    hostnames:
      - <AIRFLOW_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 8080
    tls:
      certificateRefs: []

tdp-airflow:
  config:
    webserver:
      base_url: "http://<AIRFLOW_HOSTNAME>"
      x_forwarded_proto: "http"
      x_forwarded_host: "<AIRFLOW_HOSTNAME>"
      x_forwarded_port: "<SERVICE_PORT>"
    api:
      cors_enabled: "True"
      cors_allow_origin: "*"

Argo CD

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

tdp-argo:
  configs:
    params:
      server.insecure: "true"
    cm:
      url: http://<ARGOCD_HOSTNAME>

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <ARGOCD_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
      namespace: <GATEWAY_NAMESPACE>
  server:
    enabled: true
    hostnames:
      - <ARGOCD_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 80
    tls:
      certificateRefs: []

ClickHouse

Requer extraUsers (mesmo requisito do Ingress):

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

tdp-clickhouse:
  clickhouse:
    extraUsers: |
      <yandex>
        <profiles>
          <default>
            <query_cache_system_table_handling>ignore</query_cache_system_table_handling>
          </default>
        </profiles>
        <users>
          <default>
            <networks>
              <ip>::/0</ip>
            </networks>
          </default>
        </users>
      </yandex>

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <CLICKHOUSE_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
  clickhouse:
    enabled: true
    hostnames:
      - <CLICKHOUSE_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 8123
    tls:
      certificateRefs: []

Após a exposição, aceda às interfaces web do ClickHouse:

Play UI: http://<CLICKHOUSE_HOSTNAME>/play
Dashboard: http://<CLICKHOUSE_HOSTNAME>/dashboard

CloudBeaver

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <CLOUDBEAVER_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
  cloudbeaver:
    enabled: true
    hostnames:
      - <CLOUDBEAVER_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 8978
    tls:
      certificateRefs: []

Jupyter (padrão comum)

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <JUPYTER_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
  jupyter:
    enabled: true
    hostnames:
      - <JUPYTER_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 80
    tls:
      certificateRefs: []

Kafka UI

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <KAFKA_UI_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
  kafkaUi:
    enabled: true
    hostnames:
      - <KAFKA_UI_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 80
    tls:
      certificateRefs: []

Kafka UI ≠ brokers Kafka

O Gateway API publica apenas a Kafka UI. Os brokers Kafka permanecem acessíveis internamente via listeners configurados no chart — não via HTTPRoute.

OpenMetadata

O OpenMetadata utiliza TDP-Settings (não TDP-Settings) para controlar o modo de exposição.
O backend opera na porta 8585 (API e interface web).

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
        hostname: <OPENMETADATA_HOSTNAME>
  parentRefs:
    - name: <GATEWAY_NAME>
  openmetadata:
    enabled: true
    hostnames:
      - <OPENMETADATA_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 8585
    tls:
      certificateRefs: []

Exemplos de hostname:

Kubernetes padrão: openmetadata.tdp.local
OpenShift: openmetadata-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

NiFi

O backend do NiFi usa a porta 8080 (HTTP) ou 8443 (HTTPS), conforme nifiCluster.security.protocol.

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  parentRefs:
    - name: <GATEWAY_NAME>
      namespace: <GATEWAY_NAMESPACE>
  nifi:
    enabled: true
    hostnames:
      - <NIFI_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 8080
    tls:
      certificateRefs: []

Nome do ficheiro de valores

Use o nome que preferir para o ficheiro de valores do Gateway API e passe com -f <VALUES_FILE>.

Ozone

O Ozone expõe quatro endpoints via Gateway API: S3 REST, S3 Web UI, OM UI e SCM UI:

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

tdp-ozone:
  gatewayApi:
    parentRefs:
      - name: <GATEWAY_NAME>
        namespace: <GATEWAY_NAMESPACE>
    s3g:
      rest:
        enabled: true
        hostnames:
          - <OZONE_S3_REST_HOSTNAME>
        rules:
          - matches:
              - path:
                  type: PathPrefix
                  value: /
            backendRefs:
              - name: ""
                port: 9878
        tls:
          certificateRefs: []
      web:
        enabled: true
        hostnames:
          - <OZONE_S3_WEB_HOSTNAME>
        rules:
          - matches:
              - path:
                  type: PathPrefix
                  value: /
            backendRefs:
              - name: ""
                port: 19878
        tls:
          certificateRefs: []
    om:
      enabled: true
      hostnames:
        - <OZONE_OM_HOSTNAME>
      rules:
        - matches:
            - path:
                type: PathPrefix
                value: /
          backendRefs:
            - name: ""
              port: 9874
      tls:
        certificateRefs: []
    scm:
      enabled: true
      hostnames:
        - <OZONE_SCM_HOSTNAME>
      rules:
        - matches:
            - path:
                type: PathPrefix
                value: /
          backendRefs:
            - name: ""
              port: 9876
      tls:
        certificateRefs: []

Exemplos de hostname:

Kubernetes padrão: ozone-s3.tdp.local, ozone-s3-ui.tdp.local, ozone-om.tdp.local, ozone-scm.tdp.local
OpenShift: ozone-s3-<NAMESPACE>.apps.<CLUSTER_DOMAIN>, ozone-s3-ui-<NAMESPACE>.apps.<CLUSTER_DOMAIN>, ozone-om-<NAMESPACE>.apps.<CLUSTER_DOMAIN>, ozone-scm-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Ranger

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
  parentRefs:
    - name: <GATEWAY_NAME>
  ranger:
    enabled: true
    hostnames:
      - <RANGER_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 6080
    tls:
      certificateRefs: []

Exemplos de hostname:

Kubernetes padrão: ranger.tdp.local
OpenShift: ranger-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Superset

O Superset reutiliza um Gateway externo via parentRefs — não cria um Gateway próprio. Não inclui gatewayClassName nem gateway.enabled.

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  parentRefs:
    - name: <GATEWAY_NAME>
      namespace: <GATEWAY_NAMESPACE>
  superset:
    enabled: true
    hostnames:
      - <SUPERSET_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 8088
    tls:
      certificateRefs: []

Exemplos de hostname:

Kubernetes padrão: superset.tdp.local
OpenShift: superset-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Trino

O Trino reutiliza um Gateway externo via parentRefs — não cria um Gateway próprio. Não inclui gatewayClassName nem gateway.enabled.

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  parentRefs:
    - name: <GATEWAY_NAME>
      namespace: <GATEWAY_NAMESPACE>
  trino:
    enabled: true
    hostnames:
      - <TRINO_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 8080
    tls:
      certificateRefs: []

Exemplos de hostname:

Kubernetes padrão: trino.tdp.local
OpenShift: trino-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Spark

Tal como no Ingress, o Spark requer parâmetros de reverse proxy também no modo Gateway API.

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: true

gatewayApi:
  gatewayClassName: <GATEWAY_CLASS>
  gateway:
    enabled: true
    name: <GATEWAY_NAME>
    listeners:
      - name: web
        port: 8000
        protocol: HTTP
  parentRefs:
    - name: <GATEWAY_NAME>
      namespace: <GATEWAY_NAMESPACE>
  spark:
    enabled: true
    hostnames:
      - <SPARK_HOSTNAME>
    rules:
      - matches:
          - path:
              type: PathPrefix
              value: /
        backendRefs:
          - name: ""
            port: 80
    tls:
      certificateRefs: []

spark:
  master:
    configOptions: "-Dspark.ui.reverseProxy=true -Dspark.ui.reverseProxyUrl=http://<SPARK_HOSTNAME>"
  worker:
    configOptions: "-Dspark.ui.reverseProxy=true -Dspark.ui.reverseProxyUrl=http://<SPARK_HOSTNAME>"
  sparkConf:
    "spark.ui.reverseProxy": "true"
    "spark.ui.reverseProxyUrl": "http://<SPARK_HOSTNAME>"

Exemplos de hostname:

Kubernetes padrão: spark.tdp.local
OpenShift: spark-<NAMESPACE>.apps.<CLUSTER_DOMAIN>

Referência rápida: chaves e portas

A chave gatewayApi.<APPLICATION_NAME> varia por chart — as sub-chaves e portas de backend são:

Chart	Chave `gatewayApi`	Porta de backend
tdp-airflow	`gatewayApi.airflow`	8080
tdp-argo	`gatewayApi.server`	80
tdp-clickhouse	`gatewayApi.clickhouse`	8123
tdp-cloudbeaver	`gatewayApi.cloudbeaver`	8978
tdp-jupyter	`gatewayApi.jupyter`	80
tdp-kafka	`gatewayApi.kafkaUi`	80
tdp-nifi	`gatewayApi.nifi`	8080 (HTTP) / 8443 (HTTPS)
tdp-openmetadata	`gatewayApi.openmetadata`	8585
tdp-ozone (S3 REST)	`gatewayApi.s3g.rest`	9878
tdp-ozone (S3 Web UI)	`gatewayApi.s3g.web`	19878
tdp-ozone (OM UI)	`gatewayApi.om`	9874
tdp-ozone (SCM UI)	`gatewayApi.scm`	9876
tdp-ranger	`gatewayApi.ranger`	6080
tdp-spark	`gatewayApi.spark`	80
tdp-superset	`gatewayApi.superset`	8088
tdp-trino	`gatewayApi.trino`	8080

TLS com Gateway API

Terminação no Gateway (mais comum): o listener HTTPS do Gateway faz a terminação TLS — nenhuma configuração adicional é necessária no HTTPRoute.

certificateRefs por componente (quando suportado): TLS no bloco gatewayApi.<APPLICATION_NAME>.tls.certificateRefs.

Validação

Terminal input
kubectl get gatewayclass
kubectl get gateway -A
kubectl get httproute -n <NAMESPACE>
kubectl describe httproute <HTTPROUTE_NAME> -n <NAMESPACE>
curl -I http://<COMPONENT_HOSTNAME>

Resolução de problemas

Problema	Diagnóstico	Solução
`HTTPRoute` não criado	`kubectl get httproute -n <NAMESPACE>` não lista	Verifique `TDP-Settings.gateway.gatewayApi.enabled: true`
`Gateway` não criado	`kubectl get gateway -A` não lista o recurso	Verifique `gatewayApi.gateway.enabled: true`
`HTTPRoute` sem tráfego	Status inválido no describe	Confirme `parentRefs.name` apontando para o Gateway correto
Hostname não resolve	`curl` falha com DNS lookup error	DNS deve apontar para o IP do Gateway
`backendRefs.port` incorreto	Tráfego não chega ao componente	Confirme a porta do Service com `kubectl get svc -n <NAMESPACE>`
ClickHouse `AUTHENTICATION_FAILED`	Acesso via Gateway rejeitado	Configure `extraUsers` com `<ip>::/0</ip>`
`gatewayclass` não encontrada	`kubectl get gatewayclass` retorna vazio	Instale o Gateway Controller no cluster

Objetivo da página​

Quando expor um componente externamente​

Ingress vs Gateway API​

Regra de exclusividade​

Pré-requisitos​

Padrão comum de configuração​

Como funciona​

Aplicar os valores​

Teste local sem DNS​

Padrão comum (Jupyter, Kafka UI, ClickHouse, Airflow)​

JupyterHub​

Airflow​

Argo CD​

OpenShift​

ClickHouse​

CloudBeaver​

Kafka UI​

NiFi​

Kubernetes padrão (HTTP)​

Kubernetes padrão (HTTPS)​

OpenShift​

OpenMetadata​

Kubernetes padrão​

OpenShift​

Ozone​

Ranger​

Superset​

Trino​

Spark​

TLS com Ingress​

Validação​

Resolução de problemas​

Como funciona​

Aplicar os valores​

Acesso via Gateway API​

Padrão comum de Gateway API​

Airflow​

Argo CD​

ClickHouse​

CloudBeaver​

Jupyter (padrão comum)​

Kafka UI​

OpenMetadata​

NiFi​

Ozone​

Ranger​

Superset​

Trino​

Spark​

Referência rápida: chaves e portas​

TLS com Gateway API​

Validação​

Resolução de problemas​

Objetivo da página

Quando expor um componente externamente

Ingress vs Gateway API

Regra de exclusividade

Pré-requisitos

Padrão comum de configuração

Como funciona

Aplicar os valores

Teste local sem DNS

Padrão comum (Jupyter, Kafka UI, ClickHouse, Airflow)

JupyterHub

Airflow

Argo CD

OpenShift

ClickHouse

CloudBeaver

Kafka UI

NiFi

Kubernetes padrão (HTTP)

Kubernetes padrão (HTTPS)

OpenShift

OpenMetadata

Kubernetes padrão

OpenShift

Ozone

Ranger

Superset

Trino

Spark

TLS com Ingress

Validação

Resolução de problemas

Como funciona

Aplicar os valores

Acesso via Gateway API

Padrão comum de Gateway API

Airflow

Argo CD

ClickHouse

CloudBeaver

Jupyter (padrão comum)

Kafka UI

OpenMetadata

NiFi

Ozone

Ranger

Superset

Trino

Spark

Referência rápida: chaves e portas

TLS com Gateway API

Validação

Resolução de problemas