Problemas comunes con nodos y pods
Descubra cómo identificar y solucionar problemas comunes con nodos y pods en clusters que ha creado con Kubernetes Engine (OKE).
Puede encontrar estos problemas con nodos y pods en clusters que ha creado con Kubernetes Engine.
Nodos de trabajador y/o pods sin respuesta atascados en estado Pendiente debido a recursos insuficientes
Es posible que vea los siguientes problemas con nodos y pods en clusters que ha creado con Kubernetes Engine:
- No hay nodos de trabajador que no respondan.
- Nodos de trabajador con un estado que se muestra como NotReady en respuesta al comando
kubectl get node
. - Pods atascados en estado Pendiente, con mensajes como
FailedScheduling due to Insufficient cpu
oFailedScheduling due to Insufficient memory
.
Una causa probable de estos problemas es la insuficiencia de recursos del sistema para los daemons del sistema operativo y Kubernetes.
Recomendamos utilizar los indicadores de kubelet --kube-reserved
y --system-reserved
para reservar recursos de CPU y memoria para los daemons del sistema Kubernetes (como kubelet
y container runtime
) y los daemons del sistema operativo (como sshd
y systemd
), respectivamente. Por ejemplo:
--kube-reserved=cpu=500m,memory=1Gi
--system-reserved=cpu=100m,memory=100Mi
Los pod que se ejecutan en un nodo de trabajador pueden consumir todos los recursos de CPU y memoria disponibles y, por lo tanto, evitar que otros procesos esenciales (como los daemons del sistema operativo y Kubernetes) se ejecuten en el nodo. Cuando los daemons del sistema operativo y Kubernetes no se pueden ejecutar, el nodo de trabajador puede dejar de responder, ser inestable y bloquearse inesperadamente con una carga pesada.
Para evitar que los pods soliciten recursos que necesitan los daemons del sistema operativo y Kubernetes, incluya los indicadores de kubelet --kube-reserved
y --system-reserved
como opciones kubelet-extra-args
en un script cloud-init personalizado. Para obtener más información y ver un ejemplo, consulte Ejemplo 4: Uso de un script cloud-init personalizado para reservar recursos para Kubernetes y daemons del sistema operativo.
Al utilizar el indicador de kubelet --kube-reserved
para reservar una parte de los recursos de CPU y memoria de un nodo de trabajador para su uso por parte de los daemons del sistema Kubernetes, tenga en cuenta las siguientes recomendaciones:
- La cantidad de recursos de CPU que recomendamos reservar para los daemons del sistema Kubernetes depende del número de núcleos de CPU en el nodo de trabajador, como se muestra en la siguiente tabla:
Número de núcleos de CPU en el nodo de trabajador 1 2 3 4 5 Mayor que 5 CPU recomendada para reservar, en milicore (m) 60 m 70 m 80 m 85 m 90 m 2,5 m adicionales por cada núcleo adicional en el nodo de trabajador - La cantidad de recurso de memoria que recomendamos reservar para los daemons del sistema Kubernetes depende de la cantidad de memoria en el nodo de trabajador, como se muestra en la siguiente tabla:
Memoria en nodo de trabajador, en GiB 4 GiB 8 GiB 16 GiB 128 GiB Más de 128 GiB Memoria recomendada para reservar, en GiB 1 GiB 1 GiB 2 GiB 9 GiB 20 MiB adicionales por cada GiB adicional de memoria de nodo de trabajador
Al utilizar el indicador de kubelet --system-reserved
para reservar una parte de los recursos de CPU y memoria de un nodo para su uso por parte de los daemons del sistema operativo, tenga en cuenta las siguientes recomendaciones:
- La cantidad de recurso de CPU que recomendamos reservar para los daemons del sistema operativo (independientemente de la unidad de nodo) es de 100 m (milicore).
- La cantidad de recurso de memoria que recomendamos reservar para los daemons del sistema operativo (independientemente de la unidad de nodo) es de 100 Mi (mebibytes).
Tenga en cuenta que es posible que nuestras recomendaciones de CPU y memoria para los indicadores de kubelet --kube-reserved
y --system-reserved
no sean óptimas para las cargas de trabajo que desea ejecutar, por lo que puede que necesite modificar los valores en consecuencia. También puede que necesite ajustar los valores a lo largo del tiempo.
Para ver la diferencia entre el total de recursos de un nodo de trabajador y los recursos del nodo que pueden utilizar las cargas de trabajo, ejecute el siguiente comando:
kubectl get node <NODE_NAME> -o=yaml | grep -A 6 -B 7 capacity
Salida de ejemplo:
allocatable:
cpu: 15743m
ephemeral-storage: "34262890849"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 234972476Ki
pods: "110"
capacity:
cpu: "16"
ephemeral-storage: 37177616Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 257197372Ki
pods: "110"
La diferencia entre la CPU y la memoria "capacidad" y "asignables" en la salida de ejemplo incluye las reservas de CPU y memoria para los daemons del sistema operativo y Kubernetes.
A partir de junio de 2024, las recomendaciones para las reservas de recursos de CPU y memoria para los daemons del sistema operativo y Kubernetes que se describen en esta sección se utilizan como valores por defecto para todas las imágenes de OKE, para todas las versiones de Kubernetes soportadas. Las recomendaciones también se utilizan como valores por defecto para todas las imágenes de plataforma para Kubernetes versión 1.30 y posteriores. Los valores por defecto se aplican tanto al especificar una imagen de OKE publicada en junio de 2024 (o posterior) como al actualizar la versión de Kubernetes que se ejecuta en un cluster a la versión 1.30 (o posterior). Si especifica una imagen de OKE publicada en junio de 2024 (o posterior) o si actualiza un cluster a la versión 1.30 de Kubernetes, le recomendamos que compruebe que las reservas por defecto son adecuadas para las cargas de trabajo que desea ejecutar.
La creación de pools de nodos virtuales muestra un mensaje de "servidor de API inaccesible"
Al crear un pool de nodos virtual en un cluster que ha creado con Kubernetes Engine, puede que aparezca el siguiente mensaje si ve los logs de solicitud de trabajo o los errores de solicitud de trabajo para el ID de solicitud de trabajo de la operación:
API Server Unreachable, Check network configuration and ensure network path between Virtual Node and API Server exist
Este mensaje indica un problema de configuración de red. Vuelva a comprobar que la red está configurada correctamente para permitir que los nodos virtuales del pool de nodos virtuales se comuniquen con el servidor de API de Kubernetes. Para obtener una configuración de red adecuada, consulte Example Network Resource Configuration for Cluster with Virtual Nodes.