¿Cómo puedo evitar que un contenedor en un nodo sea desalojado?

Contexto

Durante la planificación de la carga de trabajo, dos contenedores en un nodo pueden competir por recursos. Como resultado, kubelet desaloja a ambos contenedores. En esta sección se describe cómo establecer una política para conservar uno de los contenedores.

Solución

kubelet utiliza los siguientes criterios para desalojar un pod:

• Calidad de Service (QoS): BestEffort, Burstable y Guaranteed
• Recursos consumidos basados en la solicitud de programación del pod

Los pods de diferentes clases de QoS son desalojados en la siguiente secuencia:

BestEffort -> Burstable -> Guaranteed

• Pods de BestEffort: Estos pods tienen la prioridad más baja. Serán los primeros en morir si el sistema se queda sin memoria.
• Pods de burstables: Estos pods se matarán si el sistema se queda sin memoria y no existen pods de BestEffort.
• Pods de Guaranteed: Estos pods se matarán si el sistema se queda sin memoria y no existen pods de Burstable o de BestEffort.

• Si los procesos en un pod se eliminan debido al uso excesivo de recursos (mientras que los recursos del nodo son todavía suficientes), el sistema tiende a reiniciar el contenedor o a crear un pod.
• Si los recursos son suficientes, puede asignar la clase QoS de Guaranteed a todos los pods. De esta manera, se utilizan más recursos informáticos para mejorar el rendimiento y la estabilidad del servicio, reduciendo el tiempo y los costos de solución de problemas.
• Para mejorar la utilización de los recursos, asigne la clase QoS Guaranteed a los pods de servicio y Burstable o BestEffort a otros pods (por ejemplo, filebeat).