Práticas recomendadas para recursos avançados do agendador no Serviço Kubernetes do Azure (AKS) usando o kube-scheduler

As melhores práticas para as funcionalidades avançadas do agendador do AKS incluem a utilização de taints e tolerâncias para dedicar nós, seletores de nós e afinidade de nós para controlar o posicionamento dos pods, e afinidade/anti-afinidade entre pods para gerir a distribuição das cargas de trabalho no seu cluster. Ao gerenciar clusters no Serviço Kubernetes do Azure (AKS), muitas vezes você precisa isolar equipes e cargas de trabalho. Os recursos avançados fornecidos pelo agendador do Kubernetes permitem que você controle:

• Quais pods podem ser programados em determinados nós.
• Como as aplicações multipod podem ser distribuídas adequadamente pelo cluster.

Este artigo de práticas recomendadas se concentra em recursos avançados de agendamento do Kubernetes para operadores de cluster. Neste artigo, vai aprender a:

• Utilize marcações e tolerâncias para limitar quais pods podem ser agendados em nós de rede.
• Dê preferência a pods executados em nós específicos utilizando seletores de nós ou afinidade de nós.
• Separe ou agrupe pods com afinidade ou antiafinidade entre pods.
• Restrinja o agendamento de cargas de trabalho que exigem GPUs apenas em nós com GPUs escalonáveis.

Se forem necessários recursos adicionais ou estruturas de ML para agendar e enfileirar cargas de trabalho em lote, você pode instalar e configurar o Kueue no AKS para garantir um agendamento eficiente e orientado por políticas em clusters AKS.

Se a configuração refinada do agendador for necessária para otimizar como pods e trabalhos priorizam nós específicos, recursos de armazenamento, topologia e muito mais, você pode configurar um agendador no AKS.

Comparação das funcionalidades de agendamento

O que são manchas e tolerâncias?

Contaminações e tolerâncias são um mecanismo Kubernetes que permite aos nós repelir pods a menos que esses pods tolerem explicitamente a contaminação do nó, proporcionando isolamento rigoroso para cargas de trabalho dedicadas.

Boa Prática: Usar contaminações e tolerâncias para dedicar nós da GPU Limite o acesso para aplicações intensivas em recursos, como controladores de entrada, a nós específicos. Mantenha os recursos do nó disponíveis para tarefas que os exijam e não permita o agendamento de outras tarefas nesses nós.

Ao criar seu cluster AKS, você pode implantar nós com suporte a GPU ou um grande número de CPUs poderosas. Para obter mais informações, consulte Usar GPUs no AKS. Você pode usar esses nós para grandes cargas de trabalho de processamento de dados, como aprendizado de máquina (ML) ou inteligência artificial (IA).

Visto que o hardware dos recursos desses nós é normalmente caro de implementar, limite as cargas de trabalho que possam ser agendadas nesses nós. Em vez disso, dedique alguns nós no cluster para executar serviços de entrada e evitar outras cargas de trabalho.

Este suporte para diferentes nós é providenciado através do uso de vários pools de nós. Um cluster AKS suporta um ou mais pools de nós.

O agendador do Kubernetes usa taints e tolerâncias para restringir quais cargas de trabalho podem ser executadas nos nós.

• Aplique uma restrição a um nó para indicar que apenas pods específicos podem ser alocados neles.
• Em seguida, aplique uma tolerância a um pod, permitindo-lhes tolerar a mancha de um nó.

Quando você implanta um pod em um cluster AKS, o Kubernetes só agenda pods em nós cuja mancha se alinha com a tolerância. Manchas e tolerâncias trabalham juntas para garantir que os pods não sejam programados em nós inadequados. Uma ou mais manchas são aplicadas a um nó, marcando o nó para que ele não aceite nenhum pod que não tolere as manchas.

Como implemento contaminações e tolerâncias no AKS?

Por exemplo, suponha que você adicionou um pool de nós em seu cluster AKS para nós com suporte a GPU. Você define nome, como gpu, e depois um valor para agendamento. Definir esse valor como NoSchedule restringe o agendador do Kubernetes de agendar pods com tolerância indefinida no nó.

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

