{"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\/ro\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Kafka pe Kubernetes \u2014 este bine?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bun venit, Habr!<\/p>\n

\u00centr-o vreme, noi am fost primii care au adus pe pia\u021ba rus\u0103 tema Kafka<\/a><\/noindex> \u0219i continu\u0103m monitoriza<\/a><\/noindex> s\u0103 ne concentr\u0103m asupra dezvolt\u0103rii acesteia. \u00cen special, ni s-a p\u0103rut interesant subiectul interac\u021biunii dintre Kafka \u0219i Kubernetes<\/a><\/noindex>. O revizuire (\u0219i destul de prudent\u0103) articol<\/a><\/noindex> pe aceast\u0103 tem\u0103 a fost publicat\u0103 pe blogul companiei Confluent \u00eenc\u0103 din octombrie anul trecut, scris\u0103 de Gwen Shapira. Ast\u0103zi vrem s\u0103 atragem aten\u021bia asupra unui articol mai recent, din aprilie, scris de Johann Gyger, care, de\u0219i nu a ezitat s\u0103 pun\u0103 un semn de \u00eentrebare \u00een titlu, abordeaz\u0103 tema \u00eentr-o manier\u0103 mai concret\u0103, \u00eenso\u021bind textul cu linkuri interesante. V\u0103 cerem scuze pentru traducerea liber\u0103 a termenului \u201echaos monkey\u201d, dac\u0103 pute\u021bi!<\/p>\n

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

Introducere<\/h4>\n

\nKubernetes este destinat s\u0103 func\u021bioneze cu sarcini f\u0103r\u0103 stare. \u00cen general, aceste sarcini de lucru sunt reprezentate sub forma unei arhitecturi bazate pe microservicii, sunt u\u0219oare, se preteaz\u0103 bine la scalarea orizontal\u0103, respect\u0103 principiile aplica\u021biilor 12-factor \u0219i permit utilizarea \u00eentrerup\u0103toarelor automate (circuit breaker) \u0219i maimu\u021belor haotice (chaos monkeys).<\/p>\n

Kafka, situat de cealalt\u0103 parte, func\u021bioneaz\u0103 de fapt ca o baz\u0103 de date distribuit\u0103. Astfel, atunci c\u00e2nd lucra\u021bi, trebuie s\u0103 \u021bine\u021bi cont de starea sa, care este mult mai greoaie dec\u00e2t cea a unui microserviciu. Kubernetes suport\u0103 sarcini cu stare, dar, a\u0219a cum indic\u0103 Kelsey Hightower \u00een dou\u0103 dintre tweet-urile sale, trebuie tratate cu pruden\u021b\u0103:<\/p>\n

Unii cred c\u0103, dac\u0103 aplici Kubernetes pe o sarcin\u0103 cu stare, acesta devine o baz\u0103 de date complet gestionat\u0103, capabil\u0103 s\u0103 concureze cu RDS. Nu este a\u0219a. Poate c\u0103, dac\u0103 te str\u0103duie\u0219ti suficient, ad\u0103ug\u00e2nd componente suplimentare \u0219i implic\u00e2nd o echip\u0103 de ingineri SRE, po\u021bi construi RDS deasupra Kubernetes.<\/p><\/blockquote>\n

\u00centotdeauna recomand tuturor s\u0103 manifeste o pruden\u021b\u0103 deosebit\u0103 atunci c\u00e2nd ruleaz\u0103 sarcini cu stare pe Kubernetes. Cei mai mul\u021bi dintre cei care se \u00eentreab\u0103, \u201epot rula sarcini cu stare pe Kubernetes\u201d nu au suficient\u0103 experien\u021b\u0103 \u00een utilizarea Kubernetes \u0219i, de multe ori, nici cu sarcina despre care \u00eentreab\u0103.<\/p><\/blockquote>\n

Deci, ar trebui s\u0103 rul\u0103m Kafka pe Kubernetes? \u00centrebarea urm\u0103toare: va func\u021biona mai bine Kafka f\u0103r\u0103 Kubernetes? Iat\u0103 de ce vreau s\u0103 subliniez \u00een acest articol cum Kafka \u0219i Kubernetes se completeaz\u0103 reciproc \u0219i care sunt capcanele care pot ap\u0103rea \u00een combina\u021bia lor.<\/p>\n

Timp de execu\u021bie<\/h4>\n

\nS\u0103 discut\u0103m despre un aspect de baz\u0103 \u2014 mediu de execu\u021bie ca atare<\/p>\n

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

Brokerii Kafka sunt eficien\u021bi \u00een utilizarea CPU. TLS poate ad\u0103uga anumite cheltuieli. Cu toate acestea, clien\u021bii Kafka pot suprasolicita CPU-ul mai mult dac\u0103 utilizeaz\u0103 criptarea, dar acest lucru nu afecteaz\u0103 brokerii.<\/p>\n

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

Brokerii Kafka consum\u0103 memorie. Dimensiunea heap-ului JVM este de obicei limitat\u0103 la 4\u20135 GB, dar ve\u021bi avea nevoie \u0219i de mult\u0103 memorie sistemic\u0103, deoarece Kafka folose\u0219te foarte activ cache-ul de pagini. \u00cen Kubernetes, stabili\u021bi corespunz\u0103tor limitele resurselor \u0219i cererile pentru containere.<\/p>\n

Stocare de date<\/b><\/i><\/p>\n

Stocarea de date \u00een containere este efemer\u0103 \u2013 datele se pierd la repornire. Pentru datele Kafka, pute\u021bi folosi un volum, iar efectul va fi similar: datele brokerului dumneavoastr\u0103 vor fi pierdute dup\u0103 finalizare. Mesajele dumneavoastr\u0103 pot fi totu\u0219i p\u0103strate pe al\u021bi brokeri ca replici. Prin urmare, dup\u0103 repornire, brokerul care a e\u0219uat trebuie mai \u00eent\u00e2i s\u0103 replica toate datele, iar acest proces poate necesita mult timp. emptyDir<\/code>De aceea, ar trebui s\u0103 folosi\u021bi stocare de date pe termen lung. S\u0103 fie o stocare de lung\u0103 durat\u0103 non-local\u0103 cu un sistem de fi\u0219iere XFS sau, mai precis, ext4. Nu folosi\u021bi NFS. V-am avertizat. NFS versiuni v3 sau v4 nu vor func\u021biona. Pe scurt, brokerul Kafka se va opri dac\u0103 nu poate \u0219terge directorul cu date din cauza problemei cu \"renumirile stupide\", care este actual\u0103 \u00een NFS. Dac\u0103 p\u00e2n\u0103 acum nu v-am convins, citi\u021bi cu mare aten\u021bie <\/p>\n

aceast\u0103 articol . Stocarea de date ar trebui s\u0103 fie non-local\u0103, pentru ca Kubernetes s\u0103 poat\u0103 alege mai flexibil un nou nod dup\u0103 repornire sau relocare.<\/a><\/noindex>.<\/p>\n

Re\u021bea<\/b><\/i><\/p>\n

Asemenea majorit\u0103\u021bii sistemelor distribuite, performan\u021ba Kafka depinde semnificativ de minimizarea laten\u021belor de re\u021bea \u0219i maximizarea l\u0103\u021bimii de band\u0103. Nu \u00eencerca\u021bi s\u0103 plasa\u021bi to\u021bi brokerii pe acela\u0219i nod, deoarece acest lucru va reduce disponibilitatea. Dac\u0103 un nod Kubernetes e\u0219ueaz\u0103, \u00eentregul cluster Kafka va e\u0219ua \u0219i el. De asemenea, nu disp\u0103ra\u021bi clusterul Kafka pe \u00eentregi centre de date. Acela\u0219i lucru se aplic\u0103 \u0219i clusterului Kubernetes. O bun\u0103 compensa\u021bie \u00een acest caz este alegerea unor zone de disponibilitate diferite.<\/p>\n

Configura\u021bie<\/h4>\n

\nManifesturi obi\u0219nuite<\/b><\/i><\/p>\n

Pe site-ul Kubernetes exist\u0103 un ghid foarte bun<\/a><\/noindex> despre cum s\u0103 configura\u021bi ZooKeeper folosind manifesturi. Deoarece ZooKeeper face parte din Kafka, este convenabil s\u0103 \u00eencepe\u021bi familiarizarea cu conceptele Kubernetes aplicabile aici. Odat\u0103 ce \u00een\u021belege\u021bi asta, ve\u021bi putea utiliza acelea\u0219i concepte \u0219i cu clusterul Kafka.<\/p>\n