Kafka sur Kubernetes est-il bon ?

Salutations, Habr!

À une époque, nous étions les premiers à introduire ce sujet sur le marché russe. Kafka et continue suivre pour son développement. En particulier, nous avons trouvé le thème de l'interaction entre Kafka et Kubernetes. Observable (et assez prudent) article ce sujet a été publié sur le blog Confluent en octobre de l'année dernière sous la paternité de Gwen Shapira. Aujourd'hui, nous souhaitons attirer votre attention sur un article plus récent d'avril de Johann Gyger, qui, bien que non sans un point d'interrogation dans le titre, examine le sujet de manière plus substantielle, en accompagnant le texte de liens intéressants. Veuillez nous pardonner la traduction gratuite de « singe du chaos » si vous le pouvez !

introduction

Kubernetes est conçu pour gérer les charges de travail sans état. En règle générale, ces charges de travail se présentent sous la forme d'une architecture de microservices, elles sont légères, s'adaptent bien horizontalement, suivent les principes des applications à 12 facteurs et peuvent fonctionner avec des disjoncteurs et des singes du chaos.

Kafka, quant à lui, agit essentiellement comme une base de données distribuée. Ainsi, lorsqu’on travaille, il faut composer avec l’état, et c’est bien plus lourd qu’un microservice. Kubernetes prend en charge les chargements avec état, mais comme le souligne Kelsey Hightower dans deux tweets, ils doivent être traités avec précaution :

Certaines personnes pensent que si vous intégrez Kubernetes dans une charge de travail avec état, celle-ci devient une base de données entièrement gérée qui rivalise avec RDS. C'est faux. Peut-être que si vous travaillez assez dur, ajoutez des composants supplémentaires et attirez une équipe d'ingénieurs SRE, vous pourrez créer RDS sur Kubernetes.

Je recommande toujours à chacun de faire preuve d'une extrême prudence lors de l'exécution de charges de travail avec état sur Kubernetes. La plupart des personnes qui demandent « puis-je exécuter des charges de travail avec état sur Kubernetes » n'ont pas suffisamment d'expérience avec Kubernetes, et souvent avec la charge de travail qu'elles demandent.

Alors, devriez-vous exécuter Kafka sur Kubernetes ? Contre-question : Kafka fonctionnera-t-il mieux sans Kubernetes ? C'est pourquoi je souhaite souligner dans cet article comment Kafka et Kubernetes se complètent et quels pièges peuvent survenir en les combinant.

Heure d'achèvement

Parlons de l'essentiel : l'environnement d'exécution lui-même

Processus

Les courtiers Kafka sont compatibles avec le processeur. TLS peut introduire une certaine surcharge. Cependant, les clients Kafka peuvent être plus gourmands en CPU s'ils utilisent le chiffrement, mais cela n'affecte pas les courtiers.

Mémoire

Les courtiers Kafka consomment de la mémoire. La taille du tas JVM est généralement limitée à 4 à 5 Go, mais vous aurez également besoin de beaucoup de mémoire système car Kafka utilise très fortement le cache de pages. Dans Kubernetes, définissez les ressources du conteneur et les limites de requêtes en conséquence.

Entrepôt de données

Le stockage des données dans des conteneurs est éphémère : les données sont perdues au redémarrage. Pour les données Kafka, vous pouvez utiliser un volume emptyDir, et l'effet sera similaire : vos données de courtier seront perdues une fois l'opération terminée. Vos messages peuvent toujours être stockés sur d'autres courtiers en tant que répliques. Par conséquent, après un redémarrage, le courtier défaillant doit d'abord répliquer toutes les données, et ce processus peut prendre beaucoup de temps.

C'est pourquoi vous devez utiliser le stockage de données à long terme. Qu'il s'agisse d'un stockage à long terme non local avec le système de fichiers XFS ou, plus précisément, ext4. N'utilisez pas NFS. Je t'avais prévenu. Les versions NFS v3 ou v4 ne fonctionneront pas. En bref, le courtier Kafka plantera s'il ne parvient pas à supprimer le répertoire de données en raison du problème de « renommage stupide » dans NFS. Si je ne vous ai pas encore convaincu, faites très attention lire cet article. Le magasin de données ne doit pas être local afin que Kubernetes puisse choisir un nouveau nœud de manière plus flexible après un redémarrage ou une relocalisation.

Réseau

Comme pour la plupart des systèmes distribués, les performances de Kafka dépendent fortement du maintien de la latence du réseau au minimum et de la bande passante au maximum. N'essayez pas d'héberger tous les courtiers sur le même nœud, car cela réduirait la disponibilité. Si un nœud Kubernetes échoue, l'ensemble du cluster Kafka échouera. De plus, ne dispersez pas le cluster Kafka sur des centres de données entiers. Il en va de même pour le cluster Kubernetes. Un bon compromis dans ce cas est de choisir différentes zones de disponibilité.

Configuration

Manifestes réguliers

Le site Web Kubernetes a très bon guide sur la façon de configurer ZooKeeper à l'aide de manifestes. Puisque ZooKeeper fait partie de Kafka, c'est un bon point de départ pour commencer à se familiariser avec les concepts Kubernetes qui s'appliquent ici. Une fois que vous avez compris cela, vous pouvez utiliser les mêmes concepts avec un cluster Kafka.

• sous: Un pod est la plus petite unité déployable dans Kubernetes. Un pod contient votre charge de travail et le pod lui-même correspond à un processus de votre cluster. Un pod contient un ou plusieurs conteneurs. Chaque serveur ZooKeeper de l'ensemble et chaque courtier du cluster Kafka s'exécuteront dans un pod distinct.
• Ensemble avec état: Un StatefulSet est un objet Kubernetes qui gère plusieurs charges de travail avec état, et ces charges de travail nécessitent une coordination. Les StatefulSets offrent des garanties concernant l'ordre des pods et leur unicité.
• Services sans tête: Les services vous permettent de détacher des pods des clients à l'aide d'un nom logique. Kubernetes est dans ce cas responsable de l’équilibrage de charge. Cependant, lors de l'exécution de charges de travail avec état, telles que ZooKeeper et Kafka, les clients doivent communiquer avec une instance spécifique. C’est là que les services headless s’avèrent utiles : dans ce cas, le client aura toujours un nom logique, mais vous n’aurez pas à contacter directement le pod.
• Volume de stockage à long terme: Ces volumes sont nécessaires pour configurer le stockage persistant en bloc non local mentionné ci-dessus.

Sur Yoléenne Fournit un ensemble complet de manifestes pour vous aider à démarrer avec Kafka sur Kubernetes.

Cartes de barre

Helm est un gestionnaire de packages pour Kubernetes qui peut être comparé aux gestionnaires de packages de système d'exploitation tels que yum, apt, Homebrew ou Chocolatey. Il facilite l'installation de progiciels prédéfinis décrits dans les chartes Helm. Un graphique Helm bien choisi facilite la tâche difficile de configurer correctement tous les paramètres pour utiliser Kafka sur Kubernetes. Il existe plusieurs diagrammes Kafka : le diagramme officiel se trouve en condition d'incubateur, il y en a un de ConFluent™, un de plus - de Bitnami.

opérateurs

Parce que Helm présente certaines lacunes, un autre outil gagne en popularité : les opérateurs Kubernetes. L'opérateur propose non seulement des logiciels pour Kubernetes, mais vous permet également de déployer de tels logiciels et de les gérer.

la liste opérateurs incroyables Deux opérateurs pour Kafka sont mentionnés. L'un d'eux - Strimzi. Avec Strimzi, il est facile de rendre votre cluster Kafka opérationnel en quelques minutes. Pratiquement aucune configuration n'est requise, de plus, l'opérateur lui-même fournit des fonctionnalités intéressantes, par exemple le cryptage TLS point à point au sein du cluster. Confluent fournit également propre opérateur.

Performance

Il est important de tester les performances en comparant votre instance Kafka. De tels tests vous aideront à détecter les goulots d’étranglement potentiels avant que les problèmes ne surviennent. Heureusement, Kafka propose déjà deux outils de test de performances : kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Utilisez-les activement. Pour référence, vous pouvez vous référer aux résultats décrits dans ce post Jay Kreps, ou concentrez-vous sur cette revue Amazon MSK par Stéphane Maarek.

