Este bun Kafka pe Kubernetes?

Salutări, Habr!

La un moment dat, am fost primii care au introdus subiectul pe piața rusă Kafka si continua urma pentru dezvoltarea sa. În special, am găsit subiectul interacțiunii dintre Kafka și Kubernetes. Observabil (și destul de atent) articol acest subiect a fost publicat pe blogul Confluent în octombrie anul trecut, sub autoritatea lui Gwen Shapira. Astăzi dorim să vă atragem atenția asupra unui articol mai recent din aprilie al lui Johann Gyger, care, deși nu fără semn de întrebare în titlu, examinează subiectul într-o manieră mai substanțială, însoțind textul cu link-uri interesante. Vă rugăm să ne iertați traducerea gratuită a „maimuței haosului” dacă puteți!

Introducere

Kubernetes este conceput pentru a gestiona sarcinile de lucru fără stat. De obicei, astfel de sarcini de lucru sunt prezentate sub forma unei arhitecturi de microservicii, sunt ușoare, se scalează bine pe orizontală, urmează principiile aplicațiilor cu 12 factori și pot funcționa cu întrerupătoare și maimuțe haos.

Kafka, pe de altă parte, acționează în esență ca o bază de date distribuită. Astfel, atunci când lucrezi, trebuie să faci față statului și este mult mai greu decât un microserviciu. Kubernetes acceptă încărcări cu stare, dar așa cum subliniază Kelsey Hightower în două tweet-uri, acestea ar trebui tratate cu grijă:

Unii oameni consideră că, dacă introduceți Kubernetes într-un volum de lucru cu stare, acesta devine o bază de date complet gestionată, care rivalizează cu RDS. Este gresit. Poate că, dacă munciți suficient de mult, adăugați componente suplimentare și atrageți o echipă de ingineri SRE, veți putea construi RDS pe Kubernetes.

Recomand întotdeauna tuturor să fie extrem de precauți atunci când rulează sarcini de lucru cu stare pe Kubernetes. Majoritatea oamenilor care întreabă „pot rula încărcături de lucru cu stare pe Kubernetes” nu au suficientă experiență cu Kubernetes și adesea cu volumul de lucru despre care întreabă.

Deci, ar trebui să rulați Kafka pe Kubernetes? Contra întrebare: va funcționa Kafka mai bine fără Kubernetes? De aceea vreau să evidențiez în acest articol modul în care Kafka și Kubernetes se completează reciproc și ce capcane pot apărea prin combinarea lor.

Timpul de finalizare

Să vorbim despre lucrul de bază - mediul de rulare în sine

proces

Brokerii Kafka sunt prietenoși cu procesorul. TLS poate introduce unele cheltuieli generale. Cu toate acestea, clienții Kafka pot consuma mai mult CPU dacă folosesc criptarea, dar acest lucru nu îi afectează pe brokerii.

memorie

Brokerii Kafka mănâncă memoria. Dimensiunea heap-ului JVM este de obicei limitată la 4-5 GB, dar veți avea nevoie și de multă memorie de sistem, deoarece Kafka utilizează foarte mult memoria cache a paginii. În Kubernetes, setați resursele containerului și limitele de solicitare în consecință.

Magazin de date

Stocarea datelor în containere este efemeră - datele se pierd la repornire. Pentru datele Kafka puteți folosi un volum emptyDir, iar efectul va fi similar: datele brokerului dvs. se vor pierde după finalizare. Mesajele dvs. pot fi în continuare stocate pe alți brokeri ca replici. Prin urmare, după o repornire, brokerul eșuat trebuie mai întâi să reproducă toate datele, iar acest proces poate dura mult timp.

Acesta este motivul pentru care ar trebui să utilizați stocarea de date pe termen lung. Să fie stocare non-locală pe termen lung cu sistemul de fișiere XFS sau, mai precis, ext4. Nu folosiți NFS. Te-am avertizat. Versiunile NFS v3 sau v4 nu vor funcționa. Pe scurt, brokerul Kafka se va prăbuși dacă nu poate șterge directorul de date din cauza problemei „redenumire stupidă” din NFS. Dacă nu te-am convins încă, cu mare atenție citeste acest articol. Magazinul de date ar trebui să fie non-local, astfel încât Kubernetes să poată alege mai flexibil un nou nod după o repornire sau relocare.

