Concepts Kubernetes

Déployer des applications sur plusieurs machines (à l’aide de conteneurs déployés dans des pods)

Surveiller l’état des conteneurs et redémarrer ceux qui ont échoué

Augmenter ou réduire la taille des conteneurs en fonction de la charge

Mettre à jour les conteneurs avec les nouvelles versions

Répartir les ressources entre les conteneurs

Équilibrer le trafic entre les machines

Conteneurisé — Kubernetes est un outil d’orchestration de conteneurs. Pour utiliser Kubernetes, vous devez d’abord conteneuriser vos applications. Selon le type d’application, il peut s’agir d’un ensemble de microservices, de tâches par lots ou d’autres formes. Vos applications peuvent alors tirer parti d’un workflow Kubernetes qui englobe un vaste écosystème d’outils, où les conteneurs peuvent être stockés sous forme d’images dans un registre de conteneurs, déployés sur un cluster Kubernetes et exécutés sur un nœud disponible. Vous pouvez créer et tester des conteneurs individuels sur votre ordinateur local avec Docker ou une autre exécution de conteneurs, avant de les déployer sur votre cluster Kubernetes.

Évolutif : si la demande pour vos applications dépasse la capacité des instances en cours d’exécution de ces applications, Kubernetes est en mesure d’augmenter verticalement. Au besoin, Kubernetes peut déterminer si les applications ont besoin de plus de CPU ou de mémoire et réagir en augmentant automatiquement la capacité disponible ou en utilisant davantage la capacité existante. La mise à l’échelle peut être effectuée au niveau du pod, s’il y a suffisamment de puissance de calcul disponible pour exécuter davantage d’instances de l’application (mise à l’échelle automatique horizontale des pods), ou au niveau du nœud, si davantage de nœuds doivent être activés pour gérer l’augmentation de capacité (Cluster Autoscaler ou Karpenter). Comme la capacité n’est plus nécessaire, ces services peuvent supprimer les pods inutiles et arrêter les nœuds superflus.

Disponible : si une application ou un nœud devient défaillant ou indisponible, Kubernetes peut déplacer les charges de travail en cours vers un autre nœud disponible. Vous pouvez forcer la question en supprimant simplement une instance en cours d’exécution d’une charge de travail ou d’un nœud qui exécute vos charges de travail. En résumé, cela signifie que les charges de travail peuvent être transférées vers d’autres emplacements si elles ne peuvent plus être exécutées là où elles se trouvent.

Déclaratif — Kubernetes utilise la réconciliation active pour vérifier en permanence que l’état que vous déclarez pour votre cluster correspond à l’état réel. En appliquant des objets Kubernetes à un cluster, généralement via des fichiers de configuration au format YAML, vous pouvez, par exemple, demander le démarrage des charges de travail que vous souhaitez exécuter sur votre cluster. Vous pouvez modifier ultérieurement les configurations pour, par exemple, utiliser une version plus récente d’un conteneur ou allouer davantage de mémoire. Kubernetes fera le nécessaire pour établir l’état souhaité. Cela peut inclure la mise en service ou la mise hors service de nœuds, l’arrêt et le redémarrage de charges de travail, ou le retrait de conteneurs mis à jour.

Composable : Étant donné qu’une application se compose généralement de plusieurs composants, vous souhaitez pouvoir gérer ensemble un ensemble de ces composants (souvent représentés par plusieurs conteneurs). Alors que Docker Compose offre un moyen de le faire directement avec Docker, la commande Kubernetes Kompose peut vous aider à le faire avec Kubernetes. Consultez Traduire un fichier Docker Compose vers Kubernetes Resources pour obtenir un exemple de la manière de procéder.

