Dépannage des erreurs de webhook dans les clusters IBM Cloud Kubernetes

Résolvez les problèmes liés aux webhooks dans votre cluster IBM Cloud Kubernetes en identifiant et en déboguant le webhook problématique.

Lors de l'exécution des commandes oc, des messages d'erreur similaires aux exemples suivants s'affichent.

Error from server (InternalError): error when creating "testjob.yaml": Internal error occurred: failed calling webhook "mywebhook.test.io": Post https://admission-webhook.default.svc:443/validate?timeout=30s: dial tcp 172.21.189.228:443: connect: connection timed out

error creating namespace "test": Internal error occurred: admission plugin "MutatingAdmissionWebhook" failed to complete mutation in 13s

Les webhooks défaillants peuvent également provoquer des problèmes similaires aux suivants.

Vous ne pouvez pas créer ou modifier des pods, des secrets ou des espaces de nom.
Vous ne pouvez pas ajouter de noeuds worker à un cluster ou créer un secret qui contient la clé de chiffrement LUKS.
Vous ne pouvez pas corriger, mettre à jour ou mettre à niveau et l'échec sous-jacent est lié à la création de ressources dans le cluster.

Un problème dans le service appelé ou dans le tunnel sécurisé peut entraîner l'échec des demandes en raison de délais d'attente. Il se peut que vous ne soyez pas au courant que des webhooks de contrôle d'admission soient installés jusqu'à ce que cela se produise.

Les webhooks de contrôle d'admission permettent de valider, de modifier ou de muter des demandes d'API Kubernetes. Ces webhooks sont appelés à partir du cluster apiserver ou openshift-apiserver et appellent généralement un service s'exécutant dans le cluster. Les webhooks de contrôle d'admission comportent des règles définissant le type de ressource (pod, espace de noms, etc.) et l'opération pour laquelle ils sont appelés (création, récupération, mise à jour ou suppression).

Les webhooks ont une règle d'échec qui indique si Kubernetes peut ignorer les erreurs de connexion lors de l'appel du webhook ou si l'erreur de connexion doit entraîner l'échec de l'opération. Une ressource ValidatingWebhookConfiguration inspecte la demande alors qu'une ressource MutatingWebhookConfiguration modifie les données de la demande avant qu'elle ne soit traitée.

Les webhooks peuvent également refuser des demandes dans le cadre d'un fonctionnement normal: un webhook peut refuser des demandes qui ne respectent pas les règles de sécurité ou effectuer d'autres validations de données. Dans de tels cas, les informations d'échec contiennent une réponse denied the request avec une raison indiquant le problème.

admission webhook "mutate.configuration.upsert.appconnect.ibm.com" denied the request: version is not supported

Dans Red Hat OpenShift on IBM Cloud, les webhooks qui appellent les services exécutés dans le cluster le font à l'aide d'un tunnel sécurisé qui connecte le plan de contrôle du cluster dans un compte IBM Cloud aux noeuds worker du cluster dans votre compte client.

Procédez comme suit pour identifier le webhook à l'origine du problème. Ensuite, déboguez le service associé et supprimez ou recréez votre webhook si nécessaire.

