Kubernetes & Helm Fundamentals

Salut, c'est Alex de DEV STORIES DOT EU. Kubernetes et Helm, les fondamentaux, épisode 1 sur 10. Pendant des années, Google a fait tourner son infrastructure mondiale de recherche et d'e-mail sur un système ultra-secret, nommé d'après les pires méchants de Star Trek. Ils ont dû l'inventer parce que la gestion de serveurs existante ne tenait tout simplement plus la charge à leur échelle. Aujourd'hui, on va regarder les origines, de Borg à Kubernetes, et pourquoi les entreprises modernes s'appuient dessus. Pour comprendre pourquoi Kubernetes existe, tu dois regarder comment le déploiement d'applications a évolué. À l'ère du déploiement traditionnel, tu faisais tourner tes applications sur des serveurs physiques. Il n'y avait aucun moyen de définir des limites de ressources. Si une application prenait presque toute la mémoire, les autres applications sur ce serveur physique en souffraient. Tu pouvais acheter une machine physique séparée pour chaque app, mais ça donnait du hardware super cher et sous-utilisé. Ensuite, on est passés à l'ère du déploiement virtualisé. Tu faisais tourner plusieurs Virtual Machines sur le CPU d'un seul serveur physique. Les VMs isolaient les applications et offraient un certain niveau de sécurité, mais chaque VM nécessitait quand même un système d'exploitation complet et lourd. Enfin, on est arrivés à l'ère du déploiement par containers. Les containers sont similaires aux VMs, mais ils partagent l'OS sous-jacent entre les applications. Comme ils sont découplés du hardware sous-jacent, ils sont légers, rapides à démarrer, et portables sur différents clouds et distributions d'OS. Mais les containers ont apporté un nouveau problème. Si tu fais tourner une application d'entreprise à l'échelle mondiale, tu n'as pas juste un seul container. Tu en as des milliers. Si un container crashe, un autre doit démarrer immédiatement. S'il y a un pic de trafic, tu dois spin up plus de containers et distribuer la load réseau uniformément. Tu ne peux pas gérer ça à la main sur des centaines de machines. Google a rencontré exactement ce problème bien avant le reste de l'industrie. Ils ont créé un container cluster manager interne appelé Borg pour automatiser l'orchestration de centaines de milliers de jobs. Quand il est devenu évident que le reste du monde du software avait besoin de cette même capacité, les ingénieurs de Google ont lancé un projet open-source basé sur les leçons tirées de Borg. Ils lui ont donné une référence à Star Trek, en l'appelant à l'origine Project Seven of Nine, un clin d'œil à un drone Borg qui a échappé au collectif. Ce projet a finalement été lancé sous le nom de Kubernetes. Le logo en forme de gouvernail que tu vois aujourd'hui a sept branches, un petit hommage au nom original du projet. C'est ça la partie importante. Kubernetes te fournit un framework pour faire tourner des systèmes distribués de manière résiliente. Il s'occupe du scaling et du failover pour ton application. Si un container crashe, Kubernetes le remplace. Si un node tombe, il reschedule les containers sur des nodes sains. Il gère le service discovery, ce qui veut dire qu'un container peut être trouvé via un nom DNS ou sa propre adresse IP, et il fait du load balancing pour qu'aucun container ne soit surchargé. Il gère aussi l'orchestration du stockage, en te permettant de mount automatiquement du stockage local ou des cloud providers, et il automatise les rollouts et les rollbacks. Tu décris le state désiré de tes containers déployés, et Kubernetes modifie le state actuel vers le state désiré à un rythme contrôlé. Tu n'écris pas de scripts pour gérer le state du serveur ; tu déclares ce que tu veux, et le système s'en occupe. Ce qu'il faut retenir ici, c'est que Kubernetes n'est pas juste un environnement d'hébergement, c'est une control loop qui compare constamment la réalité à tes attentes et corrige la différence. Avant de terminer, si tu veux nous aider à continuer de faire ces épisodes, cherche DevStoriesEU sur Patreon — on apprécie le soutien. C'est tout pour celui-ci. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Kubernetes et Helm, épisode 2 sur 10. Tu as des dizaines de serveurs qui font tourner des centaines de containers. Quand une machine tombe soudainement en panne, quelque chose doit décider où vont ces workloads orphelins. Un orchestre sans chef d'orchestre, c'est juste du bruit, et une flotte de containers sans cerveau centralisé, c'est un chaos ingérable. Ce cerveau centralisé, ainsi que les machines qui font le vrai travail, forme l'architecture du cluster Kubernetes. Un cluster Kubernetes est divisé en deux parties distinctes. Tu as le Control Plane, qui sert de cerveau, et tu as les Worker Nodes, qui sont les muscles. Le Control Plane prend toutes les décisions globales, comme le scheduling des workloads, et il détecte et réagit aux événements du cluster. Les Worker Nodes hébergent tes applications et exécutent les instructions envoyées par le Control Plane. Chaque cluster doit avoir au moins un Worker Node pour faire tourner les applications. Regardons d'abord le Control Plane. Son composant principal, c'est le kube-apiserver. Parfois, quand on entend API server, on imagine un serveur web standard qui gère les requêtes HTTP pour une application. Mais ce n'est pas du tout ça. Le kube-apiserver est le système nerveux central de tout le cluster. C'est le front-end du Control Plane. Absolument toutes les communications, qu'elles viennent d'un opérateur humain, d'un Worker Node ou d'un composant interne, passent par cet API server. Comme l'API server est complètement stateless, le cluster a besoin d'une mémoire. C'est etcd. C'est un key-value store consistant et hautement disponible qui contient toutes les données du cluster. Chaque fois qu'une configuration est créée ou que l'état du système change, la trace réelle de ce changement se trouve dans etcd. Ensuite, il y a le kube-scheduler. Quand tu demandes au cluster de lancer un nouveau workload de containers, ce workload n'a initialement aucune machine assignée. Le scheduler repère ce workload non assigné. Il évalue les besoins en ressources, les contraintes matérielles et les règles de policy, puis il assigne le workload au Worker Node le plus approprié. Enfin, tu as le kube-controller-manager. Ce composant fait tourner des boucles continues en arrière-plan qu'on appelle des controllers. Ces controllers surveillent constamment l'état actuel du cluster via l'API server, et travaillent activement pour pousser cet état actuel vers ton état désiré. Si un Worker Node plante, le controller manager remarque la machine manquante et déclenche la réponse pour remplacer les workloads perdus. Voilà pour le cerveau. Maintenant, regardons les Worker Nodes qui exécutent les tâches. Des composants de nœud tournent sur chaque machine worker pour maintenir l'environnement runtime. Le composant le plus critique ici, c'est le kubelet. C'est un agent qui tourne sur chaque nœud et qui communique directement avec le Control Plane. Le kubelet reçoit les instructions de l'API server et s'assure que les containers requis sont bien en train de tourner et en bonne santé sur sa machine spécifique. Le kubelet ne démarre pas les containers lui-même. Il délègue cette tâche au Container Runtime. Le runtime est le logiciel réel, comme containerd, qui est responsable de pull les images de containers depuis un registry et de démarrer les processus sur le système d'exploitation. Enfin, il y a le kube-proxy. C'est un proxy réseau qui tourne sur chaque nœud. Il maintient les règles du réseau local qui permettent aux communications réseau d'atteindre tes containers depuis l'intérieur ou l'extérieur du cluster. Voici l'idée clé. Le Control Plane dicte ce qui doit se passer, mais il n'exécute jamais le code de l'application. Les Worker Nodes font tourner le code de l'application, mais ils dépendent entièrement du Control Plane pour leur dire quoi exécuter. Cette séparation stricte entre la prise de décision et l'exécution est ce qui permet à Kubernetes de scale horizontalement et de récupérer automatiquement des pannes matérielles. C'est tout pour cette fois. Merci de ton écoute, et continue de développer !

