**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.
# Configuración avanzada del plano de control de Kubernetes
## Descripción general
Amazon EKS administra el plano de control de Kubernetes del clúster, lo que incluye el servidor de la API, el planificador y el administrador de controladores. EKS ejecuta estos componentes con la configuración de Kubernetes ascendente predeterminada, que funciona bien para la mayoría de las cargas de trabajo, y no es necesario cambiarla para la mayoría de los clústeres. Sin embargo, algunas cargas de trabajo se benefician de diferentes configuraciones del plano de control. Es posible que desee que el planificador agrupe los pods en menos nodos para reducir los costos de procesamiento, retenga los eventos de Kubernetes durante un periodo más corto para limitar el crecimiento de las bases de datos de clústeres (etcd) o evalúe las decisiones de escalado automático con más frecuencia.
Con la configuración avanzada del plano de control de Kubernetes, puede establecer estos parámetros directamente en el clúster. EKS los aplica al plano de control y el clúster continúa funcionando con las mismas características de disponibilidad y rendimiento.
Se trata de configuraciones avanzadas. Cada parámetro de configuración cambia el comportamiento de un componente principal del plano de control de Kubernetes para las cargas de trabajo que se ejecutan en el clúster y el valor correcto depende de la carga de trabajo. Antes de cambiar un parámetro, lea las consideraciones correspondientes en las siguientes secciones y pruebe el cambio en un clúster que no sea de producción.
Puede establecer parámetros de configuración avanzada del plano de control cuando cree un clúster o actualizarlos en un clúster existente en cualquier momento. Esta capacidad utiliza las operaciones existentes `CreateCluster` y `UpdateClusterConfig` con parámetros nuevos, por lo que puede configurarla mediante la Consola de administración de AWS, la AWS CLI, los AWS SDK o AWS CloudFormation. EKS valida cada configuración antes de aplicarla y registra los cambios en AWS CloudTrail.
Los parámetros avanzados del plano de control se aplican a todo el clúster y a todas las cargas de trabajo que se ejecutan en él. No puede asignarlos a espacios de nombres o cargas de trabajo individuales. EKS restringe cada parámetro a un intervalo validado. Los valores admitidos para cada parámetro se enumeran junto con ese parámetro en la siguiente sección.
## Parámetros del plano de control de Kubernetes admitidos
Amazon EKS admite los siguientes parámetros. Cada parámetro pertenece a un componente del plano de control y se establece mediante el campo de configuración de ese componente: `kubeSchedulerConfig`, `kubeControllerManagerConfig` o `kubeApiServerConfig`.
| Componente | Parámetro | Valores admitidos | Predeterminado | Requiere que el plano de control esté aprovisionado |
| --- | --- | --- | --- | --- |
| kube-scheduler | `nodeResourcesFit.scoringStrategy` | `LeastAllocated`, `MostAllocated` | `LeastAllocated`, con `cpu: 1` y `memory: 1` | No |
| kube-controller-manager | `horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod` | `10s` De a `15s` | `15s` (segundos) | Sí |
| kube-controller-manager | `podGcControllerConfig.terminatedPodGcThreshold` | `10000` De a `12500` | `12500` | Sí |
| kube-apiserver | `eventTtl` | `10m` De a `60m` | `60m` (minutos) | No |
| kube-apiserver | `serviceNodePortRange` | `minPort` y `maxPort` entre `10260` y `32767` | `minPort: 30000`, `maxPort: 32767` | No |
Los valores predeterminados y admitidos en este tema se aplican a la versión de Kubernetes (EKS v1.31 y versiones posteriores) disponible en el momento de la publicación y pueden cambiar en versiones posteriores. La operación `DescribeClusterVersions` informa de los valores predeterminados y admitidos actuales para cada parámetro y versión de Kubernetes, así que úsela como origen de información fiable si administra los clústeres en varias versiones o automatiza la configuración de los clústeres. Para obtener más información, consulte [Configuración de parámetros avanzados del plano de control de Kubernetes](control-plane-configuration-getting-started.md).
En las siguientes secciones, se describe cada parámetro, cuándo cambiarlo y qué se debe tener en cuenta antes de hacerlo.
### Planificador: recursos de nodos adecuados
El planificador asigna los pods a los nodos en dos fases. Primero filtra los nodos que pueden ejecutar un pod, luego puntúa a los candidatos restantes y coloca el pod en el nodo con la puntuación más alta. El complemento `nodeResourcesFit` comprueba si un nodo tiene los recursos que solicita un pod y puntúa los nodos según una estrategia de puntuación.
| Campo | Descripción | Valores admitidos | Predeterminado |
| --- | --- | --- | --- |
| `nodeResourcesFit.scoringStrategy.type` | La estrategia que se utiliza para puntuar los nodos mediante la asignación de recursos. | `LeastAllocated`, `MostAllocated` | `LeastAllocated` |
| `nodeResourcesFit.scoringStrategy.resources` | Los recursos que se tienen en cuenta al puntuar, cada uno con una ponderación relativa. | `cpu`, `memory`, `nvidia.com/gpu`, `aws.amazon.com/neuron`, `aws.amazon.com/neuroncore`. Ponderaciones de `1` a `100`. | `cpu: 1`, `memory: 1` |
`LeastAllocated` prefiere los nodos con menor asignación de recursos, lo que distribuye los pods entre los nodos del clúster y deja espacio libre en cada nodo. Este es el comportamiento predeterminado de Kubernetes y es una buena opción si quiere que la capacidad disponible en todos los nodos absorba el crecimiento de los pods existentes.
`MostAllocated` prefiere los nodos que ya tienen una mayor asignación de recursos, lo que agrupa los pods en menos nodos. Como las cargas de trabajo ocupan menos capacidad total, puede ejecutarlas en un número menor de nodos y reducir el gasto de computación. Con el tiempo, este comportamiento de empaquetado mantiene los nodos poco utilizados libres de nuevas cargas de trabajo, por lo que los grupos de nodos que admiten la consolidación pueden eliminarlos.
EKS admite las estrategias `LeastAllocated` y `MostAllocated`. La estrategia `RequestedToCapacityRatio` de Kubernetes ascendente no se admite.
#### Ponderaciones de recursos
Si lo desea, puede especificar una matriz `resources` con ponderaciones personalizadas para influir en los recursos que más importan al tomar decisiones de puntuación. Esto resulta útil cuando un recurso específico es la limitación del clúster. Por ejemplo, en los clústeres en los que los aceleradores (GPU) son un recurso escaso, si la ponderación de `nvidia.com/gpu` es superior a la de la CPU y la memoria, los pods que solicitan el acelerador se concentran en nodos que ya están parcialmente ocupados.
Las ponderaciones son relativas, no absolutas. Configurar `cpu: 100` y `memory: 1` no hace que el programador ignore la memoria. En la fórmula de puntuación, pondera la CPU 100 veces más que la memoria. Si todos los nodos candidatos tienen una disponibilidad de CPU idéntica, la CPU ya no los distingue y la puntuación recae efectivamente en la memoria.
Omitir un recurso no es lo mismo que asignarle una ponderación baja. Al especificar una matriz `resources`, solo se puntúan los recursos que se enumeran. Los recursos que omita se excluyen por completo del cálculo. Por ejemplo, `cpu: 100` sin entrada de `memory` puntúa los nodos solo en función de la CPU y la disponibilidad de memoria no influye en el resultado. Para mantener un recurso en el cálculo y, al mismo tiempo, reducir su influencia, inclúyalo con una ponderación baja en lugar de omitirlo.
Ponderar un recurso de acelerador, como `nvidia.com/gpu`, solo afecta a la puntuación de los pods que realmente declaran `resources.requests` para ese recurso. La ponderación de acelerador no influye en los pods que no solicitan aceleradores.
Los tres recursos de acelerador son recursos ampliados de Kubernetes, es decir, recursos de nodo que un complemento anuncia a Kubernetes en lugar de estar integrados de forma nativa. Solo se puntúan cuando un complemento de dispositivo los anuncia al kubelet a través de la API del complemento de dispositivo. Los recursos que un controlador de dispositivo pone a disposición en un nodo por sí solo no son visibles para el complemento `nodeResourcesFit` y no se puntúan. Los recursos administrados mediante la asignación dinámica de recursos (DRA) se programan a través de un complemento independiente y no forman parte de la puntuación de `nodeResourcesFit`, por lo que habilitar la DRA no cambia el comportamiento de este parámetro. Para obtener más información sobre la configuración de los complementos para dispositivos de NVIDIA, consulte [DRA de NVIDIA y complemento para dispositivos](https://docs.aws.amazon.com/eks/latest/userguide/device-management-nvidia-dra-device-plugin.html). Para obtener más información sobre la configuración de los dispositivos Neuron, consulte [Administración de dispositivos Neuron](https://docs.aws.amazon.com/eks/latest/userguide/device-management-neuron.html).
La estrategia de puntuación es una de las varias entradas que el planificador utiliza para calcular una puntuación para cada nodo. Para obtener más información sobre cómo el planificador filtra y puntúa los nodos, consulte [Scheduling Framework](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/) en la documentación de Kubernetes.
#### Consideraciones para la estrategia de puntuación
+ **Los pods en ejecución no se desplazan.** El planificador de Kubernetes nunca reubica un pod que ya esté en ejecución. El cambio de la estrategia de puntuación solo afecta a las decisiones de programación futuras, y la ubicación actual de los pods es permanente. Para reequilibrar los pods que ya están en ejecución, desactívelos o reinícielos.
+ **El comportamiento de filtrado no cambia.** La estrategia de puntuación solo afecta a la fase de puntuación, en la que el planificador clasifica los nodos por preferencia. La fase de filtrado, que determina si un pod puede ejecutarse en un nodo, no ha cambiado. Un pod que no cabe en un nodo sigue sin programarse allí según ninguna de las estrategias.
+ **`MostAllocated` concentra el radio de acción.** Si las cargas de trabajo se agrupan en menos nodos, se ven afectados más pods a la vez si un nodo deja de funcionar, se retira una instancia o se interrumpe una zona de disponibilidad. Con una alta tasa de rotación de pods, los nodos densamente poblados también se llenan más rápido, lo que puede dejar los pods en estado `Pending` mientras se aprovisiona nueva capacidad.
+ **El planificador y la administración de nodos funcionan en diferentes capas.** La estrategia de puntuación influye en la ubicación de los pods entre los nodos que ya pueden ejecutarlos. No cambia la forma en que el modo automático de EKS o Karpenter aprovisionan o eliminan los nodos. Valide el comportamiento combinado de la carga de trabajo antes de cambiar la configuración.
### Administrador de controladores: periodo de sincronización del Escalador automático de pods horizontales
El administrador de controladores ejecuta los controladores de Kubernetes que llevan el estado del clúster al estado deseado, incluido el controlador del Escalador automático de pods horizontales (HPA). En cada ciclo, el controlador del HPA recupera las métricas de cada objeto `HorizontalPodAutoscaler`, calcula el recuento de réplicas deseado y actualiza la carga de trabajo de destino si el recuento ha cambiado.
| Campo | Descripción | Valores admitidos | Predeterminado |
| --- | --- | --- | --- |
| `horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod` | Con qué frecuencia evalúa el controlador de HPA las decisiones de escalado. | `10s` De a `15s` | `15s` |
Al acortar el periodo de sincronización, las cargas de trabajo se escalan antes, después del aumento de la carga, en lugar de esperar un ciclo completo antes de agregar capacidad.
Para configurar este parámetro, el clúster debe estar en el plano de control aprovisionado de Amazon EKS. Al acortar el intervalo, se aumenta la velocidad a la que el controlador de HPA concilia todos los objetos `HorizontalPodAutoscaler` del clúster, lo que genera más solicitudes de API. Cada conciliación consume al menos una solicitud de API, mientras que una conciliación que cambia el recuento de réplicas consume dos más. Los clústeres del plano de control aprovisionado asignan previamente la capacidad del plano de control para que siempre esté lista para las cargas de trabajo exigentes, de modo que se dimensionan para absorber esa carga adicional. Para obtener más información, consulte [Plano de control aprovisionado de Amazon EKS](eks-provisioned-control-plane.md).
#### Efecto en la cantidad de objetos de HPA compatibles con el clúster
+ **Al acortar el periodo de sincronización, se reduce la cantidad de objetos `HorizontalPodAutoscaler` que el plano de control puede conciliar** según lo programado, ya que el controlador tiene menos tiempo para trabajar en la misma cola. Al reducir el periodo de `15s` a `10s`, se reduce el número de objetos admitidos en aproximadamente un tercio. Antes de acortar el periodo de sincronización, cuente los objetos `HorizontalPodAutoscaler` del clúster y confirme que el periodo más corto continúe siendo compatible con ese recuento en el nivel de escalado:
```
kubectl get hpa --all-namespaces --no-headers | wc -l
```
+ **EKS no valida el periodo de sincronización mediante la comparación con el recuento de objetos del HPA.** El cambio de configuración se efectúa correctamente incluso si el clúster ya tiene más objetos `HorizontalPodAutoscaler` de los que admite el periodo más corto. Verifique el recuento antes de hacer el cambio.
+ **Si se supera el recuento admitido, se degrada el escalado automático de forma silenciosa.** Si el controlador no puede trabajar con todos los objetos dentro del periodo, algunos objetos no se concilian según lo programado. EKS no emite ninguna alarma ni ningún evento de Kubernetes para este estado, y el síntoma es que el escalado automático responde más despacio de lo esperado, es decir, el efecto contrario al deseado. Si observa un retraso en el escalado después de acortar el periodo de sincronización, devuelva el parámetro al valor predeterminado de `15s`.
+ **El periodo de sincronización se aplica a todos los objetos del HPA del clúster.** No puede establecer distintos periodos de sincronización para distintos objetos o espacios de nombres.
### Administrador de controladores: umbral de recopilación de elementos no utilizados de pods terminados
El administrador de controladores ejecuta el recopilador de elementos no utilizados de pods terminados (el controlador GC de pods). Este controlador elimina los pods terminados (los pods en la fase `Succeeded` o `Failed`) una vez que el número de pods terminados del clúster supere un umbral. El parámetro `terminatedPodGcThreshold` establece ese umbral.
| Campo | Descripción | Valores admitidos | Predeterminado |
| --- | --- | --- | --- |
| `podGcControllerConfig.terminatedPodGcThreshold` | El número de pods terminados que pueden existir antes de que el recopilador de elementos no utilizados de pods terminados comience a eliminar los pods terminados. | `10000` De a `12500` | `12500` |
El recopilador de elementos no utilizados funciona en un ciclo fijo de 20 segundos. Cuando se reduce el umbral, el recopilador comienza a eliminar forzosamente los pods terminados más antiguos en el siguiente ciclo hasta que el recuento alcance el nuevo umbral.
Para configurar este parámetro, el clúster debe estar en el plano de control aprovisionado de Amazon EKS. Si se reduce el umbral, se incrementa el trabajo de recopilación de elementos no utilizados que el controlador lleva a cabo en la base de datos del clúster (etcd). Cada recopilación completada permite consultar, procesar y eliminar más pods terminados. Los clústeres del plano de control aprovisionado asignan previamente la capacidad del plano de control para que siempre esté lista para las cargas de trabajo exigentes, de modo que pueden absorber esa carga adicional. Para obtener más información, consulte [Plano de control aprovisionado de Amazon EKS](eks-provisioned-control-plane.md).
#### Consideraciones sobre el umbral de recopilación de elementos no utilizados de pods finalizados
+ **Al reducir el umbral, se eliminan inmediatamente los pods terminados sobrantes.** Si reduce el umbral (por ejemplo, de `12500` a `10000`), el controlador de recopilación de elementos no utilizados comenzará a forzar la eliminación de los pods terminados más antiguos en su siguiente ciclo. El controlador continúa hasta que el número de pods terminados alcance el nuevo umbral. La reducción no es gradual.
+ **El umbral se aplica a todos los pods terminados, independientemente del propietario.** Afecta a los pods en la fase `Succeeded` o `Failed` tanto si son propiedad de un trabajo, CronJob o implementación como si son independientes. En la práctica, los pods de trabajo y CronJob son los que más contribuyen al recuento de pods terminados.
+ **Si se reduce el umbral, se reduce el plazo de depuración.** Los pods completados y con errores desaparecen de `kubectl get pods` y `kubectl logs` antes. La automatización que inspecciona los códigos de salida o los registros de los pods de trabajo terminados tiene un plazo de operación más pequeño.
+ **El umbral es una configuración de clúster global.** No puede configurarlo por espacio de nombres ni por trabajo. Para controlar el ciclo de vida de los pods de un trabajo individual, use `ttlSecondsAfterFinished` en ese trabajo.
### Servidor de la API: retención de eventos
El servidor de la API es la interfaz del plano de control de Kubernetes. Funciona con la API de Kubernetes y conserva el estado del clúster en la base de datos del clúster (etcd). Kubernetes registra los eventos para describir lo que ocurre en el clúster, como las decisiones de programación de pods, la extracción de imágenes, los errores en las comprobaciones de estado y las acciones de escalado.
| Campo | Descripción | Valores admitidos | Predeterminado |
| --- | --- | --- | --- |
| `eventTtl` | Cuánto tiempo retiene el servidor de la API los eventos de Kubernetes antes de eliminarlos. | `10m` De a `60m` | `60m` |
Los clústeres que ejecutan cargas de trabajo con un alto índice de rotación, como los trabajos por lotes a gran escala, las cargas de trabajo de IA, las canalizaciones de CI/CD y los CronJobs frecuentes, acumulan miles de eventos rápidamente. Cada evento retenido consume espacio en la base de datos del clúster, que compite con los objetos que el clúster necesita para ejecutarse, y una gran recopilación de eventos hace que las operaciones de la lista del servidor de la API sean más costosas de gestionar.
Al reducir la retención de eventos, se borran antes estos datos de diagnóstico efímeros, lo que reduce la presión de almacenamiento de la base de datos del clúster y mejora los tiempos de respuesta del servidor de la API para consultas con muchos eventos.
Un periodo de retención más corto es una buena opción cuando:
+ El clúster ejecuta cargas de trabajo por lotes, de CI/CD, de IA o de CronJob que generan un gran volumen de eventos.
+ Observa que el almacenamiento de la base de datos del clúster crece hasta alcanzar su límite.
+ Confía en un sistema externo para capturar eventos de forma duradera y no depende de `kubectl get events` para la depuración histórica.
#### Consideraciones para la retención de eventos
+ **Un cambio se aplica solo a los eventos nuevos.** Kubernetes establece la caducidad de un evento cuando se crea el evento. Los eventos que ya existen mantienen el periodo de retención que estaba vigente en el momento de su creación y caducan según ese calendario. Acortar `eventTtl` no acorta la vida útil de los eventos que ya están en la base de datos del clúster, por lo que la reducción del almacenamiento se aplica gradualmente según caduquen los eventos existentes.
+ **Los eventos eliminados no se pueden recuperar.** Después de que Kubernetes elimine un evento, desaparece de forma permanente. Si acorta la retención más de lo previsto y pierde el historial de eventos, no hay forma de restaurarlo. Compruebe que todo aquello de lo que dependa para la solución de problemas se capture fuera del clúster antes de acortar este valor.
+ **Los eventos pueden persistir un poco más allá del periodo configurado.** En determinadas condiciones, la caducidad de un evento puede prolongarse más allá del valor que haya configurado debido a la renovación del arrendamiento de etcd que podría producirse durante la elección del líder del plano de control.
+ **Plazo de depuración reducido.** Un periodo de retención más corto reduce el plazo que se muestra con `kubectl get events` y `kubectl describe`. Las herramientas de supervisión que extraen los eventos del clúster tienen menos datos disponibles. Elija un valor que equilibre la eficiencia del almacenamiento con el flujo de trabajo de depuración.
+ **La configuración abarca todo el clúster.** La retención se aplica a todos los eventos, incluida la programación de pods, las condiciones de nodos y los eventos de escalado, en todos los espacios de nombres. No puede establecer periodos de retención diferentes por espacio de nombres.
### Servidor de la API: intervalo de puertos de nodos de servicio
Kubernetes asigna un puerto de este intervalo en cada nodo para cada servicio que lo necesite. Esto incluye los servicios de tipo `NodePort` y, de forma predeterminada, los servicios de tipo `LoadBalancer`.
| Campo | Descripción | Valores admitidos | Predeterminado |
| --- | --- | --- | --- |
| `serviceNodePortRange.minPort` | El puerto más bajo del intervalo. | `10260` De a `32767` | `30000` |
| `serviceNodePortRange.maxPort` | El puerto más alto del intervalo. | `10260` De a `32767` | `32767` |
`minPort` debe ser menor o igual que `maxPort`. Amazon EKS rechaza una configuración en la que `minPort` es mayor que `maxPort`.
Al cambiar el intervalo, puede alinear la asignación de puertos de nodos con las políticas de red y firewall que su organización ya aplica. La ampliación del intervalo también aumenta la cantidad de servicios que puede admitir un solo clúster. Este parámetro resulta especialmente útil durante las migraciones. Las aplicaciones que se desplazan a Amazon EKS y los clientes que las llaman suelen esperar servicios en puertos fijos específicos. Cuando esos puertos se encuentran fuera del intervalo predeterminado, las opciones habituales son modificar la aplicación o colocar un proxy delante de ella. Al alinear el intervalo con los puertos que ya utilizan sus aplicaciones, se elimina ese trabajo, por lo que puede mover las cargas de trabajo a EKS sin tener que volver a escribirlas ni agregar componentes de red para su mantenimiento.
#### Por qué el intervalo está limitado a 10 260 y 32 767
El límite inferior de `10260` mantiene la asignación de `NodePort` libre de puertos que los componentes del sistema de Kubernetes de los nodos ya utilizan, incluidos el puerto de estado de kubelet (`10248`) y el puerto de comprobación de estado de kube-proxy (`10256`).
El límite superior de `32767` mantiene el intervalo alejado del intervalo de puertos efímeros de Linux, que normalmente comienza en `32768`. Si `NodePort` se encuentra dentro del intervalo efímero, el kernel podría seleccionar ese puerto para una conexión saliente desde el nodo y entrar en conflicto con el servicio.
#### Consideraciones sobre el intervalo de puertos de nodos de servicio
+ **Los servicios existentes mantienen sus puertos asignados.** Si reduce el intervalo, los servicios que ya tienen un puerto fuera del nuevo intervalo continuarán funcionando y kube-proxy continuará dirigiendo el tráfico hacia ellos. Amazon EKS no reasigna los puertos de los servicios existentes cuando cambia el intervalo.
+ **Al volver a crear un servicio, se reasigna su puerto.** Si un servicio que contiene un puerto fuera del intervalo se elimina y se vuelve a crear, ese puerto ya no se puede asignar. Planifíquelo antes de reducir el intervalo del que dependen los servicios existentes, especialmente si el proceso de implementación vuelve a crear los servicios en lugar de actualizarlos.
+ **Se rechazan las nuevas asignaciones que estén fuera del intervalo.** Al crear o actualizar un servicio que requiere un puerto fuera del intervalo configurado, se produce un error de validación por parte del servidor de la API.
+ **Los puertos especificados de forma explícita también se validan.** Si un servicio especifica un valor `nodePort` directamente en lugar de permitir que Kubernetes asigne uno, ese puerto debe estar dentro del intervalo configurado. Se rechaza una solicitud de puerto estático fuera del intervalo, incluso si el mismo puerto era válido en un intervalo más amplio que configuró anteriormente.
+ **El intervalo abarca todo el clúster.** No puede configurar diferentes intervalos para distintos espacios de nombres.
Antes de cambiar este parámetro, confirme que los grupos de seguridad y las ACL de red permiten el tráfico en el nuevo intervalo y que este no entre en conflicto con los puertos utilizados por otro software en los nodos.
## Consideraciones
Revise lo siguiente antes de configurar los parámetros avanzados del plano de control.
+ **Ámbito de todo el clúster:** los parámetros del plano de control se aplican a todo el clúster y a todas las cargas de trabajo que se ejecutan en él. No puede asignarlos a espacios de nombres o cargas de trabajo individuales. Pruebe los cambios de parámetros en un clúster que no sea de producción antes de aplicarlos a la producción.
+ **Se requiere un plano de control aprovisionado para el periodo de sincronización del Escalador automático de pods horizontales y el umbral de recopilación de elementos no utilizados de pods finalizados:** los parámetros `horizontalPodAutoscalerSyncPeriod` y `terminatedPodGcThreshold` solo están disponibles en los clústeres que utilizan el plano de control aprovisionado de Amazon EKS. Amazon EKS restringe los parámetros que aumentan considerablemente el consumo de recursos del plano de control a los clústeres con capacidad del plano de control preasignada. Se produce un error al configurar cualquiera de los parámetros en un clúster en el modo de plano de control estándar. Para usarlos, desplace antes el clúster a un nivel de escalado del plano de control aprovisionado. Para obtener más información, consulte [Plano de control aprovisionado de Amazon EKS](eks-provisioned-control-plane.md).
+ **Restricción de salida para el periodo de sincronización del Escalador automático de pods horizontales y el umbral de recopilación de elementos no utilizados de pods finalizados:** si `horizontalPodAutoscalerSyncPeriod` o `terminatedPodGcThreshold` se establece en un valor distinto del predeterminado, no puede desplazar el plano de control del clúster del modo aprovisionado al modo estándar. Para volver al modo estándar, restablezca antes los valores predeterminados de los dos parámetros (`15s` y `12500`) y, a continuación, cambie el nivel de escalado del plano de control a `standard`.
+ **Regreso a los valores predeterminados:** Amazon EKS no proporciona una operación de restablecimiento específica y, si se omite un campo de una actualización, se mantiene su valor actual en lugar de borrarlo. Para devolver un parámetro a su valor predeterminado, configúrelo explícitamente en el valor predeterminado. Recupere el valor predeterminado con `DescribeClusterVersions` para la versión de Kubernetes que ejecute el clúster. Para obtener más información, consulte [Configuración de parámetros avanzados del plano de control de Kubernetes](control-plane-configuration-getting-started.md).
+ **Semántica de las actualizaciones:** las actualizaciones se combinan con la configuración existente. Solo cambiarán los campos que especifique, mientras que los campos que omita conservarán sus valores actuales. Esto se aplica tanto a todos los componentes como en un solo componente. Por ejemplo, una actualización que especifique solo la configuración del programador deja sin cambios la configuración del administrador del controlador y del servidor de la API.
+ **Visualización de la configuración actual:** la operación `describe-cluster` devuelve la configuración completa que se está ejecutando en el plano de control, incluidos los parámetros que no se han personalizado y sus valores predeterminados.
+ **Los valores predeterminados y admitidos pueden cambiar entre las versiones de Kubernetes:** los valores documentados en este tema se aplican a las versiones de Kubernetes disponibles en el momento de la publicación. Use `DescribeClusterVersions` para recuperar los valores predeterminados y admitidos actuales para cada parámetro y versión de Kubernetes. Consulte [Configuración de parámetros avanzados del plano de control de Kubernetes](control-plane-configuration-getting-started.md).
+ **Los clústeres existentes no cambian:** Amazon EKS no cambia el comportamiento de los clústeres existentes. Todos los clústeres continúan ejecutándose con los valores de parámetros predeterminados hasta que establezca un parámetro de forma explícita.
+ **Los cambios no se aplican al instante:** un cambio de configuración no surte efecto cuando se devuelve `UpdateClusterConfig`. Amazon EKS aplica la nueva configuración mediante una actualización progresiva del plano de control, de modo que debe esperar varios minutos antes de que los cambios se apliquen. El clúster vuelve al estado `ACTIVE` cuando se completa la actualización. Puede hacer un seguimiento del progreso mediante la operación [DescribeUpdate](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeUpdate.html) o bloquearlo hasta que se complete el cambio mediante `aws eks wait cluster-active`.
+ **Auditabilidad:** Amazon EKS valida cada configuración antes de aplicarla y registra los cambios de configuración en AWS CloudTrail.
+ **Compatibilidad con herramientas:** la configuración avanzada del plano de control de Kubernetes está disponible a través de la Consola de administración de AWS, eksctl, la AWS CLI, la API de Amazon EKS, AWS CloudFormation y el AWS CDK en el momento del lanzamiento. La compatibilidad con Controladores de AWS para Kubernetes (ACK) y Terraform estará disponible próximamente.
+ **Compatibilidad con versiones de Kubernetes:** la configuración avanzada del plano de control de Kubernetes se admite en los clústeres nuevos y existentes que ejecutan la versión 1.31 o posterior de Kubernetes.
+ **Compatibilidad con regiones de AWS:** la configuración avanzada del plano de control de Kubernetes está disponible en todas las regiones comerciales de AWS, las regiones de AWS GovCloud (EE. UU.) y las regiones de AWS China en las que Amazon EKS está disponible.
+ **Precios:** la configuración de los parámetros del plano de control no conlleva ningún cargo adicional. El uso de `horizontalPodAutoscalerSyncPeriod` requiere un plano de control aprovisionado, que se factura según la tarifa por hora correspondiente al nivel de escalado. Para obtener más información, consulte los [precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).
## Siguientes pasos
+ [Configuración de parámetros avanzados del plano de control de Kubernetes](control-plane-configuration-getting-started.md): configure y visualice los parámetros del plano de control mediante la AWS CLI y la Consola de administración de AWS.
+ [Plano de control aprovisionado de Amazon EKS](eks-provisioned-control-plane.md): asigne previamente la capacidad del plano de control para obtener un alto rendimiento predecible.