{"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\/no\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Er Kafka p\u00e5 Kubernetes \u2013 er det bra?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Velkommen, Habr!<\/p>\n

Vi var de f\u00f8rste som introduserte temaet Kafka<\/a><\/noindex> og fortsetter overv\u00e5ke<\/a><\/noindex> \u00e5 f\u00f8lge utviklingen av det. Spesielt har vi funnet interaksjonen mellom Kafka og Kubernetes<\/a><\/noindex>. En oversikt (og ganske forsiktig) article<\/a><\/noindex> om dette ble publisert p\u00e5 bloggen til Confluent allerede i oktober i fjor, skrevet av Gwen Shapiro. I dag \u00f8nsker vi \u00e5 rette oppmerksomheten deres mot en ferskere, april-artikkel av Johann Gyger, som, selv om han ikke unngikk sp\u00f8rsm\u00e5lstegnet i tittelen, betrakter temaet p\u00e5 en mer konkret m\u00e5te, og supplere teksten med interessante lenker. Beklager v\u00e5r frie oversettelse av \u00abchaos monkey\u00bb, hvis dere kan!<\/p>\n

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

Innledning<\/h4>\n

\nKubernetes er laget for \u00e5 h\u00e5ndtere arbeidsoppgaver som ikke har tilstand. Vanligvis er slike arbeidsmengder representert ved mikrotjenestearkitektur, de er lette, lett kan skaleres horisontalt, f\u00f8lger prinsippene for 12-faktorapplikasjoner, og lar oss arbeide med sikringsautomater (circuit breakers) og kaosaper (chaos monkeys).<\/p>\n

Kafka, plassert p\u00e5 den andre siden, fungerer i essens som en distribuert database. Dermed m\u00e5 du h\u00e5ndtere tilstand n\u00e5r du jobber, og det er mye mer tungvint enn en mikrotjeneste. Kubernetes st\u00f8tter arbeidsoppgaver med tilstand, men som Kelsey Hightower p\u00e5peker i to av sine tweets, b\u00f8r de h\u00e5ndteres med forsiktighet:<\/p>\n

Noen synes at hvis de p\u00e5f\u00f8rer Kubernetes til en arbeidsmengde med tilstand, blir det en fullt administrert database som kan konkurrere med RDS. Det er ikke slik. Kanskje hvis du jobber hardt nok, legger til ekstra komponenter og involverer et SRE-team, klarer du \u00e5 sette opp RDS over Kubernetes.<\/p><\/blockquote>\n

Jeg anbefaler alltid \u00e5 v\u00e6re ekstremt forsiktig med \u00e5 kj\u00f8re arbeidsmengder med tilstand p\u00e5 Kubernetes. De fleste av dem som lurer p\u00e5, \u00abkan jeg kj\u00f8re arbeidsmengder med tilstand p\u00e5 Kubernetes\u00bb, har ikke tilstrekkelig erfaring med Kubernetes, og ofte heller ikke med den arbeidsmengden de sp\u00f8r om.<\/p><\/blockquote>\n

S\u00e5, b\u00f8r man kj\u00f8re Kafka p\u00e5 Kubernetes? Et motsatt sp\u00f8rsm\u00e5l: Vil Kafka fungere bedre uten Kubernetes? Derfor \u00f8nsker jeg \u00e5 understreke i denne artikkelen hvordan Kafka og Kubernetes komplementerer hverandre, og hvilke fallgruver som kan oppst\u00e5 ved \u00e5 kombinere dem.<\/p>\n

Kj\u00f8rets tid<\/h4>\n

\nLa oss snakke om det grunnleggende \u2013 kj\u00f8rets tid som s\u00e5dan<\/p>\n

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

Kafka-brokere er effektive n\u00e5r det kommer til CPU-bruk. TLS kan tilf\u00f8re noen kostnader. Samtidig kan Kafka-klienter belaste CPU-en mer, hvis de bruker kryptering, men dette p\u00e5virker ikke brokerne.<\/p>\n

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

Kafka-brokere bruker mye minne. St\u00f8rrelsen p\u00e5 JVM-haugen b\u00f8r vanligvis begrenses til 4\u20135 GB, men du vil ogs\u00e5 trenge mye systemminne, siden Kafka bruker sidecache aktivt. I Kubernetes b\u00f8r du derfor angi grenser for containere for ressurser og foresp\u00f8rslene deretter.<\/p>\n

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

Datagrunnlag i containere er ephemeral \u2013 data g\u00e5r tapt ved omstart. For Kafka-data kan du bruke volum, og effekten vil v\u00e6re den samme: dataene dine vil g\u00e5 tapt etter en avslutning. Dine meldinger kan likevel bli bevart p\u00e5 andre brokere som replikaer. Derfor, etter en omstart, b\u00f8r den mislykkede brokeren f\u00f8rst replikere all data, og denne prosessen kan ta tid. emptyDir<\/code>Det er derfor viktig \u00e5 bruke permanent datalagring. La oss si at dette er en ikke-lokal permanent lagringsl\u00f8sning med XFS-filsystemet eller mer presist, ext4. Unng\u00e5 NFS. Jeg advarer deg. NFS versjoner v3 eller v4 vil ikke fungere. For \u00e5 oppsummere, vil Kafka-brokeren stoppe hvis den ikke kan slette datakatalogen p\u00e5 grunn av et problem med 'dumme omd\u00f8pinger', som er en kjent utfordring i NFS. Hvis jeg fortsatt ikke har overbevist deg, vennligst les denne artikkelen n\u00f8ye. <\/p>\n

Datagrunnlaget b\u00f8r v\u00e6re ikke-lokalt, slik at Kubernetes kan velge en ny node mer fleksibelt etter omstart eller relokalisering. g\u00e5 gjennom denne artikkelen<\/a><\/noindex>.<\/p>\n

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

Som i de fleste distribuerte systemer avhenger ytelsen til Kafka sterkt av at nettverksforsinkelsene er minimal og b\u00e5ndbredden maksimal. Pr\u00f8v ikke \u00e5 plassere alle brokerne p\u00e5 samme node, da dette vil redusere tilgjengeligheten. Hvis en Kubernetes-node feiler, vil hele Kafka-klyngen ogs\u00e5 feile. S\u00f8rg heller ikke for \u00e5 spre Kafka-klyngen over hele datasentre. Det samme gjelder Kubernetes-klyngen. Et godt kompromiss i dette tilfellet er \u00e5 velge forskjellige tilgjengelighetssoner.<\/p>\n

Konfigurasjon<\/h4>\n

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

Kubernetes-siden har et veldig godt veiledning<\/a><\/noindex> om hvordan man konfigurerer ZooKeeper ved hjelp av manifester. Siden ZooKeeper er en del av Kafka, er dette et praktisk utgangspunkt for \u00e5 bli kjent med hvilke Kubernetes-konsepter som er relevante her. N\u00e5r du har forst\u00e5tt dette, kan du bruke de samme konseptene med Kafka-klyngen.<\/p>\n