Bästa praxis för avancerade schemaläggningsfunktioner i Azure Kubernetes Service (AKS)

Artikel
11/01/2024

När du hanterar kluster i Azure Kubernetes Service (AKS) måste du ofta isolera team och arbetsbelastningar. Med avancerade funktioner som tillhandahålls av Kubernetes-schemaläggaren kan du styra:

Vilka poddar kan schemaläggas på vissa noder.
Hur program med flera poddar kan distribueras korrekt i klustret.

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

Använd taints och toleranser för att begränsa vilka poddar som kan schemaläggas på noder.
Ge poddar företräde att köra på vissa noder med nodväljare eller nodtillhörighet.
Dela upp eller gruppera poddar med tillhörighet mellan poddar eller antitillhörighet.
Begränsa schemaläggning av arbetsbelastningar som endast kräver GPU:er på noder med schemabara GPU:er.

Tillhandahålla dedikerade noder med hjälp av taints och tolerations

Vägledning för bästa praxis:

Begränsa åtkomsten för resursintensiva program, till exempel ingresskontrollanter, till specifika noder. Behåll nodresurser tillgängliga för arbetsbelastningar som kräver dem och tillåt inte schemaläggning av andra arbetsbelastningar på noderna.

När du skapar ditt AKS-kluster kan du distribuera noder med GPU-stöd eller ett stort antal kraftfulla processorer. Mer information finns i Använda GPU:er på AKS. Du kan använda dessa noder för stora databearbetningsarbetsbelastningar som maskininlärning (ML) eller artificiell intelligens (AI).

Eftersom den här nodresursmaskinvaran vanligtvis är dyr att distribuera begränsar du de arbetsbelastningar som kan schemaläggas på dessa noder. Ägna i stället vissa noder i klustret åt att köra inkommande tjänster och förhindra andra arbetsbelastningar.

Det här stödet för olika noder tillhandahålls med hjälp av flera nodpooler. Ett AKS-kluster stöder en eller flera nodpooler.

Kubernetes-schemaläggaren använder taints och toleranser för att begränsa vilka arbetsbelastningar som kan köras på noder.

Använd en taint på en nod för att ange att endast specifika poddar kan schemaläggas på dem.
Tillämpa sedan en tolerans på en podd så att de kan tolerera en nods taint.

När du distribuerar en podd till ett AKS-kluster schemalägger Kubernetes endast poddar på noder vars taint överensstämmer med toleransen. Taints och toleranser fungerar tillsammans för att säkerställa att poddar inte schemaläggs till olämpliga noder. En eller flera taints tillämpas på en nod, vilket markerar noden så att den inte accepterar några poddar som inte tolererar tainterna.

Anta till exempel att du har lagt till en nodpool i AKS-klustret för noder med GPU-stöd. Du definierar namn, till exempel gpu, och sedan ett värde för schemaläggning. Om det här värdet anges till NoSchedule begränsas Kubernetes-schemaläggaren från att schemalägga poddar med odefinierad tolerans på noden.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-taints sku=gpu:NoSchedule \
    --no-wait

Med en taint som tillämpas på noder i nodpoolen definierar du en tolerans i poddspecifikationen som tillåter schemaläggning på noderna. I följande exempel definieras sku: gpu och effect: NoSchedule för att tolerera den taint som tillämpades på nodpoolen i föregående steg:

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  tolerations:
  - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

När podden distribueras med kan kubectl apply -f gpu-toleration.yamlKubernetes schemalägga podden på noderna med den använda tainten. Med den här logiska isoleringen kan du styra åtkomsten till resurser i ett kluster.

När du använder taints kan du samarbeta med programutvecklare och ägare så att de kan definiera nödvändiga toleranser i sina distributioner.

Mer information om hur du använder flera nodpooler i AKS finns i Skapa flera nodpooler för ett kluster i AKS.

Beteende för taints och toleranser i AKS

När du uppgraderar en nodpool i AKS följer taints och toleranser ett angivet mönster när de tillämpas på nya noder:

Standardkluster som använder Skalningsuppsättningar för virtuella Azure-datorer

Du kan taint en nodpool från AKS-API:et så att nyligen utskalade noder får API-angivna nodtaints.

Vi antar att:

Du börjar med ett kluster med två noder: node1 och node2.
Du uppgraderar nodpoolen.
Två andra noder skapas: node3 och node4.
Tainterna skickas på respektive.
Den ursprungliga node1 och node2 tas bort.

Kluster utan stöd för vm-skalningsuppsättningar

Låt oss återigen anta:

Du har ett kluster med två noder: node1 och node2.
Du uppgraderar nodpoolen.
En extra nod skapas: node3.
Tainterna från node1 tillämpas på node3.
node1 tas bort.
En ny nod1 skapas för att ersätta till den ursprungliga noden1.
Nod2-tainterna tillämpas på den nya noden1.
node2 tas bort.

I huvudsak blir node1 node3 och node2 blir den nya noden1.

När du skalar en nodpool i AKS överförs inte taint och toleranser avsiktligt.

Kontrollera schemaläggning av poddar med nodeSelector och affinity

Vägledning för bästa praxis

Kontrollera schemaläggningen av poddar på noder med hjälp av nodväljare, nodtillhörighet eller tillhörighet mellan poddar. Med de här inställningarna kan Kubernetes-schemaläggaren logiskt isolera arbetsbelastningar, till exempel efter maskinvara i noden.

Taints och toleranser isolerar logiskt resurser med en hård brytpunkt. Om podden inte tolererar en nods taint schemaläggs den inte på noden.

Du kan också använda nodväljare. Du kan till exempel märka noder för att ange lokalt ansluten SSD-lagring eller en stor mängd minne och sedan definiera en nodväljare i poddspecifikationen. Kubernetes schemalägger poddarna på en matchande nod.

Till skillnad från toleranser kan poddar utan matchande nodväljare fortfarande schemaläggas på etiketterade noder. Det här beteendet gör att oanvända resurser på noderna kan användas, men prioriterar poddar som definierar den matchande nodväljaren.

Nu ska vi titta på ett exempel på noder med hög mängd minne. Dessa noder prioriterar poddar som begär en hög mängd minne. För att säkerställa att resurserna inte är inaktiva tillåter de även att andra poddar körs. Följande exempelkommando lägger till en nodpool med etiketten hardware=highmem till myAKSCluster i myResourceGroup. Alla noder i nodpoolen har den här etiketten.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name labelnp \
    --node-count 1 \
    --labels hardware=highmem \
    --no-wait

En poddspecifikation lägger nodeSelector sedan till egenskapen för att definiera en nodväljare som matchar etiketten som angetts på en nod:

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  nodeSelector:
      hardware: highmem

När du använder dessa alternativ för schemaläggaren kan du samarbeta med programutvecklare och ägare så att de kan definiera sina poddspecifikationer korrekt.

Mer information om hur du använder nodväljare finns i Tilldela poddar till noder.

Nodtillhörighet

En nodväljare är en grundläggande lösning för att tilldela poddar till en viss nod. Nodtillhörighet ger större flexibilitet så att du kan definiera vad som händer om podden inte kan matchas med en nod. Du kan:

Kräv att Kubernetes-schemaläggaren matchar en podd med en märkt värd. Eller:
Föredrar en matchning men tillåter att podden schemaläggs på en annan värd om ingen matchning är tillgänglig.

I följande exempel anges nodtillhörigheten till requiredDuringSchedulingIgnoredDuringExecution. Den här tillhörigheten kräver Kubernetes-schemat för att använda en nod med en matchande etikett. Om ingen nod är tillgänglig måste podden vänta tills schemaläggningen fortsätter. Om du vill tillåta att podden schemaläggs på en annan nod kan du i stället ange värdet till önskadDuringSchedulingIgnoreDuringExecution:

kind: Pod
apiVersion: v1
metadata:
  name: app
spec:
  containers:
  - name: app
    image: <your-workload>:gpu
    resources:
      requests:
        cpu: 0.5
        memory: 2Gi
      limits:
        cpu: 4.0
        memory: 16Gi
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: hardware
            operator: In
            values:
            - highmem

Delen IgnoredDuringExecution i inställningen anger att podden inte ska tas bort från noden om nodetiketterna ändras. Kubernetes-schemaläggaren använder endast de uppdaterade nodetiketterna för nya poddar som schemaläggs, inte poddar som redan schemalagts på noderna.

Mer information finns i Tillhörighet och antitillhörighet.

Tillhörighet mellan poddar och antitillhörighet

En sista metod för Kubernetes-schemaläggaren att logiskt isolera arbetsbelastningar är att använda tillhörighet mellan poddar eller antitillhörighet. De här inställningarna definierar att poddar antingen inte ska eller ska schemaläggas på en nod som har en befintlig matchande podd. Som standard försöker Kubernetes-schemaläggaren schemalägga flera poddar i en replikuppsättning mellan noder. Du kan definiera mer specifika regler kring det här beteendet.

Du har till exempel ett webbprogram som också använder en Azure Cache for Redis.

Du använder regler för poddskyddstillhörighet för att begära att Kubernetes-schemaläggaren distribuerar repliker mellan noder.
Du använder tillhörighetsregler för att se till att varje webbappkomponent schemaläggs på samma värd som en motsvarande cache.

Fördelningen av poddar mellan noder ser ut som i följande exempel:

Nod 1	Nod 2	Nod 3
webapp-1	webapp-2	webapp-3
cache-1	cache-2	cache-3

Tillhörighet mellan poddar och antitillhörighet ger en mer komplex distribution än nodväljare eller nodtillhörighet. Med distributionen isolerar du resurser logiskt och styr hur Kubernetes schemalägger poddar på noder.

Ett fullständigt exempel på det här webbprogrammet med Azure Cache for Redis-exempel finns i Samplaceras poddar på samma nod.

Nästa steg

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

Dela via