Streaming & Messaging — Hikube

Kafka, RabbitMQ, NATS.
kubectl apply — c'est tout.

Trois services de messagerie entièrement managés sur Hikube. Event streaming distribué, task queues AMQP, pub/sub ultra-léger. Réplication automatique, ZooKeeper coordonné, JetStream inclus. 

CONTACTEZ NOS EXPERTS DOCUMENTATION

 3  services 

 Kafka · RabbitMQ · NATS 

 HA native

 Réplication + quorum
automatiques 

 >1  ms

 Latence NATS
 (même datacenter) 

 0 config

 ZooKeeper, Sentinel, Raft — gérés 
Comparatif

Le bon service pour chaque pattern

Kafka, RabbitMQ et NATS répondent à des besoins distincts. Le choix dépend du volume, du modèle de livraison et de la durabilité requise.  

SERVICE
PROTOCOLE
MODÈLE
PERSISTANCE
CAS D'USAGE
Kafka
Kafka
TCP binaire
Pub/Sub avec log distribué
Oui — rétention configurable
Event streaming, pipelines de données, analytics temps réel
RabbitMQ
RabbitMQ
AMQP
File d'attente avec routing
Oui — quorum queues (Raft)
Task queues, RPC, routing complexe, workflows asynchrones
Frame 11502-2
NATS
TCP texte
Pub/Sub + Request/Reply
Optionnel — JetStream
Microservices, IoT, edge, communication légère temps réel
SERVICES

Chaque service en détail

Kafka

Strimzi Operator ZooKeeper Log distribué

 Kafka organise les messages en topics divisés en partitions, distribuées sur plusieurs brokers. Chaque partition est répliquée selon le replicationFactor. En cas de panne d'un broker, les partitions sont redirigées vers les réplicas disponibles. ZooKeeper coordonne l'élection des leaders et stocke les métadonnées du cluster.

Contrairement à RabbitMQ, Kafka conserve les messages après leur consommation. La durée de rétention est configurable par topic (retention.ms). Plusieurs consumer groups peuvent lire le même topic indépendamment, chacun maintenant son propre offset. 

  • Topics déclarés dans le manifeste

    Partitions, facteur de réplication, rétention et cleanup policy configurés directement dans le YAML. Pas besoin d'outils externes pour créer les topics.
  • ZooKeeper managé

    3 instances ZooKeeper coordonnent le cluster automatiquement. Le quorum impair est garanti une panne de nœud ZK n’interrompt pas le service.
  • Rétention et compaction

    cleanup.policy: delete supprime les messages après retention.ms. cleanup.policy: compact conserve uniquement le dernier message par clé, idéal pour les tables de référence.
  • Exposition externe optionnelle

    external: true crée un LoadBalancer par broker pour les clients hors cluster. À éviter sans authentification configurée.     
yaml
apiVersion: apps.cozystack.io/v1alpha1
kind: Kafka 
  metadata:
name: example
spec:
  external: false
  kafka:
    replicas: 3
    resourcesPreset: small
    size: 10Gi
    storageClass: replicated
  zookeeper:
    replicas: 3 # Toujours impair
    resourcesPreset: small
    size: 5Gi
    storageClass: replicated
topics:
  - name: my-topic
    partitions: 3
    replicas: 3
    config:
      retention.ms: "604800000" # 7 jours
      cleanup policy: "delete" 


 
Pourquoi managé

Ce que vous n'avez plus à faire 

 Kafka, RabbitMQ et NATS sont trois systèmes distribués différents, mais ils partagent le même problème en auto-hébergé : chacun demande une expertise dédiée pour être opéré correctement en production. Dimensionner les nœuds, configurer le quorum, tester le failover, gérer les montées de version sans interrompre le flux de messages représente du temps d'ingénierie qui ne produit pas de valeur métier.


Sur Hikube, l'opérateur Kubernetes absorbe cette charge pour les trois services. Vous déclarez ce que vous voulez, nombre de nœuds, topics ou vhosts, ressources, et l'opérateur provisionne, réplique et bascule en cas de panne. Modifier la configuration revient à changer une valeur dans un fichier YAML et appliquer. 

