Versión 1.6. Ya no se admite esta versión. Para obtener más información, consulta la política de asistencia de la versión. Para obtener información sobre cómo actualizar a la versión 1.7, consulta Actualiza Anthos en equipos físicos en la documentación de la versión 1.7.

Versiones compatibles disponibles: 1.14 | 1.13 | 1.12

Eliminación forzada de nodos rotos en clústeres de Anthos alojados en equipos físicos

Cuando un nodo está roto y se debe quitar de un clúster para su reparación o reemplazo, puedes forzar su eliminación del clúster.

Eliminación forzada de los nodos en clústeres de Anthos alojados en equipos físicos 1.6.0

En la versión 1.6.0 de Anthos en equipos físicos, quita un nodo de su grupo de nodos superior da como resultado las siguientes acciones:

Desviación del nodo
Eliminación del nodo del clúster de Kubernetes
Restablecimiento de la máquina al estado anterior a la instalación de Anthos en equipos físicos

Sin embargo, si no se puede acceder al nodo, el desvío de nodos no se completa. El controlador intenta realizar el desvío del nodo varias veces y nunca avanza.

Como solución temporal, puedes aplicar los siguientes cambios para omitir los pasos de desvío y restablecimiento.

PRECAUCIÓN: esta operación requiere la actualización minuciosa de los campos de implementación específicos en los recursos personalizados de Kubernetes. No continúes, a menos que estés seguro de que el nodo no se puede recuperar.

Realiza estos pasos después de quitar físicamente el nodo dañado del grupo de nodos y aplicar el cambio en el clúster de administrador.

Busca el recurso personalizado de la máquina de la API de clúster en el clúster de administrador, en el que ADMIN_KUBECONFIG es la ruta de acceso al archivo kubeconfig, y CLUSTER_NAMESPACE es el espacio de nombres del clúster afectado:
```
kubectl --kubeconfig ADMIN_KUBECONFIG \
-n CLUSTER_NAMESPACE get ma 10.200.0.8
```
El comando muestra resultados similares a la siguiente:
```
NAME         PROVIDERID               PHASE
10.200.0.8   baremetal://10.200.0.8   Deleting
```
En este ejemplo, 10.200.0.8 es la dirección IP del nodo que se encuentra en la fase de eliminación.
Edita el recurso personalizado de la máquina y agrega la anotación machine.cluster.x-k8s.io/exclude-node-draining. Ten en cuenta que el valor de la anotación en sí no importa, ya que siempre y cuando la clave esté presente, se omitirá el desvío:
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n CLUSTER_NAMESPACE \
annotate ma 10.200.0.8 machine.cluster.x-k8s.io/exclude-node-draining=true
```

Busca el recurso personalizado de máquina de equipos físicos en el clúster de administrador:

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

El comando muestra resultados similares a la siguiente:

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

Quita el finalizador para omitir el paso de restablecimiento y desbloquear la eliminación del nodo:

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

Después de unos segundos, el nodo se quita del clúster.

Eliminación forzada de los nodos en clústeres de Anthos alojados en equipos físicos 1.6.1

En los clústeres de Anthos en equipos físicos 1.6.1, puedes agregar una anotación a fin de marcar un nodo para forzar la eliminación.

Después de quitar el nodo del grupo de nodos superior, ejecuta el siguiente comando para anotar la máquina con errores correspondiente con la anotación baremetal.cluster.gke.io/force-remove. El valor de la anotación en sí no tiene importancia:

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

Los clústeres de Anthos de equipos físicos quitan el nodo correctamente.

Fuerza la eliminación de los nodos del plano de control

La eliminación automática de un nodo del plano de control es similar a realizar un kubeadm reset en los nodos del plano de control, y requiere pasos adicionales.

Para forzar la eliminación del nodo del plano de control de los grupos de nodos, debes realizar las siguientes acciones en el clúster que contiene el nodo del plano de control con errores:

Quita el miembro etcd con errores que se ejecuta en el nodo con errores del clúster etcd
actualice el ClusterStatus en kube para quitar el apiEndpoint correspondiente.

Quita un miembro `etcd` con errores

Para quitar el nodo del plan de control con fallas, primero ejecuta etcdctl en los Pods etcd en buen estado restantes. Para obtener más información general sobre esta operación, consulta esta documentación de Kubernetes.

En el siguiente procedimiento, CLUSTER_KUBECONFIG es la ruta al archivo kubeconfig del clúster.

Busca el Pod etcd con el siguiente comando:

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

El comando muestra la siguiente lista de nodos. Para este ejemplo, supongamos que el nodo 10.200.0.8 es inaccesible y no se puede recuperar:

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

Ejecuta uno de los Pods etcd en buen estado restantes:

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

Busca los miembros actuales para encontrar el ID del miembro con errores. El comando mostrará una 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

Este comando muestra, por ejemplo, lo siguiente:

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

Quita el miembro que falla:

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

Actualiza `ClusterStatus` y quita el `apiEndpoint` con errores

En el siguiente procedimiento, CLUSTER_KUBECONFIG es la ruta al archivo kubeconfig del clúster.

Busca la sección ClusterStatus dentro del mapa de configuración kubeadm-config:

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

El comando muestra resultados similares a los que se muestran a continuación:

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

Edita el mapa de configuración para quitar la sección que contiene la IP con errores (en este ejemplo, se muestran los resultados de la eliminación de 10.200.0.8 con el comando kubectl edit):

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

Después de la edición, el mapa de configuración es similar al siguiente:

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

Cuando guardas el mapa de configuración editado, el nodo que falla se quita del clúster.