Salut, ici Alex de DEV STORIES DOT EU. Kubernetes et Helm : les fondamentaux, épisode 3 sur 10. Tu buildes un conteneur, tu le testes en local, et tu le passes à Kubernetes pour le run. Mais Kubernetes refuse catégoriquement de gérer ton conteneur directement. À la place, il exige que tu le wrappes d'abord dans une abstraction complètement différente. On va démystifier les Pods, la véritable unité de travail de cet écosystème. Si les conteneurs sont les baleines solitaires du monde traditionnel de la conteneurisation, les Pods sont les bancs soudés dans lesquels elles nagent ensemble. Un Pod est le plus petit objet déployable, le plus basique, que tu peux créer et gérer dans Kubernetes. Il représente une instance unique d'un process qui tourne dans ton cluster. Tu te demandes peut-être pourquoi Kubernetes introduit cette couche supplémentaire au lieu de gérer les conteneurs directement. La réponse, c'est l'abstraction et le contexte partagé. Kubernetes a besoin d'une façon uniforme de gérer le networking, le storage et le scheduling, quel que soit le container runtime sous-jacent que tu utilises. En wrappant les conteneurs dans un Pod, Kubernetes traite le Pod comme un hôte logique. Voici le point clé. Un Pod ne fait pas que wrapper un seul conteneur ; il établit un environnement d'exécution partagé. Même si un Pod ne contient souvent qu'un seul conteneur, il peut en héberger plusieurs qui ont besoin de travailler étroitement ensemble. Quand plusieurs conteneurs sont placés dans le même Pod, ils sont garantis d'être schedulés sur la même machine physique ou virtuelle. Plus important encore, ces conteneurs partagent le même network namespace. Chaque conteneur à l'intérieur d'un même Pod partage une seule adresse IP et un seul port space. Comme ils existent dans le même contexte réseau, ils peuvent communiquer entre eux simplement en utilisant localhost. Pas besoin de DNS lookups internes ou de service routing complexe juste pour faire parler deux process locaux. Si le conteneur A bind sur le port 8000, le conteneur B dans le même Pod peut le joindre sur localhost port 8000. Ce contexte partagé s'étend au storage. Tu peux définir des volumes de storage partagés au niveau du Pod. Une fois définis, n'importe quel conteneur dans ce Pod peut monter ces volumes partagés dans son propre file system. Ça permet à des conteneurs étroitement couplés de lire et d'écrire exactement les mêmes fichiers de manière transparente. Prends l'exemple d'un conteneur de web server principal. Son job, c'est de servir du trafic HTTP, mais il écrit aussi des access logs bruts dans un répertoire local. Tu veux envoyer ces logs vers un système de monitoring centralisé, mais tu ne veux pas alourdir l'image de ton web server avec des agents de logging et des fichiers de configuration. À la place, tu crées un deuxième conteneur, un petit utilitaire de logging. Tu déploies le web server et le conteneur de logging dans exactement le même Pod. Le web server écrit ses logs dans un volume de storage partagé. Le conteneur de logging, qui agit comme un sidecar, monte ce même volume, lit les fichiers de logs entrants, et les streame vers ton système de monitoring. Ils fonctionnent comme une seule unité intégrée, en partageant les ressources sans brouiller leurs responsabilités individuelles. Quand tu dois décider si deux conteneurs ont leur place dans le même Pod, demande-toi s'ils ont fondamentalement besoin d'atterrir sur la même machine et de partager un lifecycle identique. S'ils n'ont pas absolument besoin de deploy, de démarrer et de mourir ensemble, ils doivent aller dans des Pods séparés. C'est tout pour cet épisode. Merci de ton écoute, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. Kubernetes et Helm : les fondamentaux, épisode 4 sur 10. Tu dors. À trois heures du matin, un memory leak fait planter ton serveur d'application principal. Dans un setup classique, une alerte se déclenche, et tu te réveilles pour redémarrer le process manuellement. Avec Kubernetes, le système gère la nuit pour toi. C'est toute la puissance de la gestion du state avec les Deployments. Un Deployment permet de faire des mises à jour déclaratives pour tes applications. Au lieu d'écrire des scripts qui dictent au système étape par étape comment faire tourner ton software, tu décris exactement à quoi le résultat final doit ressembler. Tu transmets ce state désiré au controller du Deployment, et il modifie le state actuel pour qu'il corresponde, à un rythme contrôlé. Pour comprendre comment il fait ça, tu dois connaître la hiérarchie. Tu crées rarement des Pods individuels directement. À la place, tu crées un Deployment. Le Deployment crée ensuite un objet secondaire appelé ReplicaSet. Le ReplicaSet est le mécanisme strictement responsable de garantir que le nombre exact de replicas de Pods spécifié tourne à tout moment. Si un node du serveur tombe en panne, ou si un Pod crashe à cause de ce memory leak, le ReplicaSet remarque que les chiffres sont passés en dessous de ton state désiré. Il démarre immédiatement un nouveau Pod pour remplacer celui qui a été perdu. C'est ton mécanisme de self-healing. Tu n'interviens jamais. La même logique s'applique au scaling. Si le trafic fait un pic, tu mets à jour ton fichier de Deployment pour demander cinq replicas au lieu de trois. Le controller voit la différence entre ta demande et la réalité, et ordonne au ReplicaSet de lancer deux Pods de plus. Cette approche déclarative est cruciale pendant les mises à jour de l'application. Disons que tu as trois Pods qui font tourner une image Nginx en version 1.14. Tu dois faire l'upgrade vers la version 1.16 sans perdre de trafic utilisateur. Tu mets simplement à jour la version de l'image dans la configuration de ton Deployment. Le Deployment ne termine pas tous tes anciens Pods d'un coup. À la place, il crée un tout nouveau ReplicaSet spécifiquement pour la version 1.16. Ensuite, il commence un rolling update. Il démarre un nouveau Pod dans le nouveau ReplicaSet. Une fois que ce nouveau Pod est healthy, il scale down l'ancien ReplicaSet en terminant un Pod en version 1.14. Il répète ce process prudent et décalé jusqu'à ce que les trois anciens Pods aient disparu et que trois nouveaux Pods tournent. La transition est complètement transparente. Maintenant, que se passe-t-il si l'update est cassée ? Voici le point clé. Parce que le controller du Deployment orchestre ces ReplicaSets, il t'offre un filet de sécurité intégré. Si tu tapes accidentellement le nom de l'image comme Nginx 1.16-typo, les nouveaux Pods vont crasher au startup. Le Deployment détecte l'erreur et stoppe le rollout immédiatement. Il laisse tes anciens Pods restants tourner pour que ton application reste en ligne. Une fois que tu repères l'erreur, tu peux lancer une commande de rollback. Le Deployment va simplement scale up l'ancien ReplicaSet qui fonctionne, et scale down celui qui est cassé à zéro. La véritable force d'un Deployment, ce n'est pas juste de lancer des containers, mais sa boucle continue et implacable qui compare ce que tu as demandé avec ce qui existe vraiment, et qui force la réalité à correspondre. Je voudrais prendre un moment pour te remercier d'avoir écouté — ça nous aide beaucoup. Passe une bonne journée !

