Aanbevolen procedures voor eenvoudige scheduler-functies in Azure Kubernetes Service (AKS)

Wanneer u clusters beheert in Azure Kubernetes Service (AKS), moet u vaak teams en workloads isoleren. Met de Kubernetes-planner kunt u de distributie van rekenresources beheren en de impact van onderhoudsevenementen beperken.

Dit artikel met aanbevolen procedures is gericht op de basisfuncties van Kubernetes-planning voor clusteroperators. In dit artikel leert u het volgende:

Resourcequota afdwingen

Richtlijnen voor best practices

Resourcequota plannen en toepassen op naamruimteniveau. Gebruik quota's en limietbereiken om standaardresourceaanvragen en -limieten voor pods te vereisen of te bieden. Bewaak het resourcegebruik en pas zo nodig quota aan.

Stel resourceaanvragen en resourcelimieten in de podspecificatie in. Een resourceaanvraag is de hoeveelheid CPU of geheugen die de Kubernetes-planner gebruikt om een pod te plaatsen. Een resourcelimiet beperkt hoeveel van die resource een container kan gebruiken. Het systeem dwingt CPU-limieten af door beperking, terwijl geheugenlimieten reactief worden afgedwongen via OOM-beëindiging (out-of-memory). Zie Pod-resourceaanvragen en -limieten definiëren voor meer informatie.

Gebruik resourcequota om het geaggregeerde resourceverbruik voor een ontwikkelingsteam of project te beperken. Quota definiëren op het niveau van de naamruimte voor:

• Computatiebronnen, zoals CPU's, geheugen of GPU's.
• Opslagbronnen, inclusief het totale aantal volumes of de hoeveelheid schijfruimte voor een bepaalde opslagklasse.
• Het aantal objecten, zoals het maximum aantal geheimen, services of taken dat kan worden gemaakt.

De Kubernetes-scheduler maakt gebruik van resourceaanvragen om pods te plaatsen. Containers kunnen meer CPU of geheugen gebruiken dan is aangevraagd wanneer capaciteit beschikbaar is, en resourcelimieten kunnen aanvragen overschrijden. Een resourcequotum beperkt afzonderlijk het verbruik van de geaggregeerde naamruimte. Als het maken of bijwerken van een resource een vast quotum overschrijdt, weigert de API-server de aanvraag met een HTTP-antwoord 403 Forbidden . U kunt nog steeds een workloadobject zoals een implementatie maken, zelfs wanneer het quotum voorkomt dat de controller alle aangevraagde pods maakt.

Als een resourcequotum CPU of geheugen bijhoudt, moet elke nieuwe pod een aanvraag of limiet voor die resource opgeven. Anders kan de API-server de pod weigeren. U kunt standaardaanvragen en limieten voor een naamruimte configureren met behulp van een LimitRange.

In het volgende YAML-manifest met de naam dev-app-team-quotas.yaml wordt een vaste limiet ingesteld van in totaal 10 CPU's, 20Gi aan geheugen en 10 pods:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

Deze quotumlimieten aggregeren CPU-aanvragen bij 10 CPU's, aggregeren geheugenaanvragen bij 20Gi en het aantal niet-terminale pods bij 10 in de naamruimte.

Pas dit resourcequotum toe op een naamruimte, zoals dev-apps:

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

Werk samen met uw toepassingsontwikkelaars en -eigenaren om inzicht te hebben in hun behoeften en de juiste resourcequota toe te passen.

Zie Resource quotas in Kubernetes voor meer informatie over beschikbare resourceobjecten, scopes en prioriteiten.

Impact van onderbrekingen beperken met behulp van budgetten voor podonderbrekingen (PDBs)

Richtlijnen voor best practices

Definieer podonderbrekingsbudgetten (PDBs) voor gerepliceerde toepassingen om gelijktijdige vrijwillige verwijderingen te beperken tijdens gebeurtenissen zoals AKS-knooppuntafvoer. Behoud voldoende goede replica's en sta ten minste één onderbreking toe wanneer de workload toestaat, zodat clusteronderhoud kan worden voortgezet.

Verstorende gebeurtenissen die pods verwijderen, vallen in twee categorieën:

Onvrijwillige onderbrekingen

Onvrijwillige onderbrekingen zijn gebeurtenissen die buiten het typische beheer van de clusteroperator of toepassingseigenaar vallen. Enkele voorbeelden:

• Hardwarefout op de fysieke machine
• Kernelpanic
• Verwijderen van een knooppunt-VM

U kunt onvrijwillige onderbrekingen beperken door:

• Meerdere replica's van uw pods gebruiken in een implementatie.
• Meerdere knooppunten uitvoeren in het AKS-cluster.

Vrijwillige onderbrekingen

_ Vrijwillige disruptions_ zijn gebeurtenissen die de clusteroperator of toepassingseigenaar aanvraagt. Enkele voorbeelden:

• Een knooppunt leegmaken tijdens een clusterupgrade
• Een implementatiesjabloon bijwerken
• Een pod rechtstreeks verwijderen

Niet alle vrijwillige onderbrekingen worden beperkt door PDBs. Als u een pod of workloadobject rechtstreeks verwijdert, worden PDBs overgeslagen en worden workloadcontrollers zoals Implementaties en StatefulSets niet beperkt door PDBs tijdens rolling updates. Configureer de implementatiestrategie van de workload afzonderlijk om de beschikbaarheid tijdens toepassingsupdates te behouden. Zie Onderbrekingen in Kubernetes voor meer informatie.

PDBs beperken gelijktijdige vrijwillige verwijderingen voor geselecteerde pods via de Kubernetes Eviction-API. Tijdens een rolling AKS-upgrade voegt AKS piekcapaciteit toe op basis van de instellingen van de knooppuntgroep, cordons en wordt een knooppunt leeg gemaakt en wordt vervolgens de installatiekopie opnieuw gemaakt of vervangen. De verwijderings-API evalueert de PDB tijdens de afvoer. Na een verwijdering maakt de workloadcontroller een vervangende pod en plaatst de scheduler deze op een knooppunt met beschikbare capaciteit. Een beperkende PDB, onvoldoende goede replica's of onvoldoende clustercapaciteit kan de afvoer vertragen of blokkeren.

Een minimum aantal beschikbare pods instellen

Overweeg een ReplicaSet met vijf NGINX-pods met app: nginx-frontendhet label . Tijdens een vrijwillige onderbreking, zoals een clusterupgrade, moeten ten minste drie pods beschikbaar blijven. In het volgende manifest wordt PodDisruptionBudget deze vereiste gedefinieerd:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Voor dit budget moeten ten minste drie pods met het label app: nginx-frontend gezond blijven tijdens een vrijwillige verwijdering.

U kunt een percentage opgeven, zoals 60%, zodat het budget wordt aangepast wanneer de ReplicaSet wordt geschaald.

Een maximum aantal niet-beschikbare pods instellen

Een PDB kan een of minAvailablemaxUnavailable, maar niet beide definiëren. Als u vrijwillige verwijderingen wilt beperken op basis van niet-beschikbare pods, geeft u maxUnavailable op als geheel getal of percentage. Het volgende manifest staat een vrijwillige verwijdering alleen toe wanneer niet meer dan twee pods in de ReplicaSet niet meer beschikbaar zijn na de verwijdering:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  maxUnavailable: 2
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Deze begroting staat een vrijwillige verwijdering alleen toe wanneer niet meer dan twee pods met het label app: nginx-frontend niet meer beschikbaar zouden zijn na de verwijdering. Onvrijwillige onderbrekingen kunnen er nog steeds toe leiden dat de beschikbaarheid onder deze drempelwaarde valt.

Met het AlwaysAllow verwijderingsbeleid voor beschadigde pods kan een verwijdering van actieve pods die niet in orde zijn, leegmaken. Zonder deze instelling kan het standaardbeleid IfHealthyBudget een afvoer blokkeren terwijl wordt gewacht tot beschadigde pods in orde zijn. Gebruik AlwaysAllow wanneer de afvoerbaarheid belangrijker is dan het geven van een beschadigde pod meer tijd om te herstellen.

Sla het PDB-manifest op dat u wilt gebruiken als nginx-pdb.yaml en pas het vervolgens toe op uw AKS-cluster:

kubectl apply -f nginx-pdb.yaml

Controleer vóór het onderhoud van het cluster of elke PDB de verwachte verwijdering toestaat:

kubectl get poddisruptionbudgets --namespace <namespace>

Een ALLOWED DISRUPTIONS waarde van 0 kan een AKS-knooppuntafvoer blokkeren. Werk samen met uw toepassingsontwikkelaars en -eigenaren om voldoende goede replica's te onderhouden en een budget te kiezen dat de beschikbaarheid van toepassingen in balans brengt met de onderhoudsvereisten.

Zie Een onderbrekingsbudget voor uw toepassing opgeven voor meer informatie over het gebruik van budgetten voor podonderbrekingen.

Verwante onderwerpen

Dit artikel is gericht op de basisfuncties van Kubernetes Scheduler. Zie de volgende artikelen over aanbevolen procedures voor meer informatie over clusterbewerkingen in AKS:

• Multi-tenancy en cluster-isolatie
• Geavanceerde Functies van Kubernetes Scheduler
• Verificatie en autorisatie