Partager via

Résoudre les erreurs d’échec de mise à niveau en raison d’échecs d’éviction causés par des fichiers PDF

  • Article

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

Prerequisites

Cet article nécessite Azure CLI version 2.0.65 ou une version ultérieure. Pour rechercher le numéro de version, exécutez az --version. Si vous devez installer ou mettre à niveau Azure CLI, consultez Comment 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 du cluster AKS échoue avec le message d’erreur suivant :

Code : Échec de la mise à niveau
Message : Le nom du nœud <de drainage a échoué lors de la suppression du <pod pod-name>.> L’éviction a échoué avec une erreur Trop de requêtes. Cela est souvent dû à une stratégie PDB (Pod Disruption Budget) restrictive. Consultez l’article http://aka.ms/aks/debugdrainfailures. 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, le pod résiste à être drainé.

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

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

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

Solution 1 : Activer les pods pour vider

  1. Ajustez la base de données PDB pour activer le drainage des pods. En règle générale, la perturbation autorisée est contrôlée par le ou Running pods / Replicas le Min Available / Max unavailable paramètre. Vous pouvez modifier le Min Available / Max unavailable paramètre au niveau de la base de données PDB ou augmenter le nombre d’envois (push) de Running pods / Replicas la valeur d’interruption autorisée à 1 ou ultérieure.
  2. Réessayez de mettre à niveau le cluster AKS vers la même version que celle que vous avez tenté de mettre à niveau précédemment. Ce processus déclenche une réconciliation.

Solution 2 : Sauvegarder, supprimer et redéployer la base de données PDB

  1. Effectuez une sauvegarde de la base de données PDB kubectl get pdb <pdb-name> -n <pdb-namespace> -o yaml > pdb_backup.yaml, puis supprimez la base de données PDB kubectl delete pdb <pdb-name> -n /<pdb-namespace>. Une fois la mise à niveau terminée, vous pouvez redéployer la base de données PDB kubectl apply -f pdb_backup.yaml.
  2. Réessayez de mettre à niveau le cluster AKS vers la même version que celle que vous avez tenté de mettre à niveau précédemment. Ce processus déclenche une réconciliation.

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

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

    Note

    Si les pods ont été créés par un déploiement 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 de mettre à niveau le cluster AKS vers la même version que celle que vous avez tenté de mettre à niveau précédemment. Ce processus déclenche une réconciliation.

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.