Com uma tinta aplicada aos nós no grupo de nós, define-se uma tolerância na especificação do pod que permite o agendamento nos nós. O exemplo a seguir define o sku: gpu e effect: NoSchedule para tolerar a mancha aplicada ao pool de nós na etapa anterior:

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 esse pod é implantado usando kubectl apply -f gpu-toleration.yamlo , o Kubernetes pode agendar com êxito o pod nos nós com a mancha aplicada. Esse isolamento lógico permite controlar o acesso a recursos dentro de um cluster.

Dedique pools de nós a múltiplas aplicações

Para dedicar nós distintos a diferentes aplicações, crie um pool de nós para cada aplicação com uma taint única e um rótulo correspondente. A contaminação impede que outros pods sejam agendados no pool de nós, enquanto o rótulo permite exigir que uma aplicação corra apenas no seu pool dedicado de nós.

O exemplo seguinte cria pools de nós separados para aplicações frontend e backend:

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

Crie um ficheiro com nome dedicated-apps.yaml e adicione as seguintes definições de pod. Cada pod tem uma tolerância que corresponde à mancha do respetivo conjunto de nós e um nodeSelector que requer o rótulo correspondente do conjunto de nós:

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

Aplique o manifesto:

kubectl apply -f dedicated-apps.yaml

Verifique se cada pod está em execução num nó com o rótulo de carga de trabalho esperado:

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

O frontend pod é agendado num nó rotulado workload=frontend, e o backend pod é agendado num nó rotulado workload=backend. A tolerância por si só permite que um pod use um nó contaminado, mas não requer colocação nesse nó. O nodeSelector cumpre esse requisito.

Apaga os recursos de exemplo quando já não precisares deles:

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

Ao aplicar tintas, trabalhe com os desenvolvedores e proprietários das aplicações para permitir que eles definam as tolerâncias necessárias nas suas implementações.

Para obter mais informações sobre como usar vários pools de nós no AKS, consulte Criar vários pools de nós para um cluster no AKS.

Comportamento de manchas e tolerações em AKS

Quando você atualiza um pool de nós no AKS, as manchas e tolerâncias seguem um padrão definido à medida que são aplicadas a novos nós:

Clusters padrão que usam os Conjuntos de Escala de Máquina Virtual do Azure

Você pode contaminar um pool de nós da API do AKS para que nós recém-dimensionados recebam manchas de nó especificadas pela API.

Vamos supor:

1. Você começa com um cluster de dois nós: node1 e node2.
2. Você atualiza o pool de nós.
3. Dois outros nós são criados: node3 e node4.
4. Os defeitos são transmitidos adiante, respectivamente.
5. Os nós originais 1 e node2 são excluídos.

Clusters sem suporte a Conjuntos de Escala de Máquinas Virtuais

Mais uma vez, vamos supor:

1. Você tem um cluster de dois nós: node1 e node2.
2. Você atualiza o pool de nós.
3. Um nó extra é criado: node3.
4. As manchas do nó1 são aplicadas ao nó3.
5. node1 é excluído.
6. É criado um novo node1 para substituir o node1 original.
7. As manchas node2 são aplicadas ao novo node1.
8. node2 é excluído.

Em essência, node1 torna-se node3, e node2 torna-se o novo node1.

Quando você dimensiona um pool de nós no AKS, as manchas e tolerâncias não são transferidas por design.

O que são seletores de nós e afinidade de nós?

Os seletores de nós e a afinidade de nós são funcionalidades do Kubernetes que permitem aos pods especificarem preferências relativamente aos nós em que devem ser executados, com base nos rótulos dos nós.

Boa Prática: Usar seletores de nós e afinidade para controlar a colocação dos pods por tipo de hardware Controlar o escalonamento dos pods nos nós usando seletores de nós, afinidade de nós ou afinidade entre pods. Essas configurações permitem que o agendador do Kubernetes isole logicamente as cargas de trabalho, por exemplo, com base no hardware do nó.

Incompatibilidades e tolerâncias isolam logicamente os recursos com uma separação rígida. Se o pod não tolerar a mancha de um nó, ele não será agendado no nó.

