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.

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

  2. 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
    
  3. 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
  4. 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.

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

  2. Ejecuta uno de los Pods etcd en buen estado restantes:

    kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it -n \
    kube-system etcd-357b68f4ecf0 -- /bin/sh
    
  3. 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
  4. 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.

  1. 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
    ...
  2. 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
    ...
  3. Cuando guardas el mapa de configuración editado, el nodo que falla se quita del clúster.