¿Cómo puedo cambiar el estado de mis nodos de NotReady o Unknown a Ready?

7 minutos de lectura
0

Mis nodos de trabajo de Amazon Elastic Kubernetes Service (Amazon EKS) tienen el estado NotReady o Unknown. Quiero que mis nodos de trabajo vuelvan a tener el estado Ready.

Breve descripción

No puede programar pods en un nodo que tenga el estado NotReady o Unknown. Solo puede programar pods en un nodo en estado Ready.

La siguiente solución aborda los nodos en estado NotReady o Unknown.

Si su nodo está en estado MemoryPressure, DiskPressure o PIDPressure, debe administrar sus recursos para poder programar más pods en el nodo.

Si el nodo se encuentra en el estado NetworkUnavailable, debe configurar correctamente la red en el nodo. Para obtener más información, consulte Estado del nodo en el sitio web de Kubernetes.

Nota: Para obtener información sobre la gestión de las expulsiones de los pods y los límites de recursos, consulte Node-pressure eviction en el sitio web de Kubernetes.

Solución

Comprobación de los pods aws-node y kube-proxy para ver por qué se encuentran en estado NotReady

Un nodos con el estado NotReady no está disponible para programar pods.

El grupo de nodos administrado podría eliminar la política de la Interfaz de red de contenedores (CNI) en el nombre de recurso de Amazon (ARN) del rol de nodo para mejorar la seguridad. Si falta esta política de CNI, los nodos cambian al estado NotReady. Para solucionar este problema, siga las instrucciones para configurar roles de IAM para cuentas de servicio (IRSA) para el DaemonSet de aws-node.

  1. Para comprobar el estado de los pods aws-node y kube-proxy, ejecute el siguiente comando:

    $ kubectl get pods -n kube-system -o wide

    El resultado es similar al siguiente:

    $ kubectl get pods -n kube-system -o wideNAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
    aws-node-qvqr2                    1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
    kube-proxy-292b4                  1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
  2. Revise el resultado. Si el estado del nodo es normal, los pods aws-node y kube-proxy deberían estar en estado Running.
    Si no aparece ningún pod aws-node o kube-proxy en la lista, vaya directamente al paso 3. Los pods aws-node y kube-proxy se administran con un DaemonSet. Esto significa que cada nodo del clúster debe tener un pod aws-node y kube-proxy en ejecución. Para obtener más información, consulte DaemonSet en el sitio web de Kubernetes.

    Si alguno de los pods se encuentra en un estado distinto de Running, ejecute el siguiente comando:

    $ kubectl describe pod yourPodName -n kube-system

    Para obtener información adicional de los registros de los pods aws-node y hube-proxy, ejecute el siguiente comando:

    $ kubectl logs yourPodName -n kube-system

    Los registros y los eventos del resultado de describe pueden indicar por qué los pods no se encuentran en estado Running. Para que un nodo cambie al estado Ready, los pods aws-node y kube-proxy deben tener el estado Running en ese nodo.

  3. Si los pods aws-node y kube-proxy no aparecen en el resultado del comando, ejecute los siguientes comandos:

    $ kubectl describe daemonset aws-node -n kube-system
    $ kubectl describe daemonset kube-proxy -n kube-system
  4. Busque en el resultado un motivo por el que no se puedan iniciar los pods:

    Nota: También puede buscar información sobre cómo programar los pods en Registro de plano de control de Amazon EKS.

  5. Confirme si las versiones de aws-node y kube-proxy son compatibles con la versión del clúster según las instrucciones de AWS. Por ejemplo, ejecute los siguientes comandos para comprobar las versiones de los pods:

    $ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

    Nota: Para actualizar la versión de aws-node, consulte Trabajar con el complemento Amazon VPC CNI plugin for Kubernetes de Amazon EKS. Para actualizar la versión de kube-proxy, siga el paso 4 de Actualización de una versión de Kubernetes de clúster de Amazon EKS.

En algunos casos, puede que el nodo se encuentre en estado Unknown. Esto significa que el kubelet del nodo no puede comunicar el estado correcto del nodo al plano de control.

Para solucionar problemas relacionados con nodos en estado Unknown, siga los pasos de las siguientes secciones.

Comprobación de la configuración de red entre los nodos y el plano de control

  1. Confirme que no haya reglas de listas de control de acceso (ACL) a la red en sus subredes que bloqueen el tráfico entre el plano de control de Amazon EKS y sus nodos de trabajo.

  2. Confirme que los grupos de seguridad del plano de control y los nodos cumplan los requisitos mínimos de entrada y salida.

  3. (Opcional) Si sus nodos están configurados para usar un proxy, confirme que el proxy permita el tráfico a los puntos de conexión del servidor de la API.

  4. Para comprobar que el nodo tenga acceso al servidor de la API, ejecute el siguiente comando netcat desde el nodo de trabajo:

    $ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

    Nota: Sustituya 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com por el punto de conexión del servidor de la API.

  5. Compruebe que las tablas de rutas estén configuradas para permitir la comunicación con el punto de conexión del servidor de la API. Esto se puede hacer a través de una puerta de enlace de Internet o de una puerta de enlace NAT. Si el clúster utiliza redes PrivateOnly, compruebe que los puntos de conexión de la VPC estén configurados correctamente.

Comprobación del estado del kubelet

  1. Utilice SSH para conectarse al nodo de trabajo afectado.

  2. Para comprobar los registros kubelet, ejecute el siguiente comando:

    $ journalctl -u kubelet > kubelet.log

    Nota: El archivo kubelet.log contiene información sobre las operaciones kubelet que puede ayudarle a averiguar la causa principal del problema con el estado del nodo.

  3. Si los registros no proporcionan información sobre la causa del problema, ejecute el siguiente comando. El comando comprueba el estado del **kubelet ** en el nodo de trabajo:

    $ sudo systemctl status kubelet  kubelet.service - Kubernetes Kubelet
       Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/kubelet.service.d
               └─10-eksclt.al2.conf
       Active: inactive (dead) since Wed 2023-12-04 08:57:33 UTC; 40s ago

    Si el kubelet no está en estado Running, ejecute el siguiente comando para reiniciar el kubelet:

    $ sudo systemctl restart kubelet

Confirmación de si se puede alcanzar el punto de conexión de la API de Amazon EC2

  1. Utilice SSH para conectarse a uno de los nodos de trabajo.
  2. Para comprobar si se puede acceder al punto de conexión de la API de Amazon Elastic Compute Cloud (Amazon EC2) en su región de AWS, ejecute el siguiente comando:
    $ nc -vz ec2.<region>.amazonaws.com 443Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!
    Nota: Sustituya us-east-1 por la región de AWS en la que se encuentre su nodo de trabajo.

Comprobación del perfil de instancia del nodo de trabajo y el ConfigMap

  1. Confirme que el perfil de instancia del nodo de trabajo tenga las políticas recomendadas.
  2. Confirme que el rol de la instancia del nodo de trabajo esté en el ConfigMap aws-auth. Para comprobar el ConfigMap, ejecute el siguiente comando:
    $ kubectl get cm aws-auth -n kube-system -o yaml
    El ConfigMap debe tener una entrada para el rol de AWS Identity and Access Management (IAM) de la instancia del nodo de trabajo. Por ejemplo:
    apiVersion: v1kind: ConfigMap
    metadata:
      name: aws-auth
      namespace: kube-system
    data:
      mapRoles: |
        - rolearn: <ARN of instance role (not instance profile)>
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes
OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 2 meses