Kubernetes
Orquestração de Contêineres
Kubernetes (frequentemente abreviado como K8s) é uma plataforma open source de orquestração de contêineres, projetada para automatizar a implantação, o escalonamento e o gerenciamento de aplicações em contêineres.
Originalmente desenvolvido pelo Google e agora mantido pela Cloud Native Computing Foundation (CNCF), o Kubernetes tornou-se o padrão de fato para orquestração de contêineres em ambientes de produção.
No contexto do TDP Kubernetes, a plataforma Kubernetes é utilizada como base para a implantação de todos os componentes da edição cloud-native do TDP, substituindo a abordagem tradicional de bare-metal e máquinas virtuais utilizada na edição TDP Datacenter.
Por que Kubernetes?
A adoção do Kubernetes como plataforma de implantação do TDP traz diversos benefícios:
- Escalabilidade automática: os componentes podem escalar horizontalmente de acordo com a demanda, sem intervenção manual
- Alta disponibilidade: o Kubernetes garante que os componentes sejam redistribuídos automaticamente em caso de falha de um nó
- Implantação declarativa: toda a infraestrutura é descrita como código (YAML), permitindo versionamento e reprodutibilidade
- Isolamento de recursos: cada componente executa em seu próprio contêiner, com limites definidos de CPU e memória
- Atualizações sem downtime: rolling updates e rollbacks são nativos da plataforma
- Ecossistema rico: integração com ferramentas como Helm, ArgoCD, Prometheus e Grafana
Conceitos Fundamentais
Pods
O Pod é a menor unidade de implantação no Kubernetes.
Um Pod encapsula um ou mais contêineres que compartilham o mesmo namespace de rede e armazenamento.
No TDP Kubernetes, cada componente (como Kafka, Trino ou Airflow) é executado em um ou mais Pods.
| Elemento | Descrição |
|---|---|
| Contêineres | Um ou mais contêineres no mesmo Pod (recurso compartilhado) |
| Rede | Um único IP por Pod; contêineres comunicam via localhost |
| Armazenamento | Volumes compartilhados entre os contêineres do Pod |
Deployments e StatefulSets
O Kubernetes utiliza controladores para manter Pods em execução, recriá-los em caso de falha e aplicar atualizações de forma controlada.
-
Deployment: usado para cargas em que os Pods são intercambiáveis. Um Pod pode ser substituído por outro sem necessidade de preservar o mesmo nome, IP ou volume exclusivo. É comum em componentes como Trino, Superset, CloudBeaver e partes do Airflow, conforme a arquitetura do chart.
-
StatefulSet: usado para cargas que precisam de identidade estável. Cada Pod mantém um nome previsível, uma identidade de rede própria e, quando configurado, um volume persistente associado. É comum em componentes como Kafka, PostgreSQL, ClickHouse e NiFi.
| Aspecto | Deployment | StatefulSet |
|---|---|---|
| Uso principal | Pods intercambiáveis | Pods com identidade estável |
| Identidade dos Pods | Não é preservada entre recriações | Preservada entre recriações |
| Nome dos Pods | Gerado automaticamente | Ordenado e previsível, como nome-0, nome-1 |
| Armazenamento | Pode usar volumes, mas não há vínculo fixo por Pod | Pode manter volume persistente associado a cada Pod |
| Escalabilidade | Réplicas equivalentes entre si | Réplicas com identidade própria e ordem controlada |
| Exemplos no TDP | Trino, Superset, CloudBeaver, partes do Airflow | Kafka, PostgreSQL, ClickHouse, NiFi |
Services
Os Services expõem os Pods para comunicação interna (ClusterIP) ou externa (NodePort, LoadBalancer, Ingress). No TDP Kubernetes, cada componente possui seu próprio Service para descoberta e comunicação entre componentes.
| Tipo | Uso |
|---|---|
| ClusterIP | Acesso apenas dentro do cluster (padrão); usado para comunicação entre componentes (ex.: Trino → Hive Metastore). |
| NodePort | Expõe a aplicação em uma porta em cada nó; útil para testes ou clusters sem LoadBalancer. |
| LoadBalancer | Expõe via balanceador de carga do provedor de nuvem (ou MetalLB on-premise). |
| Ingress / Gateway API | Roteamento HTTP/HTTPS por host e caminho; usado para UIs (Airflow, Superset, ArgoCD, etc.). |
Ingress vs Gateway API
O TDP Kubernetes pode ser exposto por HTTP/HTTPS usando duas abordagens: Ingress ou Gateway API.
A API Ingress continua disponível e suportada no Kubernetes, mas está congelada: não há previsão de evolução funcional para essa API. Novas funcionalidades de roteamento HTTP/HTTPS estão sendo direcionadas para a Gateway API.
É importante diferenciar a API Ingress dos seus controladores. A aposentadoria anunciada para março de 2026 se refere ao controlador comunitário ingress-nginx, não à remoção da API Ingress do Kubernetes.
Por esse motivo, o TDP Kubernetes documenta as duas abordagens. Ambientes que já utilizam Ingress podem continuar usando essa opção, desde que adotem um controlador compatível e mantido. Para novas implantações ou evoluções de arquitetura, a Gateway API deve ser considerada como a abordagem preferencial.
Namespaces
Os Namespaces fornecem isolamento lógico dentro do cluster. O TDP Kubernetes utiliza um namespace único para agrupar os componentes; na documentação esse namespace é indicado como <NAMESPACE>.
O <NAMESPACE> é definido pelo usuário. Pode ser, por exemplo, tdp-ingestao, tdp-financeiro, departamento-pessoal ou qualquer outro nome. O sufixo -project em exemplos como tdp-project é apenas ilustrativo nesta documentação; o usuário escolhe o nome que desejar.
Persistent Volumes
Os Persistent Volumes (PV) e Persistent Volume Claims (PVC) fornecem armazenamento persistente para os componentes que necessitam manter dados entre reinicializações, como bancos de dados (PostgreSQL, ClickHouse) e sistemas de mensageria (Kafka).
O PVC é a solicitação de armazenamento feita pelo Pod (por exemplo, "preciso de 10 Gi em ReadWriteOnce"); o cluster atende a essa solicitação vinculando o PVC a um PV existente ou provisionando um novo volume dinamicamente por meio de uma StorageClass (por exemplo, local-path ou provisionadores de nuvem).
A figura abaixo ilustra esse fluxo: o Pod referencia um PVC; o PVC é atendido pela StorageClass, que provisiona o volume no disco físico do nó (ou em storage externo, conforme a StorageClass configurada).
ConfigMaps e Secrets
- ConfigMaps: armazenam configurações não sensíveis em formato chave-valor, utilizadas para parametrizar os componentes
- Secrets: armazenam dados sensíveis como senhas, tokens e certificados de forma criptografada
| Recurso | Conteúdo típico | Uso no TDP |
|---|---|---|
| ConfigMap | URLs, endpoints, flags, arquivos de configuração | Parâmetros de conexão (ex.: catálogos Trino), configs não sensíveis |
| Secret | Senhas, chaves de API, certificados TLS | Credenciais de banco, registry OCI, LDAP, tokens |
Modelo de Deploy do TDP Kubernetes
Helm Charts
O Helm é o gerenciador de pacotes do Kubernetes, e o TDP Kubernetes utiliza Helm Charts para empacotar, configurar e instalar cada componente da plataforma.
Cada chart contém:
- Templates de recursos Kubernetes (Deployments, Services, ConfigMaps, etc.)
- Valores padrão configuráveis (
values.yaml) - Declaração de dependências entre charts
- Metadados e documentação
No TDP Kubernetes, o Helm é geralmente adotado em componentes cujo ciclo de vida pode ser tratado adequadamente pelos recursos nativos do Kubernetes, com menor necessidade de automação operacional especializada.
Os charts do TDP Kubernetes estão disponíveis no registry OCI da Tecnisys (registry.tecnisys.com.br) e seguem a convenção de nomenclatura tdp-<componente> (por exemplo, tdp-kafka, tdp-trino, tdp-airflow).
Registry OCI
No TDP Kubernetes, artefatos como Helm Charts e imagens de contêiner podem ser distribuídos por meio de um registry compatível com OCI. Esse modelo padroniza o armazenamento, o versionamento e a distribuição dos pacotes utilizados pela plataforma.
O uso de um registry centralizado facilita:
- publicação e distribuição controlada de artefatos;
- versionamento consistente de charts e imagens;
- integração com fluxos de instalação e automação;
- suporte a abordagens baseadas em CLI e GitOps.
Os detalhes de autenticação, acesso ao registry e comandos operacionais devem ser consultados nas seções de instalação.
Operators
Operators estendem o Kubernetes com lógica operacional específica para determinadas aplicações. Eles observam o estado real dos recursos no cluster, comparam esse estado com a configuração desejada e executam ações de reconciliação quando necessário.
Na prática, um Operator automatiza tarefas como criação de recursos derivados, atualização, recuperação de falhas, ajuste de configuração, gerenciamento de réplicas, tratamento de recursos persistentes e manutenção do estado da aplicação.
No TDP Kubernetes, Operators são utilizados nos componentes cuja arquitetura requer reconciliação especializada por meio de Custom Resources. Nesses casos, o Helm permanece como mecanismo de instalação e parametrização do chart, enquanto o Operator é responsável por manter os recursos da aplicação reconciliados no cluster.
Essa abordagem é adotada, por exemplo, em componentes como Kafka, NiFi e ClickHouse, nos quais a operação da aplicação é conduzida por recursos customizados e controladores especializados.
Os CRDs necessários para componentes baseados em Custom Resources são concentrados no chart tdp-crds, que deve ser instalado antes dos charts que criam esses recursos.
Estratégia de Deploy: Helm e Operators
A implantação do TDP Kubernetes utiliza o Helm como mecanismo principal de empacotamento, configuração e instalação dos componentes.
Os charts Helm definem os recursos Kubernetes necessários para cada componente, como Deployments, StatefulSets, Services, Secrets, ConfigMaps, Jobs, Ingresses, HTTPRoutes, RBAC e, em componentes baseados em Operators, Custom Resources.
Nos componentes em que o TDP Kubernetes adota Operators, o chart Helm entrega os recursos necessários e parametriza a instalação, enquanto o Operator mantém o estado da aplicação reconciliado no cluster.
De forma geral:
- o Helm é o mecanismo de instalação e configuração dos charts do TDP Kubernetes;
- determinados componentes utilizam Operators e Custom Resources por definição da sua arquitetura;
- os CRDs utilizados por esses componentes são instalados previamente pelo chart
tdp-crds; - em OpenShift, a implantação segue o modelo Kubernetes, com adaptações de segurança e execução tratadas pelos charts dos componentes quando necessário.
Assim, Helm e Operators atuam de forma complementar no TDP Kubernetes: o Helm entrega a instalação parametrizada, e o Operator, nos componentes que o utilizam, executa a reconciliação operacional da aplicação.
ArgoCD e GitOps
GitOps
GitOps é um modelo operacional no qual o estado desejado do ambiente é definido de forma declarativa em repositórios Git. As mudanças passam a ser versionadas, auditáveis e reconciliadas continuamente no cluster.
Essa abordagem favorece maior previsibilidade operacional, rastreabilidade de mudanças e redução de alterações manuais diretas no ambiente.
Princípios do GitOps
Os princípios centrais do GitOps incluem:
- Fonte única de verdade: o estado desejado da plataforma é mantido em repositórios Git;
- Configuração declarativa: os recursos são definidos por manifestos e arquivos versionáveis;
- Versionamento e rastreabilidade: toda mudança fica registrada e auditável;
- Reconciliação automática: o ambiente é continuamente comparado com o estado desejado e ajustado quando necessário;
- Operação previsível: implantações, mudanças e reversões seguem um fluxo controlado e reproduzível.
ArgoCD
O ArgoCD é uma ferramenta de entrega declarativa baseada em princípios de GitOps. Nesse modelo, o estado desejado da aplicação é descrito em repositórios Git, e o ambiente é reconciliado continuamente com esse estado.
No TDP Kubernetes, essa abordagem permite:
- rastreabilidade de mudanças;
- maior previsibilidade de deploy;
- controle declarativo de ambientes;
- redução de alterações manuais diretas no cluster.
Arquitetura do TDP Kubernetes
O TDP Kubernetes pode ser entendido a partir de duas visões complementares.
A primeira é uma visão lógica, que mostra como os principais componentes da plataforma se organizam por responsabilidade. Nessa perspectiva, a arquitetura é apresentada em camadas, facilitando a compreensão do papel de cada serviço dentro do ecossistema: interfaces de acesso, motores de processamento, componentes de orquestração, serviços de metadados e segurança, e a base de armazenamento sobre a qual os dados são mantidos.
A segunda é uma visão de implantação, que mostra como essa arquitetura é materializada em um ambiente Kubernetes. Nessa leitura, o foco deixa de ser apenas a função de cada componente e passa a ser também a forma como artefatos, cluster, persistência, exposição de serviços e operação da plataforma se conectam na prática.
O TDP Kubernetes adota uma arquitetura de microsserviços, em que os componentes do ecossistema Big Data são executados em contêineres gerenciados pelo Kubernetes. Nesse modelo, os Helm Charts encapsulam a complexidade de instalação e configuração dos serviços, enquanto o ArgoCD garante a sincronização contínua entre o estado desejado, definido em Git, e o estado efetivamente aplicado no cluster.
A figura abaixo apresenta a visão lógica da plataforma. Ela ajuda a compreender como os serviços se distribuem em camadas funcionais e como cada grupo contribui para o funcionamento do ambiente como um todo.
Nessa organização, a camada superior concentra os serviços de acesso e interação com o usuário, como visualização, notebooks, administração e interfaces especializadas. Em seguida, aparecem os motores responsáveis por consultas, processamento analítico, ETL e streaming. A orquestração coordena fluxos e execuções, enquanto a camada de metadados e segurança sustenta catálogo, governança, controle de acesso e persistência auxiliar. Na base, o armazenamento orienta a persistência dos dados e dos formatos analíticos utilizados pela plataforma.
A figura a seguir apresenta a visão de implantação do TDP Kubernetes. Ela evidencia como os artefatos são disponibilizados, como os componentes são implantados no cluster e como a plataforma se integra com os mecanismos de persistência e acesso.
Sob essa perspectiva, o fluxo se inicia na origem dos artefatos, com o registry e as ferramentas de instalação e gestão. Em seguida, a implantação ocorre no cluster Kubernetes, que provê os elementos de controle, execução e exposição dos serviços. O armazenamento persistente dá suporte aos dados e volumes necessários à operação dos componentes, enquanto as interfaces web tornam os serviços acessíveis aos usuários e administradores da plataforma. Assim, a visão de implantação complementa a visão lógica anterior ao mostrar não apenas o papel dos componentes, mas também a forma como eles são distribuídos e operados no ambiente.
| Camada | Componentes | Função |
|---|---|---|
| Infraestrutura de Plataforma | ArgoCD, PostgreSQL | Suporte à operação da plataforma, gerenciamento e serviços compartilhados |
| Mensageria | Apache Kafka | Streaming de eventos e integração de dados |
| Armazenamento de Metadados e Tabelas | Hive Metastore, Delta Lake, Apache Iceberg | Metadados e formatos de tabela abertos |
| Armazenamento de Objetos | Apache Ozone | Armazenamento distribuído de objetos, alternativa S3-compatível para ambientes on-premise |
| Segurança | Apache Ranger | Controle de acesso e políticas de segurança |
| Ingestão | Apache NiFi | Ingestão e transformação de dados |
| Processamento | Apache Spark, Trino | Processamento batch, streaming e consultas SQL |
| Orquestração e Desenvolvimento | Apache Airflow, JupyterHub | Orquestração de pipelines e notebooks |
| Análise e Acesso | ClickHouse, Apache Superset, CloudBeaver | OLAP, visualização e administração de dados |
| Governança | OpenMetadata | Catálogo de dados e linhagem |
Funcionamento da Plataforma
A plataforma TDP Kubernetes pode ser compreendida em um fluxo que vai da definição do estado desejado até a execução dos componentes e o consumo final dos serviços implantados.
1. Controle e Implantação
A implantação e a gestão do ambiente podem ocorrer por diferentes abordagens, conforme o modelo operacional adotado:
- TDPCTL (recomendado): ferramenta de automação utilizada para reduzir etapas manuais de configuração e implantação.
- Argo CD com Git: fluxo GitOps no qual o estado desejado do ambiente é mantido em repositório Git e reconciliado continuamente no cluster.
- Deploy a partir de artefatos versionados: os componentes também podem ser implantados a partir de charts e imagens disponibilizados em registry compatível com OCI.
Os detalhes operacionais dessas abordagens estão descritos nas seções de instalação e configuração.
2. Distribuição de Artefatos
As imagens de contêiner e os Helm Charts da plataforma são distribuídos por meio de um registry compatível com OCI.
Esse modelo permite:
- versionamento centralizado dos artefatos;
- distribuição padronizada de imagens e charts;
- integração com fluxos automatizados de instalação e GitOps;
- controle de acesso conforme o ambiente.
Endereço do registry, autenticação, SSO e procedimentos de acesso devem ser tratados nas páginas de pré-requisitos e instalação.
3. Execução dos Componentes
Após a implantação, o cluster Kubernetes executa os componentes da plataforma como workloads conteinerizados, utilizando os mecanismos nativos de agendamento, rede, escalabilidade e persistência.
Nesse modelo:
- componentes stateless tendem a ser gerenciados por recursos como Deployments;
- componentes stateful tendem a utilizar StatefulSets e volumes persistentes;
- a comunicação entre componentes ocorre por meio de Services;
- a exposição de interfaces web pode ser realizada por mecanismos como Gateway API ou outras implementações suportadas pelo ambiente.
4. Persistência e Acesso aos Dados
A camada de dados da plataforma pode utilizar serviços externos de armazenamento ou recursos providos pela própria solução, conforme a arquitetura do ambiente.
De forma geral:
- serviços compatíveis com S3 podem ser utilizados quando já existem na infraestrutura;
- em cenários on-premise ou sem storage externo compatível, o Apache Ozone pode atuar como camada de armazenamento de objetos;
- componentes que exigem persistência utilizam Persistent Volumes e Persistent Volume Claims, de acordo com a StorageClass disponível no cluster.
Esse modelo preserva flexibilidade de implantação e compatibilidade entre os componentes da stack.
Próximos Passos
Para seguir com a adoção ou operação do TDP Kubernetes, consulte também: