Al comenzar con Kubernetes, es común olvidarse de configurar los recursos del contenedor. En este punto, basta con asegurarse de que la imagen de Docker funcione y se pueda implementar en el clúster de Kubernetes.
Pero luego la aplicación debe implementarse en un clúster de producción junto con otras aplicaciones. Para hacer esto, debe asignar recursos para el contenedor y asegurarse de que haya suficientes para que la aplicación esté en funcionamiento y que otras aplicaciones en ejecución no experimenten problemas.
Equipo tradujo un artículo sobre recursos de contenedores (CPU y MEM), solicitudes y limitaciones de recursos. Aprenderá los beneficios de estas configuraciones y qué sucede si no las establece.
Recursos informáticos
Disponemos de dos tipos de recursos con las siguientes unidades:
- Unidad central de procesamiento (CPU) - núcleos;
- Memoria (MEM) - bytes.
Los recursos se especifican para cada contenedor. En el siguiente archivo Pod YAML, verá una sección de recursos que contiene los recursos solicitados y limitados:
- Recursos de pod solicitados = suma de los recursos solicitados de todos los contenedores;
- Límite de recursos del pod = suma de todos los límites de recursos del pod.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiEjemplo de recursos solicitados y limitados
Campo resources.requested de la especificación Pod es uno de los elementos que se utiliza para encontrar el nodo deseado. Ya puedes planificar la implementación de Pod. ¿Cómo se encuentra un nodo adecuado?
Kubernetes consta de varios componentes, incluido un nodo maestro o nodo maestro (Kubernetes Control Plane). El nodo maestro tiene varios procesos: kube-apiserver, kube-controller-manager y kube-scheduler.
El proceso kube-scheduler es responsable de revisar los pods recién creados y encontrar posibles nodos trabajadores que coincidan con todas las solicitudes de pods, incluida la cantidad de recursos solicitados. Se clasifica la lista de nodos encontrados por kube-scheduler. El pod se programa en el nodo con las puntuaciones más altas.
¿Dónde se colocará la cápsula violeta?
En la imagen puedes ver que kube-scheduler debería programar un nuevo Pod morado. El clúster de Kubernetes contiene dos nodos: A y B. Como puede ver, kube-scheduler no puede programar un Pod en el nodo A: los recursos disponibles (no solicitados) no coinciden con las solicitudes del Pod violeta. Entonces, el 1 GB de memoria solicitado por el Pod morado no cabrá en el nodo A, ya que la memoria disponible es 0,5 GB. Pero el nodo B tiene suficientes recursos. Como resultado, kube-scheduler decide que el destino del Pod morado es el nodo B.
Ahora sabemos cómo los recursos solicitados afectan la elección del nodo para ejecutar el Pod. Pero ¿cuál es el impacto de los recursos marginales?
El límite de recursos es un límite que la CPU/MEM no puede cruzar. Sin embargo, el recurso de CPU es flexible, por lo que los contenedores que alcanzan sus límites de CPU no provocarán la salida del Pod. En su lugar, se iniciará la aceleración de la CPU. Si se alcanza el límite de uso de MEM, el contenedor se detendrá debido a OOM-Killer y se reiniciará si lo permite la configuración RestartPolicy.
Recursos solicitados y máximos en detalle
Comunicación de recursos entre Docker y Kubernetes
La mejor manera de explicar cómo funcionan las solicitudes de recursos y los límites de recursos es presentar la relación entre Kubernetes y Docker. En la imagen de arriba puede ver cómo se relacionan los campos de Kubernetes y los indicadores de inicio de Docker.
Memoria: solicitud y limitación
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Como se mencionó anteriormente, la memoria se mide en bytes. Residencia en , podemos especificar la memoria como un número. Normalmente es un número entero, por ejemplo 2678, es decir, 2678 bytes. También puedes usar sufijos. G и Gi, lo principal es recordar que no son equivalentes. El primero es decimal y el segundo es binario. Como el ejemplo mencionado en la documentación de k8s: 128974848, 129e6, 129M, 123Mi - son prácticamente equivalentes.
Opción Kubernetes limits.memory coincide con la bandera --memory de Docker. En caso de request.memory No hay una flecha para Docker porque Docker no usa este campo. Quizás te preguntes: ¿es esto siquiera necesario? Sí necesito. Como dije antes, el campo es importante para Kubernetes. Según la información que contiene, kube-scheduler decide en qué nodo programar el Pod.
¿Qué sucede si configura memoria insuficiente para una solicitud?
Si el contenedor ha alcanzado los límites de la memoria solicitada, entonces el Pod se coloca en un grupo de Pods que se detiene cuando no hay suficiente memoria en el nodo.
¿Qué sucede si estableces el límite de memoria demasiado bajo?
Si el contenedor excede el límite de memoria, se cerrará debido a OOM-Killed. Y se reiniciará si es posible según RestartPolicy, donde el valor predeterminado es Always.
¿Qué sucede si no especifica la memoria solicitada?
Kubernetes tomará el valor límite y lo establecerá como valor predeterminado.
¿Qué puede pasar si no especificas un límite de memoria?
El contenedor no tiene restricciones; puede utilizar tanta memoria como quiera. Si comienza a utilizar toda la memoria disponible del nodo, OOM lo matará. Luego, el contenedor se reiniciará, si es posible, según RestartPolicy.
¿Qué sucede si no especifica límites de memoria?
Este es el peor de los casos: el planificador no sabe cuántos recursos requiere el contenedor y esto puede causar graves problemas en el nodo. En este caso, sería bueno tener límites predeterminados en el espacio de nombres (establecidos por LimitRange). No hay límites predeterminados: el Pod no tiene límites, puede usar tanta memoria como quiera.
Si la memoria solicitada es más de la que el nodo puede ofrecer, el Pod no se programará. Es importante recordar que Requests.memory - no el valor mínimo. Esta es una descripción de la cantidad de memoria suficiente para mantener el contenedor funcionando continuamente.
Generalmente se recomienda establecer el mismo valor para request.memory и limit.memory. Esto garantiza que Kubernetes no programará un Pod en un nodo que tenga suficiente memoria para ejecutar el Pod pero no la suficiente para ejecutarlo. Tenga en cuenta: la planificación de Kubernetes Pod solo tiene en cuenta requests.memoryY limits.memory no tiene en cuenta.
CPU: solicitud y límite
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Con una CPU todo es un poco más complicado. Volviendo a la imagen de la relación entre Kubernetes y Docker, puedes ver que request.cpu partido --cpu-sharesMientras limit.cpu coincide con la bandera cpus en Docker.
La CPU que solicita Kubernetes se multiplica por 1024, la proporción de ciclos de CPU. Si desea solicitar 1 núcleo completo, deberá agregar cpu: 1como se muestra arriba.
Solicitar un kernel completo (proporción = 1024) no significa que su contenedor lo recibirá. Si su máquina host solo tiene un núcleo y está ejecutando más de un contenedor, todos los contenedores deben compartir la CPU disponible entre ellos. ¿Como sucedió esto? Miremos la foto.
Solicitud de CPU: sistema de un solo núcleo
Imaginemos que tiene un sistema host de un solo núcleo que ejecuta contenedores. Mamá (Kubernetes) horneó un pastel (CPU) y quiere dividirlo entre los niños (contenedores). Tres niños quieren un pastel entero (proporción = 1024), otro niño quiere medio pastel (512). Mamá quiere ser justa y hace un cálculo sencillo.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Según el cálculo, tres niños recibirán el 28% del núcleo, y no todo el núcleo. El cuarto niño recibirá el 14% del núcleo completo, no la mitad. Pero las cosas serán diferentes si tienes un sistema multinúcleo.
Solicitud de CPU: sistema multinúcleo (4)
En la imagen de arriba puedes ver que tres niños quieren un pastel entero y uno quiere la mitad. Como mamá horneó cuatro pasteles, cada uno de sus hijos recibirá tantos como quiera. En un sistema multinúcleo, los recursos del procesador se distribuyen entre todos los núcleos de procesador disponibles. Si un contenedor está limitado a menos de un núcleo de CPU completo, aún puede usarlo al 100%.
Los cálculos anteriores se simplifican para comprender cómo se distribuye la CPU entre los contenedores. Por supuesto, además de los propios contenedores, existen otros procesos que también utilizan recursos de la CPU. Cuando los procesos en un contenedor están inactivos, otros pueden usar su recurso. CPU: "200m" partido CPU: 0,2, lo que significa aproximadamente el 20% de un núcleo.
Ahora hablemos de limit.cpu. La CPU que limita Kubernetes se multiplica por 100. El resultado es la cantidad de tiempo que el contenedor puede usar cada 100 µs (cpu-period).
limit.cpu coincide con la bandera de Docker --cpus. Esta es una nueva combinación de lo viejo. --cpu-period и --cpu-quota. Al configurarlo, indicamos cuántos recursos de CPU disponibles el contenedor puede usar al máximo antes de que comience la limitación:
- CPUs - combinación
cpu-periodиcpu-quota. cpus = 1.5equivalente a establecercpu-period = 100000иcpu-quota = 150000; - período de CPU - período , por defecto 100 microsegundos;
- cuota-cpu - número de microsegundos dentro
cpu-period, que está delimitado por el contenedor.
¿Qué sucede si instala una CPU solicitada insuficiente?
Si el contenedor necesita más de lo que tiene instalado, robará CPU de otros procesos.
¿Qué sucede si estableces el límite de CPU demasiado bajo?
Dado que el recurso de la CPU es ajustable, se activará la limitación.
¿Qué sucede si no especifica una solicitud de CPU?
Al igual que con la memoria, el valor de la solicitud es igual al límite.
¿Qué sucede si no especifica un límite de CPU?
El contenedor utilizará tanta CPU como necesite. Si se define una política de CPU predeterminada (LimitRange) en el espacio de nombres, este límite también se usa para el contenedor.
¿Qué sucede si no especifica una solicitud o un límite de CPU?
Como ocurre con la memoria, este es el peor de los casos. El programador no sabe cuántos recursos necesita su contenedor y esto puede causar serios problemas en el nodo. Para evitar esto, debe establecer límites predeterminados para los espacios de nombres (LimitRange).
Recuerde: si solicita más CPU de la que los nodos pueden proporcionar, el Pod no se programará. Requests.cpu - no el valor mínimo, sino un valor suficiente para iniciar el Pod y funcionar sin fallos. Si la aplicación no realiza cálculos complejos, la mejor opción es instalar request.cpu <= 1 y lanzar tantas réplicas como sea necesario.
Cantidad ideal de recursos solicitados o límite de recursos
Aprendimos sobre la limitación de los recursos informáticos. Ahora es el momento de responder la pregunta: “¿Cuántos recursos requiere mi Pod para ejecutar la aplicación sin problemas? ¿Cuál es la cantidad ideal?
Desafortunadamente, no hay respuestas claras a estas preguntas. Si no sabe cómo funciona su aplicación o cuánta CPU o memoria necesita, la mejor opción es darle a la aplicación mucha memoria y CPU y luego ejecutar pruebas de rendimiento.
Además de las pruebas de rendimiento, controle el comportamiento de la aplicación durante una semana. Si los gráficos indican que su aplicación consume menos recursos de los que solicitó, puede reducir la cantidad de CPU o memoria solicitada.
Como ejemplo vea esto . Muestra la diferencia entre los recursos solicitados o el límite de recursos y el uso actual de recursos.
Conclusión
Solicitar y limitar recursos ayuda a mantener su clúster de Kubernetes en buen estado. La configuración de límites adecuada minimiza los costos y mantiene las aplicaciones funcionando en todo momento.
En resumen, hay algunas cosas a tener en cuenta:
- Los recursos solicitados son una configuración que se tiene en cuenta en el momento del inicio (cuando Kubernetes planea alojar la aplicación). Por el contrario, limitar los recursos es importante en tiempo de ejecución, cuando la aplicación ya se está ejecutando en el nodo.
- Comparada con la memoria, la CPU es un recurso regulado. Si no hay suficiente CPU, su Pod no se apagará y se activará el mecanismo de aceleración.
- ¡Los recursos solicitados y el límite de recursos no son valores mínimos ni máximos! Al definir los recursos solicitados, te aseguras que la aplicación se ejecutará sin problemas.
- Una buena práctica es establecer la solicitud de memoria igual al límite de memoria.
- Ok instalación solicitada
CPU <=1, si la aplicación no realiza cálculos complejos. - Si solicita más recursos de los que están disponibles en un nodo, el Pod nunca se programará para ese nodo.
- Para determinar la cantidad correcta de recursos solicitados/límites de recursos, utilice pruebas de carga y monitoreo.
Espero que este artículo le ayude a comprender el concepto básico de limitación de recursos. Y podrás aplicar este conocimiento en tu trabajo.
¡Buena suerte!
Qué más leer:
- .
- .
- .
Fuente: habr.com