Information in this document may be out of date

This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Limit Ranges

Rangos de límites (Limit Ranges)

Aplica límites de recursos a un Namespace para restringir y garantizar la asignación y consumo de recursos informáticos.

Contexto

Por defecto, los contenedores se ejecutan sin restricciones sobre los recursos informáticos disponibles en un clúster de Kubernetes. Si el Nodo dispone de los recursos informáticos, un Pod o sus Contenedores tienen permitido consumir por encima de la cuota solicitada si no superan el límite establecido en su especificación. Existe la preocupación de que un Pod o Contenedor pueda monopolizar todos los recursos disponibles.

Utilidad

Aplicando restricciones de asignación de recursos, los administradores de clústeres se aseguran del cumplimiento del consumo de recursos por espacio de nombre (Namespace).

Un LimitRange es la política que permite:

  • Imponer restricciones de requisitos de recursos a Pods o Contenedores por Namespace.
  • Imponer las limitaciones de recursos mínimas/máximas para Pods o Contenedores dentro de un Namespace.
  • Especificar requisitos y límites de recursos predeterminados para Pods o Contenedores de un Namespace.
  • Imponer una relación de proporción entre los requisitos y el límite de un recurso.
  • Imponer el cumplimiento de las demandas de almacenamiento mínimo/máximo para Solicitudes de Volúmenes Persistentes.

Habilitar el LimitRange

La compatibilidad con LimitRange está habilitada por defecto en Kubernetes desde la versión 1.10.

Para que un LimitRange se active en un Namespace en particular, el LimitRange debe definirse con el Namespace, o aplicarse a éste.

El nombre de recurso de un objeto LimitRange debe ser un nombre de subdominio DNS válido.

Aplicando LimitRanges

  • El administrador crea un LimitRange en un Namespace.
  • Los usuarios crean recursos como Pods, Contenedores o Solicitudes de Volúmenes Persistentes en el Namespace.
  • El controlador de admisión LimitRanger aplicará valores predeterminados y límites, para todos los Pods o Contenedores que no establezcan requisitos de recursos informáticos. Y realizará un seguimiento del uso para garantizar que no excedan el mínimo, el máximo, y la proporción de ningún LimitRange definido en el Namespace.
  • Si al crear o actualizar un recurso del ejemplo (Pods, Contenedores, Solicitudes de Volúmenes Persistentes) se viola una restricción al LimitRange, la solicitud al servidor API fallará con un código de estado HTTP "403 FORBIDDEN" y un mensaje que explica la restricción que se ha violado.
  • En caso de que en se active un LimitRange para recursos de cómputos como cpu y memory, los usuarios deberán especificar los requisitos y/o límites de recursos a dichos valores. De lo contrario, el sistema puede rechazar la creación del Pod.
  • Las validaciones de LimitRange ocurren solo en la etapa de Admisión de Pod, no en Pods que ya se han iniciado (Running Pods).

Algunos ejemplos de políticas que se pueden crear utilizando rangos de límites son:

  • En un clúster de 2 nodos con una capacidad de 8 GiB de RAM y 16 núcleos, podría restringirse los Pods en un Namespace a requerir 100m de CPU con un límite máximo de 500m para CPU y requerir 200Mi de memoria con un límite máximo de 600Mi de memoria.
  • Definir el valor por defecto de límite y requisitos de CPU a 150m y el valor por defecto de requisito de memoria a 300Mi Contenedores que se iniciaron sin requisitos de CPU y memoria en sus especificaciones.

En el caso de que los límites totales del Namespace sean menores que la suma de los límites de los Pods, puede haber contienda por los recursos. En este caso, los contenedores o pods no seran creados.

Ni la contención ni los cambios en un LimitRange afectarán a los recursos ya creados.

Siguientes pasos

Consulte el documento de diseño del LimitRanger para más información.

Los siguientes ejemplos utilizan límites y están pendientes de su traducción:


Última modificación July 17, 2022 at 8:13 PM PST: [es] Fix links for k/design-proposals-archive (758650ae2f)