{"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":"Kas Kafka Kuberneteses on hea?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Kuna t\u00f5ime esmakordselt Vene turule teema Kafka<\/a><\/noindex> ja j\u00e4tkame j\u00e4lgida<\/a><\/noindex> selle arendamist. Eelk\u00f5ige tundus meile huvitav teema Kafka ja Kubernetes<\/a><\/noindex>. \u00dclevaatlik (ja \u00fcsna ettevaatlik) artikkel<\/a><\/noindex> selle teema kohta ilmus Confluenti blogis juba eelmise aasta oktoobris Gwen Shapiro autorluses. T\u00e4na soovime teie t\u00e4helepanu juhtida uuemale, aprillikuiselle artiklile Johann Gygerilt, kes, kuigi ei suutnud peatuda k\u00fcsim\u00e4rgi lisamiseta pealkirjas, k\u00e4sitleb teemat konkreetselt, t\u00e4iustades teksti huvitavate linkidega. Palun vabandage meie vaba t\u00f5lget \u201echaos monkey\u201c, kui suudate!<\/p>\n

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

Sissejuhatus<\/h4>\n

\nKubernetes on m\u00f5eldud t\u00f6\u00f6tama seisundit mitte s\u00e4ilitavate koormustega. Reeglina esindavad sellised t\u00f6\u00f6koormused mikroteenuste arhitektuuri, need on kerged, h\u00e4sti horisontaalselt skaleeritavad, alluvad 12-faktori rakenduste p\u00f5him\u00f5tetele ning v\u00f5imaldavad kasutada automaatseid katkestusi (circuit breaker) ja kaose ahve (chaos monkeys).<\/p>\n

Kafka, mis paikneb teisel pool, toimib sisuliselt jaotatud andmebaasina. Seega, t\u00f6\u00f6tades, peate arvestama seisundiga, mis on palju raskem kui mikroteenus. Kubernetes toetab olekuga koormusi, kuid nagu Kelsey Hightower oma kahes tweet'is osutab, tuleks nendega ettevaatlik olla:<\/p>\n

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

K soovitan alati olla \u00e4\u00e4rmiselt ettevaatlik, kui k\u00e4ivitate olekuga koormusi Kubernetes'es. Enamik neist, kes k\u00fcsivad, \"kas ma saan Kubernetes'es k\u00e4itada olekuga koormusi\", ei oma piisavalt kogemusi Kubernetes'ega, ja sageli ka selle koormusega, mille kohta k\u00fcsitakse.<\/p><\/blockquote>\n

Seega, kas peaks Kafka t\u00f6\u00f6tama Kubernetesel? Vastak\u00fcsimus: kas Kafka t\u00f6\u00f6tab paremini ilma Kuberneteseta? Just sellep\u00e4rast tahan ma selles artiklis r\u00f5hutada, kuidas Kafka ja Kubernetes \u00fcksteist t\u00e4iendavad ning millised vingerpussid v\u00f5ivad nende kombinatsiooniga kaasneda.<\/p>\n

K\u00e4itusaja<\/h4>\n

\nR\u00e4\u00e4gime k\u00f5ige olulisemast \u2014 k\u00e4ituskeskkonnast sellisena.<\/p>\n

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

Kafka brokerid on kasutusele lihtsad CPU-ga seotud. TLS v\u00f5ib kaasa tuua teatud kulud. Samuti v\u00f5ivad Kafka kliendid CPU-d rohkem koormata, kui nad kasutavad kr\u00fcpteerimist, kuid see ei m\u00f5juta brokereid.<\/p>\n

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

Kafka brokerid tarvitavad palju m\u00e4lu. JVM-i hunniku suurus on tavaliselt soovitatav piirata 4-5 GB peale, kuid vajate ka palju s\u00fcsteemim\u00e4lu, kuna Kafka kasutab lehek\u00fcljecache'i v\u00e4ga aktiivselt. Kuberneteses seadke vastavalt konteinerite ressurssidele piirangud ja n\u00f5uded.<\/p>\n

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

Konteinerites andmete salvestamine on efemerne \u2013 andmed kaovad taask\u00e4ivitamisel. Kafka andmete jaoks saab kasutada mahtu. emptyDir<\/code>, ja m\u00f5ju on sarnane: teie maakleri andmed kaovad p\u00e4rast l\u00f5petamist. Teie s\u00f5numid v\u00f5ivad siiski teiste maaklerite juures j\u00e4\u00e4da koopiatena. Seet\u00f5ttu peab p\u00e4rast taask\u00e4ivitamist h\u00e4vinud maakler k\u00f5igepealt taastama k\u00f5ik andmed, mis v\u00f5ib v\u00f5tta aega. <\/p>\n

Just seet\u00f5ttu tuleks kasutada pikaajalist andmete salvestamist. Olgu see mitte-lokaalne pikaajaline salvestamine koos XFS failis\u00fcsteemiga v\u00f5i t\u00e4psemalt ext4. \u00c4rge kasutage NFS-i. Ma hoiatasin. NFS versioonid v3 v\u00f5i v4 ei toimi. L\u00fchidalt, Kafka maakler l\u00f5petab t\u00f6\u00f6, kui ei suuda andmekaustat kustutada \u201elollide \u00fcmbernimetamise\u201d t\u00f5ttu, mis NFS-is kehtib. Kui ma ei ole teid veel veennud, siis lugege v\u00e4ga t\u00e4helepanelikult seda artiklit<\/a><\/noindex>. Andmete salvestamine peab olema mitte-lokaalne, et Kubernetes saaks p\u00e4rast taask\u00e4ivitamist v\u00f5i \u00fcmberpaigutamist paindlikumalt uut s\u00f5lme valida.<\/p>\n

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

Nagu enamikul hajutatud s\u00fcsteemidest, s\u00f5ltub Kafka j\u00f5udlus tugevalt sellest, et v\u00f5rgu latentsus oleks minimaalne ja ribalaius maksimaalne. \u00c4rge proovige k\u00f5ikide vahendajate paigutamist samale s\u00f5lmele, kuna see v\u00e4hendab saadavust. Kui Kubernetes'i s\u00f5lm peaks eba\u00f5nnestuma, eba\u00f5nnestub ka kogu Kafka klaster. Samuti \u00e4rge hajutage Kafka klastrit eri andmekeskustesse. Sama kehtib Kubernetes'i klastrite kohta. Hea kompromiss on valida erinevad k\u00e4ttesaadavuspiirkonnad.<\/p>\n

Konfiguratsioon<\/h4>\n

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

Kubernetes'i saidil on v\u00e4ga hea juhend<\/a><\/noindex> kuidas seadistada ZooKeeper'i manifestide abil. Kuna ZooKeeper on osa Kafka'st, on mugav alustada just sellest, et tutvuda, millised Kubernetes'i m\u00f5isted siinkohal rakenduvad. Kui olete sellega tuttav, saate samu m\u00f5isteid rakendada ka Kafka klastriga.<\/p>\n