Pour en savoir plus sur les versions, consultez les notes de version de Distributed Cloud Connected.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Résoudre les problèmes liés à Distributed Cloud connecté

Google surveille et gère à distance les déploiements Google Distributed Cloud connecté. Pour ce faire, les ingénieurs Google disposent d'un accès Secure Shell (SSH) au matériel Distributed Cloud connecté. Si Google détecte un problème, un ingénieur Google vous contacte pour le résoudre. Si vous avez identifié un problème vous-même, contactez immédiatement l'assistance Google pour le diagnostiquer et le résoudre.

Mises à niveau logicielles de Distributed Cloud connecté

Cette section explique comment utiliser l'Explorateur de métriques pour vérifier si un cluster connecté Distributed Cloud fait l'objet d'une mise à niveau logicielle.

Cette procédure utilise les métriques Monitoring suivantes :

Version actuelle du cluster (/edge_cluster/current_cluster_version) : indique la version actuelle du logiciel Distributed Cloud connecté exécuté sur le cluster.
Version cible du cluster (/edge_cluster/target_cluster_version) : indique la version cible de Distributed Cloud connecté vers laquelle le cluster est mis à niveau.

Pour suivre la procédure décrite dans cette section, vous devez remplir les conditions préalables suivantes :

Accès à la console Google Cloud et à votre projet Google Cloud connecté à Distributed Cloud.
Le rôle IAM Lecteur Monitoring, qui vous permet d'afficher les métriques Monitoring.
(Facultatif) Valeur machine_id de la machine Distributed Cloud connectée cible pour filtrer les résultats renvoyés.

Utiliser l'explorateur de métriques pour vérifier les versions logicielles actuelle et cible du cluster

Accédez à l'explorateur de métriques :
1. Dans la console Google Cloud , accédez à la section Monitoring.
2. Dans l'arborescence de navigation de gauche, cliquez sur Explorateur de métriques.
Sélectionnez le type de ressource cible :
1. Sur la page "Explorateur de métriques", accédez à la page Configuration.
2. Cliquez sur Sélectionner une métrique.
3. Utilisez la barre de recherche pour rechercher le type de ressource Cluster. Vous pouvez également utiliser l'identifiant de ressource complet edgecontainer.googleapis.com/Cluster.
4. Dans les résultats renvoyés, cliquez sur le type de ressource Cluster.
Obtenez la version logicielle actuelle du cluster :
1. Dans la section Métrique, recherchez la valeur current_cluster_version.
2. Sélectionnez la métrique Temps d'activité de la machine. Son chemin d'accès complet est edgecontainer.googleapis.com/edge_cluster/current_cluster_version.
3. (Facultatif) Filtrez par valeur cible machine_id à l'aide de la section Filtre.
Obtenez la version logicielle cible du cluster :
1. Cliquez sur Ajouter une requête.
2. Dans la section Métrique, recherchez la valeur target_cluster_version.
3. Sélectionnez la métrique Version du cluster cible. Son chemin d'accès complet est edgecontainer.googleapis.com/edge_cluster/target_cluster_version.
4. (Facultatif) Filtrez par valeur cible machine_id à l'aide de la section Filtre.
Vérifiez l'état de la mise à niveau logicielle du cluster dans le graphique qui s'affiche.
- Si les lignes Version actuelle du cluster et Version cible du cluster indiquent des valeurs différentes, le cluster est en cours de mise à niveau logicielle.
- Si les lignes Version actuelle du cluster et Version cible du cluster indiquent la même valeur, le cluster ne fait pas l'objet d'une mise à niveau logicielle.
Vérifiez le résultat de l'étape précédente à l'aide de la commande suivante :
```
gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION
```
Remplacez les éléments suivants :
- CLUSTER_ID : ID du cluster cible.
- REGION : Google Cloud région dans laquelle le cluster a été créé.
Dans le résultat de la commande, notez les valeurs des champs suivants :
- Si la valeur du champ status est UPDATING, le cluster est en cours de mise à niveau logicielle.
- Si les valeurs des champs clusterVersion et targetVersion sont différentes, comparez-les aux valeurs renvoyées par l'explorateur de métriques.

Comprendre les résultats

Le tableau suivant explique les résultats renvoyés par l'Explorateur de métriques et la commande gcloud.

État du cluster	Diagnostic	Solution
Sain Les valeurs `currentVersion` et `targetVersion` correspondent La valeur de `status` est `RUNNING`	Le cluster exécute la version cible du logiciel Distributed Cloud connecté.	Aucune.
Mise à niveau La valeur `currentVersion` est inférieure à `targetVersion` La valeur de l'état est `UPDATING`	Le cluster est en cours de mise à niveau vers la version cible du logiciel Distributed Cloud connecté.	Surveillez le cluster dans l'explorateur de métriques jusqu'à ce que les valeurs de version actuelle et cible du cluster correspondent.
Bloqué La valeur `currentVersion` est inférieure à `targetVersion` indéfiniment La valeur de l'état est `UPDATING` indéfiniment	La mise à niveau vers la version cible du logiciel connecté Distributed Cloud a échoué sur au moins un nœud du cluster.	Vérifiez la connectivité de la machine et les journaux système. Contactez Google pour obtenir de l'aide.
Rollback La valeur `currentVersion` est supérieure à `targetVersion` La valeur de l'état est `UPDATING`	Le cluster est en train de revenir à une version précédente du logiciel Distributed Cloud connecté.	Contactez Google pour identifier la raison du rollback.

Si la mise à niveau logicielle du cluster a échoué ou si le cluster est revenu à une version logicielle précédente, vérifiez les points suivants :

État des nœuds. Vérifiez que chaque machine physique connectée à Distributed Cloud dispose d'une connectivité réseau et qu'elle indique un temps d'activité, comme décrit dans la section suivante.
Intervalles de maintenance. Vérifiez si la mise à niveau logicielle a été suspendue en raison d'un intervalle d'exclusion de maintenance.
Journaux système. Examinez les journaux système pour identifier les raisons possibles de l'échec de la mise à niveau logicielle, telles que les délais d'expiration de l'éviction des pods.

Si les étapes de résolution indiquées dans le tableau ne permettent pas de résoudre le problème, contactez l'assistance Google en indiquant la valeur machine_id de la machine concernée et l'horodatage de l'interruption.

Redémarrages de machines Distributed Cloud connecté

Cette section explique comment utiliser l'Explorateur de métriques pour vérifier si une machine physique connectée à Distributed Cloud a redémarré et déterminer la raison du redémarrage. La surveillance des redémarrages permet de déterminer s'ils faisaient partie d'une maintenance planifiée ou s'ils résultaient d'une défaillance matérielle ou d'une coupure de courant.

Cette procédure utilise les métriques Monitoring suivantes :

Temps d'activité de la machine (/machine/uptime) : indique le temps, en secondes, écoulé depuis le dernier redémarrage.
Redémarrages de la machine (/machine/restart_count) : indique le nombre total de redémarrages de la machine cible depuis son déploiement.

Pour suivre la procédure décrite dans cette section, vous devez remplir les conditions préalables suivantes :

Accès à la console Google Cloud et à votre projet Google Cloud connecté à Distributed Cloud.
Le rôle IAM Lecteur Monitoring, qui vous permet d'afficher les métriques Monitoring.
(Facultatif) Valeur machine_id de la machine Distributed Cloud connectée cible pour filtrer les résultats renvoyés.

Utiliser l'explorateur de métriques pour vérifier le temps d'activité et le nombre de redémarrages de la machine

