Cómo limpiar tareas antiguas de Kubernetes
Agencia web » Noticias digitales » Cómo depurar errores de Kubernetes "FailedScheduling"

Cómo depurar errores de Kubernetes "FailedScheduling"

Los problemas de programación de pods son uno de los errores de Kubernetes más comunes. Hay varias razones por las que un pod nuevo puede atascarse en un Pending estado con FailedScheduling como su razón. Un pod que muestre este estado no iniciará ningún contenedor, por lo que no podrá utilizar su aplicación.

Los pods pendientes causados ​​por problemas de programación normalmente no se iniciarán sin una intervención manual. Deberá encontrar la causa raíz y tomar medidas para reparar su clúster. En este artículo, aprenderá a diagnosticar y solucionar este problema para que pueda aumentar sus cargas de trabajo.

Identificación de un error de programación fallida

Es normal que los pods muestren un Pending estado por un corto tiempo después de agregarlos a su clúster. Kubernetes necesita programar instancias de contenedores en sus nodos, y esos nodos deben extraer la imagen de su registro. La primera señal de una falla en la programación de un pod es cuando siempre aparece como Pending una vez transcurrido el plazo habitual de puesta en marcha. Puede verificar el estado ejecutando Kubectl's get pods ordenado:

$ kubectl get pods NOMBRE LISTO ESTADO REINICIA EDAD demo-pod 0/1 Pendiente 0 4m05s

demo-pod más de cuatro minutos, pero todavía está en el Pending Estado. Por lo general, los pods no tardan tanto en iniciar contenedores, por lo que es hora de comenzar a investigar qué espera Kubernetes.

El siguiente paso de diagnóstico es recuperar el historial de eventos del Pod usando el describe pod ordenado:

$ kubectl describe pod demo-pod ... Eventos: Tipo Razón Antigüedad Desde Mensaje ---- ------ ---- ---- ------- ... Advertencia Error de programación 4m predeterminado- Scheduler 0/4 nodos disponibles: 1 Demasiados pods, 3 CPU insuficiente.

El registro de eventos confirma una FailedScheduling el error es el motivo de la extensión Pending Estado. Este evento se informa cuando Kubernetes no puede asignar la cantidad requerida de pods a uno de los nodos de trabajo de su clúster.

El mensaje de evento revela por qué la programación actualmente no es posible: hay cuatro nodos en el clúster, pero ninguno de ellos puede tomar el pod. Tres de los nodos tienen una capacidad de CPU insuficiente, mientras que el otro ha alcanzado un límite en la cantidad de pods que puede aceptar.

Comprensión de los errores de programación fallida y problemas similares

Kubernetes solo puede programar pods en nodos con recursos de repuesto. Los nodos que se quedan sin CPU o memoria ya no pueden aceptar pods. Los pods también pueden fallar en la programación si solicitan explícitamente más recursos de los que puede proporcionar cualquier nodo. Esto mantiene su clúster estable.

El plano de control de Kubernetes sabe qué pods ya están asignados a los nodos de su clúster. Utiliza esta información para determinar el conjunto de nodos que pueden recibir un nuevo pod. Se produce un error de programación cuando no hay ningún candidato disponible, lo que deja el grupo atascado Pending hasta que se libere la habilidad.

Es posible que Kubernetes tampoco programe pods por otros motivos. Los nodos pueden considerarse no elegibles para alojar un pod de varias maneras, incluso si tienen los recursos del sistema adecuados:

  • Es posible que un administrador haya bloqueado el nodo para evitar que reciba nuevos pods antes de una operación de mantenimiento.
  • El nodo podría tener un efecto que evita que los pods se programen. El nodo no aceptará su pod a menos que tenga una tolerancia coincidente.
  • Su pod puede estar solicitando un hostPort que ya está vinculado al nodo. Los nodos solo pueden proporcionar un número de puerto particular a un Pod a la vez.
  • Su pod puede estar usando un nodeSelector esto significa que debe programarse en un nodo con una etiqueta particular. Los nodos sin etiquetar no serán elegibles.
  • Las afinidades y antiafinidades de los pods y los nodos pueden ser insatisfactorias, lo que provoca un conflicto de programación que impide que se acepten nuevos pods.
  • El Pod puede tener un nodeName campo que identifica un nodo específico para programar. El pod quedará atascado en espera si este nodo está fuera de línea o no está programado.

es responsabilidad de kube-scheduler, el programador de Kubernetes, para trabajar con estas condiciones e identificar el conjunto de nodos que pueden alojar un nuevo pod. A FailedScheduling El evento ocurre cuando ninguno de los nodos cumple con los criterios.

Resolviendo el estado de falla del programa

El mensaje que aparece junto a FailedScheduling generalmente revelan por qué cada nodo en su clúster no pudo tomar el pod. Puede usar esta información para comenzar a solucionar el problema. En el ejemplo anterior, el clúster tenía cuatro pods, tres en los que se había alcanzado el límite de CPU y uno que había excedido el límite de conteo de pods.

La capacidad del clúster es la causa raíz en este caso. Puede escalar su clúster con nuevos nodos para abordar los problemas de consumo de hardware, agregando recursos que brindarán flexibilidad adicional. Como esto también aumentará sus costos, vale la pena verificar primero si tiene módulos redundantes en su clúster. La eliminación de los recursos no utilizados liberará capacidad para los nuevos.

Puede inspeccionar los recursos disponibles en cada uno de sus nodos usando el describe node ordenado:

$ kubectl describe node demo-node ... Recursos asignados: (los límites totales pueden ser superiores al 100 por ciento, es decir, sobreasignados). Límites de solicitudes de recursos -------- -------- ---- -- CPU 812m (90%) 202m (22%) memoria 905Mi (57%) 715Mi (45%) almacenamiento efímero 0 (0%) 0 (0%) páginas enormes-2Mi 0 (0%) 0 (0%)

Los pods de este nodo ya están solicitando el 57 % de la memoria disponible. Si un pod nuevo solicitara 1 Gi para sí mismo, el nodo no podría aceptar la solicitud de programación. Supervisar esta información para cada uno de sus nodos puede ayudarlo a evaluar si su clúster se está aprovisionando en exceso. Es importante tener capacidad adicional en caso de que uno de sus nodos falle y sus cargas de trabajo deban reprogramarse en otro.

Los errores de programación debido a la falta de nodos programables mostrarán un mensaje similar al siguiente en el FailedScheduling un evento:

0/4 nodos están disponibles: 4 nodos no eran programables

Los nodos que no se pueden programar porque se han enlazado incluirán SchedulingDisabled en su campo de estado:

$ kubectl get nodes NOMBRE ESTADO FUNCIONES EDAD VERSIÓN nodo-1 Ready,SchedulingDisabled control-plane,master 26m v1.23.3

Puede desvincular el nodo para permitirle recibir nuevos pods:

$ kubectl uncordon nodo-1 nodo/nodo-1 descordonado

Cuando los nodos no están cerrados y tienen suficientes recursos, los errores de programación suelen ser causados ​​por contaminación o error. nodeSelector campo en su Pod. Si utiliza nodeSelectorverifique que no haya cometido un error tipográfico y que haya pods en su clúster que tengan las etiquetas que especificó.

Cuando los nodos estén contaminados, asegúrese de haber incluido la tolerancia correspondiente en el manifiesto de su pod. Como ejemplo, aquí hay un nodo que se contaminó, por lo que los pods no se programarán a menos que tengan un demo-taint: allow tolerancia:

$ kubectl taint nodes node-1 demo-taint=allow:NoSchedule

Edite los manifiestos de su pod para que puedan programar en el nodo:

especulación:
  tolerancias:
    - clave: corrupción de demostración
      operador: Igual
      propuesta de: permitir
      efecto: Sin horario

Resolver el problema que causa la FailedScheduling state permitirá a Kubernetes reanudar la programación de sus pods pendientes. Comenzarán a ejecutarse automáticamente poco después de que el plano de control detecte cambios en sus nodos. No necesita reiniciar o volver a crear manualmente sus pods a menos que el problema se deba a errores en el manifiesto de su pod, como una afinidad incorrecta o nodeSelector campos.

Resumen

FailedScheduling se producen errores cuando Kubernetes no puede colocar un nuevo pod en un nodo de su clúster. Esto a menudo se debe a que los nodos existentes se están quedando sin recursos de hardware, como CPU, memoria y disco. Cuando este sea el caso, puede solucionar el problema escalando su clúster para incluir nodos adicionales.

Los errores de programación también se producen cuando los pods especifican afinidades, antiafinidades y selectores de nodos que actualmente no pueden satisfacer los nodos disponibles en su clúster. Los nodos bloqueados y contaminados reducen aún más las opciones disponibles para Kubernetes. Este tipo de problema se puede resolver revisando sus manifiestos en busca de errores tipográficos en las etiquetas y eliminando las restricciones que ya no necesita.

★ ★ ★ ★ ★