Salut, c'est Alex de DEV STORIES DOT EU. Les fondamentaux de Kubernetes et Helm, épisode 5 sur 10. Les Pods sont mortels. Ils plantent, ils scale down, ils se font evict, et quand ils sont remplacés, ils récupèrent une toute nouvelle adresse IP. Si ton application essaie de communiquer avec eux, tu tires constamment sur une cible mouvante. Les Services Kubernetes résolvent exactement ce problème. Prends l'exemple d'une application web classique. Tu as un deployment frontend et une base de données backend. Si ton Pod de base de données redémarre, le control plane du cluster démarre un nouveau Pod pour le remplacer. Ce nouveau Pod se voit attribuer une adresse IP complètement différente sur le réseau du cluster. Si ton frontend était configuré pour parler directement à l'ancienne IP, la connexion coupe et ton application plante. Tu ne peux pas te fier aux IP individuelles des Pods pour quoi que ce soit de permanent. Un Service Kubernetes est une abstraction qui fournit une identité réseau stable et durable pour un groupe dynamique de Pods. Quand tu crées un Service, on lui attribue une adresse IP qui ne changera jamais tant que le Service existe. Ton application frontend n'a pas besoin de suivre exactement quels Pods de base de données sont en vie à une seconde donnée. Elle envoie simplement le trafic vers l'IP du Service. En plus, le cluster attribue un nom DNS stable au Service. Ton code frontend peut juste se connecter à un simple hostname, et le cluster le résout automatiquement vers la bonne adresse IP. En coulisses, le Service agit comme un load balancer interne. Il s'appuie sur un composant appelé kube-proxy qui tourne sur chaque node pour implémenter les règles de routing. Quand le trafic arrive sur le Service, il est redirigé vers l'un des Pods healthy qui se trouvent derrière. Pour lier un Service aux bons Pods, tu utilises des labels et des selectors. Tu peux configurer le Service avec un selector qui cherche le label indiquant une application de base de données. Le Service surveille constamment le cluster. Si un Pod de base de données meurt, son IP est retirée du pool actif. Quand le Pod de remplacement démarre, sa nouvelle IP est ajoutée. L'application frontend ne se rend absolument pas compte que la topologie réseau sous-jacente vient de changer. Il y a plusieurs façons d'exposer un Service, selon l'origine du trafic. Le type par défaut est ClusterIP. Un Service ClusterIP obtient une adresse IP interne accessible uniquement depuis l'intérieur du cluster. C'est le bon choix pour ta base de données backend, pour la garder isolée en toute sécurité du monde extérieur. Mais ton frontend a besoin de recevoir du trafic d'utilisateurs externes. Pour ça, tu changes le type de Service en LoadBalancer. Quand tu crées un Service LoadBalancer, Kubernetes communique avec ton cloud provider pour provisionner un load balancer externe standard. Le trafic internet externe tape sur cette ressource cloud, qui redirige la connexion dans ton cluster, en la faisant passer par le Service et finalement jusqu'à tes Pods frontend. Voici l'idée clé. Les Services découplent l'identité adressable de ton application des workloads physiques qui exécutent réellement la logique. Tu arrêtes de router vers des instances spécifiques et fragiles, et tu commences à router vers un concept résilient et persistant. C'est tout pour cet épisode. Merci de m'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Kubernetes et Helm : les fondamentaux, épisode 6 sur 10. Tu veux déployer une seule application, mais tu te retrouves à gérer des centaines de lignes de YAML statique à travers tes deployments, tes services et tes ingresses. Quand tu dois pusher cette même application sur un environnement de staging, tu copies ces fichiers dans un nouveau répertoire et tu fais un chercher-remplacer manuel pour les image tags et les hostnames. C'est fragile, hyper répétitif et impossible à maintenir à mesure que ton infrastructure grandit. C'est exactement le problème que Helm vient résoudre. Helm est le package manager de Kubernetes. Tu peux le voir comme apt, yum ou Homebrew, mais conçu spécifiquement pour les ressources Kubernetes. Au lieu de traiter ton application comme un ensemble en vrac de manifests YAML indépendants, Helm les regroupe en une seule unité cohérente. Ce format de packaging s'appelle un Chart. Un Chart, c'est en gros un répertoire qui contient des fichiers décrivant un ensemble de ressources Kubernetes liées entre elles. Il contient toutes les définitions dont ton application a besoin pour tourner. Le mécanisme principal qui rend un Chart utile, c'est le templating. Les manifests Kubernetes bruts sont complètement statiques. Un Chart Helm, à l'inverse, remplace les détails d'infrastructure hardcodés par des variables de template. Au lieu d'écrire un replica count spécifique, un container image tag fixe ou une variable d'environnement distincte directement dans un fichier de deployment, tu définis des placeholders. Au moment du deploy, Helm fusionne ces templates avec un fichier séparé qui contient tes valeurs spécifiques. Avec cette architecture, tu n'as plus qu'à maintenir un seul Chart pour ton application. Tu lui passes simplement différents paramètres de configuration selon que tu déploies en local, en staging ou en production. Quand tu prends un Chart, que tu le combines avec tes valeurs de configuration spécifiques et que tu le déploies sur un cluster Kubernetes, tu crées ce que Helm appelle une Release. C'est là que ça devient intéressant. Un Chart n'est que le blueprint générique. Une Release, c'est l'instance réellement déployée qui tourne dans ton cluster. Grâce à cette séparation stricte entre le blueprint et l'instance, tu peux installer exactement le même Chart plusieurs fois dans le même cluster. Si tu as besoin de trois instances séparées d'un serveur de cache, tu ne dupliques pas le YAML. Tu installes le Chart de cache trois fois. Helm suit chaque installation comme une Release distincte, avec son propre nom unique, ses propres valeurs de configuration et son propre lifecycle isolé. Helm suit aussi l'état et l'historique de ces Releases à l'intérieur du cluster. Quand tu mets à jour une application en fournissant un nouvel image tag ou en modifiant un paramètre, Helm évalue les différences et crée une nouvelle révision de cette Release spécifique. Il applique uniquement les changements nécessaires aux ressources Kubernetes sous-jacentes. Si une mise à jour échoue ou qu'une application commence à avoir un comportement erratique, tu commandes à Helm de faire un roll back vers une révision précédente. Helm sait exactement quelles ressources Kubernetes appartiennent à quelle version de ton application, et gère la création, la modification et la suppression de ces ressources comme une seule opération. Le changement fondamental avec Helm, c'est l'abstraction. Tu arrêtes de gérer des fichiers texte indépendants qui représentent des pods, des services et des volumes déconnectés, et tu commences à déployer, configurer et upgrader des applications complètes. Merci pour ton écoute, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. Kubernetes et Helm : les fondamentaux, épisode 7 sur 10. Tu dois mettre à jour le mot de passe d'une base de données, mais les credentials sont hardcodés dans quinze fichiers YAML différents. Un seul fichier oublié, et tout le deployment plante. Hardcoder la configuration directement dans ta structure de deployment, c'est fragile. La solution, c'est de comprendre l'anatomie d'un chart Helm. Un chart Helm, c'est un package standardisé qui contient toutes les définitions de ressources nécessaires pour faire tourner une application, un outil ou un service dans un cluster Kubernetes. Tout le système repose sur une philosophie de base : une séparation stricte entre la définition structurelle et la configuration spécifique à l'environnement. Tu définis la forme de ton deployment une seule fois, et tu injectes les détails spécifiques au moment du deployment. Quand tu regardes à l'intérieur d'un chart Helm, tu trouves une arborescence de répertoires bien spécifique. Le dossier racine porte toujours le nom du chart lui-même. À l'intérieur de ce dossier, trois composants principaux pilotent le système de packaging. Le premier, c'est un fichier qui s'appelle Chart point yaml. C'est le hub de métadonnées. Il dit exactement à Helm ce qu'est le package. Il contient la version de l'API pour le standard du chart, le nom du chart, une description et les numéros de version. Surtout, il tracke à la fois la version du chart lui-même, et l'app version, c'est-à-dire la version du logiciel qui est déployé. Tu peux aussi trouver un répertoire charts juste à côté, qui contient tous les subcharts dont ton application dépend, mais le fichier de métadonnées reste l'identifiant principal. Le deuxième composant principal, c'est le répertoire templates. C'est là que se trouve la définition structurelle. Dedans, tu places tes fichiers manifests Kubernetes standards, comme les deployments et les services. Par contre, au lieu d'écrire du YAML statique, ces fichiers contiennent de la logique de template Go. Au lieu de hardcoder un nombre de replicas à trois, ou de coller un mot de passe de base de données spécifique, tu écris une directive de template. Cette directive dit à Helm d'aller chercher la valeur requise dynamiquement pendant le deployment. Le troisième composant répond à ces recherches dynamiques. C'est un fichier qui s'appelle values point yaml, situé à la racine du répertoire du chart, juste à côté du fichier de métadonnées. Ce fichier contient les paramètres de configuration par défaut. Quand un template demande un repository d'image, un numéro de port ou un mot de passe, le fichier values fournit la réponse de base. Voici le point essentiel. Les templates dictent l'architecture de ton application, alors que les values dictent comment cette architecture se comporte dans un environnement spécifique. Quand tu lances une commande install, Helm prend les templates bruts, les merge avec le fichier values, et génère des manifests Kubernetes finaux et valides. Il envoie ensuite ces manifests générés à l'API Kubernetes. C'est cette séparation qui rend les charts super réutilisables. Imagine un scénario où tu dois deploy exactement la même application dans un environnement de staging et un environnement de production. Tu ne copies pas et tu ne modifies pas le chart. Tu utilises exactement la même structure de répertoires et les mêmes templates. Pour le deployment en staging, tu passes à Helm un fichier values custom pendant la commande install. Ce fichier override les valeurs par défaut, en spécifiant un replica de pod, une URL de base de données de test locale, et un logging de niveau debug. Quand tu fais ton deployment en production, tu passes un fichier values complètement différent. Ce fichier de production spécifie dix replicas, une URL de base de données managée, et des contraintes de ressources strictes. Helm merge le set unique de templates avec les fichiers values custom respectifs, ce qui produit deux profils de deployment complètement différents. La puissance d'un chart Helm ne réside pas dans le YAML qu'il contient, mais dans les frontières qu'il crée. Il verrouille l'architecture de l'infrastructure dans les templates, tout en gardant les détails opérationnels complètement fluides dans les values. C'est tout pour cet épisode. Merci de ton écoute, et continue à builder !