markup-cropped-1

Quorum et consensus automatiques

ZooKeeper pour Kafka, Raft pour RabbitMQ et NATS JetStream. Les mécanismes d'élection de leader sont configurés et monitorés sans intervention manuelle. 

markup-cropped-1

Topics, vhosts et streams avec le cluster


Partitions, rétention, virtual hosts, streams JetStream déclarés en YAML au même endroit. Pas de script d'initialisation séparé à maintenir. 

markup-cropped-1

Scaling sans interruption


Modifiez le nombre de nœuds dans le manifeste et appliquez. L'opérateur ajoute les instances en rolling update sans rebalancing manuel, sans downtime. 

markup-cropped-1

Credentials auto-générés


Les mots de passe sont créés dans un Secret Kubernetes au provisioning. Référencez le Secret dans vos pods, aucune clé en clair dans vos manifestes ou dépôts Git. 

Cas d'usage

Quel service pour quel besoin ? 

Les trois services ne se concurrencent pas, ils se complètent. Voici les patterns concrets où chacun s'impose. 

Pipeline de logs applicatifs

Ingestion de millions d'événements de logs depuis 50 microservices. Rétention 7 jours, plusieurs consumers indépendants (Elasticsearch, ClickHouse, alerting). Chaque consumer relit depuis son propre offset.

3 brokers · 3 partitions · retention.ms: 604800000

Event sourcing et audit trail

Chaque action utilisateur est publiée sur un topic avec cleanup.policy: compact. L'état courant est la somme des événements. Le topic compact garantit la conservation du dernier état par clé.

cleanup.policy: compact · replicas: 3 · min.insync: 2

File de traitement d'emails

 Les commandes déclenchent un message dans une queue emails.pending. Des workers lisent la queue, envoient l'email, et ACK le message. Si un worker tombe, le message est re-queued automatiquement. 

replicas: 3 · quorum queues · ACK/NACK

Routing d'événements multi-destinations

 Un exchange de type topic route les événements orders.* vers la queue facturation, orders.shipped vers la queue logistique, et # vers une queue d'audit. Un seul publish, plusieurs destinations. 

exchange: topic · bindings · 3 queues

Communication inter-microservices

 Service A appelle service B via request/reply NATS plutôt qu'HTTP. Pas de service discovery, pas de load balancer. NATS route directement vers un subscriber disponible dans le queue group. 

Request/Reply · queue groups · <1ms latency

Telemetry IoT avec JetStream

 10 000 capteurs publient des métriques sur sensors.>. JetStream stocke 24h de données. Les services d'analyse se connectent et rejouent l'historique au démarrage. Utile après une maintenance. 

JetStream · 24h retention · replay on connect
Streaming & Messaging managés

L'event-driven, socle des architectures modernes 

Les architectures orientées événements sont devenues le standard des systèmes distribués modernes. Là où les APIs synchrones créent des couplages fragiles, les brokers de messages permettent aux services de communiquer sans dépendance directe. Chaque service produit ou consomme des événements à son propre rythme.

Kafka structure les pipelines de données à fort volume, logs, métriques, événements métiers, avec une rétention longue et un replay d'événements qui simplifie l'audit et la reprise après incident. RabbitMQ assure l'acheminement fiable des tâches critiques : chaque message est traité exactement une fois, avec garantie de livraison. NATS réduit la friction entre microservices grâce à une communication légère, une latence microseconde et sans infrastructure lourde.

En version managée, vos équipes adoptent ces patterns sans repartir de zéro sur l'infrastructure. Même technologie, mêmes SDKs, mêmes outils, déployés et opérés par Hikube. 

markup-cropped-1

Découplage et résilience applicative


Un service en panne n'entraîne pas les autres. Les messages s'accumulent dans le broker et sont traités à la reprise, sans perte ni intervention manuelle. 

markup-cropped-1

IoT et edge computing


