Dela via


Metodtips för grundläggande scheduler-funktioner i Azure Kubernetes Service (AKS)

När du hanterar kluster i Azure Kubernetes Service (AKS) måste du ofta isolera team och arbetsbelastningar. Med Kubernetes-schemaläggaren kan du styra fördelningen av beräkningsresurser eller begränsa effekten av underhållshändelser.

Den här artikeln om metodtips fokuserar på grundläggande kubernetes-schemaläggningsfunktioner för klusteroperatorer. I den här artikeln kan du se hur du:

  • Använd resurskvoter för att tillhandahålla en fast mängd resurser till team eller arbetsbelastningar
  • Begränsa effekten av schemalagt underhåll med hjälp av poddstörningsbudgetar

Framtvinga resurskvoter

Vägledning för bästa praxis

Planera och tillämpa resurskvoter på namnområdesnivå. Om poddar inte definierar resursbegäranden och gränser avvisar du distributionen. Övervaka resursanvändningen och justera kvoterna efter behov.

Resursbegäranden och -gränser placeras i poddspecifikationen. Begäranden används av Kubernetes-schemaläggaren vid distributionstillfället för att hitta en tillgänglig nod i klustret. Begränsningar och begäranden fungerar på enskild poddnivå. Mer information om hur du definierar dessa värden finns i Definiera poddresursbegäranden och gränser.

Om du vill tillhandahålla ett sätt att reservera och begränsa resurser i ett utvecklingsteam eller projekt bör du använda resurskvoter. Dessa kvoter definieras på ett namnområde och kan användas för att ange kvoter på följande sätt:

  • Beräkningsresurser, till exempel CPU och minne, eller GPU:er.
  • Lagringsresurser, inklusive det totala antalet volymer eller mängden diskutrymme för en viss lagringsklass.
  • Objektantal, till exempel maximalt antal hemligheter, tjänster eller jobb kan skapas.

Kubernetes överallokerar inte resurser. När summan av din kumulativa resursbegäran har passerat den tilldelade kvoten misslyckas alla ytterligare distributioner.

När du definierar resurskvoter måste alla poddar som skapats i namnområdet ange gränser eller begäranden i poddspecifikationerna. Om de inte anger dessa värden kan du avvisa distributionen. I stället kan du konfigurera standardbegäranden och gränser för ett namnområde.

Följande YAML-exempelmanifest med namnet dev-app-team-quotas.yaml anger en hård gräns på totalt 10 processorer, 20Gi minne och 10 poddar:

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

Den här resurskvoten kan tillämpas genom att ange namnområdet, till exempel dev-apps:

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

Samarbeta med programutvecklare och ägare för att förstå deras behov och tillämpa lämpliga resurskvoter.

Mer information om tillgängliga resursobjekt, omfång och prioriteringar finns i Resurskvoter i Kubernetes.

Planera för tillgänglighet med hjälp av poddstörningsbudgetar

Vägledning för bästa praxis

För att upprätthålla tillgängligheten för program definierar du poddavbrottsbudgetar (PDB) för att se till att ett minsta antal poddar är tillgängliga i klustret.

Det finns två störande händelser som gör att poddar tas bort:

Ofrivilliga störningar

Ofrivilliga störningar är händelser som ligger utanför den typiska kontrollen för klusteroperatorn eller programägaren. Inbegripa:

  • Maskinvarufel på den fysiska datorn
  • ”Kernel panic”
  • Borttagning av en virtuell noddator

Ofrivilliga störningar kan minimeras genom att:

  • Använda flera repliker av dina poddar i en distribution.
  • Köra flera noder i AKS-klustret.

Frivilliga störningar

Frivilliga störningar är händelser som begärs av klusteroperatören eller programägaren. Inbegripa:

  • Klusteruppgraderingar
  • Distributionsmallen har uppdaterats
  • Ta bort en podd av misstag

Kubernetes tillhandahåller poddstörningsbudgetar för frivilliga störningar, så att du kan planera för hur distributioner eller replikuppsättningar svarar när en frivillig avbrottshändelse inträffar. Med hjälp av poddavbrottsbudgetar kan klusteroperatorer definiera ett minsta tillgängligt eller maximalt antal otillgängliga resurser.

Om du uppgraderar ett kluster eller uppdaterar en distributionsmall schemalägger Kubernetes-schemaläggaren extra poddar på andra noder innan frivilliga avbrottshändelser kan fortsätta. Schemaläggaren väntar med att starta om en nod tills det definierade antalet poddar har schemalagts på andra noder i klustret.

Nu ska vi titta på ett exempel på en replikuppsättning med fem poddar som kör NGINX. Poddarna i replikuppsättningen tilldelas etiketten app: nginx-frontend. Under en frivillig avbrottshändelse, till exempel en klusteruppgradering, vill du se till att minst tre poddar fortsätter att köras. Följande YAML-manifest för ett PodDisruptionBudget-objekt definierar dessa krav:

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

Du kan också definiera en procentandel, till exempel 60 %, som gör att du automatiskt kan kompensera för replikuppsättningen som skalar upp antalet poddar.

Du kan definiera ett maximalt antal otillgängliga instanser i en replikuppsättning. Återigen kan en procentandel för maximalt otillgängliga poddar också definieras. Följande YAML-manifest för poddstörningar definierar att högst två poddar i replikuppsättningen inte är tillgängliga:

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

När din poddavbrottsbudget har definierats skapar du den i ditt AKS-kluster som med andra Kubernetes-objekt:

kubectl apply -f nginx-pdb.yaml

Samarbeta med programutvecklare och ägare för att förstå deras behov och tillämpa lämpliga poddstörningar.

Mer information om hur du använder poddstörningsbudgetar finns i Ange en avbrottsbudget för ditt program.

Nästa steg

Den här artikeln fokuserar på grundläggande Funktioner för Kubernetes Scheduler. Mer information om klusteråtgärder i AKS finns i följande metodtips: