Partilhar via

Melhores práticas para funcionalidades avançadas do agendador no Azure Kubernetes Service (AKS)

  • Artigo

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 os aplicativos multipod podem ser distribuídos 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:

  • Use manchas e tolerâncias para limitar quais pods podem ser programados em nós.
  • Dê preferência a pods para serem executados em determinados nós com seletores de nós ou afinidade de nós.
  • Separe ou agrupe cápsulas com afinidade ou antiafinidade entre pods.
  • Restrinja o agendamento de cargas de trabalho que exigem GPUs apenas em nós com GPUs escalonáveis.

Indicar os nós dedicados com rejeições e tolerâncias

Orientações sobre boas práticas:

Limite o acesso de aplicativos que consomem muitos recursos, como controladores de entrada, a nós específicos. Mantenha os recursos do nó disponíveis para cargas de trabalho que os exijam e não permita o agendamento de outras cargas de trabalho nos 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).

Como a implantação desse hardware de recurso de nó normalmente é cara, limite as cargas de trabalho que podem 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.

Esse suporte para nós diferentes é fornecido usando vários pools de nós. Um cluster AKS suporta um ou mais pools de nós.

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

  • Aplique uma mancha a um nó para indicar que apenas pods específicos podem ser programados 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.

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 mancha aplicada aos nós no pool de nós, você define 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.

Ao aplicar manchas, trabalhe com os desenvolvedores e proprietários de aplicativos para permitir que eles definam as tolerâncias necessárias em suas implantaçõ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. As manchas são passadas adiante, respectivamente.
  5. Os nós originais 1 e node2 são excluídos.

Clusters sem suporte a Conjuntos de Dimensionamento de Máquina Virtual

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. Um novo nó1 é criado para substituir o nó original1.
  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.

Controlar o agendamento de pods com seletores de nós e afinidade

Orientações sobre boas práticas

Controle o agendamento de pods em nós usando seletores de nós, afinidade de nó ou afinidade entre pods. Essas configurações permitem que o agendador do Kubernetes isole logicamente cargas de trabalho, como por hardware no nó.

Manchas e tolerâncias isolam logicamente os recursos com um corte rígido. Se o pod não tolerar a mancha de um nó, ele não será agendado no nó.

Como alternativa, você pode usar seletores de nós. Por exemplo, você rotula 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ó. O Kubernetes agenda esses pods em um nó correspondente.

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 recursos não utilizados nos nós sejam consumidos, mas prioriza 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 sejam executados. 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, uma especificação de pod adiciona a nodeSelector propriedade para definir um seletor de nó que corresponda ao rótulo definido em 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.

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 você defina o que acontece se o pod não puder ser correspondido com um nó. Pode:

  • Exija que o agendador do Kubernetes corresponda a um pod com um host rotulado. 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 define 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 agendado em um nó diferente, você pode, em vez disso, definir o valor como DuringSchedulingIgnoreDuringExecution:

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 removido do nó se os rótulos do nó forem alterados. O agendador do Kubernetes usa apenas os rótulos de nó atualizados para novos pods que estão sendo agendados, não pods já agendados nos nós.

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

Afinidade interpod e anti-afinidade

Uma abordagem final para o agendador do Kubernetes isolar logicamente cargas de trabalho é usar 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 agendar vários pods em um conjunto de réplicas entre nós. Você pode definir regras mais específicas em torno desse comportamento.

Por exemplo, você tem um aplicativo Web que também usa um Cache do Azure para Redis.

  • Você usa regras de antiafinidade de pod para solicitar que o agendador do Kubernetes distribua réplicas entre 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:

Nó 1 Nó 2 Nó 3
WebApp-1 WebApp-2 WebApp-3
Cache-1 cache-2 Cache-3

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 obter um exemplo completo desse aplicativo Web com o Cache do Azure para Redis, consulte Colocalizar pods no mesmo nó.

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: