Grupos de nós de capacidade estática no modo automático do EKS

O modo automático do Amazon EKS oferece suporte a grupos de nós de capacidade estática que mantêm um número fixo de nós, independentemente da demanda de pods. Os grupos de nós com capacidade estática são úteis para workloads que demandam previsibilidade de capacidade, instâncias reservadas ou requisitos de conformidade específicos nos quais é necessário manter uma área de ocupação de infraestrutura consistente.

Ao contrário dos grupos de nós dinâmicos que escalam com base nas demandas de agendamento de pods, os grupos de nós de capacidade estática mantêm o número de nós que você configurou.

Exemplo básico

A seguir, apresentamos um exemplo de um grupo de nós simples com capacidade estática que mantém cinco nós:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: my-static-nodepool
spec:
  replicas: 5  # Maintain exactly 5 nodes

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m", "c"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b"]

  limits:
    nodes: 8

Configuração de um grupo de nós de capacidade estática

Para criar um grupo de nós de capacidade estática, defina o campo replicas em sua especificação de NodePool. O campo replicas define o número exato de nós que o grupo de nós manterá.

Restrições de grupos de nós de capacidade estática

Os grupos de nós de capacidade estática apresentam vários comportamentos e restrições importantes:

Restrições de configuração:

• Não é possível alternar modos: depois de definir o campo replicas em um grupo de nós, você não pode removê-lo. O grupo de nós não pode alternar entre os modos estático e dinâmico.

• Limites de recursos limitados: há suporte apenas para o campo limits.nodes na seção de limites. Os limites de CPU e de memória não são aplicáveis.

• Ausência do campo destinado ao peso: não é possível configurar o campo weight em grupos de nós com capacidade estática, já que a seleção de nós não ocorre por prioridade.

Comportamento operacional:

• Sem consolidação: os nós presentes em grupos de nós de capacidade estática não são considerados para consolidação com base na utilização.

• Operações de escalabilidade: as operações de escalabilidade ignoram os orçamentos de interrupção de nós, mas continuam respeitando os PodDisruptionBudgets.

• Substituição de nós: os nós ainda são substituídos por desvio (como atualizações de AMI) e expiração com base na sua configuração.

Escalabilidade de um grupo de nós de capacidade estática

É possível alterar o número de réplicas em um grupo de nós de capacidade estática usando o comando kubectl scale:

# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5

Ao reduzir a escala verticalmente, o modo automático do EKS encerra os nós de maneira controlada, respeitando os PodDisruptionBudgets e possibilitando o reagendamento dos pods em execução nos nós remanescentes.

Monitoramento dos grupos de nós de capacidade estática

Use os seguintes comandos para monitorar os grupos de nós de capacidade estática:

# View node pool status
kubectl get nodepool static-nodepool

# Get detailed information including current node count
kubectl describe nodepool static-nodepool

# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'

O campo status.nodes mostra o número atual de nós gerenciados pelo grupo de nós, que deve corresponder à sua contagem de replicas desejada em condições normais.

Exemplos de configuração

Grupo de nós de capacidade estática básico

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: basic-static
spec:
  replicas: 5

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a"]

  limits:
    nodes: 8  # Allow scaling up to 8 during operations

Capacidade estática com tipos de instância específicos

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: reserved-instances
spec:
  replicas: 20

  template:
    metadata:
      labels:
        instance-type: reserved
        cost-center: production
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.2xlarge"]  # Specific instance type
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b", "us-west-2c"]

  limits:
    nodes: 25

  disruption:
    # Conservative disruption for production workloads
    budgets:
      - nodes: 10%

Grupo de nós de capacidade estática em diversas zonas

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: multi-zone-static
spec:
  replicas: 12  # Will be distributed across specified zones

  template:
    metadata:
      labels:
        availability: high
    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: In
          values: ["8", "16"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b", "us-west-2c"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]

  limits:
    nodes: 15

  disruption:
    budgets:
      - nodes: 25%

Práticas recomendadas

Planejamento de capacidade:

• Defina limits.nodes como um valor superior a replicas para permitir a escalabilidade temporária durante as operações de substituição de nós.

• Considere a capacidade máxima necessária durante o desvio de nós ou as atualizações de AMI ao definir os limites.

Seleção de instâncias:

• Use tipos de instância específicos quando você tiver instâncias reservadas ou requisitos de hardware específicos.

• Evite requisitos excessivamente restritivos que possam limitar a disponibilidade de instâncias durante a escalabilidade.

Gerenciamento de interrupções:

• Configure orçamentos de interrupção apropriados para equilibrar a disponibilidade com as operações de manutenção.

• Considere a tolerância da aplicação para a substituição de nós ao definir as porcentagens do orçamento.

Como monitorar o:

• Monitore regularmente o campo status.nodes para garantir que sua capacidade desejada seja mantida.

• Configure alertas para quando a contagem real de nós divergir das réplicas desejadas.

Distribuição de zonas:

• Para obter alta disponibilidade, distribua a capacidade estática por várias zonas de disponibilidade.

• Quando você cria um grupo de nós de capacidade estática que abrange várias zonas de disponibilidade, o modo automático do EKS distribui os nós entre as zonas especificadas, mas não há garantia de que a distribuição será uniforme.

• Para obter uma distribuição previsível e uniforme entre as zonas de disponibilidade, crie grupos de nós de capacidade estática separados, cada um fixado a uma zona de disponibilidade específica usando o requisito topology.kubernetes.io/zone.

• Se você precisar de 12 nós distribuídos uniformemente em três zonas, crie três grupos de nós com quatro réplicas cada, em vez de um único grupo de nós com 12 réplicas abrangendo as três zonas.

Solução de problemas

Nós não atingem o número de réplicas desejado:

• Verifique se o valor de limits.nodes é suficiente

• Verifique se seus requisitos não estão restringindo excessivamente a seleção de instâncias

• Revise as cotas de serviço da AWS para os tipos de instância e regiões que você está usando

Substituição de nós demorando muito:

• Ajuste os orçamentos de interrupção para permitir mais substituições simultâneas

• Verifique se os PodDisruptionBudgets estão impedindo o encerramento dos nós

Encerramento inesperado de nós:

• Analise as configurações expireAfter e terminationGracePeriod

• Verifique se houve encerramentos manuais de nós ou eventos de manutenção da AWS