Best practices voor geavanceerde planningsfuncties in Azure Kubernetes Service (AKS)

Artikel
11/01/2024

Wanneer u clusters beheert in Azure Kubernetes Service (AKS), moet u vaak teams en workloads isoleren. Met geavanceerde functies van de Kubernetes-planner kunt u het volgende beheren:

Welke pods op bepaalde knooppunten kunnen worden gepland.
Hoe toepassingen met meerdere pods op de juiste wijze kunnen worden gedistribueerd over het cluster.

Dit artikel met aanbevolen procedures is gericht op geavanceerde Kubernetes-planningsfuncties voor clusteroperators. In dit artikel leert u het volgende:

Gebruik taints en toleranties om te beperken welke pods op knooppunten kunnen worden gepland.
Geef voorkeur aan pods die op bepaalde knooppunten moeten worden uitgevoerd met knooppuntkiezers of knooppuntaffiniteit.
Splits pods of groepeer deze met affiniteit tussen pods of antiaffiniteit.
Beperk de planning van workloads waarvoor GPU's alleen zijn vereist op knooppunten met gescheerde GPU's.

Toegewezen knooppunten bieden met taints en toleranties

Richtlijnen voor aanbevolen procedures:

Beperk de toegang voor resource-intensieve toepassingen, zoals toegangsbeheerobjectcontrollers, tot specifieke knooppunten. Houd knooppuntbronnen beschikbaar voor workloads waarvoor ze nodig zijn en sta het plannen van andere workloads op de knooppunten niet toe.

Wanneer u uw AKS-cluster maakt, kunt u knooppunten implementeren met GPU-ondersteuning of een groot aantal krachtige CPU's. Zie GPU's op AKS gebruiken voor meer informatie. U kunt deze knooppunten gebruiken voor grote workloads voor gegevensverwerking, zoals machine learning (ML) of kunstmatige intelligentie (AI).

Omdat deze knooppuntresourcehardware doorgaans duur is om te implementeren, beperkt u de workloads die op deze knooppunten kunnen worden gepland. Wijs in plaats daarvan enkele knooppunten in het cluster toe om toegangsbeheerservices uit te voeren en andere workloads te voorkomen.

Deze ondersteuning voor verschillende knooppunten wordt geboden met behulp van meerdere knooppuntgroepen. Een AKS-cluster ondersteunt een of meer knooppuntgroepen.

De Kubernetes-scheduler maakt gebruik van taints en toleranties om te beperken welke workloads op knooppunten kunnen worden uitgevoerd.

Pas een taint toe op een knooppunt om aan te geven dat alleen specifieke pods erop kunnen worden gepland.
Pas vervolgens een tolerantie toe op een pod, zodat ze de taint van een knooppunt kunnen tolereren .

Wanneer u een pod implementeert in een AKS-cluster, plant Kubernetes alleen pods op knooppunten waarvan de taint overeenkomt met de tolerantie. Taints en toleranties werken samen om ervoor te zorgen dat pods niet worden gepland op ongepaste knooppunten. Een of meer taints worden toegepast op een knooppunt, waarbij het knooppunt zodanig wordt gemarkeerd dat er geen pods worden geaccepteerd die de tainten niet tolereren.

Stel dat u een knooppuntgroep hebt toegevoegd in uw AKS-cluster voor knooppunten met GPU-ondersteuning. U definieert de naam, zoals gpu, en vervolgens een waarde voor het plannen. Als u deze waarde instelt op NoSchedule , wordt de Kubernetes-planner beperkt tot het plannen van pods met niet-gedefinieerde tolerantie op het knooppunt.

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

Met een taint die is toegepast op knooppunten in de knooppuntgroep, definieert u een tolerantie in de podspecificatie die planning op de knooppunten toestaat. In het volgende voorbeeld wordt de sku: gpu taint gedefinieerd en effect: NoSchedule getolereerd die in de vorige stap is toegepast op de knooppuntgroep:

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"

Wanneer deze pod wordt geïmplementeerd met behulp kubectl apply -f gpu-toleration.yamlvan, kan Kubernetes de pod op de knooppunten plannen waarop de taint is toegepast. Met deze logische isolatie kunt u de toegang tot resources binnen een cluster beheren.

Wanneer u taints toepast, moet u samenwerken met uw toepassingsontwikkelaars en -eigenaren, zodat ze de vereiste toleranties in hun implementaties kunnen definiëren.

Zie Meerdere knooppuntgroepen maken voor een cluster in AKS voor meer informatie over het gebruik van meerdere knooppuntgroepen in AKS.

Gedrag van taints en toleranties in AKS

Wanneer u een upgrade uitvoert van een knooppuntgroep in AKS, volgen taints en toleranties een ingesteld patroon wanneer ze worden toegepast op nieuwe knooppunten:

Standaardclusters die gebruikmaken van Virtuele-machineschaalsets van Azure

U kunt een knooppuntgroep van de AKS-API tainten om onlangs uitgeschaalde knooppunten api-knooppunttaints te laten ontvangen.

Laten we aannemen:

U begint met een cluster met twee knooppunten: node1 en node2.
U upgradet de knooppuntgroep.
Er worden twee andere knooppunten gemaakt: node3 en node4.
De tainten worden respectievelijk doorgegeven.
Het oorspronkelijke knooppunt1 en knooppunt2 worden verwijderd.

Clusters zonder ondersteuning voor virtuele-machineschaalsets

We gaan er nogmaals van uit:

U hebt een cluster met twee knooppunten: knooppunt1 en knooppunt2.
U upgradet de knooppuntgroep.
Er wordt een extra knooppunt gemaakt: node3.
De tainten van knooppunt1 worden toegepast op node3.
node1 wordt verwijderd.
Er wordt een nieuw knooppunt1 gemaakt om het oorspronkelijke knooppunt1 te vervangen.
De tainten van knooppunt2 worden toegepast op het nieuwe knooppunt1.
node2 wordt verwijderd.

In wezen wordt node1 knooppunt3 en wordt node2 het nieuwe knooppunt1.

Wanneer u een knooppuntgroep in AKS schaalt, worden taints en toleranties niet standaard overgedragen.

Plannen van pods beheren met behulp van knooppuntselectors en affiniteit

Richtlijnen voor best practices

Beheer de planning van pods op knooppunten met behulp van knooppuntkiezers, knooppuntaffiniteit of affiniteit tussen pods. Met deze instellingen kan de Kubernetes scheduler workloads logisch isoleren, zoals door hardware in het knooppunt.

Taints en toleranties isoleren resources logisch met een harde cut-off. Als de pod de taint van een knooppunt niet tolereert, wordt deze niet gepland op het knooppunt.

U kunt ook knooppuntkiezers gebruiken. U labelt bijvoorbeeld knooppunten om lokaal gekoppelde SSD-opslag of een grote hoeveelheid geheugen aan te geven en definieert vervolgens in de podspecificatie een knooppuntkiezer. Kubernetes plant deze pods op een overeenkomend knooppunt.

In tegenstelling tot toleranties kunnen pods zonder een overeenkomende knooppuntkiezer nog steeds worden gepland op gelabelde knooppunten. Met dit gedrag kunnen ongebruikte resources op de knooppunten worden gebruikt, maar worden pods prioriteit gegeven die de overeenkomende knooppuntkiezer definiëren.

Laten we eens kijken naar een voorbeeld van knooppunten met een hoge hoeveelheid geheugen. Deze knooppunten geven prioriteit aan pods die een hoge hoeveelheid geheugen aanvragen. Om ervoor te zorgen dat de resources niet inactief zijn, kunnen andere pods ook worden uitgevoerd. Met de volgende voorbeeldopdracht wordt een knooppuntgroep met de labelhardware=highmem toegevoegd aan het myAKSCluster in myResourceGroup. Alle knooppunten in die knooppuntgroep hebben dit label.

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

