Streaming & Messaging - Hikube

Kafka, RabbitMQ, NATS.
kubectl apply - das ist alles.

Drei vollständig gemanagte Messaging-Dienste auf Hikube. Verteiltes Event-Streaming, AMQP-Task-Queues, ultraleichte Pub/Sub. Automatische Replikation, koordinierter ZooKeeper, JetStream inklusive.

KOSTENLOS STARTEN DOKUMENTATION

3 Dienste

Kafka - RabbitMQ - NATS

Native HA

Automatische Replikation + Quorum

<1 ms

NATS-Latenz (dasselbe Rechenzentrum)

0 Konfig.

ZooKeeper, Sentinel, Raft - verwaltet
Vergleich

Der richtige Dienst für jedes Pattern

Kafka, RabbitMQ und NATS erfüllen unterschiedliche Anforderungen. Die Wahl hängt vom Volumen, vom Liefermodell und der benötigten Haltbarkeit ab.

SERVICE
PROTOKOLL
MODELL
PERSISTANZ
GEBRAUCHSFALL
Kafka
Kafka
Binäres TCP
Pub/Sub mit verteiltem Log
Ja - konfigurierbare Retention
Event-Streaming, Datenpipelines, Echtzeit-Analytik
RabbitMQ
RabbitMQ
AMQP
Warteschlange mit Routing
Ja - Quorum Queues (Raft)
Task Queues, RPC, komplexes Routing, asynchrone Workflows
Frame 11502-2
NATS
TCP Text
Pub/Sub + Request/Reply
Optional - JetStream
Microservices, IoT, Edge, leichte Echtzeitkommunikation
DIENSTE

Jeder Dienst im Detail

Kafka

Strimzi Operator ZooKeeper Verteiltes Log

Kafka organisiert Nachrichten in Topics, die in Partitionen unterteilt und auf mehrere Broker verteilt werden. Jede Partition wird gemäß dem replicationFactor repliziert. Fällt ein Broker aus, werden die Partitionen auf die verfügbaren Replikate umgeleitet. ZooKeeper koordiniert die Leader-Wahl und speichert die die Cluster-Metadaten.

Im Gegensatz zu RabbitMQ behält Kafka die Nachrichten nach ihrem Konsum. Die Aufbewahrungsdauer ist pro Topic konfigurierbar (retention.ms). Mehrere Consumer Groups können dasselbe Topic unabhängig lesen, jede mit ihrem eigenen Offset.

  • Topics im Manifest deklariert
    Partitionen, Replikationsfaktor, Retention und Cleanup Policy direkt in YAML konfiguriert. Keine externen Tools zum Erstellen von Topicso.
  • Verwalteter ZooKeeper
    3 ZooKeeper-Instanzen koordinieren den Cluster automatisch. Das ungerade Quorum ist garantiert, ein Ausfall eines ZK-Knotens unterbricht den Dienst nicht.
  • Retention und Compaction
    cleanup.policy: delete löscht Nachrichten nach retention.ms. cleanup.policy: compact behält nur die letzte Nachricht pro Schlüssel, ideal für Referenztabellen.
  • Optionale externe Exposition
    external: true Erstellt einen LoadBalancer pro Broker für Clients außerhalb des Clusters. Ohne konfigurierte Authentifizierung vermeiden.
yaml
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" 


 
Warum gemanagt

Was Sie nicht mehr tun müssen

Kafka, RabbitMQ und NATS sind drei verschiedene verteilte Systeme, aber im Self-Hosting teilen sie dasselbe Problem: Jedes erfordert dediziertes Fachwissen, um in der Produktion korrekt betrieben zu werden. Knoten dimensionieren, das Quorum konfigurieren, Failover testen, Versions-Upgrades ohne Unterbrechung des Nachrichtenflusses verwalten — das ist Engineering-Zeit, die keinen geschäftlichen Wert schafft.

Auf Hikube übernimmt der Kubernetes-Betreiber diesen Aufwand für alle drei Dienste. Sie deklarieren, was Sie wollen, Anzahl der Knoten, Topics oder Vhosts, Ressourcen, und der Operator provisioniert, repliziert und schaltet bei einem Ausfalls um. Die Konfiguration zu ändern heißt, einen Wert in einer YAML-Datei zu ändern und anzuwenden.

markup-cropped-1

Automatisches Quorum und Konsens

ZooKeeper für Kafka, Raft für RabbitMQ und NATS JetStream. Die Leader-Election-Mechanismen werden ohne manuellen Eingriff konfiguriert und überwacht.

markup-cropped-1

Topics, vhosts und Streams mit dem Cluster

