This glossary is intended to be a comprehensive, standardized list of Kubernetes terminology. It includes technical terms that are specific to Kubernetes, as well as more general terms that provide useful context.
Filter terms according to their tags
Click on the [+] indicators below to get a longer explanation for any particular term.
cAdvisor (Container Advisor) offre aux utilisateurs de conteneurs une compréhension de l'utilisation des ressources et des caractéristiques de performance de leurs conteneurs en cours d'exécution.
[+]C'est un démon en cours d'exécution qui collecte, agrège, traite et exporte des informations sur les conteneurs en cours d'exécution. Plus précisément, pour chaque conteneur, il conserve les paramètres d'isolation des ressources, l'historique de l'utilisation des ressources, les histogrammes de l'utilisation complète des ressources historiques et les statistiques réseau. Ces données sont exportées par conteneur et à l'échelle de la machine.
Un nœud est une machine de travail dans Kubernetes.
[+]Un nœud de travail peut être une machine virtuelle ou physique, selon le cluster. Il dispose de démons ou de services locaux nécessaires pour exécuter les Pods et est géré par le plan de contrôle. Les démons sur un nœud comprennent kubelet, kube-proxy, et un moteur d'exécution de conteneur implémentant le CRI tel que Docker.
Dans les premières versions de Kubernetes, les nœuds étaient appelés "Minions".
Gère les décisions d'autorisation, permettant aux administrateurs de configurer dynamiquement les politiques d'accès via l'API Kubernetes.
[+]RBAC utilise des rôles, qui contiennent des règles de permission, et des rôles de liaison, qui accordent les permissions définies dans un rôle à un ensemble d'utilisateurs.
Ressources qui étendent les fonctionnalités de Kubernetes.
[+]Installer des addons explique l'utilisation des modules complémentaires avec votre cluster et répertorie certains modules complémentaires populaires.
Un morceau de code qui intercepte les requêtes adressées au serveur API de Kubernetes avant la persistance de l'objet.
[+]Les contrôleurs d'accès sont configurables pour le serveur API de Kubernetes. Un contrôleur d'accès peut être "validant" ("validating"), "modifiant" ("mutating"), ou les deux. Tout contrôleur d'accès peut rejeter la demande. Les contrôleurs modifiant peuvent modifier les objets qu'ils admettent ; alors que les contrôleurs validants ne le peuvent pas.
Dans Kubernetes, l’affinity est un ensemble de règles qui donnent des indications à l’ordonnanceur quant à l’emplacement des pods.
[+]Il existe deux types d’affinité :
Ces règles sont définies à l’aide des labels Kubernetes,
et des sélecteurs spécifiés dans les pods.
Elles peuvent être obligatoires ou préférentielles, selon la rigueur avec laquelle vous souhaitez que l’ordonnanceur les applique.
La couche d'agrégation vous permet d'installer des API supplémentaires de type Kubernetes dans votre cluster.
[+]Après avoir configuré Kubernetes API Server pour support additional APIs, vous pourrez ajouter des objects APIService afin de "réclamer" un chemin URL dans l'API Kubernetes.
Fonctionnalité Kubernetes permettant de demander et de partager des ressources entre les Pods.
Ces ressources sont souvent des devices, comme des accélérateurs matériels.
Avec DRA, les pilotes de périphériques et les administrateurs de cluster définissent des classes de périphériques disponibles à revendiquer dans les charges de travail. Kubernetes attribue les périphériques correspondants aux ResourceClaims et place les Pods correspondants sur les nœuds pouvant accéder aux périphériques alloués.
Une paire clé-valeur qui est utilisée pour attacher des métadonnées arbitraires non-identifiantes à des objets.
[+]Les métadonnées d'une annotation peuvent être petites ou grandes, structurées ou non structurées, et peuvent inclure des caractères non autorisés par les étiquettes. Les clients tels que les outils et les librairies peuvent récupérer ces métadonnées.
L'application qui offre les fonctionnalités de Kubernetes via une interface RESTful et stocke l'état du cluster.
[+]Les ressources Kubernetes et les "enregistrements d'intention" sont tous stockés sous forme d'objets API et modifiés via des appels RESTful à l'API. L'API permet de gérer la configuration de manière déclarative. Les utilisateurs peuvent interagir directement avec l'API Kubernetes ou via des outils tels que kubectl. L'API principale de Kubernetes est flexible et peut également être étendue pour prendre en charge des ressources personnalisées.
Les conteneurs d'application (ou conteneurs app) sont les containers dans un pod qui sont lancés après que les init containers soient terminés.
[+]Un conteneur d'initialisation vous permet de séparer les détails d'initialisation importants pour l'ensemble du workload workload, et qui n'ont pas besoin de continuer à fonctionner une fois que le conteneur d'application est démarré. Si un pod n'a pas d'init conteneurs configurés, tous les conteneurs de ce pod sont des conteneurs d'application.
La couche où s'exécutent diverses applications conteneurisées.
Personne pouvant passer en revue et approuver les contributions au code Kubernetes.
[+]Alors que l'examen du code est axé sur la qualité et l'exactitude de ce dernier, l'approbation est, quant à elle, axée sur l'acceptation globale d'une contribution. L'acceptation globale inclut entre autres, la (rétro-)comptabilité, le respect des conventions concernant l'API et les drapeaux, les problèmes subtils de performance et d'exactitude, ainsi que les interactions avec d'autres parties du système. Le statut d'approbateur est limité à une partie de la base de code. Auparavant, les approbateurs étaient appelés mainteneurs.
Personne responsable de la conception haut niveau d'une application.
[+]Un architecte s'assure que l'implémentation d'une application lui permet d'interagir avec ses composants environnants, de manière maintenable et déployable à grande échelle. Les composants environnants comprennent les bases de données, les infrastructures de logging et autres micro-services.
Personne qui conçoit une infrastructure impliquant un ou plusieurs clusters Kubernetes.
[+]Les architectes de cluster se préoccupent des bonnes pratiques pour les systèmes distribués, telle que la haute disponibilité et la sécurité par exemple.
Ancienne API d’extension permettant aux applications dans Kubernetes d’utiliser facilement des services managés externes, comme un service de base de données fourni par un cloud provider.
[+]Elle permettait de lister, provisionner et lier des Managed Services externes sans nécessiter de connaissances détaillées sur leur création ou gestion.
Un langage d’expression généraliste conçu pour être rapide, portable et sûr à exécuter.
[+]Dans Kubernetes, CEL peut être utilisé pour exécuter des requêtes et effectuer un filtrage fin.
Par exemple, vous pouvez utiliser des expressions CEL avec le contrôle d’admission dynamique pour filtrer certains champs dans les requêtes, et avec l’allocation dynamique de ressources (DRA) pour sélectionner des ressources en fonction d’attributs spécifiques.
Fichier cryptographiquement sécurisé utilisé pour valider l'accès au cluster Kubernetes.
[+]Les certificats permettent aux applications d'un cluster Kubernetes d'accéder à l'API Kubernetes en toute sécurité. Les certificats attestent que les clients sont autorisés à accéder à l'API.
Un groupe de processus Linux avec des options d'isolation, de suivi, et de limite de l'utilisation des ressources.
[+]cgroup est une fonctionnalité du noyau Linux qui limite, suit et isole l'utilisation des ressources (CPU, mémoire, E/S disque, réseau) pour un ensemble de processus.
Un ensemble de ressources Kubernetes préconfigurées qui peuvent être gérées avec l'outil Helm.
[+]Les Charts Helm fournissent un moyen reproductible de créer et de partager des applications Kubernetes. Un Chart peut être utilisé pour déployer quelque chose de simple, comme un Pod memcached, ou quelque chose de plus complexe, comme une application web complète avec des serveurs HTTP, des bases de données, des caches, etc.
CIDR (Classless Inter-Domain Routing) est une notation permettant de décrire des plages d’adresses IP, largement utilisée dans les configurations réseau.
[+]Dans le contexte de Kubernetes, chaque nœud se voit attribuer une plage d’adresses IP définie par une adresse de départ et un masque de sous-réseau en notation CIDR.
Cela permet aux nœuds d’attribuer une adresse IP unique à chaque Pod.
Bien que ce concept ait été initialement conçu pour IPv4, il a été étendu pour prendre en charge IPv6.
Conditions en vertu desquelles un contributeur accorde une licence à un projet open source pour ses contributions.
[+]Les Accords de Licence de Contributeur (Contributor License Agreements) aident à résoudre les différends juridiques concernant les apports de matériel et la propriété intellectuelle.
La classe QoS (Quality of Service) permet à Kubernetes de classer les Pods en différentes catégories afin de prendre des décisions concernant leur ordonnancement et leur éviction.
[+]La classe QoS d’un Pod est définie lors de sa création, en fonction des paramètres de requêtes et de limites de ressources.
Ces classes sont utilisées pour prioriser les Pods lors de l’ordonnancement et pour déterminer lesquels peuvent être évincés en cas de manque de ressources.
Kubernetes peut attribuer l’une des classes QoS suivantes à un Pod : Guaranteed, Burstable ou BestEffort.
Le Cloud Controller Manager est une fonctionnalité alpha de la version 1.8. Dans les prochaines versions, il deviendra le moyen privilégié pour l'intégration de Kubernetes à n'importe quel cloud.
[+]Kubernetes v1.6 contient un nouveau binaire appelé cloud-controller-manager. Le cloud-controller-manager est un service qui intègre des boucles de contrôle propres au cloud. Ces boucles de contrôle spécifiques au cloud se trouvaient à l'origine dans le kube-controller-manager. Étant donné que les fournisseurs de cloud développent et mettent à jour leurs produits à un rythme différent de celui du projet Kubernetes, l'abstraction du code spécifique au fournisseur, au niveau du binaire cloud-controller-manager, permet aux fournisseurs de cloud d'évoluer indépendamment du code principal de Kubernetes.
La Cloud Native Computing Foundation (CNCF) construit des écosystèmes durables et favorise la création d'une communauté autour des projets qui orchestrent les conteneurs dans le cadre d'une architecture de microservices.
Kubernetes est un projet de la CNCF.
[+]La CNCF est une sous-fondation de Linux Foundation. Sa mission est de rendre le "cloud native computing" omniprésent.
Un ensemble de machines, appelées des "nœuds", qui exécutent des applications conteneurisées gérées par Kubernetes..
[+]Un cluster possède plusieurs nœuds travailleurs et au moins un nœud maître.
Une condition est un champ dans le statut d’une ressource Kubernetes qui décrit l’état actuel de cette ressource.
[+]Les conditions fournissent un moyen standardisé pour les composants Kubernetes de communiquer le statut des ressources.
Chaque condition possède un type, un status (True, False, ou Unknown), et éventuellement des champs comme reason et message pour fournir des informations supplémentaires.
Par exemple, un Pod peut avoir des conditions telles que Ready, ContainersReady ou PodScheduled.
Un objet API utilisé pour stocker des données non confidentielles dans des paires clé-valeur. Peut être utilisé comme variable d'environnement, argument de ligne de commande ou fichier de configuration dans un volume.
[+]Permet de dissocier la configuration spécifique à l'environnement de vos images de conteneurs, de sorte que vos applications soient facilement portable. Lorsque vous stockez des données confidentielles, utilisez un Secret.
Une image exécutable légère et portable qui contient le logiciel et toutes ses dépendances.
[+]Les conteneurs découplent les applications de l'infrastructure hôte sous-jacente pour faciliter le déploiement dans différents environnements cloud ou OS et pour faciliter la mise à l'échelle.
Les hooks (ou déclencheurs) du cycle de vie exposent les événements du cycle de vie de la gestion du conteneur et permettent à l'utilisateur d'exécuter le code lorsque les événements se produisent
[+]Deux hooks (ou déclencheurs) sont exposés aux conteneurs : PostStart qui s'exécute immédiatement après la création d'un conteneur et PreStop qui est appelé immédiatement avant qu'un conteneur soit terminé.
L'environnement d'exécution de conteneurs est le logiciel responsable de l'exécution des conteneurs.
[+]Kubernetes est compatible avec plusieurs environnements d'exécution de conteneur: Docker, containerd, cri-o, rktlet ainsi que toute implémentation de Kubernetes CRI (Container Runtime Interface).
Un environnement d'exécution des conteneurs qui met l'accent sur la simplicité, la robustesse et la portabilité.
[+]Containerd est un environnement d'exécution de conteneur qui fonctionne comme un daemon sous Linux ou Windows. Containerd s'occupe de la récupération et du stockage d'images de conteneurs, de l'exécution de conteneurs, et de l'accès au réseau, etc.
Un type de conteneur que vous pouvez exécuter temporairement dans un Pod.
[+]Si vous souhaitez analyser un Pod en cours d’exécution présentant des problèmes, vous pouvez y ajouter un conteneur éphémère afin d’effectuer des diagnostics.
Les conteneurs éphémères ne disposent pas de garanties en termes de ressources ou d’ordonnancement, et ne doivent pas être utilisés pour exécuter une partie du workload lui-même.
Les conteneurs éphémères ne sont pas pris en charge par les Pods statiques.
Un ou plusieurs conteneurs qui sont généralement démarrés avant les conteneurs principaux de l’application.
[+]Les conteneurs sidecar fonctionnent comme des conteneurs d’application classiques, mais avec un objectif différent : le sidecar fournit un service local au Pod pour le conteneur principal.
Contrairement aux init containers, les sidecars continuent de s’exécuter après le démarrage du Pod.
Pour plus de détails, lire Sidecar containers.
Quelqu'un qui code, documente ou donne de son temps autrement, pour aider le projet ou la communauté Kubernetes.
[+]Les contributions comprennent les pull requests (PRs), le signalement des problèmes, les retours d'informations, les groupes d'intérêts spéciaux (SIG, de l'anglais Special Interest Group) la participation ou l'organisation des évènements de la communauté.
Personne qui développe et contribue au code open source de Kubernetes.
[+]Cette personne est aussi un membre actif de la communauté participant à un ou plusieurs Groupes d'Intérêts Spéciaux (SIGs, de l'anglais Special Interest Groups).
Boucle de contrôle surveillant l'état partagé du cluster à travers l'apiserver et effectuant des changements en essayant de déplacer l'état actuel vers l'état désiré.
[+]Parmis les contrôleurs livrés aujourd'hui avec Kubernetes se trouvent le contrôleur de réplication, le contrôleur d'endpoints, de namespace et de serviceaccounts.
Un objet de gestion de workload qui gère une application répliquée, en s’assurant que un nombre spécifique d’instances d’un pod sont en cours d’exécution.
[+]Le plan de contrôle veille à ce que le nombre défini de pods soit respecté, même si certains pods échouent, si vous supprimez des pods manuellement, ou si trop de pods sont démarrés par erreur.
Un outil permettant d'utiliser les runtimes de conteneurs OCI avec Kubernetes CRI.
[+]CRI-O est une implémentation du Container Runtime Interface (CRI) permettant l'utilisation des runtimes de conteneurs compatibles avec l'Open Container Initiative (OCI) runtime spec.
Le déploiement de CRI-O permet à Kubernetes d'utiliser n'importe quel runtime conforme à l'OCI, en tant que runtime de conteneur, afin d'exécuter les Pods, et de récupérer les images de conteneurs OCI provenant de registres distants.
Définition d'une ressource personnalisée qui est ajoutée au serveur d'API Kubernetes sans construire un serveur personnalisé complet.
[+]Les définitions de ressources personnalisées permettent s'ajoutent aux ressouces natives (ou "d'origine", "de base") de Kubernetes quand celles-ci ne peuvent répondre à vos besoins.
Peut faire référence à un Développeur d'Application, Contributeur de Code ou à un Développeur de Plate-forme.
[+]Ce terme ambigu peut avoir différentes significations selon le contexte.
Personne qui écrit une application s'exécutant dans un cluster Kubernetes.
[+]Un développeur d'application se concentre sur une partie de l'application. L'ampleur de son champ d'action peut varier considérablement en taille.
Une personne qui personnalise la plateforme Kubernetes afin de répondre aux besoins spécifiques de son projet.
[+]Un développeur de plateforme peut, par exemple, utiliser des Custom Resources ou étendre l’API Kubernetes via la couche d’agrégation afin d’ajouter des fonctionnalités adaptées à son application.
Certains développeurs de plateforme sont également contributeurs et participent au développement d’extensions open source pour la communauté Kubernetes.
D’autres développent des extensions propriétaires ou spécifiques à leur organisation.
Une ou plusieurs ressources d’infrastructure directement ou indirectement attachées à vos nœuds.
[+]Les devices peuvent être des produits commerciaux comme les GPU, ou du matériel personnalisé comme des cartes ASIC. Les devices attachés nécessitent généralement des pilotes permettant aux Kubernetes Pods d’y accéder.
Une catégorie de devices dans le cluster qui peut être utilisée avec l’allocation dynamique de ressources (DRA).
[+]Les administrateurs ou propriétaires de devices utilisent les DeviceClasses pour définir un ensemble de devices qui peuvent être réclamés et utilisés dans des workloads. Les devices sont réclamés en créant des ResourceClaims filtrant les paramètres spécifiques d’un device dans une DeviceClass.
Pour plus d’informations, voir Allocation dynamique de ressources.
Les disruptions sont des événements qui entraînent la mise hors service d’un ou plusieurs Pods. Une disruption a des conséquences sur la gestion des ressources de workload, comme les Déploiement, qui dépendent des Pods affectés.
[+]Si vous, en tant qu’opérateur de cluster, supprimez un Pod appartenant à une application, Kubernetes parle de disruption volontaire. Si un Pod devient indisponible à cause d’une panne de nœud ou d’une interruption touchant une zone plus large, Kubernetes parle de disruption involontaire.
Voir Disruptions pour plus d’informations.
Docker (spécifiquement, Docker Engine) est un logiciel fournissant une virtualisation au niveau du système d'exploitation également connue sous le nom conteneurs}.
[+]Docker utilise les fonctionnalités d'isolation du kernel Linux telles que les cgroups et les kernel namespaces, ainsi qu'un système de fichiers compatible union comme OverlayFS et d'autres pour permettre aux conteneurs de fonctionner indépendamment dans une seule instance Linux, évitant ainsi le démarrage et la maintenance des machines virtuelles (VMs).
Le dockershim est un composant de Kubernetes version 1.23 et antérieure. Il permet au kubelet de communiquer avec Docker Engine.
[+]À partir de la version 1.24, dockershim a été supprimé de Kubernetes. Pour plus d’informations, voir FAQ Dockershim.
Peut se référer soit au code de l'écosystème Kubernetes dépendant de la base de code Kubernetes, soit à un répertoire forké.
[+]Un mécanisme de Kubernetes permettant d’exposer des informations sur le Pod et les conteneurs à une application exécutée dans un conteneur.
[+]Il peut être utile pour un conteneur d’avoir des informations sur lui-même sans avoir à modifier son code pour l’intégrer directement avec Kubernetes.
La Downward API permet aux conteneurs d’accéder à des informations sur leur propre contexte dans le cluster Kubernetes, sans que l’application ait besoin d’interagir directement avec l’API Kubernetes.
Il existe deux façons d’exposer ces informations à un conteneur en cours d’exécution :
downwardAPICes deux mécanismes sont regroupés sous le nom de Downward API.
Le drain est le processus consistant à évacuer de manière sécurisée les Pods d’un nœud afin de le préparer à une maintenance ou à son retrait du cluster.
[+]La commande kubectl drain permet de marquer un nœud comme étant hors service.
Lorsqu’elle est exécutée, elle évacue tous les Pods présents sur ce nœud.
Si une demande d’éviction est temporairement refusée, kubectl drain réessaie jusqu’à ce que tous les Pods soient terminés ou qu’un délai configurable soit atteint.
Une valeur de type chaîne représentant une durée.
[+]Le format d’une durée dans Kubernetes est basé sur le type time.Duration du langage Go.
Dans les API Kubernetes utilisant des durées, la valeur est exprimée comme une combinaison d’entiers non négatifs associés à un suffixe d’unité de temps.
Une durée peut contenir plusieurs unités, et correspond à la somme de ces différentes valeurs.
Les unités de temps valides sont : ns, µs (ou us), ms, s, m et h.
Par exemple : 5s représente une durée de cinq secondes, et 1m30s représente une durée d’une minute et trente secondes.
Une API dépréciée qui représente l’ensemble des points de terminaison d’un
Service.
Depuis la version 1.21, Kubernetes utilise les
EndpointSlices
plutôt que les Endpoints ; l’API Endpoints originale a été dépréciée en raison
de problèmes de scalabilité.
Pour en savoir plus sur les Endpoints, consultez Endpoints.
Les EndpointSlices suivent les adresses IP des points de terminaison backend.
Les EndpointSlices sont généralement associés à un
Service et les points de terminaison backend représentent typiquement des
Pods.
Un Service peut être soutenu par plusieurs Pods. Kubernetes représente les points de terminaison backend d’un Service
à l’aide d’un ensemble d’EndpointSlices associés à ce Service.
Les points de terminaison backend sont généralement, mais pas toujours, des pods s’exécutant dans le cluster.
Le plan de contrôle gère habituellement les EndpointSlices automatiquement. Toutefois,
les EndpointSlices peuvent être définis manuellement pour des Services
ne spécifiant pas de sélecteurs.
Une fonctionnalité du noyau permettant d’émuler les privilèges root. Elle est utilisée notamment pour les conteneurs "rootless".
[+]Les espaces de noms utilisateur (user namespaces) sont une fonctionnalité du noyau Linux qui permet à un utilisateur non root d’émuler des privilèges de superutilisateur.
Cela permet, par exemple, d’exécuter des conteneurs sans disposer de privilèges root en dehors du conteneur.
Les espaces de noms utilisateur contribuent à limiter l’impact d’éventuelles attaques d’évasion de conteneur.
Dans ce contexte, le terme namespace fait référence à une fonctionnalité du noyau Linux, et non à un namespace Kubernetes.
Base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster.
[+]Si votre cluster Kubernetes utilise etcd comme mémoire de sauvegarde, assurez-vous d'avoir un plan de back up pour ces données.
Vous pouvez trouver plus d'informations à propos d'etcd dans la documentation officielle.
Un objet Kubernetes qui décrit des changements d’état ou des occurrences notables dans le cluster.
[+]Les événements ont une durée de rétention limitée, et leurs déclencheurs ainsi que leurs messages peuvent évoluer avec le temps.
Les consommateurs d’événements ne doivent pas supposer qu’un événement avec une raison donnée correspond toujours à un déclencheur identique, ni que ces événements continueront d’exister dans le temps.
Les événements doivent être considérés comme des informations indicatives, fournies au mieux (best-effort), et comme des données complémentaires.
Dans Kubernetes, le mécanisme d’audit génère un type différent d’enregistrement d’événement (groupe d’API audit.k8s.io).
L’éviction est le processus de terminaison d’un ou plusieurs Pods sur des nœuds.
[+]Il existe deux types d’éviction :
L’éviction initiée par l’API est le processus par lequel vous utilisez l’API d’éviction pour créer un objet Eviction qui déclenche l’arrêt gracieux d’un Pod.
Vous pouvez demander une éviction en appelant directement l’API d’éviction à l’aide d’un client du kube-apiserver, comme la commande kubectl drain.
Lorsqu’un objet Eviction est créé, le serveur API termine le Pod.
Les évictions initiées par l’API respectent les PodDisruptionBudgets configurés ainsi que le paramètre terminationGracePeriodSeconds.
L’éviction initiée par l’API est différente de l’éviction due à la pression sur les nœuds.
L’éviction sous pression du nœud est le processus par lequel le kubelet termine de manière proactive des Pods afin de libérer des ressources sur les nœuds.
[+]Le kubelet surveille les ressources telles que le CPU, la mémoire, l’espace disque et les inodes du système de fichiers sur les nœuds du cluster.
Lorsque l’une ou plusieurs de ces ressources atteignent un certain seuil d’utilisation, le kubelet peut interrompre un ou plusieurs Pods sur le nœud afin de libérer des ressources et éviter une saturation.
L’éviction sous pression du nœud est différente de l’éviction initiée via l’API.
Les extensions sont des composants logiciels qui s'intègrent profondément à Kubernetes afin de supporter de nouveaux types de matériel informatique.
[+]La plupart des administrateurs de cluster utiliseront une instance hébergée ou une instance de distribution de Kubernetes. En conséquence, la plupart des utilisateurs de Kubernetes devront installer des extensions et seront donc moins nombreux à devoir en créer de nouvelles.
Les feature gates sont un ensemble de clés (chaînes de caractères) utilisées pour contrôler quelles fonctionnalités de Kubernetes sont activées dans un cluster.
[+]Vous pouvez activer ou désactiver ces fonctionnalités en utilisant le paramètre --feature-gates dans la ligne de commande de chaque composant Kubernetes.
Chaque composant Kubernetes permet d’activer ou de désactiver un ensemble de feature gates qui lui sont propres.
La documentation Kubernetes fournit la liste des feature gates disponibles ainsi que les fonctionnalités qu’elles contrôlent.
Les finalizers sont des clés des namespaces qui indiquent à Kubernetes d'attendre que certaines conditions soient remplies avant de supprimer complètement les ressources marquées pour la suppression. Les finalizers alertent les contrôleurs pour nettoyer les ressources appartenant à l'objet supprimé.
[+]Lorsque vous demandez à Kubernetes de supprimer un objet qui a des finalizers spécifiés,
l'API Kubernetes marque l'objet pour la suppression en remplissant le champ .metadata.deletionTimestamp,
et renvoie un code d'état 202 (HTTP "Accepté"). L'objet cible reste dans un état de terminaison pendant que le
plan de contrôle, ou d'autres composants, effectuent les actions définies par les finalizers.
Une fois ces actions terminées, le contrôleur supprime les finalizers pertinents
de l'objet cible. Lorsque le champ metadata.finalizers est vide,
Kubernetes considère la suppression comme terminée et supprime l'objet.
Vous pouvez utiliser des finalizers pour contrôler la collecte des déchets des ressources. Par exemple, vous pouvez définir un finalizer pour nettoyer les ressources ou l'infrastructure associée avant que le contrôleur ne supprime la ressource cible.
FlexVolume est une interface obsolète pour créer des plugins de volume out-of-tree. L'interface Container Storage Interface est plus récente et résout plusieurs problèmes liés à FlexVolume.
[+]Les FlexVolumes permettent aux utilisateurs d’écrire leurs propres pilotes et d’ajouter la prise en charge de leurs volumes dans Kubernetes. Les binaires et dépendances du pilote FlexVolume doivent être installés sur les machines hôtes, ce qui nécessite un accès root. Le SIG Storage recommande, si possible, d’implémenter un pilote CSI, car il résout les limitations des FlexVolumes.
Le fournisseur de cloud est une entreprise offrant une plateforme de cloud computing, pouvant faire fonctionner des clusters Kubernetes.
[+]Les fournisseurs de cloud, parfois appelés Fournisseurs de Services Cloud (Cloud Service Providers), mettent à disposition des plate-formes de cloud computing. Ils peuvent offrir des services tels qu'une Infrastructure en tant que Service (IaaS, de l'anglais Infrastructure as a Service) ou une Plate-forme en tant que Service (PaaS, de l'anglais Platform as a Service). Les fournisseurs de cloud hébergent le cluster Kubernetes et fournissent également des services qui interagissent avec le cluster, tels que des loads balancers, des classes de stockages, etc.
Le Garbage collection est un terme générique désignant les différents mécanismes utilisés par Kubernetes pour nettoyer les ressources du cluster.
[+]Kubernetes utilise la collecte des déchets pour nettoyer les ressources telles que les conteneurs et images inutilisés, les Pods en échec, les objets possédés par la ressource ciblée, les Jobs terminés et les ressources qui ont expiré ou échoué.
Une famille de types d’API permettant de modéliser le réseau des services dans Kubernetes.
[+]La Gateway API fournit un ensemble de types d’API extensibles, orientés rôles et conscients des protocoles, pour définir et gérer le réseau des services dans Kubernetes.
Un moyen de représenter de manière unique une API Kubernetes.
[+]Les Group Version Resource (GVR) définissent le groupe d’API, la version d’API et la ressource (le nom de l’objet tel qu’il apparaît dans l’URI) utilisés pour accéder à un objet Kubernetes spécifique.
Les GVR permettent de définir et de distinguer différents objets Kubernetes, ainsi que de fournir un moyen d’y accéder de manière stable, même lorsque les API évoluent.
Dans ce contexte, le terme resource désigne une ressource HTTP.
Étant donné que certaines API sont associées à des espaces de noms (namespaces), un GVR ne correspond pas nécessairement à une ressource API spécifique.
Un ensemble de chemins liés dans l'API Kubernetes.
[+]Vous pouvez activer ou désactiver chaque groupe d'API en modifiant la configuration de votre serveur API. Vous pouvez également désactiver ou activer des chemins vers des ressources spécifiques. Le groupe d'API facilite l'extension de l'API Kubernetes. Le groupe d'API est spécifié dans un chemin REST et dans le champ apiVersion d'un objet sérialisé.
Un objet qui met automatiquement à l’échelle le nombre de Pod répliques,
en fonction de la consommation ciblée de ressources ou d’objectifs de métriques personnalisées.
Le HorizontalPodAutoscaler (HPA) est généralement utilisé avec des Deployments ou des ReplicaSets. Il ne peut pas être appliqué à des objets non extensibles, par exemple des DaemonSets.
HostAliases est un mécanisme permettant de définir une correspondance entre des adresses IP et des noms d’hôte à injecter dans le fichier hosts d’un Pod.
[+]HostAliases correspond à une liste optionnelle de noms d’hôte et d’adresses IP qui seront ajoutés au fichier hosts du Pod si elle est définie.
Cette fonctionnalité est uniquement valable pour les Pods qui n’utilisent pas le mode hostNetwork.
Instance stockée d'un conteneur qui contient un ensemble de logiciels nécessaires à l'exécution d'une application.
[+]Une façon d'empaqueter un logiciel qui permet de le stocker dans un registre de conteneurs, de le récupérer dans un système local et de l'exécuter comme une application. Des métadonnées sont incluses dans l'image qui peut indiquer quel exécutable exécuter, qui l'a construit, et d'autres informations.
La couche d'infrastructure fournit et maintient, entre autres, les machines virtuelles, les réseaux ainsi que les groupes de sécurité.
L’infrastructure immuable désigne une infrastructure informatique (machines virtuelles, conteneurs, équipements réseau) qui ne peut pas être modifiée une fois déployée.
[+]L’immuabilité peut être appliquée via un processus automatisé qui écrase les modifications non autorisées ou par un système qui n’autorise pas les modifications dès le départ. Les conteneurs sont un bon exemple d’infrastructure immuable car toute modification persistante ne peut se faire qu’en créant une nouvelle version du conteneur ou en recréant le conteneur existant à partir de son image.
En empêchant ou en détectant les modifications non autorisées, l’infrastructure immuable
facilite l’identification et la gestion des risques de sécurité.
L’exploitation d’un tel système devient beaucoup plus simple car les administrateurs
peuvent faire des hypothèses fiables sur son état.
Après tout, ils savent qu’aucune erreur ou modification n’a été effectuée à leur insu.
L’infrastructure immuable s’accompagne souvent de l’Infrastructure as Code (IaC),
où toute l’automatisation nécessaire à la création de l’infrastructure est stockée dans un
système de contrôle de version (comme Git).
Cette combinaison d’immuabilité et de contrôle de version permet d’avoir un journal d’audit durable
pour chaque changement autorisé sur le système.
Un objet API qui gère l'accès externe aux services d'un cluster, typiquement HTTP.
[+]L'Ingress peut fournir un équilibrage de charge, une terminaison SSL ainsi qu'un hébergement virtuel basé sur un nom.
Un ou plusieurs conteneurs d'initialisation qui doivent être exécutés jusqu'à la fin, avant l'exécution de tout conteneur d'application.
[+]Les conteneurs d'initialisation (init containers en anglais) sont comme les conteneurs d'applications classiques, à une différence près : les conteneurs d'initialisation doivent être exécutés jusqu'au bout, avant que les conteneurs d'applications puissent démarrer. Les conteneurs d'initialisation fonctionnent en série : chaque conteneur d'initialisation doit fonctionner jusqu'à la complétion avant que le conteneur d'initialisation suivant ne commence.
L'Interface de Stockage de Conteneurs, (CSI, de l'anglais Container Storage Interface) définit une interface normalisée pour exposer les systèmes de stockage aux conteneurs.
[+]L'Interface de Stockage de Conteneurs permet aux fournisseurs de créer des plugins de stockage personnalisés pour Kubernetes, sans les ajouter au référentiel Kubernetes (plugin hors arbre). Afin d'utiliser un pilote d'Interface de Stockage de Conteneurs d'un fournisseur de mémoire, vous devez d'abord le déployer sur votre cluster. Vous pourrez alors créer une Classe de Stockage qui utilise le pilote de cette Interface de Stockage de Conteneurs.
Le protocole principal pour la communication entre le kubelet et le Runtime de Conteneur.
[+]L'Interface du Runtime de Conteneur (CRI) de Kubernetes définit le protocole principal gRPC pour la communication entre les composants du nœud kubelet et le runtime de conteneur.
Les plugins de l'interface réseau de conteneurs (CNI, de l'anglais Container Network Interface), sont un type de plugin réseau conforme à la spécification appc/CNI.
[+]Une plate-forme ouverte (non spécifique à Kubernetes) qui fournit un moyen uniforme d'intégrer des microservices, de gérer des flux de trafic, d'appliquer des règles et d'agréger des données télémétriques.
[+]L'ajout d'Istio ne nécessite pas de changement de code d'application. Il s'agit d'une couche d'infrastructure entre un service et le réseau, qui, une fois combinée aux déploiements de services, est communément appelée maillage de services. Le plan de contrôle d'Istio fait abstraction de la plate-forme de gestion de cluster sous-jacente, qui peut être Kubernetes, Mesosphere, etc.
Les logs sont des enregistrements d’événements produits par le cluster ou les applications.
[+]Les logs des applications et du système permettent de comprendre ce qui se passe à l’intérieur de votre cluster.
Ils sont particulièrement utiles pour le débogage des problèmes et la surveillance de l’activité du cluster.
Un moyen de représenter des assertions à transférer entre deux parties.
[+]Les JWT peuvent être signés numériquement et chiffrés. Kubernetes utilise les JWT comme tokens d’authentification pour vérifier l’identité des entités souhaitant effectuer des actions dans un cluster.
kOps aide non seulement à créer, détruire, mettre à jour et maintenir des clusters Kubernetes
de production hautement disponibles, mais il provisionne également l’infrastructure cloud nécessaire.
kOps est un système de provisionnement automatisé :
Composant sur le master qui expose l'API Kubernetes. Il s'agit du front-end pour le plan de contrôle Kubernetes.
[+]Il est conçu pour une mise à l'échelle horizontale, ce qui veut dire qu'il met à l'échelle en déployant des instances supplémentaires. Voir Construire des Clusters en Haute Disponibilité.
Composant du master qui exécute les contrôleurs.
[+]Logiquement, chaque contrôleur est un processus à part mais, pour réduire la complexité, les contrôleurs sont tous compilés dans un seul binaire et s'exécutent dans un seul processus.
kube-proxy est un proxy réseau qui s'exécute sur chaque nœud du cluster et implémente une partie du concept Kubernetes de Service.
[+]kube-proxy maintient les règles réseau sur les nœuds. Ces règles réseau permettent une communication réseau vers les Pods depuis des sessions réseau à l'intérieur ou à l'extérieur du cluster.
kube-proxy utilise la couche de filtrage de paquets du système d'exploitation s'il y en a une et qu'elle est disponible. Sinon, kube-proxy transmet le trafic lui-même.
Composant sur le master qui surveille les pods nouvellement créés qui ne sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont s'exécuter.
[+]Les facteurs pris en compte pour les décisions de planification (scheduling) comprennent les exigences individuelles et collectives en ressources, les contraintes matérielles/logicielles/politiques, les spécifications d'affinité et d'anti-affinité, la localité des données, les interférences entre charges de travail et les dates limites.
Un outil pour installer rapidement le plan de contrôle et les composants de nœud de travail.
[+]Vous pouvez utiliser kubeadm pour installer à la fois le plan de contrôle et les composants des nœuds de travail.
Outil en ligne de commande pour communiquer avec le plan de contrôle d’un cluster Kubernetes via l’API Kubernetes.
[+]Vous pouvez utiliser kubectl pour créer, inspecter, mettre à jour et supprimer des objets Kubernetes.
En anglais, kubectl se prononce officiellement /kjuːb/ /kənˈtɹəʊl/ (comme "cube control").
Un agent qui s'exécute sur chaque nœud du cluster. Il s'assure que les conteneurs fonctionnent dans un pod.
[+]Le kubelet prend un ensemble de PodSpecs fournis par divers mécanismes et s'assure du fonctionnement et de la santé des conteneurs décrits dans ces PodSpecs. Le kubelet ne gère que les conteneurs créés par Kubernetes.
Limite la consommation de ressources par conteneur ou Pod, définie pour un namespace donné.
[+]Un LimitRange peut soit limiter la quantité de ressources API qui peuvent être créées (pour un type de ressource particulier), soit la quantité de ressources d’infrastructure qui peut être demandée ou consommée par des conteneurs ou des Pods individuels au sein d’un namespace.
Spécification d’un objet de l’API Kubernetes au format JSON ou YAML.
[+]Un manifeste définit l’état souhaité d’un objet que Kubernetes s’efforce de maintenir après son application.
Dans le cas du format YAML, un même fichier peut contenir plusieurs manifestes.
Terme historique, utilisé comme synonyme de nœuds hébergeant le plan de contrôle.
[+]Le terme est encore utilisé par certains outils de provisionnement, comme kubeadm,
et par certains services managés, pour label
les nœuds avec kubernetes.io/role et contrôler
le placement des Pods du plan de contrôle.
Un contributeur actif en continu dans la communauté Kubernetes.
[+]Les membres peuvent se voir assigner des issues et des PR, et participer à des special interest groups (SIGs) via les équipes GitHub. Des tests préalables sont exécutés automatiquement sur leurs PR. Un membre doit rester un contributeur actif au sein de la communauté.
Un outil pour exécuter Kubernetes localement.
[+]Minikube exécute un cluster Kubernetes local, tout-en-un ou multi-nœuds, dans une VM sur votre ordinateur. Vous pouvez utiliser Minikube pour essayer Kubernetes dans un environnement d’apprentissage.
Un objet API qui définit un modèle pour créer des Pods.
Le PodTemplate API est également intégré dans les définitions d’objets pour la gestion des workloads, comme les Deployments ou StatefulSets.
Les modèles de Pod permettent de définir des métadonnées communes (labels, nom du Pod, etc.) et de spécifier l’état souhaité d’un Pod.
Les contrôleurs de gestion des workloads utilisent ces modèles (souvent intégrés dans un autre objet, comme Deployment ou StatefulSet) pour définir et gérer un ou plusieurs Pods.
Lorsque plusieurs Pods sont créés à partir du même modèle, on parle de répliques (replicas).
Bien qu’il soit possible de créer un objet PodTemplate directement, cela est rarement nécessaire.
Définit un modèle que Kubernetes utilise pour créer des ResourceClaims.
Les ResourceClaimTemplates sont utilisés dans
l'allocation dynamique de ressources (DRA)
pour fournir un accès par Pod à des ressources séparées mais similaires.
Lorsqu'un ResourceClaimTemplate est référencé dans la spécification d'une charge de travail,
Kubernetes crée automatiquement des objets ResourceClaim basés sur le modèle.
Chaque ResourceClaim est lié à un Pod spécifique. Lorsque le Pod se termine,
Kubernetes supprime le ResourceClaim correspondant.
Le modèle Operator est une approche de conception qui lie un Contrôleur à une ou plusieurs ressources personnalisées.
[+]Il est possible d'étendre Kubernetes en ajoutant des contrôleurs à votre cluster, au-delà des contrôleurs intégrés fournis avec Kubernetes.
Si une application en cours d'exécution agit comme un contrôleur et dispose d'un accès API pour exécuter des tâches sur une ressource personnalisée définie dans le plan de contrôle, c'est un exemple du modèle Operator.
Un texte fourni par le client qui fait référence à un objet dans une URL de ressource, comme /api/v1/pods/some-name.
Seul un objet d'un certain type peut avoir un nom donné à la fois. Cependant, si vous supprimez l'objet, vous pouvez créer un nouvel objet avec le même nom.
Une abstraction utilisée par Kubernetes pour permettre l’isolation de groupes de ressources API au sein d’un même cluster.
[+]Les namespaces sont utilisés pour organiser les objets dans un cluster et permettent de répartir les ressources du cluster. Les noms des ressources doivent être uniques au sein d’un namespace, mais pas entre différents namespaces. La portée par namespace ne s’applique qu’aux ressources namespacées (par exemple : Pods, Deployments, Services) et non aux ressources à l’échelle du cluster (par exemple : StorageClasses, Nodes, PersistentVolumes).
Une spécification définissant comment des groupes de Pods sont autorisés à communiquer entre eux et avec d'autres points de terminaison réseau.
[+]Les NetworkPolicies permettent de configurer de manière déclarative quels Pods sont autorisés à se connecter entre eux, quels namespaces sont autorisés à communiquer, et plus précisément quels numéros de port sont concernés par chaque politique. Les objets NetworkPolicy utilisent des labels pour sélectionner des Pods et définir des règles spécifiant quel trafic est autorisé vers les Pods sélectionnés.
Les NetworkPolicies sont implémentées par un plugin réseau compatible fourni par un fournisseur réseau. Notez que la création d’un objet NetworkPolicy sans contrôleur pour l’implémenter n’aura aucun effet.
Une entité du système Kubernetes. Un objet est une ressource API que l’API Kubernetes utilise pour représenter l’état de votre cluster.
[+]Un objet Kubernetes est généralement un « enregistrement d’intention » — une fois l’objet créé, le plan de contrôle de Kubernetes travaille en permanence pour garantir que l’élément qu’il représente existe effectivement.
En créant un objet, vous indiquez au système Kubernetes à quoi vous souhaitez que cette partie de la charge de travail de votre cluster ressemble ; cela correspond à l’état souhaité de votre cluster.
Une personne qui configure, contrôle et surveille les clusters.
[+]Leur principale responsabilité consiste à assurer le bon fonctionnement d'un cluster, ce qui peut impliquer des activités de maintenance périodique ou des mises à niveau.
Activités telles que la mise à niveau des clusters, la mise en œuvre de la sécurité, du stockage, de l'Ingress, du réseau, de la consignation et de la surveillance, et autres opérations nécessaires pour gérer un cluster Kubernetes.
Objet API représentant une unité de stockage dans le cluster. Il s’agit d’une représentation d’une ressource de stockage générale et extensible, pouvant persister au-delà du cycle de vie de tout Pod individuel.
[+]Les PersistentVolumes (PV) fournissent une API qui abstrait les détails de la manière dont le stockage est fourni de la manière dont il est consommé. Les PV sont utilisés directement dans les cas où le stockage peut être créé à l’avance (provisionnement statique). Pour les cas nécessitant un stockage à la demande (provisionnement dynamique), des PersistentVolumeClaims (PVC) sont utilisés à la place.
Permet de réclamer des ressources de stockage définies dans un PersistentVolume, afin que ce stockage puisse être monté comme volume dans un conteneur.
[+]Spécifie la quantité de stockage, la manière dont il sera accédé (lecture seule, lecture-écriture et/ou exclusif) ainsi que la façon dont il est récupéré (conservé, recyclé ou supprimé). Les détails du stockage lui-même sont décrits dans l’objet PersistentVolume.
Couche d'orchestration des conteneurs exposant l'API et les interfaces pour définir, déployer et gérer le cycle de vie des conteneurs.
Couche fournissant des capacités comme le CPU, la mémoire, le réseau et le stockage afin que les conteneurs puissent fonctionner et se connecter à un réseau.
Les Plugins de Périphériques sont des conteneurs fonctionnant dans Kubernetes, donnant accès à une ressource spécifique d'un fournisseur.
[+]Les Plugins de Périphériques sont des conteneurs fonctionnant dans Kubernetes, donnant accès à une ressource spécifique d'un fournisseur. Les Plugins de Périphériques communiquent ces ressources à kubelet et peuvent être déployés manuellement ou sous forme de DaemonSet, plutôt que d'écrire du code Kubernetes personnalisé.
Un plugin de volume permet d'intégrer du stockage dans un Pod.
[+]Un plugin de volume permet de connecter et de monter des volumes de stockage pour un Pod. Les plugins de volume peuvent être in tree ou out of tree. Les plugins in tree font partie du dépôt de code Kubernetes et suivent son cycle de publication. Les plugins out of tree sont développés de manière indépendante.
Le plus petit et le plus simple des objets Kubernetes. Un Pod est un ensemble de conteneurs fonctionnant sur votre cluster.
[+]Un Pod est généralement configuré pour faire fonctionner un seul conteneur primaire. Il peut également exécuter des conteneurs side-car optionnels qui ajoutent des fonctions supplémentaires comme le logging. Les Pods sont généralement gérés par un Déploiement.
La Pod disruption est le processus par lequel des Pods sur des nœuds sont terminés de manière volontaire ou involontaire.
[+]Les perturbations volontaires sont déclenchées intentionnellement par les propriétaires d'applications ou les administrateurs du cluster. Les perturbations involontaires sont non intentionnelles et peuvent être causées par des problèmes inévitables, comme des nœuds à court de ressources, ou par des suppressions accidentelles.
Un Pod Disruption Budget permet au propriétaire d'une application de créer un objet pour une application répliquée, afin de garantir qu'un certain nombre ou pourcentage de Pods portant un label attribué ne sera pas évincé volontairement à un moment donné.
[+]Les perturbations involontaires ne peuvent pas être empêchées par les PDB ; cependant, elles sont comptabilisées dans le budget.
La succession des états par lesquels passe un Pod au cours de son cycle de vie.
[+]Le Pod Lifecycle est défini par les états ou phases d’un Pod. Il existe cinq phases possibles pour un Pod : Pending, Running, Succeeded, Failed et Unknown. Une description synthétique de l’état du Pod est fournie dans le champ phase de PodStatus.
Un objet pod qu’un kubelet utilise pour représenter un pod statique.
[+]Lorsque le kubelet détecte un pod statique dans sa configuration, il essaie automatiquement
de créer un objet Pod correspondant sur le serveur API Kubernetes.
Cela signifie que le pod sera visible dans le serveur API, mais ne peut pas être contrôlé depuis celui-ci.
(Par exemple, supprimer un pod miroir n’arrêtera pas le kubelet qui continue de l’exécuter.)
La priorité d’un Pod indique son importance relative par rapport aux autres Pods.
[+]La Pod Priority permet de définir une priorité d’ordonnancement pour un Pod, afin qu’il puisse être priorisé plus ou moins que d’autres Pods — une fonctionnalité importante pour les charges de travail en production.
A former Kubernetes API that enforced security restrictions during Pod creation and updates.
[+]PodSecurityPolicy was deprecated as of Kubernetes v1.21, and removed in v1.25. As an alternative, use Pod Security Admission or a 3rd party admission plugin.
Un pod géré directement par le démon kubelet sur un nœud spécifique.
[+]Le pod est créé et maintenu localement par le kubelet, sans que le serveur API de Kubernetes ne l’observe.
Les pods statiques ne prennent pas en charge les conteneurs éphémères.
Le mécanisme de préemption dans Kubernetes permet à un Pod en attente de trouver un adapté en évincant des Pods de priorité inférieure présents sur ce nœud.
[+]Si un Pod ne peut pas être planifié, le scheduler tente de préempter des Pods de priorité inférieure afin de permettre la planification du Pod en attente.
Une PriorityClass est une classe nommée représentant la priorité d’ordonnancement qui doit être attribuée à un Pod appartenant à cette classe.
[+]Une PriorityClass
est un objet non associé à un namespace qui associe un nom à une priorité entière, utilisée pour un Pod. Le nom est
spécifié dans le champ metadata.name, et la valeur de priorité dans le champ value. Les priorités vont de
-2147483648 à 1000000000 inclus. Des valeurs plus élevées indiquent une priorité plus élevée.
Une vérification que le kubelet effectue périodiquement sur un conteneur en cours d'exécution dans un Pod, qui définit l'état et la santé du conteneur et informe son cycle de vie.
[+]Pour en savoir plus, consultez la documentation sur les sondes de conteneur.
Permet aux utilisateurs de demander la création automatique de Volumes de stockage.
[+]Le provisionnement dynamique élimine le besoin, pour les administrateurs de cluster, de pré-provisionner le stockage. Au lieu de cela, il provisionne automatiquement le stockage à la demande de l'utilisateur. Le provisionnement dynamique de volume est basé sur un objet API, la Class de Stockage, se référant à un Plugin de Volume qui provisionne un Volume ainsi qu'un ensemble de paramètres à passer au Plugin de Volume.
En informatique, un proxy est un serveur qui agit comme intermédiaire pour un service distant.
[+]Un client interagit avec le proxy ; le proxy transmet les données du client au serveur réel ; le serveur réel répond au proxy ; le proxy renvoie la réponse au client.
kube-proxy est un proxy réseau qui s’exécute sur chaque nœud de votre cluster et implémente une partie du concept Kubernetes de Service.
Vous pouvez exécuter kube-proxy comme un simple service proxy utilisateur. Si votre système le permet, vous pouvez également l’exécuter en mode hybride, produisant le même effet global en utilisant moins de ressources système.
Fonctionnalité permettant au kube-apiserver de proxyfier une requête de ressource vers un serveur API pair différent.
[+]Lorsque plusieurs API servers d’un cluster exécutent des versions différentes de Kubernetes, cette fonctionnalité permet de servir les requêtes de resource par le serveur API approprié.
MVP est désactivé par défaut et peut être activé via le feature gate UnknownVersionInteroperabilityProxy au démarrage du API Server.
Une représentation en nombres entiers de petits ou grands nombres utilisant des suffixes SI.
[+]Les quantités sont des représentations de petits ou grands nombres utilisant une notation compacte en nombres entiers avec des suffixes SI. Les nombres fractionnaires sont représentés en utilisant des unités en millièmes, tandis que les grands nombres peuvent être représentés en utilisant les unités kilo, méga ou giga.
Par exemple, le nombre 1.5 est représenté comme 1500m, tandis que le nombre 1000 peut être représenté comme 1k, et 1000000 comme 1M.
Vous pouvez également spécifier des suffixes de notation binaire ;
le nombre 2048 peut s'écrire comme 2Ki.
Les unités décimales acceptées (puissance de 10) sont m (milli), k (kilo, intentionnellement en minuscule),
M (méga), G (giga), T (tera), P (peta), E (exa).
Les unités binaires acceptées (puissance de 2) sont
Ki (kibi), Mi (mebi), Gi (gibi), Ti (tebi), Pi (pebi), Ei (exbi).
Une copie ou un duplicata d'un Pod ou
d'un ensemble de pods. Les replicas garantissent une disponibilité élevée, une scalabilité et une tolérance aux pannes
en maintenant plusieurs instances identiques d'un pod.
Les replicas sont couramment utilisées dans Kubernetes pour atteindre l'état et la fiabilité souhaités de l'application.
Elles permettent de mettre à l'échelle et de distribuer la charge de travail sur plusieurs nœuds d'un cluster.
En définissant le nombre de replicas dans un déploiement ou un ReplicaSet, Kubernetes garantit que
le nombre spécifié d'instances est en cours d'exécution, ajustant automatiquement le compte selon les besoins.
La gestion des replicas permet un équilibrage de charge efficace, des mises à jour progressives et
des capacités d'auto-guérison dans un cluster Kubernetes.
Un ReplicaSet a pour objectif de maintenir un ensemble de Pods répliqués en cours d’exécution à tout moment.
[+]Des objets de type workload tels que les Déploiement utilisent des ReplicaSets pour s’assurer que le nombre configuré de Pods s’exécute dans votre cluster, conformément à la spécification de ce ReplicaSet.
Décrit les ressources nécessaires à un workload, comme des devices. Les ResourceClaims sont utilisés dans la allocation dynamique de ressources (DRA) pour fournir aux Pods l’accès à une ressource spécifique.
[+]Les ResourceClaims peuvent être créés par les opérateurs de workload ou générés par Kubernetes à partir d’un ResourceClaimTemplate.
Objet qui contraint la consommation agrégée de ressources par Namespace.
[+]Un ResourceQuota peut soit limiter la quantité de ressources API qui peuvent être créées dans un namespace par type, soit définir une limite sur la quantité totale de ressources d’infrastructure pouvant être consommées au nom du namespace (et des objets qu’il contient).
Représente une ou plusieurs ressources d'infrastructure, telles que
devices, attachées aux nœuds.
Les pilotes créent et gèrent les ResourceSlices dans le cluster. Les ResourceSlices
sont utilisés pour
l'allocation dynamique de ressources (DRA).
Lorsqu'un ResourceClaim est créé, Kubernetes utilise les ResourceSlices pour trouver les nœuds ayant accès aux ressources capables de satisfaire la demande. Kubernetes alloue les ressources au ResourceClaim et planifie le Pod sur un nœud pouvant accéder aux ressources.
Des capacités fournies à un ou plusieurs nœuds (CPU, mémoire, GPU, etc.) et mises à disposition des Pods exécutés sur ces nœuds.
Kubernetes utilise également le terme ressource pour désigner une ressource API.
[+]Les ordinateurs fournissent des ressources matérielles fondamentales : puissance de calcul, mémoire, stockage, réseau, etc.
Ces ressources ont une capacité limitée, mesurée dans une unité adaptée (nombre de CPU, quantité de mémoire, etc.).
Kubernetes abstrait ces ressources afin de les allouer aux workloads et utilise des mécanismes du système d’exploitation (par exemple les cgroups sous Linux) pour gérer leur consommation.
Vous pouvez également utiliser l’allocation dynamique de ressources pour gérer automatiquement des besoins plus complexes.
Une entité dans le système de types de Kubernetes, correspondant à un point d’accès sur l’API Kubernetes.
Une ressource représente généralement un objet.
Certaines ressources représentent des opérations sur d’autres objets, comme par exemple une vérification de permissions.
[+]Chaque ressource correspond à un endpoint HTTP (URI) sur le serveur API Kubernetes et définit le schéma des objets ou des opérations associées à cette ressource.
Une personne qui examine la qualité et l'exactitude du code sur une partie du projet.
[+]Les réviseurs connaissent bien la base de code (codebase) et les principes d'ingénierie logicielle. Le statut du réviseur est limité à une partie de la base de code.
Stocke des informations sensibles, telles que des mots de passe, des tokens OAuth et des clés SSH.
[+]Les Secrets vous donnent plus de contrôle sur la façon dont les informations sensibles sont utilisées et réduisent le risque d'exposition accidentelle. Les valeurs des Secrets sont encodées sous forme de chaînes base64 et sont stockées non chiffrées par défaut, mais peuvent être configurées pour être chiffrées au repos.
Un Pod peut faire référence au Secret de diverses manières, par exemple via un montage de volume ou comme variable d'environnement. Les Secrets sont conçus pour les données confidentielles et les ConfigMaps sont conçus pour les données non confidentielles.
Le champ securityContext définit les paramètres de privilèges et de contrôle d'accès pour un Pod ou un conteneur.
Dans un securityContext, vous pouvez définir : l'utilisateur sous lequel les processus s'exécutent, le groupe sous lequel les processus s'exécutent, ainsi que les paramètres de privilèges.
Vous pouvez également configurer des politiques de sécurité (par exemple : SELinux, AppArmor ou seccomp).
Le paramètre PodSpec.securityContext s'applique à tous les conteneurs d'un Pod.
Une manière abstraite d'exposer une application s'exécutant sur un ensemble de Pods en tant que service réseau.
[+]L'ensemble des pods ciblés par un service est (généralement) déterminé par un selecteur. Si plus de Pods sont ajoutés ou supprimés, l'ensemble de Pods correspondant au sélecteur changera. Le service s'assure que le trafic réseau peut être dirigé vers l'ensemble actuel de pods pour la charge de travail.
Une offre logicielle maintenue par un fournisseur tiers.
[+]Parmi les exemples de services gérés, on trouve AWS EC2, Azure SQL Database et GCP Pub/Sub, mais il peut s'agir de tout logiciel accessible et utilisé par une application.
Fournit une identité aux processus s’exécutant dans un Pod.
[+]Lorsque des processus à l’intérieur de Pods accèdent au cluster, ils sont authentifiés par le serveur d’API en tant que compte de service spécifique, par exemple default. Lorsque vous créez un Pod, s’il n’est associé à aucun compte de service, il se voit automatiquement attribuer le compte de service par défaut du même Namespace.
Technique d’attribution de requêtes à des files offrant une meilleure isolation qu’un simple hash modulo le nombre de files.
[+]L’objectif est d’isoler différents flux de requêtes afin qu’un flux intense ne bloque pas des flux moins chargés.
Une approche simple consiste à hasher certaines caractéristiques de la requête modulo le nombre de files pour obtenir l’indice de la file. Mais un flux intense peut alors monopoliser toutes les files correspondant au même hash.
Le shuffle-sharding améliore l’isolation : il produit un hash à haute entropie, simule un « mélange de cartes », puis attribue une « main » de files. La requête est placée dans la file la plus courte parmi celles examinées.
Avec une main de taille modeste, cette technique permet aux flux faibles de contourner l’effet des flux intenses. Une main trop grande rend le processus coûteux et réduit l’efficacité de l’isolation. La taille de la main doit donc être choisie judicieusement.
Membres de la communauté qui gèrent collectivement une partie ou un aspect continu du projet open source Kubernetes.
[+]Les membres d’un SIG partagent un intérêt pour l’avancement d’un domaine spécifique, comme l’architecture, la machinerie API ou la documentation.
Les SIG doivent suivre les lignes directrices de gouvernance des SIG, mais peuvent avoir leur propre politique de contribution et leurs canaux de communication.
Pour plus d’informations, voir le dépôt kubernetes/community et la liste actuelle des SIGs et groupes de travail.
Définit la manière dont chaque objet, comme les Pods ou les Services, doit être configuré ainsi que son état souhaité.
[+]Presque tous les objets Kubernetes incluent deux champs imbriqués qui régissent leur configuration : le spec de l’objet et le status de l’objet. Pour les objets qui possèdent un spec, celui-ci doit être défini lors de la création de l’objet, en fournissant une description des caractéristiques que la ressource doit avoir : son état souhaité.
Ce champ varie selon les objets tels que les Pods, StatefulSets et Services, en détaillant des paramètres comme les conteneurs, les volumes, les réplicas, les ports et d’autres spécifications propres à chaque type d’objet. Il représente l’état que Kubernetes doit maintenir pour l’objet défini.
Gère le déploiement et la mise à l'échelle d'un ensemble de Pods, et fournit des garanties sur l'ordre et l'unicité de ces Pods.
[+]Comme un Déploiement, un StatefulSet gère des Pods qui sont basés sur une même spécification de conteneur. Contrairement à un Deployment, un StatefulSet maintient une identité pour chacun de ces Pods. Ces Pods sont créés à partir de la même spec, mais ne sont pas interchangeables : chacun a un identifiant persistant qu'il garde à travers tous ses re-scheduling.
Si vous voulez utiliser des volumes de stockage pour fournir de la persistance à votre charge de travail, vous pouvez utiliser un StatefulSet comme partie de la solution. Même si des Pods individuels d'un StatefulSet sont susceptibles d'échouer, les identifiants persistants des Pods rendent plus facile de faire correspondre les volumes existants aux nouveaux Pods remplaçant ceux ayant échoué.
Une StorageClass permet aux administrateurs de décrire les différents types de stockage disponibles.
[+]Les StorageClasses peuvent correspondre à des niveaux de qualité de service (QoS), à des politiques de sauvegarde ou à des politiques arbitraires définies par les administrateurs du cluster. Chaque StorageClass contient les champs provisioner, parameters et reclaimPolicy, qui sont utilisés lorsqu'un Volume persistant appartenant à cette classe doit être provisionné dynamiquement. Les utilisateurs peuvent demander une classe particulière en utilisant le nom de l'objet StorageClass.
sysctl est une interface standardisée permettant de lire ou de modifier les paramètres du noyau Unix en cours d’exécution.
Sur les systèmes de type Unix, sysctl désigne à la fois l’outil utilisé par les administrateurs pour consulter et modifier ces paramètres, ainsi que l’appel système utilisé par cet outil.
Les runtimes de conteneurs et les plugins réseau peuvent dépendre de certaines valeurs sysctl correctement configurées.
Un objet de base composé de trois caractéristiques requises : clé, valeur et effet. Les marquages empêchent l'ordonnancement des pods sur les nœuds ou les groupes de nœuds.
[+]Marquages et tolérances} travaillent ensemble pour s'assurer que les pods ne sont pas ordonnancés sur des nœuds inappropriés. Un ou plusieurs marquages sont appliqués à un nœud. Un nœud ne doit ordonnancer que des pods ayant les tolérances correspondantes pour les marquages configurés.
Un objet de base composé de trois caractéristiques requises : clé, valeur et effet. Les tolérances permettent d'ordonnancer les pods sur les nœuds ou les groupes de nœuds qui ont des marquages compatibles.
[+]Tolérances et marquages fonctionnent ensemble pour s'assurer que les pods ne sont pas ordonnancés sur des nœuds inappropriés. Une ou plusieurs tolérances sont appliquées à un pod. Une tolérance indique que le pod est autorisé à (mais non obligé de) être ordonnancé sur les nœuds ou groupes de nœuds avec un marquage compatible.
Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets.
[+]Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer les occurrences historiques d'entités similaires.
Peut désigner : Kubernetes « core » ou le dépôt source à partir duquel un fork a été créé.
[+]Les variables d'environnement de conteneur sont des paires nom=valeur qui fournissent des informations utiles aux conteneurs fonctionnant au sein d'un Pod.
[+]Les variables d'environnement de conteneur fournissent les informations requises par les applications conteneurisées en cours d'exécution, ainsi que des informations sur les ressources importantes aux Conteneurs comme les détails du système de fichiers, les informations sur le conteneur lui-même et d'autres ressources du cluster telles que les terminaux de services par exemple.
Un répertoire contenant des données, accessible aux conteneurs d'un Pod.
[+]Un volume Kubernetes vit aussi longtemps que le pod qui le contient. Par conséquent, un volume survit à tous les conteneurs qui s'exécutent dans le pod, et les données contenues dans le volume sont préservées lors des redémarrages du conteneur.
Voir stockage pour plus d'informations.
Verbe utilisé pour suivre les modifications d’un objet dans Kubernetes sous forme de flux. Il permet de détecter efficacement les changements.
[+]Verbe utilisé pour suivre les modifications d’un objet dans Kubernetes sous forme de flux. Les watches permettent une détection efficace des changements ; par exemple, un contrôleur qui doit être informé lorsqu’un ConfigMap est modifié peut utiliser un watch plutôt que de faire du polling.
Voir Efficient Detection of Changes in API Concepts pour plus d’informations.
Facilite la discussion et/ou la mise en œuvre d’un projet limité, ciblé ou découplé pour un comité, SIG ou un effort inter-SIG.
[+]Les groupes de travail sont un moyen d’organiser des personnes pour accomplir une tâche précise.
Pour plus d’informations, voir le dépôt kubernetes/community et la liste actuelle des SIGs et groupes de travail.
Une charge de travail (workload) est une application exécutée sur Kubernetes.
[+]Divers objets de base qui représentent différents types ou parties d'une charge de travail incluent les objets DaemonSet, Deployment, Job, ReplicaSet et StatefulSet.
Par exemple, une charge de travail constituée d'un serveur Web et d'une base de données peut exécuter la base de données dans un StatefulSet et le serveur web dans un Déploiement.