Glossaire de termes | Kubernetes

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