Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Otimização de custos no Modo Automático do EKS

O Modo Automático do EKS otimiza continuamente os custos de computação por meio de consolidação, bin-packing e dimensionamento correto. Porém, certas configurações da workload podem impedir essas otimizações. Este tópico explica como funciona a otimização de custos, o que pode bloqueá-la e como configurar o cluster para manter a eficiência de custos.

Como o Modo Automático do EKS otimiza custos

O Modo Automático do EKS reduz os custos de computação por meio dos seguintes mecanismos:

Essas otimizações podem ser executadas continuamente, sem intervenção manual. Porém, certas anotações de pod e configurações de NodePool podem impedir que a consolidação ocorra.

Pools de nós incorporados e barreiras de proteção de custo

Os pools de nós de general-purpose e de system incorporados aplicam vários padrões de proteção de custos:

Se você usar apenas pools de nós incorporados, já terá os benefícios dessas barreiras de proteção. A orientação neste tópico sobre a exclusão das famílias de instâncias e a restrição do tamanho das instâncias é mais relevante quando você cria NodePools personalizados, que não herdam essas restrições.

Porém, mesmo com pools de nós incorporados, as seções a seguir continuam se aplicar:

O que bloqueia a consolidação

A consolidação é bloqueada quando o Modo Automático do EKS determina que interromper um nó violaria os requisitos de disponibilidade de uma workload. As seguintes configurações impedem a consolidação:

A anotação do-not-disrupt

A anotação karpenter.sh/do-not-disrupt instrui o Modo Automático do EKS a preservar um nó enquanto o pod anotado estiver sendo executado nele. Isso evita que o nó seja consolidado, substituído ou encerrado, mesmo que seja subutilizado.

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

Alternativas a serem consideradas:

Orçamentos de interrupção de pod (PDBs)

PDBs que definem maxUnavailable: 0 ou minAvailable como a contagem de réplicas atuais bloqueiam efetivamente qualquer consolidação dos pods afetados. Revise os PDBs para garantir que eles permitam que pelo menos um pod seja interrompido de cada vez.

Use os limites de NodePool como teto de custo

Os limits de NodePool estabelecem um teto rígido para o total de recursos computacionais que um NodePool pode provisionar. Quando o limite é atingido, o Modo Automático do EKS impede a inicialização de novos nós para esse NodePool. Isso acontece mesmo que haja pods pendentes.

Use limits como uma barreira de proteção de custo, especialmente para NodePools que atendem a workloads não de produção, teste ou com picos, nos quais a escalação ilimitada não é apropriada.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
  limits:
    cpu: "500"
    memory: 1000Gi

Neste exemplo, o NodePool de ci-runners não podem exceder 500 vCPUs ou 1.000 GiB de memória total em todos os nós que ele provisiona. Os pods que excedem esse limite permanecem no estado Pending até que capacidade seja liberada.

Excluir famílias de instâncias para controle de custos

Por padrão, o Modo Automático do EKS seleciona entre muitos tipos de instância para maximizar a flexibilidade de agendamento. Para workloads que não exigem hardware especializado, restrinja as famílias de instâncias para evitar que tipos de instância dispendiosos sejam iniciados.

Excluir instâncias aceleradas

Se as workloads não precisam de recursos de GPU ou acelerador, exclua as famílias de instâncias aceleradas do NodePool. Isso evita cenários em que instâncias aceleradas são selecionadas durante restrições de capacidade.

spec:
  template:
    spec:
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]

Especificando apenas as categorias de instâncias otimizadas para computação, de uso geral e otimizadas para memória, você exclui da seleção as famílias de instâncias aceleradas (P, G, Inf, Trn) e outras famílias de instâncias especializadas.

Como a seleção de instâncias interage com as restrições de capacidade

O Modo Automático do EKS desprioriza os tipos de instância aceleradas e exóticas durante a seleção normal de instâncias. Porém, quando ocorrerem falhas de inicialização sustentadas, o Modo Automático do EKS é iniciado a partir de qualquer tipo de instância disponível restante para priorizar a disponibilidade para a workload. Por exemplo, isso acontece quando as cotas de serviço do EC2 se esgotam temporariamente para todos os tipos de instância preferenciais.

Para evitar esse comportamento de fallback, restrinja explicitamente os requisitos do NodePool apenas às categorias de instâncias de que a workload precisa. Quando os tipos preferenciais não estão disponíveis e nenhum outro tipo é permitido pela configuração do NodePool, os pods permanecem no estado Pending em vez de serem agendados em instâncias caras.

Limitar os tamanhos das instâncias

Além de restringir as famílias de instâncias, você pode limitar o tamanho máximo das instâncias do NodePool. A restrição do tamanho das instâncias limita a exposição ao risco de custo de qualquer nó individual que não possa ser consolidado. Por exemplo, um nó bloqueado por uma anotação do-not-disrupt não pode ser reduzido mesmo que sua workload seja pequena.

Use o rótulo eks.amazonaws.com/instance-cpu para limitar os tamanhos máximos das instâncias nos requisitos do NodePool:

requirements:
  - key: "eks.amazonaws.com/instance-cpu"
    operator: Lte
    values: ["32"]

Essa configuração impede que o Modo Automático do EKS inicie instâncias com mais de 32 vCPUs nesse NodePool.

Para identificar oportunidades de otimização em um cluster existente, analise as maiores instâncias em execução. Se a consolidação de nós grandes for consistentemente bloqueada, o custo por nó dessa capacidade ociosa será proporcionalmente maior.

Padrões recomendados para workloads com picos elevados

Pipelines de CI/CD, trabalhos em lote e executores efêmeros criam padrões de picos e ociosidade que exigem configuração específica para manter a eficiência de custos.

Padrões recomendados para workloads com picos elevados

Exemplo: NodePool executor de CI

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ci-runners
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: Lte
          values: ["32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
  limits:
    cpu: "500"
    memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Esta configuração:

Ciclo de vida e custo do nó

O Modo Automático do EKS substitui nós por meio de interrupções graduais quando eles se desviam da especificação desejada (por exemplo, após a liberação de uma nova AMI do Modo Automático) ou quando o vida útil do nó está chegando ao fim. Durante uma substituição gradual:

Para clusters com nós grandes ou com muitos nós, essa sobreposição pode criar aumentos de custo periódicos. Para minimizar o impacto:

Para obter mais informações sobre o ciclo de vida do nós, consulte Saiba mais sobre as instâncias gerenciadas do Modo Automático do Amazon EKS.