Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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.67.0 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 l’un des messages d’erreur suivants :
-
(Échec de la mise à niveau) Échec du drainage
node aks-<nodepool-name>-xxxxxxxx-vmssxxxxxxlors de l’échec de la suppression du pod<pod-name>avec une erreur Trop de requêtes. Cela est souvent dû à une stratégie PDB (Pod Disruption Budget) restrictive. Consultez l’article https://aka.ms/aks/debugdrainfailures. Erreur d’origine : Impossible de supprimer le pod, car il violerait le budget d’interruption du pod.. Informations de débogage PDB :<namespace>/<pod-name>bloquées par pdb<pdb-name>avec 0 pods non lus. -
Code : Échec de la mise à niveau
Message : Échec du nœudaks-<nodepool-name>-xxxxxxxx-vmssxxxxxxde drainage lors de l’échec de la suppression du pod<pod-name>avec une erreur Trop de requêtes. Cela est souvent dû à une stratégie PDB (Pod Disruption Budget) restrictive. Consultez l’article https://aka.ms/aks/debugdrainfailures. Erreur d’origine : Impossible de supprimer le pod, car il violerait le budget d’interruption du pod.. Informations de débogage PDB :<namespace>/<pod-name>bloquées par pdb<pdb-name>avec 0 pods non lus.
Cause
Cette erreur peut se produire si un pod est protégé par la stratégie PDB (Pod Disruption Budget). Dans ce cas, le pod résiste à être vidé, et après plusieurs tentatives, l’opération de mise à niveau échoue et le pool de clusters/nœuds tombe dans un Failed état.
Vérifiez la configuration PDB : ALLOWED DISRUPTIONS valeur. La valeur doit être 1 ou supérieure. Pour plus d’informations, consultez Planifier la disponibilité à l’aide des budgets d’interruption de pod. Par exemple, vous pouvez vérifier la charge de travail et sa base de données PDB comme suit. Vous devez observer la ALLOWED DISRUPTIONS colonne qui n’autorise aucune interruption. Si la ALLOWED DISRUPTIONS valeur est 0, les pods ne sont pas supprimés et le drainage du nœud échoue pendant le processus de mise à niveau :
$ kubectl get deployments.apps nginx
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 2/2 2 2 62s
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-7854ff8877-gbr4m 1/1 Running 0 68s
nginx-7854ff8877-gnltd 1/1 Running 0 68s
$ kubectl get pdb
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
nginx-pdb 2 N/A 0 24s
Vous pouvez également rechercher les entrées dans les événements Kubernetes à l’aide de la commande kubectl get events | grep -i drain. Une sortie similaire montre le message « Éviction bloquée par trop de requêtes (généralement un pdb) » :
$ kubectl get events | grep -i drain
LAST SEEN TYPE REASON OBJECT MESSAGE
(...)
32m Normal Drain node/aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx Draining node: aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx
2m57s Warning Drain node/aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx Eviction blocked by Too Many Requests (usually a pdb): <pod-name>
12m Warning Drain node/aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx Eviction blocked by Too Many Requests (usually a pdb): <pod-name>
32m Warning Drain node/aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx Eviction blocked by Too Many Requests (usually a pdb): <pod-name>
32m Warning Drain node/aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx Eviction blocked by Too Many Requests (usually a pdb): <pod-name>
31m Warning Drain node/aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx Eviction blocked by Too Many Requests (usually a pdb): <pod-name>
Pour résoudre ce problème, appliquez l’une des solutions suivantes.
Solution 1 : Activer les pods pour vider
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
Min Available / Max unavailableleRunning pods / Replicasparamètre. Vous pouvez modifier leMin Available / Max unavailableparamètre au niveau de la base de données PDB ou augmenter le nombre d’envois (push) deRunning pods / Replicasla valeur d’interruption autorisée à 1 ou ultérieure.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.
$ az aks upgrade --name <aksName> --resource-group <resourceGroupName> Are you sure you want to perform this operation? (y/N): y Cluster currently in failed state. Proceeding with upgrade to existing version 1.28.3 to attempt resolution of failed cluster state. Since control-plane-only argument is not specified, this will upgrade the control plane AND all nodepools to version . Continue? (y/N): y
Solution 2 : Sauvegarder, supprimer et redéployer la base de données PDB
Effectuez une sauvegarde des bases de données PDB à l’aide de la commande
kubectl get pdb <pdb-name> -n <pdb-namespace> -o yaml > pdb-name-backup.yaml, puis supprimez la base de données PDB à l’aide de la commandekubectl delete pdb <pdb-name> -n <pdb-namespace>. Une fois la nouvelle tentative de mise à niveau terminée, vous pouvez redéployer la base de données PDB en appliquant simplement le fichier de sauvegarde à l’aide de la commandekubectl apply -f pdb-name-backup.yaml.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.
$ az aks upgrade --name <aksName> --resource-group <resourceGroupName> Are you sure you want to perform this operation? (y/N): y Cluster currently in failed state. Proceeding with upgrade to existing version 1.28.3 to attempt resolution of failed cluster state. Since control-plane-only argument is not specified, this will upgrade the control plane AND all nodepools to version . Continue? (y/N): y
Solution 3 : Supprimer les pods qui ne peuvent pas être vidés ou mettre à l’échelle la charge de travail jusqu’à zéro (0)
Supprimez les pods qui ne peuvent pas être vidés.
Remarque
Si les pods sont 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 ou mettre à l’échelle les réplicas de charge de travail à zéro (0) du déploiement ou statefulSet. Avant cela, nous vous recommandons d’effectuer une sauvegarde :
kubectl get <deployment.apps -or- statefulset.apps> <name> -n <namespace> -o yaml > backup.yaml.Pour effectuer un scale-down, vous pouvez utiliser
kubectl scale --replicas=0 <deployment.apps -or- statefulset.apps> <name> -n <namespace>avant la réconciliationRé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.
$ az aks upgrade --name <aksName> --resource-group <resourceGroupName> Are you sure you want to perform this operation? (y/N): y Cluster currently in failed state. Proceeding with upgrade to existing version 1.28.3 to attempt resolution of failed cluster state. Since control-plane-only argument is not specified, this will upgrade the control plane AND all nodepools to version . Continue? (y/N): y
Contactez-nous pour obtenir de l’aide
Si vous avez des questions, vous pouvez demander le support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.