Faire tourner un broker MQTT sur Kubernetes ou passer par un broker MQTT managé ?

Faire tourner un broker MQTT sur Kubernetes est une idée naturelle si votre équipe y déploie déjà tout le reste. Cet article compare cette approche avec un broker MQTT managé en termes d'effort, de mises à jour, de fiabilité et de postes de coût, et vous fournit un manifeste fonctionnel à tester. Vous saurez ensuite ce que Kubernetes résout pour un broker, ce qu'il ne résout pas, et quelle option convient à votre équipe.

Pourquoi les équipes envisagent Kubernetes pour MQTT

Kubernetes apporte des déploiements déclaratifs, des pods qui se réparent d'eux-mêmes, des rolling updates, la gestion des secrets et une chaîne d'outils cohérente. Si vos services backend, vos bases de données et votre stack d'observabilité tournent déjà dans un cluster, y ajouter le broker permet de tout garder au même endroit et laisse les abonnés le joindre via le réseau du cluster.

Mais un broker MQTT n'est pas un service web stateless comme les autres. Comprendre le rôle d'un broker MQTT explique pourquoi : il maintient des connexions TCP de longue durée, conserve l'état des sessions pour les clients hors ligne, stocke les retained messages et diffuse chaque message à tous les abonnés concernés. Ces propriétés entrent en conflit avec plusieurs hypothèses de Kubernetes.

Un broker MQTT minimal sur Kubernetes

Voici un déploiement Mosquitto réduit mais fonctionnel, avec authentification par mot de passe. Il convient à un cluster de test et permet de bien saisir les pièces du puzzle.

Créez d'abord un fichier de mots de passe et stockez-le dans un 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

Appliquez ensuite la configuration, le déploiement et le 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

Testez-le depuis l'extérieur du cluster une fois que le load balancer a obtenu une adresse :

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

Cela fonctionne, mais remarquez ce qui manque : TLS, le renouvellement des certificats, la supervision, l'alerting, les sauvegardes et toute forme de haute disponibilité. C'est en ajoutant tout cela que se situe le véritable effort.

Ce que Kubernetes ne résout pas pour MQTT

Connexions longues et rolling updates

Un rolling update remplace les pods un par un. Pour un service HTTP, c'est invisible. Pour un broker, chaque redémarrage de pod déconnecte d'un coup tous ses clients, qui se reconnectent tous en même temps. Les drains de nœuds, les mises à niveau du cluster et la consolidation par l'autoscaler provoquent le même effet. Il vous faut des appareils avec un backoff exponentiel aléatoire, un PodDisruptionBudget et des fenêtres de maintenance pour les changements du broker.

État et stockage

Les sessions persistantes et les retained messages exigent un stockage qui survit à la replanification des pods. Un StatefulSet avec des volumes persistants gère cela pour un nœud unique, mais les volumes sont généralement liés à une seule zone de disponibilité, ce qui limite les endroits où le pod peut être déplacé en cas de panne.

Répartir la charge n'est pas faire du clustering

Passer un broker mono-nœud à trois réplicas derrière un load balancer ne crée pas un cluster. Chaque réplica serait un broker indépendant, et un éditeur connecté à l'un n'atteindrait pas un abonné connecté à un autre. Une vraie montée en charge horizontale exige un broker conçu pour le clustering, généralement déployé avec le chart Helm ou l'opérateur Kubernetes de son éditeur. Le comparatif des brokers MQTT open source indique quels projets le permettent.

TLS en bordure du cluster

Vous pouvez terminer TLS au niveau du load balancer cloud ou du broker. Le terminer au broker préserve le chiffrement de bout en bout, mais impose de monter les certificats et de les recharger à chaque renouvellement, généralement avec cert-manager. Le terminer au load balancer est plus simple, mais demande de la vigilance si vous vous appuyez sur des certificats clients.

Observabilité

Vous devrez exporter les métriques du broker vers votre stack de supervision, construire des tableaux de bord et définir des alertes sur les déconnexions, les débits de messages et la consommation de ressources. Consultez la supervision d'un broker MQTT pour connaître les métriques qui comptent.

Kubernetes ou service managé : comparaison point par point

Comprendre les postes de coût

Comparer honnêtement les coûts implique de regarder au-delà de la facture de calcul. Pour un broker hébergé sur Kubernetes, le coût comprend :

1. L'infrastructure : la capacité des nœuds réservée aux pods du broker, les volumes persistants et les load balancers avec IP publiques.
2. Le transfert de données : le trafic sortant facturé par votre fournisseur cloud pour les messages livrés aux clients situés hors du cloud.
3. Le temps d'ingénierie pour construire : manifestes ou valeurs Helm, automatisation TLS, authentification, tableaux de bord et alertes.
4. Le temps d'ingénierie pour exploiter : mises à jour, correctifs de sécurité, revues de capacité, gestion des incidents et astreintes.
5. Le risque : le coût d'une panne ou d'un incident de sécurité causé par une erreur de configuration.

Avec un broker MQTT managé comme un cluster Dedicated, l'essentiel des points 3 à 5 est inclus dans l'abonnement, et vous payez le plan plutôt que l'infrastructure sous-jacente. Un exercice utile consiste à estimer les heures que votre équipe consacrerait chaque mois aux points 3 et 4, à les multiplier par un taux horaire chargé et à ajouter le résultat à la ligne infrastructure. Comparez ensuite ce total au prix du plan ou au devis d'une option managée, comme ConnectMQ Dedicated. Notre guide sur le coût total de possession d'un broker MQTT détaille ce calcul.

Quand Kubernetes est le bon choix

Exploiter vous-même le broker sur Kubernetes est pertinent lorsque :

• Vous disposez d'une équipe plateforme qui exploite déjà bien des workloads stateful.
• Vous avez besoin de plugins ou de personnalisations du broker qu'un service managé ne propose pas.
• Le broker doit tourner dans un cluster isolé (air-gapped) ou sur site.
• Votre nombre d'appareils est stable et bien connu.

Un service managé convient généralement mieux lorsque votre équipe est réduite, que MQTT est critique sans être votre produit principal, ou que vous devez être prêt pour la production rapidement.

La voie médiane : managé, mais dans votre cloud

Si ce qui vous attire dans Kubernetes est de garder le broker dans votre propre environnement cloud, il existe une troisième option. ConnectMQ BYOC fait tourner le broker dans votre compte cloud et ConnectMQ le gère : l'infrastructure reste la vôtre, tandis que les mises à jour, les certificats et la supervision du broker sont pris en charge pour vous. Un plan Dedicated offre un cluster isolé sans aucun travail d'infrastructure de votre côté. Les deux exposent des endpoints standard : TCP 1883, TLS 8883, WebSocket 8083 et Secure WebSocket 8084 sur /mqtt, avec des certificats Let's Encrypt, pour les clients MQTT 3.1.1 et 5.0.

Démarrer avec ConnectMQ

Avant d'écrire un énième fichier de valeurs Helm, essayez gratuitement un broker MQTT managé. Créez un broker Serverless sur app.connectmq.com, sans carte bancaire, et pointez-y les clients que vous avez testés sur Kubernetes. Vous pouvez aussi expérimenter immédiatement sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes et jamais aux données de production, et lire le guide du broker MQTT cloud pour une vue d'ensemble des modèles d'hébergement.

Questions fréquentes

Puis-je faire monter Mosquitto en charge sur Kubernetes en ajoutant des réplicas ?

Non. Chaque réplica serait un broker indépendant, et les messages ne circuleraient pas entre eux. La montée en charge horizontale exige un broker conçu pour le clustering.

Pourquoi mes clients MQTT se déconnectent-ils pendant les mises à niveau Kubernetes ?

Les redémarrages de pods et les drains de nœuds ferment toutes les connexions du pod concerné. Utilisez des PodDisruptionBudgets, des fenêtres de maintenance et un backoff de reconnexion côté client avec jitter.

Faut-il terminer TLS au load balancer ou au broker ?

Le terminer au broker préserve le chiffrement de bout en bout et l'authentification par certificat client ; le terminer au load balancer est plus simple à gérer. Choisissez en fonction de votre modèle d'authentification.

Un broker MQTT managé coûte-t-il plus cher que Kubernetes ?

Comparez le coût total, y compris le temps d'ingénierie pour la mise en place, les mises à jour et les astreintes, et pas seulement le calcul. Pour beaucoup de petites équipes, l'option managée revient moins cher au final.