Pré-requisitos

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

Esta seção descreve os pré-requisitos necessários para a instalação do TDP Kubernetes. Certifique-se de que todos os itens estejam atendidos antes de iniciar o processo de instalação dos componentes.

Requisitos de Infraestrutura

Orquestrador

O TDP Kubernetes é homologado nos seguintes orquestradores:

Orquestrador	Versão mínima
Kubernetes	1.32+
Red Hat OpenShift	4.19+
Rancher Manager	2.10.x+

• Cluster operacional com pelo menos 3 worker nodes (recomendado para alta disponibilidade)
• Acesso administrativo ao cluster via kubectl

Ferramentas de Linha de Comando

Ferramenta	Versão Mínima	Descrição
kubectl	1.27 e compatível com o cluster	CLI do Kubernetes, configurado para o cluster de destino; versão deve ser compatível com a versão do cluster
helm	3.2.0+	Gerenciador de pacotes Kubernetes para instalação dos charts

Verifique as versões instaladas:

Terminal input

kubectl version --client
helm version

Classes de Armazenamento (Storage Classes)

O TDP Kubernetes requer Storage Classes configuradas no cluster para provisionamento dinâmico de volumes persistentes.

Uma StorageClass define como o cluster provisiona volumes persistentes sob demanda: ela aponta para um provisionador — como CSI de nuvem, NFS, Ceph, Longhorn ou equivalente — e determina o tipo de disco, a política de retenção e demais parâmetros operacionais.

Quando um chart do TDP solicita armazenamento via PersistentVolumeClaim (PVC), o Kubernetes usa a StorageClass indicada — ou a padrão do cluster — para criar o PersistentVolume correspondente no backend.

Modo de Acesso	Uso	Obrigatório
ReadWriteOnce (RWO)	Utilizado pela maioria dos componentes (PostgreSQL, Kafka, ClickHouse, etc.)	Sim
ReadWriteMany (RWX)	Necessário quando algum componente ou modo de instalação exige volume persistente compartilhado entre múltiplos Pods	Condicional

note

O modo ReadWriteMany (RWX) é necessário quando múltiplos Pods precisam acessar o mesmo volume persistente em leitura e escrita. O Apache Airflow é um exemplo comum quando DAGs ou logs são compartilhados por PVC, mas a necessidade de RWX depende da arquitetura e do modo de instalação do componente. Soluções como NFS, CephFS, Azure Files ou equivalentes podem fornecer suporte a RWX, dependendo do ambiente.

Verifique as Storage Classes disponíveis no cluster:

Terminal input

kubectl get storageclass

Exposição HTTP/HTTPS dos componentes

É necessário possuir uma solução de entrada de tráfego HTTP/HTTPS para expor as interfaces web de alguns componentes do TDP Kubernetes, como Airflow, Superset, Argo CD, NiFi e JupyterHub.

Ingress Controller

O ambiente pode utilizar um controlador Ingress para publicação dos serviços web no cluster.

Exemplos comuns:

• NGINX Ingress Controller
• Traefik
• HAProxy
• AWS Load Balancer Controller

Verifique se há um controlador Ingress instalado no cluster. Exemplo com NGINX Ingress Controller:

Terminal input

kubectl get ingressclass

Gateway API

O ambiente também pode utilizar Gateway API, desde que o cluster possua os recursos e o controller compatível já instalados.

Exemplo de verificação:

Terminal input

kubectl get gatewayclass

note

A API Ingress no Kubernetes está congelada e não recebe novas evoluções. Além disso, o projeto Ingress NGINX foi retirado em março de 2026. O uso de Ingress Controller ou Gateway API deve seguir a estratégia adotada para o ambiente e as implementações suportadas no cluster.

Configuração de Rede

DNS

• Os nodes do cluster Kubernetes devem possuir resolução DNS funcional
• Recomenda-se configurar registros DNS para os serviços expostos via Ingress (ex.: airflow.tdp.exemplo.com.br, superset.tdp.exemplo.com.br)

Politicas de Rede (Network Policies)

• Certifique-se de que as Network Policies do cluster permitam a comunicação entre os pods do namespace.

• Os componentes do TDP precisam se comunicar livremente dentro do mesmo namespace

• Caso utilize Network Policies restritivas, configure regras que permitam o trafego ingress e egress entre os pods do TDP

  Em ambientes com políticas de conectividade restritivas, essas regras podem precisar ser aplicadas antes da instalação dos componentes ou durante o bootstrap do ambiente GitOps. Consulte Políticas de cluster para exemplos de NetworkPolicy e critérios de revisão.

  Se o ambiente também exigir autenticação para baixar imagens de um registry privado e a estratégia for centralizar imagePullSecrets com Kyverno, consulte Kyverno e registry privado. Essa etapa é condicional e só se aplica quando adotada pela política do cluster.

Certificados TLS/SSL (Opcional)

Para habilitar HTTPS nos serviços expostos via Ingress:

• Provisione certificados TLS/SSL para os domínios configurados
• Utilize o cert-manager para automação de certificados com Let's Encrypt ou CA interna
• Configure os certificados nos recursos Ingress de cada componente

Autenticação no Registry OCI

Para instalar o TDP Kubernetes, é necessário possuir credenciais de acesso ao registry OCI da Tecnisys, disponível em oci://registry.tecnisys.com.br/tdp/. Esse registry armazena e distribui os Helm charts¹ da plataforma.

As credenciais são usadas de formas diferentes conforme o método de instalação:

Método	Como a credencial é usada
Helm CLI	O operador autentica o Helm localmente com helm registry login.
Argo CD	O registry é cadastrado como repositório diretamente no Argo CD.

note

O helm registry login descrito abaixo é necessário apenas para instalações feitas diretamente via Helm CLI. Em instalações via Argo CD, use a mesma credencial para cadastrar o registry no Argo CD — consulte Instalação via Argo CD.

Comandos

1. Portal Web — Acesse o portal do registry Tecnisys com as credenciais fornecidas pela Tecnisys. Após o login, gere ou copie a credencial de uso em linha de comando, apresentada no portal como CLI Secret ou token de acesso.

   

   Figura 1 - Login no Registry Web
   

   Figura 2 - Captura do CLI Secret

note

A obtenção do CLI Secret/token é comum aos dois métodos de instalação. Em instalações via Argo CD, essa credencial será informada no cadastro do registry dentro do Argo CD. Em instalações via Helm CLI, ela será usada no helm registry login.

2. Helm CLI — Se a instalação for feita diretamente via Helm CLI, autentique o Helm no registry OCI para acessar os charts da plataforma.

   Terminal input

   helm registry login registry.tecnisys.com.br -u <usuario@tecnisys...>

   Ao executar o comando, o terminal solicitará a senha:

   Password:

   Informe o CLI Secret / token obtido no passo 1.

   Se a autenticação for concluída com sucesso, o Helm exibirá a confirmação de login e, a partir daí, será possível consultar e instalar os charts disponíveis no registry.

   Nota

   As credenciais de acesso ao registry devem ser obtidas junto à Tecnisys. Caso você ainda não possua acesso, entre em contato com a equipe responsável para solicitar seu usuário autorizado e a credencial de uso em CLI.

   

   Figura 3 - Registry Login via Helm

3. Validação via Helm CLI — Após a autenticação, verifique o acesso listando um chart de exemplo:

   Terminal input

   helm show chart oci://registry.tecnisys.com.br/tdp/charts/tdp-spark
   

   Figura 4 - Show chart - exemplo

Vídeos

Login no Registry Web

Portal Web (CLI Secret)

Obtenção do CLI Secret

Lista de Verificação

Antes de prosseguir para a instalação, confirme todos os itens abaixo:

• Cluster Kubernetes 1.32+ (ou Red Hat OpenShift 4.19+, ou Rancher Manager 2.10.x+) operacional
• kubectl configurado e conectado ao cluster
• helm 3.2.0+ instalado
• Storage Class com suporte a ReadWriteOnce disponível
• Storage Class com suporte a ReadWriteMany (RWX), quando algum componente ou modo de instalação exigir volume persistente compartilhado entre múltiplos Pods
• Solução de entrada HTTP/HTTPS (Ingress Controller ou Gateway API) instalada e operacional
• Recursos computacionais suficientes nos nodes do cluster
• Resolução DNS configurada para os nodes
• Políticas de cluster e/ou Kyverno avaliados e aplicados, quando exigidos pelo ambiente
• Credenciais de acesso ao registry OCI da Tecnisys obtidas
• Autenticação via helm registry login registry.tecnisys.com.br realizada com sucesso, se a instalação for via Helm CLI
• Certificados TLS/SSL provisionados (opcional)

Footnotes

1. Helm chart: pacote que reúne templates de manifestos Kubernetes e valores por omissão; o Helm aplica esse pacote no cluster para criar ou atualizar os recursos do componente, ajustáveis via arquivos de valores ou flags. ↩