Le quote delle risorse Kubernetes sono uno strumento utilizzato dagli amministratori per garantire un'equa quota di risorse tra utenti diversi. Una quota di risorse, definita da un oggetto ResourceQuota
, fornisce
limiti che limitano il consumo aggregato di risorse in un singolo spazio dei nomi.
Hierarchy Controller
estende il concetto di quote delle risorse per spazio dei nomi per supportare gli spazi dei nomi gerarchici. Un oggetto HierarchicalResourceQuota
limita il consumo aggregato di risorse in tutti gli spazi dei nomi di un sottoalbero, consentendo agli amministratori di limitare il consumo di risorse in più spazi dei nomi correlati.
Quando le quote gerarchiche delle risorse sono abilitate, Hierarchy Controller installa due callout di ammissione gerarchiche , uno per applicare effettivamente i limiti di consumo delle risorse e l'altro per convalidare le quote delle risorse gerarchiche.
Abilita le quote delle risorse gerarchiche
Le quote delle risorse gerarchiche sono fornite da Hierarchy Controller. Per abilitare le quote delle risorse gerarchiche, segui questi passaggi:
Installa Hierarchy Controller utilizzando Config Sync 1.6.2 o versioni successive.
Nel file di configurazione per l'operatore ConfigManagement, nell'oggetto
spec.hierarchyController
, imposta il valore dienableHierarchicalResourceQuota
sutrue
:# 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...
Applica la configurazione:
kubectl apply -f config-management.yaml
Dopo circa un minuto, le quote di Hierarchy Controller e delle risorse gerarchiche diventano utilizzabili nel cluster.
Per verificare che le quote delle risorse gerarchiche siano abilitate, segui questi passaggi:
Crea un oggetto
HierarchicalResourceQuota
in uno spazio dei nomi, ad esempio: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
Verifica che nello spazio dei nomi venga creato un nuovo oggetto
ResourceQuota
denominatogke-hc-hrq
con lo stessospec.hard
di 1configmap
, ad esempio:kubectl describe resourcequota gke-hc-hrq -n default
Output:
Name: gke-hc-hrq Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 1
Libera spazio:
kubectl delete hrq -n default example-hrq
Assicurati che l'oggetto creato automaticamente venga rimosso:
kubectl get resourcequota gke-hc-hrq -n default
Output:
Error from server (NotFound): resourcequotas "gke-hc-hrq" not found
Utilizzo di quote per risorse gerarchiche
Impostazione delle quote
Impostare un HierarchicalResourceQuota
è come impostare un ResourceQuota
normale, ma con apiVersion
e kind
diversi; di conseguenza, puoi
impostare limiti per le risorse nel campo spec.hard
come faresti in
ResourceQuota
.
Prendiamo in considerazione un team chiamato team-a
che possiede un servizio denominato service-a
e dispone di un
sottoteam chiamato team-b
, ognuno dei quali è rappresentato da spazi dei nomi gerarchici, come riportato di seguito:
kubectl hns tree team-a
Output:
team-a
├── service-a
└── team-b
Se vuoi limitare il numero di configmaps
in team-a
, ma senza
limitare il numero nei discendenti, puoi creare un ResourceQuota
normale come segue:
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
Al contrario, per limitare il numero totale di configmaps
in team-a
e
i relativi discendenti combinati, sostituisci apiVersion
e kind
nell'esempio
precedente:
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
Il primo tentativo di creare un configmap
in uno di questi tre spazi dei nomi ha avuto esito positivo. Ad esempio, potremmo scegliere di creare configmap
in uno degli
spazi dei nomi figlio:
kubectl create configmap config-1 --from-literal key=value -n team-b
Output:
confimap/config-1 created
Tuttavia, qualsiasi ulteriore tentativo di creare nuove configmap in uno dei tre spazi dei nomi non riesce, inclusi quelli di pari livello o padre:
kubectl create configmap config-2 --from-literal key=value -n service-a
kubectl create configmap config-2 --from-literal key=value -n team-a
Output per entrambi:
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
Ispeziona le quote
Per visualizzare i limiti e l'utilizzo attuali di HierarchicalResourceQuota
, usa il comando kubectl describe
per visualizzare una quota normale delle risorse:
kubectl describe hrq team-a-hrq -n team-a
Output:
# ...other fields...
Spec:
Hard:
Configmaps: 1
Status:
Hard:
Configmaps: 1
Used:
Configmaps: 1
Aggiorna gerarchia dello spazio dei nomi
Uno spazio dei nomi è sempre soggetto a qualsiasi HierarchicalResourceQuota
nei suoi predecessori. La modifica della gerarchia dello spazio dei nomi attiva un ricalcolo degli utilizzi di qualsiasi quota.
Rimuovi uno spazio dei nomi da un sottoalbero con quote gerarchiche
Quando uno spazio dei nomi viene eliminato da un sottoalbero con quote gerarchiche nei predecessori, non è più soggetto a queste quote e le relative risorse vengono rimosse dagli utilizzi delle quote.
Ad esempio, se team-b
viene rimosso dal sottoalbero precedente, non ci saranno
limiti al consumo di configmap
in team-b
. L'utilizzo della quota gerarchica viene reimpostato su 0
, il che significa che team-a
e service-a
possono ora consumare un altro configmap
in totale.
Aggiungi uno spazio dei nomi a un sottoalbero con quote gerarchiche
Quando uno spazio dei nomi viene aggiunto a un sottoalbero con quote gerarchiche, è soggetto alle quote gerarchiche e l'utilizzo delle risorse viene aggiunto a quelli delle quote.
Ad esempio, se viene aggiunto un altro spazio dei nomi al sottoalbero precedente, non è consentito un ulteriore consumo di configmap
nello spazio dei nomi appena aggiunto. Allo stesso modo, qualsiasi utilizzo di configmap
esistente nello spazio dei nomi appena aggiunto viene aggiunto all'utilizzo della quota gerarchica.
Le quote gerarchiche non ti impediscono di spostare un nuovo spazio dei nomi in un sottoalbero, anche se l'utilizzo del nuovo spazio dei nomi supera il limite delle quote gerarchiche. Tuttavia, se viene superato un limite, l'utilizzo ulteriore delle risorse viene vietato finché l'utilizzo non scende al di sotto del limite o finché il limite non viene aumentato. Questo comportamento è simile a quello di Kubernetes ResourceQuota
quando
viene imposto un limite inferiore all'utilizzo esistente nello spazio dei nomi.
Regole generali
Le quote delle risorse gerarchiche si comportano in modo simile alle quote delle risorse Kubernetes nei casi d'angolo. Ad esempio:
- Se allo stesso spazio dei nomi si applicano più quote delle risorse gerarchiche, vengono rispettati i limiti più restrittivi delle risorse.
- Se crei un limite inferiore alla quantità di risorse già utilizzate, le risorse esistenti non vengono eliminate, ma è vietato qualsiasi consumo futuro di risorse finché l'utilizzo non scende sotto il limite o non viene aumentato il limite.
Risoluzione dei problemi
InternalError
quando utilizzi risorse
Quando utilizzi risorse, ad esempio durante la creazione di un configmap
, la tua richiesta potrebbe non rispondere più per 10 secondi e ricevere il seguente messaggio di errore:
Error from server (InternalError): Internal error occurred: resource quota evaluates timeout
Non dovrebbe essere visualizzato questo messaggio di errore a meno che il pod gke-hc-controller-manager
non si trovi in uno stato non valido.
Per risolvere il problema, gli amministratori con l'autorizzazione possono eliminare il pod utilizzando
direttamente il prefisso gke-hc-controller-manager-
nello spazio dei nomi hnc-system
.
Il pod si riavvia automaticamente. Prima che il pod sia pronto, tieni presente quanto segue:
- Nessun consumo di risorse è soggetto a quote gerarchiche.
- Creazione/aggiornamento di
HierarchicalResourceQuota
non riuscito. - Se l'osservabilità gerarchica è abilitata, i pod vengono creati senza applicare etichette.
Se il problema persiste, segnalacelo per l'analisi, preferibilmente con i log che puoi ottenere utilizzando quanto segue:
kubectl logs -n hnc-system deployment/gke-hc-controller-manager -c manager
Passaggi successivi
- Osserva i carichi di lavoro gerarchici.
- Scopri di più sulle attività comuni che potresti utilizzare HNC nella Guida dell'utente di HNC: istruzioni.