Des leçons et des leçons réussies

Kubernetes a changé la façon dont les organisations gèrent leur charge de travail. Au cours des deux dernières années, Kubernetes est devenu l’une des principales plates-formes de développement d’applications. De nombreuses organisations à travers le monde utilisent la fonctionnalité Kubernetes dans leur charge de travail. Cependant, comme tout le reste, Kubernetes a ses inconvénients. Dans le cas de Kubernetes, cet inconvénient est sa complexité. Oui, les K8 permettent aux organisations de former plus facilement des clusters et des conteneurs individuels, mais avec un nombre croissant de configurations, le risque de défauts et de dommages est plus élevé. Et grâce à la complexité de Kubernetes, localiser ces échecs peut être comme trouver l’aiguille proverbiale dans une botte de foin. Les corriger, cependant, est un jeu différent.

1. Évitez les limites inutiles du processeur

Buffer utilise Kubernetes depuis 2016, mais en 2020, ils en ont rencontré un question étrange conduisant à une latence plus élevée. Habituellement, lorsque vous essayez d’identifier la source de tels problèmes, le dénominateur commun est des configurations terribles. À leur grande surprise, cependant, Buffer a constaté que le problème était dû aux limites du processeur. Il est conseillé aux organisations d’utiliser la limite du processeur (définie à 100 ms par défaut) pour s’assurer que leurs ressources de processeur ne sont pas épuisées par certains conteneurs. Sans limites de processeur, certains conteneurs peuvent manquer de ressources de processeur, ce qui entraîne l’exécution du processus Kubelet sur chaque nœud sans réponse et le changement de l’état des nœuds en “NotReady” et la planification des pods ailleurs dans le cluster, provoquant une défaillance complète du cluster.

Le principe de l’utilisation des limites du processeur semble utile en théorie. Cependant, lorsque Buffer a essayé de définir des limites de processeur sur ses conteneurs, le délai est devenu un problème. Après avoir essayé pendant un certain temps d’enquêter, Buffer s’est rendu compte que le processeur était étranglé pour les conteneurs utilisant des processeurs qui n’étaient même pas proches de la limite du processeur. Après quelques recherches, Buffer a découvert que cela était dû à une erreur dans le noyau Linux. Buffer a pu résoudre ce problème en abaissant la limite d’utilisation maximale du processeur au niveau le plus bas possible et en garantissant Balance automatique horizontale utilisé au cas où l’utilisation des ressources dépassait la limite définie. L’erreur du noyau Linux a depuis été résolue.

Leçon

Cet échec des K8 est dû à une erreur au sein du noyau Linux qui aurait pu passer inaperçue pendant longtemps. Ce qui est utile dans ces situations, c’est une bonne visibilité de vos charges de travail et aussi la nécessité de rester informé sur Kubernetes en participant activement aux forums K8.

2. L’augmentation de la latence n’est pas toujours une erreur de Kubernetes

Lorsque l’opérateur de site publicitaire européen Adevinta a tenté de déplacer l’un de ses microcosmes Kubernetes d’Amazon EC2, ils ont remarqué que la latence était devenue 10 fois ce que c’était dans EC2. Cela est particulièrement vrai pour une organisation qui ne fait que commencer son voyage vers Kubernetes. Pour découvrir ce qui a causé ce retard soudain, Adevinta a essayé de collecter les mesures nécessaires à partir du chemin de requête et s’est rendu compte qu’il s’agissait du problème de latence ascendante, il était d’environ 200 ms. Des recherches plus poussées ont révélé que le délai d’expiration par défaut des informations d’identification fournies par KIAM était d’environ 15 minutes et que le kit AWS Java SDK a tendance à renouveler les informations d’identification lorsque leur délai d’expiration est inférieur à 15 minutes. Ce problème a ensuite été résolu en demandant des informations d’identification KIAM avec une date d’expiration plus longue, ce qui a entraîné une latence beaucoup plus faible, même meilleure que EC2.

Leçon

La transition vers un nouveau système peut être difficile à bien des égards. Parfois, ce que nous faisons dans un système peut ne pas se traduire bien dans un autre. Dans ce cas, il n’y avait aucun moyen de prédire qu’un problème surviendrait en raison d’une incompatibilité dans les configurations par défaut. Par conséquent, les développeurs doivent comprendre correctement les configurations et savoir ce que fait chaque paramètre par défaut à un moment donné. Dans ce cas, le problème n’était pas en soi un échec de Kubernetes, mais montre simplement que vous ne pouvez pas mettre à niveau et modifier une application telle qu’elle est dans les K8.

3. Examinez vos configurations de charge de travail