rețea

Ca și în cazul majorității sistemelor distribuite, performanța Kafka depinde în mare măsură de menținerea latenței rețelei la un nivel minim și a lățimii de bandă la maximum. Nu încercați să găzduiți toți brokerii pe același nod, deoarece acest lucru va reduce disponibilitatea. Dacă un nod Kubernetes eșuează, întregul cluster Kafka va eșua. De asemenea, nu dispersați clusterul Kafka în centre de date întregi. Același lucru este valabil și pentru cluster-ul Kubernetes. Un compromis bun în acest caz este alegerea diferitelor zone de disponibilitate.

configurație

Manifeste regulate

Site-ul Kubernetes are ghid foarte bun despre cum să configurați ZooKeeper folosind manifeste. Deoarece ZooKeeper face parte din Kafka, acesta este un loc bun pentru a începe să vă familiarizați cu conceptele Kubernetes care se aplică aici. Odată ce înțelegeți acest lucru, puteți utiliza aceleași concepte cu un cluster Kafka.

• În: Un pod este cea mai mică unitate implementabilă din Kubernetes. Un pod conține volumul dvs. de lucru, iar podul în sine corespunde unui proces din clusterul dvs. Un pod conține unul sau mai multe recipiente. Fiecare server ZooKeeper din ansamblu și fiecare broker din clusterul Kafka vor rula într-un pod separat.
• StatefulSet: Un StatefulSet este un obiect Kubernetes care gestionează mai multe sarcini de lucru cu stare, iar astfel de sarcini necesită coordonare. StatefulSets oferă garanții cu privire la ordonarea podurilor și unicitatea acestora.
• Servicii fără cap: Serviciile vă permit să detașați podurile de la clienți folosind un nume logic. Kubernetes în acest caz este responsabil pentru echilibrarea încărcării. Cu toate acestea, atunci când operează sarcini de lucru cu stare, cum ar fi ZooKeeper și Kafka, clienții trebuie să comunice cu o anumită instanță. Aici sunt utile serviciile fără cap: în acest caz, clientul va avea în continuare un nume logic, dar nu va trebui să contactați direct podul.
• Volumul de stocare pe termen lung: Aceste volume sunt necesare pentru a configura stocarea persistentă a blocului non-local menționată mai sus.

Pe Yolean Oferă un set cuprinzător de manifeste pentru a vă ajuta să începeți cu Kafka pe Kubernetes.

Tabele de cârmă

Helm este un manager de pachete pentru un Kubernetes care poate fi comparat cu managerii de pachete ale sistemului de operare precum yum, apt, Homebrew sau Chocolatey. Facilitează instalarea pachetelor software predefinite descrise în diagramele Helm. O diagramă Helm bine aleasă face dificilă sarcina de a configura corect toți parametrii pentru a utiliza Kafka pe Kubernetes. Există mai multe diagrame Kafka: cea oficială este localizată în stare de incubator, există unul din joncțiune, încă unul - din BitNami.

operatori

Deoarece Helm are anumite neajunsuri, un alt instrument câștigă o popularitate considerabilă: operatorii Kubernetes. Operatorul nu numai că pachetează software pentru Kubernetes, dar vă permite și să implementați un astfel de software și să îl gestionați.

În listă operatori extraordinari Sunt menționați doi operatori pentru Kafka. Unul din ei - Strimzi. Cu Strimzi, este ușor să vă puneți în funcțiune clusterul Kafka în câteva minute. Practic nu este necesară nicio configurație, în plus, operatorul însuși oferă câteva caracteristici frumoase, de exemplu, criptarea TLS punct la punct în cadrul clusterului. Confluent oferă, de asemenea propriul operator.

productivitate

Este important să testați performanța prin compararea instanței dvs. Kafka. Astfel de teste vă vor ajuta să găsiți potențiale blocaje înainte să apară probleme. Din fericire, Kafka oferă deja două instrumente de testare a performanței: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Folosește-le activ. Pentru referință, puteți consulta rezultatele descrise în acest post Jay Kreps, sau concentrează-te pe această recenzie Amazon MSK de Stéphane Maarek.

operațiuni

monitorizarea

