Hierarchische Ressourcenkontingente nutzen

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Ressourcenkontingente von Kubernetes sind ein Tool, mit dem Administratoren dafür sorgen können, dass Ressourcen gerecht auf verschiedene Nutzer aufgeteilt werden. Ein Ressourcenkontingent, das durch ein ResourceQuota-Objekt definiert wird, bietet Einschränkungen, die den aggregierten Ressourcenverbrauch in einem einzelnen Namespace beschränken.

Hierarchy Controller erweitert das Konzept der Ressourcenkontingente pro Namespace, um hierarchische Namespaces zu unterstützen. Ein HierarchicalResourceQuota-Objekt begrenzt die aggregierte Ressourcennutzung über alle Namespaces in einer Unterstruktur, sodass Administratoren den Ressourcenverbrauch auf mehreren zugehörigen Namespaces beschränken können.

Hinweis: Kontingente für hierarchische Ressourcen unterstützen nur hierarchische Namespaces, jedoch keine abstrakten Namespaces.

Wenn hierarchische Ressourcenkontingente aktiviert sind, installiert Hierarchy Controller zwei validierende Zulassungs-Webhooks. Mit dem einen werden die Limits für den Ressourcenverbrauch erzwungen und mit dem anderen die hierarchischen Ressourcenkontingente validiert.

Hierarchische Ressourcenkontingente aktivieren

Die hierarchischen Ressourcenkontingente werden von Hierarchy Controller bereitgestellt. So aktivieren Sie hierarchische Ressourcenkontingente:

1. Installieren Sie Hierarchy Controller mit Config Sync 1.6.2 oder höher.

2. Legen Sie in der Konfigurationsdatei für den ConfigManagement Operator im Objekt spec.hierarchyController für den Wert enableHierarchicalResourceQuota true fest:

   # 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. Wenden Sie die Konfiguration an:

   kubectl apply -f config-management.yaml
   

   Nach etwa einer Minute können Hierarchy Controller und die Kontingente für hierarchische Ressourcen in Ihrem Cluster verwendet werden.

So überprüfen Sie, ob hierarchische Ressourcenkontingente aktiviert sind:

1. Erstellen Sie in einem beliebigen Namespace ein HierarchicalResourceQuota-Objekt. Beispiel:

   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. Prüfen Sie, ob im Namespace ein neues ResourceQuota-Objekt namens gke-hc-hrq mit demselben spec.hard von 1 configmap erstellt wurde. Beispiel:

   kubectl describe resourcequota gke-hc-hrq -n default
   

   Ausgabe:

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

3. Bereinigen:

   kubectl delete hrq -n default example-hrq
   

   Prüfen Sie, ob das automatisch erstellte Objekt entfernt wurde:

   kubectl get resourcequota gke-hc-hrq -n default
   

   Ausgabe:

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

Hierarchische Ressourcenkontingente verwenden

Kontingente festlegen

Die Festlegung von HierarchicalResourceQuota ist mit der Festlegung eines regulären ResourceQuota identisch, wobei apiVersion und kind voneinander abweichen. Daher können Sie Ressourcen im Feld spec.hard wie in ResourceQuota beschränken.

Nehmen wir als Beispiel ein Team namens team-a, das einen Dienst namens service-a und ein untergeordnetes Team namens team-b hat. Alle werden folgendermaßen durch hierarchische Namespaces dargestellt:

kubectl hns tree team-a

Ausgabe:

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

Wenn Sie die Anzahl der configmaps in team-a begrenzen möchten, die Zahl in den Nachfolgerelementen jedoch nicht, können Sie folgendermaßen ein reguläres ResourceQuota erstellen:

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

Wenn Sie im Gegensatz dazu die Gesamtzahl der configmaps in team-a und die Nachfolgerelemente begrenzen möchten, ersetzen Sie im vorherigen Beispiel apiVersion und kind:

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

Der erste Versuch, einen configmap in einem dieser drei Namespaces zu erstellen, war erfolgreich. Vielleicht möchten Sie configmap in einem der untergeordneten Namespaces erstellen:

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

Ausgabe:

confimap/config-1 created

Alle weiteren Versuche zum Erstellen neuer ConfigMaps in einem der drei Namespaces schlagen jedoch fehl, auch in den gleichgeordneten oder übergeordneten Namespaces:

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

Ausgabe für beide:

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

Kontingente prüfen

Die aktuell gültigen Limits und Nutzung von HierarchicalResourceQuota können Sie mit dem Befehl kubectl describe zur Anzeige eines regulären Ressourcenkontingents abrufen:

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