Extensible : Contrairement aux logiciels propriétaires, le projet open source Kubernetes est conçu pour vous permettre d’étendre Kubernetes comme vous le souhaitez afin de répondre à vos besoins. Les API et les fichiers de configuration sont ouverts aux modifications directes. Les tiers sont encouragés à écrire leurs propres contrôleurs afin d’étendre à la fois l’infrastructure et les fonctionnalités Kubernetes destinées aux utilisateurs finaux. Les webhooks vous permettent de configurer des règles de cluster afin d’appliquer des politiques et de vous adapter à des conditions changeantes. Pour plus d’idées sur la manière d’étendre les clusters Kubernetes, consultez la section Étendre Kubernetes.

Portable : De nombreuses organisations ont standardisé leurs opérations sur Kubernetes, car cela leur permet de gérer tous leurs besoins applicatifs de la même manière. Les développeurs peuvent utiliser les mêmes pipelines pour créer et stocker des applications conteneurisées. Ces applications peuvent ensuite être déployées sur des clusters Kubernetes fonctionnant sur site, dans le cloud, sur des terminaux de point de vente dans les restaurants ou sur des appareils IoT dispersés sur les sites distants de l’entreprise. Sa nature open source permet aux utilisateurs de développer ces distributions Kubernetes spécialisées, ainsi que les outils nécessaires à leur gestion.

Matériel : Si vous ne disposez pas du matériel nécessaire pour exécuter Kubernetes conformément à vos exigences, un fournisseur de services cloud tel que AWS Amazon EKS peut vous permettre de réduire vos coûts initiaux. Avec Amazon EKS, cela signifie que vous pouvez utiliser les meilleures ressources cloud proposées par AWS, notamment des instances informatiques (Amazon Elastic Compute Cloud), votre propre environnement privé (Amazon VPC), la gestion centralisée des identités et des autorisations (IAM) et le stockage (Amazon EBS). AWS gère les ordinateurs, les réseaux, les centres de données et tous les autres composants physiques nécessaires au fonctionnement de Kubernetes.c De même, vous n’avez pas besoin de planifier votre centre de données pour qu’il puisse gérer la capacité maximale lors des jours où la demande est la plus forte. Pour Amazon EKS Anywhere ou d’autres clusters Kubernetes sur site, vous êtes responsable de la gestion de l’infrastructure utilisée dans vos déploiements Kubernetes, mais vous pouvez toujours compter sur AWS pour vous aider à maintenir Kubernetes à jour.

Gestion du plan de contrôle : Amazon EKS gère la sécurité et la disponibilité du plan de contrôle Kubernetes hébergé par AWS, qui est chargé de planifier les conteneurs, de gérer la disponibilité des applications et d’autres tâches clés, afin que vous puissiez vous concentrer sur vos charges de travail applicatives. Si votre cluster tombe en panne, AWS doit disposer des moyens nécessaires pour le restaurer et le remettre en état de fonctionnement. Pour Amazon EKS Anywhere, vous devez gérer vous-même le plan de contrôle.

Mises à niveau testées : Lorsque vous mettez à niveau vos clusters, vous pouvez compter sur Amazon EKS ou Amazon EKS Anywhere pour fournir des versions testées de leurs distributions Kubernetes.

Extensions : Il existe des centaines de projets conçus pour étendre et fonctionner avec Kubernetes que vous pouvez ajouter à l’infrastructure de votre cluster ou utiliser pour faciliter l’exécution de vos charges de travail. Au lieu de créer et de gérer vous-même ces modules complémentaires, AWS fournit Modules complémentaires Amazon EKS que vous pouvez utiliser avec vos clusters. Amazon EKS Anywhere propose des packages sélectionnés qui incluent des versions de nombreux projets open source populaires. Vous n’avez donc pas à créer vous-même le logiciel ni à gérer les correctifs de sécurité critiques, les corrections de bogues ou les mises à niveau. De même, si les valeurs par défaut répondent à vos besoins, il est courant que très peu de configuration de ces modules complémentaires soient nécessaires. Consultez Extension des clusters pour plus de détails sur l’extension de votre cluster avec des modules complémentaires.

Plan de contrôle géré : AWS garantit la disponibilité et l’évolutivité du cluster Amazon EKS, car il gère le plan de contrôle à votre place et le rend disponible dans toutes les zones de disponibilité AWS.

Gestion des nœuds : Au lieu d’ajouter manuellement des nœuds, vous pouvez demander à Amazon EKS de créer automatiquement des nœuds selon vos besoins, à l’aide de groupes de nœuds gérés (voir Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés) ou de Karpenter. Les groupes de nœuds gérés sont intégrés à Kubernetes Cluster Autoscaling. Grâce aux outils de gestion des nœuds, vous pouvez réaliser des économies, notamment grâce aux instances Spot et à la consolidation des nœuds, et bénéficier d’une disponibilité optimale, en utilisant les fonctionnalités Planification pour définir le déploiement des charges de travail et la sélection des nœuds.

Réseau de cluster : À l’aide de modèles CloudFormation, eksctl configure le réseau entre les composants du plan de contrôle et du plan de données (nœud) dans le cluster Kubernetes. Il met également en place des points d’accès permettant les communications internes et externes. Pour plus d’informations, consultez la section Démystifier la mise en réseau des clusters pour les composants master Amazon EKS. Les communications entre les pods dans Amazon EKS s’effectuent à l’aide des identités de pod Amazon EKS (voir Découvrir comment l’identité du pod Amazon EKS accorde aux pods l’accès aux services AWS), qui permettent aux pods d’exploiter les méthodes AWS cloud de gestion des informations d’identification et des autorisations.

Modules complémentaires : Amazon EKS vous évite d’avoir à créer et à ajouter des composants logiciels couramment utilisés pour prendre en charge les clusters Kubernetes. Par exemple, lorsque vous créez un cluster Amazon EKS à partir du AWS Management Console, il ajoute automatiquement les modules complémentaires Amazon EKS kube-proxy (Gérer kube-proxy dans les Clusters Amazon EKS), Amazon VPC CNI plug-in for Kubernetes (Attribuer des adresses IP aux pods avec Amazon VPC CNI) et CoreDNS (Gérer CoreDNS pour DNS dans les clusters Amazon EKS). Consultez Modules complémentaires Amazon EKS pour en savoir plus sur ces modules complémentaires, y compris la liste des modules disponibles.

Communication avec les composants du cluster (serveur API) : Le serveur API (kube-apiserver) expose l’API Kubernetes afin que les requêtes puissent être envoyées au cluster depuis l’intérieur et l’extérieur de celui-ci. En d’autres termes, les demandes d’ajout ou de modification des objets d’un cluster (Pods, Services, Nœuds, etc.) peuvent provenir de commandes externes, telles que les demandes d’exécution kubectl pour exécuter un Pod. De même, des requêtes peuvent être envoyées depuis le serveur API vers des composants au sein du cluster, comme une requête au service kubelet pour connaître l’état d’un pod.

Stocker les données relatives au cluster (stockage de valeurs clés etcd) : Le service etcd joue un rôle essentiel dans le suivi de l’état actuel du cluster. Si le service etcd devenait inaccessible, vous ne pourriez plus mettre à jour ou consulter l’état du cluster, mais les charges de travail continueraient à s’exécuter pendant un certain temps. Pour cette raison, les clusters critiques disposent généralement de plusieurs instances du service etcd fonctionnant simultanément avec équilibrage de charge et effectuent des sauvegardes périodiques du magasin de valeurs clés etcd en cas de perte ou de corruption des données. N’oubliez pas que, dans Amazon EKS, tout cela est géré automatiquement par défaut. Amazon EKS Anywhere fournit des instructions pour la sauvegarde et la restauration d’etcd. Consultez le modèle de données etcd pour savoir comment etcd gère les données.

Planifier des pods vers des nœuds (planificateur): Les demandes de démarrage ou d’arrêt d’un pod dans Kubernetes sont dirigées vers le planificateur Kubernetes (kube-scheduler). Étant donné qu’un cluster peut comporter plusieurs nœuds capables d’exécuter le pod, c’est au planificateur qu’il revient de choisir le ou les nœuds (dans le cas de réplicas) sur lesquels le pod doit s’exécuter. Si la capacité disponible est insuffisante pour exécuter le pod demandé sur un nœud existant, la demande échouera, sauf si vous avez pris d’autres dispositions. Ces dispositions pourraient inclure des services d’activation tels que Managed Node Groups (Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés) ou Karpenter, capables de démarrer automatiquement de nouveaux nœuds pour gérer les charges de travail.

Maintenir les composants dans l’état souhaité (Controller Manager) : Le Kubernetes Controller Manager s’exécute en tant que processus démon (kube-controller-manager) afin de surveiller l’état du cluster et d’apporter des modifications au cluster pour rétablir les états attendus. En particulier, plusieurs contrôleurs surveillent différents objets Kubernetes, notamment statefulset-controller, endpoint-controller, cronjob-controller, node-controller, et d’autres.

Gérer les ressources cloud (Cloud Controller Manager) : Les interactions entre Kubernetes et le fournisseur de cloud qui traite les demandes relatives aux ressources du centre de données sous-jacent sont gérées par le Cloud Controller Manager (cloud-controller-manager). Les contrôleurs gérés par Cloud Controller Manager peuvent inclure un contrôleur de routage (pour configurer les routes du réseau cloud), un contrôleur de service (pour utiliser les services d’équilibrage de charge cloud) et un contrôleur de cycle de vie des nœuds (pour synchroniser les nœuds avec Kubernetes tout au long de leur cycle de vie).

Gérer chaque nœud (kubelet) : Le serveur API communique avec le service kubelet exécuté sur chaque nœud afin de s’assurer que le nœud est correctement enregistré et que les pods demandés par le planificateur sont en cours d’exécution. Le kubelet peut lire les manifestes des pods et configurer les volumes de stockage ou d’autres fonctionnalités nécessaires aux pods sur le système local. Il peut également vérifier l’état des conteneurs gérés localement.

Exécuter des conteneurs sur un nœud (environnement d’exécution de conteneurs) : l’exécution de conteneurs sur chaque nœud gère les conteneurs demandés pour chaque pod attribué au nœud. Cela signifie qu’il peut extraire des images de conteneur du registre approprié, exécuter le conteneur, l’arrêter et répondre aux requêtes concernant le conteneur. L’exécution de conteneur par défaut est containerd. À partir de Kubernetes 1.24, l’intégration spéciale de Docker (dockershim) qui pouvait être utilisée comme exécution de conteneur a été supprimée de Kubernetes. Bien que vous puissiez toujours utiliser Docker pour tester et exécuter des conteneurs sur votre système local, pour utiliser Docker avec Kubernetes, vous devez désormais installer Docker Engine sur chaque nœud afin de pouvoir l’utiliser avec Kubernetes.

Gérer la mise en réseau entre les conteneurs (kube-proxy) : Afin de prendre en charge la communication entre les pods, Kubernetes utilise une fonctionnalité appelée Service pour configurer des réseaux de pods qui suivent les adresses IP et les ports associés à ces pods. Le service kube-proxy s’exécute sur chaque nœud pour permettre la communication entre les pods.

Une image de base : Une image de conteneur de base est un conteneur généralement construit à partir d’une version minimale du système de fichiers d’un système d’exploitation (tel que Red Hat Enterprise Linux ou Ubuntu) ou d’un système minimal amélioré pour fournir des logiciels permettant d’exécuter des types d’applications spécifiques (telles que les applications nodejs ou python).

Logiciel d’application : Vous pouvez ajouter votre logiciel d’application à votre conteneur de la même manière que vous l’ajouteriez à un système Linux. Par exemple, dans votre fichier Dockerfile, vous pouvez exécuter npm et yarn pour installer une application Java ou yum et dnf pour installer des paquets RPM. En d’autres termes, en utilisant une commande RUN dans un fichier Dockerfile, vous pouvez exécuter n’importe quelle commande disponible dans le système de fichiers de votre image de base pour installer ou configurer des logiciels à l’intérieur de l’image de conteneur résultante.

Instructions : La référence Dockerfile décrit les instructions que vous pouvez ajouter à un Dockerfile lorsque vous le configurez. Il s’agit notamment des instructions utilisées pour créer le contenu du conteneur lui-même (ou les fichiers ADD ou COPY du système local), identifier les commandes à exécuter lorsque le conteneur est lancé (CMD ou ENTRYPOINT), et connecter le conteneur au système sur lequel il s’exécute (en identifiant le USER sous lequel il doit s’exécuter, un local VOLUME à monter ou les ports à EXPOSE).

Stockage : lorsqu’un conteneur en cours d’exécution est arrêté et supprimé, les stockages de données dans ce conteneur disparaissent, sauf si vous configurez un stockage plus permanent. Kubernetes prend en charge de nombreux types de stockage différents et les regroupe sous l’appellation Volumes. Les types de stockage incluent CephFS, NFS,iSCSI et autres. Vous pouvez même utiliser un périphérique de stockage en mode bloc à partir de l’ordinateur local. Avec l’un de ces types de stockage disponibles dans votre cluster, vous pouvez monter le volume de stockage sur un point de montage sélectionné dans le système de fichiers de votre conteneur. Un volume persistant est un volume qui continue d’exister après la suppression du pod, tandis qu’un volume éphémère est supprimé lorsque le pod est supprimé. Si votre administrateur de cluster a créé différentes classes de stockage pour votre cluster, vous pouvez choisir les attributs du stockage que vous utilisez, par exemple si le volume est supprimé ou récupéré après utilisation, s’il s’étend si davantage d’espace est nécessaire, et même s’il répond à certaines exigences de performances.

Secrets : En rendant les secrets disponibles pour les conteneurs dans les spécifications Pod, vous pouvez fournir les autorisations dont ces conteneurs ont besoin pour accéder aux systèmes de fichiers, bases de données ou autres ressources protégées. Les clés, les mots de passe et les jetons font partie des éléments qui peuvent être stockés en tant que secrets. L’utilisation de secrets vous évite d’avoir à stocker ces informations dans des images de conteneur, mais vous devez simplement mettre les secrets à la disposition des conteneurs en cours d’exécution. ConfigMaps est similaire à Secrets. Une ConfigMap tendance à contenir moins d’informations critiques, telles que les paires clé-valeur pour la configuration d’un service.

Ressources de conteneur : Les objets permettant de configurer davantage les conteneurs peuvent prendre la forme d’une configuration de ressources. Pour chaque conteneur, vous pouvez demander la quantité de mémoire et de CPU qu’il peut utiliser, ainsi que fixer des limites quant à la quantité totale de ces ressources que le conteneur peut utiliser. Voir Gestion des ressources pour les pods et les conteneurs pour des exemples.

Interruptions : Les pods peuvent être perturbés involontairement (un nœud tombe en panne) ou volontairement (une mise à niveau est souhaitée). En configurant un budget de perturbation des pods, vous pouvez exercer un certain contrôle sur la disponibilité de votre application en cas de perturbation. Consultez la section Spécification d’un budget de perturbation pour votre application pour obtenir des exemples.

Espaces de noms : Kubernetes propose différentes méthodes pour isoler les composants et les charges de travail Kubernetes les uns des autres. L’exécution de tous les pods d’une application particulière dans le même espace de noms est une méthode courante pour sécuriser et gérer ces pods ensemble. Vous pouvez créer vos propres espaces de noms à utiliser ou choisir de ne pas indiquer d’espace de noms (ce qui oblige Kubernetes à utiliser l’espace de noms default). Les composants du plan de contrôle Kubernetes s’exécutent généralement dans l’espace de noms kube-system.

