Kubernetes : d'Airbnb à Skyscanner, ils reviennent sur leurs échecs

Indisponibilités, surconsommation de ressources, malwares... Au-delà des success stories, Kubernetes, c'est aussi des échecs, parfois suivis de témoignages. Début 2019, Henning Jacobs, ingénieur chez Zalando, avait entrepris d'en compiler.

I started a compilation of #Kubernetes #Failure Stories - the list is still short, please help! Thanks to @obeattie and @adman65 for their public postmortems https://t.co/WcgQ1wTSlv

- Henning Jacobs (@try_except_) January 19, 2019

La liste comprend aujourd'hui une soixantaine de liens vers des contenus datés d'entre 2017 et 2021. Le dernier ajouté émane de Skyscanner. Sujet : « Comment quelques caractères ont planté notre site ». Il y est question de l'application accidentelle d'un changement destructeur dans le système de provisionnement d'infrastructure. Deux lignes dans lesquelles manquaient les caractères {{ }}. Il en a résulté la corruption des namespaces... et la suppression, par ArgoCD, des 478 microservices qui portaient le site et l'app mobile. Conséquence : quatre heures de panne, le 25 août 2021.

Dans la liste, on trouve aussi un post-mortem signé Buffer. Il s'intitule « Kubernetes : rendez vos services plus rapides en supprimant les limites CPU ». On nous y conte l'histoire d'un bug dans le noyau Linux qui plafonnait les ressources accessibles aux conteneurs alors même qu'ils étaient loin d'atteindre les plafonds de consommation fixés. Et, surtout, les mesures prises pour assurer la résilience lorsqu'on a finalement décidé de supprimer ces plafonds.

Réseau, maillage de services et malwares

Dans la catégorie « problèmes réseau », il y a MindTickle. Et son post « L'affaire du paquet manquant : l'histoire d'une migration EKS ». En toile de fond, un projet de migration de cluster de kops vers le Kubernetes managé d'AWS. Et les obstacles rencontrés pour la communication entre ledit cluster et les ressources externes (microservices sur des VM EC2 derrière un répartiteur de charge).

Du côté d'Exponea, on revient sur les difficultés à mettre en place un maillage de services (« Comment nous avons échoué à intégrer Istio dans notre plate-forme »). Face au manque d'options sur la version managée de Google, l'entreprise avait choisi de le déployer elle-même sur GKE. Elle a dû résoudre des problèmes qui tenaient notamment aux noms des ports et à l'exécution des sidecars.

L'équipe de JW Player a quant à elle eu affaire à un malware (« Comment un cryptomineur s'est infiltré dans nos clusters Kubernetes ») qui a touché son environnement de développement. Il lui a fallu plusieurs semaines pour détecter la souche, qui usurpait le nom d'un composant légitime de l'orchestrateur.

Photo d'illustration © Pressmaster - Shutterstock