Transparența în sistem este foarte importantă - altfel nu veți înțelege ce se întâmplă în el. Astăzi există un set de instrumente solid care oferă monitorizare bazată pe metrici în stilul nativ cloud. Două instrumente populare în acest scop sunt Prometheus și Grafana. Prometheus poate colecta valori din toate procesele Java (Kafka, Zookeeper, Kafka Connect) folosind un exportator JMX - în cel mai simplu mod. Dacă adăugați valori cAdvisor, puteți înțelege mai pe deplin cum sunt utilizate resursele în Kubernetes.

Strimzi are un exemplu foarte convenabil de tablou de bord Grafana pentru Kafka. Vizualizează valori cheie, de exemplu, despre sectoarele subreplicate sau cele care sunt offline. Totul este foarte clar acolo. Aceste metrici sunt completate de informații despre utilizarea resurselor și performanță, precum și indicatori de stabilitate. Așa că obții monitorizarea de bază a clusterului Kafka pentru nimic!

Sursa: streamzi.io/docs/master/#kafka_dashboard

Ar fi bine să completam toate acestea cu monitorizarea clienților (metrici asupra consumatorilor și producătorilor), precum și cu monitorizarea latenței (pentru aceasta există Vizuină) și monitorizare end-to-end - pentru această utilizare Monitorul Kafka.

Logare

Logarea este o altă sarcină critică. Asigurați-vă că toate containerele din instalația dvs. Kafka sunt conectate stdout и stderrși, de asemenea, asigurați-vă că clusterul dvs. Kubernetes reunește toate jurnalele într-o infrastructură centrală de înregistrare, de ex. Elasticsearch.

Verificare funcțională

Kubernetes folosește sonde de viabilitate și de pregătire pentru a verifica dacă podurile tale funcționează normal. Dacă verificarea de viabilitate eșuează, Kubernetes va opri acel container și apoi îl va reporni automat dacă politica de repornire este setată corespunzător. Dacă verificarea pregătirii eșuează, Kubernetes izolează podul de solicitările de service. Astfel, în astfel de cazuri, intervenția manuală nu mai este deloc necesară, ceea ce este un mare plus.

Lansarea actualizărilor

StatefulSets acceptă actualizări automate: dacă selectați strategia RollingUpdate, fiecare sub Kafka va fi actualizat pe rând. În acest fel, timpul de nefuncționare poate fi redus la zero.

Scalare

Scalarea unui cluster Kafka nu este o sarcină ușoară. Cu toate acestea, Kubernetes face foarte ușor să scalați pod-urile la un anumit număr de replici, ceea ce înseamnă că puteți defini în mod declarativ cât de mulți brokeri Kafka doriți. Cel mai dificil lucru în acest caz este reatribuirea sectoarelor după mărire sau înainte de reducere. Din nou, Kubernetes vă va ajuta cu această sarcină.

administrare

Sarcinile legate de administrarea clusterului dvs. Kafka, cum ar fi crearea de subiecte și reatribuirea sectoarelor, pot fi efectuate folosind scripturi shell existente prin deschiderea interfeței de linie de comandă în pod-urile dvs. Cu toate acestea, această soluție nu este foarte frumoasă. Strimzi acceptă gestionarea subiectelor folosind un operator diferit. Există un loc de îmbunătățire aici.

Backup și restaurare

Acum, disponibilitatea lui Kafka va depinde și de disponibilitatea Kubernetes. Dacă clusterul dvs. Kubernetes eșuează, atunci, în cel mai rău caz, clusterul dvs. Kafka va eșua. Conform legii lui Murphy, acest lucru se va întâmpla cu siguranță și veți pierde date. Pentru a reduce acest tip de risc, aveți un concept bun de rezervă. Puteți utiliza MirrorMaker, o altă opțiune este să utilizați S3 pentru aceasta, așa cum este descris în aceasta post din Zalando.

Concluzie

Când lucrați cu clustere Kafka de dimensiuni mici și mijlocii, merită cu siguranță să utilizați Kubernetes, deoarece oferă flexibilitate suplimentară și simplifică experiența operatorului. Dacă aveți cerințe foarte semnificative de latență nefuncțională și/sau de debit, atunci poate fi mai bine să luați în considerare o altă opțiune de implementare.

Sursa: www.habr.com