Sélectionner une page

Formation > Blog > Kubernetes > Que sont les Kubernetes custom Resources Definition (CRD) ?

Kubernetes custom resources definition

Les Custom Resources Definition sont apparues dans la version 1.7 de Kubernetes. Elles permettent aux utilisateurs d’ajouter leurs propres objets customs à un cluster Kubernetes et à l’utiliser comme s’il était natif. Comme les pods, les déploiements et les replicaset, l’objet devient facilement accessible via L’API.

Dans cet article, nous allons voir ce que sont précisément les Kubernetes Custom Resources Definiton et comment les utiliser dans vos clusters.

Pour une maitrise complète de l’outil, suivez notre formation Kubernetes. Il s’agit d’une formation complète sur 3 jours lors de laquelle vous apprendrez à utiliser les ressources et les objets afin d’en adapter l’utilisation à vos besoins spécifiques.

Si vous êtes déjà expert de l’outil, la formation Kubernetes avancé vous apprendra à faire évoluer vos applications vers le standard micro-service, modulaire et scalable.

L’équipe Ambient IT

Qu’est-ce qu’une Custom Resource Definition ?

Dans l‘API Kubernetes, une ressource est un endpoint qui stocke une collection d’objets API. Par exemple, la ressource « pod » stocke une collection d’objets pod.

Kubernetes fonctionne de manière standard avec de nombreux objets et resources intégrée. Les CDR sont utiles lorsque nous voulons introduire notre propre objet dans le cluster Kubernetes pour répondre à des besoins précis.

Une fois que nous avons créé une Custom Resource Definition (CDR) dans Kubernetes, nous pouvons l’utiliser comme n’importe quel autre objet Kubernetes natif et ainsi tirer parti de toutes les fonctionnalités de Kubernetes.

La ressource personnalisée créée est également stockée dans le cluster etcd avec une réplication et une gestion du cycle de vie appropriées. Les CRD nous permettent d’utiliser toutes les fonctionnalités fournies par un cluster Kubernetes pour nos objets personnalisés sans avoir besoin de les mettre en œuvre par nous-mêmes.

Afin d’apporter des fonctionnalités plus avancées à ces resources personnalisées, il faut mettre en œuvre des contrôleurs ou des opérateurs. Ceux-ci permettent aux utilisateurs d’étendre le comportement de Kubernetes sans modifier le code sous-jacent.

Use Cases

Les CDR peuvent être utilisés dans la construction une plateforme d’hébergement et de CI/CD qui gère l’ensemble du cycle de vie d’une application. Elle crée un pipeline qui construira, testera et publiera l’application. Via ce pipeline, les développeurs déploient l’application dans le cluster Kubernetes avec des modèles internes.

L’extension de l’API de Kubernetes pour déclarer des resources personnalisées permet aux développeurs de créer des ressources de plateforme personnalisées. Les API étant déclaratives, ils peuvent créer et utiliser des plateformes en libre-service.

Il existe de nombreux cas d’usage dans la création des CDR, ils peuvent être complètement personnalisés afin de répondre à n’importe lequel de vos besoins.

Composition des Custom resources definition

Le code des Custom Resources Definitions se composent de plusieurs éléments distincts :

ApiVersion : décris quelle version de l’API Kubernete vous utilisez.

Kind : indique que vous souhaitez créer un CustomResourceDefinition.

Name : spécifie le nom de la ressource, qui doit être sous la forme <plural>.<group>.

Group : indique le nom du groupe pour l’API.

Versions : indique la version à utiliser dans l’URL de l’API. Elle peut avoir des valeurs telles que v2 ou v1aplha.

Schema : spécifie un schéma structurel dont vous souhaitez valider le CRD à l’aide de la validation openAPIV3Schema avant de l’envoyer au serveur de l’API. Vous spécifiez également que les champs d’objets personnalisés spec.cronSpec et spec.image doivent être des chaînes de caractères. Le champ spec.replicas doit être un nombre entier.

Scope : spécifie si l’objet personnalisé est à espace de noms ou s’il est disponible à l’échelle du cluster. Vous avez utilisé la portée Namespaced, il n’est donc disponible que pour l’espace de noms que vous utiliserez lors de la création du CRD. La valeur par défaut est « cluster-scoped« .

Plural and singular : spécifie le nom pluriel et singulier du CRD.

ShortNames : spécifie la short string que vous pouvez utiliser dans le CLI.

UNE QUESTION ? UN PROJET ? UN AUDIT DE CODE / D'INFRASTRUCTURE ?

Pour vos besoins d’expertise que vous ne trouvez nulle part ailleurs, n’hésitez pas à nous contacter.

ILS SE SONT FORMÉS CHEZ NOUS

partenaire sncf
partenaire hp
partenaire allianz
partenaire sfr
partenaire engie
partenaire boursorama
partenaire invivo
partenaire orange
partenaire psa
partenaire bnp
partenaire sncf
partenaire hp
partenaire allianz
partenaire sfr
partenaire engie
partenaire boursorama
partenaire invivo
partenaire orange
partenaire psa
partenaire bnp