Partitionen, Retention, Virtual Hosts, JetStreams-Streams in YAML am selben Ort deklariert. Kein separates Initialisierungsskript, zu pflegen.

markup-cropped-1

Scaling ohne Unterbrechung

Ändern Sie die Anzahl der Knoten im Manifest und wenden Sie es an. Der Operator fügt die Instanzen als Rolling Update ohne manuelles Rebalancing und ohne Downtime hinzu.

markup-cropped-1

Automatisch generierte Credentials

Die Passwörter werden beim Provisioning in einem Kubernetes Secret erstellt. Referenzieren Sie das Secret in Ihren Pods, keine Klartext-Schlüssel in Ihren Manifesten oder Git-Repositorys.

Anwendungsfälle

Welcher Dienst für welchen Bedarf?

Die drei Dienste konkurrieren nicht, sie ergänzen sich. Hier die konkreten Patterns, in denen sich jeder durchsetzt.

Pipeline von Anwendungslogs

Ingestion von Millionen Log-Ereignissen aus 50 Microservices. 7 Tage Retention, mehrere unabhängige Consumer (Elasticsearch, ClickHouse, Alerting). Jeder Consumer liest aus seinem eigenen Offset.

3 Broker - 3 Partitionen - retention.ms: 604800000

Event Sourcing und Audit Trail

Jede Benutzeraktion wird auf einem Topic mit cleanup.policy: compact veröffentlicht. Der aktuelle Status ist die Summe der Ereignisse. Das Compact-Topic garantiert die Beibehaltung des letzten Status pro Schlüssel.

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

Warteschlange für die E-Mail-Verarbeitung

Bestellungen lösen eine Nachricht in einer Queue emails.pending aus. Worker lesen die Queue, senden die E-Mail und bestätigen (ACK) die Nachricht. Fällt ein Worker aus, wird die Nachricht automatisch neu eingereiht.

replicas: 3 - quorum queues - ACK/NACK

Routing von Ereignissen mit mehreren Zielen

Eine Exchange vom Typ topic routet orders.*-Ereignisse in die Rechnungs-Queue, orders.shipped in die Logistik-Queue und # in eine Audit-Queue. Ein Publish, mehrere Ziele.

exchange: topic - bindings - 3 Schwänze

Kommunikation zwischen Microservices

Dienst A ruft Dienst B über NATS request/reply statt HTTP auf. Keine Service Discovery, kein Load Balancer. NATS routet direkt zu einem verfügbaren Subscriber in der Queue Group.

Request/Reply - Warteschlangengruppen - <1ms latency

IoT-Telemetrie mit JetStream

10.000 Sensoren veröffentlichen Metriken auf sensors.>. JetStream speichert 24 Stunden lang Daten. Analysedienste verbinden sich und spielen beim Start die Historie ab. Nützlich nach einer Wartung.

JetStream - 24h retention - replay on connect
Managed Streaming & Messaging

Event-Driven als Grundlage moderner Architekturen

Ereignisorientierte Architekturen sind zum Standard moderner verteilter Systeme geworden. Wo synchrone APIs fragile Kopplungen schaffen, ermöglichen Message Broker die Kommunikation zwischen Diensten ohne direkte Abhängigkeit. Jeder Dienst produziert oder konsumiert Ereignisse in seinem eigenen Tempo.

Kafka strukturiert Datenpipelines mit hohem Volumen — Logs, Metriken, Geschäftsereignisse — mit langer Retention und Event-Replay, das Audit und Disaster Recovery vereinfacht. RabbitMQ sorgt für die zuverlässige Weiterleitung kritischer Aufgaben: jede Nachricht wird genau einmal verarbeitet, mit Zustellgarantie. NATS reduziert die Reibung zwischen Microservices durch leichtgewichtige Kommunikation, Mikrosekunden-Latenz und ohne schwere Infrastruktur.

In der gemanagten Version übernehmen Ihre Teams diese Patterns, ohne bei der Infrastruktur von vorne anzufangen. Gleiche Technologie, gleiche SDKs, gleiche Tools, von Hikube bereitgestellt und betrieben.

markup-cropped-1

Entkopplung und Anwendungs-Resilienz

Ein ausgefallener Dienst zieht die anderen nicht mit. Nachrichten sammeln sich im Broker und werden bei der Wiederaufnahme verarbeitet, ohne Verlust und ohne manuellen Eingriff.

markup-cropped-1

IoT und Edge Computing

NATS nimmt Millionen von Sensorereignissen mit minimalem Speicherbedarf auf. JetStream stellt sicher, dass keine Daten verloren gehen, wenn ein Verarbeitungsdienst neu startet.

markup-cropped-1

Data-Streaming und Echtzeit-Analytik

Speisen Sie ClickHouse, Elasticsearch oder Ihre Grafana-Dashboards kontinuierlich aus Kafka. Dasselbe Topic kann mehrere unabhängige Consumer gleichzeitig versorgen.

markup-cropped-1

Kompatibel mit Ihrem Stack

Kafka Connect, Confluent SDKs, pika, nats.go, nats.py. Alle bestehenden Clients funktionieren ohne Änderungen. Verweisen Sie auf den Kubernetes-Dienst, der Rest ist identisch.

FAQ

Fragen zu Managed Streaming & Messaging

Kafka oder RabbitMQ, wie wählt man?

Kafka ist für hochvolumiges Streaming und lange Retention gemacht. Nachrichten bleiben nach dem Konsum verfügbar, mehrere Consumer können dasselbe Topic unabhängig lesen. Es ist die natürliche Wahl für Datenpipelines, Event Sourcing und Echtzeit-Analytik.

RabbitMQ ist für Task Queues und komplexes Routing gemacht. Nachrichten werden konsumiert und gelöscht, mit garantiertem Acknowledgement. Es ist die natürliche Wahl für Hintergrundverarbeitung, asynchrone Workflows und Systeme, in denen jede Nachricht genau einmal verarbeitet werden muss.

 

Wann sollte man NATS statt Kafka oder RabbitMQ verwenden?

NATS ist die richtige Wahl, wenn Sie leichte, schnelle Kommunikation zwischen Microservices ohne die Komplexität eines schweren Brokers benötigen. Seine Sub-Millisekunden-Latenz und sein minimaler Speicherbedarf (<10 MB pro Instanz) machen es zur besten Wahl für Edge-Architekturen, IoT und Request/Reply-Kommunikation zwischen Diensten.

Wenn Sie Langzeit-Persistenz und großflächigen Event-Replay benötigen, ist Kafka weiterhin besser geeignet. Wenn Sie komplexes Routing mit garantiertem ACK benötigen, ist RabbitMQ angebrachter.

Warum benötigt ZooKeeper eine ungerade Anzahl von Replikaten?

ZooKeeper verwendet einen Quorum-basierten Konsens-Algorithmus. Eine Entscheidung (Leader-Wahl, Schreibvorgang) wird bestätigt, wenn eine Mehrheit der Knoten zustimmt. Bei 3 Knoten ist das Quorum 2: der Verlust eines Knotens unterbricht den Dienst nicht. Bei 4 Knoten ist das Quorum ebenfalls 2: Sie tolerieren weiterhin nur den Verlust eines einzigen Knotens. Der Wechsel von 3 auf 4 verbessert die Fehlertoleranz nicht, erhöht aber die Kosten. Deshalb empfehlen wir 3 oder 5, niemals 4.

Ist NATS JetStream standardmäßig aktiviert?

Ja, JetStream ist auf Hikube-NATS-Clustern standardmäßig aktiviert. Deaktivieren Sie es nur, wenn Sie ein rein flüchtiges Pub/Sub ohne Persistenz benötigen: Sie reduzieren den Speicherbedarf und beseitigen die Notwendigkeit eines persistenten Volumes. Lassen Sie JetStream in der Produktion aktiviert, um von Persistenz, Replay und dauerhaften Consumer Groups zu profitieren. Achtung: Auch bei aktiviertem JetStream werden Nachrichten nur persistiert, wenn ein Stream so konfiguriert ist, dass er die betreffenden Subjects erfasst.

 

Was ist der Unterschied zwischen Partitionen und replicationFactor in Kafka?

Partitionen definieren die Parallelität: mehr Partitionen ermöglichen es mehr Consumern, parallel zu lesen. Jede Partition ist eine geordnete Folge von Nachrichten auf einem Broker.

Der replicationFactor definiert die Haltbarkeit: jede Partition wird auf diese Anzahl Broker kopiert. Fällt ein Broker aus, werden seine Partitionen von den Replikaten bedient. Der replicationFactor kann die Anzahl der Broker nicht überschreiten.

 

Kann ich meinen Cluster außerhalb des Kubernetes-Clusters verfügbar machen?

Ja, für Kafka und RabbitMQ über external: true, und für NATS über external: true. Kafka erstellt einen LoadBalancer pro Broker, RabbitMQ legt die Ports AMQP (5672) und Management (15672) offen, NATS legt den Client-Port (4222) offen. Die externe Exposition macht den Dienst über das Internet erreichbar: Stellen Sie sicher, dass Sie starke Passwörter verwenden. Kafka hat auf Hikube keine Standard-Authentifizierung, daher wird dringend davon abgeraten, es ohne zusätzliche Sicherheitskonfiguration zu exponieren.