**Ayude a mejorar esta página** Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página. # Grupos de nodos con capacidad estática en el modo automático de EKS El modo automático de Amazon EKS admite grupos de nodos con capacidad estática que mantienen un número fijo de nodos independientemente de la demanda de los pods. Los grupos de nodos con capacidad estática son útiles para las cargas de trabajo que requieren una capacidad predecible, instancias reservadas o requisitos de cumplimiento específicos cuando es necesario mantener una huella de la infraestructura coherente. A diferencia de los grupos de nodos dinámicos que escalan en función de las exigencias de programación de los pods, los grupos de nodos con capacidad estática mantienen la cantidad de nodos que ha configurado. ## Configuración de un grupo de nodos con capacidad estática Para crear un grupo de nodos con capacidad estática, defina el campo `replicas` en la especificación de NodePool. El campo `replicas` define el número exacto de nodos que conservará el grupo de nodos. Consulte [Ejemplos](#static-capacity-examples) para saber cómo configurar `replicas`. ## Consideraciones de los grupos de nodos con capacidad estática Los grupos de nodos con capacidad estática tienen varias restricciones y comportamientos importantes: **Restricciones de configuración:** + **No se puede cambiar de modo**: una vez que haya configurado `replicas` en un grupo de nodos, no puede eliminarlo. El grupo de nodos no puede cambiar entre los modos estático y dinámico. + **Límites de recursos limitados**: solo se admite el campo `limits.nodes` en la sección de límites. Los límites de CPU y memoria no son aplicables. + **Campo sin peso**: el campo `weight` no se puede configurar en grupos de nodos con capacidad estática, ya que la selección de nodos no se basa en la prioridad. **Comportamiento operativo:** + **Sin consolidación**: los nodos de los grupos con capacidad estática no se tienen en cuenta para la consolidación en función del uso. + **Operaciones de escalado**: las operaciones de escalado eluden los presupuestos de interrupción de nodos, pero siguen respetando los PodDisruptionBudgets. + **Sustitución de nodos**: los nodos se siguen sustituyendo por desviación (como las actualizaciones de la AMI) y vencimiento en función de la configuración. ## Prácticas recomendadas **Planificación de la capacidad:** + Establezca un valor de `limits.nodes` superior a `replicas` para permitir el escalado temporal durante las operaciones de sustitución de nodos. + Tenga en cuenta la capacidad máxima necesaria durante la desviación de nodos o las actualizaciones de la AMI al establecer los límites. **Selección de instancias:** + Utilice tipos de instancias específicos cuando tenga instancias reservadas o requisitos de hardware específicos. + Evite los requisitos demasiado restrictivos que puedan limitar la disponibilidad de las instancias durante el escalado. **Administración de interrupciones:** + Configure los presupuestos de interrupciones adecuados para equilibrar la disponibilidad con las operaciones de mantenimiento. + Tenga en cuenta la tolerancia de la aplicación con respecto a la sustitución de nodos al establecer los porcentajes del presupuesto. **Supervisión de:** + Supervise el campo `status.nodes` periódicamente para garantizar que se mantenga la capacidad deseada. + Configure alertas para cuando el recuento real de nodos se desvíe de las réplicas deseadas. **Distribución en zonas:** + Distribuya la capacidad estática en varias zonas de disponibilidad para una mayor disponibilidad. + Al crear un grupo de nodos con capacidad estática que abarca varias zonas de disponibilidad, el modo automático de EKS distribuye los nodos entre las zonas especificadas, pero no se garantiza que la distribución sea uniforme. + Para lograr una distribución predecible y uniforme entre las zonas de disponibilidad, cree grupos de nodos con capacidad estática independientes, cada uno fijado a una zona de disponibilidad específica según el requisito `topology.kubernetes.io/zone`. + Si necesita 12 nodos distribuidos uniformemente en 3 zonas, cree 3 grupos de nodos con 4 réplicas cada uno, en lugar de un grupo de nodos con 12 réplicas en 3 zonas. ## Escalado de un grupo de nodos con capacidad estática Puede cambiar el número de réplicas de un grupo de nodos con capacidad estática mediante el comando `kubectl scale`: ``` # Scale down to 5 nodes kubectl scale nodepool static-nodepool --replicas=5 ``` Al reducir verticalmente, el modo automático de EKS terminará los nodos correctamente: respetará los PodDisruptionBudgets y permitirá reprogramar los pods en ejecución para los nodos restantes. ## Supervisión de grupos de nodos con capacidad estática Utilice los siguientes comandos para supervisar los grupos de nodos con capacidad 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}' ``` El campo `status.nodes` muestra el número actual de nodos administrados por el grupo de nodos, que debería coincidir con el recuento de `replicas` deseado en condiciones normales. ## Solución de problemas **Nodos que no llegan a las réplicas deseadas:** + Compruebe si el valor de `limits.nodes` es suficiente. + Compruebe que los requisitos no restrinjan demasiado la selección de instancias. + Revise las AWS Service Quotas para los tipos de instancias y las regiones que utiliza. **Sustitución del nodo que tarda demasiado tiempo:** + Ajuste los presupuestos de interrupción para permitir más sustituciones simultáneas. + Compruebe si los PodDisruptionBudgets impiden la terminación del nodo. **Terminación inesperada del nodo:** + Revise las configuraciones `expireAfter` y `terminationGracePeriod`. + Compruebe si hay terminaciones manuales del nodo o eventos de mantenimiento de AWS. ## Ejemplos ### Grupo de nodos básico con capacidad estática ``` 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 ``` ### Capacidad estática con tipos de instancias 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 nodos con capacidad estática multizona ``` 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% ``` ### Capacidad estática con reserva de capacidad En el siguiente ejemplo se muestra cómo utilizar un grupo de nodos con capacidad estática con una reserva de capacidad de EC2. Para obtener más información sobre el uso de las reservas de capacidad de EC2 con el modo automático de EKS, consulte [Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS](auto-odcr.md). `NodeClass` que define `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` que hace referencia al `NodeClass` anterior y utiliza `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'] ```