Kubernetes Tolerations: ejemplos, casos de uso y mejores prácticas

Efectos de los taints en Kubernetes

Repasemos los efectos de los taints que ofrece Kubernetes y que las tolerations pueden anular.

NoSchedule

El efecto NoSchedule impide que se programen pods nuevos en un nodo, a menos que tengan una toleration coincidente. Los pods que ya están en ejecución en el nodo cuando se agrega el taint no se desalojan. Esto hace que NoSchedule sea útil para reservar nodos para workloads específicos sin afectar los pods existentes.

Por ejemplo, agregar un taint hardware=gpu:NoSchedule evita que los pods sin una toleration coincidente se programen en el nodo con GPU a partir de ese momento. Los pods que ya se ejecutan ahí pueden seguir funcionando.

PreferNoSchedule

El efecto PreferNoSchedule es una restricción flexible de scheduling. Kubernetes intenta no ubicar en el nodo con taint pods que no tengan una toleration coincidente, pero puede programarlos ahí cuando es necesario. A diferencia de NoSchedule, no bloquea el scheduling de forma estricta.

Este efecto es útil cuando los administradores prefieren reservar nodos para ciertos workloads, pero aun así quieren que el scheduler use esos nodos cuando las demás opciones de ubicación son limitadas. Los pods existentes no se desalojan al agregar un taint PreferNoSchedule.

NoExecute

El efecto NoExecute afecta tanto al scheduling como a los pods que ya se ejecutan en un nodo. Los pods nuevos sin una toleration coincidente no pueden programarse ahí, mientras que los pods existentes que no toleran el taint son desalojados.

Una toleration puede incluir tolerationSeconds para que el pod permanezca temporalmente en el nodo después de que aparece un taint NoExecute coincidente. Una vez vencido ese plazo, el pod se desaloja si el taint sigue presente. Si se omite tolerationSeconds, una toleration coincidente permite que el pod permanezca mientras el taint exista.

Ejemplos de tolerations en Kubernetes

Ejemplo 1: toleration básica con NoSchedule

Supongamos que un nodo tiene el taint workload=analytics:NoSchedule. Un pod necesita una toleration coincidente para volverse elegible y poder programarse en ese nodo. El siguiente pod tolera ese taint específico:

apiVersion: v1
kind: Pod
metadata:
  name: analytics-pod
spec:
  containers:
    - name: web
      image: nginx:latest
  tolerations:
    - key: "workload"
      operator: "Equal"
      value: "analytics"
      effect: "NoSchedule"

El operador Equal exige que tanto la key como el value coincidan con el taint. Esta toleration permite que el pod llegue a nodos con el taint indicado, pero no obliga al scheduler a ubicarlo en uno de esos nodos.

Ejemplo 2: tolerar cualquier valor de un taint

El operador Exists puede usarse cuando un pod debe tolerar una clave de taint sin importar su valor. Por ejemplo, la siguiente configuración tolera cualquier taint NoSchedule cuya clave sea workload:

apiVersion: v1
kind: Pod
metadata:
  name: compute-pod
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "workload"
      operator: "Exists"
      effect: "NoSchedule"

Al usar Exists no se especifica ningún valor. Como resultado, este pod puede tolerar taints como workload=database:NoSchedule y workload=batch:NoSchedule. Otras claves o efectos de taint siguen requiriendo tolerations coincidentes por separado.

Ejemplo 3: NoExecute con tolerationSeconds

Una toleration NoExecute puede incluir tolerationSeconds para controlar cuánto tiempo permanece un pod en un nodo después de que se aplica un taint coincidente. El siguiente pod tolera un taint maintenance-window=active:NoExecute durante 100 segundos:

apiVersion: v1
kind: Pod
metadata:
  name: maintenance-worker
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "maintenance-window"
      operator: "Equal"
      value: "active"
      effect: "NoExecute"
      tolerationSeconds: 100

Si el taint se agrega mientras el pod está en ejecución, el pod puede permanecer en el nodo hasta por 100 segundos. Si el taint sigue existiendo después de ese plazo, Kubernetes desaloja el pod. Si el taint se elimina antes de que venza el plazo, el pod puede seguir ejecutándose.

Buenas prácticas con tolerations en Kubernetes

Usa tolerations solo en los workloads que las necesitan

Agrega tolerations solo cuando un workload tenga una razón clara para ejecutarse en nodos con taints. Las tolerations amplias o innecesarias debilitan el aislamiento que los taints buscan proporcionar y pueden permitir que los workloads lleguen a nodos reservados para otros fines. Esto puede provocar contención de recursos y hacer que la ubicación en nodos sea menos predecible.

Revisa las tolerations a medida que cambian los requisitos de los workloads. Evita las tolerations genéricas con Exists, salvo que el pod realmente necesite tolerar un rango amplio de taints. Prefiere claves, valores y efectos de alcance acotado, de modo que cada workload reciba solo los permisos de scheduling que requiere.

También es útil gestionar las tolerations a nivel del controlador del workload, por ejemplo en un Deployment, StatefulSet o DaemonSet. Así el comportamiento de scheduling se mantiene consistente cuando los pods se recrean o escalan.

Combina las tolerations con la afinidad de nodos

Una toleration hace que un pod sea elegible para ejecutarse en un nodo con taint, pero no lo dirige hacia ese nodo. Si un workload debe ejecutarse específicamente en un node pool determinado, combina las tolerations con la afinidad de nodos o con node selectors.

Por ejemplo, un workload de GPU puede tolerar el taint de los nodos con GPU y, al mismo tiempo, usar afinidad de nodos para exigir nodos etiquetados con el tipo de GPU adecuado. El taint mantiene alejados a los workloads comunes, mientras que la afinidad dirige el workload de GPU hacia nodos compatibles.

Elige entre afinidad de nodos requerida o preferida según qué tan estricta deba ser la ubicación. La afinidad requerida impide el scheduling en nodos que no coinciden, mientras que la preferida le da al scheduler más flexibilidad cuando no hay nodos adecuados disponibles.

Mantén la consistencia de taints y tolerations entre node pools

Usa un esquema de nombres consistente para las claves y los valores de los taints en todos los node pools. Valores inconsistentes como workload=gpu, type=gpu y node=gpu para el mismo propósito hacen que las configuraciones de los pods sean más difíciles de mantener y aumentan el riesgo de errores de scheduling.

Define taints estándar para los roles de nodo más comunes y aplícalos mediante la automatización del clúster o de la infraestructura. Así, los manifiestos de los workloads pueden usar tolerations predecibles en desarrollo, staging y producción, sin diferencias de configuración innecesarias.

La consistencia es especialmente importante cuando los nodos se crean o reemplazan automáticamente mediante sistemas de autoescalado del clúster. Los nodos nuevos deben recibir los taints y las etiquetas esperados durante el aprovisionamiento, para que los workloads se comporten igual sin importar qué instancia de nodo esté en ejecución.

Protege los nodos especializados y costosos

Usa taints para evitar que los pods de propósito general consuman recursos especializados, como GPU, instancias de alta memoria u otro hardware costoso. Solo los workloads diseñados para usar esos recursos deberían recibir las tolerations correspondientes.

Las tolerations por sí solas no garantizan que un pod solicite realmente el recurso especializado. Para los workloads de GPU, por ejemplo, configura las solicitudes o límites de recursos adecuados además de la toleration. La afinidad de nodos puede ofrecer un control adicional de ubicación cuando hay varios tipos de hardware disponibles.

Este enfoque ayuda a evitar que workloads de baja prioridad ocupen la capacidad que necesitan las aplicaciones especializadas. También puede reducir los costos de infraestructura al mantener los nodos costosos disponibles para los workloads que realmente aprovechan su hardware.

Monitorea los resultados del scheduling, no solo la configuración

Una toleration válida no garantiza que un pod se programe con éxito. La disponibilidad de recursos, la afinidad de nodos, las restricciones de topología, la afinidad y antiafinidad de pods y otras reglas del scheduler aún pueden impedir la ubicación.

Monitorea los pods pendientes, los eventos del scheduler, los taints de los nodos y la ubicación real de los pods para verificar que las políticas de scheduling se comporten según lo previsto. Comandos como kubectl describe pod y kubectl describe node pueden ayudar a identificar discrepancias en los taints y otras restricciones de scheduling.

El monitoreo también debe detectar ubicaciones inesperadas, no solo pods que quedan pendientes. Un workload que se ejecuta sin problemas en el node pool equivocado puede indicar tolerations demasiado amplias o reglas de afinidad faltantes. Las revisiones periódicas ayudan a garantizar que las políticas de scheduling sigan funcionando a medida que el clúster y sus workloads cambian.

Preguntas frecuentes

¿Qué es una toleration en Kubernetes? Una toleration es una configuración en la especificación de un pod que permite programarlo en nodos con taints coincidentes. Solo permite el scheduling. No garantiza que el pod termine en un nodo con taint, porque las solicitudes de recursos y la afinidad de nodos siguen aplicándose.

¿Cuál es la diferencia entre un taint y una toleration? Los taints se aplican a los nodos y repelen a los pods que no tienen una toleration coincidente. Las tolerations se aplican a los pods y permiten, pero no exigen, programarlos en nodos con taints coincidentes.

¿Cuál es la diferencia entre los operadores Equal y Exists? Equal exige que la clave, el valor y el efecto de la toleration coincidan con el taint, y es el operador predeterminado cuando no se especifica ninguno. Exists coincide solo por la clave, por lo que el valor debe omitirse, y tolera cualquier valor para esa clave.

¿Qué hacen los efectos NoSchedule, PreferNoSchedule y NoExecute? NoSchedule bloquea los pods nuevos sin una toleration coincidente, pero no toca los pods en ejecución. PreferNoSchedule es una versión flexible en la que el scheduler intenta evitar el nodo. NoExecute además desaloja los pods en ejecución que no toleran el taint.

¿Para qué sirve tolerationSeconds? En una toleration NoExecute, tolerationSeconds define cuánto tiempo puede permanecer un pod en un nodo después de que aparece un taint coincidente. Si pasado ese tiempo el taint sigue ahí, Kubernetes desaloja el pod. Si se omite, el pod permanece mientras el taint esté presente.

¿Una toleration hace que un pod se ejecute en un nodo con taint? No. Una toleration solo hace que el pod sea elegible. Para dirigir un pod a un node pool específico, combina la toleration con afinidad de nodos o un node selector.

Haz más eficiente el scheduling basado en tolerations con PerfectScale

Los taints y las tolerations deciden dónde pueden ejecutarse los pods, pero no dicen nada sobre si esos nodos están bien dimensionados ni si los workloads que llegan a ellos solicitan la cantidad correcta de CPU y memoria. PerfectScale es una plataforma de optimización y gobernanza para Kubernetes que se despliega con un solo comando de Helm y, a partir de ahí, ofrece información accionable y optimización autónoma en todo el stack de K8s, workloads, nodos y autoscalers, para que los node pools reservados, especializados y costosos realmente se usen de forma eficiente.

Capacidades clave de PerfectScale:

• Right-sizing autónomo de workloads: Podfit ofrece una vista granular de la salud y el costo del clúster, detecta recursos desaprovechados y problemas de resiliencia, y optimiza los workloads de forma autónoma con recomendaciones de right-sizing basadas en datos que puedes dejar en automático.
• Visibilidad del uso a nivel de nodo: Infrafit revela la capacidad ociosa de los nodos y propone los tipos de nodo adecuados para tus workloads, de modo que los node pools dedicados, con GPU y otros nodos con taints rindan al máximo nivel sin pagar por capacidad sin usar.
• Optimización de autoscalers: PerfectScale se integra con HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning y Google Autopilot, maximizando la efectividad de los sistemas que aprovisionan y reemplazan tus nodos con taints.
• Alertas en tiempo real con priorización automática: Los riesgos de resiliencia y las anomalías de costos se detectan con una priorización basada en el impacto y se envían directamente a Slack, Datadog, MS Teams o PagerDuty antes de que lleguen a tus usuarios o a tu factura de la nube.
• Tendencias, gobernanza y proyecciones: El reporte de Tendencias ofrece visibilidad detallada de las métricas de costo, pérdida y riesgo a lo largo del tiempo en clústeres, grupos de nodos, namespaces y workloads, lo que facilita el análisis de causa raíz y una planificación presupuestaria precisa.
• Cualquier entorno de Kubernetes: PerfectScale funciona tanto en clústeres on-premise como en la nube, incluyendo OpenShift, EKS, GKE, AKS y configuraciones híbridas, con soporte para contenedores de Windows y workloads efímeros o de ML, como los jobs de Airflow y Spark.

Conoce más sobre la plataforma PerfectScale