{"id":36706,"date":"2019-10-31T22:13:15","date_gmt":"2019-10-31T19:13:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs\/"},"modified":"2019-10-31T22:13:15","modified_gmt":"2019-10-31T19:13:15","slug":"kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-prioritety-podov-v-kubernetes-stali-prichinoj-prostoya-v-grafana-labs","title":{"rendered":"Comment les priorit\u00e9s des pods dans Kubernetes ont caus\u00e9 une interruption chez Grafana Labs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Note de traduction.<\/b>: Nous vous pr\u00e9sentons des d\u00e9tails techniques sur les raisons de la r\u00e9cente interruption du service cloud, g\u00e9r\u00e9 par les cr\u00e9ateurs de Grafana. C'est un exemple classique de la fa\u00e7on dont une nouvelle fonctionnalit\u00e9, apparemment tr\u00e8s utile, con\u00e7ue pour am\u00e9liorer la qualit\u00e9 de l'infrastructure\u2026 peut causer des dommages si les nombreux aspects de son utilisation en production ne sont pas pris en compte. Il est remarquable d'avoir des mat\u00e9riaux comme celui-ci, qui permettent d'apprendre non seulement de ses propres erreurs. Les d\u00e9tails sont dans la traduction de ce texte du vice-pr\u00e9sident produit de Grafana Labs.<\/i><\/p>\n

\"Comment
\n
\nLe vendredi 19 juillet, le service Hosted Prometheus dans Grafana Cloud a cess\u00e9 de fonctionner pendant environ 30 minutes. Je pr\u00e9sente mes excuses \u00e0 tous les clients qui ont souffert de cette panne. Notre objectif est de fournir les outils n\u00e9cessaires \u00e0 la surveillance, et nous comprenons que leur indisponibilit\u00e9 complique votre vie. Nous prenons cet incident tr\u00e8s au s\u00e9rieux. Dans cette note, nous expliquons ce qui s'est pass\u00e9, comment nous avons r\u00e9agi et ce que nous faisons pour \u00e9viter que cela ne se reproduise.<\/a><\/noindex><\/p>\n

Contexte<\/h2>\n

\nLe service Grafana Cloud Hosted Prometheus est bas\u00e9 sur Cortex<\/a><\/noindex> \u2014 un projet CNCF visant \u00e0 cr\u00e9er un service Prometheus \u00e9volutif horizontalement, hautement disponible et multi-tenant. L'architecture Cortex se compose d'un ensemble de microservices distincts, chacun remplissant sa propre fonction : r\u00e9plication, stockage, requ\u00eates, etc. Cortex est en d\u00e9veloppement actif, avec constamment de nouvelles fonctionnalit\u00e9s et une performance am\u00e9lior\u00e9e. Nous d\u00e9ployons r\u00e9guli\u00e8rement de nouvelles versions de Cortex dans les clusters afin que nos clients puissent b\u00e9n\u00e9ficier de ces fonctionnalit\u00e9s - heureusement, Cortex peut \u00eatre mis \u00e0 jour sans temps d'arr\u00eat.<\/p>\n

Pour les mises \u00e0 jour sans interruption, le service Ingester de Cortex n\u00e9cessite une r\u00e9plication suppl\u00e9mentaire d'Ingester pendant le processus de mise \u00e0 jour. (Note de traduction.<\/b>: Ingester<\/a><\/noindex> \u2014 le composant de base de Cortex. Sa t\u00e2che est de rassembler un flux constant d'\u00e9chantillons, de les regrouper en chunks pour Prometheus et de les stocker dans une base de donn\u00e9es comme DynamoDB, BigTable ou Cassandra.<\/i> Cela permet aux anciens Ingester de transmettre les donn\u00e9es actuelles aux nouveaux Ingester. Il convient de noter que les Ingester sont exigeants en ressources. Pour leur fonctionnement, il est n\u00e9cessaire d'avoir 4 c\u0153urs et 15 Go de m\u00e9moire par pod, c'est-\u00e0-dire 25 % de la puissance CPU et de la m\u00e9moire de la machine de base dans nos clusters Kubernetes. En g\u00e9n\u00e9ral, nous avons g\u00e9n\u00e9ralement beaucoup plus de ressources inutilis\u00e9es dans le cluster que 4 c\u0153urs et 15 Go de m\u00e9moire, donc nous pouvons facilement lancer ces Ingester suppl\u00e9mentaires pendant les mises \u00e0 jour.<\/p>\n

Cependant, il arrive souvent qu'aucune des machines n'ait ces 25 % de ressources non utilis\u00e9es pendant le fonctionnement normal. Et nous ne cherchons pas \u00e0 en avoir : le CPU et la m\u00e9moire seront toujours utiles pour d'autres processus. Pour r\u00e9soudre ce probl\u00e8me, nous avons d\u00e9cid\u00e9 de tirer parti de Kubernetes Pod Priorities<\/a><\/noindex>L'id\u00e9e est d'attribuer aux Ingester une priorit\u00e9 plus \u00e9lev\u00e9e que celle des autres microservices (sans \u00e9tat). Lorsque nous devons lancer un Ingester suppl\u00e9mentaire (N+1), nous relocalisons temporairement d'autres pods plus petits. Ces pods sont d\u00e9plac\u00e9s vers des ressources libres sur d'autres machines, laissant une \"large place\" pour le lancement d'un Ingester suppl\u00e9mentaire.<\/p>\n

Le jeudi 18 juillet, nous avons d\u00e9ploy\u00e9 quatre nouveaux niveaux de priorit\u00e9 dans nos clusters : critique<\/b>, un<\/b>, moyenne<\/b> et basse<\/b>Ils ont \u00e9t\u00e9 test\u00e9s sur un cluster interne sans trafic client pendant environ une semaine. Par d\u00e9faut, les pods sans priorit\u00e9 d\u00e9finie recevaient moyenne<\/b> une priorit\u00e9, pour les Ingester une classe a \u00e9t\u00e9 \u00e9tablie avec haute<\/b> priorit\u00e9 a \u00e9t\u00e9 attribu\u00e9e aux Ingester. Critique<\/b> \u00e9tait r\u00e9serv\u00e9 \u00e0 la surveillance (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). Notre config est ouverte et le PR peut \u00eatre consult\u00e9 ici<\/a><\/noindex>.<\/p>\n

Incident<\/h2>\n

\nLe vendredi 19 juillet, un des ing\u00e9nieurs a lanc\u00e9 un nouveau cluster d\u00e9di\u00e9 Cortex pour un grand client. La configuration de ce cluster n'incluait pas de nouvelles priorit\u00e9s pour les pods, donc tous les nouveaux pods recevaient la priorit\u00e9 par d\u00e9faut \u2014 moyenne<\/b>.<\/p>\n

Le cluster Kubernetes n'avait pas assez de ressources pour le nouveau cluster Cortex, et le cluster de production existant Cortex n'avait pas \u00e9t\u00e9 mis \u00e0 jour (les Ingester sont rest\u00e9s sans haute<\/b> priorit\u00e9). Comme les Ingester du nouveau cluster avaient par d\u00e9faut moyenne<\/b> la priorit\u00e9, et que les pods existants en production fonctionnaient sans priorit\u00e9, les Ingester du nouveau cluster ont remplac\u00e9 les Ingester du cluster de production existant de Cortex.<\/p>\n

Le ReplicaSet pour l'Ingester d\u00e9log\u00e9 dans le cluster de production a d\u00e9tect\u00e9 le pod d\u00e9log\u00e9 et en a cr\u00e9\u00e9 un nouveau pour maintenir le nombre sp\u00e9cifi\u00e9 de copies. Le nouveau pod a \u00e9t\u00e9 attribu\u00e9 par d\u00e9faut moyenne<\/b> une priorit\u00e9, et un autre Ingester \"ancien\" dans la production a perdu des ressources. Le r\u00e9sultat a \u00e9t\u00e9 un processus en cascade<\/b>, ce qui a entra\u00een\u00e9 le remplacement de tous les pods d'Ingester dans les clusters de production de Cortex.<\/p>\n

Les Ingester conservent l'\u00e9tat (stateful) et stockent les donn\u00e9es des 12 derni\u00e8res heures. Cela nous permet de les compresser plus efficacement avant de les \u00e9crire dans le stockage \u00e0 long terme. Pour ce faire, Cortex effectue un sharding des donn\u00e9es par s\u00e9ries, utilisant une table de hachage distribu\u00e9e (Distributed Hash Table, DHT), et r\u00e9plique chaque s\u00e9rie sur trois Ingester avec une coh\u00e9rence de quorum de style Dynamo. Cortex n'\u00e9crit pas de donn\u00e9es sur des Ingester qui sont hors ligne. Ainsi, lorsque de nombreux Ingester quittent la DHT, Cortex ne peut pas assurer une r\u00e9plication suffisante des enregistrements, et ces derniers \u00ab tombent \u00bb.<\/p>\n

D\u00e9tection et r\u00e9solution<\/h2>\n

\nLes nouvelles alertes Prometheus bas\u00e9es sur le \"budget d'erreurs\" (error-budget-based<\/i> \u2014 des d\u00e9tails appara\u00eetront dans un futur article) ont commenc\u00e9 \u00e0 tirer la sonnette d'alarme quatre minutes apr\u00e8s le d\u00e9but de la d\u00e9connexion. Au cours des cinq minutes suivantes, nous avons diagnostiqu\u00e9 et amplifi\u00e9 le cluster Kubernetes sous-jacent pour h\u00e9berger \u00e0 la fois les nouveaux et les anciens clusters de production.<\/p>\n

Cinq minutes plus tard, les anciens Ingester ont r\u00e9ussi \u00e0 \u00e9crire leurs donn\u00e9es, tandis que les nouveaux ont \u00e9t\u00e9 lanc\u00e9s, et les clusters Cortex sont redevenus accessibles.<\/p>\n

Dix minutes suppl\u00e9mentaires ont \u00e9t\u00e9 n\u00e9cessaires pour diagnostiquer et corriger des erreurs de type out-of-memory (OOM) des serveurs proxy inverses d'authentification situ\u00e9s devant Cortex. Les erreurs OOM \u00e9taient caus\u00e9es par une augmentation d\u00e9courag\u00e9e du QPS (consid\u00e9rant que c'\u00e9tait d\u00fb \u00e0 des requ\u00eates excessivement agressives venant des serveurs Prometheus du client).<\/p>\n

Cons\u00e9quences<\/h2>\n

\nLa dur\u00e9e totale de l'arr\u00eat a \u00e9t\u00e9 de 26 minutes. Les donn\u00e9es n'ont pas \u00e9t\u00e9 perdues. Les Ingester ont r\u00e9ussi \u00e0 charger toutes les donn\u00e9es en m\u00e9moire dans le stockage \u00e0 long terme. Pendant l'arr\u00eat, les serveurs Prometheus des clients ont mis en m\u00e9moire tampon les donn\u00e9es supprim\u00e9es. (remote)<\/i> enregistrements via la nouvelle API remote_write<\/a><\/noindex> bas\u00e9e sur le WAL (cr\u00e9\u00e9e par Callum Styan<\/a><\/noindex> de Grafana Labs) et ont r\u00e9it\u00e9r\u00e9 les enregistrements \u00e9chou\u00e9s apr\u00e8s la panne.<\/p>\n

\"Comment
\nLes op\u00e9rations d'\u00e9criture du cluster de production<\/i><\/p>\n

Conclusions<\/h2>\n

\nIl est important de tirer des le\u00e7ons de cet incident et de prendre les mesures n\u00e9cessaires pour \u00e9viter sa r\u00e9currence.<\/p>\n

En repensant \u00e0 cela, il convient de reconna\u00eetre que nous n'aurions pas d\u00fb d\u00e9finir par d\u00e9faut moyenne<\/b> priorit\u00e9, jusqu'\u00e0 ce que tous les Ingester en production aient re\u00e7u un<\/b> en priorit\u00e9. De plus, il aurait fallu pr\u00e9voir \u00e0 l'avance leur haute<\/b> priorit\u00e9. Maintenant, tout est corrig\u00e9. Nous esp\u00e9rons que notre exp\u00e9rience aidera d'autres organisations envisageant d'utiliser des priorit\u00e9s de pods dans Kubernetes.<\/p>\n

