👩🏿‍🏫 🚾 👸🏼 Cómo acceder a los recursos del pod de Kubernetes 👏🏽 👨‍⚕️ 🐡

La recompensa de Tohad

Al comenzar con Kubernetes, es común olvidarse de configurar los recursos del contenedor. En este punto, solo necesita asegurarse de que la imagen de Docker esté funcionando y se pueda implementar en su clúster de Kubernetes.

Pero luego, la aplicación debe implementarse en el clúster de producción junto con otras aplicaciones. Para hacer esto, debe asignar recursos para el contenedor y asegurarse de que haya suficientes recursos para iniciar y ejecutar la aplicación, y en otras aplicaciones en ejecución no habrá problemas.

El equipo de Kubernetes aaS de Mail.ru ha traducido un artículo sobre recursos de contenedores (CPU y MEM), solicitudes y límites de recursos. Aprenderá los beneficios de estas configuraciones y lo que sucede si no las instala.

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 de pod YAML, verá una sección de recursos que contiene los recursos solicitados y limitados:

Recursos de pods solicitados = la suma de los recursos solicitados de todos los pods;
Limitar recursos de pod = la suma de los recursos limitantes de todos los contenedores

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:  1Gi

^{Ejemplo de recursos solicitados y limitados Un}

campo resources.requestedde la especificación del Pod es uno de los elementos que se utilizan para encontrar el nodo deseado. Ya en él, puede programar una implementación de Pod. ¿Cómo encuentras un nodo adecuado?

Kubernetes consta de varios componentes, incluido el nodo principal o el nodo principal (plano de control de Kubernetes). Hay varios procesos en el nodo principal: kube-apiserver, kube-controller-manager y kube-Scheduler.

El proceso del programador de kube es responsable de observar los módulos recién creados y buscar posibles nodos trabajadores que coincidan con todas las solicitudes de módulos, incluida la cantidad de recursos solicitados. La lista de nodos encontrados por kube-Scheduler se clasifica. El pod está programado para el sitio con las puntuaciones más altas.

^{¿Dónde se colocará la cápsula púrpura?}

La imagen muestra que el programador de kube debería programar un nuevo Pod violeta. El clúster de Kubernetes contiene dos nodos: A y B. Como puede ver, el programador de kube no puede programar un Pod en el nodo A; los recursos disponibles (no solicitados) no coinciden con las solicitudes del Pod púrpura. Por ejemplo, la memoria de 1 GB solicitada por el Pod violeta no cabrá en el nodo A, ya que la memoria disponible es de 0,5 GB. Pero el nodo B tiene suficientes recursos. Como resultado, el programador de kube decide que el destino del Pod púrpura es el Nodo B.

Ahora sabemos cómo los recursos solicitados afectan la elección del nodo para iniciar el Pod. Pero, ¿cómo afectan los recursos marginales?

Los recursos limitados son un límite que la CPU / MEM no puede cruzar. Sin embargo, la CPU es flexible, por lo que los contenedores que alcanzan el límite de la CPU no harán que el Pod se apague. En cambio, 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 limitados en detalle

_{Relación de recursos entre Docker y Kubernetes La}

mejor manera de explicar cómo funcionan los recursos solicitados y limitados es representar 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 lanzamiento de Docker.

Memoria: solicitud y límite

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Como se mencionó anteriormente, la memoria se mide en bytes. Según la documentación de Kubernetes , podemos especificar la memoria como un número. Por lo general, es un número entero, por ejemplo 2678, es decir, 2678 bytes. También puede utilizar sufijos Gy Gi, lo más importante, recuerde que no son equivalentes. El primero es decimal y el segundo es binario. A modo de ejemplo, se menciona en los K8S documentación: 128974848, 129e6, 129M, 123Mi- que son prácticamente equivalentes.

El parámetro de Kubernetes limits.memorycoincide con la marca --memoryde Docker. En caso derequest.memoryno hay una flecha para Docker porque Docker no usa este campo. Puede preguntar si esto es necesario en absoluto. Si necesito. Como dije, 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 no hay suficiente memoria instalada para una consulta?

Si el contenedor alcanza los límites de la memoria solicitada, el Pod se coloca en el grupo Pod, que se detiene cuando no hay memoria en el nodo.

¿Qué sucede si establece el límite de memoria demasiado bajo?

Si el contenedor excede el límite de memoria, se terminará debido a OOM-Killed. Y se reiniciará si es posible en función de RestartPolicy, donde es el predeterminado Always.

¿Qué sucede si no especifica la memoria solicitada?

Kubernetes tomará el límite y lo establecerá como predeterminado.

¿Qué puede pasar si no especifica el límite de memoria?

El contenedor no tiene límites, puede usar tanta memoria como quiera. Si comienza a usar toda la memoria disponible del nodo, entonces 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 programador no sabe cuántos recursos necesita el contenedor y esto puede causar serios problemas en el nodo. En este caso, sería bueno tener restricciones de espacio de nombres predeterminadas (establecidas por LimitRange). No hay límites por defecto: 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.memoryno es un valor mínimo. Esta es una descripción de la cantidad de memoria suficiente para que el contenedor se ejecute de forma continua.

Por lo general, se recomienda establecer el mismo valor para request.memoryylimit.memory... Esto evita que Kubernetes programe un Pod en un nodo que tiene suficiente memoria para ejecutar el Pod, pero no lo suficiente para ejecutarlo. Recuerde: al programar un Pod, Kubernetes solo cuenta requests.memory, limits.memoryno cuenta.

CPU: solicitud y límite

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

Con la CPU, todo es un poco más complicado. Volviendo a la imagen de la relación entre Kubernetes y Docker, puede ver que request.cpucoincide --cpu-shares, mientras que limit.cpucoincide con la bandera cpusen Docker.

La CPU que solicita Kubernetes se multiplica por 1024, la proporción de ciclos de CPU. Si desea solicitar 1 núcleo completo, debe agregarlo cpu: 1como se muestra arriba.

Solicitar un kernel completo (proporción = 1024) no significa que su contenedor lo recibirá. Si su máquina host tiene solo un núcleo y está utilizando más de un contenedor, todos los contenedores deben compartir la CPU disponible entre ellos. ¿Como sucedió esto? Echemos un vistazo a la imagen.

_{Solicitud de CPU: sistema}

de un solo núcleo Supongamos que tiene un sistema host de un solo núcleo que ejecuta contenedores. Mamá (Kubernetes) ha horneado un pastel (CPU) y quiere compartirlo con los niños (contenedores). Tres niños quieren un pastel entero (proporción = 1024), otro niño quiere la mitad del pastel (512). Mamá quiere ser justa y hace un cálculo simple.

#    ?
# 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 hijos recibirán el 28% del kernel y no el kernel completo. El cuarto hijo obtendrá el 14% del núcleo completo, no la mitad. Pero las cosas serán diferentes si tiene un sistema de múltiples núcleos.

_{Solicitud de CPU - Sistema de varios núcleos (4)}

En la imagen de arriba, puede ver que tres niños quieren un pastel completo y uno quiere la mitad. Como mamá ha horneado cuatro pasteles, cada uno de sus hijos obtendrá todo lo que quiera. En un sistema de varios núcleos, 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 han simplificado para comprender cómo se asigna la CPU entre contenedores. Por supuesto, además de los propios contenedores, hay otros procesos que también utilizan recursos de CPU. Cuando los procesos de un contenedor están inactivos, otros pueden usar su recurso. CPU: "200m"corresponde CPU: 0,2, lo que significa aproximadamente el 20% de un núcleo.

Ahora hablemos delimit.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.cpucoincide con la bandera de Docker --cpus. Esta es una nueva combinación de antiguo --cpu-periody --cpu-quota. Al configurarlo, indicamos cuántos recursos de CPU disponibles puede usar el contenedor al máximo hasta que comience a ralentizarse:

cpus es una combinación de cpu-periody es cpu-quota. cpus = 1.5equivalente a establecer cpu-period = 100000y cpu-quota = 150000;
cpu-period : período del programador CFS de la CPU , por defecto 100 microsegundos;
cpu-quota : el número de microsegundos dentro de los cpu-periodque está limitado el contenedor.

¿Qué sucede si la CPU solicitada es insuficiente?

Si el contenedor necesita más de lo que está instalado, entonces robará CPU de otros procesos.

¿Qué sucede si establece un límite de CPU insuficiente?

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 el 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 ni la solicitud ni el límite de CPU?

Al igual que con la memoria, este es el peor de los casos. El planificador no sabe cuántos recursos necesita su contenedor y esto puede causar serios problemas en el nodo. Para evitar esto, debe establecer los límites predeterminados para los espacios de nombres (LimitRange).

Recuerde, si solicita más CPU de la que pueden suministrar los nodos, el Pod no se programará. Requests.cpu- no es un valor mínimo, sino un valor suficiente para iniciar el Pod y trabajar sin fallas. Si su aplicación no realiza cálculos complejos, la mejor opción es instalar request.cpu <= 1y ejecutar 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 necesita mi Pod para ejecutar la aplicación sin problemas? ¿Cuál es la cantidad ideal? "

Desafortunadamente, no hay respuestas definitivas a estas preguntas. Si no sabe cómo se está desempeñando su aplicación, cuánta CPU o memoria necesita, la mejor opción es darle a la aplicación mucha memoria y CPU, y luego ejecutar evaluaciones comparativas.

Además de las pruebas de rendimiento, observe el comportamiento de supervisión de la aplicación durante una semana. Si los gráficos muestran que su aplicación consume menos recursos de los que solicitó, entonces puede reducir la cantidad de CPU o memoria solicitada.

Vea este panel de Grafana como ejemplo .... Muestra la diferencia entre los recursos solicitados o el límite de recursos y el uso de recursos actual.

Conclusión

Consultar y limitar los recursos ayuda a mantener el clúster de Kubernetes en buen estado. La configuración correcta de los límites minimiza los costos y mantiene las aplicaciones en ejecución en todo momento.

En resumen, hay algunas cosas a tener en cuenta:

Los recursos solicitados son la configuración que se tiene en cuenta durante el inicio (cuando Kubernetes planea alojar la aplicación). Por el contrario, es importante limitar los recursos en tiempo de ejecución, cuando la aplicación ya se está ejecutando en el nodo.
En comparación con la memoria, la CPU es un recurso regulado. En caso de CPU insuficiente, su Pod no se apagará, comenzará a ralentizarse.
Los recursos solicitados y el límite de recursos no son valores mínimos y máximos. Al identificar los recursos solicitados, se asegura de que la aplicación se ejecute sin problemas.
Es una buena práctica establecer la solicitud de memoria igual al límite de memoria.
Es bueno configurarlo según lo solicitado CPU <=1si la aplicación no realiza cálculos complejos.
Si solicita más recursos de los que tiene el nodo, el Pod nunca se programará para ese nodo.
Utilice la prueba y el monitoreo de carga para determinar la cantidad correcta de recursos / límites de recursos solicitados.

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:

Cómo acceder a los recursos del pod de Kubernetes