{"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\/it\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Kafka su Kubernetes: \u00e8 una buona cosa?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Benvenuti, Habr!<\/p>\n

All'epoca siamo stati i primi a portare sul mercato russo il tema Kafka<\/a><\/noindex> e continuiamo di monitorare<\/a><\/noindex> a seguirne l'evoluzione. In particolare, ci \u00e8 sembrato interessante il tema dell'interazione tra Kafka e Kubernetes<\/a><\/noindex>. Un'analisi (e piuttosto cauta) su Habr.<\/a><\/noindex> su questo argomento \u00e8 stata pubblicata nel blog dell'azienda Confluent gi\u00e0 nell'ottobre dello scorso anno a firma di Gwen Shapiro. Oggi vogliamo attirare la vostra attenzione su un articolo pi\u00f9 recente, di aprile, di Johann Gyger, che, pur non essendosi astenuto dall'usare un punto interrogativo nel titolo, esplora il tema in una chiave pi\u00f9 specifica, accompagnando il testo con link interessanti. Vi chiediamo scusa per la libera traduzione di \u00abchaos monkey\u00bb, se ce la fate!<\/p>\n

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

Introduzione<\/h4>\n

\nKubernetes \u00e8 progettato per gestire carichi di lavoro senza stato. Di norma, questi tipi di carichi di lavoro sono rappresentati in forma di architettura a microservizi, sono leggeri, scalabili orizzontalmente, seguono i principi delle applicazioni a 12 fattori, e permettono di lavorare con interruttori automatici (circuit breaker) e scimmie del caos (chaos monkeys).<\/p>\n

Kafka, d'altra parte, funge essenzialmente da database distribuito. Pertanto, quando si lavora, bisogna gestire uno stato, che \u00e8 molto pi\u00f9 pesante di un microservizio. Kubernetes supporta carichi di lavoro con stato, ma, come sottolinea Kelsey Hightower in due dei suoi tweet, bisogna fare attenzione:<\/p>\n

Alcuni pensano che se si applica Kubernetes a un carico di lavoro con stato, esso diventi un database completamente gestito in grado di competere con RDS. Non \u00e8 cos\u00ec. Forse, se si lavora abbastanza, si possono aggiungere componenti e coinvolgere un team di ingegneri SRE, si potrebbe configurare un RDS su Kubernetes.<\/p><\/blockquote>\n

Raccomando sempre di prestare estrema attenzione quando si avviano carichi di lavoro con stato su Kubernetes. La maggior parte di coloro che si chiedono: \u00abPosso eseguire carichi di lavoro con stato su Kubernetes?\u00bb non ha esperienza sufficiente con Kubernetes e spesso nemmeno con il carico di lavoro in questione.<\/p><\/blockquote>\n

Quindi, vale la pena eseguire Kafka su Kubernetes? Una domanda a contrario: funzionerebbe meglio Kafka senza Kubernetes? Ecco perch\u00e9 voglio sottolineare in questo articolo come Kafka e Kubernetes si completino a vicenda e quali insidie possono sorgere dalla loro combinazione.<\/p>\n

Tempo di esecuzione<\/h4>\n

\nParliamo di una cosa fondamentale: l'ambiente di runtime in quanto tale<\/p>\n

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

I broker Kafka sono efficienti nell'uso della CPU. Il TLS pu\u00f2 comportare alcuni costi. Tuttavia, i client Kafka possono caricare maggiormente la CPU se utilizzano la crittografia, ma ci\u00f2 non influisce sui broker.<\/p>\n

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

I broker Kafka consumano memoria. La dimensione della heap JVM di solito deve essere limitata a 4-5 GB, ma avrete anche bisogno di molta memoria di sistema, poich\u00e9 Kafka utilizza molto attivamente la cache delle pagine. In Kubernetes, impostate adeguatamente i limiti delle risorse e le richieste del container.<\/p>\n

Storage dei dati<\/b><\/i><\/p>\n

Lo storage dei dati nei container \u00e8 efimero: i dati vanno persi al riavvio. Per i dati di Kafka, si pu\u00f2 utilizzare un volume emptyDir<\/code>, e l'effetto sar\u00e0 analogo: i dati del vostro broker andranno persi dopo la chiusura. I vostri messaggi possono comunque essere conservati su altri broker come repliche. Pertanto, dopo il riavvio, il broker difettoso deve prima replicare tutti i dati, e questo processo pu\u00f2 richiedere un bel po' di tempo. <\/p>\n

Ecco perch\u00e9 \u00e8 necessario utilizzare uno storage di dati durevole. Deve essere uno storage durevole non locale con un filesystem XFS o, pi\u00f9 precisamente, ext4. Non utilizzare NFS. Te l\u2019ho detto. NFS versione v3 o v4 non funzioner\u00e0. In breve, il broker Kafka si fermer\u00e0 se non riesce a eliminare la directory dei dati a causa di problemi con le \"rinomine stupide\", rilevanti in NFS. Se non ti ho ancora convinto, presta molta attenzione leggi questo articolo<\/a><\/noindex>. Lo storage dei dati deve essere non locale, affinch\u00e9 Kubernetes possa scegliere un nuovo nodo in modo pi\u00f9 flessibile dopo un riavvio o una relocation.<\/p>\n

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

Come nella maggior parte dei sistemi distribuiti, le prestazioni di Kafka dipendono fortemente dal mantenere al minimo le latenze di rete e al massimo la larghezza di banda. Non tentate di posizionare tutti i broker sullo stesso nodo, poich\u00e9 ci\u00f2 ridurrebbe la disponibilit\u00e0. Se un nodo Kubernetes fallisce, fallir\u00e0 anche l'intero cluster Kafka. Inoltre, non disperdete il cluster Kafka su interi data center. Lo stesso vale per il cluster Kubernetes. Un buon compromesso in questo caso \u00e8 scegliere diverse zone di disponibilit\u00e0.<\/p>\n

Configurazione<\/h4>\n

\nManifesti comuni<\/b><\/i><\/p>\n

Sul sito di Kubernetes c'\u00e8 una guida molto utile<\/a><\/noindex> su come configurare ZooKeeper utilizzando i manifesti. Poich\u00e9 ZooKeeper fa parte di Kafka, \u00e8 un buon punto di partenza per familiarizzare con le concetti di Kubernetes applicabili qui. Una volta compreso ci\u00f2, sarete in grado di applicare le stesse concezioni anche al cluster Kafka.<\/p>\n