Kafka su Kubernetes è buono?

Saluti, Habr!

Un tempo siamo stati i primi a introdurre l'argomento nel mercato russo Kafka e continuare seguire per il suo sviluppo. In particolare, abbiamo trovato il tema dell'interazione tra Kafka e kubernetes. Osservabile (e abbastanza attento) articolo questo argomento è stato pubblicato sul blog Confluent nell'ottobre dello scorso anno sotto la paternità di Gwen Shapira. Oggi vorremmo attirare la vostra attenzione su un articolo più recente di aprile di Johann Gyger, che, pur non senza un punto interrogativo nel titolo, esamina l'argomento in modo più sostanziale, accompagnando il testo con link interessanti. Per favore perdonaci la traduzione gratuita di “scimmia del caos” se puoi!

Introduzione

Kubernetes è progettato per gestire carichi di lavoro stateless. In genere, tali carichi di lavoro sono presentati sotto forma di un'architettura di microservizi, sono leggeri, si adattano bene in senso orizzontale, seguono i principi delle applicazioni a 12 fattori e possono funzionare con interruttori automatici e scimmie del caos.

Kafka, invece, agisce essenzialmente come un database distribuito. Pertanto, quando lavori, devi occuparti dello stato ed è molto più pesante di un microservizio. Kubernetes supporta i carichi con stato, ma come sottolinea Kelsey Hightower in due tweet, dovrebbero essere gestiti con cura:

Alcune persone ritengono che se si inserisce Kubernetes in un carico di lavoro con stato, diventa un database completamente gestito che rivaleggia con RDS. Questo è sbagliato. Forse, se lavori abbastanza duramente, aggiungi componenti aggiuntivi e attiri un team di ingegneri SRE, sarai in grado di creare RDS su Kubernetes.

Consiglio sempre a tutti di prestare la massima attenzione durante l'esecuzione di carichi di lavoro con stato su Kubernetes. La maggior parte delle persone che chiedono "posso eseguire carichi di lavoro con stato su Kubernetes" non hanno abbastanza esperienza con Kubernetes e spesso con il carico di lavoro di cui chiedono.

Quindi, dovresti eseguire Kafka su Kubernetes? Controdomanda: Kafka funzionerà meglio senza Kubernetes? Ecco perché voglio evidenziare in questo articolo come Kafka e Kubernetes si completano a vicenda e quali insidie ​​possono derivare dalla loro combinazione.

Tempo di completamento

Parliamo della cosa fondamentale: l'ambiente di runtime stesso

Процесс

I broker Kafka sono compatibili con la CPU. TLS potrebbe introdurre un sovraccarico. Tuttavia, i client Kafka potrebbero richiedere un utilizzo più intensivo della CPU se utilizzano la crittografia, ma ciò non influisce sui broker.

Память

I broker Kafka divorano la memoria. La dimensione dell'heap JVM è solitamente limitata a 4-5 GB, ma avrai bisogno anche di molta memoria di sistema poiché Kafka utilizza molto la cache delle pagine. In Kubernetes, imposta le risorse del contenitore e i limiti delle richieste di conseguenza.

Archivio dati

L'archiviazione dei dati nei contenitori è effimera: i dati vengono persi al riavvio. Per i dati Kafka puoi utilizzare un volume emptyDire l'effetto sarà simile: i dati del tuo broker andranno persi dopo il completamento. I tuoi messaggi possono comunque essere archiviati su altri broker come repliche. Pertanto, dopo il riavvio, il broker non riuscito deve prima replicare tutti i dati e questo processo può richiedere molto tempo.

Questo è il motivo per cui dovresti utilizzare l’archiviazione dei dati a lungo termine. Lascia che si tratti di archiviazione a lungo termine non locale con il file system XFS o, più precisamente, ext4. Non utilizzare NFS. Ti ho avvertito. Le versioni NFS v3 o v4 non funzioneranno. In breve, il broker Kafka andrà in crash se non riesce a eliminare la directory dei dati a causa del problema della "stupida ridenominazione" in NFS. Se non ti ho ancora convinto, con molta attenzione leggi questo articolo. L'archivio dati dovrebbe essere non locale in modo che Kubernetes possa scegliere in modo più flessibile un nuovo nodo dopo un riavvio o un riposizionamento.

