Kubernetes
Orquestração de Contentores
Kubernetes (frequentemente abreviado como K8s) é uma plataforma open source de orquestração de contentores, concebida para automatizar a implantação, o escalonamento e a gestão de aplicações em contentores.
Originalmente desenvolvido pelo Google e agora mantido pela Cloud Native Computing Foundation (CNCF), o Kubernetes tornou-se o padrão de facto para orquestração de contentores 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.
Porquê 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 procura, 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 no seu próprio contentor, 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 contentores que partilham 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 |
|---|---|
| Contentores | Um ou mais contentores no mesmo Pod (recurso partilhado) |
| Rede | Um único IP por Pod; contentores comunicam via localhost |
| Armazenamento | Volumes partilhados entre os contentores 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 o 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 numa porta em cada nó; útil para testes ou clusters sem LoadBalancer. |
| LoadBalancer | Expõe via balanceador de carga do fornecedor de nuvem (ou MetalLB on-premise). |
| Ingress / Gateway API | Roteamento HTTP/HTTPS por host e caminho; usado para UIs (Airflow, Superset, ArgoCD, etc.). |
Ingress e 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 utilizador. 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 utilizador escolhe o nome que desejar.
Persistent Volumes
Os Persistent Volumes (PV) e Persistent Volume Claims (PVC) fornecem armazenamento persistente para os componentes que necessitam de manter dados entre reinicializações, como bases 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 aprovisionando um novo volume dinamicamente por meio de uma StorageClass (por exemplo, local-path ou aprovisionadores de nuvem).
A figura abaixo ilustra esse fluxo: o Pod referencia um PVC; o PVC é atendido pela StorageClass, que aprovisiona 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 palavras-passe, tokens e certificados de forma encriptada
| Recurso | Conteúdo típico | Uso no TDP |
|---|---|---|
| ConfigMap | URLs, endpoints, flags, ficheiros de configuração | Parâmetros de conexão (ex.: catálogos Trino), configs não sensíveis |
| Secret | Palavras-passe, chaves de API, certificados TLS | Credenciais de base de dados, registry OCI, LDAP, tokens |
Modelo de Deploy do TDP Kubernetes
Helm Charts
O Helm é o gestor 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 contentor podem ser distribuídos por meio de um registry compatível com OCI. Este 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 secções de instalação.
Operators
Operators extend Kubernetes with application-specific operational logic. They observe the actual state of resources in the cluster, compare it with the desired configuration, and perform reconciliation actions when required.
In practice, an Operator automates tasks such as creating derived resources, performing updates, recovering from failures, adjusting configuration, managing replicas, handling persistent resources, and maintaining the application state.
In TDP Kubernetes, Operators are used by components whose architecture requires specialized reconciliation through Custom Resources. In these cases, Helm remains the mechanism for installing and parametrizing the chart, while the Operator is responsible for keeping the application resources reconciled in the cluster.
This approach is adopted, for example, by components such as Kafka, NiFi, and ClickHouse, where the application lifecycle is managed through Custom Resources and specialized controllers.
The CRDs required by components based on Custom Resources are centralized in the tdp-crds chart, which must be installed before charts that create those resources.
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 alterações passam a ser versionadas, auditáveis e reconciliadas continuamente no cluster.
Esta abordagem favorece maior previsibilidade operacional, rastreabilidade de alterações 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 ficheiros versionáveis;
- Versionamento e rastreabilidade: toda a alteração fica registada 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, alterações e reversões seguem um fluxo controlado e reproduzível.
ArgoCD
O ArgoCD é uma ferramenta de entrega declarativa baseada em princípios de GitOps. Neste modelo, o estado desejado da aplicação é descrito em repositórios Git, e o ambiente é reconciliado continuamente com esse estado.
No TDP Kubernetes, esta abordagem permite:
- rastreabilidade de alterações;
- maior previsibilidade de deploy;
- controlo declarativo de ambientes;
- redução de alterações manuais diretas no cluster.
Arquitetura do TDP Kubernetes
A arquitetura do TDP Kubernetes pode ser observada sob duas perspetivas complementares.
A primeira apresenta uma visão geral da implantação da solução, incluindo origem dos artefatos, cluster Kubernetes, mecanismos de exposição e integração com armazenamento.
A segunda detalha a organização funcional dos componentes da plataforma, agrupando os serviços por camadas lógicas de responsabilidade.
A edição TDP Kubernetes organiza os seus componentes em camadas lógicas, de acordo com a função exercida por cada serviço dentro da plataforma.
| Camada | Componentes | Função |
|---|---|---|
| Infraestrutura de Plataforma | ArgoCD, PostgreSQL | Suporte à operação da plataforma, gestão e serviços partilhados |
| 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 | Controlo 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 num fluxo que vai da definição do estado desejado até à execução dos componentes e ao consumo final dos serviços implantados.
1. Controlo 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 destas abordagens estão descritos nas secções de instalação e configuração.
2. Distribuição de Artefactos
As imagens de contentor e os Helm Charts da plataforma são distribuídos por meio de um registry compatível com OCI.
Este modelo permite:
- versionamento centralizado dos artefatos;
- distribuição padronizada de imagens e charts;
- integração com fluxos automatizados de instalação e GitOps;
- controlo 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.
Neste modelo:
- componentes stateless tendem a ser geridos 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.
Este 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: