Ist Kafka auf Kubernetes gut?

Grüße, Habr!

Wir waren einst die Ersten, die das Thema auf dem russischen Markt eingeführt haben Kafkaeske Zustände und fortsetzen folgen für seine Entwicklung. Insbesondere fanden wir das Thema der Interaktion zwischen Kafka und Kubernetes. Beobachtbar (und ziemlich vorsichtig) Beitrag Dieses Thema wurde bereits im Oktober letzten Jahres auf dem Confluent-Blog unter der Autorschaft von Gwen Shapira veröffentlicht. Heute möchten wir Sie auf einen neueren Artikel von Johann Gyger aus dem April aufmerksam machen, der zwar nicht ohne Fragezeichen im Titel auskommt, das Thema aber inhaltlicher beleuchtet und den Text mit interessanten Links begleitet. Bitte verzeihen Sie uns die kostenlose Übersetzung von „Chaos Monkey“, wenn Sie können!

Einführung

Kubernetes ist für die Verarbeitung zustandsloser Arbeitslasten konzipiert. Typischerweise werden solche Workloads in Form einer Microservice-Architektur dargestellt, sie sind leichtgewichtig, lassen sich gut horizontal skalieren, folgen den Prinzipien von 12-Faktor-Anwendungen und können mit Leistungsschaltern und Chaosaffen arbeiten.

Kafka hingegen fungiert im Wesentlichen als verteilte Datenbank. Daher muss man sich bei der Arbeit mit dem Status auseinandersetzen, und dieser ist viel schwerer als ein Microservice. Kubernetes unterstützt Stateful Loads, aber wie Kelsey Hightower in zwei Tweets betont, sollten sie mit Vorsicht behandelt werden:

Manche Leute sind der Meinung, dass Kubernetes zu einer vollständig verwalteten Datenbank wird, die mit RDS konkurriert, wenn man es in einen zustandsbehafteten Workload einfügt. Das ist nicht so. Wenn Sie hart genug arbeiten, zusätzliche Komponenten hinzufügen und ein Team von SRE-Ingenieuren gewinnen, können Sie möglicherweise RDS auf Kubernetes aufbauen.

Ich empfehle jedem immer, bei der Ausführung zustandsbehafteter Workloads auf Kubernetes äußerste Vorsicht walten zu lassen. Die meisten Leute, die fragen: „Kann ich zustandsbehaftete Workloads auf Kubernetes ausführen“, haben nicht genug Erfahrung mit Kubernetes und oft auch mit der Workload, nach der sie fragen.

Sollten Sie Kafka also auf Kubernetes ausführen? Gegenfrage: Funktioniert Kafka ohne Kubernetes besser? Deshalb möchte ich in diesem Artikel hervorheben, wie sich Kafka und Kubernetes ergänzen und welche Fallstricke eine Kombination mit sich bringen kann.

Zeitpunkt der Fertigstellung

Lassen Sie uns über das Grundlegende sprechen – die Laufzeitumgebung selbst

Prozess

Kafka-Broker sind CPU-freundlich. TLS kann zu einem gewissen Overhead führen. Kafka-Clients sind jedoch möglicherweise rechenintensiver, wenn sie Verschlüsselung verwenden. Dies hat jedoch keine Auswirkungen auf Broker.

Память

Kafka-Broker fressen Speicher auf. Die JVM-Heap-Größe ist normalerweise auf 4–5 GB begrenzt, Sie benötigen jedoch auch viel Systemspeicher, da Kafka den Seitencache sehr stark nutzt. Legen Sie in Kubernetes die Containerressourcen- und Anforderungslimits entsprechend fest.

Datenspeicherung

Die Datenspeicherung in Containern ist kurzlebig – beim Neustart gehen Daten verloren. Für Kafka-Daten können Sie ein Volume verwenden emptyDir, und der Effekt wird ähnlich sein: Ihre Brokerdaten gehen nach Abschluss verloren. Ihre Nachrichten können weiterhin als Replikate auf anderen Brokern gespeichert werden. Daher muss der ausgefallene Broker nach einem Neustart zunächst alle Daten replizieren, was sehr viel Zeit in Anspruch nehmen kann.

Deshalb sollten Sie eine langfristige Datenspeicherung nutzen. Sei es eine nicht-lokale Langzeitspeicherung mit dem XFS-Dateisystem oder genauer gesagt ext4. Verwenden Sie kein NFS. Ich habe dich gewarnt. Die NFS-Versionen v3 oder v4 funktionieren nicht. Kurz gesagt: Der Kafka-Broker stürzt ab, wenn er das Datenverzeichnis aufgrund des Problems der „dummen Umbenennung“ in NFS nicht löschen kann. Falls ich Sie noch nicht überzeugt habe, ganz vorsichtig Lesen Sie diesen Artikel. Der Datenspeicher sollte nicht lokal sein, damit Kubernetes nach einem Neustart oder Umzug flexibler einen neuen Knoten auswählen kann.

Netzwerk

Wie bei den meisten verteilten Systemen hängt die Leistung von Kafka stark davon ab, die Netzwerklatenz auf ein Minimum und die Bandbreite auf ein Maximum zu beschränken. Versuchen Sie nicht, alle Broker auf demselben Knoten zu hosten, da dies die Verfügbarkeit verringert. Wenn ein Kubernetes-Knoten ausfällt, fällt der gesamte Kafka-Cluster aus. Verteilen Sie den Kafka-Cluster außerdem nicht über ganze Rechenzentren. Das Gleiche gilt für den Kubernetes-Cluster. Ein guter Kompromiss besteht in diesem Fall darin, verschiedene Verfügbarkeitszonen zu wählen.

Konfiguration

Regelmäßige Manifeste

Die Kubernetes-Website hat sehr guter Führer Informationen zum Konfigurieren von ZooKeeper mithilfe von Manifesten. Da ZooKeeper Teil von Kafka ist, ist dies ein guter Ausgangspunkt, um sich mit den hier anwendbaren Kubernetes-Konzepten vertraut zu machen. Sobald Sie dies verstanden haben, können Sie dieselben Konzepte mit einem Kafka-Cluster verwenden.

• Unter: Ein Pod ist die kleinste bereitstellbare Einheit in Kubernetes. Ein Pod enthält Ihre Arbeitslast und der Pod selbst entspricht einem Prozess in Ihrem Cluster. Ein Pod enthält einen oder mehrere Container. Jeder ZooKeeper-Server im Ensemble und jeder Broker im Kafka-Cluster werden in einem separaten Pod ausgeführt.
• StatefulSet: Ein StatefulSet ist ein Kubernetes-Objekt, das mehrere zustandsbehaftete Workloads verarbeitet, und solche Workloads erfordern eine Koordination. StatefulSets bieten Garantien hinsichtlich der Reihenfolge von Pods und ihrer Einzigartigkeit.
• Headless-Dienste: Mit Diensten können Sie Pods mithilfe eines logischen Namens von Clients trennen. Kubernetes ist in diesem Fall für den Lastausgleich verantwortlich. Beim Betrieb zustandsbehafteter Workloads wie ZooKeeper und Kafka müssen Clients jedoch mit einer bestimmten Instanz kommunizieren. Hier bieten sich Headless-Dienste an: In diesem Fall hat der Client weiterhin einen logischen Namen, Sie müssen den Pod jedoch nicht direkt kontaktieren.
• Langzeitspeichervolumen: Diese Volumes werden benötigt, um den oben erwähnten nicht-lokalen persistenten Blockspeicher zu konfigurieren.

Auf Yolean Bietet einen umfassenden Satz an Manifesten, die Ihnen den Einstieg in Kafka auf Kubernetes erleichtern.

Helmkarten

Helm ist ein Paketmanager für Kubernetes, der mit Betriebssystempaketmanagern wie yum, apt, Homebrew oder Chocolatey verglichen werden kann. Es erleichtert die Installation vordefinierter Softwarepakete, die in Helm-Charts beschrieben sind. Ein gut ausgewähltes Helm-Diagramm erleichtert die schwierige Aufgabe, alle Parameter für die Verwendung von Kafka auf Kubernetes richtig zu konfigurieren. Es gibt mehrere Kafka-Diagramme: Das offizielle befindet sich im Inkubatorzustand, da ist einer von Confluent, noch einer - von Bitnami.

Betreiber

Da Helm gewisse Mängel aufweist, erfreut sich ein anderes Tool großer Beliebtheit: Kubernetes-Operatoren. Der Betreiber verpackt nicht nur Software für Kubernetes, sondern ermöglicht Ihnen auch die Bereitstellung und Verwaltung dieser Software.

die Liste tolle Betreiber Zwei Operatoren für Kafka werden erwähnt. Einer von ihnen - Strimzi. Mit Strimzi ist es ganz einfach, Ihren Kafka-Cluster in wenigen Minuten zum Laufen zu bringen. Es ist praktisch keine Konfiguration erforderlich, außerdem stellt der Betreiber selbst einige nette Funktionen bereit, beispielsweise die Punkt-zu-Punkt-TLS-Verschlüsselung innerhalb des Clusters. Confluent bietet auch eigener Betreiber.

Leistung

Es ist wichtig, die Leistung durch ein Benchmarking Ihrer Kafka-Instanz zu testen. Solche Tests helfen Ihnen, potenzielle Engpässe zu erkennen, bevor Probleme auftreten. Glücklicherweise bietet Kafka bereits zwei Leistungstest-Tools: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Nutzen Sie diese aktiv. Als Referenz können Sie auf die in beschriebenen Ergebnisse verweisen dieser Beitrag Jay Kreps, oder konzentrieren Sie sich auf diese Rezension Amazon MSK von Stéphane Maarek.

Geschäftstätigkeit

Überwachung

Transparenz im System ist sehr wichtig – sonst versteht man nicht, was darin passiert. Heute gibt es ein solides Toolkit, das eine metrikbasierte Überwachung im Cloud-native-Stil ermöglicht. Zwei beliebte Tools für diesen Zweck sind Prometheus und Grafana. Prometheus kann mit einem JMX-Exporter Metriken aus allen Java-Prozessen (Kafka, Zookeeper, Kafka Connect) sammeln – und das auf einfachste Weise. Wenn Sie cAdvisor-Metriken hinzufügen, können Sie besser verstehen, wie Ressourcen in Kubernetes verwendet werden.

Strimzi hat ein sehr praktisches Beispiel für ein Grafana-Dashboard für Kafka. Es visualisiert wichtige Kennzahlen, beispielsweise zu Sektoren, die nicht ausreichend repliziert werden oder offline sind. Da ist alles sehr klar. Ergänzt werden diese Kennzahlen durch Ressourcennutzungs- und Leistungsinformationen sowie Stabilitätsindikatoren. Sie erhalten also die grundlegende Kafka-Clusterüberwachung umsonst!

Source: streamzi.io/docs/master/#kafka_dashboard

Es wäre schön, all dies durch Client-Überwachung (Metriken zu Verbrauchern und Produzenten) sowie Latenzüberwachung (dafür gibt es) zu ergänzen Bau) und End-to-End-Überwachung - für diesen Einsatz Kafka-Monitor.

Protokollierung

Die Protokollierung ist eine weitere wichtige Aufgabe. Stellen Sie sicher, dass alle Container in Ihrer Kafka-Installation angemeldet sind stdout и stderrund stellen Sie außerdem sicher, dass Ihr Kubernetes-Cluster alle Protokolle in einer zentralen Protokollierungsinfrastruktur zusammenfasst, z. B. Elasticsearch.

Funktionsprüfung

Kubernetes verwendet Liveness- und Bereitschaftstests, um zu überprüfen, ob Ihre Pods normal laufen. Wenn die Aktivitätsprüfung fehlschlägt, stoppt Kubernetes diesen Container und startet ihn dann automatisch neu, wenn die Neustartrichtlinie entsprechend festgelegt ist. Wenn die Bereitschaftsprüfung fehlschlägt, isoliert Kubernetes den Pod von der Bearbeitung von Anfragen. Somit ist in solchen Fällen überhaupt kein manueller Eingriff mehr erforderlich, was ein großes Plus ist.

Rollout von Updates

StatefulSets unterstützen automatische Updates: Wenn Sie die RollingUpdate-Strategie auswählen, wird jedes unter Kafka nacheinander aktualisiert. Auf diese Weise können Ausfallzeiten auf Null reduziert werden.

Skalierung

Die Skalierung eines Kafka-Clusters ist keine leichte Aufgabe. Kubernetes macht es jedoch sehr einfach, Pods auf eine bestimmte Anzahl von Replikaten zu skalieren, was bedeutet, dass Sie deklarativ so viele Kafka-Broker definieren können, wie Sie möchten. Am schwierigsten ist es in diesem Fall, die Sektoren nach der Vergrößerung bzw. vor der Verkleinerung neu zuzuordnen. Auch hier hilft Ihnen Kubernetes bei dieser Aufgabe.

Verwaltung

Aufgaben im Zusammenhang mit der Verwaltung Ihres Kafka-Clusters, wie das Erstellen von Themen und das Neuzuweisen von Sektoren, können mithilfe vorhandener Shell-Skripte erledigt werden, indem Sie die Befehlszeilenschnittstelle in Ihren Pods öffnen. Allerdings ist diese Lösung nicht sehr schön. Strimzi unterstützt die Verwaltung von Themen mit einem anderen Operator. Hier besteht durchaus Raum für Verbesserungen.

езервное копирование и восстановление

Nun hängt die Verfügbarkeit von Kafka auch von der Verfügbarkeit von Kubernetes ab. Wenn Ihr Kubernetes-Cluster ausfällt, fällt im schlimmsten Fall auch Ihr Kafka-Cluster aus. Nach Murphys Gesetz wird dies definitiv passieren und Sie werden Daten verlieren. Um diese Art von Risiko zu reduzieren, sollten Sie über ein gutes Backup-Konzept verfügen. Sie können MirrorMaker verwenden, eine andere Möglichkeit besteht darin, hierfür S3 zu verwenden, wie hier beschrieben post von Zalando.

Abschluss

Bei der Arbeit mit kleinen bis mittelgroßen Kafka-Clustern lohnt sich der Einsatz von Kubernetes auf jeden Fall, da es zusätzliche Flexibilität bietet und das Bedienererlebnis vereinfacht. Wenn Sie sehr hohe nichtfunktionale Latenz- und/oder Durchsatzanforderungen haben, ist es möglicherweise besser, eine andere Bereitstellungsoption in Betracht zu ziehen.

Source: habr.com