Accédez à l'explorateur de métriques :
1. Dans la console Google Cloud , accédez à la section Monitoring.
2. Dans l'arborescence de navigation de gauche, cliquez sur Explorateur de métriques.
Sélectionnez le type de ressource cible :
1. Sur la page "Explorateur de métriques", accédez à la page Configuration.
2. Cliquez sur Sélectionner une métrique.
3. Utilisez la barre de recherche pour rechercher le type de ressource Machine. Vous pouvez également utiliser l'identifiant de ressource complet edgecontainer.googleapis.com/Machine.
4. Dans les résultats renvoyés, cliquez sur le type de ressource Machine.
Vérifiez le temps d'activité de la machine :
1. Dans la section Métrique, recherchez la valeur uptime.
2. Sélectionnez la métrique Temps d'activité de la machine. Son chemin d'accès complet est edgecontainer.googleapis.com/machine/uptime.
3. (Facultatif) Filtrez par valeur cible machine_id à l'aide de la section Filtre.
4. Dans le graphique temporel qui s'affiche, vérifiez que le graphique de temps d'activité augmente en continu. Si, à un moment donné, la valeur du temps d'activité tombe à zéro et redémarre, cela indique que la machine a redémarré.
Vérifiez le nombre de redémarrages de la machine :
1. Dans la section Métrique, recherchez la valeur restart_count.
2. Sélectionnez la métrique Redémarrages de la machine. Son chemin d'accès complet est edgecontainer.googleapis.com/machine/restart_count.
3. (Facultatif) Filtrez par valeur cible machine_id à l'aide de la section Filtre.
4. Dans le graphique temporel qui s'affiche, vérifiez que la ligne du graphique reste à 0, ce qui indique qu'aucun redémarrage n'a eu lieu. Si, à un moment donné, la ligne atteint 1, cela indique que la machine a redémarré. Notez le code temporel exact du redémarrage pour un dépannage ultérieur.
5. (Facultatif) Pour afficher des événements individuels au lieu d'un graphique, accédez à la section Agrégation de la page, définissez le champ Période d'alignement sur 1 minute et le champ Aligneur par série sur Delta.

Comprendre les résultats

Le tableau suivant explique les résultats renvoyés par l'explorateur de métriques.

État de la machine	Diagnostic	Solution
Stable La métrique "Temps d'activité de la machine" augmente régulièrement Le delta de la métrique "Redémarrages de la machine" est de `0`	La machine n'a pas redémarré.	Aucune.
Redémarrage propre La métrique "Temps d'activité de la machine" chute à `0` La métrique "Redémarrages de la machine" atteint un pic à `1`	La machine a bien redémarré et s'est reconnectée à Google Cloud.	Consultez les journaux système pour déterminer la raison du redémarrage.
Panne de courant Le graphique de la métrique "Temps d'activité de la machine" présente une interruption sans données La métrique "Redémarrages de la machine" n'a pas changé pendant l'interruption du temps d'activité de la machine	La machine a perdu l'alimentation ou la connectivité réseau avant de pouvoir redémarrer.	Vérifiez les câbles d'alimentation et réseau, la configuration du réseau local et l'état du voyant.
Intermittent La valeur de la métrique "Machine connectée" alterne entre `0` et `1` La valeur de la métrique "Connectivité réseau" alterne entre `0` et `1`	Connexion réseau instable, perte de paquets ou latence excessive.	Vérifiez si votre réseau local est encombré et si du matériel est défectueux.

Connectivité des machines Distributed Cloud connecté

Cette section explique comment vérifier la connectivité Internet et Google Cloud de vos machines connectées Distributed Cloud à l'aide de la fonctionnalité Explorateur de métriques de Cloud Monitoring.

Cette procédure utilise les métriques Monitoring suivantes :

Machine connectée (/machine/connected) : indique si la machine est connectée à Google Cloud.
Connectivité réseau (/machine/network/connectivity) : indique si l'interface réseau principale de la machine dispose d'une connectivité Internet.

Pour suivre la procédure décrite dans cette section, vous devez remplir les conditions préalables suivantes :

Accès à la console Google Cloud et à votre projet Google Cloud connecté à Distributed Cloud.
Le rôle IAM Lecteur Monitoring, qui vous permet d'afficher les métriques Monitoring.
(Facultatif) Valeur machine_id de la machine Distributed Cloud connectée cible pour filtrer les résultats renvoyés.

Utiliser l'explorateur de métriques pour vérifier la connectivité de la machine

