Get best of the week

Mejores prácticas de Kubernetes. Establecer consultas y límites de recursos

Mejores prácticas de Kubernetes. Creación de contenedores pequeños
Las mejores prácticas de Kubernetes. Organización de Kubernetes con el espacio de
nombres de mejores prácticas de Kubernetes . Comprobación de la viabilidad de Kubernetes mediante las pruebas de disponibilidad y vitalidad

Para cada recurso de Kubernetes, puede configurar dos tipos de requisitos: solicitudes y límites. El primero describe los requisitos mínimos para la disponibilidad de recursos de nodo libre necesarios para ejecutar un contenedor o hogar, el segundo limita estrictamente los recursos disponibles para el contenedor.

Cuando Kubernetes planifica una cápsula, es muy importante que los contenedores tengan suficientes recursos para el funcionamiento normal. Si planea implementar una aplicación grande en un nodo con recursos limitados, es muy posible que no funcione porque el nodo se queda sin memoria o carece de la potencia del procesador. En este artículo, veremos cómo puede resolver los problemas de falta de capacidad informática utilizando solicitudes de recursos y restricciones.

Las solicitudes y los límites son mecanismos que Kubernetes utiliza para administrar recursos como el procesador y la memoria. Las solicitudes son el resultado de que el contenedor está garantizado para recibir el recurso solicitado. Si un contenedor solicita un recurso, Kubernetes solo lo programará en el host que pueda proporcionarlo. Los límites limitan el control de que los recursos solicitados por el contenedor nunca excederán un cierto valor.



Un contenedor solo puede aumentar el poder de cómputo hasta cierto límite, después del cual será limitado. Vamos a ver cómo funciona. Por lo tanto, hay dos tipos de recursos: procesador y memoria. El Programador de Kubernetes utiliza datos de estos recursos para determinar dónde ejecutar sus pods. Una especificación típica de recursos de hogar se ve así.



Cada contenedor en el pod puede establecer sus propias consultas y restricciones, todas las cuales son aditivas. Los recursos del procesador se definen en milímetros. Si su contenedor de lanzamiento necesita dos núcleos completos, establezca el valor en 2000m. Si el contenedor necesita energía solo 1/4 del núcleo, el valor es de 250 m. Tenga en cuenta que si asigna un valor de recurso de procesador mayor que el número de núcleos del nodo más grande, entonces el lanzamiento de su hogar no se planificará en absoluto. Una situación similar sucederá si tiene un sub que necesita cuatro núcleos, y el clúster de Kubernetes consta de solo dos máquinas virtuales principales.

A menos que su aplicación esté específicamente diseñada para aprovechar múltiples núcleos (con programas tales como computación científica compleja y operaciones de bases de datos que vienen a la mente), es una buena práctica establecer las solicitudes de CPU en 1 o menos y luego ejecutar más réplicas para escalabilidad Tal solución le dará al sistema una mayor flexibilidad y confiabilidad.

Cuando se trata de limitaciones del procesador, las cosas se ponen más interesantes, ya que se considera un recurso compresible. Si su aplicación comienza a acercarse al límite de capacidad del procesador, Kubernetes comenzará a ralentizar su contenedor utilizando la aceleración de la CPU, disminuyendo la frecuencia del procesador. Esto significa que el procesador estará limitado artificialmente, proporcionando a la aplicación un rendimiento potencialmente peor, pero el proceso no se terminará ni se transmitirá.

Los recursos de memoria se definen en bytes. Por lo general, el valor en la configuración se mide en mebytes Mib, pero puede especificar cualquier valor, desde bytes hasta petabytes. Aquí la situación es la misma que con la CPU: si solicita una cantidad de memoria superior a la cantidad de memoria en sus nodos, no se programará la ejecución de este pod. Pero a diferencia de los recursos del procesador, la memoria no está comprimida, porque no hay forma de limitar su uso. Por lo tanto, la ejecución del contenedor se detendrá tan pronto como vaya más allá de los límites de la memoria asignada a él.



Es importante recordar que no puede configurar solicitudes que excedan el tamaño de los recursos que pueden proporcionar sus sitios. Las características de los recursos compartidos para las máquinas virtuales GKE se pueden encontrar en los enlaces ubicados debajo de este video.

En un mundo ideal, la configuración predeterminada del contenedor será suficiente para que los flujos de trabajo funcionen sin problemas. Pero el mundo real no es así, las personas pueden olvidarse fácilmente de configurar el uso de recursos o los hackers establecerán solicitudes y restricciones que excedan las capacidades reales de la infraestructura. Para evitar que se desarrollen estos escenarios, puede configurar las cuotas de recursos de ResourceQuota y los rangos de restricción de LimitRange.

Después de crear un espacio de nombres, puede bloquearlos con cuotas. Por ejemplo, si tiene espacios de nombres de producción y desarrollo, se utiliza una plantilla en la que no hay cuotas de producción y las cuotas de desarrollo son muy estrictas. Esto permite que, en caso de un salto brusco en el tráfico, tome todos los recursos disponibles para sí mismo, bloqueando completamente el desarrollo.

Una cuota de recursos puede verse así. En este ejemplo, hay 4 secciones: estas son las 4 líneas inferiores del código.



Veamos cada uno de ellos. Requests.cpu es el número máximo de solicitudes de alimentación de procesador combinadas que pueden provenir de todos los contenedores de espacios de nombres. En este ejemplo, puede tener 50 contenedores con solicitudes de 10m cada uno, cinco contenedores con solicitudes de 100m o solo un contenedor con una solicitud de 500m. Mientras el número total de solicitudes.cpu de este espacio de nombres sea inferior a 500 m, todo estará bien.

Las solicitudes de memoria solicitadas. Memoria es la cantidad máxima de solicitudes de memoria combinadas que pueden tener todos los contenedores en el espacio de nombres. Como en el caso anterior, puede tener 50 contenedores de 2 mib cada uno, cinco contenedores de 20 Mib cada uno o un solo contenedor con 100 Mib hasta que la cantidad total de memoria solicitada en el espacio de nombres sea inferior a 100 mebibytes.

Limits.cpu es el valor máximo de potencia combinada del procesador que pueden usar todos los contenedores de espacios de nombres. Podemos suponer que este es el límite de las solicitudes de energía del procesador.

Finalmente, limit.memory es la cantidad máxima de memoria compartida que pueden usar todos los contenedores en el espacio de nombres. Esta es una limitación de las solicitudes de memoria total.
Por lo tanto, de forma predeterminada, los contenedores en un clúster de Kubernetes funcionan con recursos informáticos ilimitados. Mediante el uso de cuotas de recursos, los administradores del clúster pueden limitar el consumo de recursos y su creación en función del espacio de nombres. En el espacio de nombres, el módulo o contenedor de pod puede consumir tanta CPU y memoria como lo determine la cuota de recursos de espacio de nombres. Sin embargo, existe la preocupación de que uno debajo o un contenedor pueda monopolizar todos los recursos disponibles. Para evitar esta situación, se utiliza el rango límite Rango Rango: la política de restringir la distribución de recursos (para pods o contenedores) en el espacio de nombres.

El rango límite proporciona limitaciones que pueden:

  • ;
  • Starage Request PersistentVolumeClaim ;
  • Request Limit ;
  • Requests/Limits .

De esta manera, puede crear un rango límite en su espacio de nombres. A diferencia de la cuota que se aplica a todo el espacio de nombres, el rango límite se utiliza para contenedores individuales. Esto puede evitar que los usuarios creen contenedores muy pequeños, o viceversa, gigantes dentro del espacio de nombres. El rango límite puede verse así.



Como en el caso anterior, se pueden distinguir 4 secciones aquí. Echemos un vistazo a cada uno.
En la sección predeterminada, las restricciones predeterminadas se establecen para el contenedor en el hogar. Si especifica estos valores en el rango límite, cualquier contenedor para el que estos valores no se hayan establecido explícitamente se guiará por los valores predeterminados.

En la sección de consulta predeterminada, defaultRequest, se configuran las consultas predeterminadas para el contenedor en el hogar. Nuevamente, si establece estos valores en el rango límite, cualquier contenedor para el que estos parámetros no estén establecidos explícitamente usará estos valores por defecto.

