Derrière ce titre, je dois l’avouer un peu pute à clic, j’ai envie de faire un vrai bilan sur ce que je retiens de cette technologie au travers de ces dernières années.

Une découverte dans la douleur

On va commencer quelques années en arrière, plus précisément en 2017.

À cette époque, j’étais un jeune étudiant en alternance qui découvrait l’étendue sans fin de nos métiers. Surement proche de la caricature de l’administrateur système GNU/Linux barbu, un peu réfractaire au changement, j’étais souvent prompt à partager les derniers mêmes sur l’open source et le logiciel libre.

Avec le recul, je pense que comme beaucoup à cette époque j’étais assez ignorant sur la réalité et le seul sommet que j’avais atteint était probablement celui de la montagne de la stupidité.

Je travaillais pour un infogéreur plutôt orienté DevOps. Je faisais beaucoup d’AWS, j’avais encore du mal avec le principe d’immutabilité notamment.

J’ai découvert Kubernetes un jour d’astreinte. J’en avais entendu parler à la machine à café et en lisant 2-3 articles, bref je savais ce que c’était dans l’idée. J’ai donc reçu ma première alerte Kubernetes : “Crash loop backoff” autant dire que ça change des classiques “HTTP timeout” ou “Disk space”. Sauf que même si cette alerte ne me parlait pas et que je ne connaissais pas la technologie, il fallait la traiter.

Autant dire que la documentation interne était, comme trop souvent, incomplète. Le monitoring était tout sauf adapté. Bref j’étais perdu, mes réflexes de se connecter sur la machine m’étaient ici inutiles. J’ai fini par escalader, la personne ayant installé le cluster régla l’erreur à coup de quelques kubectl. J’avoue que ces explications m’avaient perdu.

C’est à ce moment que j’ai réellement détesté Kubernetes.

Beaucoup de choses que je connaissais semblaient inutiles et j’étais impuissant. Kubernetes représentait un mélange de complexité, de magie et de frustration. Je savais que j’aurais pu me former dessus, mais à ce moment je me disais que la priorité n’était pas là et je me penchais sur AWS notamment.

La vie sans Kubernetes

J’ai donc continué mon chemin et évitant Kubernetes comme on évite de passer sous une échelle, plus par superstition et peur que par raison.

Cela dit, cela ne signifie pas que je n’ai pas avancé. Concentré sur mes outils du moment, je me suis penché sur l’infrastructure moderne. J’ai compris l’intérêt de plusieurs modèles d’infrastructure, l’immutabilité, j’ai commencé à maîtriser l’IaC.

À ce moment, les infrastructures que je réalisais étaient propres, même pour les standards actuels. Là-dessus je découvre plusieurs principes que j’adore :

• Je ne manipule plus des instances, mais des groupes d’instances qui définissent ce que je souhaite comme état et AWS se charge du reste.
• Tout passe par l’API cloud, tout passe en IAC avec Terraform dans lequel je décris l’état souhaité. Le tout est réparti sur plusieurs AZs ou datacenter en fonction du provider.
• Le nombre de machines n’étant pas fixe, le monitoring devient dynamique, les logs centralisés.
• Pour déployer les applications, un rollout des instances suffit, les Health-check du load balancer s’occupent du reste.
• Tout se met à l’échelle automatiquement.
• Les droits sont attachés à mes instances, elles peuvent les utiliser pour taper l’API du fournisseur, plus de token à gérer.
• Les images d’instances sont construites avec Packer automatiquement toutes les nuits (et déployées dans la foulée).
• En cas d’erreur l’application est redémarrée, si besoin les logs pourront être analysés au calme.

À ce moment, je me dis qu’on est réellement sur le top de l’infrastructure. C’est flexible, agréable à utiliser, qui nécessite très peu de run et pour une personne qui a fait de l’admin sys et de l’astreinte classique, ben c’est un bonheur.

Kubernetes vs moi round 2

Avec le temps, et ma vie de consultant, je me suis de nouveau retrouvé confronté à Kubernetes, mais cette fois-ci je m’y étais mieux préparé et j’avais creusé un peu. En bref, je savais interagir et mieux comprendre ce qu’il me disait.

J’arrive sur le projet, je suis seul, je dois reprendre l’infrastructure qui tourne déjà sur Kubernetes. Mais ça ne se passe pas comme prévu…

J’ai beau savoir faire les actions de base, l’administration de Kubernetes me semble un puits sans fond. Des heures, qui me semblent perdues à debug et essayer d’intégrer des applications. Je n’aime pas Kubernetes et visiblement celui-ci ne m’apprécie pas vraiment plus.

Quelques semaines plus tard, l’équipe se renforce et un nouveau SRE arrive, il est habitué à Kubernetes. J’ai une chance, en plus de bien connaître la technologie, il est très pédagogue même si la barrière de la langue n’aide pas.

Avec son aide je comprends pas mal de choses et le déclic se fait, Kubernetes n’est pas plus complexe que les autres infrastructures sur lesquelles je travaillais. Mais j’ai essayé, et visiblement les personnes qui avaient mis en place ce cluster dont j’ai hérité de faire des patterns à l’ancienne plutôt que de s’adapter à ceux de Kubernetes.

Quelques exemples d’erreur de compréhension: lancer un script qui va lancer des php doctrines avant de lancer l’application plutôt qu’utiliser un init container, avec de la CI/CD qui fait des patchs de manifestes, des applications sans health-check, des crons exécutent directement des commandes dans les pods à coup de kubectl exec.

