Como remover nós bloqueados pelo orçamento de interrupção do pod

Em determinadas condições, as políticas de orçamento de interrupção de pod (PDB) podem impedir que os nós sejam removidos dos pools de nós. Nessas condições, o status do nó relata Ready,SchedulingDisabled, mesmo sendo removido.

O orçamento de interrupção do pod 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 simultaneamente indisponíveis em um aplicativo replicado.

No entanto, a política de PDB pode evitar exclusões de nós que você queira fazer. Se remover um nó, você violará a política.

Por exemplo, uma política de PDB pode definir que sempre há 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 precisa estar indisponível (.spec.maxUnavailable é 0), a política também impede que os nós associados sejam excluídos. Mesmo que você tente remover um único pod por vez, a política de PDB impede a exclusão do nó.

Solução alternativa: desativar e reativar a política de PDB

Para resolver esse conflito, você deve fazer backup e, em seguida, remover a política de PDB. Depois que o PDB é excluído, o nó é esvaziado e os pods associados são removidos. Depois de fazer as alterações que você quer, é possível reativar 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 Anthos em clusters bare metal: administradores, clusters híbridos, autônomos e usuários.

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.

Variações de comando para diferentes tipos de cluster

Para facilitar a leitura, observe o marcador ${KUBECONFIG} nos comandos a seguir. Dependendo do tipo de cluster, exporte o caminho kubeconfig do cluster de administrador (ADMIN_KUBECONFIG) ou o kubeconfig do cluster do usuário (USER_CLUSTER_CONFIG) para $(KUBECONFIG) e siga as etapas abaixo.

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

(opcional): se você estiver excluindo um nó de um pool de nós de cluster de usuário, execute o comando a seguir para extrair o arquivo kubeconfig do cluster de usuários. A variável ADMIN_KUBECONFIG especifica o caminho para o kubeconfig do cluster de administrador, e a variável USER_CLUSTER_NAME especifica o nome do cluster:
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME  \
get secret USER_CLUSTER_NAME-kubeconfig  \
-o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
```

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 seguinte:

NAME        STATUS                    ROLES      AGE      VERSION
abmnewCP2   Ready                     Master     11m      v.1.18.6-gke.6600
abmnewCP3   Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
abmnewCP4   Ready                     <none>     9m18s    v.1.18.6-gke.6600

Verifique os PDBs no cluster:

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

O sistema informa PDBs semelhantes aos mostrados abaixo:

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
 ```

Inspecione o PDB. É preciso encontrar 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"}}}
```

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 PDB e verifica a política de PDB que você precisa remover:

stackdriver-log-aggregator-0    abmnewCP3
stackdriver-log-aggregator-1    abmnewCP3

Depois de confirmar o pod afetado, faça uma cópia de backup da política de PDB. Neste exemplo, a política log-aggregator:
```
kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
-o yaml >> log-aggregator.yaml
```
Exclua a política de PDB específica. Nesse caso, a política log-aggregator:
```
kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
```
Depois que você exclui a política de PDB, o nó continua a drenar. No entanto, pode levar algum tempo (até 30 minutos) para que o nó seja totalmente excluído. Portanto, continue verificando o status do nó.

Se você quiser remover o nó permanentemente e também remover os recursos de armazenamento associados a ele, poderá fazer isso antes de restaurar a política de PDB. Consulte Como remover recursos de armazenamento.

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

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

Verifique se os pods excluídos foram recriados com sucesso. Neste exemplo, se havia dois pods stackdriver-log-aggregator-x, eles serão recriados:
```
kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
```

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

Como remover recursos de armazenamento de nós excluídos permanentemente

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

Nos comandos a seguir, observe as seguintes variáveis:

ADMIN-KUBECONFIG especifica o caminho para o cluster de administração.
USER_CLUSTER_CONFIG especifica o caminho para o arquivo YAML de configuração do cluster.

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}'

Exclua o PV associado ao nó:

kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}