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
- Deployment: gerencia Pods sem estado (stateless), garantindo que o número desejado de réplicas esteja sempre em execução. Utilizado para componentes como Trino, Superset e CloudBeaver.
- StatefulSet: gerencia Pods com estado (stateful), fornecendo identidade de rede estável e armazenamento persistente. Utilizado para componentes como Kafka, PostgreSQL e ClickHouse.
| Aspecto | Deployment | StatefulSet |
|---|---|---|
| Estado | Stateless (sem estado persistente) | Stateful (identidade e volume por Pod) |
| Nome dos Pods | Aleatório | Ordenado e estável (nome-0, nome-1, …) |
| Escalabilidade | Escala réplicas de forma intercambiável | Escala com ordem; cada Pod mantém identidade |
| No TDP | Trino, Superset, CloudBeaver, Airflow, etc. | Kafka, PostgreSQL, ClickHouse, NiFi, etc. |
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 suporta duas abordagens para exposição HTTP/HTTPS: Ingress e Gateway API.
A API Ingress continua suportada no Kubernetes, porém está congelada, sem evolução funcional planejada. Já o Ingress NGINX Controller, uma das implementações mais conhecidas para recursos Ingress, entrou em processo de aposentadoria em março de 2026.
O TDP Kubernetes documenta as duas abordagens, pois diferentes ambientes de clientes podem utilizar qualquer uma delas.
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
Os Operators estendem o Kubernetes para automatizar o gerenciamento de aplicações que exigem lógica operacional mais específica. Além da instalação, eles permitem monitorar, reconciliar e administrar continuamente o estado da aplicação.
No TDP Kubernetes, essa abordagem é normalmente utilizada em componentes com maior complexidade operacional, especialmente quando há necessidade de automação mais avançada sobre persistência, atualização ou recuperação de falhas.
Estratégia de Deploy: Helm e Operators
A estratégia de implantação do TDP Kubernetes é definida de acordo com a complexidade operacional de cada serviço. Para isso, a plataforma pode adotar abordagens distintas com Helm e Operators, conforme o perfil do componente implantado.
De forma geral:
- serviços mais simples, efêmeros ou com comportamento predominantemente stateless tendem a ser implantados com Helm;
- serviços com maior complexidade operacional, persistência de dados ou requisitos avançados de automação podem ser implantados com Operators.
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: