Kubernetes Scheduling Parte 3

Kubernetes Scheduling parte 3 es la continuación del tema referente a cómo asignar Pods en los nodos. Si eres nuevo en el tema, te recomiendo que primero leas Kubernetes Scheduling parte 1 y Kubernetes Scheduling Parte 2.

En esta ocasión, te explicaré qué son los Taints y Tolerations. Como ya verás, ambos son utilizados para poder restringir en qué nodos pueden o no ejecutarse ciertos pods.

¿Qué son los Taints?

Imagina que tienes una sala de cine y quieres reservar ciertas butacas para personas VIP. Para lograrlo, podrías poner una etiqueta en esas butacas que diga «Solo para VIP». De esta forma, cualquier persona que no tenga un pase VIP no podrá sentarse en esas butacas.

En Kubernetes, los Taints funcionan de manera similar.

• Un Taints es como esa etiqueta en la butaca: Es una marca que se coloca en un nodo (que sería como una sala de cine) para indicar que ciertos pods (que serían como los espectadores) no pueden ejecutarse en ese nodo.
• Un nodo es como una sala de cine: Es una máquina en tu clúster de Kubernetes donde se ejecutan los pods.
• Un pod es como un espectador: Es la unidad más pequeña de trabajo en Kubernetes, donde se ejecuta una aplicación.

¿Para que se usan los Taints en la práctica?

Imagina que tienes un nodo en tu clúster que quieres usar exclusivamente para ejecutar tareas críticas.

Para asegurarte de que ningún otro pod pueda interrumpir estas tareas, puedes aplicar un taint al nodo con la siguiente etiqueta o label:

kubectl taint nodes <NODO> <LABEL>=<VALOR>:<EFECTO>

Este sería un ejemplo siguiendo el formato antes mostrado:

Esto significa que ningún pod puede ser programado (NoSchedule) en ese nodo a menos que tenga una tolerancia para el taint «prod» con el valor puesto en «true».

Importante: También, es muy común que se utilice los Taints para configurar los nodos master o Control Plane de modo que no se ejecuten cargas de trabajo en ellos, dado que su función debe centrarse casi exclusivamente en los roles de etcd y apiserver.

En resumen, los taints sirven para:

• Aislamiento: Puedes aislar workloads sensibles en nodos específicos.
• Mantenimiento: Puedes marcar nodos que están en mantenimiento para evitar que se programen nuevos pods en ellos.
• Drenaje de nodos: Puedes marcar nodos que están a punto de ser eliminados para que los pods se muevan a otros nodos.

En pocas palabras, los Taints te dan un control granular sobre dónde se ejecutan tus pods en tu clúster de Kubernetes.

Especificación de Taints en los nodos

Así es como luce una definición de Taints en un objeto de tipo nodo en Kubernetes:

---
apiVersion: v1
kind: Node
metadata:
  name: k3d-default-agent-1
spec:
  taints:
    - effect: NoSchedule
      key: prod
      value: "true"

Para mayores detalles, usar el comando:

kubectl explain node.spec.taints

Por último, así se consulta si un nodo tiene Taints o no:

kubectl describe node k3d-default-agent-1

¿Qué son los Tolerations?

Las tolerancias son como los pases VIP en nuestro ejemplo. Un pod con una tolerancia al taint «prod» podría ser programado en el nodo con el taint, incluso si el nodo está marcado como «prod».

Imagina que eres un espectador con un pase VIP especial que te permite sentarte en cualquier butaca, incluso en las que tienen la etiqueta «Solo para VIP». Este pase especial sería tu Toleration o tolerancia.

¿Para qué se usan los Tolerations?

En Kubernetes, un Toleration es una característica que se añade a un pod para permitirle ejecutarse en un nodo que tiene un taint específico. Es como el pase VIP que te permite ignorar la restricción de la butaca.

Por lo tanto, el uso de Tolerations va de la mano con los Taints, porque permite definir cuáles pods son los únicos que van a soportar las prohibiciones o Taints configurados en ciertos nodos.

De este modo se cumple el propósito de destinar ciertos nodos de forma dedicada para cierto grupo particular de aplicaciones (pods). Todas las demás aplicaciones que no soportan la prohibición o Taint, simplemente tendrán que buscar otro nodo disponible.

Especificación de Tolerations en los pods

Así es como luce una definición de Tolerations en un objeto de tipo pod en Kubernetes:

---
apiVersion: v1
kind: Pod
metadata:
  name: mi-pod-de-produccion
spec:
  tolerations:
    - key: "prod"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"

Si deseas conocer más detalles sobre la definición de Tolerations en los pods, usa este comando para revisar la documentación:

kubectl explain pod.spec.tolerations

Por último, así se consulta si un pod tiene Tolerations o no:

kubectl describe pod mi-pod-de-produccion

Detalles adicionales de Taints y Tolerations

Habiendo explicado ya los conceptos y usos de Taints y Tolerations, quisiera aclarar algunos puntos adicionales:

1. Los nodos pueden tener múltiples Taints. Pero, para que un pod se ejecute en dicho nodo, tiene que tener Tolerations para todos y cada uno de los Taints del nodo donde pretende ejecutarse.
2. Hasta ahora se mostró ejemplos de Taints solo con el efecto NoSchedule, pero sin explicar mucho detalle al respecto. Cabe extender la explicación aquí:
   • NoSchedule: Prohíbe que nuevos pods se ejecuten en un nodo, a menos que toleren (Toleration) todos los Taints del nodo. Los pods que ya se encontraban ejecutando en el nodo previo a la creación de los Taints seguirán corriendo ahí con normalidad, inclusive si no cumplen con la tolerancia necesaria.
   • PreferNoSchedule: Similar a NoSchedule, pero no realiza una prohibición estricta. Sino, el scheduler intentará evitar programar el pod en ese nodo, pero si no encuentra una mejor opción, lo hará de todos modos.
   • NoExecute: Prohíbe que cualquier pod se ejecute en el nodo. Si ya existen algunos corriendo en el nodo al momento de crear el Taint, entonces se les expulsará («evict» en inglés) inmediatamente. Esto se hace para drenar los nodos y dejarlos totalmente libres de cualquier pod no deseado.
3. Los Taints y Tolerations hacen uso de un «operador» que hasta ahora hemos usado solo como Equal, el cual sirve para comprobar que un key (o llave) tenga un value (valor) igual a «algo». Sin embargo, también es posible crear un Taint con una llave o key sin ningún valor específico, para lo cual es apropiado usar el operador Exists, como se muestra debajo:

kubectl taint node k3d-default-agent-1 emergency:NoExecute

Se creó el Taint con el key «emergency» sin valor alguno. El Toleration apropiado para que coincida sería así:

---
apiVersion: v1
kind: Pod
metadata:
  name: mi-pod-critico
spec:
  tolerations:
    - key: "emergency"
      operator: "Exists"
      effect: "NoExecute"

Para mayor información y otros ejemplos, sugieron revisar Taints and Tolerations en la documentación oficial de Kubernetes.

Conclusión de Kubernetes Scheduling Parte 3

En este artículo te he mostrado cómo controlar la programación o Scheduling de pods con el uso de Taints y Tolerations.

Esto es, básicamente, trabajar con prohibiciones impuestas en algunos nodos y la tolerancia de ciertos pods a dichas prohibiciones.

En la práctica se utilizan estos dos conceptos para poder separar o destinar ciertos nodos de Kubernetes para un propósito específico. Por ejemplo, solo para ciertas aplicaciones particulares.

Si te gustó la explicación y crees que le puede ser de utilidad a algún amigo, no dudes en compartirlo.

En una próxima oportunidad, explicaré sobre la afinidad de pods y nodos que también son parte importante de Kubernetes Scheduling.