{"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\/et\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Kafka Kuberneteses - kas see on hea?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere tulemast, Habr!<\/p>\n

Oma ajal olime esimesed, kes t\u00f5id Venemaa turule teema Kafka<\/a><\/noindex> ja j\u00e4tkame j\u00e4lgib<\/a><\/noindex> selle arendamist. Eelk\u00f5ige leidis meile huvi teema Kafka ja Kubernetes<\/a><\/noindex>. \u00dclevaade (ja \u00fcsna ettevaatlik) artikkel<\/a><\/noindex> selle teema kohta ilmus Confluenti ettev\u00f5tte blogis juba eelmise aasta oktoobris Gwen Shapiro autorlusega. T\u00e4nap\u00e4eval tahame aga juhtida teie t\u00e4helepanu v\u00e4rskemale, aprillis ilmunud artiklile Johann Gygerilt, kes, kuigi ei suutnud v\u00e4ltida k\u00fcsim\u00e4rki pealkirjas, k\u00e4sitleb teemat konkreetsemalt, lisades tekstile huvitavaid linke. Palun andestage meile vabak\u00e4eline t\u00f5lge \"chaos monkey\", kui saate!<\/p>\n

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

Sissejuhatus<\/h4>\n

\nKubernetes on m\u00f5eldud t\u00f6\u00f6tama olekuta koormuste, st. tavaliselt mikroteenuste arhitektuuri vormis, mis on kerged, h\u00e4sti skaleeritavad ja j\u00e4rgivad 12-faktori rakenduse p\u00f5him\u00f5tteid, v\u00f5imaldades t\u00f6\u00f6tada automaatsete katkestajate (circuit breaker) ja kaose ahvidega (chaos monkeys).<\/p>\n

Kafka, mis asub teisel pool, toimib sisuliselt jaotatud andmebaasina. Seega peate t\u00f6\u00f6tama olekuga, mis on palju raskem kui mikroteenus. Kubernetes toetab olekuga koormusi, kuid nagu osutab Kelsey Hightower oma kahe s\u00e4utsu kaudu, tuleb nendega olla ettevaatlik:<\/p>\n

M\u00f5ned arvavad, et kui paigaldada Kubernetes olekuga koormusele, muutub see t\u00e4ielikult hallatavaks andmebaasiks, mis suudab konkureerida RDS-iga. Nii see ei ole. V\u00f5ib-olla, kui piisavalt vaeva n\u00e4ha, lisada t\u00e4iendavad komponendid ja kaasata SRE-insenere, on v\u00f5imalik rajada RDS Kubernetes'i peale.<\/p><\/blockquote>\n

Soovitan alati \u00e4\u00e4rmiselt ettevaatlikult l\u00e4heneda olekuga koormuste k\u00e4ivitamisele Kuberneteses. Enamik inimesi, kes k\u00fcsivad, \"kas ma saan Kuberneteses k\u00e4itada olekuga koormusi\", ei oma piisavat kogemust Kubernetesega t\u00f6\u00f6tamisel ja tihti \u2013 isegi selle koormuse osas, mille kohta k\u00fcsitakse.<\/p><\/blockquote>\n

Nii et, kas peaksime k\u00e4ivitama Kafka Kubernetesel? Vastuk\u00fcsimus: kas Kafka t\u00f6\u00f6tab paremini ilma Kuberneteseta? Just seet\u00f5ttu tahan selles artiklis r\u00f5hutada, kuidas Kafka ja Kubernetes \u00fcksteist t\u00e4iustavad ning millised takistused v\u00f5ivad tekkida nende kombinatsiooni korral.<\/p>\n

Suunamine<\/h4>\n

\nR\u00e4\u00e4gime alustest \u2014 jooksukeskkonnast kui sellisest.<\/p>\n

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

Kafka maaklerid sobivad h\u00e4sti CPU kasutamiseks. TLS v\u00f5ib tuua kaasa teatud kulud. Sellegipoolest v\u00f5ivad Kafka kliendid koormata CPU-d rohkem, kui nad kasutavad kr\u00fcpteerimist, kuid see ei m\u00f5juta maaklereid.<\/p>\n

M\u00e4lu<\/b><\/i><\/p>\n

Kafka maaklerid kasutavad m\u00e4lu. JVM-i kuhja suurust on tavaliselt soovitatav piirata 4\u20135 GB-ni, kuid teil on vaja ka palju s\u00fcsteemim\u00e4lu, kuna Kafka kasutab lehe vahem\u00e4lu v\u00e4ga aktiivselt. Kuberneteses seadistage konteineri ressursside piirangud ja n\u00f5udmised vastavalt.<\/p>\n

Andmete salvestamine<\/b><\/i><\/p>\n

Konteineritesse salvestatud andmed on ajutised \u2013 andmed kaovad taask\u00e4ivitamisel. Kafka andmete jaoks v\u00f5ib kasutada vol\u00fc\u00fcmi, emptyDir<\/code>, ja efekt on sama: teie maakleri andmed kaovad p\u00e4rast sulgemist. Teie s\u00f5numid v\u00f5ivad siiski j\u00e4\u00e4da teistes maaklerites replikatena. Seet\u00f5ttu peab p\u00e4rast taask\u00e4ivitamist esmajoones replikatsiooniprotsessi k\u00e4ivitama eba\u00f5nnestunud maakler, mis v\u00f5ib v\u00f5tta p\u00e4ris kaua aega. <\/p>\n

Seet\u00f5ttu on soovitatav kasutada pikaajalist andmesalvestust. Olgu see mittelikealne pikaajaline salvestus XFS failis\u00fcsteemiga v\u00f5i t\u00e4psemalt ext4. \u00c4rge kasutage NFS-i. Ma hoiatatud. NFS versioonid v3 v\u00f5i v4 ei t\u00f6\u00f6ta. L\u00fchidalt kokku v\u00f5ttes, Kafka maakler l\u00f5petab t\u00f6\u00f6, kui ta ei saa andmekausta kustutada t\u00e4nu probleemile \"rumalate \u00fcmbernimetamisega\", mis on NFS-is aktuaalne. Kui ma teid siiani ei veennud, vaadake v\u00e4ga t\u00e4helepanelikult lugeda seda artiklit<\/a><\/noindex>. Andmesalvestus peab olema mittelikealne, et Kubernetes saaks taask\u00e4ivitamisel v\u00f5i uue s\u00f5lme valimisel olema paindlikum.<\/p>\n

V\u00f5rk<\/b><\/i><\/p>\n

Nagu enamikus hajutatud s\u00fcsteemides, s\u00f5ltub Kafka j\u00f5udlus tugevalt sellest, et v\u00f5rgu hilinemine oleks minimaalne ja ribalaius maksimaalne. \u00c4ra p\u00fc\u00fca paigutada k\u00f5iki brokereid samale s\u00f5lmele, sest see v\u00e4hendab k\u00e4ttesaadavust. Kui Kubernetes'i s\u00f5lm eba\u00f5nnestub, eba\u00f5nnestub ka kogu Kafka klaster. Samuti \u00e4ra jaota Kafka klastrit laialdaselt erinevate andmekeskuste vahel. Sama kehtib Kubernetes'i klustreid. Heaks kompromissiks on valida erinevad k\u00e4ttesaadavuse tsoonid.<\/p>\n

Konfiguratsioon<\/h4>\n

\nTavalised manifestid<\/b><\/i><\/p>\n

Kubernetes'i veebisaidil on v\u00e4ga hea juhend<\/a><\/noindex> kuidas seadistada ZooKeeperit manifestide abil. Kuna ZooKeeper on osa Kafka'st, on sellest mugav alustada tutvumist nendega, millised Kubernetes'i kontseptsioonid siinkohal kohaldavad. P\u00e4rast nende m\u00f5istmist saad kasutada samu kontseptsioone ka Kafka klastris.<\/p>\n