Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Leitfaden überprüfen wir die Voraussetzungen, Architekturaspekte und wichtige Komponenten für die Bereitstellung und Den Betrieb eines hoch verfügbaren Apache Kafka-Clusters auf Azure Kubernetes Service (AKS) mithilfe des Strimzi-Operators.
Von Bedeutung
Open-Source-Software wird überall in AKS-Dokumenten und -Beispielen erwähnt. Software, die Sie bereitstellen, ist von AKS-Vereinbarungen zum Servicelevel, der eingeschränkten Garantie und dem Azure-Support ausgeschlossen. Wenn Sie Open-Source-Technologie zusammen mit AKS nutzen, nutzen Sie die Supportoptionen, die von den jeweiligen Communitys und Projektbetreuenden angeboten werden, um einen Plan zu entwickeln.
Microsoft übernimmt die Verantwortung für die Erstellung der Open-Source-Pakete, die wir in AKS bereitstellen. Diese Verantwortung schließt die volle Verantwortung für den Build-, Scan-, Signatur-, Validierungs- und Hotfixprozess sowie die Kontrolle über die binären Dateien in Containerabbildern ein. Weitere Informationen finden Sie unter Sicherheitsrisikomanagement für AKS und AKS-Supportabdeckung.
Was ist Apache Kafka und Strimzi?
Apache Kafka ist eine Open Source Distributed Event Streaming-Plattform, die für die Verarbeitung von Daten mit hohem Volumen, hohem Durchsatz und Echtzeitstreaming entwickelt wurde. Als Ergebnis wird es von Tausenden von Unternehmen für leistungsstarke Datenpipelinen, Streaminganalysen, Datenintegration und unternehmenskritische Anwendungen verwendet. Das Verwalten und Skalieren von Kafka-Clustern kann jedoch schwierig und oft zeitaufwändig sein.
Strimzi ist ein Open-Source-Projekt, das die Bereitstellung, Verwaltung und Den Betrieb von Apache Kafka auf Kubernetes vereinfacht. Es stellt eine Reihe von Kubernetes Operatoren und Containerimages bereit, die komplexe Kafka-Betriebsaufgaben durch deklarative Konfiguration automatisieren.
Die Strimzi-Operatoren folgen dem Kubernetes-Operatormuster, um Kafka-Vorgänge zu automatisieren. Sie versöhnt kontinuierlich den deklarierten Zustand von Kafka-Komponenten mit ihrem tatsächlichen Zustand, wobei komplexe betriebstechnische Vorgänge automatisch verarbeitet werden.
Weitere Informationen zu Strimzi finden Sie in der Strimzi-Dokumentation.
Komponenten
Strimzi Cluster Operator
Der Strimzi Cluster Operator ist die zentrale Komponente, die das gesamte Kafka-Ökosystem verwaltet. Wenn er bereitgestellt wurde, kann er auch den Entity Operator bereitstellen, der aus Folgendem besteht:
-
Themenoperator: Automatisiert die Erstellung, Änderung und Löschung von Kafka-Themen basierend auf
KafkaTopicbenutzerdefinierten Ressourcen. -
Benutzeroperator: Verwaltet Kafka-Benutzer und ihre Zugriffssteuerungslisten (Access Control Lists, ACLs) über
KafkaUserbenutzerdefinierte Ressourcen.
Zusammen erstellen diese Operatoren ein vollständig deklaratives Verwaltungssystem, bei dem Ihre Kafka-Infrastruktur als Kubernetes-Ressourcen definiert ist, die Sie versionssteuerung, überwachen und konsistent in allen Umgebungen bereitstellen können.
Kafka-Cluster
Der Strimzi Cluster Operator verwaltet Kafka-Cluster über spezielle benutzerdefinierte Ressourcen:
- KafkaNodePools: Definieren von Gruppen von Kafka-Knoten mit bestimmten Rollen (Broker, Controller oder beides).
- Kafka: Die wichtigste benutzerdefinierte Ressource, die alles miteinander verbindet und clusterweite Konfigurationen definiert.
Eine typische Bereitstellung von KafkaNodePools und Kafka umfasst:
- Dedizierte Brokerknoten, die den Clientdatenverkehr und die Datenspeicherung verarbeiten.
- Dedizierte Controllerknoten, die Clustermetadaten und -koordination verwalten.
- Mehrere Replikate jeder Komponente, die über Verfügbarkeitszonen verteilt sind.
Geschwindigkeitsregelanlage
Cruise Control ist eine erweiterte Komponente, die automatisierte Workloadausgleich und Überwachung für Kafka-Cluster bereitstellt. Beim Einsatz als Teil eines Strimzi-verwalteten Kafka-Clusters bietet Cruise Control die folgenden Funktionen an:
- Automatische Neuverteilung der Partitionen: Verteilt Partitionen zwischen Brokern, um die Ressourcenauslastung zu optimieren.
- Anomalieerkennung: Identifiziert und meldet abnormales Clusterverhalten.
- Selbstheilungsfunktionen: Behebt automatisch häufige Probleme mit Clusterungleichgewichten.
- Workloadanalyse: Bietet Einblicke in die Clusterleistung und ressourcennutzung.
Cruise Control hilft dabei, eine optimale Leistung aufrechtzuerhalten, da sich Ihre Arbeitsauslastung im Laufe der Zeit ändert, wodurch der Bedarf an manuellen Eingriffen bei Skalierungsereignissen oder nach Maklerfehlern reduziert wird.
Entwässerungsreiniger
Strimzi Drain Cleaner ist ein Hilfsprogramm zur Verwaltung von Kafka-Broker-Pods, die von Strimzi während der Kubernetes-Knoten-Entwässerung bereitgestellt werden. Strimzi Drain Cleaner fängt Kubernetes-Knotenausgleiche durch seinen Zugangswebhook ab, um eine ordnungsgemäße Wartung von Kafka-Clustern zu koordinieren. Wenn eine Räumungsanforderung für Kafka-Broker-Pods gestellt wird, wird die Anforderung erkannt, und der Drain Cleaner annotiert die Pods, um dem Strimzi Cluster Operator zu signalisieren, den Neustart durchzuführen, um sicherzustellen, dass der Kafka-Cluster in einem stabilen Zustand bleibt. Dieser Prozess gewährleistet die Cluster-Gesundheit und Datenzuverlässigkeit während routinemäßiger Wartungsvorgänge oder unerwarteter Knotenausfälle.
Wann kafka auf AKS verwenden
Erwägen Sie, Kafka auf AKS auszuführen, wenn:
- Sie benötigen vollständige Kontrolle über die Kafka-Konfiguration und -Vorgänge.
- Für Ihren Anwendungsfall sind bestimmte Kafka-Features erforderlich, die in verwalteten Angeboten nicht verfügbar sind.
- Sie möchten Kafka in andere containerisierte Anwendungen integrieren, die auf AKS ausgeführt werden.
- Sie müssen in Regionen bereitstellen, in denen verwaltete Kafka-Dienste nicht verfügbar sind.
- Ihre Organisation verfügt über vorhandene Kenntnisse in Kubernetes und Container-Orchestrierung.
Für einfachere Anwendungsfälle oder wenn der Betriebsaufwand ein Problem darstellt, sollten Sie vollständig verwaltete Dienste wie Azure Event Hubs in Betracht ziehen.
Wichtige Überlegungen zu Kafka bei AKS
Azure Disk Storage
Für Kafka-Bereitstellungen auf AKS verwenden wir den Azure Disk CSI-Treiber, der persistente Volumes bereitstellt, die von von Azure verwalteten Datenträgern unterstützt werden. Strimzi nutzt die Konfiguration (Just a Bunch of Disks , JBOD) zum Verwalten der Datenpersistenz.
Um Hochverfügbarkeit über Infrastrukturfehler hinweg sicherzustellen, sollten Speicherklassen mit SSD Premium v2-Datenträgern konfiguriert werden, die über Verfügbarkeitszonen verteilt werden, indem sie den WaitForFirstConsumer-Volumebindungsmodus verwenden. Dadurch wird sichergestellt, dass Pods in Zonen geplant werden, in denen ihre persistenten Volumes erstellt werden können. Premium SSD v2 kann die Latenz, hohe IOPS und einen konsistenten Durchsatz liefern, der von E/A-intensiven Kafka-Workloads in einer optimierten Kostenstruktur benötigt wird.
Die folgende Tabelle enthält Ausgangspunkte für Premium SSD v2-Konfigurationen in verschiedenen Kafka-Clustergrößen:
| Kafka-Clustergröße | Datenträgergröße | IOPS | Bandbreite |
|---|---|---|---|
|
Klein (3-9 Broker) |
1 TB (Terabyte) | 5.000 | 250 MB/s |
|
Medium (10-19 Broker) |
2 TB | 10.000 | 500 MB/s |
|
Groß (20+ Makler) |
4 TB | 20.000 | 1.000 MB/s |
Die tatsächliche erforderliche IOPS-, Bandbreiten- und Datenträgergröße variiert je nach Ihren spezifischen Kafka-Workloadmerkmalen. Diese Eigenschaften können sich im Laufe der Zeit weiterentwickeln, da sich der Durchsatz und die Aufbewahrungsanforderungen ihrer Anwendung ändern.
Knotenpools
Die Auswahl der geeigneten Knotenpools für Ihre Kafka-Bereitstellung auf AKS ist eine wichtige Architekturentscheidung, die sich direkt auf Leistung, Verfügbarkeit und Kosteneffizienz auswirkt. Kafka-Workloads weisen einzigartige Ressourcenauslastungsmuster auf – gekennzeichnet durch hohe Durchsatzanforderungen, Speicher-E/A-Intensität und die Notwendigkeit einer konsistenten Leistung bei unterschiedlichen Lasten. Kafka ist in der Regel speicherintensiver als CPU-intensiv. Die CPU-Anforderungen können jedoch mit nachrichtenkomprimierung/Dekomprimierung, SSL/TLS-Verschlüsselung oder Szenarien mit hohem Durchsatz mit vielen kleinen Nachrichten erheblich gesteigert werden.
In Anbetracht der Kubernetes-nativen Architektur von Strimzi, bei der jeder Kafka-Broker als einzelner Pod ausgeführt wird, sollte Ihre AKS-Knotenauswahlstrategie für die horizontale Skalierung und nicht für die vertikale Skalierung eines einzelnen Knotens optimiert werden. Die richtige Konfiguration des Knotenpools auf AKS stellt eine effiziente Ressourcenauslastung sicher, während die Leistungsisolation beibehalten wird, die kafka-Komponenten für die zuverlässige Bedienung benötigen.
Kafka wird mit einem virtuellen Java-Computer (JVM) ausgeführt. Die Optimierung des JVM ist entscheidend für eine optimale Kafka-Leistung, insbesondere in Produktionsumgebungen. LinkedIn, die Ersteller von Kafka, teilten die typischen Argumente für die Ausführung von Kafka auf Java für einen der größten Cluster von LinkedIn: Kafka Java Configuration.
Für diesen Leitfaden wird ein Speicher-Heap von 6 GB als Basiswert für die Broker verwendet, wobei zusätzliche 2 GB für die Off-Heap-Speichernutzung zugewiesen sind. Für Controller wird ein Heap mit 3 GB Arbeitsspeicher als Basismaß verwendet, mit zusätzlichen 1 GB als Mehraufwand.
Berücksichtigen Sie bei der Größenanpassung von VMs für Ihre Kafka-Bereitstellung die folgenden workloadspezifischen Faktoren:
| Arbeitsauslastungsfaktor | Auswirkungen auf die Größenanpassung | Überlegungen |
|---|---|---|
| Nachrichtendurchsatz | Ein höherer Durchsatz erfordert mehr CPU, Arbeitsspeicher und Netzwerkkapazität. | – Überwachen Sie die ein- und ausgehenden Bytes pro Sekunde. – Berücksichtigen Sie Spitzen- gegenüber dem Durchschnittsdurchsatz. - Die zukünftigen Wachstumsprognosen berücksichtigen. |
| Nachrichtengröße | Die Größenanpassung von Nachrichten wirkt sich auf die ANFORDERUNGEN an CPU, Netzwerk und Datenträger aus. | - Kleine Nachrichten (≤1 KB) sind cpugebundener. - Große Nachrichten (>1 MB) sind stärker netzwerkgebunden. – Sehr große Nachrichten erfordern möglicherweise eine spezielle Optimierung. |
| Aufbewahrungszeitraum | Längere Aufbewahrung erhöht die Speicheranforderungen. | - Berechnen der Gesamtspeicheranforderungen basierend auf dem Durchsatz × Aufbewahrung. |
| Verbraucheranzahl | Mehr Verbraucher erhöhen die CPU- und Netzwerklast. | - Jede Verbrauchergruppe erhöht den Aufwand. – Für hohe Fan-Out-Muster sind zusätzliche Ressourcen erforderlich. |
| Themenpartitionierung | Die Partitionsanzahl wirkt sich auf die Speicherauslastung aus. | – Jede Partition verbraucht Speicherressourcen. – Die Überpartitionierung kann die Leistung beeinträchtigen. |
| Infrastrukturaufwand | Zusätzliche Systemkomponenten wirken sich auf verfügbare Ressourcen für Kafka aus. | – Der Azure Disk CSI-Treiber hat minimalen Ressourcenaufwand. – Überwachungs-Agents, Protokollierungskomponenten, Netzwerkrichtlinien und Sicherheitstools erhöhen zusätzlichen Aufwand. – Reservieren Sie einen Mehraufwand für Systemkomponenten. |
Von Bedeutung
Die folgenden Empfehlungen dienen nur als Startleitfaden. Ihre optimale VM-SKU-Auswahl sollte auf Ihre spezifischen Kafka-Workloadeigenschaften, Datenmuster und Leistungsanforderungen zugeschnitten sein. Für jeden Broker-Pod werden ungefähr 8 GB reservierter Arbeitsspeicher geschätzt. Es wird geschätzt, dass jeder Controller-Pod ca. 4 GB reservierten Speicher hat. Ihre JVM- und Heap-Speicheranforderungen können größer oder kleiner sein.
Kleine bis mittlere Kafka-Cluster
| VM-SKU | vCPUs (virtuelle CPUs) | RAM | Netzwerk | Maklerdichte (Schätzungen) | Hauptvorteile |
|---|---|---|---|---|---|
| Standard_D8ds | 8 | 32 GB | 12.500 Mbit/s | 1-3 pro Knoten | Kosteneffizient für die horizontale Skalierung, erfordert aber möglicherweise mehr Knoten, wenn die Skalierung zunimmt. |
| Standard_D16ds | 16 | 64 GB | 12.500 Mbit/s | 3-6 pro Knoten | Effizientere Ressourcennutzung mit zusätzlichem vCPU und RAM, was weniger AKS-Knoten erfordert. |
Große Kafka-Cluster
| VM-SKU | vCPUs (virtuelle CPUs) | RAM | Netzwerk | Maklerdichte (Schätzungen) | Hauptvorteile |
|---|---|---|---|---|---|
| Standard_E16ds | 16 | 128 GB | 12.500 Mbit/s | 6+ pro Knoten | - Bessere Leistung für datenintensive, groß angelegte Vorgänge mit erhöhten Arbeitsspeicher-zu-Core-Verhältnissen. – Kann größere Speicher-Heaps oder mehr horizontale Skalierung unterstützen. |
Bevor Sie Ihre Produktionsumgebung abschließen, sollten Sie die folgenden Schritte ausführen:
- Führen Sie Auslastungstests mit repräsentativen Datenvolumes und Mustern durch.
- Überwachen Sie die CPU-, Arbeitsspeicher-, Datenträger- und Netzwerkauslastung bei Spitzenlasten.
- Passen Sie AKS-Knotenpool-SKUs basierend auf beobachteten Engpässen an.
- Überprüfen Sie die Kosten für Knotenpool-SKUs.
Hohe Verfügbarkeit und Resilienz
Um die hohe Verfügbarkeit Ihrer Kafka-Bereitstellung sicherzustellen, sollten Sie:
- Bereitstellung über mehrere Verfügbarkeitszonen hinweg.
- Konfigurieren Sie die richtigen Replikatverteilungseinschränkungen.
- Implementieren Sie geeignete Podunterbrechungsbudgets.
- Konfigurieren Sie Cruise Control für den Partitionsausgleich von Themen.
- Verwenden Sie Strimzi Drain Cleaner, um Knotenentwässerungs- und Wartungsvorgänge zu verwalten.
Überwachung und Betrieb
Eine effektive Überwachung von Kafka-Clustern umfasst:
- JMX-Metrikensammlungskonfiguration.
- Heimanwender-Latenzüberwachung mit Kafka Exporter.
- Integration in Azure Managed Prometheus und Azure Managed Grafana.
- Überwachung von wichtigen Leistungsindikatoren und Gesundheitsmetriken.
Nächster Schritt
Beitragende
Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:
- Sergio Navar | Senior Customer Engineer
- Erin Schaffer | Inhaltsentwickler 2