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

Artikel
08/05/2023

När du hanterar kluster i Azure Kubernetes Service (AKS) behöver 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 metodtipsartikeln fokuserar på avancerade Kubernetes-schemaläggningsfunktioner för klusteroperatörer. 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öras på vissa noder med nodväljare eller nodtillhörighet.
Dela upp eller gruppera poddar med tillhörighet mellan poddar eller anti-tillhörighet.
Begränsa schemaläggning av arbetsbelastningar som endast kräver GPU:er på noder med schemaläggningsbara 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. Dedikera i stället vissa noder i klustret för att köra ingresstjä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 för 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 på olämpliga noder. En eller flera taints tillämpas på en nod, vilket markerar noden så att den inte accepterar poddar som inte tolererar taints.

Anta till exempel att du har lagt till en nodpool i ditt AKS-kluster 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 tillämpad 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: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo: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 den här podden distribueras med kan kubectl apply -f gpu-toleration.yamlKubernetes schemalägga podden på noderna med taint tillämpad. Med den här logiska isoleringen kan du styra åtkomsten till resurser i ett kluster.

När du tillämpar taints kan du samarbeta med dina programutvecklare och ägare så att de kan definiera de toleranser som krävs i deras 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 Azure Virtual Machine Scale Sets

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

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 vidare.
Den ursprungliga node1 och node2 tas bort.

Kluster utan stöd för Virtual Machine Scale Sets

Låt oss anta att:

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.
Node2-tainterna tillämpas på den nya noden1.
node2 tas bort.

I princip blir node1node3 och node2 blir den nya noden1.

När du skalar en nodpool i AKS överförs inte taints 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 gräns. 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 förbruka, men prioriterar poddar som definierar den matchande nodväljaren.

Nu ska vi titta på ett exempel på noder med mycket minne. Dessa noder prioriterar poddar som begär en stor 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: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo: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 mer 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öredra en matchning men tillåt 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: tf-mnist
spec:
  containers:
  - name: tf-mnist
    image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo: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 bara 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 anti-tillhö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 för 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 anti-tillhörighet ger en mer komplex distribution än nodväljare eller nodtillhörighet. Med distributionen isolerar du logiskt resurser 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 i Kubernetes Scheduler. Mer information om klusteråtgärder i AKS finns i följande metodtips: