Taints y tolerations

Imagine que tiene nodos especiales en su clúster de Kubernetes, quizá con hardware específico, como GPU, o reservados para determinadas cargas de trabajo. No querría que cualquier Pod se ejecutara en ellos, ¿verdad?

¡Aquí entran en juego los taints! Un taint es una propiedad que se aplica a un nodo y que impide planificar Pods en él, a menos que esos Pods «toleren» explícitamente dicho taint.

Los taints son muy útiles para gestionar dónde se ejecutan los Pods:

• Nodos dedicados: reserve nodos para equipos o aplicaciones específicos.
• Hardware especial: aísle nodos con GPU o SSD de alto rendimiento para los Pods que los necesiten.
• Mantenimiento: marque un nodo para realizar tareas de mantenimiento e impida temporalmente que se planifiquen nuevos Pods en él.

Considere un taint como una señal de «prohibido el paso» en un nodo. Un Pod solo puede ignorar esta señal si tiene un «permiso» correspondiente llamado toleration.

Un taint consta de una clave, un valor y un efecto. Por ejemplo: key=value:effect.

La parte «effect» de un taint indica a Kubernetes qué debe hacer con los Pods que no lo toleran. Hay tres efectos principales:

• NoSchedule
• PreferNoSchedule
• NoExecute

Veamos cada uno.

El efecto NoSchedule es el más estricto. Si un nodo tiene un taint con NoSchedule, ningún Pod se planificará en ese nodo a menos que tenga una toleration correspondiente.

Los Pods que ya se estén ejecutando en el nodo NO se ven afectados por un nuevo taint NoSchedule.

PreferNoSchedule es una versión «flexible» de NoSchedule. Kubernetes intentará evitar en la medida de lo posible planificar Pods en un nodo con taint, pero no es un requisito estricto.

Si no hay otros nodos adecuados, un Pod podría planificarse igualmente en un nodo con el taint PreferNoSchedule, incluso sin una toleration.

El efecto NoExecute es especial porque afecta a los Pods que *ya están en ejecución*. Si un nodo tiene un taint NoExecute:

• Los Pods sin una toleration correspondiente se *expulsan inmediatamente*.
• Los nuevos Pods sin una toleration correspondiente no se pueden planificar.

Esto se utiliza a menudo para vaciar nodos o gestionar fallos de nodos.

Mientras que los taints se aplican a los nodos, las tolerations se aplican a los Pods. La toleration de un Pod permite planificarlo en un nodo que tenga un taint correspondiente.

Sin una toleration correspondiente, un Pod no puede (o prefiere no) planificarse en un nodo con taint.

Las tolerations se definen en el manifiesto YAML de un Pod, dentro de la sección spec. Así es como un Pod tolera un taint con key=value:NoSchedule:

Para que un Pod se planifique en un nodo con taint, su toleration debe coincidir con el taint del nodo. La coincidencia incluye:

• Clave: debe ser la misma.
• Valor: debe ser el mismo si operator: Equal.
• Efecto: debe ser el mismo.
• Operador: puede ser Equal o Exists (es decir, cualquier valor para la clave).

Una toleration especial, key: "" operator: Exists, tolera *cualquier* taint.

Un nodo tiene el taint env=production:NoSchedule. ¿Qué configuración del Pod permitiría planificarlo en este nodo?

¡Ha aprendido sobre los taints y las tolerations!

• Los taints se aplican a los nodos para repeler Pods.
• Las tolerations se aplican a los Pods para permitir que se planifiquen en nodos con taints.
• Los efectos principales de los taints son NoSchedule, PreferNoSchedule y NoExecute.
• Las tolerations deben coincidir con la clave, el valor y el efecto del taint para que un Pod se pueda planificar.

Estas herramientas le proporcionan un control detallado sobre la ubicación de los Pods.