Remover nós bloqueados por PodDisruptionBudgets

A resolução de conflitos do PodDisruptionBudget (PDB) permite concluir as remoções de nós dos clusters do Google Distributed Cloud quando as exclusões estão bloqueadas. Quando um PDB impede que os pods sejam removidos, o nó não pode ser drenado e permanece no cluster com o status Ready,SchedulingDisabled, mesmo que você o tenha removido da configuração do pool de nós. Para concluir a remoção do nó, identifique e desative temporariamente a política conflitante.

O PDB entra em conflito com o número de pods disponíveis

As políticas de PDB ajudam a garantir o desempenho do aplicativo, evitando que os pods desliguem ao mesmo tempo, quando você faz alterações no sistema. Consequentemente, as políticas de PDB limitam o número de pods indisponíveis simultaneamente em um aplicativo replicado.

No entanto, a política de PDB às vezes pode impedir exclusões de nós que você quer fazer se violar a política ao remover um nó.

Por exemplo, uma política de PDB pode definir que sempre deve haver dois pods disponíveis no sistema (.spec.minAvailable é 2). No entanto, se você tiver apenas dois pods e tentar remover o nó que contém um deles, a política de PDB entrará em vigor e impedirá a remoção do nó.

Da mesma forma, quando a política de PDB define que nenhum pod deve ficar indisponível (.spec.maxUnavailable é 0), ela também impede que os nós associados sejam excluídos. Mesmo que você tente remover um único pod por vez, a política do PDB impede a exclusão do nó afetado.

Desativar e reativar a política de PDB

Para resolver um conflito de PDB, faça backup e remova a política de PDB. Depois que o PDB for excluído, o nó será drenado e os pods associados serão removidos. Em seguida, faça as mudanças que quiser e reative a política de PDB.

O exemplo a seguir mostra como excluir um nó nessa condição, o que pode afetar todos os tipos de clusters do Google Distributed Cloud: clusters de administrador, híbrido, autônomo e de usuário.

O mesmo procedimento geral funciona para todos os tipos de cluster. No entanto, os comandos específicos para excluir um nó de um pool de clusters de administrador (para clusters administradores, híbridos ou autônomos) diferem um pouco dos comandos para excluir um nó de um pool de nós de clusters de usuários.

1. Para facilitar a leitura, a variável ${KUBECONFIG} é usada nos comandos a seguir.

   Dependendo do tipo de cluster, exporte o caminho do kubeconfig do cluster de administrador (ADMIN_KUBECONFIG) ou do kubeconfig do cluster de usuário (USER_CLUSTER_CONFIG) para $(KUBECONFIG) e conclua as seguintes etapas:

   • Para excluir um nó de um cluster de usuário, defina export KUBECONFIG=USER_CLUSTER_CONFIG
   • Para excluir um nó de um cluster de administrador, defina export KUBECONFIG=ADMIN_KUBECONFIG.

2. Opcional: se você estiver excluindo um nó de um pool de nós de cluster de usuário, execute o seguinte comando para extrair o arquivo kubeconfig do cluster de usuário:

   kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME \
     get secret USER_CLUSTER_NAME-kubeconfig  \
     -o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
   

   Substitua as seguintes entradas por informações específicas do seu ambiente de cluster:

   • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
   • CLUSTER_NAME: o nome do cluster do qual você quer gerar um snapshot.
   • USER_CLUSTER_CONFIG: o caminho para o arquivo de configuração do cluster de usuário.

3. Depois de remover o nó do pool de nós, verifique o status do nó. O nó afetado informa Ready, SchedulingDisabled:

   kubectl get nodes --kubeconfig ${KUBECONFIG}
   

   O status do nó é semelhante ao exemplo de saída a seguir:

   NAME   STATUS                    ROLES      AGE      VERSION
   CP2    Ready                     Master     11m      v.1.18.6-gke.6600
   CP3    Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
   CP4    Ready                     <none>     9m18s    v.1.18.6-gke.6600
   

4. Verifique os PDBs no cluster:

   kubectl get pdb --kubeconfig ${KUBECONFIG} -A
   

   O sistema informa PDBs semelhantes aos mostrados no exemplo de saída a seguir:

   NAMESPACE     NAME             MIN AVAILABLE    MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
   gke-system    istio-ingress    1                N/A               1                     19m
   gke-system    istiod           1                N/A               1                     19m
   kube-system   coredns          1                N/A               0                     19m
   kube-system   log-aggregator   N/A              0                 0                     19m
   kube-system   prometheus       N/A              0                 0                     19m
   

5. Inspecione o PDB. Encontre uma correspondência entre o rótulo do pod no PDB e os pods correspondentes no nó. Essa correspondência garante que você desative o PDB correto para remover o nó:

   kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
   

   O sistema retorna os resultados de rótulos correspondentes na política de PDB:

   {"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
   

6. Encontre pods que correspondam ao rótulo da política de PDB:

   kubectl --kubeconfig ${KUBECONFIG} get pods -A --selector=app=stackdriver-log-aggregator  \
     -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'
   

   O comando retorna uma lista de pods que correspondem ao rótulo do PDB e verifica a política do PDB que você precisa remover:

   stackdriver-log-aggregator-0    CP3
   stackdriver-log-aggregator-1    CP3
   

7. Depois de confirmar o pod afetado, faça uma cópia de backup da política de PDB. O exemplo a seguir faz backup da política log-aggregator:

   kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
     -o yaml >> log-aggregator.yaml
   

8. Exclua a política de PDB específica. Novamente, os exemplos a seguir excluem a política log-aggregator:

   kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
   

   Depois de excluir a política de PDB, o nó é drenado. No entanto, pode levar até 30 minutos para que o nó seja totalmente excluído. Continue verificando o status do nó para confirmar se o processo foi concluído.

   Se você quiser remover o nó permanentemente e também os recursos de armazenamento associados a ele, faça isso antes de restaurar a política de PDB. Para mais informações, consulte Remover recursos de armazenamento.

9. Restaure a política de PDB da sua cópia:

   kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}
   

10. Verifique se os pods excluídos foram recriados. Neste exemplo, se houver dois pods stackdriver-log-aggregator-x, eles serão recriados:

    kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
    

11. Se você quiser restaurar o nó, edite a configuração apropriada do pool de nós e restaure o endereço IP do nó.

Remover recursos de armazenamento de nós excluídos permanentemente

Se você excluir permanentemente um nó e não quiser restaurá-lo no sistema, também poderá excluir os recursos de armazenamento associados a ele.

1. Verifique e veja o nome do volume permanente (PV) associado ao nó:

   kubectl get pv --kubeconfig ${KUBECONFIG}  \
     -A -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{.spec.claimRef.name}{":\t"}  \
     {.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].values}{"\n"}{end}'
   

2. Exclua o PV associado ao nó:

   kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}
   

   Substitua PV_NAME pelo nome do volume permanente a ser excluído.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care. Consulte também Como receber suporte para mais informações sobre recursos de suporte, incluindo:

• Requisitos para abrir um caso de suporte.
• Ferramentas para ajudar você a resolver problemas, como a configuração do ambiente, os registros e as métricas.
• Componentes compatíveis.