Jetstack voulait mettre à niveau son maître de cluster lorsqu’il en rencontrait un thème ce qui a causé l’échec de l’ensemble du complexe. La mise à niveau était destinée à ne pas avoir de temps d’arrêt de l’API. Cependant, une fois que le pipeline de mise à niveau était en cours d’exécution, le processus de mise à niveau n’était pas terminé avant l’expiration du délai Terraform (défini sur 20 minutes). Une fois le pipeline mis à niveau redémarré, la mise à niveau a rencontré une erreur car l’état du nœud principal n’était pas sain. Cela était dû à un webhook d’introduction qui n’a pas répondu après la mise à niveau vers la première apparence principale. Cela a conduit à une boucle de crash, car Kubelet ne pouvait pas signaler la santé des nœuds et ce problème a déclenché une réaction en chaîne alors que la réparation automatique de GKE continuait à créer de nouveaux nœuds pour corriger l’erreur. Le problème a ensuite été résolu en recherchant et en supprimant le webhook non réactif et en configurant un nouveau webhook d’introduction pour OPA (Open Policy Agent) pour surveiller uniquement les noms de domaine spécifiques qui répondent à la politique. Un détecteur d’animation a également été créé pour surveiller en permanence le webhook d’entrée et le redémarrer lorsqu’il ne répond pas.

Leçon

Dans ce cas, l’échec de Kubernetes aurait pu être évité si Jetstack avait surveillé les temps de réponse de l’API depuis le développement d’OPA. Le temps de réponse plus lent pour les commandes «create» et «update» aurait alerté les développeurs Jetstack avant qu’ils ne rencontrent l’erreur lors de la mise à niveau du maître. L’utilisation d’un graphique Helm après avoir développé OPA aurait également aidé. Avec un diagramme Helm, le Jetstack pourrait avoir les configurations requises, y compris un détecteur de vitalité, pour aider à empêcher tout le cluster de tomber en panne. La clé pour éviter les problèmes de configuration est de vous assurer que vous avez exploré toutes les configurations et de vous assurer qu’il n’y a pas de changement de latence en raison de certains paramètres pouvant entraîner des problèmes plus importants à l’avenir.

4. L’interruption DNS peut couler tout le navire

Les sites Web des magasins de mode Zalando ont soudainement commencé à fonctionner les erreurs comme l’un des services ultérieurs au niveau de la concentration a commencé à se terminer. Cela a conduit à une augmentation des demandes car les clients ont tenté de résoudre les problèmes à la fin. Cette augmentation a conduit à une augmentation des requêtes DNS dans l’infrastructure CoreDNS. La gestion de toutes ces demandes nécessite plus de mémoire que les pods CoreDNS. Les pods ont alors manqué de mémoire et ont continué à tuer le MOO, ce qui a conduit à une panne DNS complète. La panne DNS a également amené le service agressif à ouvrir des disjoncteurs dans les services ultérieurs car il ne pouvait pas résoudre la mise en cache DNS des noms d’hôtes. Le résultat de cette panne a été que les systèmes de surveillance internes sont devenus inutiles car ils ont dû interagir avec des systèmes externes pour fournir des alertes en utilisant des mesures pertinentes.
Échecs de Kubernetes
Il a fallu plus de temps que d’habitude pour contacter un développeur Kubernetes pour configurer manuellement la limite de mémoire de 100 mi à 2000 mi. Une fois que cela a été fait, les pods CoreDNS ont cessé de tuer OOM et tout est revenu à la normale.

Leçon

L’infrastructure DNS peut se planter d’elle-même si elle n’est pas configurée correctement. Pour le rendre plus durable, les développeurs doivent s’assurer qu’un délai d’attente DNS ne conduit pas à un effet domino. Une autre leçon importante que nous avons tirée de ce cas d’utilisation est que la surveillance doit être efficace et puissante. En raison de l’interruption totale du DNS, le système de surveillance et de notification interne a été complètement arrêté. Cela a considérablement retardé la récupération car le problème n’a pas été signalé assez tôt.

Il y a généralement des raisons – et des solutions – aux échecs de Kubernetes

Kubernetes est compliqué. Parfois, les échecs de Kubernetes peuvent être dus à un défaut inhérent à l’écosystème K8. Et, parfois, cela peut être dû à de mauvais paramètres et à un manque de surveillance appropriée. Tous ces éléments peuvent entraîner des pannes difficiles à détecter et peuvent également entraîner de longues pauses sans précédent. La communauté K8 est énorme et les développeurs peuvent toujours utiliser ces forums pour trouver des solutions aux problèmes qu’ils rencontrent soit à travers des problèmes existants et des correctifs, soit en contactant des experts en cas de besoin.

Image en vedette: Shutterstock / TechGenix Photo Image


Affichage des messages:
12


Ézoïquementionner cette annonce

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *