Aujourd'hui, nous allons parler d'un sujet dont presque tout le monde a entendu parler sans pouvoir l'expliquer, Kubernetes. C'est déroutant, car il résout un problème que la plupart des gens ne voient pas avant d'y être confronté. Tout le monde sait que c'est important, mais demandez-leur ce qu'il fait, vous obtiendrez un regard vide. Ce n'est pas un remplaçant de Docker, ni un système d'exploitation cloud, bien que les gens le supposent souvent. La confusion est logique, car Kubernetes résout un problème dont vous ignorez l'existence avant d'y être confronté. C'est un outil qui devient essentiel lorsque vous avez plus d'une poignée de conteneurs à gérer. A la fin de cet épisode, vous comprendrez ce qu'est réellement Kubernetes, comment ils s'intègrent au conteneur, et pourquoi Azure Kubernetes Service le rend pratique pour les équipes qui ne veulent pas tout créer à partir de zéro. Prenez votre café, plongeons-nous dans le vif du sujet.

Le problème avant les conteneurs. Revenons au problème. Imaginez une entreprise de logiciels il y a 10 ans. Vous avez quelques applications à exécuter, vous achetez donc des serveurs, installez des systèmes d'exploitation et déployez tout manuellement. Chaque application dispose de sa propre machine, et vous ne pouvez pas partager les ressources centrales. Si une application a besoin de beaucoup de mémoire et qu'une autre en utilise à peine, chacune d'elles dispose de son propre serveur. Le gaspillage était là. Les serveurs fonctionnaient à environ 20% de leur capacité, mais vous ne pouviez pas les consolider, car les applications se disputaient les dépendances. Vous vous retrouviez avec une salle remplie de serveurs, chacun ne faisant pratiquement rien, chacun consommant de l'énergie et du refroidissement, et tous nécessitant une maintenance constante. Une application a besoin de Python 3.7, une autre de Python 3.8, l'une a besoin d'une bibliothèque plus ancienne, une autre de la dernière.

Vous ne pouvez pas les exécuter sur la même machine sans casser quelque chose, vous achetez donc plus de serveurs et payez pour du matériel qui reste principalement inactif. Les machines virtuelles ont un peu aidé en vous permettant de découper un serveur physique en plus petits morceaux, chacun exécutant son propre système d'exploitation, mais chaque VM est lourde, avec un système d'exploitation complet qui occupe de l'espace disque et de la mémoire et prend quelques minutes à démarrer. Et vous deviez configurer chacun séparément, ce qui représentait beaucoup de travail. Vous deviez toujours gérer tous ces systèmes d'exploitation, les corriger, les mettre à jour et les sécuriser. Les équipes avaient besoin de quelque chose de plus léger et portable, un moyen de regrouper une application avec tout ce dont elle a besoin pour fonctionner sans la surcharge d'une machine virtuelle complète et qui puisse être déplacée facilement d'une machine à l'autre.

C'est là que les conteneurs sont en train de... Ce que sont réellement les conteneurs ? Un conteneur est un petit paquet qui inclut votre application et tout ce dont elle a besoin pour fonctionner. Cela signifie que le code, l'environnement d'exécution, les bibliothèques et les fichiers de configuration sont tous regroupés dans une seule unité. Pensez-y comme un conteneur d'expédition pour les logiciels. Un conteneur d'expédition peut être embarqué dans un camion, un train ou un bateau et le conteneur lui-même reste le même. Votre conteneur logiciel fonctionne de la même manière. Vous le créez une fois et il s'exécute de la même manière sur votre ordinateur portable, votre serveur de test et votre environnement de production. La principale différence entre les conteneurs et les machines virtuelles réside dans leur efficacité. Une machine virtuelle exécute son propre système d'exploitation complet de sorte que chaque machine virtuelle possède son propre noyau, ses propres fichiers système et tout le reste.

