Metodtips för grundläggande schemafunktioner i Azure Kubernetes Service (AKS)

  • Artikel
  • 3 minuter för att läsa

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

Den här artikeln om bästa praxis fokuserar på grundläggande Funktioner för Kubernetes-schemaläggning för klusteroperatörer. 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 poddavbrottsbudgetar

Framtvinga resurskvoter

Vägledning och metodtips

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 kvoter efter behov.

Resursbegäranden och gränser placeras i poddspecifikationen. Gränser används av Kubernetes-schemaläggaren vid distributionen 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

För att 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 i ett namnområde och kan användas för att ange kvoter på följande basis:

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

Kubernetes överkompenserar inte resurser. När den ackumulerade resursbegärandesumman 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 sina poddspecifikationer. 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.

I följande YAML-exempelmanifest med namnet dev-app-team-quotas.yaml anges 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

Arbeta med dina 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 poddavbrottsbudgetar

Vägledning och metodtips

För att upprätthålla tillgängligheten för program definierar du pod disruption budgets (PDBs) 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:

Voluntary disruptions

Involuntary disruptions are events beyond the typical control of the cluster operator or application owner. Inkluderar:

  • Maskinvarufel på den fysiska datorn
  • Kernel panic
  • Borttagning av en nod-VM

Involuntary disruptions can be mitigated by:

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

Frivilliga avbrott

Frivilliga avbrott är händelser som begärs av klusteroperatören eller programägaren. Inkluderar:

  • Klusteruppgraderingar
  • Uppdaterad distributionsmall
  • Ta bort en podd av misstag

Kubernetes tillhandahåller budgetar för poddavbrott för frivilliga avbrott, så att du kan planera för hur distributioner eller replikuppsättningar svarar när en frivillig störning inträffar. Med hjälp av poddavbrottsbudgetar kan klusteroperatörer definiera ett minsta antal tillgängliga eller högsta 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 följande krav:

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

Du kan också definiera en procentandel, till exempel 60 %, vilket gör att du automatiskt kan kompensera för att replikuppsättningen 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 poddavbrottsbudget definierar att högst två poddar i replikuppsättningen inte är tillgängliga:

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

När din budget för poddavbrott har definierats skapar du den i ditt AKS-kluster precis som med andra Kubernetes-objekt:

kubectl apply -f nginx-pdb.yaml

Arbeta med dina programutvecklare och ägare för att förstå deras behov och tillämpa lämpliga budgetar för poddavbrott.

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

Nästa steg

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