Configuração do Kafka
O chart tdp-kafka implanta um cluster Apache Kafka gerenciado pelo operador Strimzi, além de uma interface web (Kafka UI) e suporte a conectores Debezium via Kafka Connect.
Visão geral
| Propriedade | Valor |
|---|---|
| Chart | tdp-kafka |
| Kafka | 4.1.0 |
| Versão do Chart | 3.0.1 |
Páginas relacionadas
- Integrações — Kafka — Kafka Connect, Debezium e integração com clientes
- Segurança — Kafka — usuários, autenticação, TLS e políticas
- Exposição externa: Ingress e Gateway API — exposição HTTP/HTTPS da Kafka UI
O que é o Strimzi?
O Strimzi é um operador Kubernetes especializado no ciclo de vida de clusters Kafka. Em vez de gerenciar processos Kafka manualmente, o Strimzi traduz recursos Kubernetes nativos (como KafkaNodePool e Kafka) em brokers configurados, monitorados e atualizados de forma declarativa.
A versão 4.1.0 do chart tdp-kafka opera no modo KRaft (Kafka sem ZooKeeper). No Kafka 4.x o modo ZooKeeper foi removido, então o gerenciamento de metadados é feito pelo próprio Kafka via KRaft, o que simplifica a topologia e reduz a latência de operações de metadados.
Consulte Apache Kafka — Conceitos para uma visão completa da ferramenta, sua arquitetura e funcionamento.
Componentes implantados
| Componente | Descrição |
|---|---|
| Cluster Kafka | Brokers e controllers gerenciados pelo Strimzi via KafkaNodePool |
| Entity Operator | Gerencia KafkaTopic e KafkaUser como recursos Kubernetes |
| Kafka UI | Interface web para monitoramento, navegação de tópicos e mensagens |
| Kafka Connect | Infraestrutura para conectores Debezium (CDC) — opcional |
Estrutura de valores (Helm)
O chart tdp-kafka distribui a configuração nos blocos abaixo:
- Blocos raiz do cluster Kafka —
name,kafkaVersion,metadataVersion,clusterLabel,listeners.*,security.*,config.*,entityOperator.*enodePool.*. tdp-kafka:— habilitação do chart.kafka-ui:— configuração da interface web, autenticação, RBAC, conexão com o cluster e Service.kafkaConnects:— conectores Debezium opcionais para bancos como PostgreSQL, MySQL, SQL Server e Oracle.registryPushSecret:— Secret opcional para push de imagens de conectores.TDP-Settings:,ingress:egatewayApi:— controle de exposição da Kafka UI por Ingress ou Gateway API.
name: tdp-kafka
kafkaVersion: 4.1.0
metadataVersion: 4.1-IV1
listeners:
plain:
enabled: true
tls:
enabled: true
nodePool:
name: brokers
replicas: 4
tdp-kafka:
enabled: true
kafka-ui:
enabled: true
kafkaConnects:
postgres:
enabled: false
TDP-Settings:
gateway:
ingress:
enabled: false
gatewayApi:
enabled: false
Pré-requisitos
- Kubernetes 1.32+, Red Hat OpenShift 4.19+ ou Rancher Manager 2.10.x+.
- Helm 3.2.0+.
- StorageClass disponível com capacidade suficiente para os volumes dos brokers.
- CRDs do Strimzi instalados no cluster (veja seção abaixo).
Gerenciamento de CRDs do Strimzi
Os Custom Resource Definitions (CRDs) do Strimzi — como Kafka, KafkaNodePool, KafkaTopic, KafkaUser e KafkaConnect — são gerenciados separadamente do chart tdp-kafka. No TDP Kubernetes, esses CRDs são entregues pelo chart tdp-crds.
Os CRDs são recursos de escopo de cluster e não são removidos ao desinstalar o chart tdp-kafka.
Instalar CRDs antes da primeira instalação do Kafka
Antes de instalar o chart tdp-kafka pela primeira vez, instale o chart tdp-crds no cluster:
helm upgrade --install tdp-crds \
oci://registry.tecnisys.com.br/tdp/charts/tdp-crds \
-n <NAMESPACE> --create-namespace
Atualização de versão do Strimzi
Ao atualizar a versão do TDP, atualize o chart tdp-crds antes de executar o helm upgrade do tdp-kafka.
Solução de problemas: conflito de CRD
Se o helm install ou helm upgrade retornar um erro semelhante a:
conflict with "helm" using apiextensions.k8s.io/v1: .spec.versions
confirme se o chart tdp-crds já foi atualizado para a versão esperada e repita a instalação ou atualização do tdp-kafka.
- Instalação
- Parâmetros principais
- Detalhes de configuração
- Acesso & Segurança
- Solução de problemas
- Desinstalação
Instalação (OCI)
Para quem instala ou opera o cluster, o comando abaixo é o primeiro passo declarativo: o Helm aplica o chart tdp-kafka no namespace indicado e o Strimzi passa a reconciliar o estado desejado (brokers, Entity Operator, UI e, se habilitado, Connect). Os ajustes de comportamento — capacidade, listeners, replicação, senhas — vêm depois, via values.yaml ou helm upgrade com o mesmo release.
helm upgrade --install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-kafka -n <NAMESPACE> --create-namespace --timeout 10m
Validação pós-instalação
# Estado do cluster Kafka (recurso Strimzi)
kubectl get kafka -n <NAMESPACE>
# Node Pools do cluster
kubectl get kafkanodepools -n <NAMESPACE>
# Pods gerenciados pelo Strimzi
kubectl get pods -n <NAMESPACE> -l strimzi.io/cluster=<KAFKA_CLUSTER_NAME>
# Serviços gerados (bootstrap, brokers, UI)
kubectl get svc -n <NAMESPACE> | grep kafka
# KafkaConnect instances (Debezium)
kubectl get kafkaconnect -n <NAMESPACE>
# Conectores registrados
kubectl get kafkaconnector -n <NAMESPACE>
Parâmetros principais
A tabela a seguir resume chaves que costumam ser revisadas na primeira instalação e em upgrades: nome do cluster, versões KRaft, listeners, fatores de replicação, Entity Operator, dimensionamento do Node Pool e opções da Kafka UI. Para valores exatos de todas as chaves do chart, use helm show values na versão do pacote que você está implantando; aqui o foco é o que cada parâmetro controla na prática para quem opera o release.
| Parâmetro | Descrição | Valor padrão |
|---|---|---|
name | Nome do cluster Kafka | tdp-kafka |
kafkaVersion | Versão do Kafka | 4.1.0 |
metadataVersion | Versão de metadados KRaft | 4.1-IV1 |
clusterLabel | Label do cluster | tdp |
listeners.plain.enabled | Listener plain habilitado | true |
listeners.plain.port | Porta do listener plain | 9092 |
listeners.tls.enabled | Listener TLS habilitado | true |
listeners.tls.port | Porta do listener TLS | 9093 |
config.default.replication.factor | Fator de replicação padrão dos tópicos | 3 |
config.min.insync.replicas | Mínimo de réplicas síncronas | 2 |
entityOperator.enabled | Entity Operator habilitado | true |
nodePool.replicas | Número de brokers/controllers | 4 |
nodePool.storage.volumes[0].size | Tamanho do volume por nó | 10Gi |
kafka-ui.enabled | Kafka UI habilitada | true |
kafka-ui.service.type | Tipo do serviço da UI | ClusterIP |
kafka-ui.service.nodePort | NodePort da UI (quando type: NodePort) | 30081 |
config.offsets.topic.replication.factor | Fator de replicação do tópico de offsets | 3 |
config.transaction.state.log.replication.factor | Fator de replicação do log de transações | 3 |
nodePool.roles | Papéis dos nós (controller/broker) | ["controller","broker"] |
nodePool.storage.type | Tipo de storage | jbod |
security.enabled | Habilitar autenticação e ACLs no broker | false |
security.authentication.type | Tipo de autenticação Strimzi | scram-sha-512 |
security.authorization.type | Tipo de autorização Strimzi | simple |
kafka-ui.connection.bootstrapServers | Bootstrap server da Kafka UI | tdp-kafka-kafka-bootstrap:9092 |
kafka-ui.applicationConfig.auth.type | Tipo de autenticação da UI | LOGIN_FORM |
kafka-ui.rbac.enabled | Habilitar RBAC da Kafka UI | false |
ingress.annotations | Anotações do Ingress | {} |
TDP-Settings.gateway.ingress.enabled | Habilita Ingress para a Kafka UI | false |
TDP-Settings.gateway.gatewayApi.enabled | Habilita Gateway API (HTTPRoute) para a Kafka UI | false |
ingress.ingressClassName | IngressClass a usar | nginx |
ingress.hosts[0].host | Hostname do Ingress | kafka-ui.tdp.local |
gatewayApi.kafkaUi.enabled | Habilita HTTPRoute para a Kafka UI | true |
gatewayApi.kafkaUi.hostnames[0] | Hostname do HTTPRoute | kafka-ui.tdp.local |
nodePool.name | Nome do Node Pool | brokers |
security.listener | Listener protegido pela autenticação | plain |
security.users | Lista declarativa de KafkaUser com ACLs | [] |
kafka-ui.service.port | Porta do serviço da Kafka UI | 80 |
kafka-ui.connection.authentication.existingSecret.name | Secret com a senha do principal técnico da Kafka UI | "" |
kafka-ui.rbac.roles | Roles de RBAC da Kafbat UI | [] |
config.transaction.state.log.min.isr | ISR mínimo para o log de transações | 2 |
Configuração do cluster Kafka
Node Pool
Os Node Pools definem quantos nós existem, que papéis cada um exerce (metadados KRaft e/ou dados) e como o armazenamento se comporta ao escalar ou remover o recurso. Em ambientes pequenos, combinar controller e broker no mesmo pool simplifica a operação; à medida que a carga ou os requisitos de isolamento crescem, separar pools evita que operações de metadados e de I/O de dados disputem os mesmos recursos. As escolhas abaixo impactam diretamente custo de nós, capacidade de disco e o que acontece com os PVCs quando o release é removido.
No Strimzi com KRaft, os nós do cluster são declarados em Node Pools (KafkaNodePool). Cada pool define a quantidade de réplicas, os papéis exercidos pelos nós e o armazenamento.
nodePool:
name: brokers
replicas: 4
roles: ["controller", "broker"]
storage:
type: jbod
volumes:
- id: 0
type: persistent-claim
size: 10Gi
deleteClaim: true
kraftMetadata: shared
| Campo | Descrição |
|---|---|
roles | Um nó pode ser controller, broker ou ambos. Em clusters pequenos, combine os dois papéis. Em clusters grandes, separe-os em pools distintos |
storage.type: jbod | JBOD (Just a Bunch of Disks) permite múltiplos volumes por nó, maximizando throughput de I/O |
deleteClaim: true | Os PVCs serão excluídos ao remover o NodePool. Defina false em produção se quiser preservar os dados |
kraftMetadata: shared | Indica que este volume também armazena metadados KRaft |
Com 4 réplicas combinando controller e broker, o quórum KRaft e a replicação de dados coexistem nos mesmos nós. Para cargas intensas, considere pools separados: um pool de controllers (3 réplicas) e um pool de brokers (quantos forem necessários).
Versão e metadados
name: tdp-kafka
kafkaVersion: 4.1.0
metadataVersion: 4.1-IV1
clusterLabel: "tdp"
O campo metadataVersion é a versão de metadados do KRaft usada pelo cluster. Mantenha-o alinhado à kafkaVersion durante instalações novas. Em atualizações, aumente apenas após todos os brokers estarem na nova versão.
Listeners
Os listeners definem os pontos de entrada do cluster para produtores e consumidores.
Manter plain e tls habilitados é comum: o plain simplifica clientes internos na mesma rede do cluster (menos overhead de TLS), enquanto o TLS atende cenários em que a política de segurança ou a rede exigem criptografia em trânsito. A decisão prática é qual bootstrap e porta os aplicativos usarão; misturar sem critério pode gerar configuração inconsistente entre serviços. Os endereços de bootstrap listados mais abaixo são os que você repassa às equipes de aplicação.
listeners:
plain:
enabled: true
port: 9092
tls:
enabled: true
port: 9093
| Listener | Porta | Quando usar |
|---|---|---|
plain | 9092 | Comunicação interna ao cluster, ambientes de desenvolvimento ou redes privadas confiáveis |
tls | 9093 | Comunicação sobre redes não confiáveis ou quando clientes exigem criptografia em trânsito |
O nome do serviço de bootstrap segue a convenção Strimzi: <CLUSTER_NAME>-kafka-bootstrap. Exemplo com o nome padrão tdp-kafka:
- Plain:
tdp-kafka-kafka-bootstrap:9092 - TLS:
tdp-kafka-kafka-bootstrap:9093
Replicação e durabilidade
Os valores padrão abaixo priorizam durabilidade (mais cópias, min.insync.replicas alinhado a acks=all em clientes bem configurados) em detrimento de tolerar mais falhas simultâneas sem ajuste. Em troca, clusters com poucos brokers não podem honrar fatores de replicação maiores que o número de nós — daí a necessidade de alinhar estes números à topologia real antes de ir a produção.
config:
offsets.topic.replication.factor: 3
transaction.state.log.replication.factor: 3
transaction.state.log.min.isr: 2
default.replication.factor: 3
min.insync.replicas: 2
Estes parâmetros determinam o equilíbrio entre durabilidade e disponibilidade:
| Parâmetro | Significado |
|---|---|
default.replication.factor: 3 | Cada tópico terá 3 cópias distribuídas em brokers distintos |
min.insync.replicas: 2 | Um produtor com acks=all só recebe confirmação quando ao menos 2 réplicas estiverem sincronizadas. Tolera a perda de 1 broker sem perda de dados |
offsets.topic.replication.factor: 3 | Controla a durabilidade dos offsets dos consumidores (tópico interno __consumer_offsets) |
transaction.state.log.* | Durabilidade do log de transações (produção transacional / exactly-once) |
Em ambientes com menos de 3 brokers, reduza *.replication.factor e min.insync.replicas ao número real de nós. Manter fatores maiores que o número de brokers impede a criação de tópicos.
Entity Operator
entityOperator:
enabled: true
O Entity Operator é um componente do Strimzi que observa recursos KafkaTopic e KafkaUser no namespace e os reconcilia com o cluster. Com ele habilitado, tópicos e usuários podem ser gerenciados de forma declarativa como manifests Kubernetes, sem acesso direto à API administrativa do Kafka.
Kafka UI
O Kafka UI oferece uma interface gráfica para inspecionar tópicos, visualizar mensagens, monitorar grupos de consumidores e acompanhar métricas básicas do cluster.
Trate a UI como ferramenta operacional e de diagnóstico, não como substituto de controles de acesso do próprio Kafka: ela expõe visão sobre o cluster conforme a configuração de autenticação da aplicação web. O exemplo a seguir usa PLAINTEXT em relação ao bootstrap interno — coerente com rede de cluster, mas um alerta a mais para não expor a interface sem senha forte, rede adequada e, quando necessário, os mecanismos descritos na página de segurança.
kafka-ui:
enabled: true
applicationConfig:
auth:
type: LOGIN_FORM
spring:
security:
user:
name: admin
password: <PASSWORD>
connection:
clusterName: TDP
bootstrapServers: <CLUSTER_NAME>-kafka-bootstrap:9092
service:
type: ClusterIP
port: 80
nodePort: 30081
Substitua <CLUSTER_NAME> pelo valor de name definido no cluster (ex.: tdp-kafka) e <PASSWORD> por uma senha segura.
A conexão da UI com o cluster Kafka é configurada em kafka-ui.connection.bootstrapServers.
Para autenticação LDAP ou SCRAM no broker, consulte Segurança — Kafka.
yamlApplicationConfigConfigMapO chart gera automaticamente um ConfigMap (tdp-kafka-ui-config) a partir dos valores definidos em kafka-ui.applicationConfig. O campo kafka-ui.yamlApplicationConfig permanece null para que applicationConfig tenha precedência. Não é necessário alterar esses campos manualmente.
A senha admin (padrão do chart) não deve ser mantida em ambientes acessíveis fora da rede interna. Troque antes de expor a interface.
Kafka Connect / Debezium
O chart suporta conectores Debezium para captura de dados em tempo real (CDC).
A configuração é feita sob a chave kafkaConnects.*.
Tipos suportados: postgres, mysql, sqlserver, oracle.
Para cada tipo, é possível:
- Gerar o Secret automaticamente com as credenciais:
createSecret: true - Referenciar um Secret já existente:
createSecret: false+secretName
Exemplo mínimo para PostgreSQL usando Secret existente:
kafkaConnects:
postgres:
enabled: true
connect:
name: connect-debezium-postgres
replicas: 1
bootstrapServers: tdp-kafka-kafka-bootstrap:9092
kafkaVersion: "4.1.0"
connectors:
appdb:
enabled: true
name: debezium-postgres-appdb
topicPrefix: "pgapp"
postgres:
createSecret: false
secretName: "db-pg-appdb"
host: "tdp-postgresql-project.<NAMESPACE>.svc.cluster.local"
port: "5432"
dbname: "appdb"
user: "debezium"
O campo topicPrefix define o prefixo dos tópicos Kafka criados pelo conector
(por exemplo: pgapp.public.tabela).
O Strimzi cria um recurso KafkaConnect e um KafkaConnector para cada conector habilitado.
Verifique o status com:
kubectl get kafkaconnect -n <NAMESPACE>
kubectl get kafkaconnector -n <NAMESPACE>
Consulte Integrações — Kafka para exemplos completos de cada tipo de conector (PostgreSQL, MySQL, SQL Server, Oracle) e gestão de credenciais.
Acesso
ClusterIP / Port-forward (Kafka UI)
O serviço da Kafka UI usa o tipo ClusterIP por padrão.
Para acessar localmente sem expor a porta ao exterior:
kubectl port-forward svc/<RELEASE_NAME>-kafka-ui 8080:80 -n <NAMESPACE>
Acesse em http://localhost:8080.
kubectl port-forward svc/tdp-kafka-kafka-ui 8080:80 -n tdp-project
NodePort (Kafka UI)
Para expor via NodePort, defina kafka-ui.service.type: NodePort nos values.
A porta padrão é 30081, configurável em kafka-ui.service.nodePort.
kubectl get nodes -o wide
Acesse em http://<NODE_IP>:30081.
Ingress (Kafka UI)
Para expor a Kafka UI via Ingress, habilite TDP-Settings.gateway.ingress.enabled: true e configure o bloco ingress.* com o IngressClass, hostname e paths desejados.
TDP-Settings.gateway.ingress.enabled e TDP-Settings.gateway.gatewayApi.enabled são mutuamente exclusivos — ative somente um.
O Ingress publica apenas a interface web da Kafka UI.
Produtores e consumidores externos continuam precisando de configuração adicional para acessar os brokers (listeners Kafka).
Consulte Exposição externa — Kafka UI para o exemplo completo com YAML, IngressClass (incluindo OpenShift), ingress.tls e validação.
Gateway API (Kafka UI)
Para expor a Kafka UI via Kubernetes Gateway API, habilite TDP-Settings.gateway.gatewayApi.enabled: true e configure o bloco gatewayApi.*.
O chart cria automaticamente os recursos Gateway e HTTPRoute quando habilitado.
O Gateway API publica apenas a interface web da Kafka UI.
Produtores e consumidores externos continuam precisando de configuração adicional para acessar os brokers (listeners Kafka).
Consulte Exposição externa — Kafka UI para o exemplo completo com YAML, gatewayClassName, listeners, HTTPRoute, /etc/hosts e validação.
Bootstrap para produtores e consumidores
O endereço de bootstrap segue a convenção Strimzi:
<KAFKA_CLUSTER_NAME>-kafka-bootstrap.<NAMESPACE>.svc.cluster.local.
Com o valor padrão name: tdp-kafka:
# Plain (PLAINTEXT) — porta padrão 9092
tdp-kafka-kafka-bootstrap:9092
# TLS — porta padrão 9093
tdp-kafka-kafka-bootstrap:9093
Autenticação da UI
Consulte Segurança — Kafka para configurar autenticação LOGIN_FORM ou LDAP na interface web.
Solução de problemas
# Detalhes e eventos do cluster Kafka
kubectl describe kafka <KAFKA_CLUSTER_NAME> -n <NAMESPACE>
# Logs de um broker
kubectl logs -n <NAMESPACE> \
-l strimzi.io/cluster=<KAFKA_CLUSTER_NAME> \
-c kafka
# Logs da Kafka UI
kubectl logs -n <NAMESPACE> -l app.kubernetes.io/name=kafka-ui
# Detalhes de um conector com problema
kubectl describe kafkaconnector <CONNECTOR_NAME> -n <NAMESPACE>
Problemas comuns
| Problema | Causa provável | Ação |
|---|---|---|
Conflito de CRD na instalação (spec.versions) | CRDs Strimzi já existem no cluster | Confirme que o chart tdp-crds está na versão esperada e repita o helm upgrade do tdp-kafka |
Pods em Pending | StorageClass inexistente ou sem capacidade | kubectl get storageclass e kubectl describe pvc -n <NAMESPACE> |
| Kafka UI não conecta ao cluster | bootstrapServers incorreto ou credenciais Kafka | Confira kafka-ui.connection.bootstrapServers e o Secret referenciado em kafka-ui.connection.authentication.existingSecret |
| Broker não inicia | min.insync.replicas > número de brokers disponíveis | Ajuste config.min.insync.replicas ao número real de réplicas |
Conector em estado FAILED | Credenciais ou host do banco incorretos | kubectl describe kafkaconnector <CONNECTOR_NAME> -n <NAMESPACE> |
| Kafka UI não inicia (RBAC) | Recursos ou ações RBAC incompatíveis com a versão da UI | Verifique kafka-ui.rbac.roles e os logs do pod |
Pods com OOMKilled | Limites de CPU/memória insuficientes | Ajuste os limites de recursos dos pods via resources do subchart |
Comandos de diagnóstico
# Baixe o chart antes de validar:
helm pull oci://registry.tecnisys.com.br/tdp/charts/tdp-kafka --untar
helm lint tdp-kafka/
helm template tdp-kafka tdp-kafka/ -n <NAMESPACE>
# Estado do cluster e usuários
kubectl -n <NAMESPACE> get kafka
kubectl -n <NAMESPACE> get kafkauser
# Secrets gerados pelo Strimzi
kubectl -n <NAMESPACE> get secret
# Logs do operador Strimzi
kubectl -n <NAMESPACE> logs deployment/strimzi-cluster-operator
# Logs da Kafka UI
kubectl -n <NAMESPACE> logs deployment/<RELEASE_NAME>-kafka-ui
# Conectores
kubectl -n <NAMESPACE> get kafkaconnectors
kubectl -n <NAMESPACE> describe kafka <KAFKA_CLUSTER_NAME>
Desinstalação
helm uninstall <RELEASE_NAME> -n <NAMESPACE>
Os PVCs dos brokers não são removidos automaticamente pelo helm uninstall, salvo se nodePool.storage.volumes[].deleteClaim: true estiver configurado (padrão do chart).
Para remover PVCs manualmente (operação destrutiva e irreversível):
kubectl delete pvc -n <NAMESPACE> -l strimzi.io/cluster=<KAFKA_CLUSTER_NAME>