Exécutez les commandes suivantes pour obtenir les journaux de pod VPN. Si vous ne pouvez pas obtenir les journaux VPN, suivez les étapes de la rubrique Debug common CLI issues et revenez à cette page lorsque vous pouvez extraire les journaux. Si les commandes aboutissent et que vous pouvez obtenir les journaux, le tunnel VPN fonctionne et vous pouvez passer à l'étape suivante.
```
oc get pods -n kube-system -l app=vpn
```
```
oc logs -n kube-system -l app=vpn
```
Décrivez vos webhooks de contrôle d'admission et sauvegardez la sortie dans un fichier appelé webhooks.txt.
```
kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
```
Recherchez les messages d'erreur dans le fichier webhooks.txt. Les messages d'erreur liés au webhook provenant d'une application, y compris oc, peuvent aider à identifier le webhook.
Passez en revue les métriques apiserver pour le type de rejet, le nombre et le code de rejet. Vous pouvez obtenir un aperçu des métriques à l'aide de la commande suivante.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_rejection_count
```
```
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="check-ignore-label.gatekeeper.sh",operation="UPDATE",rejection_code="0",type="validating"} 16
```
Une valeur rejection_code de 0 indique qu'une erreur s'est produite lors de l'appel du webhook. Une valeur rejection_code différente de zéro indique que le webhook a rejeté la demande.

Il existe 3 instances apiserver. La commande oc extrait les métriques de l'une d'entre elles et reflète l'activité qui s'y trouve. Chaque serveur d'API renvoie des données différentes. Les instances qui n'ont pas traité les demandes ayant échoué risquent de ne pas renvoyer cette métrique.
Examinez le résultat de la commande des étapes précédentes et recherchez les descriptions de webhook pour identifier la valeur MutatingWebhookConfiguration ou ValidatingWebhookConfiguration spécifique. Si les erreurs, les journaux ou les métriques n'aident pas, passez en revue les descriptions de webhook que vous avez extraites précédemment. Chaque configuration de webhook comporte un ensemble de règles qui spécifient les types de ressources et d'actions pour lesquels le webhook est appelé. Ces informations peuvent être utilisées pour identifier le (s) webhook (s) pouvant être impliqué (s).
- En cas d'erreur lors de l'appel du webhook, consultez la documentation de ce service pour connaître les étapes de débogage spécifiques au produit.
- Si le webhook rejette les demandes, examinez les règles et les options de configuration du webhook. Il peut être possible de les ajuster pour autoriser la demande. Il se peut également que la demande viole les règles et que la demande ou l'application à l'origine de la demande doive être modifiée. Pour plus d'informations, voir Quelles sont les meilleures pratiques d'utilisation des webhooks.

Vérification du service appelé par le webhook

Obtenez les détails du service et de ses noeuds finaux.
```
kubectl get svc NAME -n NAMESPACE
```
```
kubectl get ep NAME -n NAMESPACE
```
- Si le webhook appelle un service qui n'existe pas, il se peut que le webhook soit retiré d'une suppression incomplète ou incorrecte d'une application. Dans ce cas, recherchez la documentation spécifique au service et suivez les étapes de désinstallation du service.
- Si vous ne parvenez pas à désinstaller le service, supprimez la configuration de webhook.
```
    kubectl delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    kubectl delete mutatingwebhookconfiguration NAME
    ```
```
Si le service existe mais n'a pas de noeud final, vérifiez la santé des pods. Tout d'abord, obtenez les libellés de pod du service.
```
kubectl describe svc NAME -n NAMESPACE
```
Exemple de sortie
```
Selector:          app=my-webhook
```
Répertoriez les pods qui utilisent ces étiquettes. Par exemple, le libellé de la commande suivante est app=mywebhook.
```
kubectl get pods -n NAMESPACE -l app=my-webhook
```
Consultez la sortie de la commande. Si les pods ne sont pas opérationnels, vérifiez les événements des pods, les journaux, l'état des nœuds de travail et les autres composants pour résoudre le problème. Pour plus d'informations, voir Débogage de déploiements d'application.

Désactivation ou suppression d'un webhook

Ignorez temporairement les connexions et les délais d'attente en définissant la règle d'échec sur Ignore. Modifiez le webhook en exécutant les commandes suivantes.
```
kubectl edit validatingwebhookconfiguration NAME
```
```
kubectl edit mutatingwebhookconfiguration NAME
```
Recherchez failurePolicy et remplacez la valeur par Ignore.
Enregistrez la configuration et quittez l'éditeur. Si l'ajustement de la règle d'échec ne résout pas le problème, répétez les étapes précédentes et redéfinissez la valeur sur Fail.

Retirez temporairement le webhook. Sauvegardez la configuration de webhook existante dans un fichier avant de la supprimer.

kubectl get validatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

kubectl get mutatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

Supprimez la configuration de webhook.

kubectl delete validatingwebhookconfiguration NAME

kubectl delete mutatingwebhookconfiguration NAME

Patientez quelques minutes, puis relancez les commandes kubectl qui n'ont pas réussi à déterminer si le problème a été résolu.
Recréez le webhook.
```
kubectl apply -f webhook-config.yaml
```
Si le problème persiste, contactez l'assistance. Ouverture d'un cas de support. Dans les détails du cas, veillez à inclure les fichiers journaux, les messages d'erreur ou les sorties de commande appropriés.