Como alternativa, podes usar seletores de nós. Por exemplo, você etiqueta nós para indicar armazenamento SSD conectado localmente ou uma grande quantidade de memória e, em seguida, define na especificação do pod um seletor de nós. Kubernetes agenda esses pods em nós correspondentes.

Ao contrário das tolerações, os pods sem um seletor de nó correspondente ainda podem ser programados em nós rotulados. Esse comportamento permite que os recursos não utilizados nos nós sejam consumidos, mas prioriza os pods que definem o seletor de nó correspondente.

Vejamos um exemplo de nós com uma grande quantidade de memória. Esses nós priorizam pods que solicitam uma grande quantidade de memória. Para garantir que os recursos não fiquem ociosos, eles também permitem que outros pods funcionem. O comando de exemplo a seguir adiciona um pool de nós com o rótulo hardware=highmem ao myAKSCluster no myResourceGroup. Todos os nós nesse pool de nós têm esse rótulo.

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

Em seguida, a especificação do pod adiciona a propriedade nodeSelector para definir um seletor de nó que corresponda ao rótulo atribuído a um nó:

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

Ao usar essas opções do agendador, trabalhe com os desenvolvedores e proprietários de aplicativos para permitir que eles definam corretamente suas especificações de pod.

Para obter mais informações sobre como usar seletores de nós, consulte Atribuindo pods a nós.

O que é a afinidade de nó?

Um seletor de nó é uma solução básica para atribuir pods a um determinado nó. A afinidade de nó fornece mais flexibilidade, permitindo que se defina o que acontece se o pod não puder ser associado a um nó. Pode:

• Exija que o agendador do Kubernetes associe um pod com um host etiquetado. Ou,
• Prefira uma partida, mas permita que o pod seja agendado em um host diferente se nenhuma partida estiver disponível.

O exemplo a seguir configura a afinidade do nó como requiredDuringSchedulingIgnoredDuringExecution. Essa afinidade requer que a agenda do Kubernetes use um nó com um rótulo correspondente. Se nenhum nó estiver disponível, o pod terá que aguardar a continuação do agendamento. Para permitir que o pod seja programado noutro nó, pode antes definir o valor como 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

A parte IgnoredDuringExecution da configuração indica que o pod não deve ser expulso do nó se os rótulos do nó forem alterados. O agendador do Kubernetes usa apenas os rótulos dos nós atualizados para novos pods que são agendados, não para pods já agendados nos nós.

Para obter mais informações, consulte Afinidade e antiafinidade.

O que são a afinidade entre pods e a anti-afinidade?

Uma abordagem final para o agendador do Kubernetes isolar logicamente as cargas de trabalho é a utilização de afinidade ou antiafinidade entre pods. Essas configurações definem que os pods não devem ou devem ser agendados em um nó que tenha um pod correspondente existente. Por padrão, o agendador do Kubernetes tenta distribuir vários pods em um conjunto de réplicas entre os nós. Você pode definir regras mais específicas em torno desse comportamento.

Por exemplo, tens uma aplicação web que também usa um recurso Azure Managed Redis.

• Você usa regras de antiafinidade de pod para requerer que o agendador do Kubernetes distribua as réplicas pelos nós.
• Você usa regras de afinidade para garantir que cada componente do aplicativo Web esteja agendado no mesmo host que um cache correspondente.

A distribuição de pods entre nós se parece com o exemplo a seguir:

A afinidade entre pods e a antiafinidade fornecem uma implantação mais complexa do que os seletores de nó ou a afinidade de nós. Com a implantação, você isola logicamente os recursos e controla como o Kubernetes agenda pods nos nós.

Para ver um exemplo completo desta aplicação web com Azure Managed Redis, consulte Co-locate pods on the same node.

Próximos passos

Este artigo se concentrou nos recursos avançados do agendador do Kubernetes. Para obter mais informações sobre operações de cluster no AKS, consulte as seguintes práticas recomendadas:

• Multilocação e isolamento de cluster
• Recursos básicos do agendador do Kubernetes
• Autenticação e autorização