Alors oui, avec le recul, ça paraît évident. Je me suis même demandé comment j’avais pu louper ça. Mais au-delà de Kubernetes, j’ai vu trois points qui m’ont bloqué :

J’avais uniquement connu des installations faites à l’arrache qui étaient plus proches du POC qu’autre chose.

• Je n’avais pas d’exemple propre ou avec la bonne démarche.
• J’ai uniquement découvert la technologie dans le rush, je n’ai jamais pris le temps de me former.
• J’avais gardé de mauvais aprioris sur la technologie.

Ces points là, hors de Kubernetes, restent pour moi des erreurs dont j’ai retenu la leçon.

Donc j’apprends, je découvre, des concepts et des outils. Le GitOps avec FluxCD qui simplifie pas mal de points sur la CD. J’apprends à faire des déploiements efficaces et fiables. Je ne suis pas expert, mais j’ai plus cette impression horrible de me battre contre une technologie, mais de la comprendre.

Je finis ma mission en me disant que la prochaine fois ça ne sera plus un combat.

Comprendre et itérer

Je continue d’approfondir de surtout discuter avec des personnes de comment ils font du Kubernetes, les retours sont super intéressants. Je remarque aussi que certains trolls sur les réseaux sociaux, notamment sur la fameuse landscape CNCF, m’avaient empêché de comprendre l’intérêt de tout ça. Ce n’est pas la liste des outils à connaître et encore moins à installer, mais une liste de projets sérieux dans lequel piocher en cas de besoin.

Puis arrive pour moi la fin de ma vie de consultant à plein temps. Je retourne à mes premiers amours, gérer des infrastructures du build au run pour des sites web en tant que SRE. Petit détail, pas des moindres, ce changement de travail c’est aussi pour moi l’occasion de redécouvrir et surtout de travailler avec une très large majorité de Cloud Français.

Rapidement je me rends compte que réaliser des infrastructures modernes est possible, mais demande un effort bien plus colossal que sur un AWS. Bref, il faut réinventer la roue.

Je réalise assez rapidement que ce qu’il me manque toutes ces fonctionnalités qui me simplifiait la vie sur les infrastructures, Kubernetes peut me les offrir. Du coup, on part sur Kubernetes. Je n’avais jamais fait d’installation non managée, je découvre pas mal de choses, je me rends compte que même à l’installation l’architecture n’est pas si compliquée, les briques sont bien définies, leurs rôles clairs.

Je commence à m’amuser à intégrer des opérateurs, notamment pour le monitoring. Je découvre la réelle puissance de Kubernetes et contrairement à ce que beaucoup m’ont vendu ce n’est pas le scaling.

La vraie puissance de Kubernetes c’est de vous offrir une plateforme standard, avec une API extensible permettant de faire le pont entre dev et ops tout en répondant à toutes les problématiques d’architectures modernes.

Dans notre métier ça permet réellement de travailler avec les développeurs par la même API, de partager un langage, mine de rien c’est une grande aide.

Malgré ça je reste réaliste, même si je connais bien mieux Kubernetes, je bosse encore sur pas mal d’éléments passionnants, mais qui apportent leurs lots de nouvelles connaissances. Comme les CNI (Cilium), mais aussi la gestion et l’optimisation du stockage, le monitoring avancé et plein d’autres choses.

Morales de l’histoire

Je suis une personne plutôt pragmatique, Kubernetes n’est pas parfait et ne le sera sûrement jamais. Un jour il sera sûrement remplacé par une autre technologie qui aura son lot de “hater” et de fan. Se battre pour des guerres de clocher n’a je pense pas ou peu d’intérêt.

Je continue de penser que Kubernetes, malgré toutes ces qualités, n’est pas applicable partout, notamment pour des raisons organisationnelles et humaines.

C’est une technologie qui vous force à penser à faire les choses d’une certaine manière, elle structure votre architecture et une partie de votre manière de travailler. Elle va forcer des bonnes pratiques, au prix d’une mise en place souvent plus coûteuse.

Kubernetes n’est pas compliqué, mais elle demande de comprendre beaucoup d’éléments techniques et de principes généraux. C’est important de bien comprendre ces points-là, même si vous ne faites pas de Kubernetes.

J’ai envie aussi de vous partager ce qu’humainement je retiens.

Il faut savoir prendre le temps d’apprendre et surtout de se connaître, je sais que j’ai besoin de temps pour apprendre, d’expérimenter. Quand c’est nécessaire, il faut savoir le faire.

Prenez le temps de partager vos connaissances, c’est cool de connaître quelque chose, la partager c’est encore mieux.

Soyez ouvert, ne soyez pas le moi cliché de ma vie étudiante, vous ne savez pas tout et tout le monde a quelque chose à apprendre. Aussi, mal utilisé, toutes les technologies peuvent être mauvaises.

Quand vous découvrez une technologie ou une méthodologie, essayez d’avoir des expériences qui sortent de votre cercle d’échange avec des gens d’horizon différents.

Pour conclure cette morale, Kubernetes est sûrement un des standards les plus intéressants aujourd’hui. Même si vous ne l’utilisez pas, je vous invite à découvrir et comprendre les principes qu’il apporte, car ils sont super intéressants même hors de celui-ci.