Que sont les définitions de ressources personnalisées (CRD) Kubernetes ?
Les définitions de ressources personnalisées (CRD) sont des extensions d’API Kubernetes qui peuvent définir de nouveaux types d’objets. Les pods, ReplicaSets, ConfigMaps et Ingresses sont des exemples de ressources intégrées courantes. Les CRD vous permettent d’ajouter des types entièrement nouveaux à cette liste, puis de les gérer à l’aide d’outils Kubernetes familiers tels que Kubectl.
Le mécanisme CRD est intentionnellement abstrait et peut être utilisé de multiples façons pour stocker des données et créer de nouvelles fonctionnalités. Vous trouverez des ressources personnalisées dans de nombreux outils communautaires populaires : Cert-Manager définit les objets qui représentent les certificats SSL et les émetteurs, tandis que Helm représente les graphiques comme leur propre CRD.
Sommaire
Qu’est-ce qui fait une ressource ?
Les ressources Kubernetes définissent les types de données que vous pouvez stocker dans votre cluster. Ils sont accessibles via l’API Kubernetes qui fournit des points de terminaison pour créer, répertorier et modifier des éléments dans chaque type de ressource.
Vous pouvez ajouter des ressources personnalisées pour stocker vos propres données arbitraires dans votre cluster. Les éléments que vous créez seront stockés par le composant de plan de contrôle etcd, aux côtés des instances de ressources intégrées. Les ressources personnalisées sont automatiquement affichées par l’API, vous n’avez donc pas besoin de configurer vos propres outils pour créer des instances d’élément.
Les CRD agissent par défaut comme de simples structures de données. Bien que les CRD dans la nature aient souvent leurs propres comportements, cela n’est pas fourni par le mécanisme CRD. Les contrôleurs et opérateurs Kubernetes personnalisés peuvent être utilisés pour implémenter des fonctionnalités autour de ressources personnalisées. Sans contrôleur, les éléments d’un CRD existeront toujours en tant que données statiques dans le cluster avec lesquelles vous pouvez interagir via les points de terminaison CRUD fournis par l’API Kubernetes.
Les CRD sont des composants dynamiques qui peuvent être créés et supprimés à tout moment. Certains types d’objets inclus dans Kubernetes sont également implémentés en tant que CRD, ce qui offre une plus grande modularité au cœur du cluster.
Création d’un CRD
Les CRD sont eux-mêmes un type d’objet Kubernetes. Vous les créez de la même manière que n’importe quelle autre ressource, en écrivant un fichier YAML et en l’appliquant à votre cluster :
apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: custom-apps.crds.example.com spec: group: crds.example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: app-name: type: string app-version: type: string release-count: type: integer scope: Namespaced names: plural: custom-apps singular: custom-app kind: CustomApp
Utilisez Kubectl pour ajouter le CustomApp CRD à votre cluster :
$ kubectl apply -f custom-apps-crd.yaml customresourcedefinition.apiextensions.k8s.io/custom-apps.crds.example.com created
Le fichier YAML définit un CRD qui peut être utilisé pour stocker des données sur les applications. Les CRD ont besoin d’un metadata.name et spec.group champ dans un format précis : le groupe prend la forme d’un sous-domaine auquel appartient le CRD. Le même sous-domaine doit être inclus dans les CRD metadata.name . La valeur de names.plural est ajouté en tant que nouveau composant de sous-domaine pour créer la version finale metadata.name.
La spec.names Le champ définit comment vous ferez référence au CRD lors de l’utilisation de l’API Kubernetes et des commandes Kubectl. Dans cet exemple, vous pourrez exécuter kubectl get custom-apps et kubectl get custom-app/example-app pour interagir avec les objets qui utilisent le CRD. Lorsque vous créez un nouvel objet en tant que fichier YAML, vous devez définir kind: CustomApp pour en faire une instance du CRD.
Le CRD est configuré comme un type d’objet au niveau de l’espace de noms par le scope champ. Vous pouvez utiliser Cluster comme valeur alternative pour ce champ afin de créer des objets qui existent au niveau du cluster, en dehors de tout espace de noms.
Les données associées à vos objets personnalisés sont définies dans le spec.versions.schema.openAPIV3Schema champ. Chaque « version » répertoriée crée une nouvelle version de l’API du CRD que vous pouvez référencer avec le apiVersion dans vos fichiers YAML de ressources. Les données du CRD sont configurées à l’aide des propriétés OpenAPI ; ici, chaque « application personnalisée » de votre cluster doit avoir app-name, app-versionet release-count propriétés définies dans son YAML spec.
Utilisation de votre CRD
Le provisionnement des points de terminaison d’API d’un nouveau CRD peut prendre quelques minutes. Vérifiez la progression en récupérant les détails du CRD avec Kubectl :
$ kubectl describe crd custom-apps.crds.example.com
...
Status:
Accepted Names:
Kind: CustomApp
List Kind: CustomAppList
Plural: custom-apps
Singular: custom-app
Conditions:
Last Transition Time: 2022-04-04T13:29:24Z
Message: no conflicts found
Reason: NoConflicts
Status: True
Type: NamesAccepted
Last Transition Time: 2022-04-04T13:29:24Z
Message: the initial names have been accepted
Reason: InitialNamesAccepted
Status: True
Type: Established
...
Le CRD est prêt à être utilisé lorsque vous voyez Type: Established vers la fin de la sortie de la commande. Kubernetes acceptera les demandes adressées au point de terminaison API du CRD. Dans ce cas, l’URL de base de l’API sera la suivante :
/apis/custom-apps.crds.example.com/v1/namespaces/*/custom-apps/...
Vous pouvez maintenant utiliser Kubectl pour afficher les objets qui ont été créés avec le CRD :
$ kubectl get custom-apps No resources found in default namespace.
Bien qu’aucun objet n’existe encore, Kubernetes sait maintenant qu’il a un type de ressource appelé custom-apps.
Pour créer un objet « application personnalisée », écrivez un nouveau fichier YAML avec kind: CustomApp. La apiVersion doit être défini sur le nom du groupe et la version de l’API fournis par le CRD. Au sein de la spec incluez les propriétés que vous avez définies dans le schéma du CRD.
apiVersion: crds.example.com/v1 kind: CustomApp metadata: name: demo-app-1 spec: app-name: demo-app app-version: 1.1.0 release-count: 5
Utilisez Kubectl pour ajouter l’objet à votre cluster :
$ kubectl apply -f custom-app.yaml customapp.crds.example.com/demo-app created
Vous pouvez maintenant récupérer les détails de l’objet à l’aide des commandes Kubectl habituelles :
$ kubectl describe custom-app/demo-app-1 Name: demo-app Namespace: default Labels: <none> Annotations: <none> API Version: crds.example.com/v1 Kind: CustomApp ... Spec: App - Name: demo-app App - Version: 1.1.0 Release - Count: 5 ... Events: <none>
Vous disposez d’une ressource personnalisée fonctionnelle qui stocke maintenant certaines données dans votre cluster Kubernetes. Vous pouvez supprimer le CRD en le supprimant dans Kubectl ; cela nettoiera automatiquement tous les objets qui l’utilisent.
$ kubectl delete crd custom-apps.crds.example.com customresourcedefinition.apiextensions.k8s.io "custom-apps.crds.example.com" deleted
Construire des API déclaratives avec des CRD
Ce CRD n’ajoute aucune fonctionnalité au cluster. Il stocke les données, fournit une API pour interagir avec elles et peut être référencé par d’autres objets. Les CRD deviennent plus puissants lorsqu’ils sont associés à un contrôleur personnalisé qui peut prendre la responsabilité de les gérer.
Les contrôleurs suivent les ressources et prennent des mesures en réponse à leurs événements. L’écriture d’un contrôleur pour vos CRD vous permet de les transformer en API déclaratives qui provoquent de réels changements au sein de votre cluster. Vos objets peuvent représenter le voulu état, au lieu de l’état actuel précis.
Cert-Manager utilise ce modèle pour acquérir automatiquement des certificats SSL lorsque de nouveaux objets CertificateRequest apparaissent dans votre cluster. Au sein du cœur de Kubernetes, les nœuds extraient et exécutent des images de conteneur en réponse à l’apparition de pods. Les contrôleurs vous permettent d’attacher un comportement à vos propres CRD, de sorte que l’ajout d’une « application personnalisée » pourrait entraîner la récupération de sa configuration à partir d’un service externe. Vous pouvez commencer à créer des contrôleurs en utilisant le SDK Go pour intégrer votre propre code à l’environnement d’exécution Kubernetes.
Quand utiliser les CRD ?
Les CRD sont mieux utilisés pour gérer les données internes à votre organisation, équipe ou projet. Ils sont conçus pour représenter des schémas clairement définis, sous forme de valeurs statiques ou d’API déclaratives soutenues par une implémentation de contrôleur personnalisée.
Les fonctionnalités avancées vous permettent d’implémenter des routines de validation pour les champs de votre schéma. Vous pouvez également utiliser des finaliseurs pour gérer les suppressions d’objets et adopter le système de gestion des versions pour gérer les modifications apportées à vos définitions CRD.
Les CRD se chevauchent parfois avec Kubernetes ConfigMaps. Ce sont des objets intégrés pour stocker les données de configuration génériques associées à vos applications. Un ConfigMap est approprié lorsque vous consommez les valeurs à un endroit spécifique de votre cluster, tel qu’un pod qui accède aux paramètres de la base de données en tant que variables d’environnement injectées à partir d’un ConfigMap.
Les CRD sont destinés à être utilisés lorsque les données doivent être un citoyen de première classe dans votre cluster. Vous pouvez créer plusieurs instances du type de ressource du CRD, interagir directement avec elles à l’aide de Kubectl et créer vos propres schémas structurés qui guident les utilisateurs vers la saisie de valeurs correctes. Ils peuvent constituer un meilleur choix lorsque les données existent indépendamment de tout autre élément de votre cluster.
Sommaire
Les définitions de ressources personnalisées (CRD) Kubernetes définissent de nouveaux types d’objets que vous pouvez utiliser avec l’API Kubernetes et Kubectl. Chaque CRD obtient sa propre API versionnée, possède un schéma structuré et peut être utilisé pour implémenter de nouvelles fonctionnalités dans le cluster lorsqu’il est soutenu par un contrôleur compagnon.
Les CRD peuvent parfois sembler compliqués et réservés aux situations avancées. Cela ne doit pas être le cas. Des CRD simples pour stocker des valeurs statiques dans votre cluster sont faciles à créer, comme illustré par l’exemple « application personnalisée » ci-dessus. Ils peuvent être utilisés pour contenir des données de cluster autonomes afin qu’elles reçoivent un traitement de première classe dans Kubernetes.
Il est également important de reconnaître où les CRD ne conviennent pas. Les objets intégrés tels que ConfigMaps et Secrets sont conçus pour s’adapter à la plupart des formes de configuration qui seront directement utilisées par les pods de votre application. L’écriture d’un CRD qui définit le schéma du fichier de configuration de votre application est généralement inutile et plus difficile à maintenir au fil du temps, car vous ne bénéficierez pas des fonctionnalités de ConfigMap telles que les mises à jour continues automatiques et l’injection de variables d’environnement.
