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 of 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. Als pods geen resourceaanvragen en -limieten definiëren, negeert u de implementatie. Bewaak het resourcegebruik en pas zo nodig quota aan.

Resourceaanvragen en -limieten worden in de podspecificatie geplaatst. Aanvragen worden tijdens de implementatie door de Kubernetes-planner gebruikt om een beschikbaar knooppunt in het cluster te vinden. Limieten en verzoeken werken op het niveau van de individuele pod. Zie Pod-resourceaanvragen en -limieten definiëren voor meer informatie over het definiëren van deze waarden.

Als u resources wilt reserveren en beperken voor een ontwikkelingsteam of project, moet u resourcequota gebruiken. Deze quota worden gedefinieerd in een naamruimte en kunnen worden gebruikt om quota op de volgende basis in te stellen:

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

Kubernetes overschrijft geen resources. Zodra het totale aantal cumulatieve resourceaanvragen het toegewezen quotum overschrijdt, zullen alle verdere implementaties onsuccesvol zijn.

Wanneer u resourcequota definieert, moeten alle pods die in de naamruimte zijn gemaakt, limieten of aanvragen opgeven in hun podspecificaties. Als ze deze waarden niet opgeven, kunt u de implementatie weigeren. In plaats daarvan kunt u standaardaanvragen en limieten voor een naamruimte configureren.

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"

Dit resourcequotum kan worden toegepast door de naamruimte op te geven, 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.

Beschikbaarheid plannen met budgetten voor podonderbreking

Richtlijnen voor best practices

Als u de beschikbaarheid van toepassingen wilt behouden, definieert u POD-onderbrekingsbudgetten (PDBs) om ervoor te zorgen dat er een minimum aantal pods beschikbaar is in het cluster.

Er zijn twee verstorende gebeurtenissen waardoor pods worden verwijderd:

Onvrijwillige onderbrekingen

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

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

Onvrijwillige onderbrekingen kunnen worden beperkt door:

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

Vrijwillige onderbrekingen

Vrijwillige onderbrekingen zijn gebeurtenissen die worden aangevraagd door de clusteroperator of toepassingseigenaar . Bevatten:

• Clusterupgrades
• Bijgewerkte implementatiesjabloon
• Per ongeluk een pod verwijderen

Kubernetes biedt pod disruption budgets voor vrijwillige onderbrekingen, zodat u kunt plannen hoe implementaties of replicasets reageren op zo'n gebeurtenis. Met behulp van budgetten voor podonderbrekingen kunnen clusteroperators een minimaal of maximaal niet-beschikbaar aantal resources definiëren.

Als u een cluster bijwerkt of een implementatiesjabloon bijwerkt, plant de Kubernetes-planner extra pods op andere knooppunten voordat vrijwillige onderbrekingsevenementen kunnen worden voortgezet. De planner wacht met het opnieuw opstarten van een knooppunt totdat het gedefinieerde aantal pods met succes op andere knooppunten in het cluster is gepland.

Laten we eens kijken naar een voorbeeld van een replicaset met vijf pods waarop NGINX wordt uitgevoerd. Aan de pods in de replicaset wordt het label app: nginx-frontendtoegewezen. Tijdens een vrijwillige verstoring, zoals een clusterupgrade, wilt u ervoor zorgen dat ten minste drie pods in werking blijven. Het volgende YAML-manifest voor een PodDisruptionBudget-object definieert deze vereisten:

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

U kunt ook een percentage definiëren, zoals 60%, waarmee u automatisch kunt compenseren voor het schalen van het aantal pods voor de replicaset.

U kunt een maximum aantal niet-beschikbare exemplaren in een replicaset definiëren. Nogmaals, een percentage voor de maximaal niet-beschikbare pods kan ook worden gedefinieerd. In het volgende YAML-manifest voor podonderbreking wordt gedefinieerd dat niet meer dan twee pods in de replicaset niet beschikbaar zijn:

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

Zodra uw budget voor podonderbreking is gedefinieerd, maakt u het in uw AKS-cluster, net als bij elk ander Kubernetes-object:

kubectl apply -f nginx-pdb.yaml

Werk samen met uw toepassingsontwikkelaars en -eigenaren om inzicht te krijgen in hun behoeften en pas de juiste budgetten voor podonderbreking toe.

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

Volgende stappen

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

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