5 leçons que j’ai apprises sur l’ingénierie du chaos pour Kubernetes

Kubernetes est un framework complexe pour un travail complexe. La gestion de plusieurs conteneurs peut être compliquée, et la gestion de centaines et de milliers d’entre eux n’est tout simplement pas humainement possible. Kubernetes fait des applications cloud hautement disponibles et hautement évolutives une réalité, et il fait généralement son travail remarquablement bien. Cependant, les gens n’ont pas tendance à remarquer les jours et les mois de succès. Des mois et des années de bon fonctionnement ne sont pas les choses qui se traduisent par des appels téléphoniques à 2 heures du matin. En informatique, ce sont les échecs qui comptent. Et malheureusement, les échecs ne s’exécutent pas selon un calendrier.

Le nouvel eBook de Jessica Cherry, Ingénierie du chaos pour Kubernetes, présente plusieurs concepts sur la façon dont les ingénieurs système peuvent aider à tester la robustesse des systèmes qu’ils ont conçus. Étonnamment, une grande partie de celui-ci est l’échec. Voici les cinq principales leçons que j’ai apprises du livre de Cherry.

L’échec intentionnel fait partie du succès

Peu importe que vous ayez tout fait correctement. Vous avez acheté du matériel sur mesure pour le travail, vous avez installé une distribution stable, acheté une assistance, lu les manuels de qualité, documenté votre processus, automatisé de récupération, effectué des sauvegardes, etc. Après tout le travail de préparation, il n’y a qu’une seule chose dont vous pouvez être sûr : quelque chose finira par mal tourner.

Ce n’est pas morbide de penser ainsi parce que c’est exactement ce qui se passe dans les systèmes technologiques et mécaniques. Les choses échouent.

Vous ne pouvez pas empêcher les choses d’échouer, mais vous pouvez Fabriquer ils échouent quand cela vous convient. Malheureusement, forcer une panne sur votre système n'”épuise” pas toutes vos pannes allouées pour l’année. Les choses échoueront toujours de manière inattendue, mais en provoquant des échecs selon votre propre calendrier, vous vous assurez que vous disposez des ressources et des connaissances dont vous avez besoin pour résoudre les problèmes.

L’échec aléatoire fait partie de la résilience

Vous n’êtes pas le seul à avoir besoin de savoir comment gérer l’échec. Votre infrastructure doit également être capable de résister aux pannes. Bien que vous puissiez tester certains de ces éléments avec des échecs planifiés, le caractère aléatoire contribue à garantir la résilience. Après tout, certains échecs se produiront lorsque vous n’êtes pas là pour vous assurer que tout le reste fonctionne toujours. Idéalement, vous voulez développer la tranquillité d’esprit que quelque chose pourrait se casser sans que vous le sachiez jamais (mais vous le saurez éventuellement parce que vous surveillez votre cluster. Vous surveillez votre cluster, n’est-ce pas ?).

La résilience doit se produire dans de nombreux endroits

Je n’oublierai jamais le premier serveur de fichiers partagé à grande échelle (200 utilisateurs étaient à grande échelle pour moi, alors). Il disposait d’un pool de stockage LVM avec beaucoup d’espace pour des disques durs supplémentaires, une batterie de secours, un back-end SAMBA robuste, une routine de sauvegarde basée sur AMANDA, un réseau de secours et un accès administrateur facile à la fois localement et à distance. Le serveur n’avait pas besoin d’une disponibilité constante, j’ai donc eu tout le temps de le tester pendant la semaine, mais il nécessitait une disponibilité à des moments précis de la journée de travail. Il a été bien utilisé, et j’en étais à juste titre fier pendant plusieurs mois.

Et puis, une semaine, mon serveur de fichiers a manqué d’espace sur le disque dur. Pas de problème, je l’avais construit pour avoir un stockage extensible, donc ce serait une simple question de marcher jusqu’au serveur, de glisser dans un nouveau lecteur et de continuer ma journée. À l’exception d’un petit problème : les disques durs n’étaient pas échangeables à chaud sur le matériel que j’avais acheté. (Qui savait qu’il y avait des serveurs rack sans baies de disques remplaçables à chaud ?) L’ensemble du système a dû être arrêté pour que je puisse y ajouter du stockage, et bien sûr, cela s’est produit un vendredi après-midi, lorsque le travail de tout le monde était rendu.

Leçon apprise : La résilience n’est pas un point fixe dans le temps. Vous ne concevez pas un système pour qu’il soit parfait à un moment précis ; vous le concevez pour qu’il puisse échouer à tout moment.

Il est difficile de détecter les points faibles de votre conception, à moins que vous ne provoquiez une défaillance à des moments et à des endroits inattendus.

Le chaos renforce l’ordre

J’avais l’habitude de penser que les tests rigoureux étaient un luxe. Je pensais que c’était quelque chose que les grandes équipes pouvaient se permettre de faire parce qu’elles avaient sûrement des personnes dédiées à l’assurance qualité assises dans des laboratoires pour bricoler et démonter des copies carbone de ce qui est en production.

Comme j’ai eu le privilège de travailler dans des équipes de plus en plus grandes, j’ai découvert que plus de personnes signifie seulement qu’il y a une plus grande potentiel pour que les tests se produisent. Il ne garantit jamais que les tests sont réellement effectués.

L’ingénierie du chaos est une pratique que tout le monde peut adopter. Parlez à votre service, formez une équipe, formez un plan. Configurez la surveillance, rendez votre fonctionnement de cluster transparent, invitez des questions et des défis. Obtenez un plan d’ingénierie du chaos formalisé, car le chaos met l’Ordre à rude épreuve et peut finalement le rendre plus fort.

Kubernetes peut être étonnamment amusant

Les gens me demandent parfois ce que je fais avec mon cluster Raspberry Pi Kubernetes. Certes, je n’exécute personnellement aucun service vital sur mon petit cloud hybride ouvert. Mais il s’avère qu’il y a beaucoup de plaisir à avoir avec un super-ordinateur miniature (enfin, c’est super pour moi, de toute façon.). Regarder de jolis tableaux de bord Grafana et jouer à Doom avec des pods sont tous deux amusants, mais la configuration l’est aussi, le défi de tester les performances de mon cluster après qu’un nœud a été soudainement supprimé du réseau, en essayant de voir combien de fois une carte SD peut survivre à un retrait incorrect (jusqu’à présent, grâce probablement à ext4), configurer deux conteneurs pour interagir les uns avec les autres, maîtriser les structures logiques des espaces de noms et des pods, etc.

En fin de compte, Kubernetes m’a donné mon propre cloud, et j’aime franchement avoir ce genre de pouvoir à portée de main.

L’ingénierie du chaos vous donne la permission d’être un peu dévergondé. Cela vous encourage à être méthodiquement imprudent. Et au final, vous obtenez un système plus résilient.

Téléchargez l’ebook

Bien sûr, vous ne pouvez pas simplement essayer de détruire sans but votre propre ordinateur et appeler cela de l’ingénierie du chaos. Sans discipline, documentation et atténuation, c’est juste le chaos. Pour vous assurer que vous cassez les choses de manière responsable et intelligente, téléchargez Ingénierie du chaos pour Kubernetes. Et puis laissez filer les singes du chaos !