{"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\/da\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Er Kafka p\u00e5 Kubernetes en god id\u00e9?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Velkommen til dig, Habr!<\/p>\n

Engang var vi de f\u00f8rste til at introducere emnet Kafka<\/a><\/noindex> og forts\u00e6tter med at f\u00f8lge<\/a><\/noindex> dens udvikling. Is\u00e6r har emnet omkring interaktionen mellem Kafka og Kubernetes<\/a><\/noindex>. En oversigt (og ganske forsigtig) artikel<\/a><\/noindex> om dette emne blev udgivet i bloggen fra Confluent tilbage i oktober sidste \u00e5r af Gwen Shapiro. I dag vil vi gerne henlede din opm\u00e6rksomhed p\u00e5 en mere aktuel artikel fra april af Johann Gyger, som, selvom han ikke undgik et sp\u00f8rgsm\u00e5lstegn i titlen, betragter emnet mere konkret og supplerer teksten med interessante links. Undskyld, hvis vi har oversat \"chaos monkey\" frit!<\/p>\n

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

Introduktion<\/h4>\n

\nKubernetes er designet til at arbejde med belastninger, der ikke har en beholdning. Som regel er s\u00e5danne arbejdsbelastninger pr\u00e6senteret i form af en mikrotjenestearkitektur, de er lette, nemme at skalere horisontalt, f\u00f8lger principperne for 12-faktor applikationer og tillader arbejde med automatisk afbrydere (circuit breakers) og chaos monkeys.<\/p>\n

Kafka, derimod, fungerer i princippet som en distribueret database. Derfor skal du arbejde med tilstand, som er meget tungere end en mikrotjeneste. Kubernetes underst\u00f8tter tilstande med persistent lagring, men som Kelsey Hightower p\u00e5peger i sine to tweets, skal man v\u00e6re forsigtig med dem:<\/p>\n

Nogle mener, at hvis man implementerer Kubernetes p\u00e5 en belastning med persistent lagring, s\u00e5 bliver det til en fuldt administreret database, der kan konkurrere med RDS. Det er ikke korrekt. M\u00e5ske, hvis man arbejder h\u00e5rdt nok, tilf\u00f8jer ekstra komponenter og inviterer et SRE-team, kan man f\u00e5 RDS til at fungere oven p\u00e5 Kubernetes.<\/p><\/blockquote>\n

Jeg anbefaler altid at udvise ekstrem forsigtighed, n\u00e5r man k\u00f8rer belastninger med persistent lagring p\u00e5 Kubernetes. De fleste af dem, der sp\u00f8rger, \"kan jeg k\u00f8re belastninger med persistent lagring p\u00e5 Kubernetes\", har ikke tilstr\u00e6kkelig erfaring med Kubernetes, og ofte heller ikke med den belastning, de sp\u00f8rger om.<\/p><\/blockquote>\n

S\u00e5, skal Kafka k\u00f8re p\u00e5 Kubernetes? Det modsatte sp\u00f8rgsm\u00e5l er: Vil Kafka fungere bedre uden Kubernetes? Derfor vil jeg i denne artikel fremh\u00e6ve, hvordan Kafka og Kubernetes supplerer hinanden, samt hvilke faldgruber der kan opst\u00e5 ved deres kombination.<\/p>\n

Udf\u00f8relsestid<\/h4>\n

\nLad os tale om den grundl\u00e6ggende ting - udf\u00f8relsesmilj\u00f8et som s\u00e5dan<\/p>\n

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

Kafka-m\u00e6glere er effektive at arbejde med CPU. TLS kan tilf\u00f8re nogle overhead. Klienter til Kafka kan dog belaste CPU'en yderligere, hvis de bruger kryptering, men det p\u00e5virker ikke m\u00e6glere.<\/p>\n

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

Kafka-m\u00e6glere kr\u00e6ver meget hukommelse. St\u00f8rrelsen p\u00e5 JVM-haugen b\u00f8r typisk begr\u00e6nses til 4-5 GB, men du f\u00e5r ogs\u00e5 brug for meget systemhukommelse, da Kafka bruger side-cache meget aktivt. I Kubernetes skal du passende angive containerens ressourcegr\u00e6nser og -anmodninger.<\/p>\n

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

Datastore i containere er ephemeralt - data g\u00e5r tabt ved genstart. For Kafka-data kan du bruge et volumen emptyDir<\/code>, og effekten vil v\u00e6re den samme: dine m\u00e6glers data vil g\u00e5 tabt efter afslutning. Dine beskeder kan stadig bevares p\u00e5 andre m\u00e6glere som replikaer. Derfor skal den fejlede m\u00e6gler f\u00f8rst replikere alle data efter genstart, og denne proces kan tage noget tid. <\/p>\n

Derfor b\u00f8r du bruge langsigtet datastore. Lad det v\u00e6re et ikke-lokalt langsigtet datastore med filsystemet XFS eller mere pr\u00e6cist ext4. Brug ikke NFS. Jeg advarer. NFS-versioner v3 eller v4 vil ikke fungere. Kort sagt, Kafka-m\u00e6gleren vil stoppe, hvis den ikke kan slette datakataloget p\u00e5 grund af problemer med 'dumme omd\u00f8bninger', der er relevante for NFS. Hvis jeg ikke har overbevist dig indtil nu, l\u00e6s denne artikel meget omhyggeligt . Datastore skal v\u00e6re ikke-lokal, s\u00e5 Kubernetes mere fleksibelt kan v\u00e6lge en ny node efter genstart eller relokation.<\/a><\/noindex>. Datalagringen skal v\u00e6re ikke-lokal, s\u00e5 Kubernetes mere fleksibelt kan v\u00e6lge en ny node efter genstart eller relokation.<\/p>\n

Netv\u00e6rk<\/b><\/i><\/p>\n

Som ligesom med de fleste distribuerede systemer afh\u00e6nger ydeevnen af Kafka st\u00e6rkt af, at netv\u00e6rksforsinkelsen er minimal, og b\u00e5ndbredden er maksimal. Fors\u00f8g ikke at placere alle brokere p\u00e5 samme node, da dette vil reducere tilg\u00e6ngeligheden. Hvis en Kubernetes-node fejler, vil hele Kafka-klusteret fejle. Spred heller ikke Kafka-klusteret over hele datacentre. Det samme g\u00e6lder for Kubernetes-klusteret. Et godt kompromis i dette tilf\u00e6lde er at v\u00e6lge forskellige tilg\u00e6ngelighedszoner.<\/p>\n

Konfiguration<\/h4>\n

\nAlmindelige manifester<\/b><\/i><\/p>\n

P\u00e5 Kubernetes-websitet er der et meget godt vejledning<\/a><\/noindex> om, hvordan man konfigurerer ZooKeeper ved hj\u00e6lp af manifester. Da ZooKeeper er en del af Kafka, er det her, det er praktisk at begynde at blive bekendt med, hvilke koncepter Kubernetes der er anvendelige her. N\u00e5r du forst\u00e5r dette, kan du anvende de samme koncepter med Kafka-klusteret.<\/p>\n