Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

7.3. Les plugins d’admission Webhook

En plus des plugins d’admission par défaut OpenShift Dedicated, l’admission dynamique peut être implémentée via des plugins d’admission Webhook qui appellent des serveurs webhook, afin d’étendre les fonctionnalités de la chaîne d’admission. Les serveurs Webhook sont appelés HTTP à des points de terminaison définis.

Il existe deux types de plugins d’admission webhook dans OpenShift Dedicated:

  • Au cours du processus d’admission, le plugin d’admission mutant peut effectuer des tâches, telles que l’injection d’étiquettes d’affinité.
  • À la fin du processus d’admission, le plugin d’admission de validation peut être utilisé pour s’assurer qu’un objet est configuré correctement, par exemple en veillant à ce que les étiquettes d’affinité soient comme prévu. Lorsque la validation passe, OpenShift Dedicated programme l’objet tel qu’il est configuré.

Lorsqu’une demande d’API intervient, muter ou valider les plugins d’admission utilisent la liste des webhooks externes dans la configuration et les appellent en parallèle:

  • Lorsque tous les webhooks approuvent la demande, la chaîne d’admission se poursuit.
  • Lorsque l’un des webhooks refuse la demande, la demande d’admission est refusée et le motif de ce refus est fondé sur le premier refus.
  • Lorsque plus d’un webhook refuse la demande d’admission, seule la première raison de refus est renvoyée à l’utilisateur.
  • En cas d’erreur lors de l’appel d’un webhook, la demande est refusée ou le webhook est ignoré en fonction de l’ensemble de la stratégie d’erreur. Lorsque la politique d’erreur est définie sur Ignore, la demande est acceptée sans condition en cas de défaillance. En cas d’échec de la politique, les demandes manquées sont refusées. L’utilisation d’Ignore peut entraîner un comportement imprévisible pour tous les clients.

Le diagramme suivant illustre le processus de chaîne d’admission séquentiel dans lequel plusieurs serveurs webhook sont appelés.

Figure 7.1. Chaîne d’admission API avec mutation et validation des plugins d’admission

Étape d’admission à l’API
View larger image
Étape d’admission à l’API

Exemple de cas d’utilisation du plugin d’admission webhook est où tous les pods doivent avoir un ensemble commun d’étiquettes. Dans cet exemple, le plugin d’admission mutant peut injecter des étiquettes et le plugin d’admission de validation peut vérifier que les étiquettes sont comme prévu. L’OpenShift Dedicated programmerait par la suite les pods qui incluent les étiquettes requises et rejetterait ceux qui ne le font pas.

Certains cas d’utilisation du plugin d’admission Webhook courants incluent:

  • La réservation de l’espace de noms.
  • Limiter les ressources réseau personnalisées gérées par le plugin de périphérique réseau SR-IOV.
  • La validation de classe prioritaire de pod.
Note

La valeur maximale de timeout par défaut de webhook dans OpenShift Dedicated est de 13 secondes, et elle ne peut pas être modifiée.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat