¿Cómo puedo cambiar el estado de mis nodos de NotReady o Unknown a Ready?
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.
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
Confirme que los grupos de seguridad del plano de control y los nodos cumplan los requisitos mínimos de entrada y salida.
-
(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.
-
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.
-
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
-
Utilice SSH para conectarse al nodo de trabajo afectado.
-
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.
-
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
- Utilice SSH para conectarse a uno de los nodos de trabajo.
- 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:
Nota: Sustituya us-east-1 por la región de AWS en la que se encuentre su nodo de trabajo.$ nc -vz ec2.<region>.amazonaws.com 443Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!
Comprobación del perfil de instancia del nodo de trabajo y el ConfigMap
- Confirme que el perfil de instancia del nodo de trabajo tenga las políticas recomendadas.
- 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:
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:$ kubectl get cm aws-auth -n kube-system -o yaml
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
Vídeos relacionados
Contenido relevante
- OFICIAL DE AWSActualizada hace 8 meses
- OFICIAL DE AWSActualizada hace 3 años
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 3 meses