Concepts Kubernetes

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

Surveillez l'état des conteneurs et redémarrez les conteneurs défaillants

Agrandir ou diminuer les conteneurs en fonction de la charge

Mettre à jour les conteneurs avec les nouvelles versions

Allouer des ressources entre les conteneurs

Équilibrez le trafic entre les machines

Containerized — Kubernetes est un outil d'orchestration de conteneurs. Pour pouvoir l'utiliserKubernetes, vous devez d'abord avoir conteneurisé 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 ensuite tirer parti d'un Kubernetes flux de travail qui englobe un vaste écosystème d'outils, dans lequel les conteneurs peuvent être stockés sous forme d'images dans un registre de conteneurs, déployés sur un Kubernetes cluster 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 sans autre environnement d'exécution de conteneur, avant de les déployer sur votre Kubernetes cluster.

Évolutif : si la demande pour vos applications dépasse la capacité des instances en cours d'exécution de ces applications, Kubernetes vous pouvez augmenter votre capacité. Le cas échéant, Kubernetes peut déterminer si les applications ont besoin de plus CPU de mémoire et réagir en augmentant automatiquement la capacité disponible ou en utilisant une plus grande partie de la capacité existante. Le dimensionnement peut être effectué au niveau du pod, s'il y a suffisamment de calcul disponible pour exécuter un plus grand nombre d'instances de l'application (scalage automatique du pod horizontal), ou au niveau du nœud, si davantage de nœuds doivent être créé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 inutiles.

Disponible : si une application ou un nœud ne fonctionne plus correctement ou n'est plus disponible, Kubernetes vous pouvez déplacer les charges de travail en cours vers un autre nœud disponible. Vous pouvez résoudre le problème 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 fin de compte, les charges de travail peuvent être transférées sur d'autres sites si elles ne peuvent plus fonctionner 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 Kubernetesdes objets à un cluster, généralement par le biais de fichiers de configuration au YAML format, vous pouvez, par exemple, demander de démarrer les charges de travail que vous souhaitez exécuter sur votre cluster. Vous pouvez ultérieurement modifier les configurations pour utiliser une version ultérieure d'un conteneur ou allouer plus de mémoire, par exemple. Kubernetesfera ce qu'il faut pour établir l'état souhaité. Cela peut inclure l'augmentation ou la désactivation des nœuds, l'arrêt et le redémarrage des charges de travail ou le retrait de conteneurs mis à jour.

Composable : étant donné qu'une application est généralement composée de plusieurs composants, vous souhaitez être en mesure de gérer ensemble un ensemble de ces composants (souvent représentés par plusieurs conteneurs). Bien que Docker Compose offre un moyen de le faire directement avecDocker, la commande Kubernetes Kompose peut vous aider à le faire avecKubernetes. Voir Translate a Docker Compose File to Kubernetes Resources pour un exemple de procédure à suivre.

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

Portable — De nombreuses entreprises ont standardisé leurs opérations, Kubernetes car cela leur permet de gérer tous leurs besoins en matière d'applications 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 Kubernetes clusters exécutés sur site, dans le cloud, sur des point-of-sales terminaux de restaurants ou sur des IOT appareils dispersés sur les sites distants de l'entreprise. Sa nature open source permet aux utilisateurs de développer ces Kubernetes distributions spéciales, ainsi que les outils nécessaires pour les gérer.

Matériel — Si vous ne disposez pas de matériel adapté à vos Kubernetes besoins, un fournisseur de cloud tel qu' AWS Amazon EKS peut vous faire économiser sur les coûts initiaux. Avec AmazonEKS, cela signifie que vous pouvez utiliser les meilleures ressources cloud proposées AWS, notamment les instances informatiques (Amazon Elastic Compute Cloud), votre propre environnement privé (AmazonVPC), la gestion centralisée des identités et des autorisations (IAM) et le stockage (AmazonEBS). AWS gère les ordinateurs, les réseaux, les centres de données et tous les autres composants physiques nécessaires au fonctionnementKubernetes. De même, vous n'avez pas à planifier votre centre de données de manière à gérer la capacité maximale les jours où la demande est la plus forte. Pour Amazon EKS Anywhere ou d'autres Kubernetes clusters sur site, vous êtes responsable de la gestion de l'infrastructure utilisée dans vos Kubernetes déploiements, mais vous pouvez toujours compter sur vous AWS pour vous aider à rester Kubernetes à jour.

Gestion du plan de contrôle : Amazon EKS gère la sécurité et la disponibilité du plan de Kubernetes contrôle AWS hébergé, 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 les charges de travail de vos applications. Si votre cluster tombe en panne, vous AWS devriez avoir les moyens de rétablir son é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 Kubernetes distributions.

Modules complémentaires : il existe des centaines de projets conçus pour être étendus et Kubernetes compatibles. Vous pouvez les ajouter à l'infrastructure de votre cluster ou les 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, vous pouvez proposer AWS des EKSmodules complémentaires Amazon 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. Voir Étendre les 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 EKS cluster Amazon, car il gère le plan de contrôle pour vous et le rend disponible dans toutes les zones de AWS disponibilité.

Gestion des nœuds — Au lieu d'ajouter manuellement des nœuds, vous pouvez demander à Amazon de EKS créer des nœuds automatiquement selon vos besoins, à l'aide de Managed Node Groups ou de Karpenter. Les groupes de nœuds gérés sont intégrés à Kubernetes Cluster Autoscaling. À l'aide des outils de gestion des nœuds, vous pouvez réaliser des économies, notamment grâce aux instances Spot, à la consolidation et à la disponibilité des nœuds, en utilisant les fonctionnalités de planification pour définir la manière dont les charges de travail sont déployées et les nœuds sélectionnés.

Mise en réseau du cluster : à l'aide de CloudFormation modèles, eksctl configure la mise en réseau entre les composants du plan de contrôle et du plan de données (nœud) du Kubernetes cluster. Il met également en place des points de terminaison par lesquels les communications internes et externes peuvent avoir lieu. Consultez Démystifier le réseau de clusters pour les nœuds de EKS travail Amazon pour plus de détails. Les communications entre Pods sur Amazon EKS sont effectuées à l'aide d'Amazon EKS Pod Identities, qui permet aux Pods de tirer parti des méthodes AWS cloud de gestion des informations d'identification et des autorisations.

Modules complémentaires : Amazon vous EKS évite d'avoir à créer et à ajouter des composants logiciels couramment utilisés pour prendre en charge les Kubernetes clusters. Par exemple, lorsque vous créez un EKS cluster Amazon à partir de la console de AWS gestion, celui-ci ajoute automatiquement le EKS proxy Amazon kubeKubernetes, le VPC CNI plugin Amazon pour et les modules complémentaires Core DNS. Consultez les EKSmodules complémentaires Amazon pour en savoir plus sur ces modules complémentaires, y compris la liste des modules disponibles.

Communication avec les composants du cluster (APIserveur) — Le API serveur (kube-apiserver) expose le cluster afin que les demandes Kubernetes API puissent être faites à la fois depuis l'intérieur et l'extérieur du cluster. 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 des demandes kubectl d'exécution d'un pod. De même, des demandes peuvent être adressées par le API serveur aux composants du cluster, par exemple une requête au kubelet service concernant l'état d'un Pod.

Stocker les données relatives au cluster (magasin de valeurs etcd clés) : le etcd service joue un rôle essentiel dans le suivi de l'état actuel du cluster. Si le etcd service devenait inaccessible, vous ne pourriez pas mettre à jour ou demander l'état du cluster, même si 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 équilibrées du etcd service exécutées simultanément et effectuent des sauvegardes périodiques de la banque de valeurs etcd clés en cas de perte ou de corruption de données. N'oubliez pas que, sur AmazonEKS, tout cela est géré automatiquement par défaut. Amazon EKS Anywhere fournit des instructions pour la sauvegarde et la restauration etcd. Consultez le modèle de etcd données pour savoir comment etcd gérer les données.

Planifier des pods vers des nœuds (planificateur) : les demandes de démarrage ou d'arrêt d'un pod Kubernetes sont dirigées vers le planificateur (Kuberneteskube-scheduler). Comme un cluster peut comporter plusieurs nœuds capables d'exécuter le Pod, il appartient au planificateur de choisir sur quel nœud (ou quels nœuds, dans le cas de répliques) 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 les groupes de nœuds gérés ou Karpenter qui peuvent automatiquement démarrer 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 comme un processus daemon (kube-controller-manager) pour surveiller l'état du cluster et apporter des modifications au cluster afin de rétablir les états attendus. En particulier, plusieurs contrôleurs surveillent différents Kubernetes objets, notamment astatefulset-controller,, endpoint-controller cronjob-controllernode-controller, et d'autres.

Gérer les ressources du cloud (Cloud Controller Manager) : les interactions entre le fournisseur de cloud Kubernetes et le fournisseur de cloud qui exécute 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 le Cloud Controller Manager peuvent inclure un contrôleur de route (pour configurer les routes du réseau cloud), un contrôleur de service (pour utiliser les services d'équilibrage de charge dans le cloud) et un contrôleur du cycle de vie des nœuds (pour maintenir les nœuds synchronisés avec Kubernetes tout au long de leur cycle de vie).

Gérer chaque nœud (kubelet) — Le API serveur communique avec le service kubelet exécuté sur chaque nœud pour s'assurer que le nœud est correctement enregistré et que les pods demandés par le planificateur fonctionnent. Le kubelet peut lire les manifestes des pods et configurer des 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 (runtime de conteneur) : le Container Runtime de chaque nœud gère les conteneurs demandés pour chaque pod attribué au nœud. Cela signifie qu'il peut extraire les images du conteneur du registre approprié, exécuter le conteneur, l'arrêter et répondre aux requêtes concernant le conteneur. Le runtime du conteneur par défaut est containerd. À partir de la Kubernetes version 1.24, l'intégration spéciale de Docker (dockershim) qui pouvait être utilisée comme environnement d'exécution du conteneur a été suppriméeKubernetes. Bien que vous puissiez toujours l'utiliser Docker pour tester et exécuter des conteneurs sur votre système local, Kubernetes vous devez désormais installer le Docker moteur sur chaque nœud pour l'utiliserKubernetes. Docker

Gérer le réseau entre les conteneurs (kube-proxy) — Pour pouvoir prendre en charge la communication entre les pods à l'aide des services, Kubernetes il fallait un moyen de configurer les réseaux de pods pour suivre 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 créé à 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 (tels que des 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 Dockerfile, vous pouvez exécuter npm et yarn installer une application Java ou dnf installer yum RPM des packages. En d'autres termes, à l'aide d'une RUN commande dans un Dockerfile, vous pouvez exécuter n'importe quelle commande disponible dans le système de fichiers de votre image de base pour installer un logiciel ou configurer un logiciel à l'intérieur de l'image de conteneur obtenue.

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 (ADDou des COPY fichiers provenant du système local), identifier les commandes à exécuter lorsque le conteneur est exécuté (CMDouENTRYPOINT) et connecter le conteneur au système sur lequel il s'exécute (en identifiant le USER conteneur sous lequel exécuter, un local VOLUME à monter ou les ports vers lesquelsEXPOSE).

Stockage — Lorsqu'un conteneur en cours d'exécution est arrêté et supprimé, le stockage des données dans ce conteneur disparaît, sauf si vous configurez un stockage plus permanent. Kubernetesprend en charge de nombreux types de stockage différents et les regroupe sous l'égide de Volumes. Les types de stockage incluent CephFS NFSSCSI, i et autres. Vous pouvez même utiliser un périphérique de blocage local depuis l'ordinateur local. L'un de ces types de stockage étant disponible sur 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éé une solution différente StorageClassespour 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 sera étendu si davantage d'espace est nécessaire, et même s'il répond à certaines exigences de performance.

Secrets — En mettant les secrets à la disposition des conteneurs dans les spécifications du Pod, vous pouvez fournir les autorisations dont ces conteneurs ont besoin pour accéder aux systèmes de fichiers, aux bases de données ou à d'autres actifs protégés. 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 conteneurs, mais vous n'avez qu'à les mettre à la disposition des conteneurs en cours d'exécution. Similaire à Secrets are ConfigMaps. A ConfigMap a tendance à contenir des informations moins critiques, telles que les paires clé-valeur pour configurer 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 CPU qu'il peut utiliser, ainsi que fixer des limites à 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 d'interruption du Pod, vous pouvez exercer un certain contrôle sur la disponibilité de votre application en cas de perturbations. Consultez la section Spécification d'un budget d'interruption pour votre application pour des exemples.

Espaces de noms : Kubernetes propose différentes méthodes pour isoler les Kubernetes composants et les charges de travail 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 entraîne l'utilisation de l'espace Kubernetes de default noms). Kubernetesles composants du plan de contrôle s'exécutent généralement dans l'espace de kube-systemnoms.

Applications sans état : une application sans état n'enregistre pas les données de session d'un client. Une autre session n'a donc 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 ReplicaSets. A ReplicaSet définit le nombre d'instances d'un Pod que vous souhaitez exécuter simultanément. Bien que vous puissiez exécuter un pod ReplicaSet directement, il est courant d'exécuter des répliques directement dans un déploiement, afin de définir le nombre de répliques d'un pod à exécuter à la fois.

Applications dynamiques — Une application dynamique 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 dansKubernetes, vous pouvez utiliser StatefulSets. Une base de données est un exemple d'application généralement exécutée en tant StatefulSet que. Dans un StatefulSet, vous pouvez définir les répliques, le Pod et ses conteneurs, les volumes de stockage à monter et les emplacements dans le conteneur où les données sont stockées. Voir Exécuter une application dynamique répliquée pour un exemple de déploiement d'une base de données en tant que. ReplicaSet

Applications par nœud : il arrive que vous souhaitiez exécuter une application sur chaque nœud de votre Kubernetes cluster. 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 spécifique. En Kubernetes effet, vous pouvez utiliser a DaemonSetpour 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'à la fin : vous souhaitez exécuter certaines applications pour effectuer 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 qu'elle se ferme une fois la tâche terminée. Un CronJobobjet vous permet de configurer une application pour qu'elle s'exécute à une heure, une minute, un jour du mois ou un jour de la semaine spécifiques, en utilisant une structure définie par le crontabformat Linux.

Services — Étant donné qu'un Pod peut se déplacer vers différents nœuds et adresses, un autre Pod ayant besoin de communiquer avec le premier Pod peut avoir du mal à le trouver. Pour résoudre ce problème, vous Kubernetes 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 depuis le 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 redirigera cette demande vers le port approprié pour une instance du Pod exécutant ce service.

Entrée — L'entrée permet de mettre les applications représentées par Kubernetes des services à la disposition des clients extérieurs au cluster. Les fonctionnalités de base d'Ingress incluent un équilibreur de charge (géré par Ingress), le contrôleur Ingress et des règles de routage des demandes du contrôleur vers le Service. Il existe plusieurs contrôleurs d'entrée parmi lesquels vous pouvez choisir. Kubernetes

Création d'un cluster simple

Création d'un cluster plus complexe

Déployer un exemple d'application

Découvrez les moyens de gérer votre cluster