Accédez à l'explorateur de métriques :
1. Dans la console Google Cloud , accédez à la section Monitoring.
2. Dans l'arborescence de navigation de gauche, cliquez sur Explorateur de métriques.
Sélectionnez le type de ressource cible :
1. Sur la page "Explorateur de métriques", accédez à la page Requêtes.
2. Utilisez la barre de recherche pour rechercher le type de ressource Machine. Vous pouvez également utiliser l'identifiant de ressource complet edgecontainer.googleapis.com/Machine.
3. Dans les résultats renvoyés, cliquez sur le type de ressource Machine.
Vérifiez la connexion de la machine à Google Cloud :
1. Dans la section Métrique, recherchez la valeur connected.
2. Sélectionnez la métrique Machine Connected (Machine connectée). Son chemin d'accès complet est edgecontainer.googleapis.com/machine/connected.
3. (Facultatif) Filtrez par valeur cible machine_id à l'aide de la section Filtre.
4. Dans le graphique temporel qui s'affiche, vérifiez que la ligne Opérationnel reste à 100 % de manière continue. Si, à un moment donné, cette valeur est de 0% ou Non opérationnel, cela signifie que la machine a perdu la connectivité avec Google Cloud à l'heure indiquée.
Vérifiez la connectivité Internet de la machine :
1. Dans la section Métrique, recherchez la valeur connectivity.
2. Sélectionnez la métrique Connectivité réseau. Son chemin d'accès complet est edgecontainer.googleapis.com/machine/network/connectivity.
3. (Facultatif) Filtrez par valeur cible machine_id à l'aide de la section Filtre.
4. Dans le graphique temporel qui s'affiche, vérifiez que la ligne Opérationnel reste à 100 % de manière continue. Si, à un moment donné, cette valeur est de 0% Non opérationnel, cela signifie que la machine a perdu la connectivité Internet à l'heure indiquée.

Comprendre les résultats

Le tableau suivant explique les résultats renvoyés par l'explorateur de métriques.

État de la machine	Diagnostic	Solution
Bon état La valeur de la métrique "Machine connectée" est `1` La valeur de la métrique "Connectivité réseau" est `1`	Fonctionnement normal.	Aucune.
Déconnecté La valeur de la métrique "Machine connectée" est `0` La valeur de la métrique "Connectivité réseau" est `1`	La machine dispose d'une connectivité Internet, mais ne peut pas se connecter à Google Cloud.	Vérifiez vos règles de pare-feu pour les services Google et les points de terminaison de l'API. Vérifiez que les agents connectés Distributed Cloud sont en cours d'exécution sur la machine.
Isolé La valeur de la métrique "Machine connectée" est `0` La valeur de la métrique "Connectivité réseau" est `0`	La machine n'a pas de connectivité Internet.	Vérifiez les câbles d'alimentation et réseau, la configuration du réseau local et l'état du voyant LED. Vérifiez la configuration de votre VLAN et de votre routage.
Intermittent La valeur de la métrique "Machine connectée" alterne entre `0` et `1` La valeur de la métrique "Connectivité réseau" alterne entre `0` et `1`	Connexion réseau instable, perte de paquets ou latence excessive.	Vérifiez si votre réseau local est encombré et si du matériel est défectueux.

Si vous remarquez des valeurs de 0 soutenues pour l'une ou l'autre des métriques, suivez les étapes de dépannage décrites dans le tableau pour les résoudre. Si le problème persiste, contactez l'assistance Google en indiquant la valeur machine_id de la machine concernée et l'horodatage de la panne.

Machines virtuelles bloquées à l'état `Pending`

Une charge de travail de machine virtuelle peut se bloquer à l'état Pending et ne pas être planifiée sur un nœud si l'un des événements suivants se produit :

Distributed Cloud connecté ne peut pas allouer les ressources demandées, telles que le temps CPU, la mémoire ou l'espace disque, à la machine virtuelle.
La configuration de la machine virtuelle présente un problème.
Une erreur s'est produite au niveau du stockage de la machine virtuelle.
Le nœud cible est entaché.

Pour résoudre ce problème, procédez comme suit :

Obtenez les identifiants du cluster comme décrit dans Obtenir les identifiants d'un cluster.

Obtenez des informations sur la machine virtuelle concernée :

kubectl describe virtualmachine VM_NAME -n NAMESPACE

Remplacez les éléments suivants :

VM_NAME : nom de la machine virtuelle cible.
NAMESPACE : espace de noms de la machine virtuelle cible.

