↓Aller au contenu
  1. Découvrir/

2 minutes pour comprendre... les CRDs

·3 mins
Sommaire
Étendre l’API de Kubernetes avec vos propres types d’objets.

En 2 minutes #

Les objets de type Custom Resource Definition (CRD), apparus dans la version 1.7 de Kubernetes, permettent d’étendre l’API de Kubernetes et d’y ajouter de nouveaux types d’objets. Chaque nouveau type d’objet défini par une CRD possède un schéma commun et des champs spécifiques à ce dernier. Cependant, un nouveau type d’objet créé à partir d’une CRD n’est pas exploité s’il est ajouté seul dans un cluster Kubernetes. Afin d’en tirer parti, il faudra également mettre en œuvre des opérateurs ou contrôleurs qui auront pour rôle de manipuler les objets de ce nouveau type et d’en exploiter les champs afin de réaliser différentes actions. Les nouveaux objets créés à partir des types personnalisés sont bien évidement utilisables dans les fonctionnalités natives de Kubernetes comme les RBAC, les Validating Admission Policy, etc…

Voici quelques cas d’usages des CRDs :

  • définir les spécifications d’une application personnalisée
  • utiliser Kubernetes comme API centrale pour construire des plateformes (applicatives ou d’infrastructure)
  • disposer des fonctionnalités de Kubernetes comme les systèmes d’authentification et d’autorisation pour la gestion des ressources personnalisées sur les clusters
  • avoir un standard pour la définition de nouveaux endpoint d’API
Documentation officielle

En savoir plus… #

Architecture #

Pour illustrer le format des CRDs, nous utiliserons un exemple de la documentation officielle.

Voici donc un exemple de CRD au format YAML :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # Le nom doit correspondre aux champs sous spec, sous la forme <names.plural>.<group>
  name: crontabs.stable.example.com
spec:
  # Le nom du groupe à utiliser pour l'API REST : /apis/<group>/<version>
  group: stable.example.com
  # Liste des version supportées par la CRD
  versions:
    - name: v1
      # Chaque version peut être activée/désactivée par ce champ
      served: true
      # Seulement une version doit être marquée comme storage version
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
      - ct

Dans les spécifications de cet objet (spec), on peut distinguer plusieurs champs qui sont, par ailleur, des éléments définissable dans chaque CRDs :

  • group : indique le nom du groupe de l’API, généralement défini à partir d’un nom de domaine (eg. networking.k8s.io)
  • versions : indique la ou les version(s) utilisables de l’objet, telles que v1alpha1, v1beta, v1, …
  • schema : définit le schéma de l’objet à l’aide de la spécification OpenAPI qui permet de vérifier le format de l’objet avant chaque opération en envoyant ce dernier à l’API Kubernetes
  • scope : spécifie si l’objet doit être présent dans un namespace Kubernetes (Namespaced) ou bien s’il est disponible à l’échelle du cluster (Cluster)
  • names.plural et names.singular : spécifie le nom pluriel et singulier de la ressource
  • shortNames : spécifie le nom court disponible pour les appels à cette ressource via kubectl (eg. deploy pour deployments)

Voici un exemple d’objet créé à partir du schéma de cette ressource :

1
2
3
4
5
6
7

apiVersion: stable.example.com/v1
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image

Ecosystème #

Vous pourrez trouver dans ce dépôt GitHub un grand nombre de CRDs liés à des projets et solutions populaires.

Il existe également Kubeconform qui est un projet permettant de valider le schéma des CRDs et autres ressources Kubernetes avant leur application, dans le cadre d’une CI, par exemple.

Liens complémentaires #