{"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\/fr\/blog\/administrirovanie\/kafka-na-kubernetes-eto-horosho","title":{"rendered":"Kafka sur Kubernetes \u2014 est-ce une bonne chose ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bienvenue, Habr !<\/p>\n

Nous avons \u00e9t\u00e9 les premiers \u00e0 introduire le th\u00e8me sur le march\u00e9 russe Kafka<\/a><\/noindex> et nous continuons \u00e0 surveiller<\/a><\/noindex> son d\u00e9veloppement. En particulier, nous avons trouv\u00e9 int\u00e9ressant le sujet de l'interaction entre Kafka et Kubernetes<\/a><\/noindex>. Un article g\u00e9n\u00e9ral (et plut\u00f4t prudent) article<\/a><\/noindex> sur ce sujet a \u00e9t\u00e9 publi\u00e9 sur le blog de la soci\u00e9t\u00e9 Confluent en octobre dernier, \u00e9crit par Gwen Shapira. Aujourd'hui, nous souhaitons attirer votre attention sur un article plus r\u00e9cent, d'avril, de Johann Gyger, qui, bien qu'il ait pos\u00e9 une question dans le titre, traite le sujet de mani\u00e8re plus concr\u00e8te, accompagnant le texte de liens int\u00e9ressants. Pardonnez-nous cette traduction libre de \u00ab chaos monkey \u00bb, si vous le pouvez !<\/p>\n

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

Introduction<\/h4>\n

\nKubernetes est destin\u00e9 \u00e0 fonctionner avec des charges de travail sans \u00e9tat. En g\u00e9n\u00e9ral, ces charges de travail se pr\u00e9sentent sous forme d'architecture \u00e0 microservices, elles sont l\u00e9g\u00e8res, se pr\u00eatent bien \u00e0 la scalabilit\u00e9 horizontale, ob\u00e9issent aux principes des applications en 12 facteurs, permettent de travailler avec des disjoncteurs (circuit breakers) et des chaos monkeys.<\/p>\n

Kafka, de l'autre c\u00f4t\u00e9, agit essentiellement comme une base de donn\u00e9es distribu\u00e9e. Ainsi, lors de son utilisation, vous devez g\u00e9rer l'\u00e9tat, qui est beaucoup plus lourd qu'un microservice. Kubernetes prend en charge les charges de travail avec \u00e9tat, mais, comme l'indique Kelsey Hightower dans ses deux tweets, il faut les manipuler avec pr\u00e9caution :<\/p>\n

Certains pensent que si l'on d\u00e9ploie Kubernetes sur une charge de travail avec \u00e9tat, cela devient une base de donn\u00e9es compl\u00e8tement g\u00e9r\u00e9e, capable de rivaliser avec RDS. Ce n'est pas le cas. Peut-\u00eatre qu'avec suffisamment d'efforts, en ajoutant des composants suppl\u00e9mentaires et en engageant une \u00e9quipe d'ing\u00e9nieurs SRE, il serait possible de construire une RDS sur Kubernetes.<\/p><\/blockquote>\n

Je recommande toujours d'exercer une extr\u00eame prudence lors du d\u00e9ploiement de charges de travail avec \u00e9tat sur Kubernetes. La plupart de ceux qui se demandent si \u00ab je peux ex\u00e9cuter des charges de travail avec \u00e9tat sur Kubernetes \u00bb n'ont pas suffisamment d'exp\u00e9rience avec Kubernetes et souvent pas avec la charge de travail en question.<\/p><\/blockquote>\n

Alors, faut-il lancer Kafka sur Kubernetes ? Une question inverse est : Kafka fonctionnera-t-il mieux sans Kubernetes ? C'est pourquoi je veux souligner dans cet article comment Kafka et Kubernetes se compl\u00e8tent, et quels pi\u00e8ges peuvent se pr\u00e9senter lors de leur combinaison.<\/p>\n

Temps d'ex\u00e9cution<\/h4>\n

\nParlons d'une chose fondamentale : l'environnement d'ex\u00e9cution tel quel.<\/p>\n

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

Les courtiers Kafka sont pratiques pour travailler avec le CPU. TLS peut introduire certains co\u00fbts. Cela dit, les clients Kafka peuvent solliciter davantage le CPU s'ils utilisent le chiffrement, mais cela n'affecte pas les courtiers.<\/p>\n

M\u00e9moire<\/b><\/i><\/p>\n

Les courtiers Kafka consomment de la m\u00e9moire. La taille de la m\u00e9moire heap JVM est g\u00e9n\u00e9ralement limit\u00e9e \u00e0 4-5 Go, mais vous aurez \u00e9galement besoin de beaucoup de m\u00e9moire syst\u00e8me, car Kafka utilise activement le cache de pages. Dans Kubernetes, d\u00e9finissez correctement les limites des conteneurs sur les ressources et les demandes.<\/p>\n

Stockage de donn\u00e9es<\/b><\/i><\/p>\n

Le stockage de donn\u00e9es dans des conteneurs est \u00e9ph\u00e9m\u00e8re \u2013 les donn\u00e9es sont perdues lors du red\u00e9marrage. Pour les donn\u00e9es de Kafka, vous pouvez utiliser un volume, et l'effet sera similaire : les donn\u00e9es de votre courtier seront perdues apr\u00e8s l'arr\u00eat. Vos messages peuvent quand m\u00eame \u00eatre conserv\u00e9s sur d'autres courtiers en tant que r\u00e9pliques. Donc, apr\u00e8s le red\u00e9marrage, le courtier en panne doit d'abord r\u00e9pliquer toutes les donn\u00e9es, et ce processus peut prendre un certain temps. emptyDir<\/code>C'est pourquoi il est recommand\u00e9 d'utiliser un stockage de donn\u00e9es persistant. Qu'il s'agisse d'un stockage persistant non local avec un syst\u00e8me de fichiers XFS ou, plus pr\u00e9cis\u00e9ment, ext4. N'utilisez pas NFS. Je vous pr\u00e9viens. NFS versions v3 ou v4 ne fonctionneront pas. En r\u00e9sum\u00e9, le courtier Kafka s'arr\u00eatera s'il ne peut pas supprimer le r\u00e9pertoire contenant les donn\u00e9es en raison d'un probl\u00e8me de 'renommages stupides', probl\u00e9matique sous NFS. Si je ne vous ai pas encore convaincu, lisez tr\u00e8s attentivement <\/p>\n

cet article. Le stockage de donn\u00e9es doit \u00eatre non local, afin que Kubernetes puisse choisir plus efficacement un nouveau n\u0153ud apr\u00e8s un red\u00e9marrage ou une relocalisation.<\/a><\/noindex>.<\/p>\n

R\u00e9seau<\/b><\/i><\/p>\n

Comme pour la plupart des syst\u00e8mes distribu\u00e9s, la performance de Kafka d\u00e9pend fortement du fait que les latences r\u00e9seau soient minimales et la bande passante maximale. N'essayez pas de placer tous les courtiers sur le m\u00eame n\u0153ud, car cela r\u00e9duira la disponibilit\u00e9. Si un n\u0153ud Kubernetes \u00e9choue, l'ensemble du cluster Kafka \u00e9chouera \u00e9galement. \u00c9vitez \u00e9galement de r\u00e9partir le cluster Kafka sur plusieurs centres de donn\u00e9es. Il en va de m\u00eame pour le cluster Kubernetes. Un bon compromis dans ce cas est de choisir diff\u00e9rentes zones de disponibilit\u00e9.<\/p>\n

Configuration<\/h4>\n

\nManifestes standard<\/b><\/i><\/p>\n

Le site de Kubernetes dispose d'un tr\u00e8s bon guide<\/a><\/noindex> sur la configuration de ZooKeeper \u00e0 l'aide de manifestes. \u00c9tant donn\u00e9 que ZooKeeper fait partie de Kafka, c'est un bon point de d\u00e9part pour se familiariser avec les concepts de Kubernetes qui s'appliquent ici. Une fois que vous les aurez compris, vous pourrez utiliser les m\u00eames concepts avec le cluster Kafka.<\/p>\n