Rete

Come con la maggior parte dei sistemi distribuiti, le prestazioni di Kafka dipendono fortemente dal mantenimento della latenza di rete al minimo e della larghezza di banda al massimo. Non provare a ospitare tutti i broker sullo stesso nodo, poiché ciò ridurrà la disponibilità. Se un nodo Kubernetes fallisce, l'intero cluster Kafka fallirà. Inoltre, non disperdere il cluster Kafka in interi data center. Lo stesso vale per il cluster Kubernetes. Un buon compromesso in questo caso è scegliere zone di disponibilità diverse.

Configurazione

Manifesti regolari

Il sito Web Kubernetes ha ottima guida su come configurare ZooKeeper utilizzando i manifest. Poiché ZooKeeper fa parte di Kafka, questo è un buon punto di partenza per acquisire familiarità con i concetti di Kubernetes applicabili qui. Una volta compreso questo, puoi utilizzare gli stessi concetti con un cluster Kafka.

• sotto: Un pod è la più piccola unità distribuibile in Kubernetes. Un pod contiene il tuo carico di lavoro e il pod stesso corrisponde a un processo nel tuo cluster. Un pod contiene uno o più contenitori. Ciascun server ZooKeeper nell'insieme e ciascun broker nel cluster Kafka verrà eseguito in un pod separato.
• StatefulSet: uno StatefulSet è un oggetto Kubernetes che gestisce più carichi di lavoro con stato e tali carichi di lavoro richiedono coordinamento. Gli StatefulSet forniscono garanzie relative all'ordinamento dei pod e alla loro unicità.
• Servizi senza testa: i servizi ti consentono di scollegare i pod dai client utilizzando un nome logico. Kubernetes in questo caso è responsabile del bilanciamento del carico. Tuttavia, quando si utilizzano carichi di lavoro con stato, come ZooKeeper e Kafka, i client devono comunicare con un'istanza specifica. È qui che tornano utili i servizi headless: in questo caso il client avrà ancora un nome logico, ma non dovrai contattare direttamente il pod.
• Volume di archiviazione a lungo termine: questi volumi sono necessari per configurare l'archiviazione persistente a blocchi non locale menzionata sopra.

Su Yolean Fornisce un set completo di manifest per aiutarti a iniziare a utilizzare Kafka su Kubernetes.

Grafici del timone

Helm è un gestore di pacchetti per Kubernetes che può essere paragonato ai gestori di pacchetti del sistema operativo come yum, apt, Homebrew o Chocolatey. Semplifica l'installazione dei pacchetti software predefiniti descritti nei grafici Helm. Un grafico Helm ben scelto semplifica il difficile compito di configurare correttamente tutti i parametri per utilizzare Kafka su Kubernetes. Esistono diversi diagrammi di Kafka: si trova quello ufficiale in condizioni di incubatrice, ce n'è uno da ConFluent™, un altro - da Bitnami.

Operatori

Poiché Helm presenta alcuni difetti, un altro strumento sta guadagnando notevole popolarità: gli operatori Kubernetes. L'operatore non solo confeziona software per Kubernetes, ma consente anche di distribuire tale software e gestirlo.

l'elenco operatori straordinari Vengono menzionati due operatori per Kafka. Uno di loro - Strimzi. Con Strimzi, è facile rendere operativo il tuo cluster Kafka in pochi minuti. Praticamente non è richiesta alcuna configurazione, inoltre l'operatore stesso fornisce alcune funzionalità interessanti, ad esempio la crittografia TLS punto a punto all'interno del cluster. Confluent fornisce anche proprio operatore.

Производительность

È importante testare le prestazioni confrontando la tua istanza Kafka. Tali test ti aiuteranno a trovare potenziali colli di bottiglia prima che sorgano problemi. Fortunatamente, Kafka fornisce già due strumenti di test delle prestazioni: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Fatene un uso attivo. Per riferimento, è possibile fare riferimento ai risultati descritti in questo post Jay Kreps, o concentrati su questa recensione Amazon MSK di Stéphane Maarek.