Ausgabe:

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

Namespace-Hierarchie aktualisieren

Ein Namespace unterliegt immer einem HierarchicalResourceQuota in seinen Ancestors. Durch das Ändern der Namespace-Hierarchie wird eine Neuberechnung der Kontingentnutzung ausgelöst.

Namespace aus einer Unterstruktur mit hierarchischen Kontingenten entfernen

Wenn ein Namespace aus einer Teilstruktur mit hierarchischen Kontingenten in seinen Ancestors verschoben wird, unterliegt er nicht mehr diesen Kontingenten und die zugehörigen Ressourcen werden aus der Kontingentnutzung entfernt.

Wenn beispielsweise team-b aus der vorherigen Unterstruktur entfernt wird, gibt es keine Begrenzung für die Nutzung von configmap in team-b. Die Nutzung des hierarchischen Kontingents wird auf 0 zurückgesetzt, d. h. team-a und service-a können jetzt insgesamt eine weitere configmap verbrauchen.

Namespace zu einer Unterstruktur mit hierarchischen Kontingenten hinzufügen

Wenn ein Namespace einer Unterstruktur mit hierarchischen Kontingenten hinzugefügt wird, unterliegt er den hierarchischen Kontingenten. Die Ressourcennutzung wird der Kontingentnutzung hinzugefügt.

Wenn zum Beispiel der vorherigen Unterstruktur ein anderer Namespace hinzugefügt wird, ist keine neue configmap-Nutzung im neu hinzugefügten Namespace zulässig. Ebenso wird jede vorhandene configmap-Nutzung im neu hinzugefügten Namespace zur Nutzung des hierarchischen Kontingents hinzugefügt.

Hierarchische Kontingente verhindern nicht das Verschieben eines neuen Namespace in eine Unterstruktur, auch wenn die Nutzung des neuen Namespace das Limit in hierarchischen Kontingenten überschreitet. Wird ein Limit jedoch überschritten, wird die weitere Ressourcennutzung gesperrt, bis die Nutzung wieder unter das Limit fällt oder das Limit erhöht wird. Dies entspricht dem Verhalten des ResourceQuota von Kubernetes, wenn ein Limit festgelegt wird, das unter der vorhandenen Nutzung im Namespace liegt.

Allgemeine Regeln

Kontingente für hierarchische Ressourcen verhalten sich ähnlich wie die Ressourcenkontingente von Kubernetes. Beispiel:

• Wenn für denselben Namespace mehrere hierarchische Ressourcenkontingente gelten, werden die strengsten Ressourcenlimits berücksichtigt.
• Wenn Sie ein Limit erstellen, das unter der Menge der bereits verbrauchten Ressourcen liegt, werden vorhandene Ressourcen nicht gelöscht. Eine Ressourcennutzung ist jedoch erst dann wieder zulässig, wenn die Nutzung unter das Limit fällt oder das Limit erhöht wird.

Fehlerbehebung

InternalError, beim Verbrauch von Ressourcen

Wenn Sie Ressourcen verbrauchen, z. B. wenn Sie eine configmap erstellen, reagiert Ihre Anfrage möglicherweise 10 Sekunden lang nicht und Sie erhalten die folgende Fehlermeldung:

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

Diese Fehlermeldung wird nur angezeigt, wenn sich der Pod gke-hc-controller-manager in einem fehlerhaften Zustand befindet.

Zur Lösung des Problems können berechtigte Administratoren den Pod löschen, indem sie das Präfix gke-hc-controller-manager- im Namespace hnc-system direkt verwenden. Der Pod wird automatisch neu gestartet. Achten Sie auf Folgendes, bevor der Pod bereit ist:

• Der Ressourcenverbrauch unterliegt keinen hierarchischen Kontingenten.
• Die Erstellung/Aktualisierung von HierarchicalResourceQuota schlägt fehl.
• Wenn die hierarchische Beobachtbarkeit aktiviert ist, werden Pods ohne Label erstellt.

Wenn das Problem dadurch nicht behoben wird, geben Sie uns Bescheid, damit wir es analysieren können. Senden Sie am besten Logs mit, die Sie so abrufen können:

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

Nächste Schritte

• Hierarchische Arbeitslasten beobachten
• Weitere Informationen zu gängigen Aufgaben, für deren Durchführung Sie HNC verwenden können, finden Sie im HNC-Nutzerhandbuch: Anleitungen.