Partager via

Résoudre les erreurs UpgradeFailed dues à des échecs d’éviction causés par des PDB

  • Article

Cet article explique comment identifier et résoudre les erreurs UpgradeFailed dues aux échecs d’éviction causés par les budgets d’interruption de pod (PDB) qui se produisent lorsque vous essayez de mettre à niveau un cluster Azure Kubernetes Service (AKS).

Conditions préalables

Cet article nécessite Azure CLI version 2.0.65 ou ultérieure. Pour rechercher le numéro de version, exécutez az --version. Si vous devez installer ou mettre à niveau Azure CLI, consultez Guide pratique pour installer Azure CLI.

Pour plus d’informations sur le processus de mise à niveau, consultez la section « Mettre à niveau un cluster AKS » dans Mettre à niveau un cluster Azure Kubernetes Service (AKS).

Symptômes

Une opération de mise à niveau de cluster AKS échoue avec le message d’erreur suivant :

Code : UpgradeFailed
Message : Le nom du nœud <de drainage a échoué lors de la suppression du <pod pod-name>.> L’éviction a échoué avec l’erreur Trop de requêtes. Cela est souvent dû à une stratégie PDB (Pod Disruption Budget) restrictive. Voir http://aka.ms/aks/debugdrainfailures (en anglais). Erreur d’origine : Échec de l’appel d’API au serveur d’API Kubernetes.

Cause

Cette erreur peut se produire si un pod est protégé par la stratégie PDB (Pod Disruption Budget). Dans cette situation, la gousse résiste à être drainée.

Pour tester cette situation, exécutez kubectl get pdb -A, puis case activée la valeur Interruption autorisée. La valeur doit être égale ou supérieure à 1. Pour plus d’informations, consultez Planifier la disponibilité à l’aide des budgets d’interruption de pod.

Si la valeur Interruption autorisée est 0, le drainage du nœud échoue pendant le processus de mise à niveau.

Pour résoudre ce problème, utilisez l’une des solutions suivantes.

Solution 1 : Autoriser le drainage des pods

  1. Ajustez le PDB pour activer le drainage des pods. En règle générale, l’interruption autorisée est contrôlée par le Min Available / Max unavailable paramètre ou Running pods / Replicas . Vous pouvez modifier le Min Available / Max unavailable paramètre au niveau PDB ou augmenter le nombre de Running pods / Replicas pour envoyer (push) la valeur Interruption autorisée à 1 ou plus.
  2. Réessayez pour mettre à niveau le cluster AKS vers la version vers laquelle vous avez essayé de procéder à la mise à niveau précédemment. Ce processus déclenche un rapprochement.

Solution 2 : Sauvegarder, supprimer et redéployer le PDB

  1. Effectuez une sauvegarde du PDB kubectl get pdb <pdb-name> -n <pdb-namespace> -o yaml > pdb_backup.yaml, puis supprimez le PDB kubectl delete pdb <pdb-name> -n /<pdb-namespace>. Une fois la mise à niveau terminée, vous pouvez redéployer le PDB kubectl apply -f pdb_backup.yaml.
  2. Réessayez pour mettre à niveau le cluster AKS vers la version vers laquelle vous avez essayé de procéder à la mise à niveau précédemment. Ce processus déclenche un rapprochement.

Solution 3 : Supprimer les pods qui ne peuvent pas être vidés

  1. Supprimez les pods qui ne peuvent pas être vidés.

    Remarque

    Si les pods ont été créés par un deployment ou StatefulSet, ils sont contrôlés par un ReplicaSet. Si c’est le cas, vous devrez peut-être supprimer le déploiement ou StatefulSet. Avant cela, nous vous recommandons d’effectuer une sauvegarde : kubectl get <kubernetes-object> <name> -n <namespace> -o yaml > backup.yaml.

  2. Réessayez pour mettre à niveau le cluster AKS vers la version vers laquelle vous avez essayé de procéder à la mise à niveau précédemment. Ce processus déclenche un rapprochement.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.