{"id":82920,"date":"2020-05-26T13:42:37","date_gmt":"2020-05-26T11:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov"},"modified":"2020-05-26T13:42:37","modified_gmt":"2020-05-26T11:42:37","slug":"luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Mejores pr\u00e1cticas de Kubernetes. Configuraci\u00f3n de solicitudes y l\u00edmites de recursos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mejores pr\u00e1cticas de Kubernetes. Creaci\u00f3n de contenedores peque\u00f1os<\/a><\/noindex>
\nMejores pr\u00e1cticas de Kubernetes. Organizaci\u00f3n de Kubernetes con el espacio de nombres<\/a><\/noindex>
\nMejores pr\u00e1cticas de Kubernetes. Verificaci\u00f3n de la viabilidad de Kubernetes mediante pruebas de Readiness y Liveness.<\/a><\/noindex><\/p>\n

Para cada recurso de Kubernetes, hay dos tipos de requisitos que se pueden configurar: Requests y Limits. El primero describe los requisitos m\u00ednimos para la disponibilidad de recursos libres en un nodo, necesarios para ejecutar un contenedor o pod, mientras que el segundo limita estrictamente los recursos disponibles para el contenedor. <\/p>\n

Cuando Kubernetes planifica un pod, es muy importante que los contenedores tengan suficientes recursos para funcionar correctamente. Si planeas desplegar una aplicaci\u00f3n grande en un nodo con recursos limitados, es muy probable que no funcione debido a que el nodo se queda sin memoria o no tiene suficiente potencia de CPU. En este art\u00edculo, analizaremos c\u00f3mo resolver los problemas de falta de capacidad computacional a trav\u00e9s de solicitudes de recursos y l\u00edmites.<\/p>\n

Las solicitudes Requests y los l\u00edmites Limits son mecanismos que Kubernetes utiliza para gestionar recursos como, por ejemplo, CPU y memoria. Requests es lo que garantiza que un contenedor reciba el recurso solicitado. Si un contenedor solicita un recurso, Kubernetes lo programar\u00e1 solo en el nodo que pueda proporcionarlo. Los l\u00edmites Limits controlan que los recursos solicitados por el contenedor nunca superen un valor determinado.<\/p>\n

\"Mejores<\/a><\/noindex><\/p>\n

Un contenedor solo puede aumentar su capacidad de c\u00e1lculo hasta un cierto l\u00edmite, despu\u00e9s del cual estar\u00e1 restringido. Veamos c\u00f3mo funciona esto. As\u00ed que hay dos tipos de recursos: CPU y memoria. El programador de Kubernetes utiliza datos sobre estos recursos para determinar d\u00f3nde ejecutar tus pods. Una especificaci\u00f3n t\u00edpica de recursos para un pod se ve as\u00ed.<\/p>\n

\"Mejores
\n
\nCada contenedor en un pod puede establecer sus propias solicitudes y l\u00edmites, todo de manera aditiva. Los recursos de CPU se definen en milicoros. Si su contenedor necesita dos n\u00facleos completos para ejecutarse, establece un valor de 2000m. Si el contenedor solo requiere 1\/4 de n\u00facleo, el valor ser\u00e1 250m. Tenga en cuenta que si asigna un valor de recursos de CPU mayor que el n\u00famero de n\u00facleos del nodo m\u00e1s grande, la ejecuci\u00f3n de su pod no ser\u00e1 programada en absoluto. Una situaci\u00f3n similar ocurrir\u00e1 si tiene un pod que necesita cuatro n\u00facleos y el cl\u00faster de Kubernetes consta de solo dos m\u00e1quinas virtuales principales.<\/p>\n

A menos que su aplicaci\u00f3n est\u00e9 dise\u00f1ada espec\u00edficamente para aprovechar los beneficios de m\u00faltiples n\u00facleos (programas como c\u00e1lculos cient\u00edficos complejos y operaciones con bases de datos vienen a la mente), la mejor pr\u00e1ctica es establecer las solicitudes de CPU en 1 o menos y luego ejecutar un mayor n\u00famero de r\u00e9plicas para escalabilidad. Esta decisi\u00f3n proporcionar\u00e1 mayor flexibilidad y confiabilidad al sistema.<\/p>\n

Cuando se trata de las limitaciones de CPU, las cosas se ponen m\u00e1s interesantes, ya que se considera un recurso comprimible. Si su aplicaci\u00f3n comienza a acercarse al l\u00edmite de capacidad de CPU, Kubernetes comenzar\u00e1 a estrangular su contenedor usando CPU Throttling, que reduce la frecuencia de la CPU. Esto significa que la CPU ser\u00e1 artificialmente limitada, proporcionando a la aplicaci\u00f3n un rendimiento potencialmente peor, sin embargo, el proceso no ser\u00e1 detenido ni expulsado. <\/p>\n

Los recursos de memoria se definen en bytes. Generalmente, el valor en la configuraci\u00f3n se mide en mebibytes (Mib), pero puede establecer cualquier valor, desde bytes hasta petabytes. Aqu\u00ed se presenta la misma situaci\u00f3n que con la CPU: si env\u00eda una solicitud por m\u00e1s cantidad de memoria de la que hay en sus nodos, la ejecuci\u00f3n de este pod no ser\u00e1 programada. Pero a diferencia de los recursos de CPU, la memoria no se puede comprimir porque no hay forma de limitar su uso. Por lo tanto, la ejecuci\u00f3n del contenedor se detendr\u00e1 tan pronto como exceda la memoria asignada.<\/p>\n

\"Mejores
\n
\nEs importante recordar que no puedes configurar solicitudes que superen el tama\u00f1o de los recursos que pueden proporcionar tus nodos. Las caracter\u00edsticas de los recursos compartidos para las m\u00e1quinas virtuales de GKE se pueden encontrar en los enlaces colocados debajo de este video.<\/p>\n

En un mundo ideal, la configuraci\u00f3n del contenedor por defecto ser\u00eda m\u00e1s que suficiente para que los flujos de trabajo funcionaran sin problemas. Pero el mundo real no es as\u00ed, las personas pueden f\u00e1cilmente olvidar ajustar el uso de recursos o los hackers pueden establecer solicitudes y l\u00edmites que superen las capacidades reales de la infraestructura. Para evitar el desarrollo de tales escenarios, se pueden configurar cuotas de recursos ResourceQuota y rangos de l\u00edmites LimitRange.<\/p>\n

Despu\u00e9s de crear un espacio de nombres, se pueden bloquear con cuotas. Por ejemplo, si tienes espacios de nombres prod y dev, se utiliza una plantilla donde las cuotas de producci\u00f3n est\u00e1n completamente ausentes, mientras que las cuotas de desarrollo son muy estrictas. Esto permite que prod, en caso de un repentino aumento de tr\u00e1fico, tome todos los recursos disponibles, bloqueando completamente a dev.<\/p>\n

La cuota de recursos puede verse de esta manera. En este ejemplo, hay 4 secciones: son 4 l\u00edneas de c\u00f3digo en la parte inferior.<\/p>\n

\"Mejores
\n
\nVeamos cada una de ellas. Requests.cpu es la cantidad m\u00e1xima combinada de solicitudes de potencia de CPU que pueden provenir de todos los contenedores del espacio de nombres. En este ejemplo, puedes tener 50 contenedores con solicitudes de 10m, cinco contenedores con solicitudes de 100m o simplemente un contenedor con una solicitud de 500m. Mientras el total de requests.cpu de este espacio de nombres sea inferior a 500m, todo estar\u00e1 bien.<\/p>\n

La memoria solicitada requests.memory es la cantidad m\u00e1xima combinada de solicitudes de memoria que pueden tener todos los contenedores en el espacio de nombres. Al igual que en el caso anterior, puedes tener 50 contenedores de 2 MiB, cinco contenedores de 20 MiB o un \u00fanico contenedor de 100 MiB, siempre que el total de memoria solicitada en el espacio de nombres sea inferior a 100 mebibytes.<\/p>\n

Limits.cpu es el valor combinado m\u00e1ximo de potencia de CPU que pueden utilizar todos los contenedores en el espacio de nombres. Se puede considerar como el l\u00edmite de las solicitudes de potencia de CPU.<\/p>\n

Finalmente, limits.memory es la cantidad m\u00e1xima de memoria total que pueden usar todos los contenedores en el espacio de nombres. Esta es una limitaci\u00f3n de las solicitudes de memoria sumadas.
\nPor defecto, los contenedores en un cl\u00faster de Kubernetes funcionan con recursos de computaci\u00f3n ilimitados. A trav\u00e9s de las cuotas de recursos, los administradores del cl\u00faster pueden restringir el consumo y creaci\u00f3n de recursos bas\u00e1ndose en el espacio de nombres. En un espacio de nombres, un pod o contenedor puede consumir tanto poder de CPU y memoria como est\u00e9 definido por la cuota de recursos del espacio de nombres. Sin embargo, existe la preocupaci\u00f3n de que un pod o contenedor pueda monopolizar todos los recursos disponibles. Para prevenir esta situaci\u00f3n, se utiliza el rango l\u00edmite Limit Range, una pol\u00edtica de restricci\u00f3n de distribuci\u00f3n de recursos (para pods o contenedores) en el espacio de nombres.<\/p>\n

El rango l\u00edmite proporciona restricciones que pueden:<\/p>\n