Ejecutar un broker MQTT en Kubernetes frente a usar un servicio gestionado

Ejecutar un broker MQTT en Kubernetes es una idea natural si tu equipo ya despliega allí todo lo demás. Este artículo compara ese camino con un servicio gestionado en cuanto a esfuerzo, actualizaciones, fiabilidad y factores de coste, y te ofrece un manifiesto funcional para probar. Terminarás sabiendo qué resuelve Kubernetes para un broker, qué no resuelve y qué opción encaja con tu equipo.

Por qué los equipos se plantean Kubernetes para MQTT

Kubernetes te ofrece despliegues declarativos, pods que se autorreparan, actualizaciones escalonadas, gestión de secretos y una cadena de herramientas coherente. Si tus servicios de backend, bases de datos y stack de observabilidad ya se ejecutan en un clúster, añadir allí el broker lo mantiene todo en un solo lugar y permite que los suscriptores lo alcancen por la red del clúster.

Pero un broker MQTT no es un servicio web sin estado típico. Entender qué hace un broker MQTT explica por qué: mantiene conexiones TCP de larga duración, conserva el estado de sesión de los clientes desconectados, almacena retained messages y reparte cada mensaje a todos los suscriptores que coinciden. Esas propiedades chocan con varias suposiciones de Kubernetes.

Un broker MQTT mínimo en Kubernetes

Aquí tienes un despliegue pequeño pero funcional de Mosquitto con autenticación por contraseña. Es adecuado para un clúster de laboratorio y una buena forma de familiarizarte con las piezas.

Primero crea un archivo de contraseñas y guárdalo como secreto:

mosquitto_passwd -c -b passwd device01 'change-this-password'
kubectl create namespace mqtt
kubectl -n mqtt create secret generic mosquitto-passwd --from-file=passwd

Después aplica la configuración, el despliegue y el servicio:

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

Pruébalo desde fuera del clúster en cuanto el balanceador de carga tenga una dirección:

mosquitto_sub -h <LOAD_BALANCER_IP> -p 1883 -u device01 -P 'change-this-password' -i k8s-sub -t 'test/#' -v

Funciona, pero fíjate en lo que falta: TLS, renovación de certificados, monitorización, alertas, copias de seguridad y cualquier forma de alta disponibilidad. Añadir todo eso es donde está el esfuerzo real.

Lo que Kubernetes no resuelve para MQTT

Conexiones de larga duración y actualizaciones escalonadas

Una actualización escalonada reemplaza los pods uno a uno. Para un servicio HTTP, eso es invisible. Para un broker, cada reinicio de pod desconecta a todos sus clientes a la vez, y estos se reconectan simultáneamente. Los drenajes de nodos, las actualizaciones del clúster y la consolidación del autoescalador provocan el mismo efecto. Necesitas dispositivos con backoff exponencial aleatorio, un PodDisruptionBudget y ventanas de mantenimiento para los cambios en el broker.

Estado y almacenamiento

Las sesiones persistentes y los retained messages necesitan un almacenamiento que sobreviva a la reprogramación de pods. Un StatefulSet con volúmenes persistentes lo resuelve para un solo nodo, pero los volúmenes suelen estar ligados a una zona de disponibilidad, lo que limita adónde puede moverse el pod durante una caída.

Balancear la carga no es crear un clúster

Escalar un broker de un solo nodo a tres réplicas detrás de un balanceador de carga no crea un clúster. Cada réplica sería un broker independiente, y un publicador en una no llegaría a un suscriptor en otra. El escalado horizontal real necesita un broker diseñado para clustering, normalmente desplegado con el Helm chart o el operador de Kubernetes de su fabricante. La comparativa de brokers MQTT de código abierto muestra qué proyectos lo admiten.

TLS en el borde del clúster

Puedes terminar TLS en el balanceador de carga de la nube o en el broker. Terminarlo en el broker mantiene el cifrado de extremo a extremo, pero implica montar certificados y recargarlos al renovarse, normalmente con cert-manager. Terminarlo en el balanceador es más sencillo, pero requiere cuidado si dependes de certificados de cliente.

Observabilidad

Tendrás que exportar las métricas del broker a tu stack de monitorización, construir paneles y definir alertas sobre caídas de conexión, tasas de mensajes y uso de recursos. Consulta monitorización de un broker MQTT para ver las métricas que importan.

