Is Kafka op Kubernetes goed?

Groeten, Habr!

Ooit waren wij de eersten die dit onderwerp op de Russische markt introduceerden Kafka en doorgaan volgen voor zijn ontwikkeling. In het bijzonder vonden we het onderwerp interactie tussen Kafka en Kubernetes. Waarneembaar (en behoorlijk voorzichtig) artikel dit onderwerp werd in oktober vorig jaar gepubliceerd op de Confluent-blog onder het auteurschap van Gwen Shapira. Vandaag willen we graag uw aandacht vestigen op een recenter artikel uit april van Johann Gyger, die, hoewel niet zonder vraagteken in de titel, het onderwerp op een meer inhoudelijke manier onderzoekt en de tekst begeleidt met interessante links. Vergeef ons alstublieft de gratis vertaling van “chaos aap” als je kunt!

Introductie

Kubernetes is ontworpen om staatloze workloads af te handelen. Dergelijke workloads worden doorgaans gepresenteerd in de vorm van een microservice-architectuur, ze zijn licht van gewicht, goed horizontaal te schalen, volgen de principes van 12-factor-applicaties en kunnen werken met stroomonderbrekers en chaos-apen.

Kafka daarentegen fungeert in wezen als een gedistribueerde database. Als je werkt, heb je dus te maken met de staat, en het is veel zwaarder dan een microservice. Kubernetes ondersteunt stateful belastingen, maar zoals Kelsey Hightower in twee tweets opmerkt, moeten ze met zorg worden behandeld:

Sommige mensen zijn van mening dat als je Kubernetes in een stateful workload integreert, het een volledig beheerde database wordt die kan wedijveren met RDS. Dit is fout. Als je hard genoeg werkt, extra componenten toevoegt en een team van SRE-ingenieurs aantrekt, kun je misschien RDS bovenop Kubernetes bouwen.

Ik raad iedereen altijd aan uiterst voorzichtig te zijn bij het uitvoeren van stateful workloads op Kubernetes. De meeste mensen die vragen “kan ik stateful workloads draaien op Kubernetes” hebben niet genoeg ervaring met Kubernetes, en vaak ook met de workload waar ze naar vragen.

Dus, moet je Kafka op Kubernetes draaien? Tegenvraag: zal Kafka beter werken zonder Kubernetes? Daarom wil ik in dit artikel benadrukken hoe Kafka en Kubernetes elkaar aanvullen, en welke valkuilen er kunnen ontstaan ​​als je ze combineert.

Tijd van voltooiing

Laten we het over de basis hebben: de runtime-omgeving zelf

Процесс

Kafka-makelaars zijn CPU-vriendelijk. TLS kan enige overhead met zich meebrengen. Kafka-clients kunnen echter CPU-intensiever zijn als ze encryptie gebruiken, maar dit heeft geen invloed op makelaars.

Память

Kafka-makelaars vreten geheugen op. De JVM-heapgrootte is meestal beperkt tot 4-5 GB, maar je hebt ook veel systeemgeheugen nodig omdat Kafka de paginacache zeer intensief gebruikt. Stel in Kubernetes de containerresource in en vraag dienovereenkomstig limieten aan.

Gegevensopslag

Gegevensopslag in containers is van tijdelijke aard: gegevens gaan verloren bij het opnieuw opstarten. Voor Kafka-gegevens kunt u een volume gebruiken emptyDir, en het effect zal vergelijkbaar zijn: uw makelaarsgegevens gaan na voltooiing verloren. Uw berichten kunnen nog steeds als replica's bij andere makelaars worden opgeslagen. Daarom moet de mislukte broker na een herstart eerst alle gegevens repliceren, en dit proces kan veel tijd in beslag nemen.

Daarom moet u gebruik maken van langdurige gegevensopslag. Laat het niet-lokale langetermijnopslag zijn met het XFS-bestandssysteem of, preciezer, ext4. Gebruik geen NFS. Ik heb je gewaarschuwd. NFS-versies v3 of v4 zullen niet werken. Kortom, de Kafka-broker zal crashen als hij de gegevensmap niet kan verwijderen vanwege het "domme hernoemen" -probleem in NFS. Als ik je nog niet heb overtuigd: heel voorzichtig lees dit artikel. De datastore moet niet-lokaal zijn, zodat Kubernetes na een herstart of verhuizing flexibeler een nieuw knooppunt kan kiezen.

Сеть

Zoals bij de meeste gedistribueerde systemen zijn de prestaties van Kafka sterk afhankelijk van het tot een minimum beperken van de netwerklatentie en het maximaliseren van de bandbreedte. Probeer niet alle brokers op hetzelfde knooppunt te hosten, omdat dit de beschikbaarheid zal verminderen. Als een Kubernetes-knooppunt faalt, faalt het hele Kafka-cluster. Verspreid het Kafka-cluster ook niet over hele datacenters. Hetzelfde geldt voor het Kubernetes-cluster. Een goed compromis in dit geval is om verschillende beschikbaarheidszones te kiezen.

Configuratie

Reguliere manifesten

De Kubernetes-website heeft zeer goede gids over het configureren van ZooKeeper met behulp van manifesten. Omdat ZooKeeper onderdeel is van Kafka, is dit een goede plek om kennis te maken met welke Kubernetes-concepten hier van toepassing zijn. Als u dit eenmaal begrijpt, kunt u dezelfde concepten gebruiken met een Kafka-cluster.

• onder: Een pod is de kleinste inzetbare eenheid in Kubernetes. Een pod bevat uw werklast en de pod zelf komt overeen met een proces in uw cluster. Een pod bevat een of meer containers. Elke ZooKeeper-server in het ensemble en elke makelaar in het Kafka-cluster zal in een aparte pod draaien.
• StatefulSet: Een StatefulSet is een Kubernetes-object dat meerdere stateful workloads afhandelt, en dergelijke workloads vereisen coördinatie. StatefulSets bieden garanties met betrekking tot het bestellen van pods en hun uniciteit.
• Diensten zonder hoofd: Met services kunt u pods loskoppelen van clients met behulp van een logische naam. Kubernetes is in dit geval verantwoordelijk voor de taakverdeling. Bij het uitvoeren van stateful workloads, zoals ZooKeeper en Kafka, moeten clients echter met een specifiek exemplaar communiceren. Dit is waar headless services van pas komen: in dit geval heeft de client nog steeds een logische naam, maar hoeft u niet rechtstreeks contact op te nemen met de pod.
• Opslagvolume voor de lange termijn: Deze volumes zijn nodig om de hierboven genoemde niet-lokale permanente blokopslag te configureren.

Op Yoleaan Biedt een uitgebreide set manifesten om u op weg te helpen met Kafka op Kubernetes.

Helmgrafieken

Helm is een pakketbeheerder voor Kubernetes die kan worden vergeleken met OS-pakketbeheerders zoals yum, apt, Homebrew of Chocolatey. Het maakt het eenvoudig om vooraf gedefinieerde softwarepakketten te installeren die worden beschreven in Helm-grafieken. Een goed gekozen Helm-diagram maakt de moeilijke taak van het correct configureren van alle parameters om Kafka op Kubernetes te gebruiken eenvoudig. Er zijn verschillende Kafka-diagrammen: de officiële bevindt zich in couveusetoestand, er is er één van ConFluent™, nog één - van Bitnami.

Операторы

Omdat Helm bepaalde tekortkomingen heeft, wint een andere tool aanzienlijk aan populariteit: Kubernetes-operators. De operator verpakt niet alleen software voor Kubernetes, maar stelt u ook in staat dergelijke software te implementeren en te beheren.

In de lijst geweldige exploitanten Er worden twee operators voor Kafka genoemd. Een van hen - Strimzi. Met Strimzi is het eenvoudig om uw Kafka-cluster binnen enkele minuten operationeel te krijgen. Er is vrijwel geen configuratie nodig, daarnaast zorgt de operator zelf voor een aantal leuke features, bijvoorbeeld point-to-point TLS-encryptie binnen het cluster. Confluent biedt ook eigen exploitant.

Производительность

Het is belangrijk om de prestaties te testen door uw Kafka-instantie te benchmarken. Dergelijke tests helpen u potentiële knelpunten te vinden voordat er zich problemen voordoen. Gelukkig biedt Kafka al twee prestatietesttools: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Maak er actief gebruik van. Ter referentie kunt u de resultaten raadplegen die worden beschreven in deze post Jay Kreps, of focus je op deze recensie Amazon MSK van Stéphane Maarek.

operaties

controle

Transparantie in het systeem is erg belangrijk, anders begrijp je niet wat erin gebeurt. Tegenwoordig is er een solide toolkit die op statistieken gebaseerde monitoring biedt in de cloud-native stijl. Twee populaire hulpmiddelen voor dit doel zijn Prometheus en Grafana. Prometheus kan met behulp van een JMX-exporteur op de eenvoudigste manier statistieken verzamelen van alle Java-processen (Kafka, Zookeeper, Kafka Connect). Als u cAdvisor-statistieken toevoegt, krijgt u beter inzicht in de manier waarop resources in Kubernetes worden gebruikt.

Strimzi heeft een heel handig voorbeeld van een Grafana-dashboard voor Kafka. Het visualiseert belangrijke statistieken, bijvoorbeeld over sectoren die niet voldoende gerepliceerd zijn of die offline zijn. Alles is daar heel duidelijk. Deze statistieken worden aangevuld met informatie over het gebruik van hulpbronnen en prestatie-informatie, evenals stabiliteitsindicatoren. U krijgt dus voor niets de basis Kafka-clustermonitoring!

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

Het zou leuk zijn om dit alles aan te vullen met clientmonitoring (statistieken over consumenten en producenten), evenals latentiemonitoring (hiervoor is er Hol) en end-to-end monitoring - voor dit gebruik Kafka-monitor.

Loggen

Loggen is een andere cruciale taak. Zorg ervoor dat op alle containers in uw Kafka-installatie is ingelogd stdout и stderr, en zorg er ook voor dat uw Kubernetes-cluster alle logbestanden verzamelt in een centrale loginfrastructuur, b.v. Elasticsearch.

Gezondheidscontrole

Kubernetes gebruikt liveness- en readiness-sondes om te controleren of uw pods normaal werken. Als de liveness-check mislukt, stopt Kubernetes die container en start deze vervolgens automatisch opnieuw op als het herstartbeleid dienovereenkomstig is ingesteld. Als de gereedheidscontrole mislukt, isoleert Kubernetes de pod van onderhoudsaanvragen. In dergelijke gevallen is handmatige tussenkomst dus helemaal niet meer nodig, wat een groot pluspunt is.

Updates uitrollen

StatefulSets ondersteunen automatische updates: als u de RollingUpdate-strategie selecteert, worden ze allemaal onder Kafka om de beurt bijgewerkt. Op deze manier kan de downtime tot nul worden teruggebracht.

scaling

Het schalen van een Kafka-cluster is geen gemakkelijke taak. Kubernetes maakt het echter heel eenvoudig om pods te schalen naar een bepaald aantal replica's, wat betekent dat je declaratief zoveel Kafka-makelaars kunt definiëren als je wilt. Het moeilijkste in dit geval is het opnieuw toewijzen van sectoren na het opschalen of vóór het terugschalen. Nogmaals, Kubernetes zal u helpen met deze taak.

administratie

Taken met betrekking tot het beheer van uw Kafka-cluster, zoals het maken van onderwerpen en het opnieuw toewijzen van sectoren, kunnen worden uitgevoerd met behulp van bestaande shell-scripts door de opdrachtregelinterface in uw pods te openen. Deze oplossing is echter niet erg mooi. Strimzi ondersteunt het beheren van onderwerpen met een andere operator. Er is hier enige ruimte voor verbetering.

Back-up en herstel

Nu zal de beschikbaarheid van Kafka ook afhangen van de beschikbaarheid van Kubernetes. Als uw Kubernetes-cluster faalt, zal in het ergste geval ook uw Kafka-cluster falen. Volgens de wet van Murphy zal dit zeker gebeuren en verlies je gegevens. Om dit soort risico's te verminderen, moet u een goed back-upconcept hebben. Je kunt MirrorMaker gebruiken, een andere optie is om hiervoor S3 te gebruiken, zoals hierin beschreven post van Zalando.

Conclusie

Bij het werken met kleine tot middelgrote Kafka-clusters is het zeker de moeite waard om Kubernetes te gebruiken, omdat het extra flexibiliteit biedt en de operatorervaring vereenvoudigt. Als u zeer aanzienlijke niet-functionele latentie- en/of doorvoervereisten heeft, is het wellicht beter om een ​​andere implementatieoptie te overwegen.

Bron: www.habr.com