Salut, ici Alex de DEV STORIES DOT EU. Kubernetes et Helm : les fondamentaux, épisode 8 sur 10. Ce n'est pas parce que tu peux templater chaque ligne d'un manifest Kubernetes que tu dois le faire. Quand tu essaies de rendre chaque champ configurable, tu te retrouves avec un chart que personne ne peut lire, et encore moins maintenir. Cet épisode couvre les best practices des charts Helm, les règles qui empêchent tes configurations de s'effondrer sous leur propre poids. Le principal piège lors de la création d'un chart est l'over-templating. Beaucoup de développeurs considèrent les templates Helm comme de simples scripts de remplacement de texte. C'est une erreur fréquente. Helm utilise un moteur de templates Go pour produire du YAML structuré et valide. Si tu ajoutes une variable à un fichier sans gérer soigneusement l'indentation et les types de données, le YAML généré sera complètement cassé. C'est pourquoi tu ne devrais templater que les valeurs qui changent réellement d'un environnement à l'autre. Pense aux tags d'image, aux replicas, aux resource limits ou aux règles d'ingress. Laisse les champs structurels principaux hardcodés. Si un utilisateur n'a jamais besoin de modifier un security context ou un volume mount spécifique, ne l'expose pas comme variable. Le fichier values point yaml sert d'API publique pour ton chart. Quand tu organises ce fichier, tu dois trouver un équilibre entre structure et facilité d'utilisation. La recommandation officielle est de garder la hiérarchie aussi plate que possible. Même si tu dois regrouper les paramètres associés, évite le deep nesting. Pense à l'utilisateur qui passe des overrides via la ligne de commande. Le forcer à taper un chemin séparé par des points sur cinq niveaux de profondeur juste pour changer un numéro de port crée des frictions inutiles. Si tu as une configuration de serveur web, place les propriétés sous une seule clé server, mais garde les propriétés internes à plat. Pour nommer ces variables, utilise toujours le camel case. Commence par une minuscule et mets une majuscule à la première lettre de chaque mot suivant. N'utilise ni tirets ni underscores dans ton fichier values. Tu pourrais créer une variable nommée externalPort, plutôt que external tiret port. L'utilisation cohérente du camel case évite les erreurs de parsing lors du rendu des templates et correspond aux standards plus larges de l'écosystème Kubernetes. Garde aussi une stricte cohérence des types. Si un paramètre est un entier dans Kubernetes, comme un numéro de port, laisse-le comme un entier dans ton fichier values. Ne le mets pas entre guillemets pour le transformer en string. Cette cohérence s'applique directement à la façon dont tu tagues les ressources générées par ton chart. Chaque objet a besoin de labels standards. Les best practices Helm dictent d'utiliser les labels d'application Kubernetes officiels. Plus précisément, utilise le préfixe app point kubernetes point io. Le label name doit correspondre au nom du chart, tandis que le label instance doit correspondre au nom de la release. Tu inclus aussi le label version, et tu notes que la ressource est gérée par Helm. Appliquer ces labels exacts à chaque deployment, pod, service et config map garantit que les outils de monitoring externes et les service meshes peuvent automatiquement découvrir et regrouper les composants de ton application sans configuration manuelle. Voici l'idée clé. Le meilleur chart Helm n'est pas celui qui a le plus d'options de configuration. C'est celui qui nécessite le moins d'overrides pour fonctionner correctement out of the box. Si tu veux aider à faire vivre l'émission, cherche DevStoriesEU sur Patreon — on apprécie vraiment le soutien. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. Kubernetes et Helm : les fondamentaux, épisode 9 sur 10. Créer un cluster from scratch est un super exercice d'apprentissage, mais quand tu scales à des centaines de microservices, tu n'as pas envie de gérer le control plane toi-même. Tu veux que le cloud provider fasse le gros du travail pour que tes ingénieurs puissent se concentrer sur le fait de shipper du code. C'est exactement à ça que ressemble une implémentation Azure d'entreprise de Kubernetes et Helm. Dans une architecture Kubernetes standard, tu as un control plane qui prend les décisions globales et des worker nodes qui les exécutent. Garder ce control plane hautement disponible est notoirement difficile. Un client d'entreprise qui déploie sur Azure utilise généralement Azure Kubernetes Service, ou AKS. AKS abstrait le control plane. Azure gère l'API server, le scheduler et le key-value data store. Ton équipe d'ops est uniquement responsable des worker nodes qui font réellement tourner tes applications. Alors, comment une application passe-t-elle de la machine d'un développeur à ces worker nodes ? C'est là que Helm entre dans le workflow. Une application d'entreprise se compose rarement d'un seul container. C'est généralement une collection de microservices, chacun ayant besoin de ses propres deployments, services et configurations. Au lieu de gérer des dizaines de fichiers YAML statiques, les développeurs packagent ces ressources dans un Helm chart. Un chart agit comme un blueprint unique et versionné pour un microservice. Comme Helm utilise des templates, les développeurs peuvent écrire la logique structurelle une seule fois et injecter différentes valeurs de configuration selon qu'ils déploient sur un cluster de dev, de staging ou de production. Avant que quoi que ce soit ne tourne, le code de l'application est buildé en images de container. Ces images sont pushées vers un espace de stockage sécurisé, comme un container registry. Les Helm charts eux-mêmes peuvent aussi être packagés et pushés vers un registry, ce qui permet aux équipes d'entreprise de traiter leurs définitions d'infrastructure exactement comme leur code d'application compilé. Voici le point clé. Quand une release pipeline déclenche un deployment, Helm évalue ses templates avec les valeurs spécifiques à l'environnement et envoie les manifests finaux à l'API server d'AKS. Le control plane d'AKS lit cet état désiré et commence à scheduler des Pods sur tes worker nodes. Les nodes contactent le container registry, s'authentifient de manière sécurisée, pullent les versions d'images spécifiques et démarrent les containers. Kubernetes monitore cet état en permanence. Si un worker node crashe, le control plane reschedule immédiatement ses Pods sur des nodes sains pour maintenir le nombre de replicas défini dans le Helm chart. Une fois que les Pods tournent, ils doivent recevoir du trafic. Un Helm chart inclura généralement une définition de service pour exposer l'application. Quand c'est déployé sur AKS, Kubernetes parle directement à l'infrastructure Azure sous-jacente. Si le service demande un point d'entrée public, AKS provisionne automatiquement un Azure Load Balancer. Ce load balancer prend le trafic externe entrant et le route de manière sécurisée dans le cluster, en le distribuant sur les Pods sains. Tes développeurs n'ont jamais eu besoin de toucher au portail Azure ou d'écrire des règles de routage cloud spécifiques. Ils ont simplement défini un service Kubernetes standard dans leur Helm chart, et la plateforme managée s'est occupée du provisioning du réseau physique. La vraie puissance de cette architecture d'entreprise, c'est la séparation claire des responsabilités. Helm standardise la façon dont l'application est définie à travers les environnements, le registry sécurise les artefacts versionnés, et la plateforme cloud managée s'assure que l'infrastructure sous-jacente reste bien en vie pour la faire tourner. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. Kubernetes et Helm : les fondamentaux, épisode 10 sur 10. Tu as la théorie et les outils. Mais quand tu te retrouves face à un terminal vide, le fossé entre une infrastructure cloud massive et ton ordinateur portable paraît immense. Combler ce fossé, c'est exactement le but quand tu commences avec Minikube. Un cluster Kubernetes en production implique plusieurs machines qui agissent comme control planes et worker nodes. Provisionner tout ça dans le cloud coûte de l'argent, prend du temps et demande une configuration réseau complexe. Pour un développeur solo ou une petite équipe qui conçoit une architecture day-one, tu as besoin d'un environnement local qui se comporte exactement comme la production, sans l'overhead. Minikube est une implémentation Kubernetes légère qui crée une machine virtuelle ou un conteneur directement sur ton ordinateur portable. Dans cet environnement isolé, il déploie un cluster simple, single-node. D'habitude, Kubernetes sépare le control plane, qui gère l'état du cluster, des worker nodes, qui font tourner les conteneurs de ton application. Minikube les combine. Ta machine locale fait tourner un seul nœud qui gère à la fois la logique de management et les workloads de l'application. Il n'est pas fait pour servir du trafic de production. Il existe uniquement pour que tu puisses tester ton orchestration de conteneurs en toute sécurité. Voici le point clé. L'interface que tu utilises pour interagir avec Minikube est identique à celle que tu utilises pour un énorme cluster cloud. Tu utilises l'outil en ligne de commande kubectl. Quand tu exécutes une commande kubectl, elle communique directement avec le control plane de Minikube via son API. Il n'y a pas de syntaxe spéciale à apprendre pour le développement local. Le workflow correspond parfaitement au tutoriel officiel des bases de Kubernetes. Tu inities le cluster avec une simple commande start. Minikube provisionne l'environnement et configure automatiquement kubectl pour pointer vers ta nouvelle instance locale. À partir de là, tu utilises kubectl pour créer un deployment. Tu dis au control plane de pull une image de conteneur spécifique et de la faire tourner. Une fois déployée, ton application tourne dans un pod sur ce nœud unique. Cependant, elle est isolée de ton réseau hôte. Pour y accéder depuis le navigateur de ton ordinateur portable, tu dois l'exposer en créant un service. Un service route le trafic depuis un port spécifique sur ta machine locale vers le bon port sur le pod qui tourne dans Minikube. À partir de là, tu peux pratiquer toutes les fonctions de base de Kubernetes. Tu peux scale ton application en disant à kubectl d'augmenter le nombre de replicas. Minikube va lancer des pods supplémentaires à côté du premier. Tu peux t'entraîner aux rolling updates en changeant la version de l'image du conteneur dans ton deployment. Minikube va terminer proprement les anciens pods et en démarrer de nouveaux, simulant un deployment zero-downtime. Comme Minikube expose une API Kubernetes standard, ton outillage externe s'intègre parfaitement. Helm marche immédiatement. Tu peux installer des bases de données complexes, des ingress controllers ou des message queues en utilisant des Helm charts, exactement comme tu le ferais dans un environnement live. Minikube inclut même des addons intégrés, comme un web dashboard local, qui te permet d'inspecter visuellement l'état de ton cluster, de lire les logs et de monitorer l'utilisation des ressources. La vraie force d'un cluster local, c'est la parité. Quand tu écris une configuration de deployment ou un Helm chart qui tourne avec succès sur Minikube, tu as déjà écrit la configuration exacte qui tournera dans le cloud. Prends le temps d'explorer la documentation officielle de Kubernetes et de tester ces commandes en pratique. Si tu as des suggestions de sujets qu'on devrait aborder dans notre prochaine série, visite devstories dot eu et dis-le-nous. C'est tout pour aujourd'hui. Merci d'avoir écouté, va construire un truc cool.