Usar cuotas de recursos jerárquicos.

Las cuotas de recursos de Kubernetes son una herramienta para que los administradores garanticen un porcentaje compartido de recursos entre diferentes usuarios. Una cuota de recursos, definida por un objeto ResourceQuota, proporciona restricciones que limitan el consumo de recursos agregados en un espacio de nombres único.

El controlador de jerarquía extiende el concepto de las cuotas de recursos por espacio de nombres para admitir espacios de nombres jerárquicos. Un objeto HierarchicalResourceQuota limita el consumo agregado de recursos en todos los espacios de nombres en un subárbol, lo que permite a los administradores limitar el consumo de recursos en varios espacios de nombres relacionados.

Cuando las cuotas de recursos jerárquicas están habilitadas, el controlador de jerarquía instala dos validating admission webhooks (webhooks de admisión de validación), uno para aplicar los límites de consumo de recursos y el otro para validar las cuotas de recursos jerárquicos.

Habilita las cuotas jerárquicas de recursos

El controlador de jerarquía proporciona las cuotas de recursos jerárquicos. Para habilitar las cuotas de recursos jerárquicos, sigue estos pasos:

  1. Instala el controlador de jerarquía, mediante el Sincronizador de configuración 1.6.2 o versiones posteriores.

  2. En el archivo de configuración para el operador ConfigManagement, en el objeto spec.hierarchyController, establece el valor de enableHierarchicalResourceQuota en true:

    # config-management.yaml

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  hierarchyController:
    enabled: true
    # Set to true to enable hierarchical resource quotas:
    enableHierarchicalResourceQuota: true
  # ...other fields...

  3. Aplica la configuración:

    kubectl apply -f config-management.yaml

    Después de un minuto, el controlador de jerarquía y las cuotas de recursos jerárquicos se pueden usar en tu clúster.

Para verificar que las cuotas de recursos jerárquicas estén habilitadas, sigue estos pasos:

  1. Crea un objeto HierarchicalResourceQuota en cualquier espacio de nombres, como se muestra a continuación:

    cat > example-hrq.yaml <<EOF
apiVersion: hierarchycontroller.configmanagement.gke.io/v1alpha1
kind: HierarchicalResourceQuota
metadata:
  name: example-hrq
spec:
  hard:
    configmaps: "1"
EOF

kubectl apply -f example-hrq.yaml -n default

  2. Verifica que se cree un objeto ResourceQuota nuevo llamado gke-hc-hrq en el espacio de nombres con el mismo spec.hard de 1 configmap, p. ej.:

    kubectl describe resourcequota gke-hc-hrq -n default

    Salida:

    Name:           gke-hc-hrq
Namespace:      default
Resource        Used    Hard
--------        ----    ----
configmaps      0       1

  3. Realiza una limpieza:

    kubectl delete hrq -n default example-hrq

    Asegúrate de que se quite el objeto creado de forma automática:

    kubectl get resourcequota gke-hc-hrq -n default

    Resultado:

    Error from server (NotFound): resourcequotas "gke-hc-hrq" not found

Usa cuotas de recursos jerárquicos

Configura cuotas

Configurar un HierarchicalResourceQuota es lo mismo que configurar un ResourceQuota normal, pero con un apiVersion y un kind diferentes. Por lo tanto, puedes establecer límites en los recursos del campo spec.hard como lo harías en ResourceQuota.

Considera un equipo llamado team-a que posee un servicio llamado service-a y tiene un subequipo llamado team-b, que se representan mediante espacios de nombres jerárquicos de la siguiente manera:

kubectl hns tree team-a

Resultado:

team-a
├── service-a
└── team-b

Si deseas limitar la cantidad de configmaps en team-a, pero sin limitar el número en cualquier descendientes, puedes crear un ResourceQuota normal de la siguiente manera:

cat > team-a-rq.yaml <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-rq
  namespace: team-a
spec:
  hard:
    configmaps: "1"
EOF

kubectl apply -f team-a-rq.yaml

Por el contrario, para limitar la cantidad total de configmaps en team-a y sus descendientes combinados, reemplaza apiVersion y kind en el ejemplo anterior:

cat > team-a-hrq.yaml <<EOF
# Modify the following two lines:
apiVersion: hierarchycontroller.configmanagement.gke.io/v1alpha1
kind: HierarchicalResourceQuota
# Everything below this line remains the same
metadata:
  name: team-a-hrq
  namespace: team-a
spec:
  hard:
    configmaps: "1"

EOF

kubectl apply -f team-a-hrq.yaml

El primer intento de crear un configmap en cualquiera de estos tres espacios de nombres tiene éxito. Por ejemplo, podríamos crear el configmap en uno de los espacios de nombres secundarios:

kubectl create configmap config-1 --from-literal key=value -n team-b

Resultado:

confimap/config-1 created

Sin embargo, los intentos adicionales de crear nuevos mapas de configuración en cualquiera de los tres espacios de nombres fallarán, incluidos los espacios de nombres superiores o del mismo nivel:

kubectl create configmap config-2 --from-literal key=value -n service-a
kubectl create configmap config-2 --from-literal key=value -n team-a

Resultado para ambos:

Error from server (Forbidden): admission webhook "resourcesquotasstatus.hierarchycontroller.configmanagement.gke.io" denied the request: exceeded hierarchical quota in namespace "team-a": "team-a-hrq", requested: configmaps=1, used: configmaps=1, limited: configmaps=1

Inspecciona cuotas

Para ver los límites y el uso actual de HierarchicalResourceQuota, usa el comando kubectl describe para ver una cuota de recursos normal:

kubectl describe hrq team-a-hrq -n team-a

Resultado:

# ...other fields...
Spec:
  Hard:
    Configmaps:  1
Status:
  Hard:
    Configmaps:  1
  Used:
    Configmaps:  1

Actualiza la jerarquía del espacio de nombres

Un espacio de nombres siempre está sujeto a cualquier HierarchicalResourceQuota en sus principales. La modificación de la jerarquía de espacios de nombres activa un nuevo cálculo de los usos de cualquier cuota.

Quita un espacio de nombres de un subárbol con cuotas jerárquicas

Cuando un espacio de nombres se quita de un subárbol con cuotas jerárquicas en sus principales, ya no está sujeto a estas cuotas, y sus recursos se quitan de los usos de las cuotas.

Por ejemplo, si se quita team-b del subárbol anterior, no habrá límites en el consumo de configmap en team-b. El uso de cuota jerárquica se restablece a 0, lo que significa que team-a y service-a ahora pueden consumir un configmap más en total.

Agrega un espacio de nombres a un subárbol con cuotas jerárquicas

Cuando se agrega un espacio de nombres a un subárbol con cuotas jerárquicas, está sujeto a las cuotas jerárquicas y sus usos de recursos se agregan a los usos de las cuotas.

Por ejemplo, si se agrega otro espacio de nombres al subárbol anterior, no se permite un aumento del configmap en el espacio de nombres recién agregado. Del mismo modo, cualquier uso de configmap existente en el espacio de nombres recién agregado se agrega al uso de la cuota jerárquica.

Las cuotas jerárquicas no te impiden mover un espacio de nombres nuevo a un subárbol, incluso si el uso del espacio de nombres nuevo supera el límite de cuotas jerárquicas. Sin embargo, si se excede un límite, se bloquea el uso de recursos adicionales hasta que el uso disminuya al límite o hasta que se aumente el límite. Esto es similar al comportamiento de Kubernetes ResourceQuota cuando se impone un límite que es inferior al uso existente en el espacio de nombres.

Reglas Generales

Las cuotas de recursos jerárquicos se comportan de manera similar a las cuotas de recursos de Kubernetes en casos excepcionales. Por ejemplo:

  • Si se aplican varias cuotas de recursos jerárquicos al mismo espacio de nombres, se respetarán los límites de recursos más restrictivos.
  • Si creas un límite inferior a la cantidad de recursos ya consumidos, los recursos existentes no se borrarán, pero se prohíbe cualquier consumo de recursos futuro hasta que el uso disminuya por debajo del límite o se aumente el límite.

Soluciona problemas

InternalError cuando se consumen recursos

Cuando consumes recursos, por ejemplo, cuando creas un configmap, tu solicitud puede dejar de responder durante 10 segundos y obtienes el siguiente mensaje de error:

Error from server (InternalError): Internal error occurred: resource quota evaluates timeout

No se espera que veas este mensaje de error, a menos que el Pod gke-hc-controller-manager esté en mal estado.

Para solucionar el problema, los administradores con permiso pueden borrar el Pod mediante el prefijo gke-hc-controller-manager- directamente en el espacio de nombres hnc-system. El Pod se reinicia de forma automática. Antes de que el Pod esté listo, ten en cuenta lo siguiente:

Si esto no soluciona el problema, denúncianos para su análisis, preferentemente con registros que puedas obtener mediante el siguiente comando:

kubectl logs -n hnc-system deployment/gke-hc-controller-manager -c manager

¿Qué sigue?