Annexe B. Validation des ressources personnalisées
Lors de l'ajout d'une nouvelle API, le SDK de l'opérateur génère un squelette de définition de ressource personnalisée. Ce squelette est utilisable tel quel ; il n'est pas nécessaire d'effectuer d'autres modifications ou ajouts pour créer des ressources personnalisées.
Le squelette CRD atteint cette flexibilité en définissant simplement les sections spec et status qui représentent respectivement l'entrée de l'utilisateur et l'état de la ressource personnalisée, comme des objets ouverts :
spec:type:objectstatus:type:object
L'inconvénient de cette approche est que Kubernetes n'est pas en mesure de valider les données de l'un ou l'autre de ces champs. Puisque Kubernetes ne sait pas quelles valeurs doivent être autorisées ou non, tant que le manifeste s'analyse, les valeurs sont autorisées.
Pour résoudre ce problème, les CRD incluent la prise en charge de la spécification OpenAPI pour décrire les contraintes de validation de chacun de ses champs. Tu devras ajouter manuellement cette validation au CRD pour décrire les valeurs autorisées pour les sections spec et status sections.
Tu apporteras deux changements principaux à la section spec du CRD :
-
Ajoute une carte
properties. Pour chacun des attributs qui peuvent être spécifiés pour les ressources personnalisées de ce type, ajoute une entrée à cette carte ainsi que des informations sur le type de paramètre et les valeurs autorisées. -
En option, tu peux ajouter un champ
required ...