Kubernetes est-il un verre à moitié vide ou à moitié plein ? Eh bien, cela dépend de la façon dont vous le regardez ! Les mécanismes de ses capacités d'orchestration sont plutôt complexes (à mon avis), et il n'est pas rare, même pour les praticiens les plus expérimentés, de se taper la tête contre le mur à cause de cela. En même temps, je l'ai souvent recommandé pour les utilisateurs novices et même pour les cas d'entreprise dans lesquels la capacité de dette technique est plus limitée - dans le but de travailler plus intelligemment, et non plus durement. J'occupe un deuxième emploi à temps partiel en tant qu'indépendant, en assurant la maintenance d'un système pour une petite organisation à but non lucratif. Lorsque je n'ai pas 8 heures par jour à consacrer au baby-sitting, plus je peux confier de tâches lourdes aux K8, mieux c'est pour nous tous. Mieux encore, si je travaille pour une grande entreprise où je suis payé 8 heures par jour pour faire du baby-sitting, je préfère encore tirer parti de la puissance de K8s pour faire le plus gros du travail à ma place. C'est la perspective du verre à moitié plein - considérer K8s comme un allié qui est là pour vous faciliter la vie. Déclarez ce que vous voulez et laissez-le faire ce qu'il fait le mieux.
Comme cette approche peut sembler trop simpliste, je soulignerai également notre tendance à rendre les choses trop complexes. Par exemple, lorsque nous sur-ingénierons une solution pour une "protection future" qui n'est même pas encore à l'horizon, ou lorsque nous réinventerons la roue au lieu d'utiliser des outils éprouvés qui ont déjà été conçus pour cette tâche. La plongée dans l'ingénierie des plateformes ne fait pas exception, mais nous y reviendrons dans un prochain article.
K8s est un organisme puissant et complexe, mais n'oubliez pas que beaucoup de nos pairs de l'industrie ont consacré des heures à en faire quelque chose qui " fonctionne ", et comme pour apprendre à conduire une voiture, la meilleure façon d'apprendre est pratique.
J'ai été initié à Kubernetes pour la première fois en 2019 - en première ligne de l'équipe de support client de Linode - lorsque nous avons lancé le Linode Kubernetes Engine (LKE). C'était un moment où il fallait couler ou nager que nous ne pouvions pas éviter parce que la demande des utilisateurs était tout simplement trop énorme. Nous devions soutenir ce produit, ce qui signifie que nous devions l'apprendre et, mieux encore, le dépanner ! Bien que parfois frustrantes, ces expériences ont été parmi les plus précieuses de ma carrière.
Dans cet article, nous allons explorer quelques stratégies d'apprentissage et de gestion de Kubernetes, basées sur des expériences réelles comme la mienne.
Apprendre par la pratique
La meilleure façon de comprendre véritablement la plateforme est de construire et de casser casser choses. Combiner la documentation et les tutoriels est un excellent moyen de mettre la main sur un cluster fonctionnel. Mettez vos manifestes dans un repo Git et vous aurez un modèle auquel vous pourrez vous référer à jamais. Ensuite, trouvez un moyen intéressant de le casser. Cela peut consister à laisser un ami ou un collègue s'en charger, de sorte que vous n'ayez aucune idée de la source du problème jusqu'à ce que vous commenciez à le diagnostiquer. Une autre méthode que j'ai utilisée consiste à faire quelque chose de plus complexe que ce qui est démontré dans le guide. Par exemple, supposons que vous suiviez le cours CKAD de la Fondation Linux. Il peut vous demander de construire un cluster simplifié avec un seul plan de contrôle et un nœud de travail. Au lieu de cela, essayez de démarrer avec succès un cluster avec trois nœuds de plan de contrôle pour la haute disponibilité et trois nœuds de travail. Si cela ne suffisait pas, essayez d'implémenter un VPC et de personnaliser l'adressage du réseau du cluster pour éviter les collisions dans l'espace IP. Même si vous vous sentez frustré et que vous jetez l'éponge au bout d'un certain temps, vous aurez appris beaucoup plus que vous ne l'auriez fait autrement. Il ne s'agit là que de deux exemples tirés de ma propre expérience. Il n'y a pas de limite.
De plus, des outils comme Minikube ou Kind peuvent être très utiles pour l'expérimentation locale avant de toucher à quoi que ce soit dans le nuage. Quelle que soit la façon dont vous vous y prenez pour casser, dépanner et réparer votre cluster, assurez-vous de laisser une trace de documentation. L'acte d'écrire sert votre mémoire, car il vous oblige à articuler les étapes et les solutions. Si vous avez le temps de rendre cette documentation publique, vous pourrez non seulement montrer votre excellente méthodologie de dépannage, mais aussi aider vos pairs.
Le dépannage en tant que parcours d'apprentissage
En ce qui concerne la méthodologie de dépannage, il n'y a pas de "meilleure pratique" en soi, il n'y a que "votre pratique", ce qui signifie que vous devez trouver la méthode qui vous convient le mieux, quelle qu'elle soit. Ce qui est important, c'est que vous ayez l'intention de développer ce muscle pour vous-même, et que cela devienne plus facile avec le temps. Les meilleurs dépanneurs que j'ai rencontrés sont devenus les meilleurs après des années passées à faire exactement cela et, par conséquent, je peux leur jeter n'importe quoi à la figure. Par conséquent, ils sont aussi ceux qui apprennent le plus facilement.
Voici quelques techniques qui me conviennent le mieux :
- Diviser pour mieux régner: couper le problème en deux et éliminer systématiquement les causes potentielles. Si, pour certains, il est plus facile d'escalader systématiquement la pile, je parviens généralement à passer directement à ce que je peux éliminer en premier. Cela va-t-il à l'encontre des conseils avisés des autres ? C'est possible ! Mais ce qui m'importe le plus, c'est ce qui fonctionne pour moi.
- LaMonitoring et l'observabilité sont vos amis, tout comme les erreurs: Les métriques, les journaux et les traces peuvent donner une vue holistique du système et, mieux encore, une vue holistique du problème ! Prometheus et Grafana sont les outils de facto pour la surveillance et sont de bon augure pour votre choix d'outils d'agrégation de logs et de traçage. Dans le monde réel, cependant, vous n'avez pas toujours la chance de disposer d'une pile d'observabilité complète - parfois, le mieux que vous puissiez obtenir est Prometheus et Grafana avec quelques cibles distantes à gratter. Heureusement, cela va encore très loin la plupart du temps, et avec ou sans, considérez les messages d'erreur comme votre ami ! Bien sûr, certains sont plus utiles que d'autres, mais il s'agit néanmoins d'un retour d'information du système qui indique que quelque chose n'a pas fonctionné.
- Recréer le problème : dans la mesure du possible, recréez le problème dans un environnement distinct. Cela peut fournir une mine d'informations sur la cause du problème, ce qui ouvre la voie à la recherche de la solution. Cela signifie également que vous disposez d'un environnement de test avec lequel vous pouvez expérimenter en toute sécurité. L'une des nombreuses raisons pour lesquelles il est bon de tirer parti de la puissance de l'infrastructure en tant que code (IaC) est la possibilité de recréer ou de détruire rapidement cet environnement en cas de besoin. Même s'il faut l'écrire soi-même, dans les situations où l'environnement n'a pas été codifié auparavant, passer un peu plus de temps sur ce point au départ peut faire gagner beaucoup de temps par la suite.
- Tenir un journal de dépannage: Vous êtes peut-être familier avec le concept d'un registre/journal des décisions en matière d'architecture. Qu'est-ce qui vous empêche d'appliquer un concept similaire au dépannage ? Rien du tout ! Et il n'y a pas besoin d'un formatage ou d'une convention particulière. Il vous suffit de consigner les étapes de votre dépannage au fur et à mesure que vous les effectuez. Cela peut s'avérer utile si vous avez besoin de revenir en arrière ou de réaffirmer les éléments que vous avez déjà écartés. Mieux encore, vous pourrez y revenir plus tard pour documenter la solution et expliquer comment vous y êtes parvenu. Le fait de pouvoir articuler les étapes et la logique qui les sous-tend permet de laisser des traces plus permanentes dans votre mémoire. Cela s'avérera également utile à toute personne qui lira votre documentation. Cette documentation peut être placée sur une plate-forme de base de connaissances interne, ou même sur un blog public destiné à la formation des autres.
Lorsque vous êtes confronté à des problèmes particulièrement difficiles, considérer le dépannage comme une opportunité d'apprentissage peut conduire à des améliorations à long terme des compétences en matière de résolution de problèmes et contribuer à améliorer la façon dont vous gérez votre infrastructure. Les équipes qui affinent et itèrent leurs processus de débogage se trouveront mieux équipées pour profiter de la puissance de Kubernetes.
Utiliser des techniques simples et fiables
L'écosystème "cloud native" (et le paysage "cloud" en général) offre une pléthore d'outils et de cadres à assembler. Les possibilités de construction sont presque infinies ! Cependant, cette notion peut souvent conduire à des écueils majeurs : trop d'outils, trop de complexité et trop de dette technique. Heureusement, il s'agit d'un piège facile à éviter avec un peu de discipline et un état d'esprit : moins, c'est plus. La meilleure technologie est celle qui est la plus facile à maintenir et la plus stable, et vous constaterez que vos utilisateurs sont d'accord avec vous. Si vous deviez monter sur une échelle pour accéder au toit d'une maison, vous ne voudriez pas qu'elle soit surdimensionnée au point de vous faire douter que vous l'utilisez correctement. Ce serait effrayant !
Il n'y a pas de fierté à maintenir une base de code si compliquée que personne ne peut la lire. Il n'y a pas de médaille d'or ou de trophée pour la construction d'un système si complexe que presque personne ne peut l'utiliser. Ce que nous voulons, ce sont des choses qui fonctionnent, qui sont stables et que nous pouvons utiliser correctement de manière fiable sans avoir à se donner plus de mal. La simplicité est votre amie dans ce domaine. N'oubliez pas non plus qu'un modèle de conception "cloud native" est un modèle qui accepte les changements rapides. L'architecture de votre application gagnera naturellement en complexité au fil du temps et de son évolution, il n'est donc pas nécessaire de lui forcer la main. En adoptant une approche minimaliste en plus d'une conception modulaire "cloud native", les équipes peuvent disposer de systèmes plus légers et plus sûrs, et rationaliser les déploiements, la maintenance et le dépannage.
En outre, la simplicité permet de réduire le risque de mauvaises configurations qui réduisent les performances et/ou augmentent la surface d'attaque pour les failles de sécurité.
Kubernetes lui-même est une abstraction. Nous ne pourrions pas l'appeler " cloud native " s'il ne l'était pas, mais le fait de limiter le nombre d'abstractions inutiles signifie que les ingénieurs passent moins de temps à gérer la complexité sous-jacente et plus de temps à se concentrer sur la création de valeur. Je m'en tiens ici à ma propre opinion, à contre-courant de l'approche "à volonté", car l'innovation la plus avancée que j'ai vue tout au long de ma carrière provient d'entreprises qui incarnent l'approche "régime strict" ; celles qui se sont concentrées sur la maîtrise des bases, afin de pouvoir construire en toute sécurité et de manière fiable des produits de pointe qui résolvent des problèmes très complexes.
Continuer à maîtriser Kubernetes
La combinaison d'une expérience pratique, d'une méthodologie de dépannage solide et d'une approche réfléchie de l'outillage peut rendre Kubernetes beaucoup plus facile à maîtriser. L'apprentissage par la pratique (plutôt que par la lecture) permet d'acquérir des compétences en matière de résolution de problèmes qui sont essentielles dans les opérations du monde réel. Le dépannage ne consiste pas seulement à réparer ce qui est cassé ; c'est l'occasion d'affiner votre compréhension, d'améliorer la documentation et de développer une approche systématique qui facilite la résolution des défis futurs. Et simplifier votre pile Kubernetes en minimisant les abstractions inutiles réduit les frais généraux cognitifs, ce qui facilite la gestion au fil du temps.
Comme l'ont appris de nombreux praticiens expérimentés, un cluster allégé et bien structuré est plus facile à maintenir et à faire évoluer qu'un cluster surchargé d'outils qui ajoutent de la complexité sans apporter d'avantages clairs. En fin de compte, pour réussir avec Kubernetes, il ne s'agit pas d'utiliser tous les nouveaux outils disponibles sur le marché, mais de savoir lesquels apportent une réelle valeur ajoutée à long terme.
Si vous souhaitez en savoir plus sur Kubernetes, j'en parle plus en détail dans le podcast KubeFM, que vous pouvez regarder sur YouTube ou ci-dessous.
Commentaires