Compartilhar via

Solucionar problemas de erros UpgradeFailed devido a falhas de remoção causadas por PDBs

  • Artigo

Este artigo discute como identificar e resolver erros UpgradeFailed devido a falhas de remoção causadas por PDBs (Orçamentos de Interrupção de Pod) que ocorrem quando você tenta atualizar um cluster do AKS (Serviço de Kubernetes do Azure).

Pré-requisitos

Este artigo requer a CLI do Azure versão 2.67.0 ou posterior. Para localizar o número da versão, execute az --version. Se você precisar instalar ou atualizar a CLI do Azure, consulte Como instalar a CLI do Azure.

Para obter informações mais detalhadas sobre o processo de atualização, consulte a seção "Atualizar um cluster do AKS" em Atualizar um cluster do AKS (Serviço de Kubernetes do Azure).

Sintomas

Uma operação de atualização de cluster do AKS falha com uma das seguintes mensagens de erro:

  • (Falha na atualização) A drenagem node aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx falhou quando o pod <pod-name> de remoção falhou com o erro Muitas solicitações. Isso geralmente é causado por uma política restritiva de Orçamento de Interrupção de Pod (PDB). Consulte https://aka.ms/aks/debugdrainfailures. Erro original: Não é possível remover o pod, pois isso violaria o orçamento de interrupção do pod. Informações de depuração do PDB: <namespace>/<pod-name> bloqueado pelo pdb <pdb-name> com 0 pods não prontos.

  • Código: UpgradeFailed
    Mensagem: Falha no nó de aks-<nodepool-name>-xxxxxxxx-vmssxxxxxx drenagem ao remover o pod <pod-name> com o erro Muitas solicitações. Isso geralmente é causado por uma política restritiva de Orçamento de Interrupção de Pod (PDB). Consulte https://aka.ms/aks/debugdrainfailures. Erro original: Não é possível remover o pod, pois isso violaria o orçamento de interrupção do pod. Informações de depuração do PDB: <namespace>/<pod-name> bloqueado pelo pdb <pdb-name> com 0 pods não prontos.

Motivo

Esse erro poderá ocorrer se um pod estiver protegido pela política de Orçamento de Interrupção do Pod (PDB). Nessa situação, o pod resiste a ser drenado e, após várias tentativas, a operação de atualização falha e o cluster/pool de nós entra em um Failed estado.

Verifique a configuração do PDB: ALLOWED DISRUPTIONS valor. O valor deve ser 1 ou maior. Para obter mais informações, consulte Planejar a disponibilidade usando orçamentos de interrupção de pod. Por exemplo, você pode verificar a carga de trabalho e seu PDB da seguinte maneira. Você deve observar que a ALLOWED DISRUPTIONS coluna não permite nenhuma interrupção. Se o ALLOWED DISRUPTIONS valor for 0, os pods não serão removidos e a drenagem do nó falhará durante o processo de atualização:

$ 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

Você também pode verificar se há entradas em eventos do Kubernetes usando o comando kubectl get events | grep -i drain. Uma saída semelhante mostra a mensagem "Remoção bloqueada por muitas solicitações (geralmente um 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>

Para resolver o problema, use uma das soluções a seguir.

Solução 1: Habilitar a drenagem de pods

  1. Ajuste o PDB para habilitar a drenagem do pod. Geralmente, a interrupção permitida é controlada pelo Min Available / Max unavailable parâmetro or Running pods / Replicas . Você pode modificar o Min Available / Max unavailable parâmetro no nível do PDB ou aumentar o número de para enviar o valor de Running pods / Replicas Interrupção permitida para 1 ou mais.

  2. Tente atualizar novamente o cluster do AKS para a mesma versão para a qual você tentou atualizar anteriormente. Esse processo aciona uma reconciliação.

    $ 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

Solução 2: Fazer backup, excluir e reimplantar o PDB

  1. Faça um backup do(s) PDB(s) usando o comando kubectl get pdb <pdb-name> -n <pdb-namespace> -o yaml > pdb-name-backup.yamle exclua o PDB usando o comando kubectl delete pdb <pdb-name> -n <pdb-namespace>. Após a conclusão da nova tentativa de atualização, você pode reimplantar o PDB apenas aplicando o arquivo de backup usando o comando kubectl apply -f pdb-name-backup.yaml.

  2. Tente atualizar novamente o cluster do AKS para a mesma versão para a qual você tentou atualizar anteriormente. Esse processo aciona uma reconciliação.

    $ 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

Solução 3: Excluir os pods que não podem ser drenados ou reduzir a carga de trabalho para zero (0)

  1. Exclua os pods que não podem ser drenados.

    Observação

    Se os pods forem criados por uma Implantação ou StatefulSet, eles serão controlados por um ReplicaSet. Se esse for o caso, talvez seja necessário excluir ou dimensionar as réplicas de carga de trabalho para zero (0) da Implantação ou StatefulSet. Antes de fazer isso, recomendamos que você faça um backup: kubectl get <deployment.apps -or- statefulset.apps> <name> -n <namespace> -o yaml > backup.yaml.

  2. Para reduzir verticalmente, você pode usar kubectl scale --replicas=0 <deployment.apps -or- statefulset.apps> <name> -n <namespace> antes da reconciliação

  3. Tente atualizar novamente o cluster do AKS para a mesma versão para a qual você tentou atualizar anteriormente. Esse processo aciona uma reconciliação.

    $ 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

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.