La commande renvoie un résultat semblable à celui-ci :

Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

Le résultat de la commande contient des messages pouvant indiquer des contraintes de ressources, des échecs de planification, des erreurs de stockage et d'autres problèmes.

Examinez le résultat pour déterminer les causes de l'échec de la planification, comme expliqué dans les sections suivantes.

Ressources insuffisantes

Un message peut s'afficher pour indiquer que les ressources sont insuffisantes (processeur, mémoire ou espace disque, par exemple). Exemple :

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

Pour résoudre ce problème, vérifiez les ressources allouées aux machines virtuelles concernées et aux autres charges de travail planifiées sur le nœud, puis effectuez les opérations suivantes en fonction des besoins de votre entreprise :

Réduisez la capacité des autres charges de travail planifiées sur le nœud.
Réduisez la quantité de ressources allouées à la machine virtuelle concernée.
Ajoutez des machines au cluster concerné.

Nœuds rejetés

Un message peut s'afficher pour indiquer que le nœud cible est entaché. Exemple :

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

Pour résoudre ce problème, procédez comme suit :

Exécutez la commande suivante pour vérifier les rejets sur le nœud :

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

La commande renvoie un résultat semblable à celui-ci :

NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

Effectuez l'une des opérations suivantes :
- Pour les rejets inattendus, supprimez-les comme décrit dans Rejets et tolérances.
- Pour les rejets attendus, ajoutez les tolérances correspondantes à la configuration de la machine virtuelle, comme décrit dans Rejets et tolérances.

Défaillances de stockage

Un message indiquant un problème de stockage de la machine virtuelle peut s'afficher. Exemple :

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

Ce message peut indiquer que le volume persistant correspondant ne parvient pas à s'installer sur le nœud cible.

Pour résoudre ce problème, procédez comme suit :

Utilisez la commande suivante pour obtenir l'état des revendications de volume persistant (PVC) dans l'espace de noms de la machine virtuelle concernée :

kubectl get pvc -n NAMESPACE

Remplacez NAMESPACE par le nom de l'espace de noms cible.

La commande renvoie un résultat semblable à celui-ci :

NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

Vérifiez que la PVC correspondante présente l'état Bound. Si l'état est Pending, le sous-système de stockage n'a pas réussi à provisionner le volume. Dans ce cas, vous devez résoudre les problèmes de configuration du sous-système de stockage et vous assurer que le StorageClass approprié est disponible.

Blocages de planification causés par l'échec des webhooks d'admission

Les webhooks d'admission vous permettent d'intercepter les requêtes adressées au serveur d'API Kubernetes avant que l'objet ne devienne persistant. Bien qu'ils soient utiles pour appliquer des règles de sécurité personnalisées, des webhooks mal configurés peuvent entraîner des pannes à l'échelle du cluster, en particulier lors d'opérations critiques telles que les mises à niveau logicielles et les actualisations de certificats. Plus précisément, un webhook d'admission bloqué ou indisponible peut bloquer le plan de contrôle Kubernetes, ce qui empêche toute planification de charge de travail sur le cluster.

Blocage du plan de contrôle

Un blocage de dépendance circulaire peut se produire lorsqu'un webhook d'admission est chargé de valider les ressources nécessaires à la récupération du webhook lui-même. Par exemple, si un webhook d'admission est configuré pour valider des pods et que ce pod de webhook doit être reprogrammé lors d'une mise à niveau logicielle de nœud, le serveur d'API Kubernetes peut tenter de contacter le webhook pour autoriser la création du nouveau pod. Si le webhook n'est pas accessible, la requête échoue, le pod n'est pas créé et le cluster passe à un état de blocage dans lequel aucune nouvelle charge de travail ne peut être planifiée.

Lorsqu'un webhook est configuré avec failurePolicy: Fail, toute erreur de communication ou tout délai d'expiration entre le serveur d'API et le webhook entraîne le rejet de la requête API. Cela entraîne les problèmes suivants :

Échec des mises à niveau logicielles : les composants système et les VM ne peuvent pas être planifiés pendant et après une mise à niveau logicielle de nœud.
Impossible de démarrer les services système : les pods d'infrastructure, tels que Symcloud Storage et l'environnement d'exécution de VM sur GDC, ne peuvent pas démarrer.
Nœuds bloqués en mode maintenance : les nœuds en mode maintenance ne peuvent pas être rapprochés ni quitter ce mode, car le contrôleur est bloqué par la logique d'admission.

Bonnes pratiques de configuration des webhooks

Suivez les bonnes pratiques décrites dans cette section pour éviter le blocage du plan de contrôle décrit précédemment. Ces bonnes pratiques s'appliquent à tous les objets ValidatingWebhookConfiguration et MutatingWebhookConfiguration.

Utiliser `failurePolicy: Ignore`

Sauf si vos exigences métier imposent qu'une requête API doit échouer si elle ne peut pas être validée, définissez toujours le champ failurePolicy sur Ignore. Cela garantit que le serveur d'API Kubernetes continue de fonctionner même lorsque le service de webhook concerné est indisponible, ce qui permet aux pods critiques pour le système de planifier et de récupérer.

Exclure les espaces de noms réservés

Vos webhooks ne doivent jamais intercepter les requêtes de ressources dans des espaces de noms réservés. Vous devez exclure ces espaces de noms de votre configuration de webhook à l'aide du champ namespaceSelector. Pour obtenir la liste complète des espaces de noms réservés, consultez Restrictions concernant les espaces de noms de gestion. Exemple :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

Récupérer un cluster bloqué par des webhooks défaillants

Si votre cluster est bloqué par des webhooks défaillants et que vos commandes kubectl de création de ressources expirent ou renvoient des erreurs, cela est généralement dû au fait que le webhook a défini son failurePolicy sur Fail. Suivez les étapes de cette section pour récupérer le cluster après un blocage. Si le webhook défaillant est un webhook de mutation, utilisez mutatingwebhookconfiguration au lieu de validatingwebhookconfiguration.

Identifiez les webhooks défaillants :
1. Répertoriez les webhooks de validation déployés sur le cluster :
```
kubectl get validatingwebhookconfigurations
```
2. Répertoriez les webhooks de mutation déployés sur le cluster :
```
kubectl get mutatingwebhookconfigurations
```
Vérifiez si les pods qui soutiennent ces webhooks sont en cours d'exécution :
```
kubectl get pods -A | grep WEBHOOK_SERVICE
```
Remplacez WEBHOOK_SERVICE par le nom du service du webhook cible.

Définissez le paramètre failurePolicy du webhook défaillant sur Ignore :

kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

Remplacez WEBHOOK_SERVICE par le nom du service du webhook cible.

(Facultatif) Si l'étape précédente a échoué, forcez la suppression de la configuration du webhook concerné :
```
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
```
Remplacez WEBHOOK_CONFIG par le nom de la configuration du webhook cible.

Après avoir modifié ou supprimé de force la configuration du webhook, le serveur d'API Kubernetes reprend le traitement des requêtes, ce qui résout le blocage et permet aux processus bloqués de se terminer.

Résoudre les problèmes liés à Distributed Cloud connecté Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Mises à niveau logicielles de Distributed Cloud connecté

Utiliser l'explorateur de métriques pour vérifier les versions logicielles actuelle et cible du cluster

Comprendre les résultats

Redémarrages de machines Distributed Cloud connecté

Utiliser l'explorateur de métriques pour vérifier le temps d'activité et le nombre de redémarrages de la machine

Comprendre les résultats

Connectivité des machines Distributed Cloud connecté

Utiliser l'explorateur de métriques pour vérifier la connectivité de la machine

Comprendre les résultats

Machines virtuelles bloquées à l'état Pending

Ressources insuffisantes

Nœuds rejetés

Défaillances de stockage

Blocages de planification causés par l'échec des webhooks d'admission

Blocage du plan de contrôle

Bonnes pratiques de configuration des webhooks

Utiliser failurePolicy: Ignore

Exclure les espaces de noms réservés

Récupérer un cluster bloqué par des webhooks défaillants

Résoudre les problèmes liés à Distributed Cloud connecté

Machines virtuelles bloquées à l'état `Pending`

Utiliser `failurePolicy: Ignore`