NATS ingère des millions d'événements de capteurs avec une empreinte mémoire minimale. JetStream garantit que les données ne sont pas perdues si un service de traitement redémarre. 

markup-cropped-1

Data streaming et analytics temps réel


Alimentez ClickHouse, Elasticsearch ou vos dashboards Grafana en continu depuis Kafka. Le même topic peut nourrir plusieurs consumers indépendants simultanément. 

markup-cropped-1

Compatible avec votre stack


Kafka Connect, Confluent SDKs, pika, nats.go, nats.py. Tous les clients existants fonctionnent sans modification. Pointez vers le service Kubernetes, le reste est identique. 

FAQ

Question sur le Streaming & Messaging Managés

Kafka ou RabbitMQ, comment choisir ?

Kafka est fait pour le streaming à fort volume et la rétention longue — les messages restent disponibles après consommation, plusieurs consumers peuvent lire le même topic indépendamment. C'est le choix naturel pour les pipelines de données, l'event sourcing et les analytics temps réel.

RabbitMQ est fait pour les task queues et le routing complexe — les messages sont consommés et supprimés, avec acknowledgement garanti. C'est le choix naturel pour les traitements en arrière-plan, les workflows asynchrones et les systèmes où chaque message doit être traité exactement une fois.

Quand utiliser NATS plutôt que Kafka ou RabbitMQ ?

NATS est le bon choix quand vous avez besoin de communication légère et rapide entre microservices — sans la complexité d'un broker lourd. Sa latence sub-milliseconde et son empreinte mémoire minimale (<10 Mo par instance) en font le meilleur choix pour les architectures edge, l'IoT, et les communications request/reply entre services.

Si vous avez besoin de persistance longue durée et de replay d'événements à grande échelle, Kafka reste plus adapté. Si vous avez besoin de routing complexe avec ACK garanti, RabbitMQ est plus approprié.

Pourquoi ZooKeeper nécessite-t-il un nombre impair de réplicas ?

ZooKeeper utilise un algorithme de consensus par quorum — une décision (élection de leader, écriture) est validée quand une majorité de nœuds l'approuve. Avec 3 nœuds, le quorum est 2 — la perte d'un nœud n'interrompt pas le service. Avec 4 nœuds, le quorum est aussi 2 — vous tolérez toujours la perte d'un seul nœud. Passer de 3 à 4 n'améliore pas la tolérance aux pannes, mais augmente les coûts. C'est pourquoi on recommande 3 ou 5, jamais 4.

NATS JetStream est-il activé par défaut ?

Oui, JetStream est activé par défaut sur les clusters NATS Hikube. Désactivez-le uniquement si vous avez besoin d'un pub/sub purement éphémère sans persistance — vous réduirez l'empreinte mémoire et supprimerez le besoin de volume persistant. En production, gardez JetStream activé pour bénéficier de la persistance, du replay et des consumer groups durables.

Attention : même avec JetStream activé, les messages ne sont persistés que si un stream est configuré pour capturer les subjects concernés.

Quelle est la différence entre partitions et replicationFactor dans Kafka ?

Les partitions définissent le parallélisme — plus de partitions permettent à plus de consumers de lire en parallèle. Chaque partition est une séquence ordonnée de messages sur un broker.

Le replicationFactor définit la durabilité — chaque partition est copiée sur ce nombre de brokers. Si un broker tombe, ses partitions sont servies par les réplicas. Le replicationFactor ne peut pas dépasser le nombre de brokers.

Puis-je exposer mon cluster à l'extérieur du cluster Kubernetes ?

Oui, pour Kafka et RabbitMQ via external: true, et pour NATS via external: true. Kafka crée un LoadBalancer par broker, RabbitMQ expose les ports AMQP (5672) et Management (15672), NATS expose le port client (4222).

L'exposition externe rend le service accessible sur Internet — assurez-vous d'utiliser des mots de passe forts. Kafka ne dispose pas d'authentification par défaut sur Hikube, il est donc fortement déconseillé de l'exposer sans configuration de sécurité supplémentaire.