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

Artikel
08/05/2023

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

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

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

Gebruik taints en toleranties om te beperken welke pods kunnen worden gepland op knooppunten.
Geef de voorkeur aan pods die worden uitgevoerd op bepaalde knooppunten met knooppuntkiezers of knooppuntaffiniteit.
Pods splitsen of groeperen met affiniteit tussen pods of anti-affiniteit.
Beperk de planning van workloads waarvoor GPU's alleen zijn vereist op knooppunten met aanpasbare 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 knooppuntresources beschikbaar voor workloads waarvoor ze nodig zijn en sta planning 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 gebruiken op AKS voor meer informatie. U kunt deze knooppunten gebruiken voor grote gegevensverwerkingsworkloads, zoals machine learning (ML) of kunstmatige intelligentie (AI).

Omdat de implementatie van deze knooppuntresourcehardware doorgaans duur is, 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-planner 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 kunnen worden gepland.
Pas vervolgens een tolerantie toe op een pod, zodat deze de taint van een knooppunt kan 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 aangegeven dat het geen pods accepteert die de taints niet tolereren.

Stel dat u een knooppuntgroep hebt toegevoegd in uw AKS-cluster voor knooppunten met GPU-ondersteuning. U definieert naam, zoals gpu, en vervolgens een waarde voor planning. Als u deze waarde instelt op NoSchedule , beperkt u de Kubernetes-planner 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 toegepast op knooppunten in de knooppuntgroep, definieert u een tolerantie in de podspecificatie waarmee planning op de knooppunten mogelijk is. In het volgende voorbeeld wordt de sku: gpu en effect: NoSchedule gedefinieerd om de taint te tolereren die in de vorige stap op de knooppuntgroep is toegepast:

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"

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

Wanneer u taints toepast, werkt u met uw toepassingsontwikkelaars en -eigenaren om hen in staat te stellen de vereiste toleranties in hun implementaties te 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 vast patroon wanneer ze worden toegepast op nieuwe knooppunten:

Standaardclusters die gebruikmaken van Azure Virtual Machine Scale Sets

U kunt een knooppuntgroep van de AKS-API taints geven om nieuw uitgeschaalde knooppunten API-opgegeven knooppunttaints te laten ontvangen.

Laten we aannemen:

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

Clusters zonder Virtual Machine Scale Sets ondersteuning

Laten we nogmaals uitgaan van:

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

In wezen wordt node1node3 en knooppunt2 het nieuwe knooppunt1.

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

Plannen van pods beheren met behulp van knooppuntselectors en affiniteit

Richtlijnen voor aanbevolen procedures

Beheer de planning van pods op knooppunten met behulp van knooppuntkiezers, knooppuntaffiniteit of affiniteit tussen pods. Met deze instellingen kan de Kubernetes-planner werkbelastingen logisch isoleren, zoals op 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. Dit gedrag staat ongebruikte resources op de knooppunten toe om te gebruiken, maar geeft prioriteit aan pods die de overeenkomende knooppuntkiezer definiëren.

Laten we eens kijken naar een voorbeeld van knooppunten met een grote hoeveelheid geheugen. Deze knooppunten geven prioriteit aan pods die een grote hoeveelheid geheugen aanvragen. Om ervoor te zorgen dat de resources niet inactief zijn, kunnen ook andere pods worden uitgevoerd. Met de volgende voorbeeldopdracht wordt een knooppuntgroep met het label hardware=highmem toegevoegd aan de myAKSCluster in de 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: 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

Wanneer u deze scheduler-opties gebruikt, werkt u met uw toepassingsontwikkelaars en -eigenaren om hen in staat te stellen hun podspecificaties correct te 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 gekoppeld aan 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. Deze affiniteit vereist dat de Kubernetes-planning een knooppunt met een overeenkomend label gebruikt. Als er geen knooppunt beschikbaar is, moet de pod wachten totdat de planning wordt voortgezet. Als u wilt toestaan dat de pod op een ander knooppunt wordt gepland, kunt u in plaats daarvan de waarde instellen op 'DuringSchedulingIgnoreDuringExecution':

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

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

Zie Affiniteit en anti-affiniteit voor meer informatie.

Affiniteit tussen pods en anti-affiniteit

Een laatste benadering voor de Kubernetes-planner om workloads logisch te isoleren, is het gebruik van affiniteit tussen pods of anti-affiniteit. Met deze instellingen wordt gedefinieerd dat pods niet mogen of moeten worden gepland op een knooppunt met een bestaande overeenkomende pod. Standaard probeert de Kubernetes-planner meerdere pods te plannen in een replicaset op verschillende 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 te vragen dat de Kubernetes-planner replica's over knooppunten distribueert.
U gebruikt affiniteitsregels om ervoor te zorgen dat elk onderdeel van de web-app wordt gepland op dezelfde host als een bijbehorende cache.

De distributie van pods over knooppunten ziet er als volgt uit:

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 op knooppunten plant.

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

Volgende stappen

Dit artikel is gericht op geavanceerde Kubernetes-scheduler-functies. Zie de volgende aanbevolen procedures voor meer informatie over clusterbewerkingen in AKS: