Manchas y tolerancias
La afinidad de nodos es una propiedad de un pod que hace que un pod se sienta atraído por una clase particular de nodos (esto puede ser una preferencia o un requisito estricto).
Las corrupciones son todo lo contrario: permiten que los nodos excluyan una clase específica de pods.
La tolerancia se aplica a los Pods. Las tolerancias permiten al programador programar pods con las contaminaciones correspondientes. Las tolerancias permiten la programación pero no la garantizan: el programador también evalúa otros parámetros como parte de su funcionalidad.
Las corrupciones y la tolerancia (Tolerancia) cooperan entre sí y se pueden usar para evitar que los Pods se asignen a nodos inapropiados. Se pueden aplicar uno o más taints a cada nodo, lo que significa que el nodo no aceptará aquellos Pods que no puedan tolerar estos taints.
ejemplo
Puede agregar una contaminación a un nodo con el comando kubectl taint. Por ejemplo
[root@kubernetes-master ~]# kubectl taint nodes node1 key1=value1:NoSchedule
Agregue una contaminación al nodo nodo1, su nombre clave es clave1, el valor clave es valor1 y el efecto es NoSchedule. Esto significa que solo los pods con una tolerancia que coincida con la contaminación se pueden asignar al nodo1.
Para eliminar la mancha agregada por el comando anterior, puede ejecutar:
[root@kubernetes-master ~]# kubectl taint nodes node1 key1=value1:NoSchedule-
Puede establecer tolerancias para Pods en la especificación de Pod. Las dos tolerancias siguientes coinciden con las contaminaciones creadas con el comando kubectl taint en el ejemplo anterior, por lo que si un pod tiene cualquiera de estas tolerancias, se puede programar para el nodo1:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
Aquí hay un Pod usando tolerancias:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
tolerations:
- key: "example-key"
operator: "Exists"
effect: "NoSchedule"
El valor predeterminado del operador es Igual.
Una tolerancia y una corrupción "coinciden" si tienen la misma clave y efecto, y:
- Si el operador es Existe (la tolerancia no puede especificar un valor en este momento), o
- Si el operador es Igual, sus valores serán iguales.
Tenga en cuenta que hay dos casos especiales:
Si la clave de una tolerancia está vacía y el operador existe, significa que esta tolerancia coincide con cualquier clave, valor y efecto, es decir, esta tolerancia puede tolerar cualquier contaminación.
Si el efecto está vacío, puede coincidir con todos los efectos del nombre de clave key1.
El efecto usado en el ejemplo anterior es NoSchedule, también puede usar otro valor PreferNoSchedule. Esta es la versión "optimizada" o "suave" de NoSchedule: el sistema intentará evitar la programación de pods en nodos con contaminaciones que no puede tolerar, pero no se aplica. El valor del efecto también se puede establecer en NoExecute, que se describirá en detalle a continuación.
Puede agregar múltiples contaminaciones a un nodo y múltiples configuraciones de tolerancia a un pod. El proceso en el que Kubernetes maneja múltiples contaminaciones y tolerancias es como un filtro: comience a atravesar todas las contaminaciones de un nodo y filtre aquellas contaminaciones que tengan tolerancias coincidentes en el Pod. El valor del efecto de las corrupciones restantes sin filtrar determina si el pod se asignará al nodo. Es necesario prestar atención a las siguientes situaciones:
- Si hay al menos una contaminación con un valor de efecto de NoSchedule entre las contaminaciones no ignoradas, Kubernetes no programará el Pod para ese nodo.
- Si no hay una mancha con un valor de efecto de NoSchedule entre las manchas no ignoradas, pero hay al menos una mancha con un valor de efecto de PreferNoSchedule, Kubernetes intentará no programar el pod en el nodo.
- Si hay al menos una mancha con un valor de efecto de NoExecute entre las manchas no ignoradas, Kubernetes no programará el Pod en el nodo (si el Pod aún no se está ejecutando en el nodo) ni expulsará el Pod del nodo ( si el Pod ya se está ejecutando en el nodo).
Por ejemplo, suponga que contamina un nodo como este:
[root@kubernetes-master ~]# kubectl taint nodes node1 key1=value1:NoSchedule
[root@kubernetes-master ~]# kubectl taint nodes node1 key1=value1:NoExecute
[root@kubernetes-master ~]# kubectl taint nodes node1 key2=value2:NoSchedule
Supongamos que un Pod tiene dos tolerancias:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"
En este caso, el Pod anterior no se programará para el nodo anterior porque no tiene tolerancia que coincida con la tercera corrupción. Pero si el Pod ya se está ejecutando en el nodo anterior antes de agregar la corrupción anterior al nodo, puede continuar ejecutándose en el nodo, porque la tercera corrupción es la única entre las tres que no puede tolerar este Pod.
Normalmente, si agrega una corrupción con un valor de efecto de NoExecute a un nodo, cualquier Pod que no pueda tolerar la corrupción será desalojado inmediatamente, y cualquier Pod que pueda tolerar la corrupción no será desalojado. Sin embargo, si el pod tiene un efecto cuya tolerancia es NoExecute y especifica el valor del atributo opcional de toleranciaSeconds, significa el tiempo que el pod puede continuar ejecutándose en el nodo después de agregar la corrupción anterior al nodo.
Por ejemplo:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"
tolerationSeconds: 3600
Esto significa que si el Pod se está ejecutando y se agrega una contaminación coincidente a su nodo, el Pod continuará ejecutándose en el nodo durante 3600 segundos antes de ser desalojado. Si la corrupción anterior se elimina antes de esa fecha, el Pod no será desalojado.
Por ejemplo:
Los pods se pueden evitar o desalojar de manera flexible de ciertos nodos a través de contaminaciones y tolerancias. Aquí hay algunos ejemplos de uso:
- Nodos dedicados: si desea dedicar ciertos nodos a un grupo específico de usuarios, puede agregar una contaminación a estos nodos (es decir, kubectl taint nodes nombre de nodo dedicado = nombre de grupo: Sin programación) y luego agregar las tolerancias correspondientes (fácil de hacer por escribir un controlador de admisión personalizado). Los pods con la tolerancia mencionada anteriormente se pueden programar en los nodos dedicados mencionados anteriormente y también se pueden programar en otros nodos del clúster. Si desea que estos pods se programen solo para los nodos dedicados mencionados anteriormente, también debe agregar una etiqueta similar a la contaminación mencionada anteriormente para estos nodos dedicados (por ejemplo: dedicado = groupName), y también en el anterior controlador de admisión mencionado. Pod agrega requisitos de afinidad de nodos, lo que requiere que los Pods anteriores solo se puedan programar en nodos con la etiqueta dedicada = groupName agregada.
- Nodos equipados con hardware especial: en un clúster donde algunos nodos están equipados con hardware especial (como GPU), esperamos que los Pods que no necesitan dicho hardware no se programen para estos nodos especiales, a fin de reservar recursos para Pods posteriores. que requieren dicho hardware. Para lograr esto, primero puede agregar taints a los nodos equipados con hardware especial (como kubectl taint nodes nodename special=true:NoSchedule o kubectl taint nodes nodename special=true:PreferNoSchedule), y luego agregar una tolerancia coincidente. Similar al ejemplo del nodo dedicado, la forma más fácil de agregar esta tolerancia es usar un controlador de admisión personalizado. Por ejemplo, recomendamos usar recursos extendidos para representar hardware especial, incluido el nombre del recurso extendido al contaminar los nodos configurados con hardware especial y ejecutar un controlador de admisión ExtendedResourceToleration. En este momento, debido a que los nodos se han contaminado, los pods sin las tolerancias correspondientes no se programarán para estos nodos. Pero cuando crea un Pod que usa recursos extendidos, el controlador de admisión ExtendedResourceToleration agregará automáticamente la tolerancia correcta al Pod, de modo que el Pod se programe automáticamente para estos nodos configurados con hardware especial. De esta forma, puede asegurarse de que los nodos con hardware especial estén dedicados a ejecutar pods que requieren ese hardware, y no necesita agregar tolerancias manualmente a esos pods.
- Desalojo basado en corrupción: este es el comportamiento de desalojo configurado por pod cuando falla un nodo, y el siguiente capítulo describe esta característica.
desalojo basado en la corrupción
Estado de la función: Kubernetes v1.18 [estable]
Como se mencionó anteriormente, el valor del efecto de contaminación NoExecute afectará a los siguientes pods que ya se están ejecutando en el nodo:
- Si un Pod no puede tolerar este tipo de contaminación, el Pod será desalojado inmediatamente.
- Si el Pod puede tolerar este tipo de corrupción, pero no especifica los segundos de tolerancia en la definición de tolerancia, el Pod siempre se ejecutará en este nodo.
- Si el pod puede tolerar este tipo de contaminación y especifica tolerancia en segundos, el pod puede continuar ejecutándose en este nodo durante el período de tiempo especificado.
El controlador de nodo agrega automáticamente una mancha al nodo cuando se cumple una determinada condición. Las corrupciones incorporadas actuales incluyen
- node.kubernetes.io/not-ready: el nodo no está listo. Esto es equivalente a un valor de "Falso" para el estado del nodo Listo.
- node.kubernetes.io/unreachable: el controlador de nodo no puede llegar al nodo. Esto equivale a que el valor del estado del nodo Listo sea "Desconocido".
- node.kubernetes.io/memory-pression: hay presión de memoria en el nodo.
- node.kubernetes.io/disk-pression: hay presión de disco en el nodo.
- node.kubernetes.io/pid-pression: presión PID del nodo.
- node.kubernetes.io/network-undisponible: la red del nodo no está disponible.
- node.kubernetes.io/unschedulable: el nodo no es programable.
- node.cloudprovider.kubernetes.io/uninitialized: si el kubelet comienza con un controlador de plataforma en la nube "externo" especificado, contaminará el nodo actual para marcarlo como no disponible. Después de que un controlador de cloud-controller-manager inicialice el nodo, el kubelet eliminará la contaminación.
Cuando se drena un nodo, el controlador de nodo o kubelet agrega la contaminación asociada con el efecto NoExecute. Si el estado anómalo vuelve a la normalidad, el kubelet o el controlador de nodos pueden eliminar la contaminación asociada.
En algunos casos, el servidor API no podía comunicarse con el kubelet en el nodo cuando no se podía acceder al nodo. La decisión de eliminar un Pod no se puede comunicar al kubelet hasta que se restablezca la comunicación con el servidor API. Mientras tanto, los pods programados para su eliminación pueden continuar ejecutándose en nodos particionados.
ilustrar:
El plano de control limita la velocidad a la que se agregan nuevas contaminaciones a los nodos. Este límite de tasa administra la cantidad de desalojos que pueden desencadenarse si no se puede acceder a varios nodos al mismo tiempo (por ejemplo, en el caso de una interrupción de la red).
Puede configurar los segundos de tolerancia para que el pod especifique cuánto tiempo mantendrá el pod la relación vinculante con el nodo cuando el nodo falle o no responda.
Por ejemplo, es posible que desee que una aplicación que está profundamente vinculada al estado local del nodo permanezca en el nodo actual durante un período de tiempo más largo en caso de una división de la red, para esperar a que la red se recupere y evitar siendo desalojado. La tolerancia que establezca para este Pod podría verse así:
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
ilustrar:
Kubernetes agregará automáticamente tolerancia para node.kubernetes.io/not-ready y node.kubernetes.io/unreachable a Pod, y configurará tolerationSeconds=300, a menos que el usuario o un controlador establezca explícitamente esta tolerancia.
Estas tolerancias agregadas automáticamente significan que un pod puede permanecer vinculado a un nodo durante 5 minutos cuando se detecta uno de los problemas correspondientes.
Cuando se crea un Pod en un DaemonSet, la tolerancia NoExecute para las siguientes contaminaciones se agregará automáticamente sin especificar los segundos de tolerancia:
- node.kubernetes.io/inalcanzable
- node.kubernetes.io/not-ready
Esto garantiza que los pods del DaemonSet nunca se desalojen cuando ocurran los problemas anteriores.
Agregar contaminación basada en el estado del nodo
El plano de control usa el controlador de nodo para crear automáticamente una contaminación con efecto NoSchedule que corresponde al estado del nodo.
El programador verifica las corrupciones al programar, no el estado del nodo. Esto asegura que las condiciones de los nodos no afecten directamente la programación. Por ejemplo, si el estado del nodo DiskPressure está activo, el plano de control agrega la contaminación node.kubernetes.io/disk-pression y no programa nuevos pods para los nodos afectados. Si el estado del nodo MemoryPressure está activo, el plano de control agrega la mancha node.kubernetes.io/memory-pression.
Para pods recién creados, las condiciones de los nodos se pueden ignorar agregando las tolerancias de pod correspondientes. El plano de control también agrega una tolerancia de presión de memoria node.kubernetes.io/memory en pods con una clase de QoS que no sea BestEffort. Esto se debe a que Kubernetes considera que los pods en las clases QoS garantizada o ampliable (incluso los pods que no tienen un conjunto de solicitudes de memoria) pueden hacer frente a la presión de la memoria, y los pods BestEffort recién creados no se programarán en los nodos afectados.
El controlador DaemonSet agrega automáticamente las siguientes tolerancias NoSchedule a todos los demonios en caso de que DaemonSet falle:
- node.kubernetes.io/memoria-presión
- node.kubernetes.io/disk-presion
- node.kubernetes.io/pid-presión (1.14 o posterior)
- node.kubernetes.io/unschedulable (1.10 o posterior)
- node.kubernetes.io/network-undisponible (solo para la configuración de la red del host)