Rodar um broker MQTT no Kubernetes é uma ideia natural se a sua equipe já implanta todo o resto lá. Este artigo compara esse caminho com um broker MQTT gerenciado em termos de esforço, upgrades, confiabilidade e fatores de custo, e traz um manifesto funcional para você testar. Ao final, você saberá o que o Kubernetes resolve para um broker, o que ele não resolve e qual opção combina com a sua equipe.
Por Que as Equipes Consideram o Kubernetes para MQTT
O Kubernetes oferece implantações declarativas, pods que se recuperam sozinhos, rolling updates, gestão de secrets e um conjunto consistente de ferramentas. Se os seus serviços de back-end, bancos de dados e a stack de observabilidade já rodam em um cluster, colocar o broker ali mantém tudo em um só lugar e permite que os assinantes o alcancem pela rede do cluster.
Mas um broker MQTT não é um serviço web stateless típico. Entender o que um broker MQTT faz explica por quê: ele mantém conexões TCP de longa duração, guarda o estado de sessão de clientes offline, armazena retained messages e distribui cada mensagem para todos os assinantes correspondentes. Essas propriedades entram em conflito com várias premissas do Kubernetes.
Um Broker MQTT Mínimo no Kubernetes
Veja abaixo uma implantação pequena, mas funcional, do Mosquitto com autenticação por senha. Ela serve para um cluster de laboratório e é uma boa forma de sentir as peças em movimento.
Primeiro, crie um arquivo de senhas e armazene-o como secret:
mosquitto_passwd -c -b passwd device01 'change-this-password'
kubectl create namespace mqtt
kubectl -n mqtt create secret generic mosquitto-passwd --from-file=passwd
Depois aplique a configuração, a implantação e o service:
apiVersion: v1
kind: ConfigMap
metadata:
name: mosquitto-config
namespace: mqtt
data:
mosquitto.conf: |
listener 1883
allow_anonymous false
password_file /mosquitto/secret/passwd
persistence true
persistence_location /mosquitto/data/
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mosquitto
namespace: mqtt
spec:
serviceName: mosquitto
replicas: 1
selector:
matchLabels:
app: mosquitto
template:
metadata:
labels:
app: mosquitto
spec:
terminationGracePeriodSeconds: 30
containers:
- name: mosquitto
image: eclipse-mosquitto:2
ports:
- containerPort: 1883
volumeMounts:
- name: config
mountPath: /mosquitto/config
- name: passwd
mountPath: /mosquitto/secret
- name: data
mountPath: /mosquitto/data
resources:
requests:
cpu: 100m
memory: 64Mi
limits:
memory: 256Mi
volumes:
- name: config
configMap:
name: mosquitto-config
- name: passwd
secret:
secretName: mosquitto-passwd
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
name: mosquitto
namespace: mqtt
spec:
type: LoadBalancer
selector:
app: mosquitto
ports:
- name: mqtt
port: 1883
targetPort: 1883
Teste a partir de fora do cluster assim que o load balancer tiver um endereço:
mosquitto_sub -h <LOAD_BALANCER_IP> -p 1883 -u device01 -P 'change-this-password' -i k8s-sub -t 'test/#' -v
Funciona, mas repare no que está faltando: TLS, renovação de certificados, monitoramento, alertas, backups e qualquer forma de alta disponibilidade. É ao adicionar esses itens que está o esforço de verdade.
O Que o Kubernetes Não Resolve para o MQTT
Conexões de Longa Duração e Rolling Updates
Um rolling update substitui os pods um a um. Para um serviço HTTP, isso é invisível. Para um broker, cada reinício de pod desconecta todos os seus clientes de uma vez, e eles reconectam simultaneamente. Drenagens de nós, upgrades do cluster e consolidações do autoscaler provocam o mesmo efeito. Você precisa de dispositivos com backoff exponencial aleatório, um PodDisruptionBudget e janelas de manutenção para mudanças no broker.
Estado e Armazenamento
Sessões persistentes e retained messages precisam de um armazenamento que sobreviva ao reagendamento do pod. Um StatefulSet com volumes persistentes resolve isso para um único nó, mas os volumes geralmente ficam presos a uma zona de disponibilidade, o que limita para onde o pod pode ir durante uma falha.
Balanceamento de Carga Não É Clustering
Escalar um broker de nó único para três réplicas atrás de um load balancer não cria um cluster. Cada réplica seria um broker independente, e um publicador em uma delas não alcançaria um assinante em outra. A escala horizontal de verdade exige um broker projetado para clustering, normalmente implantado com o Helm chart ou o operador Kubernetes do próprio fornecedor. A comparação de brokers MQTT open source mostra quais projetos suportam isso.
TLS na Borda do Cluster
Você pode terminar o TLS no load balancer da nuvem ou no broker. Terminar no broker mantém a criptografia de ponta a ponta, mas exige montar os certificados e recarregá-los na renovação, normalmente com o cert-manager. Terminar no load balancer é mais simples, mas exige cuidado se você depende de certificados de cliente.
Observabilidade
Você vai precisar exportar as métricas do broker para a sua stack de monitoramento, construir dashboards e definir alertas para quedas de conexão, taxas de mensagens e uso de recursos. Veja monitoramento de broker MQTT para as métricas que importam.
Kubernetes vs Broker MQTT Gerenciado: Lado a Lado
| Aspecto | Broker no seu cluster Kubernetes | Broker MQTT gerenciado |
|---|---|---|
| Configuração inicial | Manifestos ou Helm, load balancer, DNS, TLS | Criar o broker em um portal |
| Certificados TLS | Você instala o cert-manager ou similar | Fornecidos e renovados |
| Upgrades | Você planeja, testa e aplica | Feitos pelo provedor |
| Alta disponibilidade | Broker em cluster mais design multizona | Responsabilidade do provedor |
| Monitoramento | Você exporta métricas e cria alertas | Console integrado mais suas próprias verificações |
| Hardening de segurança | Você configura autenticação, limites de taxa, patches | O provedor aplica as proteções da plataforma |
| Flexibilidade | Controle total do broker e dos plugins | Dentro do conjunto de recursos do provedor |
| Proximidade de rede | Mesmo cluster dos seus serviços | Endpoints públicos, ou BYOC na sua conta |
Entendendo os Fatores de Custo
Comparar custos com honestidade significa olhar além da fatura de computação. Para um broker hospedado no Kubernetes, o custo inclui:
- Infraestrutura: capacidade de nós reservada para os pods do broker, volumes persistentes e load balancers com IPs públicos.
- Transferência de dados: egress do seu provedor de nuvem para mensagens entregues a clientes fora da nuvem.
- Tempo de engenharia para construir: manifestos ou valores do Helm, automação de TLS, autenticação, dashboards e alertas.
- Tempo de engenharia para operar: upgrades, patches de segurança, revisões de capacidade, resposta a incidentes e cobertura de plantão.
- Risco: o custo de uma indisponibilidade ou de um incidente de segurança causado por uma configuração incorreta.
Para um broker MQTT gerenciado, como um cluster Dedicated, a maior parte dos itens 3 a 5 passa para a assinatura, e você paga pelo plano em vez da infraestrutura subjacente. Um exercício útil é estimar as horas mensais que a sua equipe gastaria nos itens 3 e 4, multiplicar por um custo-hora com encargos e somar à linha de infraestrutura. Depois compare esse total com o custo do plano ou a cotação de uma opção gerenciada, como o ConnectMQ Dedicated. Nosso guia de custo total de propriedade de um broker MQTT percorre esse cálculo.
Quando o Kubernetes É a Escolha Certa
Rodar o broker por conta própria no Kubernetes faz sentido quando:
- Você tem uma equipe de plataforma que já opera bem cargas de trabalho stateful.
- Você precisa de plugins ou customizações de broker que um broker MQTT gerenciado não oferece.
- O broker precisa rodar em um cluster isolado (air-gapped) ou on-premises, como no data center de uma planta industrial.
- O número de dispositivos é estável e bem conhecido.
Um broker MQTT gerenciado costuma ser a melhor escolha quando a sua equipe é pequena, o MQTT é crítico, mas não é o seu produto principal, ou você precisa estar pronto para produção rapidamente.
O Meio-Termo: Gerenciado, Mas na Sua Nuvem
Se o que atrai você no Kubernetes é manter o broker dentro do seu próprio ambiente de nuvem, existe uma terceira opção. O BYOC do ConnectMQ roda o broker na sua conta de nuvem e o ConnectMQ o gerencia, de modo que a infraestrutura continua sendo sua enquanto upgrades, certificados e monitoramento do broker ficam por nossa conta. O plano Dedicated oferece um cluster isolado sem nenhum trabalho de infraestrutura do seu lado. Ambos expõem endpoints padrão: TCP 1883, TLS 8883, WebSocket 8083 e Secure WebSocket 8084 em /mqtt, com certificados Let's Encrypt, para clientes MQTT 3.1.1 e 5.0.
Comece com o ConnectMQ
Antes de escrever mais um arquivo de valores do Helm, experimente um broker MQTT gerenciado gratuitamente. Crie um broker Serverless em app.connectmq.com, sem cartão de crédito, e aponte para ele os mesmos clientes que você testou no Kubernetes. Você também pode experimentar na hora no servidor MQTT público (gratuito, apenas para testes, sem dados de produção) e ler o guia de broker MQTT na nuvem para uma visão mais ampla dos modelos de hospedagem.
Perguntas frequentes
Posso escalar o Mosquitto no Kubernetes adicionando réplicas?
Não. Cada réplica seria um broker independente, então as mensagens não fluiriam entre elas. A escala horizontal exige um broker construído para clustering.
Por que meus clientes MQTT desconectam durante upgrades do Kubernetes?
Reinícios de pods e drenagens de nós fecham todas as conexões daquele pod. Use PodDisruptionBudgets, janelas de manutenção e backoff de reconexão com jitter no lado do cliente.
Devo terminar o TLS no load balancer ou no broker?
Terminar no broker mantém a criptografia de ponta a ponta e preserva a autenticação por certificado de cliente; terminar no load balancer é mais simples de gerenciar. Escolha com base no seu modelo de autenticação.
Um broker MQTT gerenciado é mais caro que o Kubernetes?
Compare o custo total, incluindo o tempo de engenharia para configuração, upgrades e plantão, e não apenas a computação. Para muitas equipes pequenas, a opção gerenciada custa menos no geral.
