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

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:

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 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.

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.

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

Gerir a programação 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 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.

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 agendado em um nodo diferente, pode, em vez de, configurar 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 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.

Afinidade interpod e 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, você tem um aplicativo Web que também usa um Cache do Azure para 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 obter um exemplo completo desta aplicação 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:

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