Glossaire

Services au-delà des composants fondamentaux nécessaires pour déployer un cluster conforme à Kubernetes, classés en deux types :

Configurer et exécuter des clusters Kubernetes sans accès direct à Internet.

Le processus de transformation d’un serveur en nœud Kubernetes. Cela peut impliquer de rassembler des données à fournir lors de la création du serveur qui soutient la Machine, ainsi que la configuration d’exécution du logiciel fonctionnant sur ce serveur.

Un cluster temporaire utilisé pour provisionner un cluster de gestion cible.

Fait référence à un fournisseur qui met en œuvre une solution pour le processus de démarrage.

API de cluster principale

Fournisseur d’API de cluster AWS

Fournisseur d’API de cluster Docker

Fournisseur d’API Google Cloud pour les clusters

Opérateur d’API de cluster

Fournisseur d’API RKE2 pour les clusters. Pour des informations détaillées sur CAPRKE2, consultez sa documentation ici.

Fournisseur d’API vSphere pour les clusters

Fournisseur d’API Azure pour les clusters

Une API publique qui facilite le provisionnement et les opérations sur les ressources Opérateur CAPI et API de cluster.

Terme couramment utilisé de manière interchangeable avec le cluster de charge de travail.

Un déploiement Kubernetes complet. Voir le cluster de gestion et le cluster de charge de travail.

Une collection de modèles qui définissent une topologie (plan de contrôle et de travail) à utiliser pour réconcilier en continu un ou plusieurs clusters. Voir ClusterClass

Ou projet API de Cluster

L’API de Cluster est un sous-projet du SIG-cluster-lifecycle. Il est également utilisé pour désigner les composants logiciels, les API et la communauté qui les produisent.

Voir fournisseur de noyau

Ou projet Cluster API Operator

L’Opérateur d’API de cluster est un sous-projet du SIG-cluster-lifecycle. Il est conçu pour permettre aux administrateurs de clusters de gérer le cycle de vie des fournisseurs d’API de Cluster au sein d’un cluster de gestion en utilisant une approche déclarative.

Le fournisseur d’API de Cluster RKE2 est une combinaison de deux types de fournisseurs : un fournisseur de plan de contrôle d’API de Cluster pour le provisionnement des nœuds de plan de contrôle Kubernetes et un fournisseur de démarrage d’API de Cluster pour démarrer Kubernetes sur une machine où RKE2 est utilisé comme distribution Kubernetes.

L’ensemble des services Kubernetes qui forment la base d’un cluster. Voir aussi https://kubernetes.io/docs/concepts/#_kubernetes-control-plane Il existe deux variantes :

Fait référence à un fournisseur qui met en œuvre une solution pour la gestion d’un plan de contrôle Kubernetes.

Voir CAPRRKE2, KCP.

Fait référence à un fournisseur qui implémente les contrôleurs noyau de l’API Cluster ; si l’on considère que le premier projet à déployer dans un Cluster de gestion est l’API Cluster elle-même, il devrait être clair pourquoi le projet API Cluster est également appelé fournisseur de noyau.

Voir CAPI.

Un moteur de gestion et de déploiement de conteneurs conçu pour offrir aux utilisateurs un meilleur contrôle sur le cluster local et une surveillance constante via GitOps. Consultez la documentation de Fleet pour en savoir plus sur Fleet.

Fait référence à un fournisseur qui implémente la fourniture de ressources d’infrastructure/computationnelles requises par le Cluster ou par les Machines (par exemple, VMs, réseau, etc.). Les fournisseurs d’infrastructure Cloud incluent AWS, Azure ou Google ; tandis que VMware, MAAS ou metal3.io peuvent être définis comme des fournisseurs de matériel sans système d’exploitation.

Fait référence à un fournisseur qui permet à l’API Cluster d’interagir avec des solutions IPAM. L’interaction du fournisseur IPAM avec l’API Cluster est basée sur les types d’API IPAddressClaim et IPAddress.

Ou conforme à Kubernetes

Un cluster qui réussit les tests de conformité Kubernetes.

Un opérateur Kubernetes est une méthode d’emballage, de déploiement et de gestion d’une application Kubernetes. Voir aussi https://kubernetes.io/docs/concepts/extend-kubernetes/operator/ pour plus d’informations.

Fait référence au référentiel git principal de Kubernetes ou au projet principal de Kubernetes.

Fournisseur de plan de contrôle Kubeadm

Ou Machine Ressource

La ressource personnalisée pour Kubernetes qui représente un composant d’infrastructure hébergeant un nœud Kubernetes.

Effectuer des opérations de création, de mise à l’échelle, de mise à niveau ou de destruction sur le cluster.

Kubernetes géré fait référence à toute abstraction de provisionnement et de maintenance de cluster Kubernetes, généralement exposée sous forme d’API, qui est nativement disponible auprès d’un fournisseur Cloud. Par exemple : EKS, OKE, AKS, GKE, IBM Cloud Kubernetes Service, DOKS, et bien d’autres dans l’écosystème Kubernetes natif Cloud.

Voir Topologie

Le cluster où un ou plusieurs fournisseurs d’infrastructure fonctionnent, et où les ressources (par exemple, Machines) sont stockées. Généralement mentionné lorsque vous provisionnez plusieurs clusters de charge de travail.

Un pool de nœuds est un groupe de nœuds au sein d’un cluster qui ont tous la même configuration.

Ou OS

Une combinaison généralement comprise d’un noyau et d’une interface utilisateur de niveau système, comme Linux ou Windows, par opposition à une distribution particulière.

Le pivot est un processus de déplacement des composants du fournisseur et des ressources cluster-api déclarées d’un cluster de gestion source vers un cluster de gestion cible.

Le processus de pivot est également utilisé pour supprimer un cluster de gestion et pourrait également être utilisé lors d’une mise à niveau du cluster de gestion.

Ou Fournisseur d’API de cluster

Ce terme était à l’origine utilisé comme abréviation pour Fournisseur d’infrastructure, mais il est actuellement utilisé pour désigner tout projet qui peut être déployé et qui fournit des fonctionnalités à la gestion de l’API Cluster.

Voir Fournisseur de bootstrap, Fournisseur de plan de contrôle, Fournisseur de noyau, Fournisseur d’infrastructure, Fournisseur IPAM, Fournisseur d’extension d’exécution.

Fait référence à l’artéfact YAML publié dans le cadre du processus de publication pour fournisseurs; il inclut généralement des définitions de ressources personnalisées (CRDs), des déploiements (pour exécuter le gestionnaire de contrôleur), RBAC, etc.

Dans certains cas, la même expression est utilisée pour désigner les instances des composants ci-dessus déployés dans un cluster de gestion.

Voir Dépôt du fournisseur

Fait référence à l’emplacement où le YAML pour composants du fournisseur est hébergé ; généralement, un dépôt de fournisseur héberge de nombreuses versions des composants du fournisseur, une pour chaque version publiée.

Une plateforme open-source conçue pour simplifier le déploiement et la gestion des clusters Kubernetes.

Un composant déployé par Rancher dans chaque cluster Kubernetes qu’il gère. Son rôle principal est d’établir un canal de communication sécurisé entre le serveur Rancher et le cluster Kubernetes, permettant à Rancher de gérer et d’interagir avec le cluster.

Le Gestionnaire Rancher (ou Serveur Rancher) est l’endroit où l’interface utilisateur et l’API de Rancher sont hébergées, et il communique avec les clusters gérés via des composants comme le Agent de cluster Rancher. Il permet aux utilisateurs de gérer leurs clusters Kubernetes, applications et ressources spécifiques à Rancher telles que Catalogues, Utilisateurs, Rôles globaux, et plus encore.

La distribution Kubernetes de nouvelle génération de Rancher, entièrement conforme, qui se concentre sur la sécurité et la conformité aux États-Unis. secteur du gouvernement fédéral américain. Voir documentation pour plus de détails.

Un composant externe qui fait partie d’un système construit sur Cluster API et qui peut gérer des demandes pour un Hook d’exécution spécifique.

Fait référence à un fournisseur qui implémente une ou plusieurs extensions d’exécution.

Sauf indication contraire, cela fait référence à la mise à l’échelle horizontale.

Un nœud de plan de contrôle où etcd est co-localisé avec le serveur API Kubernetes et fonctionne en tant que pod statique.

L’infrastructure qui soutient une ressource Machine, typiquement soit une instance cloud, une machine virtuelle ou un hôte physique.

Un opérateur Kubernetes qui assure l’intégration entre Rancher Manager et Cluster API (CAPI) dans le but de permettre la prise en charge intégrale de CAPI dans Rancher.

Un champ dans la spécification de l’objet Cluster qui permet de définir et de gérer la forme du plan de contrôle et des machines de travail du Cluster à partir d’un point de contrôle unique. La topologie du Cluster est basée sur un ClusterClass. Parfois, cela est également appelé une topologie gérée.

Voir ClusterClass

Fait référence à SUSE® Rancher Prime Cluster API

Un cluster créé par un contrôleur ClusterAPI, qui n’est pas un cluster de démarrage, et qui est destiné à être utilisé par les utilisateurs finaux, contrairement aux outils CAPI.

Une collection de modèles qui définissent un ensemble de nœuds de travail dans le cluster. Une ClusterClass contient zéro ou plusieurs définitions de WorkerClass.

Voir ClusterClass