Estoy ejecutando un clúster que se comparte entre equipos y me gustaría garantizar a cada equipo una cantidad mínima de recursos, especialmente memoria.
Siguiendo elinstruccionesIntenté usar lo siguiente en su espacio de nombres:
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-quota
spec:
hard:
requests.memory: 8Gb
Sin embargo, al leer más documentos, resulta que esto no garantiza que tengan 8 Gb de memoria para sus pods. Simplemente significa que la suma del requests.memoryvalor de sus pods no puede exceder los 8 Gb. Es posible que tengan 8 Gb configurados como se indicó anteriormente, solo usen 4 Gb y no puedan crear un nuevo pod si el clúster estaba al máximo en otro lugar y el nuevo pod no se pudo programar.
También, por ejemplo, puedo crear un ResourceQuotavalor requests.memoryde 16 Gi en un clúster con solo 8 Gi de memoria total.
¿Existe alguna forma de garantizar a un equipo una cantidad fija de memoria solo para su uso?
Respuesta1
Simplemente significa que la suma de sus solicitudes de pods. El valor de la memoria no puede exceder los 8 Gb.
Sí, esta es la lógica de ResourceQuota. DeComprensión de las cuotas de recursos:
Las cuotas de recursos funcionan así:
Los usuarios colocan solicitudes de recursos informáticos en sus pods.La suma de todas las solicitudes de recursos en todos los pods en el mismo espacio de nombres no debe exceder ningún límite estricto de recursos en ningún documento de Cuota de recursos para el espacio de nombres.Tenga en cuenta que solíamos verificar la cuota de recursos tomando la suma de los límites de recursos de los pods, pero esto se modificó para usar solicitudes de recursos. La compatibilidad con versiones anteriores de los pods creados previamente se conserva porque los pods que solo especifican un límite de recursos tienen sus solicitudes de recursos predeterminadas para que coincidan con sus límites definidos. Al usuario solo se le cobra por los recursos que solicita en la cuota de recursos en comparación con sus límites porque la solicitud es la cantidad mínima de recursos garantizada por el clúster durante la programación. Para obtener más información sobre la sobrecompromiso, consulte recursos informáticos.
Si la creación de un pod provocaría que el espacio de nombres excediera cualquiera de los límites especificados en la cuota de recursos para ese espacio de nombres, entonces la solicitud fallará con el código de estado HTTP 403 PROHIBIDO.
Si la cuota está habilitada en un espacio de nombres y el usuario no especifica solicitudes en el pod para cada uno de los recursos para los cuales está habilitada la cuota, entonces la POST del pod fallará con el código de estado HTTP 403 PROHIBIDO. Sugerencia: utilice el controlador de admisión LimitRange para forzar los valores predeterminados de los límites (entonces las solicitudes de recursos serían iguales a los límites de forma predeterminada, consulte el controlador de admisión) antes de verificar la cuota para evitar este problema.
Sin embargo, el artículo amplía un poco los casos en los que es necesario dividir los recursos por separado. Y esto no es algo que ya esté implementado.
Capacidad de cuota y clúster: A veces es posible que se deseen políticas más complejas, como por ejemplo:
- Divida proporcionalmente los recursos totales del clúster entre varios equipos.
- Permita que cada inquilino aumente el uso de recursos según sea necesario, pero tenga un límite generoso para evitar el agotamiento accidental de los recursos.
- detecte la demanda de un espacio de nombres, agregue nodos y aumente la cuota.
Estas políticas podrían implementarse utilizando ResourceQuota como componente básico, escribiendo un 'controlador' que controle el uso de la cuota y ajuste los límites estrictos de la cuota de cada espacio de nombres de acuerdo con otras señales.
Supongo que necesitarás escribir una lógica personalizada en tu propio controlador.
Por favor, echa un vistazo también aCómo forzar que los espacios de nombres de Kubernetes tengan cuotas de recursos usando OPA