La sección max indica las restricciones máximas que se pueden establecer para el contenedor en el hogar. Los valores en la sección predeterminada y las restricciones para el contenedor no se pueden establecer por encima de este límite. Es importante tener en cuenta que si se establece max y la sección predeterminada está ausente, el valor máximo se convierte en el valor predeterminado.

La sección min indica las consultas mínimas que se pueden establecer para el contenedor en el hogar. Al mismo tiempo, los valores en la sección predeterminada y las solicitudes para el contenedor no se pueden establecer por debajo de este límite.

Nuevamente, es importante tener en cuenta que si se establece este valor, el valor predeterminado no, entonces el valor mínimo se convierte en la consulta predeterminada.

Como resultado, el planificador de Kubernetes utiliza estas solicitudes de recursos para ejecutar sus cargas de trabajo. Para que pueda configurar correctamente sus contenedores, es muy importante comprender cómo funciona esto. Suponga que desea ejecutar varios módulos en su clúster. Suponiendo que las especificaciones del hogar son válidas, la programación de Kubernetes utilizará el equilibrio cíclico para seleccionar el nodo para la carga de trabajo.



Kubernetes verificará si el nodo Nodo 1 tiene suficientes recursos para cumplir con las solicitudes de contenedor de pod, y si no lo hace, pasará al siguiente nodo. Si ninguno de los nodos del sistema puede satisfacer las solicitudes, los pods irán al estado Pendiente. Con las características del motor Google Kubernetes, como el autoescalado de nodos, GKE puede determinar automáticamente el estado de espera y crear algunos nodos adicionales.

Si posteriormente hay un exceso de capacidad de nodos, la función de autoescalado reducirá su número para ahorrarle dinero. Es por eso que Kubernetes planea pods basados ​​en consultas. Sin embargo, el límite puede ser mayor que las solicitudes y, en algunos casos, el nodo puede quedarse sin recursos. Llamamos a este estado estado de sobrecompromiso.



Como dije, si estamos hablando de un procesador, Kubernetes comenzará a limitar las cápsulas. Cada cápsula recibirá tanto como solicitó, pero si al mismo tiempo no alcanza el límite, comenzará a aplicarse la aceleración.

En cuanto a los recursos de memoria, aquí Kubernetes se ve obligado a tomar decisiones sobre qué pods eliminar y cuáles conservar hasta que libere recursos del sistema, de lo contrario, todo el sistema se bloqueará.

Imaginemos un escenario en el que tienes una máquina que se ha quedado sin memoria, ¿cómo hará Kubernetes?

Kubernetes buscará pods que usen más recursos de los solicitados. Por lo tanto, si sus contenedores no tienen solicitudes, significa que, por defecto, usan más de lo que solicitaron, ¡simplemente porque no pidieron nada! Dichos contenedores se convierten en los principales candidatos para el cierre. Los siguientes candidatos son contenedores que han satisfecho todas sus solicitudes, pero aún están por debajo del límite máximo.

Entonces, si Kubernetes encuentra varios pods que han excedido los parámetros de sus consultas, los ordenará por prioridad y luego eliminará los módulos de menor prioridad. Si todos los módulos tienen la misma prioridad, Kubernetes detendrá los pods que exceden sus solicitudes más que el resto de los pods.

En casos muy raros, Kubernetes puede interrumpir los hogares que aún están dentro de su alcance. Esto puede suceder cuando los componentes críticos del sistema, como el agente Kubelet o Docker, comienzan a consumir más recursos de los que tenían reservados.
Entonces, en las etapas iniciales de las pequeñas empresas, el clúster de Kubernetes puede funcionar bien sin establecer solicitudes de recursos y restricciones, pero a medida que sus equipos y proyectos comienzan a crecer en tamaño, corre el riesgo de encontrar problemas en esta área. Agregar consultas y restricciones a sus módulos y espacios de nombres requiere muy poco esfuerzo adicional y puede ahorrarle mucha molestia.

Mejores prácticas de Kubernetes. Correcto Terminar Deshabilitar


Un poco de publicidad :)


Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos.Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?

More articles:


All Articles