Een podspecificatie voegt vervolgens de nodeSelector eigenschap toe om een knooppuntkiezer te definiëren die overeenkomt met het label dat op een knooppunt is ingesteld:

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

Wanneer u deze scheduler-opties gebruikt, kunt u samenwerken met uw toepassingsontwikkelaars en -eigenaren, zodat ze hun podspecificaties correct kunnen definiëren.

Zie Pods toewijzen aan knooppunten voor meer informatie over het gebruik van knooppuntkiezers.

Knooppuntaffiniteit

Een knooppuntkiezer is een basisoplossing voor het toewijzen van pods aan een bepaald knooppunt. Knooppuntaffiniteit biedt meer flexibiliteit, zodat u kunt definiëren wat er gebeurt als de pod niet kan worden vergeleken met een knooppunt. U kunt:

Vereisen dat Kubernetes scheduler overeenkomt met een pod met een gelabelde host. Of
Geef de voorkeur aan een overeenkomst, maar sta toe dat de pod op een andere host wordt gepland als er geen overeenkomst beschikbaar is.

In het volgende voorbeeld wordt de knooppuntaffiniteit ingesteld op requiredDuringSchedulingIgnoredDuringExecution. Voor deze affiniteit moet het Kubernetes-schema een knooppunt met een overeenkomend label gebruiken. Als er geen knooppunt beschikbaar is, moet de pod wachten tot de planning is voortgezet. Als u wilt toestaan dat de pod wordt gepland op een ander knooppunt, kunt u in plaats daarvan de waarde instellen op De voorkeurTijdensSchedulingIgnoreDuringExecution:

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

Het onderdeel IgnoredDuringExecution van de instelling geeft aan dat de pod niet uit het knooppunt mag worden verwijderd als de knooppuntlabels worden gewijzigd. De Kubernetes-planner gebruikt alleen de bijgewerkte knooppuntlabels voor nieuwe pods die worden gepland, niet pods die al op de knooppunten zijn gepland.

Zie Affiniteit en antiaffiniteit voor meer informatie.

Affiniteit tussen pods en antiaffiniteit

Een laatste benadering voor de Kubernetes scheduler om workloads logisch te isoleren, is het gebruik van affiniteit tussen pods of antiaffiniteit. Deze instellingen definiëren dat pods niet of niet moeten worden gepland op een knooppunt met een bestaande overeenkomende pod. Standaard probeert de Kubernetes-planner meerdere pods in een replicaset te plannen op meerdere knooppunten. U kunt specifiekere regels voor dit gedrag definiëren.

U hebt bijvoorbeeld een webtoepassing die ook gebruikmaakt van een Azure Cache voor Redis.

U gebruikt antiaffiniteitsregels voor pods om aan te vragen dat de Kubernetes scheduler replica's over knooppunten distribueert.
U gebruikt affiniteitsregels om ervoor te zorgen dat elk web-app-onderdeel wordt gepland op dezelfde host als een bijbehorende cache.

De distributie van pods tussen knooppunten ziet eruit als in het volgende voorbeeld:

Knooppunt 1	Knooppunt 2	Knooppunt 3
webapp-1	webapp-2	webapp-3
cache-1	cache-2	cache-3

Affiniteit tussen pods en antiaffiniteit bieden een complexere implementatie dan knooppuntkiezers of knooppuntaffiniteit. Met de implementatie kunt u resources logisch isoleren en bepalen hoe Kubernetes pods plant op knooppunten.

Zie Pods zoeken op hetzelfde knooppunt voor een volledig voorbeeld van deze webtoepassing met Azure Cache voor Redis voorbeeld.

Volgende stappen

Dit artikel is gericht op geavanceerde Functies van Kubernetes Scheduler. Zie de volgende aanbevolen procedures voor meer informatie over clusterbewerkingen in AKS:

Delen via