{"id":36822,"date":"2019-10-31T22:14:01","date_gmt":"2019-10-31T19:14:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kafka-na-kubernetes-eto-horosho\/"},"modified":"2019-10-31T22:14:01","modified_gmt":"2019-10-31T19:14:01","slug":"kafka-na-kubernetes-eto-horosho","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Ist Kafka auf Kubernetes gut?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Willkommen, Habr!<\/p>\n

Zu seiner Zeit haben wir als erste das Thema Kafka<\/a><\/noindex> auf den russischen Markt gebracht und verfolgen<\/a><\/noindex> seine Entwicklung. Besonders interessant fanden wir das Thema der Interaktion zwischen Kafka und Kubernetes<\/a><\/noindex>. Ein \u00dcberblick (und ziemlich vorsichtig) Artikel<\/a><\/noindex> zu diesem Thema erschien im Blog des Unternehmens Confluent bereits im Oktober letzten Jahres unter der Autorenschaft von Gwen Shapiro. Heute m\u00f6chten wir Ihre Aufmerksamkeit auf einen aktuelleren Artikel von Johann Gyger lenken, der, obwohl er im Titel nicht ohne Fragezeichen auskommt, das Thema aus einem konkreteren Blickwinkel betrachtet und den Text mit interessanten Links erg\u00e4nzt. Bitte entschuldigen Sie uns den freien \u00dcbersetzungsversuch von \u201echaos monkey\u201c, wenn Sie k\u00f6nnen!<\/p>\n

\"Ist<\/a><\/noindex>
\n<\/a><\/noindex> <\/p>\n

Einf\u00fchrung<\/h4>\n

\nKubernetes ist f\u00fcr die Arbeit mit zustandslosen Lasten konzipiert. In der Regel werden solche Arbeitslasten in Form einer Microservices-Architektur dargestellt, sie sind leichtgewichtig, gut horizontal skalierbar, folgen den Prinzipien der 12-Faktor-Anwendungen, erm\u00f6glichen den Einsatz von automatischen Schaltern (circuit breaker) und Chaos-Monkeys.<\/p>\n

Kafka hingegen fungiert im Wesentlichen als verteilte Datenbank. Somit muss man bei der Arbeit mit ihn sich mit Zustand befassen, der deutlich schwerer wiegt als ein Microservice. Kubernetes unterst\u00fctzt workloads mit Zustand, aber wie Kelsey Hightower in zwei seiner Tweets anmerkt, ist mit ihnen vorsichtig umzugehen:<\/p>\n

Einige glauben, wenn Kubernetes auf eine zustandsbehaftete Last angewandt wird, wird es zu einer vollst\u00e4ndig verwalteten Datenbank, die mit RDS konkurrieren kann. Das ist nicht der Fall. Vielleicht gelingt es, wenn man gen\u00fcgend M\u00fche investiert, zus\u00e4tzliche Komponenten anf\u00fcgt und ein Team von SRE-Ingenieuren einbezieht, ein RDS \u00fcber Kubernetes zu erstellen.<\/p><\/blockquote>\n

Ich empfehle immer, bei der Ausf\u00fchrung zustandsbehafteter Lasten auf Kubernetes au\u00dfergew\u00f6hnlich vorsichtig zu sein. Die meisten, die sich fragen, \u201eKann ich zustandsbehaftete Lasten auf Kubernetes ausf\u00fchren\u201c, haben nicht gen\u00fcgend Erfahrung mit Kubernetes, und oft auch nicht mit der spezifischen Last, nach der gefragt wird.<\/p><\/blockquote>\n

Sollte man Kafka auf Kubernetes ausf\u00fchren? Eine Gegenfrage: Wird Kafka besser ohne Kubernetes funktionieren? Deshalb m\u00f6chte ich in diesem Artikel hervorheben, wie Kafka und Kubernetes sich gegenseitig erg\u00e4nzen und welche Fallstricke beim Zusammenspiel dieser beiden Technologien auftreten k\u00f6nnen.<\/p>\n

Ausf\u00fchrungszeit<\/h4>\n

\nLass uns \u00fcber eine grundlegende Sache sprechen \u2013 die Ausf\u00fchrungsumgebung an sich.<\/p>\n

Prozess<\/b><\/i><\/p>\n

Kafka-Broker sind CPU-freundlich. TLS kann einige Kosten verursachen. Dabei k\u00f6nnen Kafka-Clients die CPU st\u00e4rker belasten, wenn sie Verschl\u00fcsselung verwenden, was sich jedoch nicht auf die Broker auswirkt.<\/p>\n

Speicher<\/b><\/i><\/p>\n

Kafka-Broker nehmen Speicher in Anspruch. Die JVM-Haupthaltestgr\u00f6\u00dfe sollte normalerweise auf 4-5 GB begrenzt werden, aber Sie ben\u00f6tigen auch viel Systemspeicher, da Kafka den Seiten-Cache sehr aktiv nutzt. Stellen Sie in Kubernetes die Containerlimits f\u00fcr Ressourcen und Anfragen entsprechend ein.<\/p>\n

Datenspeicherung<\/b><\/i><\/p>\n

Die Datenspeicherung in Containern ist fl\u00fcchtig \u2013 Daten gehen bei einem Neustart verloren. F\u00fcr Kafka-Daten kann ein Volume verwendet werden emptyDir<\/code>, und der Effekt wird \u00e4hnlich sein: Die Daten Ihres Brokers gehen nach dem Herunterfahren verloren. Ihre Nachrichten k\u00f6nnen jedoch als Replikate von anderen Brokern erhalten bleiben. Daher muss der ausgefallene Broker nach dem Neustart zun\u00e4chst alle Daten replizieren, was einige Zeit in Anspruch nehmen kann. <\/p>\n

Deshalb sollte man ein dauerhaftes Datenspeicher verwenden. Lassen Sie es ein nicht-lokales, dauerhaftes Speichersystem mit XFS oder genauer gesagt ext4 sein. Verwenden Sie kein NFS. Ich warne Sie. NFS-Versionen v3 oder v4 werden nicht funktionieren. Kurz gesagt, der Kafka-Broker wird abbrechen, wenn er das Datenverzeichnis aufgrund eines Problems mit den \u201edummen Umbenennungen\u201c, die bei NFS auftreten, nicht l\u00f6schen kann. Falls ich Sie bis jetzt nicht \u00fcberzeugt habe, lesen Sie bitte sehr aufmerksam diesen Artikel<\/a><\/noindex>. Der Datenspeicher sollte nicht lokal sein, damit Kubernetes flexibler einen neuen Knoten nach einem Neustart oder einer Neuplatzierung ausw\u00e4hlen kann.<\/p>\n

Netzwerk<\/b><\/i><\/p>\n

Wie bei den meisten verteilten Systemen h\u00e4ngt die Leistung von Kafka stark davon ab, dass die Netzwerklatenzen minimal und die Bandbreiten maximal sind. Versuchen Sie nicht, alle Broker auf demselben Knoten zu platzieren, da die Verf\u00fcgbarkeit dadurch verringert wird. Wenn ein Kubernetes-Knoten ausf\u00e4llt, f\u00e4llt der gesamte Kafka-Cluster aus. Verteilen Sie auch den Kafka-Cluster nicht \u00fcber ganze Rechenzentren. Das Gleiche gilt f\u00fcr den Kubernetes-Cluster. Ein guter Kompromiss in diesem Fall ist, verschiedene Verf\u00fcgbarkeitszonen auszuw\u00e4hlen.<\/p>\n

Konfiguration<\/h4>\n

\n\u00dcbliche Manifeste<\/b><\/i><\/p>\n

Auf der Kubernetes-Website gibt es ein sehr gutes Handbuch<\/a><\/noindex> dar\u00fcber, wie man ZooKeeper mit Hilfe von Manifesten konfiguriert. Da ZooKeeper Teil von Kafka ist, ist es sinnvoll, hiermit zu beginnen, um herauszufinden, welche Konzepte von Kubernetes hier anwendbar sind. Nachdem Sie dies verstanden haben, k\u00f6nnen Sie dieselben Konzepte auch im Kafka-Cluster anwenden.<\/p>\n