Utiliser des quotas de ressources hiérarchiques

Les quotas de ressources Kubernetes sont des outils permettant aux administrateurs de garantir un partage équitable des ressources entre les différents utilisateurs. Un quota de ressources, défini par un objet ResourceQuota, fournit des contraintes limitant la consommation de ressources agrégées dans un seul espace de noms.

Hierarchy Controller étend le concept de quotas de ressources par espace de noms pour assurer la compatibilité avec les espaces de noms hiérarchiques. Un objet HierarchicalResourceQuota limite la consommation globale des ressources sur tous les espaces de noms d'une sous-arborescence, ce qui permet aux administrateurs de limiter la consommation de ressources à travers plusieurs espaces de noms associés.

Lorsque les quotas de ressources hiérarchiques sont activés, Hierarchy Controller installe deux webhooks d'admission de validation, un pour appliquer réellement les limites de consommation des ressources et un autre pour valider les quotas de ressources hiérarchiques.

Activer les quotas de ressources hiérarchiques

Les quotas des ressources hiérarchiques sont fournis par Hierarchy Controller. Pour activer les quotas de ressources hiérarchiques, procédez comme suit :

  1. Installez Hierarchy Controller, à l'aide de Config Sync version 1.6.2 ou ultérieure.

  2. Dans le fichier de configuration de Config Management Operator, dans l'objet spec.hierarchyController, définissez la valeur de enableHierarchicalResourceQuota sur 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. Appliquez la configuration :

    kubectl apply -f config-management.yaml

    Après environ une minute, Hierarchy Controller et les quotas de ressources hiérarchiques deviennent utilisables sur votre cluster.

Pour vérifier que les quotas de ressources hiérarchiques sont activés, procédez comme suit :

  1. Créez un objet HierarchicalResourceQuota dans n'importe quel espace de noms, par exemple :

    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. Vérifiez qu'un nouvel objet ResourceQuota appelé gke-hc-hrq est créé dans l'espace de noms avec la même configuration spec.hard de 1 configmap, par exemple :

    kubectl describe resourcequota gke-hc-hrq -n default

    Sortie :

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

  3. Effectuez un nettoyage :

    kubectl delete hrq -n default example-hrq

    Assurez-vous que l'objet créé automatiquement est supprimé :

    kubectl get resourcequota gke-hc-hrq -n default

    Sortie :

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

Utiliser des quotas de ressources hiérarchiques

Définir des quotas

Définir un objet HierarchicalResourceQuota revient à définir un objet ResourceQuota standard, mais avec des valeurs apiVersion et kind différentes. Par conséquent, vous pouvez définir des limites sur les ressources du champ spec.hard comme vous le feriez dans l'objet ResourceQuota.

Prenons l'exemple d'une équipe appelée team-a qui possède un service appelé service-a, et qui possède une sous-équipe appelée team-b, tous représentés par des espaces de noms hiérarchiques comme suit :

kubectl hns tree team-a

Sortie :

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

Si vous souhaitez limiter le nombre d'objets configmaps dans team-a, mais sans limiter le nombre dans les descendants, vous pouvez créer un objet ResourceQuota standard comme suit :

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

En revanche, pour limiter le nombre total de configmaps dans team-a et ses descendants, remplacez apiVersion et kind dans l'exemple précédent :

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

La première tentative de création d'une ressource configmap dans l'un de ces trois espaces de noms aboutit. Par exemple, nous pouvons choisir de créer configmap dans l'un des espaces de noms enfants :

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

Sortie :

confimap/config-1 created

Mais toute autre tentative de création de ConfigMaps dans l'un des trois espaces de noms échouera, y compris dans les espaces de noms des frères ou parents :

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

Résultat pour ces deux éléments :

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

Quotas d'inspection

Pour afficher les limites et l'utilisation actuelles de l'objet HierarchicalResourceQuota, exécutez la commande kubectl describe pour afficher un quota de ressources standard :

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

Sortie :

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

Mettre à jour la hiérarchie des espaces de noms

Un espace de noms est toujours soumis à tout objet HierarchicalResourceQuota dans ses ancêtres. La modification de la hiérarchie des espaces de noms déclenche un nouveau calcul des utilisations des quotas.

Supprimer un espace de noms d'une sous-arborescence avec des quotas hiérarchiques

Lorsqu'un espace de noms est retiré d'une sous-arborescence avec des quotas hiérarchiques dans ses ancêtres, il n'est plus soumis à ces quotas et ses ressources sont supprimées des utilisations de ces quotas.

Par exemple, si team-b est supprimé de la sous-arborescence précédente, la consommation de configmap dans team-b ne sera pas limitée. L'utilisation des quotas hiérarchiques est réinitialisée sur 0, ce qui signifie que team-a et service-a peuvent désormais utiliser un configmap supplémentaire au total.

Ajouter un espace de noms à une sous-arborescence avec des quotas hiérarchiques

Lorsqu'un espace de noms est ajouté à une sous-arborescence avec des quotas hiérarchiques, il est soumis aux quotas hiérarchiques et ses utilisations de ressources sont basées sur les utilisations des quotas.

Par exemple, si un autre espace de noms est ajouté à la sous-arborescence précédente, aucune consommation de configmap supplémentaire n'est autorisée dans le nouvel espace de noms. De même, toute utilisation existante de configmap dans l'espace de noms récemment ajouté est ajoutée à l'utilisation des quotas hiérarchiques.

Les quotas hiérarchiques ne vous empêchent pas de déplacer un nouvel espace de noms dans une sous-arborescence, même si l'utilisation du nouvel espace de noms dépasse la limite au sein des quotas hiérarchiques. Toutefois, si une limite est dépassée, l'utilisation supplémentaire des ressources est interdite jusqu'à ce que l'utilisation soit inférieure à la limite ou jusqu'à ce que la limite soit augmentée. Ce comportement est semblable au comportement de Kubernetes ResourceQuota lorsqu'une limite imposée est inférieure à l'utilisation existante dans l'espace de noms.

Règles générales

Les quotas de ressources hiérarchiques se comportent de la même manière que les quotas de ressources Kubernetes dans les cas limites d'utilisation. Exemple :

  • Si plusieurs quotas de ressources hiérarchiques s'appliquent au même espace de noms, les limites de ressources les plus restrictives sont respectées.
  • Si vous créez une limite inférieure à la quantité de ressources déjà utilisées, les ressources existantes ne sont pas supprimées, mais toute future consommation de ressources est interdite tant que l'utilisation ne dépasse pas la limite ou jusqu'à ce que la limite soit augmentée.

Dépannage

InternalError lors de la consommation de ressources

Lorsque vous consommez des ressources, par exemple, lorsque vous créez un configmap, votre requête peut cesser de répondre pendant 10 secondes et afficher le message d'erreur suivant :

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

Ce message d'erreur ne s'affiche pas, sauf si le pod gke-hc-controller-manager présente un état incorrect.

Pour résoudre le problème, les administrateurs autorisés peuvent supprimer le pod en utilisant directement le préfixe gke-hc-controller-manager- dans l'espace de noms hnc-system. Le pod redémarre automatiquement. Avant que le pod ne soit prêt, tenez compte des points suivants :

Si le problème n'est pas résolu, signalez-le-nous à des fins d'analyse, de préférence avec les journaux que vous pouvez obtenir en utilisant la commande suivante :

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

Étape suivante