{"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\/sl\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Je Kafka na Kubernetes dobra ideja?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozdravljamo vas, Habr!<\/p>\n

V svoj \u010das smo prvi predstavili temo na ruski trg Kafka<\/a><\/noindex> in \u0161e vedno slediti<\/a><\/noindex> smo njeno razvijanje. Zlasti se nam je zdelo zanimivo sodelovanje med Kafka in Kubernetes<\/a><\/noindex>. Pregledna (in precej previdna) \u010dlanek<\/a><\/noindex> o tej temi je bila objavljena na blogu podjetja Confluent \u017ee oktobra lani, avtorica je bila Gwen Shapira. Danes bi vam \u017eeleli opozoriti na nekoliko novej\u0161i aprilski \u010dlanek Johann Gygerja, ki\u010de obstaja s vpra\u0161ajem v naslovu, obravnava temo na bolj vsebinski na\u010din, in spremlja besedilo z zanimivimi povezavami. Opravi\u010dujemo se za prosto prevajanje \"chaos monkey\", \u010de lahko!<\/p>\n

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

Uvod<\/h4>\n

\nKubernetes je zasnovan za delo z obremenitvami, ki ne ohranjajo stanja. Obi\u010dajno so tak\u0161ne delovne obremenitve predstavljene v obliki mikroservisne arhitekture, so lahke, dobro se raz\u0161irijo horizontalno, spo\u0161tujejo na\u010dela 12 faktor aplikacij, omogo\u010dajo delovanje z avtomatskimi odklopniki (circuit breaker) in kaos opicami (chaos monkeys).<\/p>\n

Kafka pa z druge strani v resnici deluje kot razdeljena baza podatkov. Tako ob delu naletite na stanje, ki je precej te\u017eje od mikroservisa. Kubernetes podpira obremenitve z ohranjanjem stanja, vendar, kot opozarja Kelsey Hightower v dveh svojih tweetih, je s temi potrebno ravnati previdno:<\/p>\n

Nekaterim se zdi, da \u010de se na obremenitev z ohranjanjem stanja namesti Kubernetes, ta postane popolnoma upravljana baza podatkov, ki je zmo\u017ena tekmovati z RDS. To ne dr\u017ei. Morda, \u010de se dovolj potrudite, dodate dodatne komponente in pritegnete ekipo SRE in\u017eenirjev, lahko uspete ustvariti RDS na vrhu Kubernetesa.<\/p><\/blockquote>\n

Vedno priporo\u010dam izjemno previdnost pri zagonu obremenitev z ohranjanjem stanja na Kubernetesu. Ve\u010dina tistih, ki se spra\u0161ujejo: \"Ali lahko na Kubernetesu zagnati obremenitve z ohranjanjem stanja\" nima dovolj izku\u0161enj z delom s Kubernetesom, v mnogih primerih pa tudi z obremenitvijo, o kateri spra\u0161ujejo.<\/p><\/blockquote>\n

Torej, ali naj se Kafka poganja na Kubernetesu? Nasprotno vpra\u0161anje: ali bi Kafka delovala bolje brez Kubernetes? Zato \u017eelim v tem \u010dlanku poudariti, kako se Kafka in Kubernetes dopolnjujeta ter katere pasti se lahko pojavijo pri njunem kombiniranju.<\/p>\n

Vreme izvo\u0111enja<\/h4>\n

\nPogovorimo se o osnovni stvari \u2014 o okolju za izvr\u0161evanje kot takem.<\/p>\n

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

Brokerski stre\u017eniki Kafka so priro\u010dni pri delu s procesorjem. TLS lahko prinese dolo\u010dene stro\u0161ke. Hkrati lahko stranke Kafka mo\u010dneje obremenijo procesor, \u010de uporabljajo \u0161ifriranje, a to ne vpliva na brokerje.<\/p>\n

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

Brokerski stre\u017eniki Kafka hitro zasedejo pomnilnik. Velikost JVM kupa je obi\u010dajno omejena na 4\u20135 GB, vendar boste potrebovali tudi veliko sistemskega pomnilnika, saj Kafka zelo aktivno uporablja predpomnilnik strani. V Kubernetesu ustrezno nastavite omejitve virov in zahteve za kontejner.<\/p>\n

Shramba podatkov<\/b><\/i><\/p>\n

Shramba podatkov v kontejnerjih je efemerna \u2013 podatki se izgubijo ob ponovnem zagonu. Za podatke Kafka lahko uporabite volumen emptyDir<\/code>, in u\u010dinek bo podoben: podatki va\u0161ega brokerja bodo izgubljeni po kon\u010danem delu. Va\u0161a sporo\u010dila se vseeno lahko ohranijo na drugih brokerjih kot replike. Zato mora broker, ki je odpovedal, najprej replicirati vse podatke, kar lahko traja kar nekaj \u010dasa. <\/p>\n

Zato je treba uporabiti dolgoro\u010dno shrambo podatkov. Naj bo to neolokalna dolgoro\u010dna shramba s datote\u010dnim sistemom XFS ali, natan\u010dneje, ext4. Nefunkcionirajte NFS. Opozoril sem vas. NFS razli\u010dic v3 ali v4 ne bo delovala. Na kratko, broker Kafka bo kon\u010dal delo, \u010de ne bo mogel izbrisati imenika s podatki zaradi te\u017eave z \"neumnimi preimeni\u010denji\", ki velja za NFS. \u010ce vas do sedaj \u0161e nisem prepri\u010dal, bodite zelo pozorni preberite ta \u010dlanek<\/a><\/noindex>. Shramba podatkov mora biti neolokalna, da bo Kubernetes lahko bolj fleksibilno izbral nov vozli\u0161\u010de po ponovnem zagonu ali preselitvi.<\/p>\n

Omre\u017eje<\/b><\/i><\/p>\n

Kot v primeru ve\u010dine distribuiranih sistemov, je uspe\u0161nost Kafke mo\u010dno odvisna od minimalnih zamud v omre\u017eju in maksimalne pasovne \u0161irine. Ne posku\u0161ajte spraviti vseh posrednikov na isto vozli\u0161\u010de, saj se bo s tem zmanj\u0161ala razpolo\u017eljivost. \u010ce se vozli\u0161\u010de Kubernetes ustavi, bo celoten grozd Kafke prav tako odpovedal. Prav tako ne porazdeli energijo Kafke \u010dez celotna podatkovna sredi\u0161\u010da. Enako velja za grozd Kubernetes. Dober kompromis v tem primeru je izbira razli\u010dnih obmo\u010dij dostopnosti.<\/p>\n

\u041a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u044f<\/h4>\n

\nObi\u010dajni manifesti<\/b><\/i><\/p>\n

Na spletni strani Kubernetes je zelo dobra smernica<\/a><\/noindex> o tem, kako nastaviti ZooKeeper s pomo\u010djo manifestov. Ker je ZooKeeper del Kafke, je to dobro izhodi\u0161\u010de za spoznavanje konceptov, ki se tukaj uporabljajo v Kuberneteseu. Ko se s tem teko\u010de spoznate, boste lahko uporabili iste koncepte tudi za grozd Kafke.<\/p>\n