**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. # 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. ## 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á. Veja [Exemplos](#static-capacity-examples) para saber como configurar `replicas`. ## Considerações sobre o conjunto 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**: nós em conjuntos de capacidade estática não são considerados para consolidaçã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. ## 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. ## 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. ## 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 ## Exemplos ### 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% ``` ### Capacidade estática com reserva de capacidade O exemplo a seguir mostra como usar um pool de nós de capacidade estática com uma Reserva de Capacidade do EC2. Para obter mais informações sobre como usar as Reservas de Capacidade do EC2 com o Modo Automático do EKS, consulte [Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS](auto-odcr.md). `NodeClass` definindo `capacityReservationSelectorTerms` ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: capacity-reservation-nodeclass spec: role: AmazonEKSNodeRole securityGroupSelectorTerms: - id: sg-0123456789abcdef0 subnetSelectorTerms: - id: subnet-0123456789abcdef0 capacityReservationSelectorTerms: - id: cr-0123456789abcdef0 ``` `NodePool` referenciando `NodeClass` acima e usando `karpenter.sh/capacity-type: reserved`. ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: static-capacity-reservation-nodepool spec: replicas: 5 limits: nodes: 8 # Allow scaling up to 8 during operations template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: capacity-reservation-nodeclass requirements: - key: karpenter.sh/capacity-type operator: In values: ['reserved'] ```