Pourquoi les opérations du maître de cluster échouent-elles en raison d'un webhook défectueux?

Cloud privé virtuel Infrastructure classique

Cette rubrique de traitement des incidents ne concerne pas le traitement des incidents liés aux webhooks généraux. Voir Débogage de webhooks pour les problèmes de webhook non liés à la mise à jour du maître cluster.

Dépanner les problèmes liés à des webhooks défectueux qui interfèrent avec les opérations du maître de cluster.

Lors d'une opération de maître telle que la mise à jour de votre version de cluster, une application de webhook endommagée a été détectée sur le cluster.

Maintenant, les opérations principales ne peuvent pas être terminées. Un message d'erreur semblable à celui présenté ci-dessous s'affiche :

Cannot complete cluster master operations because the cluster has a broken webhook application. For more information, see the troubleshooting docs: 'https://ibm.biz/master_webhook'

Votre cluster dispose de ressources de webhook Kubernetes configurables, des webhooks de validation ou de modification, qui peuvent intercepter et modifier des demandes émises par différents services du cluster sur le serveur d'API dans le maître cluster.

Etant donné que les webhooks peuvent modifier ou rejeter des demandes, ceux qui sont endommagés peuvent impacter de différentes manières la fonctionnalité du cluster, par exemple, en vous empêchant de mettre à jour la version maître ou d'effectuer d'autres opérations de maintenance. Pour plus d’informations, consultez la section Dynamic Admission Control dans la documentation d’ Kubernetes.

Les webhooks peuvent être endommagés pour différentes raisons, notamment :

La ressource sous-jacente qui émet la demande est manquante ou défectueuse, par exemple, un service Kubernetes, un noeud final ou un pod.
Le webhook fait partie d'un module complémentaire ou de toute autre application plug-in qui ne se sont pas installés correctement ou qui sont défectueux.
Votre cluster peut présenter un problème de connectivité réseau qui empêche le webhook de communiquer avec le serveur d'API Kubernetes dans le maître cluster.

Exécutez les commandes suivantes pour créer un pod de test afin d'obtenir une erreur qui identifie le webhook défectueux. Si le test réussit, l'échec était peut-être temporaire et il est possible de réessayer.

Exécutez les commandes suivantes pour créer le module de test et étiqueter l'espace de noms ibm-system.

oc run webhook-test --image us.icr.io/armada-master/pause:3.10 -n ibm-system
oc delete pod -n ibm-system webhook-test --ignore-not-found
oc label ns ibm-system ibm-cloud.kubernetes.io/webhook-test-at="$(date -u +%FT%H_%M_%SZ)" --overwrite

Le message d'erreur peut comporter le nom du webhook endommagé. Dans l'exemple de résultat suivant, le webhook est trust.hooks.securityenforcement.admission.cloud.ibm.com.

Error from server (InternalError): Internal error occurred: failed calling webhook "trust.hooks.securityenforcementadmission.cloud.ibm.com": Post https://ibmcloud-image-enforcement.ibm-system.svc:443/mutating-pods?timeout=30s: dialtcp 172.21.xxx.xxx:443: connect: connection timed out

Obtenez le nom du webhook endommagé.

Si le message d'erreur mentionne un webhook endommagé, remplacez trust.hooks.securityenforcement.admission.cloud.ibm.com par le webhook endommagé que vous avez précédemment identifié.

    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations -o jsonpath='{.items[?(@.webhooks[*].name=="trust.hooks.securityenforcement.admission.cloud.ibm.com")].metadata.name}{"\n"}'
    ```
    Exemple de sortie
    ```sh {: pre}
    image-admission-config
    ```
*   Si le message d'erreur ne mentionne pas de webhook endommagé, répertoriez tous les webhooks présents dans votre cluster et vérifiez leur configuration en procédant comme indiqué ci-après.
```sh {: pre}
    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations
    ```

Passez en revue les détails de service et d'emplacement de la configuration de webhook de modification ou de validation dans la section clientConfig de la sortie de la commande ci-après. Remplacez image-admission-config par le nom que vous avez précédemment identifié. Si le webhook se trouve en dehors du cluster, contactez le propriétaire de celui-ci pour vérifier la statut du webhook.
```
oc get mutatingwebhookconfiguration image-admission-config -o yaml
```
```
oc get validatingwebhookconfigurations image-admission-config -o yaml
```
Exemple de sortie
```
  clientConfig:
    caBundle: <redacted>
    service:
        name: <name>
        namespace: <namespace>
        path: /inject
        port: 443
```
En option: sauvegardez les webhooks, en particulier si vous ne savez pas comment réinstaller le webhook ou si vous ne disposez pas des autorisations nécessaires pour créer des webhooks.
```
oc get mutatingwebhookconfiguration <name> -o yaml > mutatingwebhook-backup.yaml
```
```
oc get validatingwebhookconfiguration <name> -o yaml > validatingwebhook-backup.yaml
```

Vérifiez le statut du service et des pods connexes pour le webhook.

Vérifiez les zones Type, Sélecteur et Noeud final du service.

    oc describe service -n <namespace> <service_name>
    ```
2. Si le type de service est **ClusterIP**, vérifiez que le pod Konnectivity est en état **Running** afin que le webhook puisse se connecter en toute sécurité à l'API Kubernetes sur le maître du cluster. Si le pod est défectueux, vérifiez les événements de pod, les journaux, la santé du noeud worker et d'autres composants à déboguer.

    * Vérifiez les pods de l'agent de konnectivité.
        ```sh {: pre}
        oc describe pods -n kube-system -l app=konnectivity-agent
        ```

1. Si le service ne comporte pas de noeud final, vérifiez la santé des ressources de sauvegarde, telles qu'un déploiement ou un pod. Si la ressource est défectueuse, vérifiez les événements de pod, les journaux, la santé du noeud worker et d'autres composants à déboguer. Pour plus d'informations, voir [Débogage de déploiements d'application](/docs/openshift?topic=openshift-debug_apps).
```sh {: pre}
    oc get all -n my-service-namespace -l <key=value>
    ```
1. Si le service ne dispose d'aucune ressource de secours, ou si le dépannage des pods ne permet pas de résoudre le problème, supprimez la configuration du webhook de mutation ou de validation identifiée précédemment.
```sh {: pre}
    oc delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    oc delete mutatingwebhookconfiguration NAME
    ```

Réessayez l'opération de maître cluster, telle que la mise à jour du cluster.
Si l'erreur persiste, cela peut être dû à des problèmes liés au noeud worker ou à la connectivité réseau.
- Consultez Traitement des incidents liés au noeud worker.
- Assurez-vous que le webhook peut se connecter au serveur d'API Kubernetes dans le maître cluster. Par exemple, si vous utilisez des règles réseau Calico, des groupes de sécurité ou tout autre type de pare-feu, configurez votre cluster classique ou VPC avec l'accès approprié.
- Si le webhook est géré par un module complémentaire que vous avez installé, désinstallez ce dernier. Le module complémentaire suivant fait partie des modules complémentaires courants qui génèrent des problèmes de webhook :
  - Portieris
Recréez le webhook ou désinstallez le module complémentaire.
Si le problème persiste, contactez l'assistance. Ouverture d'un cas de support. Dans les détails de l'affaire, veillez à inclure tout fichier journal, message d'erreur ou résultat de commande pertinent.