operazioni

Monitoraggio

La trasparenza nel sistema è molto importante, altrimenti non capirai cosa sta succedendo al suo interno. Oggi esiste un solido toolkit che fornisce monitoraggio basato su metriche in stile cloud nativo. Due strumenti popolari per questo scopo sono Prometeo e Grafana. Prometheus può raccogliere parametri da tutti i processi Java (Kafka, Zookeeper, Kafka Connect) utilizzando un esportatore JMX, nel modo più semplice. Se aggiungi le metriche di cAdvisor, puoi comprendere più a fondo come vengono utilizzate le risorse in Kubernetes.

Strimzi ha un esempio molto conveniente di dashboard Grafana per Kafka. Visualizza le metriche chiave, ad esempio, sui settori sottoreplicati o su quelli offline. Lì è tutto molto chiaro. Questi parametri sono integrati da informazioni sull’utilizzo delle risorse e sulle prestazioni, nonché indicatori di stabilità. Quindi ottieni il monitoraggio di base del cluster Kafka gratuitamente!

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

Sarebbe bello integrare tutto questo con il monitoraggio dei clienti (metriche su consumatori e produttori), nonché il monitoraggio della latenza (per questo esiste Tana) e monitoraggio end-to-end - per questo uso Monitor Kafka.

Registrazione

La registrazione è un altro compito fondamentale. Assicurati che tutti i contenitori nell'installazione di Kafka siano collegati stdout и stderre assicurati inoltre che il tuo cluster Kubernetes aggreghi tutti i log in un'infrastruttura di registrazione centrale, ad es. elasticsearch.

Controllo funzionale

Kubernetes utilizza sonde di attività e disponibilità per verificare se i tuoi pod funzionano normalmente. Se il controllo di attività fallisce, Kubernetes arresterà il contenitore e lo riavvierà automaticamente se la policy di riavvio è impostata di conseguenza. Se il controllo di idoneità fallisce, Kubernetes isola il pod dalle richieste di manutenzione. Pertanto, in questi casi, l’intervento manuale non è più necessario, il che è un grande vantaggio.

Aggiornamenti in distribuzione

Gli StatefulSet supportano gli aggiornamenti automatici: se selezioni la strategia RollingUpdate, ciascuno sotto Kafka verrà aggiornato a turno. In questo modo i tempi di inattività possono essere ridotti a zero.

scalata

Scalare un cluster Kafka non è un compito facile. Tuttavia, Kubernetes semplifica il ridimensionamento dei pod fino a un certo numero di repliche, il che significa che puoi definire in modo dichiarativo tutti i broker Kafka che desideri. La cosa più difficile in questo caso è riassegnare i settori dopo l’aumento o prima del ridimensionamento. Ancora una volta, Kubernetes ti aiuterà in questo compito.

amministrazione

Le attività relative all'amministrazione del tuo cluster Kafka, come la creazione di argomenti e la riassegnazione dei settori, possono essere eseguite utilizzando gli script di shell esistenti aprendo l'interfaccia della riga di comando nei tuoi pod. Questa soluzione però non è molto bella. Strimzi supporta la gestione degli argomenti utilizzando un operatore diverso. C'è qualche margine di miglioramento qui.

Backup e ripristino

Ora la disponibilità di Kafka dipenderà anche dalla disponibilità di Kubernetes. Se il tuo cluster Kubernetes fallisce, nel peggiore dei casi anche il tuo cluster Kafka fallirà. Secondo la legge di Murphy, ciò accadrà sicuramente e perderai i dati. Per ridurre questo tipo di rischio, avere un buon concetto di backup. Puoi usare MirrorMaker, un'altra opzione è usare S3 per questo, come descritto in questo posta di Zalando.

conclusione

Quando si lavora con cluster Kafka di piccole e medie dimensioni, vale sicuramente la pena utilizzare Kubernetes poiché fornisce ulteriore flessibilità e semplifica l'esperienza dell'operatore. Se si hanno requisiti di latenza e/o velocità effettiva non funzionali molto significativi, potrebbe essere meglio prendere in considerazione qualche altra opzione di distribuzione.

Fonte: habr.com