opérations

Surveillance

La transparence du système est très importante, sinon vous ne comprendrez pas ce qui s'y passe. Il existe aujourd’hui une boîte à outils solide qui fournit une surveillance basée sur des métriques dans le style cloud natif. Deux outils populaires à cet effet sont Prometheus et Grafana. Prometheus peut collecter des métriques de tous les processus Java (Kafka, Zookeeper, Kafka Connect) à l'aide d'un exportateur JMX - de la manière la plus simple. Si vous ajoutez des métriques cAdvisor, vous pouvez mieux comprendre comment les ressources sont utilisées dans Kubernetes.

Strimzi propose un exemple très pratique de tableau de bord Grafana pour Kafka. Il visualise des indicateurs clés, par exemple sur les secteurs sous-répliqués ou ceux qui sont hors ligne. Tout y est très clair. Ces mesures sont complétées par des informations sur l'utilisation des ressources et les performances, ainsi que des indicateurs de stabilité. Vous bénéficiez donc d’une surveillance de base du cluster Kafka pour rien !

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

Ce serait bien de compléter tout cela par un suivi client (métriques sur les consommateurs et les producteurs), ainsi qu'un suivi de la latence (pour cela il y a Terrier) et surveillance de bout en bout - pour cette utilisation Moniteur Kafka.

Enregistrement

La journalisation est une autre tâche critique. Assurez-vous que tous les conteneurs de votre installation Kafka sont connectés stdout и stderr, et assurez-vous également que votre cluster Kubernetes regroupe tous les journaux dans une infrastructure de journalisation centrale, par ex. ElasticSearch.

Bilan de santé

Kubernetes utilise des sondes d'activité et de préparation pour vérifier si vos pods fonctionnent normalement. Si la vérification de l'activité échoue, Kubernetes arrêtera ce conteneur, puis le redémarrera automatiquement si la stratégie de redémarrage est définie en conséquence. Si la vérification de l'état de préparation échoue, Kubernetes isole le pod des demandes de service. Ainsi, dans de tels cas, aucune intervention manuelle n’est plus nécessaire, ce qui est un gros plus.

Déploiement des mises à jour

Les StatefulSets prennent en charge les mises à jour automatiques : si vous sélectionnez la stratégie RollingUpdate, chacun sous Kafka sera mis à jour à son tour. De cette façon, les temps d’arrêt peuvent être réduits à zéro.

Mise à l'échelle

Faire évoluer un cluster Kafka n’est pas une tâche facile. Cependant, Kubernetes permet de faire évoluer très facilement les pods vers un certain nombre de réplicas, ce qui signifie que vous pouvez définir de manière déclarative autant de courtiers Kafka que vous le souhaitez. Le plus difficile dans ce cas est de réaffecter les secteurs après l’augmentation ou avant la réduction. Encore une fois, Kubernetes vous aidera dans cette tâche.

administration

Les tâches liées à l'administration de votre cluster Kafka, telles que la création de sujets et la réaffectation de secteurs, peuvent être effectuées à l'aide de scripts shell existants en ouvrant l'interface de ligne de commande dans vos pods. Cependant, cette solution n’est pas très belle. Strimzi prend en charge la gestion des sujets à l'aide d'un opérateur différent. Il y a ici matière à amélioration.

Sauvegarde et récupération

Désormais, la disponibilité de Kafka dépendra également de la disponibilité de Kubernetes. Si votre cluster Kubernetes échoue, dans le pire des cas, votre cluster Kafka échouera également. Selon la loi de Murphy, cela se produira certainement et vous perdrez des données. Pour réduire ce type de risque, ayez un bon concept de sauvegarde. Vous pouvez utiliser MirrorMaker, une autre option consiste à utiliser S3 pour cela, comme décrit dans ce poster de Zalando.

Conclusion

Lorsque vous travaillez avec des clusters Kafka de petite ou moyenne taille, il vaut vraiment la peine d'utiliser Kubernetes car il offre une flexibilité supplémentaire et simplifie l'expérience de l'opérateur. Si vous avez des exigences de latence et/ou de débit non fonctionnelles très importantes, il peut être préférable d'envisager une autre option de déploiement.

Source: habr.com