Salutacions, Habr!
En un moment, vam ser els primers a introduir el tema al mercat rus i continuar pel seu desenvolupament. En particular, hem trobat el tema de la interacció entre Kafka i . Observable (i força curós) aquest tema es va publicar al bloc Confluent l'octubre de l'any passat sota l'autoria de Gwen Shapira. Avui volem cridar la vostra atenció sobre un article més recent d'abril de Johann Gyger, que, encara que no exempt d'un signe d'interrogació en el títol, examina el tema d'una manera més substantiva, acompanyant el text amb enllaços interessants. Si us plau, perdoneu-nos la traducció gratuïta de "mono del caos" si podeu!
Introducció
Kubernetes està dissenyat per gestionar càrregues de treball sense estat. Normalment, aquestes càrregues de treball es presenten en forma d'arquitectura de microservei, són lleugeres, s'escalen bé horitzontalment, segueixen els principis de les aplicacions de 12 factors i poden funcionar amb interruptors i micos del caos.
Kafka, en canvi, actua essencialment com una base de dades distribuïda. Així, quan treballeu, heu de fer front a l'estat, i és molt més pesat que un microservei. Kubernetes admet càrregues amb estat, però tal com assenyala Kelsey Hightower en dos tuits, s'han de manejar amb cura:
Algunes persones creuen que si poseu Kubernetes a una càrrega de treball amb estat, es converteix en una base de dades totalment gestionada que rivalitza amb RDS. Això està malament. Potser, si treballeu prou, afegiu components addicionals i atreu un equip d'enginyers SRE, podreu construir RDS a sobre de Kubernetes.
Sempre recomano que tothom tingui molta precaució quan executeu càrregues de treball amb estat a Kubernetes. La majoria de les persones que pregunten "Puc executar càrregues de treball amb estat a Kubernetes" no tenen prou experiència amb Kubernetes i sovint amb la càrrega de treball que estan preguntant.
Aleshores, hauríeu d'executar Kafka a Kubernetes? Pregunta contraria: Kafka funcionarà millor sense Kubernetes? És per això que vull destacar en aquest article com Kafka i Kubernetes es complementen i quins inconvenients poden comportar-los combinar-los.
Temps de finalització
Parlem de la cosa bàsica: el propi entorn d'execució
procés
Els corredors de Kafka són compatibles amb la CPU. TLS pot introduir algunes despeses generals. Tanmateix, els clients Kafka poden ser més intensius de CPU si utilitzen el xifratge, però això no afecta els corredors.
Память
Els corredors de Kafka es mengen la memòria. La mida de l'emmagatzematge de la JVM sol limitar-se a 4-5 GB, però també necessitareu molta memòria del sistema, ja que Kafka utilitza molt la memòria cau de la pàgina. A Kubernetes, establiu els límits dels recursos del contenidor i de la sol·licitud en conseqüència.
Emmagatzematge de dades
L'emmagatzematge de dades als contenidors és efímer: les dades es perden quan es reinicien. Per a les dades de Kafka podeu utilitzar un volum emptyDir, i l'efecte serà similar: les dades del vostre corredor es perdran un cop finalitzat. Els vostres missatges encara es poden emmagatzemar en altres corredors com a rèpliques. Per tant, després d'un reinici, el corredor fallit primer ha de replicar totes les dades i aquest procés pot trigar molt de temps.
És per això que hauríeu d'utilitzar l'emmagatzematge de dades a llarg termini. Que sigui un emmagatzematge no local a llarg termini amb el sistema de fitxers XFS o, més precisament, ext4. No utilitzeu NFS. Et vaig avisar. Les versions de NFS v3 o v4 no funcionaran. En resum, el corredor de Kafka es bloquejarà si no pot suprimir el directori de dades a causa del problema de "canviar el nom estúpid" a NFS. Si encara no t'he convençut, amb molta cura . El magatzem de dades hauria de ser no local perquè Kubernetes pugui triar un node nou de manera més flexible després d'un reinici o una reubicació.
Xarxa
Com passa amb la majoria de sistemes distribuïts, el rendiment de Kafka depèn molt de mantenir la latència de la xarxa al mínim i l'amplada de banda al màxim. No intenteu allotjar tots els corredors al mateix node, ja que això reduirà la disponibilitat. Si falla un node de Kubernetes, fallarà tot el clúster de Kafka. A més, no disperseu el clúster de Kafka en centres de dades sencers. El mateix passa amb el clúster de Kubernetes. Un bon compromís en aquest cas és triar diferents zones de disponibilitat.
Configuració
Manifests periòdics
El lloc web de Kubernetes té sobre com configurar ZooKeeper mitjançant manifests. Com que ZooKeeper forma part de Kafka, aquest és un bon lloc per començar a familiaritzar-se amb quins conceptes de Kubernetes s'apliquen aquí. Un cop hàgiu entès això, podeu utilitzar els mateixos conceptes amb un clúster de Kafka.
- Sota: Un pod és la unitat desplegable més petita de Kubernetes. Un pod conté la vostra càrrega de treball i el pod en si correspon a un procés del vostre clúster. Una beina conté un o més contenidors. Cada servidor ZooKeeper del conjunt i cada corredor del clúster Kafka s'executaran en un pod independent.
- StatefulSet: Un StatefulSet és un objecte de Kubernetes que gestiona diverses càrregues de treball amb estat, i aquestes càrregues de treball requereixen coordinació. StatefulSets ofereix garanties pel que fa a l'ordre de les beines i la seva singularitat.
- Serveis sense cap: els serveis us permeten separar pods dels clients mitjançant un nom lògic. Kubernetes en aquest cas és responsable de l'equilibri de càrrega. Tanmateix, quan operen càrregues de treball amb estat, com ara ZooKeeper i Kafka, els clients han de comunicar-se amb una instància específica. Aquí és on els serveis sense cap són útils: en aquest cas, el client encara tindrà un nom lògic, però no haureu de contactar directament amb el pod.
- Volum d'emmagatzematge a llarg termini: aquests volums són necessaris per configurar l'emmagatzematge persistent de blocs no locals esmentat anteriorment.
En Proporciona un conjunt complet de manifests per ajudar-vos a començar amb Kafka a Kubernetes.
Gràfiques de timó
Helm és un gestor de paquets per a un Kubernetes que es pot comparar amb gestors de paquets del sistema operatiu com ara yum, apt, Homebrew o Chocolatey. Facilita la instal·lació de paquets de programari predefinits descrits als gràfics Helm. Un gràfic Helm ben escollit facilita la difícil tasca de configurar correctament tots els paràmetres per utilitzar Kafka a Kubernetes. Hi ha diversos diagrames de Kafka: es localitza l'oficial , n'hi ha un de , un més - de .
Operadors
Com que Helm té certes deficiències, una altra eina està guanyant una popularitat considerable: els operadors de Kubernetes. L'operador no només empaqueta programari per a Kubernetes, sinó que també us permet implementar aquest programari i gestionar-lo.
A la llista S'esmenten dos operadors de Kafka. Un d'ells - . Amb Strimzi, és fàcil posar en funcionament el vostre clúster Kafka en qüestió de minuts. Pràcticament no es requereix cap configuració, a més, el propi operador ofereix algunes funcions agradables, per exemple, el xifratge TLS punt a punt dins del clúster. Confluent també ofereix .
Productivitat
És important provar el rendiment fent comparatives de la vostra instància de Kafka. Aquestes proves us ajudaran a trobar possibles colls d'ampolla abans que es produeixin problemes. Afortunadament, Kafka ja ofereix dues eines de prova de rendiment: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Fes-ne un ús actiu. Com a referència, podeu consultar els resultats descrits a Jay Kreps, o centrar-se en Amazon MSK de Stéphane Maarek.
Operacions
Seguiment
La transparència en el sistema és molt important; en cas contrari, no entendreu què hi passa. Avui hi ha un conjunt d'eines sòlid que proporciona un seguiment basat en mètriques a l'estil natiu del núvol. Dues eines populars per a aquest propòsit són Prometeu i Grafana. Prometheus pot recopilar mètriques de tots els processos Java (Kafka, Zookeeper, Kafka Connect) mitjançant un exportador JMX, de la manera més senzilla. Si afegiu mètriques de cAdvisor, podreu entendre millor com s'utilitzen els recursos a Kubernetes.
Strimzi té un exemple molt convenient de tauler de control de Grafana per a Kafka. Visualitza mètriques clau, per exemple, sobre els sectors poc replicats o els que estan fora de línia. Allà està tot molt clar. Aquestes mètriques es complementen amb informació sobre l'ús dels recursos i el rendiment, així com amb indicadors d'estabilitat. Així que obteniu un seguiment bàsic del clúster de Kafka per res!
Font:
Seria bo complementar tot això amb el seguiment del client (mètriques sobre consumidors i productors), així com el seguiment de la latència (per això hi ha ) i monitorització d'extrem a extrem - per a aquest ús .
Enregistrament
El registre és una altra tasca crítica. Assegureu-vos que tots els contenidors de la vostra instal·lació de Kafka estiguin registrats stdout и stderr, i també assegureu-vos que el vostre clúster de Kubernetes agrupi tots els registres en una infraestructura de registre central, p. .
Prova funcional
Kubernetes utilitza sondes de vivacitat i preparació per comprovar si els vostres pods funcionen amb normalitat. Si la comprovació d'activació falla, Kubernetes aturarà aquest contenidor i després el reiniciarà automàticament si la política de reinici s'estableix en conseqüència. Si la comprovació de preparació falla, Kubernetes aïlla el pod de les sol·licituds de servei. Així, en aquests casos, la intervenció manual ja no és necessària, la qual cosa és un gran avantatge.
Desplegant actualitzacions
StatefulSets admet actualitzacions automàtiques: si seleccioneu l'estratègia RollingUpdate, cadascuna de Kafka s'actualitzarà al seu torn. D'aquesta manera, el temps d'inactivitat es pot reduir a zero.
Escalat
Escalar un clúster de Kafka no és una tasca fàcil. Tanmateix, Kubernetes fa que sigui molt fàcil escalar pods a un nombre determinat de rèpliques, el que significa que podeu definir de manera declarativa tants corredors de Kafka com vulgueu. El més difícil en aquest cas és reassignar sectors després d'augmentar o abans de reduir l'escala. De nou, Kubernetes us ajudarà amb aquesta tasca.
Administració
Les tasques relacionades amb l'administració del vostre clúster de Kafka, com ara la creació de temes i la reassignació de sectors, es poden fer mitjançant scripts d'intèrpret d'ordres existents obrint la interfície de línia d'ordres als vostres pods. Tanmateix, aquesta solució no és molt bonica. Strimzi admet la gestió de temes mitjançant un operador diferent. Aquí hi ha marge de millora.
Còpia de seguretat i restaurar
Ara la disponibilitat de Kafka també dependrà de la disponibilitat de Kubernetes. Si el vostre clúster de Kubernetes falla, en el pitjor dels casos, el vostre clúster Kafka també fallarà. Segons la llei de Murphy, això passarà definitivament i perdràs dades. Per reduir aquest tipus de risc, tingueu un bon concepte de còpia de seguretat. Podeu utilitzar MirrorMaker, una altra opció és utilitzar S3 per a això, tal com es descriu aquí de Zalando.
Conclusió
Quan es treballa amb clústers Kafka de mida petita i mitjana, val la pena utilitzar Kubernetes, ja que proporciona flexibilitat addicional i simplifica l'experiència de l'operador. Si teniu requisits de latència no funcional i/o de rendiment molt significatius, potser és millor considerar alguna altra opció de desplegament.
Font: www.habr.com