Un conteneur partage le système d'exploitation au long. Il s'agit simplement d'un processus avec sa propre vision isolée du monde. Cela signifie que les conteneurs démarrent en quelques secondes et non en quelques minutes. Ils utilisent moins de mémoire et vous pouvez en regrouper davantage sur une seule machine. Docker a rendu les conteneurs populaires en offrant aux développeurs un moyen simple de les créer et de les exécuter avec une seule commande. Soudain, le problème du cas, ça marche sur ma machine gueule, commençait à disparaître. Si votre application s'exécute dans un conteneur sur votre ordinateur portable, elle s'exécutera de la même manière sur le serveur. L'environnement est cohérent partout, mais les conteneurs résolvent un problème et en créent un autre. Avec quelques conteneurs, la gestion manuelle fonctionne très bien. Vous pouvez les démarrer, les arrêter et en assurer de suivre vous-même.

Mais que se passe-t-il lorsque vous en avez des centaines ? Vous devez décider quel serveur exécute quel conteneur, redémarrer ceux qui ont échoué, les connecter les uns aux autres et les faire évoluer lorsque le trafic augmente. C'est un nouveau défi et c'est exactement là qu'intervient Kubernetes. Le problème de l'orchestration. Donc, vous avez des conteneurs qui fonctionnent, vous empaquetez votre application et s'exécute de manière cohérente partout et la vie est belle. Mais seulement pendant un certain temps. Avec 10 ou 20 conteneurs, vous pouvez gérer les choses manuellement. Vous savez quel serveur exécute quel conteneur, vous pouvez redémarrer quelque chose en cas de panne et mettre à jour quelques éléments ici et là. C'est gérable. Mais votre application grandit. Passez au microservice. Ainsi, au lieu d'une seule grosse application, vous en avez 20 plus petites. Chacune nécessite plusieurs copies pour être fiable et vous vous retrouvez maintenant avec 200 conteneurs.

La gestion manuelle ne fonctionne plus. Vous devez décider quel serveur exécute chaque conteneur, redémarrer les conteneurs en cas de défaillance et les connecter pour qu'ils puissent communiquer, pour qu'ils puissent communiquer. Vous devez également augmenter la capacité lorsque le trafic augmente. Par exemple, pendant une vente ou un lancement de produit et la réduire lorsque les choses se calment. Et vous devez déployer des mises à jour sans interruption, ce qui signifie remplacer les anciens conteneurs par de nouveaux, un par un, avec précaution et sans rien casser. Ce sont des problèmes d'orchestration et c'est exactement ce que Kubernetes a été conçu pour résoudre, résoudre. Kubernetes est une plateforme open source qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Considérez-la comme le système d'exploitation de votre Sando 2. Tout comme Windows ou Linux gèrent les ressources d'un seul ordinateur, comme le processeur.

La mémoire et le disque, Kubernetes gèrent les ressources de tous vos serveurs. Il traite toutes vos machines comme un seul et même pool de puissance de calcul. Vous lui indiquez ce que vous souhaitez exécuter et il détermine où le placer, comment le faire fonctionner et comment le connecter à tout le reste. Concept de base, pods, nœuds et clusters. Voyons comment fonctionne réellement Kubernetes. La plus petite unité de Kubernetes est appelée un pod. Un pod englobe un ou plusieurs conteneurs. Les conteneurs d'un même pod partagent le stockage et la mise en réseau, ce qui leur permet de communiquer entre eux via localhost. Vous pouvez considérer un pod comme une unité de déploiement unique. Vous ne déployez pas de conteneur directement dans Kubernetes. Vous déployez des pods. Les pods ne fonctionnent pas seuls, ils fonctionnent sur des nœuds. Un nœud est un serveur, physique ou virtuel, qui fait partie de votre cluster Kubernetes.

