Remova nós bloqueados por PodDisruptionBudgets

Em determinadas condições, as políticas de PodDisruptionBudgets (PDB) podem impedir que os nós sejam removidos com êxito dos conjuntos de nós. Nestas condições, o estado do nó indica Ready,SchedulingDisabled apesar de ter sido removido. Este documento mostra como remover nós dos seus clusters do Google Distributed Cloud que estão atualmente bloqueados por problemas de PDB.

Esta página destina-se a administradores, arquitetos e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente e respondem a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são cumpridos ou as aplicações falham. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte o artigoFunções e tarefas comuns do utilizador do GKE.

O PDB está em conflito com o número de agrupamentos disponíveis

As políticas de PDB ajudam a garantir o desempenho da app, impedindo que os pods fiquem inativos ao mesmo tempo quando faz alterações ao sistema. Consequentemente, as políticas de PDB limitam o número de pods simultaneamente indisponíveis numa aplicação replicada.

No entanto, a política de PDB pode, por vezes, impedir as eliminações de nós que quer fazer se violar a política ao remover um nó.

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

Da mesma forma, quando a política PDB define que nenhum Pod deve estar indisponível (.spec.maxUnavailable é 0), a política também impede que quaisquer nós associados sejam eliminados. Mesmo que tente remover um único pod de cada vez, a política PDB impede a eliminação do nó afetado.

Desative e reative a política de PDB

Para resolver um conflito de PDB, faça uma cópia de segurança e, em seguida, remova a política de PDB. Depois de o PDB ser eliminado com êxito, o nó é esvaziado e os pods associados são removidos. Em seguida, pode fazer as alterações pretendidas e reativar a política de PDB.

O exemplo seguinte mostra como eliminar um nó nesta condição, o que pode afetar todos os tipos de clusters do Google Distributed Cloud: clusters de administrador, híbridos, autónomos e de utilizador.

O mesmo procedimento geral funciona para todos os tipos de clusters. No entanto, os comandos específicos para eliminar um nó de um conjunto de nós do cluster de administrador (para clusters de administrador, híbridos ou autónomos) variam ligeiramente dos comandos para eliminar um nó de um conjunto de nós do cluster de utilizador.

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

    Consoante o tipo de cluster, exporte o caminho kubeconfig do cluster de administrador (ADMIN_KUBECONFIG) ou o caminho kubeconfig do cluster de utilizador (USER_CLUSTER_CONFIG) para $(KUBECONFIG) e conclua os seguintes passos:

    • Para eliminar um nó de um cluster de utilizadores, defina export KUBECONFIG=USER_CLUSTER_CONFIG
    • Para eliminar o nó de um cluster de administrador, defina export KUBECONFIG=ADMIN_KUBECONFIG.

  2. Opcional: se estiver a eliminar um nó de um grupo de nós do cluster de utilizadores, execute o seguinte comando para extrair o ficheiro kubeconfig do cluster de utilizadores:

    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 para o ficheiro kubeconfig do cluster de administrador.
    • CLUSTER_NAME: o nome do cluster do qual quer tirar uma captura de ecrã.
    • USER_CLUSTER_CONFIG: o caminho para o ficheiro de configuração do cluster do utilizador.

  3. Depois de remover o nó do conjunto de nós, verifique o estado do nó. O nó afetado comunica Ready, SchedulingDisabled:

    kubectl get nodes --kubeconfig ${KUBECONFIG}

    O estado do nó tem um aspeto semelhante ao seguinte exemplo de resultado:

    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 seu cluster:

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

    O sistema comunica PDBs semelhantes aos apresentados no seguinte exemplo de resultado:

    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 a PDB. Encontrar uma correspondência entre a etiqueta Pod no PDB e os Pods correspondentes no nó. Esta correspondência garante que desativa a PDB correta para remover o nó com êxito:

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

    O sistema devolve resultados de etiquetas correspondentes na política de PDB:

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

  6. Encontre pods que correspondam à etiqueta 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 devolve uma lista de pods que correspondem à etiqueta PDB e valida a política PDB que tem de remover:

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

  7. Depois de confirmar o Pod afetado, faça uma cópia de segurança da política de PDB. O exemplo seguinte apoia a política log-aggregator:

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

  8. Elimine a política de PDB específica. Mais uma vez, os exemplos seguintes eliminam a política log-aggregator:

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

    Depois de eliminar a política de PDB, o nó começa a esvaziar-se. No entanto, a eliminação completa do nó pode demorar até 30 minutos. Continue a verificar o estado do nó para confirmar que o processo foi concluído com êxito.

    Se quiser remover o nó permanentemente e também remover os recursos de armazenamento associados ao nó, pode fazê-lo antes de restaurar a política de PDB. Para mais informações, consulte o artigo Remova recursos de armazenamento.

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

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

  10. Confirme se os pods eliminados são recriados com êxito. Neste exemplo, se existissem dois stackdriver-log-aggregator-x Pods, estes seriam recriados:

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

  11. Se quiser restaurar o nó, edite a configuração do conjunto de nós adequada e restaure o endereço IP do nó.

Remova recursos de armazenamento de nós eliminados permanentemente

Se eliminar permanentemente um nó e não quiser restaurá-lo no seu sistema, também pode eliminar os recursos de armazenamento associados a esse nó.

  1. Verifique e obtenha o nome do volume persistente (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. Elimine o PV associado ao nó:

    kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}

    Substitua PV_NAME pelo nome do volume persistente a eliminar.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

  • Requisitos para abrir um registo de apoio ao cliente.
  • Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
  • Componentes suportados.