Versão 1.6. Esta versão não é mais compatível. Para mais informações, consulte a política de suporte de versões. Para informações sobre como fazer upgrade para a versão 1.7, consulte Como fazer upgrade do Anthos em Bare Metal na documentação do 1.7.

Versões com suporte disponíveis: 1.14 | 1.13 | 1.12

Como forçar a remoção de nós corrompidos nos clusters do Anthos em bare metal

Quando um nó é corrompido e precisa ser removido de um cluster para reparo ou substituição, é possível forçar a remoção dele do cluster.

Como forçar a remoção de nós nos clusters do Anthos em bare metal 1.6.0

Na versão 1.6.0 do Anthos em bare metal, a remoção de um nó do pool de nós pai resulta nas ações a seguir:

Drenar o nó
Remover o nó do cluster do Kubernetes
Redefinir a máquina para o estado em que estava antes de instalar o Anthos em bare metal

No entanto, se o nó estiver inacessível, a drenagem do nó não será concluída. O controlador tenta repetidamente drenar o nó sem sucesso.

Como solução temporária, aplique as alterações a seguir para ignorar as etapas de drenagem e redefinição.

CUIDADO: esta operação requer uma atualização cuidadosa de campos de implementação específicos em recursos personalizados do Kubernetes. Não continue, a menos que tenha certeza de que não é possível recuperar o nó.

Execute estas etapas após remover fisicamente o nó corrompido do pool de nós e aplicado a alteração no cluster de administrador.

Procure o recurso personalizado da máquina da API Cluster no cluster de administrador, em que ADMIN_KUBECONFIG é o caminho para o arquivo kubeconfig e CLUSTER_NAMESPACE é o namespace do cluster afetado:
```
kubectl --kubeconfig ADMIN_KUBECONFIG \
-n CLUSTER_NAMESPACE get ma 10.200.0.8
```
O comando retorna resultados semelhantes aos a seguir:
```
NAME         PROVIDERID               PHASE
10.200.0.8   baremetal://10.200.0.8   Deleting
```
Neste exemplo, 10.200.0.8 é o endereço IP do nó que está preso na fase de exclusão.
Edite o recurso personalizado da máquina e adicione a anotação machine.cluster.x-k8s.io/exclude-node-draining. Observe que o valor da anotação em si não importa, porque, enquanto a chave estiver presente, a drenagem será ignorada:
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
annotate ma 10.200.0.8 machine.cluster.x-k8s.io/exclude-node-draining=true
```

Procure o recurso personalizado de máquina bare metal no cluster de administrador:

kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
get baremetalmachine 10.200.0.8

O comando retorna resultados semelhantes aos a seguir:

NAME         CLUSTER    READY   INSTANCEID               MACHINE
10.200.0.8   cluster1   true    baremetal://10.200.0.8   10.200.0.8

Remova o finalizador para pular a etapa de redefinição e desbloquear a remoção do nó:

kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
patch baremetalmachine 10.200.0.8 --type json -p='[{"op": "remove", "path": "/metadata/finalizers"}]'

Após alguns segundos, o nó é removido do cluster.

Como forçar a remoção de nós nos clusters do Anthos em bare metal 1.6.1

Nos clusters do Anthos em bare metal 1.6.1, é possível adicionar uma anotação para marcar um nó para a remoção forçada.

Após remover o nó do pool de nós pai, execute o comando a seguir para anotar a máquina com falha correspondente com a anotação baremetal.cluster.gke.io/force-remove. O valor da anotação em si não importa:

kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
  annotate machine 10.200.0.8 baremetal.cluster.gke.io/force-remove=true

Os clusters do Anthos em bare metal removem o nó.

Como forçar a remoção de nós no plano de controle

A remoção forçada de um nó de plano de controle é semelhante à execução de um kubeadm reset nos nós do plano de controle e requer outras etapas.

Para forçar a remoção de um nó do plano de controle dos pools de nós, é necessário executar as ações a seguir em relação ao cluster que contém o nó do plano de controle com falha:

remover o membro do etcd com falha da execução do nó com falha no cluster do etcd;
atualizar o ClusterStatus no kube para remover o apiEndpoint correspondente.

Como remover um membro do `etcd` com falha

Para remover o nó do plano de controle com falha, primeiro execute o etcdctl nos pods do etcd íntegros restantes. Para obter mais informações gerais sobre essa operação, consulte esta documentação do Kubernetes.

No procedimento a seguir, CLUSTER_KUBECONFIG é o caminho para o arquivo kubeconfig do cluster.

Procure o pod do etcd com o comando a seguir:

kubectl --kubeconfig CLUSTER_KUBECONFIG get \
 pod -n kube-system -l component=etcd -o wide

O comando retorna a lista de nós a seguir. Neste exemplo, suponha que o nó 10.200.0.8 esteja inacessível e irrecuperável:

NAME                READY   STATUS    RESTARTS   AGE     IP           NODE
etcd-357b68f4ecf0   1/1     Running   0          9m2s    10.200.0.6   357b68f4ecf0
etcd-7d7c21db88b3   1/1     Running   0          33m     10.200.0.7   7d7c21db88b3
etcd-b049141e0802   1/1     Running   0          8m22s   10.200.0.8   b049141e0802

Especifique um dos pods do etcd íntegros restantes:

kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it -n \
kube-system etcd-357b68f4ecf0 -- /bin/sh

Procure os membros existentes para encontrar o ID do membro com falha. O comando retornará uma lista:

etcdctl --endpoints=https://10.200.0.6:2379,https://10.200.0.7:2379 --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt  member list

Esse comando retorna, por exemplo:

23da9c3f2594532a, started, 7d7c21db88b3, https://10.200.0.6:2380, https://10.200.0.6:2379, false
772c1a54956b7f51, started, 357b68f4ecf0, https://10.200.0.7:2380, https://10.200.0.7:2379, false
f64f66ad8d3e7960, started, b049141e0802, https://10.200.0.8:2380, https://10.200.0.8:2379, false

Remova o membro com falha:

etcdctl --endpoints=https://10.200.0.6:2379,https://10.200.0.7:2379 --key=/etc/kubernetes/pki/etcd/peer.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt \
 member remove f64f66ad8d3e7960

Como atualizar o `ClusterStatus` e remover o `apiEndpoint` com falha

No procedimento a seguir, CLUSTER_KUBECONFIG é o caminho para o arquivo kubeconfig do cluster.

Procure a seção ClusterStatus no mapa de configuração kubeadm-config:

kubectl --kubeconfig CLUSTER_KUBECONFIG describe configmap -n \
kube-system kubeadm-config

O comando retorna resultados semelhantes aos mostrados abaixo:

...
ClusterStatus:
----
apiEndpoints:
7d7c21db88b3:
  advertiseAddress: 10.200.0.6
  bindPort: 6444
357b68f4ecf0:
  advertiseAddress: 10.200.0.7
  bindPort: 6444
b049141e0802:
  advertiseAddress: 10.200.0.8
  bindPort: 6444
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterStatus
...

Edite o mapa de configuração para remover a seção que contém o IP com falha. Este exemplo mostra os resultados da remoção do 10.200.0.8 usando o comando kubectl edit:

kubectl --kubeconfig CLUSTER_KUBECONFIG edit configmap \
-n kube-system kubeadm-config

Após a edição, o mapa de configuração será semelhante a este:

...
ClusterStatus: |
  apiEndpoints:
    7d7c21db88b3:
      advertiseAddress: 10.200.0.6
      bindPort: 6444
    357b68f4ecf0:
      advertiseAddress: 10.200.0.7
      bindPort: 6444
  apiVersion: kubeadm.k8s.io/v1beta2
  kind: ClusterStatus
...

Ao salva ro mapa de configuração editado, o nó com falha é removido do cluster.