Chaque nœud exécute le logiciel nécessaire à l'exécution des pods, ainsi que quelques autres éléments que nous abordons dans ce temps. Un cluster est l'ensemble de tous les nœuds gérés comme un système unifié. En termes simples, un pod est votre application, un nœud est l'endroit où elles s'exécutent, et le cluster est l'environnement entier. Les pods sont éphémères. Ils peuvent être créés, détruits ou déplacés à tout moment. C'est intentionnel. Si un nœud tombe en panne, Kubernetes déplace les pods vers un autre. Pour la mise à l'échelle, ils créent de nouveaux pods, et lorsqu'un pod plante, il est remplacé automatiquement. L'ensemble traite les pods comme temporaires. Mais si les pods vont et viennent, vous devez trouver un moyen de leur part. Au lieu de parler directement à un pod, vous parlez à un service. Un service fourni une adresse réseau stable qui achemine le trafic vers les bons pods, même lorsque des pods changent.

Imaginez un hôtel. Le numéro de téléphone de l'hôtel et le service. Les chambres changent tout le temps de client, mais le numéro de téléphone reste le même. Vous appelez la réception et ils acheminent votre appel vers la bonne salle. C'est exactement ce que fait un service dans Kubernetes. Ils vous donnent une adresse fixe qui pointe toujours vers les pods qui exécutent actuellement votre application. Le plan de contrôle, le cerveau du cluster. Vous avez donc des pods, des nœuds et un cluster. La question est de savoir qui décide de l'exécution de chaque élément. C'est le rôle du plan de contrôle. Chaque cluster Kubernetes en possède un, et c'est le cerveau de toute l'opération. Toutes les décisions sont prises ici. Le plan de contrôle comporte plusieurs composants. Le premier est le serveur d'API, qui agit comme la porte d'entrée de votre cluster. Chaque commande que vous envoyez à Kubernetes, que ce soit depuis la ligne de commande, un tableau de bord ou un script automatisé passe par le serveur d'API.

Il authentifie votre requête, vérifie si vous êtes autorisé à faire ce que vous demandez, puis la transmet au bon endroit. Rien ne se passe dans Kubernetes sans passer d'abord par le serveur d'API. Vient ensuite le planificateur qui décide quel nœud exécute chaque pod. Lorsque vous dites Gachadardic en mai je veux que cette application soit en cours d'exécution et gomme, le planificateur examine tous les nœuds disponibles, vérifie les ressources disponibles comme le processeur, la mémoire et l'espace disque et choisit le meilleur pour la tâche. C'est comme un directeur d'hôtel qui attribue des chambres en fonction des besoins de chaque client. Un client avec beaucoup de bagages obtient une chambre plus grande, tandis qu'une application légère obtient un nœud plus petit avec de la capacité de réserve. Ensuite il y a le gestionnaire de contrôleur. Ce composant surveille le cluster et s'assure que l'état réel correspond à ce que vous avez déclaré.

Vous avez dit que vous vouliez que 3 copies de votre application web soient en cours d'exécution. Le gestionnaire de contrôleur vérifie qu'il y a effectivement 3 copies en cours d'exécution. Si l'une d'entre elles plante, il le remarque et lance un remplacement. Si quelqu'un supprime accidentellement un pod, il en crée un nouveau. C'est le composant qui maintient votre cluster honnête. Et enfin il y a XCD qui est la base de données du cluster. Il stocke tout comme ce qui est en cours d'exécution, où cela s'exécute et comment c'est configuré. C'est la source de vérité pour l'ensemble du cluster. Si le serveur d'API est la porte d'entrée, XCDD, et le classeur dans le back-office où sont conservés tous les enregistrements, l'avantage de cette conception est que vous décrivez ce que vous voulez, et Kubernetes trouve comment le concrétiser. Vous ne lui dites pas comment faire les choses, vous lui dites à quoi devrait ressembler le résultat final.

C'est le modèle déclaratif, et c'est l'idée centrale qui sous-tend tout ce que fait Kubernetes. Charge de travail, déploiement, service et mise à l'échelle. Parlons donc de la manière dont vous exécutez réellement les applications sur Kubernetes. Vous ne créerez pas de pod directement. A la place, vous utiliserez un objet de niveau supérieur, appelé déploiement. Considérez un déploiement comme un gestionnaire qui indique à Kubernetes combien de copies de votre pod doivent s'exécuter, quelle image de conteneur, utilisée, et comment les mettre à jour lorsqu'une nouvelle version sort. C'est la manière standard d'exécuter des applications sans état. Lorsque vous mettez à jour un déploiement, par exemple en poussant une nouvelle version de votre application, Kubernetes effectue une mise à jour progressive. Il remplace les pods un par un en s'assurant comment une copie est toujours en cours d'exécution.

Cela signifie qu'il n'y a pas de temps d'arène ni d'interruption soudaine pour vos utilisateurs. Si quelque chose ne va pas avec la nouvelle version, vous pouvez revenir à la version précédente avec une seule commande. C'est un filet de sécurité puissant. Mais vos pods doivent toujours être accessibles. C'est là qu'interviennent les services. Un service fournit une adresse réseau stable qui achemine le trafic vers les bons pods. Il peut également exposer ces pods à d'autres parties de votre application ou au monde extérieur. Un service peut être interne, accessible uniquement au sein du cluster, ou externe, avec une adresse IP publique que les utilisateurs peuvent atteindre depuis Internet. Voici maintenant ce qu'il faut savoir sur la mise à l'échelle. Kubernetes peut automatiquement faire croître et réduire votre application en fonction de la demande. Vous définissez un objectif, disons 70% d'utilisation du processeur, et Kubernetes ajoute des pods lorsque l'utilisation dépasse ce seuil et les supprime lorsqu'elle diminue.

Votre application augmente son envergure en cas de pic de trafic et la réduit lorsque les choses se calment. Aucune intervention manuelle n'est nécessaire. Mais toute cette puissance s'accompagne d'une certaine complexité. Si vous gérez votre propre cluster Kubernetes, vous êtes responsable du plan de contrôle, des mises à niveau, des correctifs de sécurité et des sauvegardes. Vous avez besoin d'une expertise approfondie pour gérer les défaillances de nœuds, la configuration du réseau et la mise à l'échelle du cluster. De nombreuses équipes passent plus de temps à gérer le cluster qu'à créer des applications. Et c'est là qu'intervient Kubernetes géré. Kubernetes autogéré ou géré ? Parlons donc de la réalité de l'exécution de Kubernetes par vous-même. Lorsque vous configurez votre propre cluster, vous êtes responsable de tout. Le plan de contrôle, les mises à niveau, les correctifs de sécurité et les sauvegardes de TCD.

Si le serveur d'API tombe en panne, c'est votre problème. Si une faille de sécurité est découverte dans la version que vous exécutez, vous devez la corriger. Si ETCD est corrompu, vous devez restaurer à partir d'une sauvegarde. Tout cela nécessite une expertise approfondie. Vous devez comprendre comment les nœuds tombent en panne, comment fonctionne la mise en réseau au niveau du cluster et comment faire évoluer les choses sans les casser. Voici ce qui surprend beaucoup d'équipes. De nombreuses organisations passent plus de temps à gérer leur cluster Kubernetes qu'à créer des applications qui s'exécutent dessus. Sont constamment en proie à des problèmes de mise à niveau, de résolution des problèmes de réseau et de gestion des défaillances de nœuds. Le cluster devient un travail à temps plein. Ce n'est pas la raison pour laquelle vous avez adopté Kubernetes en premier lieu. C'est là qu'interviennent les services Kubernetes gérés.

