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
- Deployment: gere 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: gere Pods com estado (stateful), fornecendo identidade de rede estável e armazenamento persistente. Utilizado para componentes como Kafka, PostgreSQL e ClickHouse.
| Aspeto | 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 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 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 planeada. 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 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
Os Operators estendem o Kubernetes para automatizar a gestão de aplicações que exigem lógica operacional mais específica. Além da instalação, permitem monitorizar, reconciliar e administrar continuamente o estado da aplicação.
No TDP Kubernetes, esta 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 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: