5.10. Valider les opérateurs à l'aide de la carte de score
En tant qu'auteur de l'opérateur, vous pouvez utiliser l'outil de scorecard dans le SDK de l'opérateur pour effectuer les tâches suivantes :
- Validez que votre projet Operator ne contient pas d'erreurs de syntaxe et qu'il est correctement empaqueté
- Examinez les suggestions d'amélioration de votre opérateur
5.10.1. A propos de l'outil carte de score Copier lienLien copié sur presse-papiers!
Alors que la sous-commande Operator SDK bundle validate
peut valider le contenu et la structure des répertoires de bundle locaux et des images de bundle distantes, vous pouvez utiliser la commande scorecard
pour exécuter des tests sur votre Operator sur la base d'un fichier de configuration et d'images de test. Ces tests sont mis en œuvre dans des images de test qui sont configurées et construites pour être exécutées par le scorecard.
Le scorecard suppose qu'il est exécuté avec un accès à un cluster Kubernetes configuré, tel que OpenShift Container Platform. Le scorecard exécute chaque test dans un pod, à partir duquel les journaux du pod sont agrégés et les résultats des tests sont envoyés à la console. Le scorecard intègre des tests de base et des tests OLM (Operator Lifecycle Manager) et fournit également un moyen d'exécuter des définitions de test personnalisées.
Flux de travail du tableau de bord
- Créer toutes les ressources requises par les ressources personnalisées (RC) et l'opérateur
- Créer un conteneur proxy dans le déploiement de l'opérateur pour enregistrer les appels au serveur API et exécuter les tests
- Examiner les paramètres dans les CR
Les tests du tableau de bord ne font aucune supposition quant à l'état de l'opérateur testé. La création d'opérateurs et de CR pour un opérateur dépasse le champ d'application du tableau de bord lui-même. Les tests du tableau de bord peuvent toutefois créer toutes les ressources dont ils ont besoin si les tests sont conçus pour la création de ressources.
scorecard
syntaxe de la commande
operator-sdk scorecard <bundle_dir_ou_image> [flags] (drapeaux)
$ operator-sdk scorecard <bundle_dir_ou_image> [flags] (drapeaux)
Le tableau de bord requiert un argument de position pour le chemin d'accès au disque de votre groupe d'opérateurs ou le nom d'une image de groupe.
Pour plus d'informations sur les drapeaux, cliquez ici :
operator-sdk scorecard -h
$ operator-sdk scorecard -h
5.10.2. Configuration du tableau de bord Copier lienLien copié sur presse-papiers!
L'outil scorecard utilise une configuration qui vous permet de configurer des plugins internes, ainsi que plusieurs options de configuration globales. Les tests sont pilotés par un fichier de configuration nommé config.yaml
, qui est généré par la commande make bundle
, située dans votre répertoire bundle/
:
./bundle ... └── tests └── scorecard └── config.yaml
./bundle
...
└── tests
└── scorecard
└── config.yaml
Exemple de fichier de configuration d'un scorecard
Le fichier de configuration définit chaque test que le scorecard peut exécuter. Les champs suivants du fichier de configuration du scorecard définissent le test comme suit :
Champ de configuration | Description |
---|---|
| Nom de l'image du conteneur de test qui met en œuvre un test |
| Commande et arguments invoqués dans l'image de test pour exécuter un test |
| Étiquettes personnalisées ou définies dans le tableau de bord permettant de sélectionner les tests à effectuer |
5.10.3. Tests de cartes de pointage intégrés Copier lienLien copié sur presse-papiers!
Le tableau de bord est livré avec des tests prédéfinis qui sont organisés en suites : la suite de tests de base et la suite Operator Lifecycle Manager (OLM).
Test | Description | Nom court |
---|---|---|
Existence d'un bloc de spécifications |
Ce test vérifie que toutes les ressources personnalisées (CR) créées dans le cluster disposent d'un bloc |
|
Test | Description | Nom court |
---|---|---|
Validation de l'offre groupée | Ce test valide les manifestes de la liasse trouvés dans la liasse qui est passée dans le scorecard. Si le contenu de la liasse contient des erreurs, le résultat du test comprend le journal du validateur ainsi que les messages d'erreur de la bibliothèque de validation. |
|
Les API fournies sont validées |
Ce test permet de vérifier que les définitions de ressources personnalisées (CRD) pour les CR fournis contiennent une section de validation et qu'il existe une validation pour chaque champ |
|
Les CRD possédés ont des ressources répertoriées |
Ce test vérifie que les CRD de chaque CR fourni via l'option |
|
Champs spécifiques avec descripteurs |
Ce test permet de vérifier que chaque champ des sections CRs |
|
Champs d'état avec descripteurs |
Ce test permet de vérifier que chaque champ des sections CRs |
|
5.10.4. Exécution de l'outil de tableau de bord Copier lienLien copié sur presse-papiers!
Un ensemble de fichiers Kustomize par défaut est généré par le SDK de l'opérateur après l'exécution de la commande init
. Le fichier par défaut bundle/tests/scorecard/config.yaml
qui est généré peut être immédiatement utilisé pour exécuter l'outil de scorecard avec votre opérateur, ou vous pouvez modifier ce fichier selon les spécifications de votre test.
Conditions préalables
- Projet d'opérateur généré à l'aide de l'Operator SDK
Procédure
Générer ou régénérer les manifestes et les métadonnées de vos bundles pour votre opérateur :
make bundle
$ make bundle
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cette commande ajoute automatiquement des annotations de scorecard aux métadonnées de votre bundle, qui sont utilisées par la commande
scorecard
pour exécuter les tests.Exécutez le tableau de bord en fonction du chemin d'accès au disque de votre groupe d'opérateurs ou du nom d'une image de groupe :
operator-sdk scorecard <bundle_dir_or_image>
$ operator-sdk scorecard <bundle_dir_or_image>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.10.5. Résultats du tableau de bord Copier lienLien copié sur presse-papiers!
L'option --output
de la commande scorecard
spécifie le format de sortie des résultats de la carte de score : text
ou json
.
Exemple 5.15. Exemple d'extrait de sortie JSON
Exemple 5.16. Exemple d'extrait de texte
La spécification du format de sortie correspond à la présentation du type Test
de la présentation du type.
5.10.6. Sélection des tests Copier lienLien copié sur presse-papiers!
Les tests du tableau de bord sont sélectionnés en associant l'indicateur CLI --selector
à un ensemble de chaînes d'étiquettes. Si aucun drapeau de sélection n'est fourni, tous les tests contenus dans le fichier de configuration du tableau de bord sont exécutés.
Les tests sont exécutés en série, les résultats étant agrégés par le tableau de bord et écrits sur la sortie standard, ou stdout.
Procédure
Pour sélectionner un seul test, par exemple
basic-check-spec-test
, spécifiez le test en utilisant l'indicateur--selector
:operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=test=basic-check-spec-test
$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=test=basic-check-spec-test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour sélectionner une série de tests, par exemple
olm
, indiquez une étiquette utilisée par tous les tests OLM :operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=suite=olm
$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector=suite=olm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour sélectionner plusieurs tests, spécifiez les noms des tests à l'aide de l'indicateur
selector
en utilisant la syntaxe suivante :operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector='test in (basic-check-spec-test,olm-bundle-validation-test)'
$ operator-sdk scorecard <bundle_dir_or_image> \ -o text \ --selector='test in (basic-check-spec-test,olm-bundle-validation-test)'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.10.7. Permettre des tests en parallèle Copier lienLien copié sur presse-papiers!
En tant qu'auteur d'un opérateur, vous pouvez définir des étapes distinctes pour vos tests à l'aide du fichier de configuration du tableau de bord. Les étapes s'exécutent séquentiellement dans l'ordre où elles sont définies dans le fichier de configuration. Une étape contient une liste de tests et un paramètre configurable parallel
.
Par défaut, ou lorsqu'une étape définit explicitement parallel
à false
, les tests d'une étape sont exécutés séquentiellement dans l'ordre où ils sont définis dans le fichier de configuration. L'exécution des tests un par un est utile pour garantir que deux tests n'interagissent pas et n'entrent pas en conflit l'un avec l'autre.
Toutefois, si les tests sont conçus pour être totalement isolés, ils peuvent être parallélisés.
Procédure
Pour exécuter un ensemble de tests isolés en parallèle, incluez-les dans la même étape et fixez
parallel
àtrue
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Permet de réaliser des tests en parallèle
Tous les tests d'une étape parallèle sont exécutés simultanément, et Scorecard attend qu'ils soient tous terminés avant de passer à l'étape suivante. Vos tests peuvent ainsi s'exécuter beaucoup plus rapidement.
5.10.8. Tests personnalisés des cartes de pointage Copier lienLien copié sur presse-papiers!
L'outil de tableau de bord peut exécuter des tests personnalisés qui respectent ces conventions obligatoires :
- Les tests sont mis en œuvre dans une image conteneur
- Les tests acceptent un point d'entrée comprenant une commande et des arguments
-
Les tests produisent la carte de score
v1alpha3
au format JSON, sans journalisation superflue dans la sortie du test -
Les tests peuvent obtenir le contenu du paquet à un point de montage partagé de
/bundle
- Les tests peuvent accéder à l'API Kubernetes à l'aide d'une connexion client dans le cluster
Il est possible d'écrire des tests personnalisés dans d'autres langages de programmation si l'image de test suit les lignes directrices ci-dessus.
L'exemple suivant montre une image de test personnalisée écrite en Go :
Exemple 5.17. Exemple de test de scorecard personnalisé