Des services tels qu'Azure Kubernetes Service ou AKS gèrent le plan de contrôle à votre place, GS. Azure gère le serveur d'API, EXCD, le planificateur et le gestionnaire de contrôleur. Vous n'avez pas à vous soucier de les corriger ou de les maintenir en fonctionnement. Vous payez uniquement pour les nœuds de travail, des machines virtuelles qui exécutent vos charges de travail. Le plan de contrôle lui-même est gratuit. Cela change radicalement la donne. Au lieu de consacrer votre temps à la maintenance du cluster, votre équipe peut se concentrer sur ce qui compte vraiment, les applications que vous créez. Pour la plupart des équipes, en particulier celles qui débutent, Kubernetes gérée est le bon choix. Vous bénéficiez de toute la puissance de Kubernetes sans les frais généraux d'exploitation. AKS, Kubernetes simplifié sur Azure. Qu'est-ce qu'AKS exactement ? Il s'agit du service Kubernetes géré par Azure qui vous offre un cluster complet sans avoir à le créer de toute pièce.

Le plan de contrôle est gratuit comme nous l'avons mentionné, vous ne payez donc que pour les machines virtuelles exécutant vos charges de travail. Cela signifie que vous pouvez commencer petit, payer très peu et évoluer à mesure que vos besoins augmentent. Azure s'occupe de tout le travail lourd. Les mises à niveau, les correctifs et la surveillance de l'état du plan de contrôle sont tous pris en charge. Vous n'avez pas besoin d'une équipe dédiée d'experts Kubernetes pour que tout fonctionne correctement. Et comme AKS fait partie de l'écosystème Azure, il s'intègre aux outils que vous utilisez probablement déjà. Azure Active Directory pour l'authentification, Azure Monitor pour la journalisation et les métriques et Azure Policy pour la gouvernance. Ils fonctionnent tous ensemble dès le départ. Pas besoin d'ajouter des éléments distincts. La configuration de pipeline CICD avec GitHub Actions ou Azure DevOps ne prend que quelques minutes.

Envoyez une modification à votre référentiel et il crée automatiquement une nouvelle image de conteneur, la transmet à Azure Container Registry et met à jour votre déploiement sur AKS. Aucune étape manuelle, pas de connexion SSH au serveur, tout est automatisé. Pour les débutants, il existe le mode automatique AKS conçu pour les équipes qui ne souhaitent pas prendre toutes les décisions concernant la configuration du cluster. Il fournit des paramètres par défaut prêts à l'emploi pour la mise à l'échelle, la mise en réseau, la sécurité et les mises à nuit. Vous n'avez pas besoin de devenir un expert Kubernetes pour commencer. Décrivez simplement votre application et AKS s'occupe du reste. Une commande vous donne un cluster, un fichier manifeste lance votre application. Les compétences acquises sur AKS sont transférables à n'importe quel environnement Kubernetes car il s'agit d'une version standard de Kubernetes.

Vous n'apprenez pas un système propriétaire, vous apprenez la vraie chose avec Azure qui gère la complexité opérationnelle. Vous avez désormais une vue d'ensemble. Les conteneurs impactent vos applications afin qu'elles s'exécutent de manière cohérente partout et Kubernetes orchestre ses conteneurs à grande échelle en gérant automatiquement le déploiement, la mise à l'échelle et la récupération. AKS rend cette orchestration gérable en prenant en charge le plan de contrôle et en s'intégrant aux outils Azure que vous connaissez déjà. Le point essentiel est le suivant. Kubernetes n'est pas réservé aux grandes entreprises technologiques dotées d'équipes d'ingénieurs massifs. Avec des services gérés comme AKS, il est accessible à toutes les équipes. Vos devoirs pour cette semaine sont simples. Créer un compte Azure gratuit, lancer un cluster AKS et déployer une application simple. Cela ne prend que quelques minutes et vous verrez à quel point la plateforme a évolué.

Prêt à aller plus loin ? Le prochain épisode explique comment créer votre première image de conteneur et la transférer vers Azure Container Registry. Abonnez-vous sur votre plateforme de podcast préférée et partagez cet épisode avec quelqu'un qui débute son parcours avec Kubernetes.