Kubernetes frente a servicio gestionado, cara a cara

Entender los factores de coste

Comparar costes con honestidad implica mirar más allá de la factura de cómputo. Para un broker alojado en Kubernetes, el coste incluye:

1. Infraestructura: capacidad de nodos reservada para los pods del broker, volúmenes persistentes y balanceadores de carga con IP públicas.
2. Transferencia de datos: salida desde tu proveedor de nube para los mensajes entregados a clientes fuera de la nube.
3. Tiempo de ingeniería para construirlo: manifiestos o valores de Helm, automatización de TLS, autenticación, paneles y alertas.
4. Tiempo de ingeniería para operarlo: actualizaciones, parches de seguridad, revisiones de capacidad, respuesta a incidentes y guardias.
5. Riesgo: el coste de una caída o un incidente de seguridad causado por una mala configuración.

Con un broker gestionado, como un clúster Dedicated, la mayor parte de los puntos 3 a 5 pasa a la suscripción, y pagas el plan en lugar de la infraestructura subyacente. Un ejercicio útil es estimar las horas al mes que tu equipo dedicaría a los puntos 3 y 4, multiplicarlas por una tarifa horaria con cargas incluidas y sumarlas a la línea de infraestructura. Después compara ese total con el coste del plan o el presupuesto de una opción gestionada, como ConnectMQ Dedicated. Nuestra guía sobre el coste total de propiedad de un broker MQTT recorre este cálculo.

Cuándo Kubernetes es la opción correcta

Ejecutar tú mismo el broker en Kubernetes tiene sentido cuando:

• Tienes un equipo de plataforma que ya opera bien cargas de trabajo con estado.
• Necesitas plugins o personalizaciones del broker que un servicio gestionado no ofrece.
• El broker debe ejecutarse en un clúster aislado de la red (air-gapped) o local.
• Tu número de dispositivos es estable y está bien entendido.

Un servicio gestionado suele encajar mejor cuando tu equipo es pequeño, MQTT es crítico pero no es tu producto principal o necesitas estar listo para producción rápidamente.

El término medio: gestionado, pero en tu nube

Si lo que te atrae de Kubernetes es mantener el broker dentro de tu propio entorno de nube, hay una tercera opción. ConnectMQ BYOC ejecuta el broker en tu cuenta de nube y ConnectMQ lo gestiona, de modo que la infraestructura sigue siendo tuya mientras las actualizaciones, los certificados y la monitorización del broker corren de nuestra cuenta. Un plan Dedicated ofrece un clúster aislado sin ningún trabajo de infraestructura por tu parte. Ambos exponen endpoints estándar: TCP 1883, TLS 8883, WebSocket 8083 y Secure WebSocket 8084 en /mqtt, con certificados de Let's Encrypt, para clientes MQTT 3.1.1 y 5.0.

Empieza con ConnectMQ

Antes de escribir otro archivo de valores de Helm, prueba gratis un broker MQTT gestionado. Crea un broker Serverless en app.connectmq.com, sin tarjeta de crédito, y apunta a él los mismos clientes que probaste en Kubernetes. También puedes experimentar al instante en el servidor MQTT público gratuito (solo para pruebas, nunca para datos de producción) y leer la guía de broker MQTT en la nube para una visión más amplia de los modelos de alojamiento.

Preguntas frecuentes

¿Puedo escalar Mosquitto en Kubernetes añadiendo réplicas?

No. Cada réplica sería un broker independiente, así que los mensajes no fluirían entre ellas. El escalado horizontal requiere un broker diseñado para clustering.

¿Por qué se desconectan mis clientes MQTT durante las actualizaciones de Kubernetes?

Los reinicios de pods y los drenajes de nodos cierran todas las conexiones de ese pod. Usa PodDisruptionBudgets, ventanas de mantenimiento y backoff de reconexión con jitter en el cliente.

¿Debo terminar TLS en el balanceador de carga o en el broker?

Terminarlo en el broker mantiene el cifrado de extremo a extremo y conserva la autenticación con certificado de cliente; terminarlo en el balanceador es más sencillo de gestionar. Elige según tu modelo de autenticación.

¿Un broker gestionado es más caro que Kubernetes?

Compara el coste total, incluido el tiempo de ingeniería para la puesta en marcha, las actualizaciones y las guardias, no solo el cómputo. Para muchos equipos pequeños, la opción gestionada cuesta menos en conjunto.