Puis-je créer mes propres contrôleurs d'admission ?

Oui, voir la documentation Kubernetes et Red Hat OpenShift pour plus d'informations.

Comme indiqué dans la documentation Kubernetes, vous pouvez utiliser des contrôleurs d'admission pour des opérations qui sont par ailleurs gérées par le plan de contrôle. Par conséquent, soyez prudent lorsque vous configurez un contrôleur d'admission personnalisé. Vous êtes responsable des modifications apportées dans votre cluster en raison d'un contrôleur d'admission personnalisé.

Quelles sont les meilleures pratiques pour l'utilisation des webhooks?

Évitez autant que possible d'utiliser des webhooks. Utilisez plutôt les touches ValidatingAdmissionPolicy et MutatingAdmissionPolicy (lorsqu'elles sont activées par défaut) comme alternatives.

Si vous devez utiliser des webhooks, gardez à l'esprit les meilleures pratiques et considérations suivantes lorsque vous configurez un webhook.

• N'utilisez pas les webhooks de mutation pour muter des ressources appartenant à un autre contrôleur ou opérateur. Cela pourrait entraîner une boucle de réconciliation infinie entre le propriétaire de la ressource et le webhook. Les Webhooks peuvent déterminer la propriété de la ressource en vérifiant si metadata.ownerReferences est défini dans les données de la ressource. Par exemple, une ressource Kubernetes replicaset appartient à une ressource Kubernetes deployment et ne doit jamais être modifiée par un webhook.

• Créez des pods de réplique pour le webhook de sorte que si un pod tombe en panne, le webhook puisse toujours traiter les demandes à partir de vos ressources. Dans la mesure du possible, répartissez les pods de réplique entre les zones.

• Définissez une option failurePolicy appropriée, par exemple, si votre webhook échoue ou ignore les échecs de connexion ou les délais d'attente. Vous pouvez affecter à failurePolicy la valeur Ignore si vous souhaitez que votre webhook ignore les erreurs de connexion et les délais d'attente. Notez que cela ne change pas le comportement de apiserver si le webhook rejette une demande.

• Vérifiez l'intervalle timeoutSeconds. Les anciens webhooks qui utilisent l'API v1beta1.admissionregistration.k8s.io ont un délai d'attente par défaut de 30 secondes. L'API v1 utilise une valeur par défaut de 10 secondes. Si la règle d'échec du webhook est Ignorer et que le timeoutSeconds en cours est 30, réduisez le délai d'attente à 10 secondes. Pour les clusters OpenShift, les composants de plan de contrôle ont souvent leur propre délai d'attente de 13 secondes.

  Évitez de laisser plusieurs webhooks mutables opérer sur les mêmes ressources. Les webhooks mutables s'exécutent de manière séquentielle. Un seul webhook mutant peut fonctionner comme prévu du point de vue des délais d'expiration et des politiques d'échec, mais lorsqu'il est combiné à d'autres webhooks mutants qui opèrent sur la même ressource, les webhooks mutants peuvent dépasser le délai d'expiration total accordé pour l'exécution de tous les webhooks.

• Définissez des demandes et des limites de ressource d'UC et de mémoire appropriées pour votre webhook.

• Ajoutez des sondes de disponibilité et de réactivité pour vous assurer que votre conteneur de webhook est en cours d'exécution et prêt à traiter les requêtes.

• Définissez des règles de planification d'anti-affinité pour faire en sorte que vos pods de webhook s'exécutent de préférence sur d'autres zones et noeuds worker dans la mesure du possible. Vous pouvez utiliser la topologie de pod à la place. Évitez toutefois les contraintes ou les affinités imposées qui pourraient limiter les emplacements où les pods de webhook peuvent être planifiés.

• Définir la priorité du pod à system-cluster-critical pour les points webhook de sorte que les autres pods ne puissent pas utiliser les ressources de pods webhook.

• Définissez la portée de votre webhook au projet approprié. Évitez d'utiliser des webhooks qui traitent des ressources exécutées dans des projets critiques pour le système, configurés par défaut dans votre cluster, tels que les projets kube-system, ibm-system, ibm-operators, calico-apiserver, calico-system, tigera-operator et openshift-*.

• Passez en revue l'option namespaceSelector. Vous pouvez ajouter des libellés à certains espaces de nom critiques, tels que kube-system, de sorte que le webhook n'est pas appelé pour ces cas. Cette configuration est appelée configuration de style "opt-out". Vous pouvez également configurer l'option namespaceSelector de sorte que le webhook soit appelé uniquement pour les espaces de nom ayant un libellé spécifique. Cette configuration est appelée configuration "opt-in". Selon l'objectif du webhook, il peut être important que le webhook soit appelé pour tous les espaces de nom. Passez en revue les options de configuration namespaceSelector dans la documentationKubernetes et ajustez votre configuration de webhook.

• Assurez-vous que les nœuds de travail de votre cluster ont la taille adéquate pour exécuter vos applications webhook. Par exemple, si vos pods nécessitent plus d'UC ou de mémoire que ne peut en fournir le noeud worker, les pods ne sont pas planifiés.

Quels autres types d'applications utilisent des contrôleurs d'admission ?

De nombreux modules complémentaires, plug-in et autres extensions tierces de cluster utilisent des contrôleurs d'admission. Parmi les plus courants :

• Portieris

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

J'ai besoin d'aide avec un webhook qui ne fonctionne pas. Que puis-je faire ?

Pour obtenir de l'aide sur l'identification et la résolution des problèmes liés aux webhooks, voir Débogage des webhooks ou Cluster can't update due of broken webhook.