{"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 eine gute Idee?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Willkommen, Habr!<\/p>\n

Wir waren die Ersten, die das Thema Kafka<\/a><\/noindex> auf den russischen Markt gebracht haben, und verfolgen weiterhin seine Entwicklung. Besonders interessant fanden wir das Thema der Interaktion zwischen Kafka und<\/a><\/noindex> . Ein \u00dcberblick (und ziemlich vorsichtig) zu diesem Thema erschien bereits im Blog der Firma Confluent im Oktober letzten Jahres unter der Federf\u00fchrung von Gwen Shapiro. Heute m\u00f6chten wir Ihre Aufmerksamkeit auf einen neueren Artikel von Johann Gyger im April lenken, der, obwohl er nicht ohne Fragezeichen im Titel auskommt, das Thema in einem konkreteren Rahmen betrachtet und den Text mit interessanten Links erg\u00e4nzt. Bitte entschuldigen Sie uns die freie \u00dcbersetzung von \u201echaos monkey\u201c, wenn Sie k\u00f6nnen! Kubernetes<\/a><\/noindex>Kubernetes ist f\u00fcr den Betrieb von zustandslosen Workloads konzipiert. Diese werden normalerweise in Form einer Mikroservice-Architektur dargestellt, sind leichtgewichtig, gut horizontal skalierbar, folgen den Prinzipien von 12-Factor-Apps, erm\u00f6glichen die Verwendung von automatischen Abschaltern (circuit breaker) und Chaosmonkeys. Artikel<\/a><\/noindex> Zu diesem Thema ver\u00f6ffentlichte das Unternehmen Confluent bereits im Oktober letzten Jahres einen Blogbeitrag von Gwen Shapiro. Heute m\u00f6chten wir Ihre Aufmerksamkeit auf einen neueren Artikel von Johann Gyger aus dem April lenken. Obwohl er in seinem Titel nicht ohne ein Fragezeichen auskommt, behandelt er das Thema mit einem konkreteren Ansatz und erg\u00e4nzt den Text mit interessanten Links. Bitte entschuldigen Sie unsere freie \u00dcbersetzung 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 den Betrieb von zustandslosen Workloads konzipiert. In der Regel zeigen sich solche Workloads in Form von Microservice-Architekturen, die leichtgewichtig sind, sich gut horizontal skalieren lassen, den Prinzipien von 12-Faktor-Anwendungen entsprechen, den Einsatz von Circuit Breakern unterst\u00fctzen und mit Chaosmonkeys arbeiten.<\/p>\n

Kafka, der sich auf der anderen Seite befindet, fungiert im Wesentlichen als verteilte Datenbank. Daher m\u00fcssen Sie beim Arbeiten mit ihm den Zustand ber\u00fccksichtigen, der weitaus komplexer ist als bei einem Mikrodienst. Kubernetes unterst\u00fctzt zustandsbehaftete Workloads, aber wie Kelsey Hightower in zwei seiner Tweets anmerkt, sollte man mit ihnen vorsichtig umgehen:<\/p>\n

Einige denken, dass, wenn man Kubernetes auf einen zustandsbehafteten Workload anwendet, es sich in eine vollst\u00e4ndig verwaltete Datenbank verwandelt, die mit RDS konkurrieren kann. Das ist nicht der Fall. Vielleicht, wenn man genug Aufwand betreibt, zus\u00e4tzliche Komponenten integriert und ein Team von SRE-Ingenieuren hinzuzieht, kann man RDS auf Kubernetes einrichten.<\/p><\/blockquote>\n

Ich empfehle immer, beim Ausf\u00fchren zustandsbehafteter Workloads auf Kubernetes \u00e4u\u00dferst vorsichtig zu sein. Die meisten, die sich fragen: \"Kann ich zustandsbehaftete Workloads auf Kubernetes ausf\u00fchren?\", haben nicht gen\u00fcgend Erfahrung mit Kubernetes und oft auch nicht mit dem spezifischen Workload, nach dem sie fragen.<\/p><\/blockquote>\n

Sollte man Kafka also auf Kubernetes ausf\u00fchren? Eine Gegenfrage: W\u00fcrde Kafka besser ohne Kubernetes laufen? Deshalb m\u00f6chte ich in diesem Artikel betonen, wie Kafka und Kubernetes sich gegenseitig erg\u00e4nzen und welche Fallstricke bei ihrer Kombination auftreten k\u00f6nnen.<\/p>\n

Laufzeit<\/h4>\n

\nLassen Sie uns \u00fcber eine grundlegende Sache sprechen \u2013 das Konzept der Laufzeitumgebung an sich.<\/p>\n

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

Kafka-Broker sind CPU-effizient. TLS kann einige Kosten verursachen. Gleichzeitig k\u00f6nnen Kafka-Clients die CPU st\u00e4rker belasten, wenn sie Verschl\u00fcsselung nutzen, doch dies hat keine Auswirkungen auf die Broker.<\/p>\n

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

Kafka-Broker verbrauchen viel RAM. Die JVM-Heap-Gr\u00f6\u00dfe sollte normalerweise auf 4\u20135 GB begrenzt werden, aber Sie ben\u00f6tigen auch viel Systemspeicher, da Kafka intensiv den Seiten-Cache nutzt. Stellen Sie in Kubernetes entsprechend Ressourcenlimits und -anforderungen f\u00fcr die Container ein.<\/p>\n

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

Der Datenspeicher in Containern ist fl\u00fcchtig \u2013 Daten gehen beim Neustart verloren. F\u00fcr Kafka-Daten k\u00f6nnen Sie ein Volume verwenden. emptyDir<\/code>, und der Effekt wird \u00e4hnlich sein: die Daten Ihres Brokers gehen nach der Beendigung verloren. Ihre Nachrichten k\u00f6nnen dennoch als Replikate bei anderen Brokern gespeichert bleiben. Daher muss der ausgefallene Broker nach dem Neustart als Erstes alle Daten replizieren, und dieser Prozess kann einige Zeit in Anspruch nehmen. <\/p>\n

Das ist der Grund, warum Sie einen langfristigen Datenspeicher verwenden sollten. Dies sollte ein nicht-lokales Langzeitdatenspeicher mit dem XFS-Dateisystem oder genauer gesagt, ext4 sein. Vermeiden Sie NFS. Ich habe gewarnt. NFS-Versionen v3 oder v4 werden nicht funktionieren. Kurz gesagt, der Kafka-Broker wird beendet, wenn er das Verzeichnis mit den Daten aufgrund von 'dummen Umbenennungen', die in NFS auftreten, nicht l\u00f6schen kann. Wenn ich Sie bis jetzt nicht \u00fcberzeugt habe, lesen Sie bitte diesen Artikel<\/a><\/noindex>. Der Datenspeicher sollte nicht-lokal sein, damit Kubernetes flexibler einen neuen Knoten nach einem Neustart oder einer Relokation 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 Netzwerkverz\u00f6gerungen minimal und die Bandbreite maximal sind. Versuchen Sie nicht, alle Broker auf demselben Knoten zu platzieren, da dies die Verf\u00fcgbarkeit verringern kann. Wenn ein Kubernetes-Knoten ausf\u00e4llt, f\u00e4llt auch der gesamte Kafka-Cluster aus. Verteilen Sie den Kafka-Cluster auch nicht \u00fcber ganze Rechenzentren. Dasselbe gilt f\u00fcr den Kubernetes-Cluster. Ein guter Kompromiss in diesem Fall ist, verschiedene Verf\u00fcgbarkeitszonen zu w\u00e4hlen.<\/p>\n

Konfiguration<\/h4>\n

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

Auf der Website von Kubernetes gibt es ein sehr gutes Handbuch<\/a><\/noindex> wie man ZooKeeper mit Manifesten konfiguriert. Da ZooKeeper Teil von Kafka ist, ist dies ein guter Ausgangspunkt, um sich mit den in Kubernetes verwendeten Konzepten vertraut zu machen. Wenn Sie dies verstanden haben, k\u00f6nnen Sie dieselben Konzepte auch f\u00fcr den Kafka-Cluster nutzen.<\/p>\n