9.3. Plugins d'admission aux webhooks
En plus des plugins d'admission par défaut d'OpenShift Container Platform, l'admission dynamique peut être mise en œuvre via des plugins d'admission webhook qui appellent des serveurs webhook, afin d'étendre la fonctionnalité de la chaîne d'admission. Les serveurs webhook sont appelés via HTTP à des points d'extrémité définis.
Il existe deux types de plugins d'admission de webhook dans OpenShift Container Platform :
- Au cours du processus d'admission, le site mutating admission plugin peut effectuer des tâches telles que l'injection d'étiquettes d'affinité.
- À la fin du processus d'admission, le site validating admission plugin peut être utilisé pour s'assurer qu'un objet est correctement configuré, par exemple en s'assurant que les étiquettes d'affinité sont conformes aux attentes. Si la validation passe, OpenShift Container Platform planifie l'objet tel qu'il est configuré.
Lorsqu'une demande d'API arrive, les plugins d'admission de mutation ou de validation utilisent la liste des webhooks externes dans la configuration et les appellent en parallèle :
- Si tous les webhooks approuvent la demande, la chaîne d'admission se poursuit.
- Si l'un des webhooks refuse la demande, la demande d'admission est refusée et la raison de ce refus est basée sur le premier refus.
- Si plusieurs webhooks refusent la demande d'admission, seul le premier motif de refus est renvoyé à 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 la politique d'erreur définie. Si la politique d'erreur est définie sur
Ignore, la demande est acceptée sans condition en cas d'échec. Si la politique est définie surFail, les demandes qui échouent sont refusées. L'utilisation deIgnorepeut entraîner un comportement imprévisible pour tous les clients.
La communication entre le plugin webhook admission et le serveur webhook doit utiliser TLS. Générez un certificat d'autorité de certification et utilisez-le pour signer le certificat de serveur utilisé par votre serveur d'admission au webhook. Le certificat d'autorité de certification codé en PEM est fourni au plugin de webhook admission à l'aide d'un mécanisme tel que le service serving certificate secrets.
Le diagramme suivant illustre le processus séquentiel de la chaîne d'admission dans lequel plusieurs serveurs de webhook sont appelés.
Figure 9.1. Chaîne d'admission de l'API avec des plugins d'admission mutants et validants
Un exemple de cas d'utilisation du plugin d'admission webhook est celui 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 validant peut vérifier que les étiquettes sont conformes aux attentes. OpenShift Container Platform planifierait ensuite les pods qui incluent les labels requis et rejetterait ceux qui ne les incluent pas.
Voici quelques cas d'utilisation courants des plugins d'admission aux webhooks :
- Réservation d'espace de noms.
- Limitation des ressources réseau personnalisées gérées par le plugin de périphérique réseau SR-IOV.
- Définition de tolérances permettant aux taints de déterminer quels pods doivent être planifiés sur un nœud.
- Validation de la classe de priorité des pods.
La valeur par défaut du délai d'attente du webhook dans OpenShift Container Platform est de 13 secondes et ne peut pas être modifiée.
