Controlar se uma workload é implantada nos nós do Modo Automático do EKS

Ao executar workloads em um cluster do EKS com o Modo Automático do EKS, talvez você precise controlar se workloads específicas são executadas nos nós do Modo Automático do EKS ou em outros tipos de computação. Este tópico descreve como usar seletores de nós e regras de afinidade para garantir que as workloads sejam agendadas na infraestrutura de computação pretendida.

Os exemplos neste tópico demonstram como usar o rótulo eks.amazonaws.com/compute-type para exigir ou impedir a implantação de uma workload nos nós do Modo Automático do EKS. Isso é particularmente útil em clusters de modo misto em que você está executando o Modo Automático do EKS e outros tipos de computação, como provisionadores do Karpenter autogerenciados ou grupos de nós gerenciados pelo EKS.

Os nós do Modo Automático do EKS definiram o valor do rótulo eks.amazonaws.com/compute-type como auto. Você pode usar esse rótulo para controlar se uma workload é implantada em nós gerenciados pelo Modo Automático do EKS.

Exigir que uma workload seja implantada nos nós do Modo Automático do EKS

nota

Esse valor de nodeSelector não é necessário para o Modo Automático do EKS. Esse valor de nodeSelector só será relevante se você estiver executando um cluster em um modo misto, com tipos de nós não gerenciados pelo Modo Automático do EKS. Por exemplo, você pode ter capacidade computacional estática implantada no cluster com grupos de nós gerenciados pelo EKS e capacidade computacional dinâmica gerenciada pelo Modo Automático do EKS.

Você pode adicionar esse nodeSelector às implantações ou a outras workloads para exigir que o Kubernetes as programe nos nós do Modo Automático do EKS.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      nodeSelector:
        eks.amazonaws.com/compute-type: auto

Exigir que uma workload não seja implantada nos nós do Modo Automático do EKS

Você pode adicionar esse nodeAffinity às implantações ou a outras workloads para exigir que o Kubernetes não as programe nos nós do Modo Automático do EKS.

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - auto

Direcione um NodePool específico

Um cluster do Modo Automático do Amazon EKS pode ter mais de um NodePool. Talvez você queira que uma workload o seja executada somente em nós de um NodePool específico. Para fazer isso, as workloads podem corresponder a qualquer um dos seguintes rótulos:

• Um rótulo personalizado que você define no NodePool. Quando você adiciona rótulos em spec.template.metadata.labels em um NodePool, o Modo Automático do Amazon EKS aplica esses rótulos a cada nó provisionado pelo NodePool. Rótulos personalizados são a abordagem recomendada. Um rótulo personalizado vincula a workload a um recurso, como workload-class: gpu-inference, em vez de a um nome específico do NodePool.

• O conhecido rótulo karpenter.sh/nodepool. O Modo Automático do Amazon EKS aplica esse rótulo a cada nó provisionado, usando o nome do NodePool como valor. Use esse rótulo quando você não tiver definido um rótulo personalizado e quiser direcionar um NodePool pelo nome.

Direcione um rótulo NodePool personalizado

Primeiro, defina um rótulo no NodePool.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    metadata:
      labels:
        workload-class: gpu-inference

Para obter mais informações sobre como implantar uma configuração, consulte Criar um grupo de nós para o Modo Automático do EKS.

Em seguida, combine esse rótulo com a workload.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference
spec:
  template:
    spec:
      nodeSelector:
        workload-class: gpu-inference

Os pods dessa implantação são agendados somente nos nós provisionados pelo NodePool gpu. As workloads sem esse nodeSelector continuam sendo executadas no NodePool padrão.

Direcione um NodePool pelo nome

Alterações no nome do NodePool afetam o agendamento

Fixar uma workload pelo nome pode deixar os pods no estado Pending se você renomear ou excluir o NodePool de destino. Use um rótulo de capacidade personalizado para qualquer workload que você espera que sobreviva a uma única definição do NodePool.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      nodeSelector:
        karpenter.sh/nodepool: <your-nodepool-name>

Para obter mais informações sobre como o Karpenter combina pods com NodePools, consulte Scheduling na documentação do Karpenter.