Procedure consigliate per le funzionalità avanzate dell'utilità di pianificazione nel servizio Azure Kubernetes con kube-scheduler

Le procedure consigliate per le funzionalità avanzate dell'utilità di pianificazione di AKS includono l'uso di taints e tolleranze per dedicare nodi, selettori di nodo e affinità dei nodi per controllare il posizionamento dei pod, e affinità/anti-affinità tra pod per gestire la distribuzione dei carichi di lavoro nell'intero cluster. Quando si gestiscono i cluster nel servizio Azure Kubernetes (AKS), spesso è necessario isolare i team e i carichi di lavoro. Le funzionalità avanzate fornite dall'utilità di pianificazione Kubernetes consentono di controllare:

  • Quali pod possono essere pianificati su specifici nodi.
  • Modalità di distribuzione appropriata delle applicazioni multi-pod nel cluster.

Questo articolo sulle procedure consigliate è incentrato sulle funzionalità di pianificazione avanzate di Kubernetes per gli operatori del cluster. In questo articolo vengono illustrate le operazioni seguenti:

  • Usare taint e tolleranze per limitare i pod che possono essere pianificati sui nodi.
  • Stabilire che i pod vengano eseguiti su determinati nodi con i selettori di nodo o l'affinità tra nodi.
  • Suddividere o raggruppare i pod con l'affinità tra pod o l'anti-affinità.
  • Limitare la pianificazione dei carichi di lavoro che richiedono GPU solo nei nodi con GPU pianificabili.

Se sono necessarie funzionalità aggiuntive o framework ml per pianificare e accodare i carichi di lavoro batch, è possibile installare e configurare Kueue nel servizio Azure Kubernetes per garantire una pianificazione efficiente basata su criteri nei cluster del servizio Azure Kubernetes.

Se è necessaria una configurazione dell'utilità di pianificazione con granularità fine per ottimizzare il modo in cui i pod e i processi assegnano priorità a nodi specifici, risorse di archiviazione, topologia e altro ancora, è possibile configurare un'utilità di pianificazione nel servizio Azure Kubernetes.

Confronto tra le funzionalità di pianificazione

Feature Caso di utilizzo Comportamento di pianificazione Quando scegliere
Taint e tolleranze Dedicare nodi per carichi di lavoro specifici (ad esempio, nodi GPU) Restrizione rigida: i pod senza la tolleranza corrispondente non possono essere pianificati sui nodi con taint Quando è necessario un isolamento rigoroso dei nodi e si vuole impedire carichi di lavoro non autorizzati
Selettori dei nodi Posizionamento semplice dei pod basato su etichette Restrizione non rigida: i pod richiedono etichette corrispondenti, ma i pod senza etichetta possono comunque essere pianificati sui nodi con etichette Quando hai bisogno di un controllo di pianificazione di base con una semplice corrispondenza delle etichette
Affinità tra nodi Selezione di nodi flessibili con opzioni di fallback Configurabile: supporta le regole di corrispondenza richieste (hard) e preferite (soft) Quando sono necessarie espressioni avanzate o si desidera pianificare le preferenze con il comportamento di fallback
Affinità tra pod e anti-affinità Scegliere una posizione condivisa per i pod o separarli in base al posizionamento esistente dei pod Controlla la distribuzione dei pod rispetto ad altri pod nei nodi Quando le relazioni tra pod e pod sono importanti (ad esempio la condivisione dell'app e della cache o la distribuzione delle repliche)

Cosa sono i taint e le toleration?

I taint e le toleration sono un meccanismo di Kubernetes che consente ai nodi di respingere i pod, a meno che questi non tollerino esplicitamente il taint del nodo, fornendo un isolamento rigoroso per i carichi di lavoro dedicati.

Procedura consigliata: usare i taints e le tolleranze per dedicare i nodi GPU Limitare l'accesso per applicazioni a elevato utilizzo di risorse, ad esempio controller in ingresso, a nodi specifici. Mantenere le risorse dei nodi disponibili per i carichi di lavoro che le richiedono e non consentire la pianificazione di altri carichi di lavoro sui nodi.

Quando si crea il proprio cluster AKS, è possibile distribuire nodi con supporto GPU o un numero elevato di CPU potenti. Per ulteriori informazioni, vedere Usare GPU su AKS. È possibile usare questi nodi per carichi di lavoro di elaborazione dati di grandi dimensioni, ad esempio Machine Learning (ML) o intelligenza artificiale (AI).

Poiché l'hardware delle risorse del nodo è generalmente costoso da implementare, limitare i carichi di lavoro che possono essere assegnati su questi nodi. Dedicare invece alcuni nodi nel cluster per eseguire servizi di ingresso e impedire altri carichi di lavoro.

Questo supporto per nodi diversi viene fornito usando più pool di nodi. Un cluster AKS supporta uno o più pool di nodi.

Il scheduler di Kubernetes usa taints e tolleranze per limitare i carichi di lavoro che possono essere eseguiti sui nodi.

  • Applicare un taint a un nodo per indicare che è possibile pianificare solo pod specifici.
  • Applicare quindi una tolleranza a un pod, consentendo loro di tollerare il taint di un nodo.

Quando si distribuisce un pod in un cluster AKS, Kubernetes pianifica solo i pod sui nodi in cui un tant è allineata con una tolleranza. I taint e le tolleranze interagiscono per garantire che i pod non siano pianificati in nodi inappropriati. Uno o più taint vengono applicati a un nodo, contrassegnando il nodo in modo che non accetti i pod che non tollerano i taint.

Come si implementano taint e tolleranze in AKS?

Si supponga, ad esempio, di aver aggiunto un pool di nodi nel cluster del servizio Azure Kubernetes per i nodi con supporto GPU. Si definisce il nome, ad esempio gpu, quindi un valore per la pianificazione. L'impostazione di questo valore su NoSchedule impedisce all'utilità di pianificazione Kubernetes di pianificare i pod con tolerazione non definita nel nodo.

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

Con un taint applicato ai nodi nel pool di nodi, si definisce quindi una tolleranza nella specifica del pod che consente la pianificazione sui nodi. L'esempio seguente definisce sku: gpu e effect: NoSchedule per tollerare il taint applicato al pool di nodi nel passaggio precedente:

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"

Quando questo pod viene distribuito, ad esempio usando kubectl apply -f gpu-toleration.yaml, Kubernetes può pianificare correttamente il pod sui nodi con il taint applicato. Questo isolamento logico consente di controllare l'accesso alle risorse all'interno di un cluster.

Dedicare pool di nodi a più applicazioni

Per dedicare nodi separati ad applicazioni diverse, creare un pool di nodi per ogni applicazione con un taint univoco e un'etichetta corrispondente. Il taint impedisce che altri pod vengano pianificati su quel pool di nodi, mentre l'etichetta consente di specificare che un'applicazione venga eseguita solo sul pool di nodi dedicato.

L'esempio seguente crea pool di nodi separati per le applicazioni front-end e back-end:

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name frontpool \
    --node-count 1 \
    --labels workload=frontend \
    --node-taints workload=frontend:NoSchedule

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name backpool \
    --node-count 1 \
    --labels workload=backend \
    --node-taints workload=backend:NoSchedule

Creare un file denominato dedicated-apps.yaml e aggiungere le definizioni di pod seguenti. Ogni pod ha una tollerazione che corrisponde al taint del relativo pool di nodi e un nodeSelector che richiede l'etichetta del pool di nodi corrispondente:

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  nodeSelector:
    workload: frontend
  tolerations:
  - key: "workload"
    operator: "Equal"
    value: "frontend"
    effect: "NoSchedule"
  containers:
  - name: frontend
    image: mcr.microsoft.com/oss/nginx/nginx:1.25.5
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi
---
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: backend
spec:
  nodeSelector:
    workload: backend
  tolerations:
  - key: "workload"
    operator: "Equal"
    value: "backend"
    effect: "NoSchedule"
  containers:
  - name: backend
    image: mcr.microsoft.com/oss/nginx/nginx:1.25.5
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

Applicare il manifesto:

kubectl apply -f dedicated-apps.yaml

Verifica che ogni pod sia in esecuzione su un nodo con l'etichetta del carico di lavoro prevista:

kubectl get pods -o wide
kubectl get nodes -L workload

Il pod frontend è pianificato su un nodo etichettato con workload=frontend, e il pod backend è pianificato su un nodo etichettato con workload=backend. Una tollerazione da sola consente a un pod di usare un nodo tainted, ma non richiede il posizionamento in tale nodo. Il nodeSelector soddisfa tale requisito.

Eliminare le risorse di esempio quando non sono più necessarie:

kubectl delete -f dedicated-apps.yaml

az aks nodepool delete \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name frontpool

az aks nodepool delete \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name backpool

Quando si applicano i taint, contattare gli sviluppatori e i proprietari delle applicazioni per consentire loro di definire le tolleranze richieste nelle proprie distribuzioni.

Per altre informazioni su come usare più pool di nodi nel servizio Azure Kubernetes, vedere Creare più pool di nodi per un cluster nel servizio Azure Kubernetes.

Comportamento dei taint e delle tolleranze in AKS

Quando si aggiorna un pool di nodi in AKS, i taints e le tolerations seguono uno schema predefinito mentre vengono applicati ai nuovi nodi.

Cluster predefiniti che usano set di scalabilità di macchine virtuali di Azure

È possibile applicare taint a un pool di nodi tramite l'API di AKS per fare in modo che i nuovi nodi scalati ricevano i taint dei nodi specificati dall'API.

Supponiamo:

  1. Si inizia con un cluster a due nodi: nodo1 e nodo2.
  2. Si aggiorna il pool di nodi.
  3. Vengono creati altri due nodi: nodo3 e nodo4.
  4. I taint vengono trasmessi rispettivamente.
  5. I nodo1 e nodo2 originali vengono eliminati.

Cluster senza supporto per set di scalabilità di macchine virtuali

Anche in questo caso, si supponga:

  1. È disponibile un cluster a due nodi: nodo1 e nodo2.
  2. Si aggiorna il pool di nodi.
  3. Viene creato un nodo aggiuntivo: nodo3.
  4. I taint del nodo1 vengono applicati al nodo3.
  5. Il nodo1 viene eliminato.
  6. Viene creato un nuovo nodo1 per sostituire il nodo originale1.
  7. I taint del nodo2 vengono applicati al nuovo nodo1.
  8. Il nodo2 viene eliminato.

In sostanza, il nodo1 diventa nodo3 e il nodo2 diventa il nuovo nodo1.

Quando si scala un pool di nodi in AKS, per impostazione predefinita i taint e le tolleranze non vengono trasferiti.

Che cosa sono i selettori di nodo e l'affinità dei nodi?

I selettori di nodo e l'affinità dei nodi sono funzionalità di Kubernetes che consentono ai pod di specificare le preferenze per i nodi su cui devono essere eseguiti, in base alle etichette dei nodi.

Procedura consigliata: usare selettori di nodo e affinità per controllare il posizionamento dei pod in base al tipo di hardware Controllare la pianificazione dei pod nei nodi usando selettori di nodo, affinità dei nodi o affinità tra pod. Queste impostazioni consentono all'utilità di pianificazione di Kubernetes di isolare in modo logico i carichi di lavoro, ad esempio in base all'hardware nel nodo.

Taint e tolleranze isolano logicamente le risorse con un'interruzione netta. Se il pod non tollera il taint di un nodo, non viene pianificato sul nodo.

In alternativa, è possibile usare dei selettori di nodo. Ad esempio, si etichettano i nodi per indicare l'archiviazione SSD collegata localmente o una grande quantità di memoria e quindi definire nella specifica del pod un selettore di nodo. Kubernetes pianifica tali pod su un nodo corrispondente.

A differenza delle tolleranze, i pod senza un selettore di nodo corrispondente possono essere comunque pianificati sui nodi con etichetta. Questo comportamento consente l'utilizzo delle risorse inutilizzate sui nodi, dando tuttavia la priorità ai pod che definiscono il selettore di nodo corrispondente.

Verrà ora preso in esame un esempio di nodi con una quantità elevata di memoria. Questi nodi assegnano priorità ai pod che richiedono una quantità elevata di memoria. Per assicurarsi che le risorse non rimangano inattive, consentono anche l'esecuzione di altri pod. Il comando di esempio seguente aggiunge un pool di nodi con l'etichetta hardware=highmem al myAKSCluster nel myResourceGroup. Tutti i nodi nel pool di nodi hanno questa etichetta.

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

Una specifica del pod aggiunge quindi la proprietà nodeSelector per definire un selettore di nodo corrispondente all'etichetta impostata su un nodo:

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

Quando si usano queste opzioni dell'utilità di pianificazione, contattare gli sviluppatori e i proprietari delle applicazioni per consentire loro di definire correttamente le specifiche dei pod.

Per altre informazioni sull'uso dei selettori di nodo, vedere Assigning Pods to Nodes (Assegnazione di pod ai nodi).

Che cos'è l'affinità dei nodi?

Un selettore di nodo è una soluzione di base per l'assegnazione di pod a un determinato nodo. L’affinità nodo offre maggiore flessibilità, consentendo di definire cosa accade se il pod non può essere associato a un nodo. È possibile:

  • Richiedere che l'utilità di pianificazione di Kubernetes trovi una corrispondenza tra un pod e un host con etichetta. Oppure
  • Preferire una corrispondenza ma consentire la pianificazione del pod su un host differente se la corrispondenza non è disponibile.

Nell'esempio seguente l'affinità tra nodi viene impostata su requiredDuringSchedulingIgnoredDuringExecution. Questa affinità richiede che il programma di pianificazione di Kubernetes usi un nodo con un'etichetta corrispondente. Se non è disponibile alcun nodo, il pod deve attendere che la programmazione continui. Per consentire la pianificazione del pod su un nodo diverso, è possibile impostare invece il valore su preferredDuringSchedulingIgnoreDuringExecution:

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

La parte IgnoredDuringExecution dell'impostazione indica che il pod non deve essere rimosso dal nodo se le etichette del nodo cambiano. L'utilità di pianificazione di Kubernetes usa solo le etichette dei nodi aggiornate per la pianificazione dei nuovi pod, e non i pod già pianificati sui nodi.

Per altre informazioni, vedere la sezione relativa ad affinità e anti-affinità.

Che cos'è l'affinità e l'anti-affinità tra pod?

Un ultimo approccio per consentire all'utilità di pianificazione di Kubernetes di isolare in modo logico i carichi di lavoro consiste nell'usare l'affinità tra pod o l'anti-affinità. Queste impostazioni definiscono che i pod non devono o devono essere pianificati in un nodo con un pod corrispondente esistente. Per impostazione predefinita, l'utilità di pianificazione di Kubernetes tenta di pianificare più pod in un set di repliche tra i nodi. È possibile definire più regole specifiche in base a questo comportamento.

Ad esempio, si dispone di un'applicazione Web che usa anche una risorsa Redis gestita di Azure.

  • Usare le regole di anti-affinità dei pod per richiedere che il pianificatore di Kubernetes distribuisca le repliche tra i nodi.
  • Si usano regole di affinità per assicurarsi che ogni componente dell'app Web sia pianificato nello stesso host di una cache corrispondente.

La distribuzione dei pod tra i nodi è simile alla seguente:

Nodo 1 Nodo 2 Nodo 3
webapp-1 webapp-2 webapp-3
cache-1 cache-2 cache-3

L'affinità tra pod e l'anti-affinità offrono una distribuzione più complessa rispetto ai selettori di nodo o all'affinità dei nodi. Con la distribuzione, si isolano logicamente le risorse e si controlla il modo in cui Kubernetes pianifica i pod nei nodi.

Per un esempio completo di questa applicazione Web con Azure Managed Redis, vedere Co-lochi i pod nello stesso nodo.

Passaggi successivi

Questo articolo ha illustrato le funzionalità avanzate dell'utilità di pianificazione di Kubernetes. Per ulteriori informazioni sulle operazioni del cluster in Azure Kubernetes Service (AKS), consultare le seguenti procedure consigliate:

  • Last updated on