Nous ajouterons un niveau de contr\u00f4le suppl\u00e9mentaire sur le d\u00e9ploiement de tout objet suppl\u00e9mentaire dont la configuration est globale au cluster. \u00c0 l'avenir, de tels changements seront \u00e9valu\u00e9s parde<\/i>un plus grand nombre de personnes. En outre, la modification qui a conduit \u00e0 l'\u00e9chec \u00e9tait jug\u00e9e trop insignifiante pour un document de projet distinct \u2014 elle n'a \u00e9t\u00e9 discut\u00e9e que dans un probl\u00e8me GitHub. Dor\u00e9navant, tous les changements de configuration similaires seront accompagn\u00e9s d'une documentation de projet appropri\u00e9e.<\/p>\n

Enfin, nous automatiserons le redimensionnement du serveur proxy inverse d'authentification pour \u00e9viter les OOM lors de la surcharge, que nous avons v\u00e9cue, et analyserons les param\u00e8tres par d\u00e9faut de Prometheus li\u00e9s au rollback et au scaling, afin d'\u00e9viter \u00e0 l'avenir des probl\u00e8mes similaires.<\/p>\n

L'\u00e9chec que nous avons rencontr\u00e9 a \u00e9galement eu des cons\u00e9quences positives : ayant \u00e0 disposition les ressources n\u00e9cessaires, Cortex s'est automatiquement r\u00e9tabli sans intervention suppl\u00e9mentaire. Nous avons \u00e9galement acquis une exp\u00e9rience pr\u00e9cieuse avec Grafana Loki<\/a><\/noindex> \u2014 notre nouveau syst\u00e8me d'agr\u00e9gation des journaux, \u2014 qui a aid\u00e9 \u00e0 s'assurer que tous les Ingester se comportaient correctement pendant et apr\u00e8s la panne.<\/p>\n

P.S. de l'auteur<\/h2>\n

\nLisez aussi dans notre blog :<\/p>\n