{"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 \u2014 \u00e8 una buona idea?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Benvenuti, Habr!<\/p>\n

In passato, siamo stati i primi a lanciare sul mercato russo il tema Kafka<\/a><\/noindex> e continuiamo di seguire<\/a><\/noindex> a seguirne lo sviluppo. In particolare, ci \u00e8 sembrato interessante il tema dell'interazione tra Kafka e Kubernetes<\/a><\/noindex>. Un'analisi (e piuttosto cauta) su questo argomento \u00e8 stata pubblicata nel blog dell'azienda Confluent gi\u00e0 nell'ottobre dello scorso anno a cura di Gwen Shapiro. Oggi vogliamo attirare la vostra attenzione su un articolo pi\u00f9 recente, di aprile, di Johann Gyger, il quale, sebbene non abbia evitato un punto interrogativo nel titolo, affronta la questione in modo pi\u00f9 concreto, accompagnando il testo con link interessanti. Scusateci, per favore, per la traduzione libera di \"chaos monkey\", se potete! articolo<\/a><\/noindex> di questo argomento si era gi\u00e0 parlato nel blog dell'azienda Confluent nell'ottobre dello scorso anno a cura di Gwen Shapiro. Oggi vogliamo richiamare la vostra attenzione su un articolo pi\u00f9 recente di aprile di Johann Gyger, che, sebbene non abbia evitato un punto interrogativo nel titolo, affronta il tema in modo pi\u00f9 concreto, accompagnando il testo con link interessanti. Vi preghiamo di scusare la nostra traduzione libera di \"chaos monkey\", se possibile!<\/p>\n

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

Introduzione<\/h4>\n

\nKubernetes \u00e8 progettato per gestire carichi di lavoro senza stato. In genere, questi carichi di lavoro sono rappresentati in forma di architetture a microservizi, sono leggeri, ben scalabili orizzontalmente, seguono i principi delle applicazioni 12-factor, consentono di lavorare con interruttori automatici (circuit breaker) e scimmie del caos (chaos monkeys).<\/p>\n

Kafka, posizionato dall'altra parte, funge sostanzialmente da database distribuito. Di conseguenza, quando si lavora, ci si deve confrontare con lo stato, che \u00e8 molto pi\u00f9 pesante di un microservizio. Kubernetes supporta i carichi di lavoro con stato, ma, come sottolinea Kelsey Hightower nei suoi due tweet, bisogna maneggiarli con cautela:<\/p>\n

Alcuni credono che se si implementa Kubernetes su un carico di lavoro con stato, esso diventi un database completamente gestito, in grado di competere con RDS. Non \u00e8 cos\u00ec. Forse, con sufficiente impegno, aggiungendo componenti e coinvolgendo un team di ingegneri SRE, si riesce a configurare RDS sopra Kubernetes.<\/p><\/blockquote>\n

Raccomando sempre di essere estremamente cauti nel lanciare carichi di lavoro con stato su Kubernetes. La maggior parte di coloro che si chiedono 'posso eseguire carichi di lavoro con stato su Kubernetes' non ha esperienza sufficiente con Kubernetes e spesso nemmeno con il carico di lavoro specifico a cui si riferiscono.<\/p><\/blockquote>\n

Dunque, \u00e8 opportuno eseguire Kafka su Kubernetes? La domanda opposta \u00e8: funzionerebbe meglio Kafka senza Kubernetes? Ecco perch\u00e9 voglio sottolineare in questo articolo come Kafka e Kubernetes si completano a vicenda e quali insidie possono sorgere dalla loro combinazione.<\/p>\n

Tempo di esecuzione<\/h4>\n

\nParliamo di una cosa basilare: 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 questo non influisce sui broker.<\/p>\n

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

I broker Kafka consumano molta memoria. La dimensione della heap JVM di solito \u00e8 consigliata per essere limitata a 4-5 GB, ma avrai anche bisogno di molta memoria di sistema, poich\u00e9 Kafka utilizza intensamente la cache delle pagine. In Kubernetes, imposta di conseguenza i limiti delle risorse del contenitore e le richieste.<\/p>\n

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

L'archiviazione dei dati nei contenitori \u00e8 effimera: i dati vengono persi al riavvio. Per i dati di Kafka \u00e8 possibile utilizzare un volume emptyDir<\/code>, e l'effetto sar\u00e0 simile: i dati del tuo broker andranno persi al termine. I tuoi messaggi potrebbero comunque rimanere su altri broker come repliche. Quindi, dopo il riavvio, il broker guasto deve prima replicare tutti i dati, e questo processo potrebbe richiedere del tempo. <\/p>\n

Ecco perch\u00e9 \u00e8 importante utilizzare uno storage dati a lungo termine. Che sia uno storage non locale con un filesystem XFS o, pi\u00f9 precisamente, ext4. Non usare NFS. Ti avverto. NFS versioni v3 o v4 non funzioneranno. In breve, il broker Kafka si fermer\u00e0 se non pu\u00f2 eliminare la directory dei dati a causa di problemi di \u00abrinominazione stupida\u00bb, attuali in NFS. Se finora non ti ho convinto, fai 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 rilocazione.<\/p>\n

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

Come nella maggior parte dei sistemi distribuiti, le prestazioni di Kafka dipendono fortemente dal mantenimento di latenze di rete minime e da una larghezza di banda massima. Non cercate di posizionare tutti i broker nello stesso nodo, poich\u00e9 ci\u00f2 ridurrebbe la disponibilit\u00e0. Se un nodo Kubernetes fallisce, anche l'intero cluster Kafka andr\u00e0 in crash. Inoltre, non disperdete il cluster Kafka su diversi 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 manifesti. Poich\u00e9 ZooKeeper fa parte di Kafka, \u00e8 un buon punto di partenza per familiarizzare con quali concetti di Kubernetes sono applicabili qui. Una volta compreso questo, sarete in grado di applicare gli stessi concetti anche al cluster Kafka.<\/p>\n