Applications sans état : Une application sans état n’enregistre pas les données de session d’un client, de sorte qu’une autre session n’a pas besoin de se référer à ce qui s’est passé lors d’une session précédente. Cela permet de remplacer plus facilement les pods par de nouveaux s’ils deviennent insalubres ou de les déplacer sans enregistrer leur état. Si vous exécutez une application sans état (telle qu’un serveur Web), vous pouvez utiliser un Déploiement pour déployer des Pods et des ReplicaSets. Un ReplicaSet définit le nombre d’instances d’un Pod que vous souhaitez exécuter simultanément. Bien que vous puissiez exécuter un ReplicaSet directement, il est courant d’exécuter des réplicas directement dans un déploiement, afin de définir le nombre de réplicas d’un pod qui doivent être exécutés simultanément.

Applications dynamiques : Une application avec état est une application dans laquelle l’identité du pod et l’ordre dans lequel les pods sont lancés sont importants. Ces applications ont besoin d’un stockage persistant stable qui doit être déployé et mis à l’échelle de manière cohérente. Pour déployer une application dynamique dans Kubernetes, vous pouvez utiliser StatefulSets. Une base de données est un exemple d’application généralement exécutée en tant que StatefulSet. Dans un StatefulSet, vous pouvez définir des réplicas, le pod et ses conteneurs, les volumes de stockage à monter et les emplacements dans le conteneur où les données sont stockées. Consultez Exécuter une application avec état répliquée pour obtenir un exemple de base de données déployée en tant que ReplicaSet.

Applications par nœud : Il arrive parfois que vous souhaitiez exécuter une application sur chaque nœud de votre cluster Kubernetes. Par exemple, votre centre de données peut exiger que chaque ordinateur exécute une application de surveillance ou un service d’accès à distance particulier. Pour Kubernetes, vous pouvez utiliser un DaemonSet pour vous assurer que l’application sélectionnée s’exécute sur tous les nœuds de votre cluster.

Les applications s’exécutent jusqu’à leur achèvement : Certaines applications doivent être exécutées pour accomplir une tâche particulière. Cela peut inclure un système qui publie des rapports d’état mensuels ou nettoie les anciennes données. Un objet Job peut être utilisé pour configurer une application afin qu’elle démarre et s’exécute, puis se ferme une fois la tâche terminée. Un objet CronJob vous permet de configurer une application pour qu’elle s’exécute à une heure, une minute, un jour du mois, un mois ou un jour de la semaine spécifiques, à l’aide d’une structure définie par le format crontab de Linux.

Services :Étant donné qu’un pod peut se déplacer vers différents nœuds et adresses, un autre pod qui doit communiquer avec le premier pod peut avoir des difficultés à le localiser. Pour résoudre ce problème, Kubernetes vous permet de représenter une application en tant que Service. Avec un service, vous pouvez identifier un pod ou un ensemble de pods avec un nom particulier, puis indiquer quel port expose le service de cette application à partir du pod et quels ports une autre application pourrait utiliser pour contacter ce service. Un autre pod au sein d’un cluster peut simplement demander un service par son nom, et Kubernetes dirigera cette demande vers le port approprié pour une instance du pod exécutant ce service.

Ingress : Ingress permet de mettre les applications représentées par les services Kubernetes à la disposition des clients situés en dehors du cluster. Les fonctionnalités de base d’Ingress comprennent un équilibreur de charge (géré par Ingress), le contrôleur Ingress et des règles pour acheminer les requêtes du contrôleur vers le service. Il existe plusieurs contrôleurs Ingress parmi lesquels vous pouvez choisir avec Kubernetes.

Démarrage avec Amazon EKS – eksctl

Création d’un cluster Amazon EKS

Déployer un exemple d’application sur Linux

Organiser et surveiller les ressources du cluster