El libro aprendido en la sección anterior limita los recursos de los pods individuales, usando LimitRange. Si necesitamos limitar la cantidad total de recursos disponibles en el espacio de nombres, no podemos satisfacerlo, necesitamos crear un objeto ResourceQuota para lograrlo.
1. Recurso ResourceQuota
El complemento de control ResourceQuota puede verificar si el pod recién agregado hará que los recursos totales excedan ResourceQuota, de manera similar a los complementos LimitRange y LimitRange. Solo para pods recién creados y no afecta a los pods existentes.
Las cuotas de recursos limitan la cantidad total de recursos que pueden usar los pods y el almacenamiento de PVC en un espacio de nombres. Al mismo tiempo, también puede limitar la cantidad de pods, PVC y otros objetos de la API que los usuarios pueden crear en este espacio de nombres. Los recursos más procesados son la CPU y la memoria.
Crear ResourceQuota para CPU y memoria
archivo yaml: cuota-cpu-memory.yaml
apiVersión：v1
kind:Cuota de recursos
metadatos:
nombre: cpu-and0mem
Especificaciones:
duro:
solicitudes.cpu:400m
solicitudes.memoria:200Mi
limites.cpu:600m
límites.memoria:500Mi
Como se indicó anteriormente, la cantidad total de solicitudes y los límites se definen para la CPU y la memoria, en lugar de simplemente definir una cantidad total para cada recurso. En comparación con LimitRange, la estructura es diferente: las solicitudes y los límites de todos los recursos se definen en un campo.
Al igual que limitRange, el objeto ResourceQuota se aplica al espacio de nombres que creó, pero la diferencia es que ResourceQuota puede limitar la cantidad total de solicitudes de recursos y los límites de todos los pods, no de cada pod y contenedor individual.
Ver cuota y uso de cuota
kubectl describir cuota
Crear LimitRange al mismo tiempo que ResourceQuota
Nota: La creación de una ResourceQuota también requiere la creación de un objeto LimitRange. De lo contrario, no se puede crear con éxito, porque no ha fijado ninguna solicitud ni límite de recursos.
2. Especifique una cuota para el almacenamiento persistente
ResourceQuota exclusivo puede limitar la cantidad máxima de almacenamiento persistente que se puede declarar en un espacio de nombres.
documento yaml: cuota-almacenamiento.yaml
apiVersion:v1
kind:Cuota de recursos
metadatos:
nombre: almacenamiento
Especificaciones:
duro:
solicitudes.almacenamiento:500Gi
ssd.storageclass.storage.k8s.io/requests.storage:300Gi
almacenamiento.clase.almacenamiento.estándar.k8s.io/requests.storage:1Ti
3. Limite la cantidad de objetos que se pueden crear
ResourceQuota puede limitar la cantidad de pods, ReplicationControllers, Services y otros objetos en un espacio de nombres. El administrador de la bandada puede limitar la cantidad de objetos que los usuarios pueden crear en función, por ejemplo, de un plan de pago, y también se puede usar para limitar la cantidad de puertos de nodo que puede usar la IP o el servicio de la red pública.
yaml文件：cuota-objeto-recuento.yaml
apiVersion:v1
kind:Cuota de recursos
metadatos:
nombre:objetos
Especificaciones:
duro:
vainas: 10
controladores de replicación: 5
secretos: 10
mapas de configuración: 10
reclamaciones de volumen persistentes: 4
servicios:5
servicios.balances de carga:1
servicios.nodeports:2
ssd.storageclass.storage.k8s.io/persistentvolumeclains:2
La cuota de número de objetos actualmente puede limitar la configuración de objetos:
vaina
Controlador de replicación
Secreto
Mapa de configuración
Reclamación de volumen persistente
Servicio (general) y dos tipos específicos de Servicio, como el Servicio LoadBalancer (service.loadbalances) y el Servicio NodePort (services.nodeports)
En la actualidad, las limitaciones de ReplicaSet, Job, Deployment, Ingress, etc. aún necesitan leer los últimos documentos
4. Especifique cuotas para estados de pod específicos o niveles de QoS
La cuota creada se aplica a todos los pods, independientemente del estado actual del pod y del nivel de QoS.
Pero la cuota puede estar limitada por un conjunto de ámbitos de cuota. Actualmente hay 4 tipos de ámbitos de cuota:
BestEffort、NotBestEffort、Termination和NotTerminating
Los rangos BestEffort y NotBestEffort determinan si la cuota se aplica a los pods del nivel BestEffort Qos o a ambos niveles (Burstable y Guaranteed)
Los dos rangos de Terminating y NotTerminating describen:
Para cada pod, se marca como Failed y cuánto tiempo puede ejecutarse antes de que realmente se detenga.Esto se logra a través de activeDeadlineSeconds configurado en la especificación del pod. Esta propiedad define la cantidad de segundos que se le permite a un pod continuar ejecutándose en un nodo desde el momento en que comienza a intentar detenerse hasta que se marca como Fallido y luego se detiene. La cuota de finalización se aplica a los pods configurados con activeDeadlineSeconds. Y NotTerminating se aplica a los pods que no especifican esta configuración.
ilustrar:
Al crear una ResourceQuota, puede especificar un ámbito para ella y el pod de destino debe coincidir con todos los ámbitos configurados por la cuota. Además, el rango de cuota también determina el contenido que puede ser limitado por la cuota: el rango BestEffort solo permite limitar la cantidad de pods, mientras que los otros tres rangos pueden limitar las solicitudes y los límites de CPU/memoria además de la cantidad. de vainas