Versiones de Amazon EKS Kubernetes - Amazon EKS

Versiones de Amazon EKS Kubernetes

El proyecto Kubernetes evoluciona rápidamente con nuevas características, actualizaciones de diseño y corrección de errores. La comunidad publica versiones secundarias de Kubernetes nuevas, como la versión 1.21, que se encuentran disponibles con carácter general aproximadamente cada tres meses y cuyo soporte es de aproximadamente doce meses después de su lanzamiento.

Versiones de Amazon EKS Kubernetes disponibles

Las siguientes versiones de Kubernetes se encuentran disponibles actualmente para los clústeres nuevos en Amazon EKS:

  • 1.21.2

  • 1.20.7

  • 1.19.8

  • 1.18.16

  • 1.17.17

  • 1.16.15

A menos que la aplicación requiera una versión específica de Kubernetes, recomendamos que elija la última versión de Kubernetes disponible admitida por Amazon EKS para sus clústeres. Cuando haya nuevas versiones de Kubernetes disponibles en Amazon EKS, le recomendamos que actualice proactivamente los clústeres para que utilicen la versión más reciente disponible. Para obtener más información, consulte Actualización de un clúster. Para obtener más información, consulte Calendario de lanzamiento de Amazon EKS Kubernetes y Preguntas frecuentes y soporte de versión de Amazon EKS.

Kubernetes 1.21

Kubernetes 1.21 ya se encuentra disponible en Amazon EKS. Para obtener más información sobre Kubernetes 1.21, consulte el anuncio del lanzamiento oficial.

Important

  • La compatibilidad con redes de doble pila (direcciones IPv4 e IPv6) en pods, servicios y nodos ha alcanzado el estado beta. Sin embargo, Amazon EKS y la CNI de Amazon VPC no admiten redes de doble pila actualmente.

  • Ahora, la AMI de Amazon Linux 2 optimizada para Amazon EKS contiene un indicador de proceso de arranque con el fin de habilitar el tiempo de ejecución de containerd como una alternativa a Docker. Este indicador permite la preparación para la eliminación de Docker como un tiempo de ejecución compatible en el próximo lanzamiento de Kubernetes. Para obtener más información, consulte Habilitar el indicador del proceso de arranque en tiempo de ejecución de containerd. Esto se puede rastrear a través del plan de desarrollo de contenedores en Github.

  • Los grupos de nodos administrados admiten el expansor de prioridades del Cluster Autoscaler.

    Los grupos de nodos administrados recién creados en clústeres de Amazon EKS v1.21 utilizan el siguiente formato para el nombre del grupo de Auto Scaling subyacente:

    eks-<managed-node-group-name>-<uuid>

    Esto permite el uso de la característica de expansor de prioridad del Cluster Autoscaler para escalar los grupos de nodos en función de las prioridades que define el usuario. Un caso de uso común es preferir escalar grupos de nodos de spot en lugar de bajo demanda. Este cambio de comportamiento resuelve el problema del plan de desarrollo de contenedores n.º 1304.

Las siguientes características de Kubernetes ya son compatibles con los clústeres de Amazon EKS de Kubernetes 1.21:

  • Ahora, CronJobs (anteriormente ScheduledJobs) se ha ajustado al estado estable. Esto permite a los usuarios realizar acciones programadas de forma regular, como copias de seguridad y generación de informes.

  • Ahora, los Secretos inmutables y ConfigMaps se han ajustado a un estado estable. Se ha agregado un campo inmutable nuevo a estos objetos para rechazar los cambios. Este rechazo protege al clúster de actualizaciones que podrían interrumpir las aplicaciones involuntariamente. Debido a que estos recursos son inmutables, kubelet no observa ni sondea los cambios, lo que reduce la carga de kube-apiserver y mejora la escalabilidad y el rendimiento.

  • Ahora, el Apagado correcto de nodos se ha ajustado al estado beta. Esto permite que el kubelet sea consciente del apagado del nodo y termine correctamente los pods de ese nodo. Antes de esta característica, cuando un nodo se apagaba, sus pods no seguían el ciclo de vida de terminación esperado lo que generaba problemas de carga de trabajo. Ahora, el kubelet puede detectar el apagado inminente del sistema a través de systemd, e informar a los pods en ejecución para que terminen de forma correcta.

  • Los pods con varios contenedores ahora pueden utilizar el comentario kubectl.kubernetes.io/default-container a fin de tener un contenedor preseleccionado para los comandos de kubectl.

  • PodSecurityPolicy ha quedado obsoleto. PodSecurityPolicy funcionará para varias versiones más y seguirá las pautas de obsolescencia de Kubernetes. Para obtener más información, lea PodSecurityPolicy Deprecation: Past, Present, and Future y el Blog de AWS.

Para completar el registro de cambios de Kubernetes 1.21, consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md.

Kubernetes 1.20

Para obtener más información sobre Kubernetes 1.20, consulte el anuncio del lanzamiento oficial.

Important

Las siguientes características de Kubernetes ya son compatibles con los clústeres de Amazon EKS de Kubernetes 1.20:

  • La Equidad y prioridad de la API ha alcanzado el estado beta y se encuentra habilitada de forma predeterminada. Esto permite a kube-apiserver clasificar las solicitudes entrantes por niveles de prioridad.

  • RuntimeClass ha alcanzado el estado estable. El recurso RuntimeClass proporciona un mecanismo para admitir varios tiempos de ejecución en un clúster y presenta información sobre ese tiempo de ejecución de contenedor en el plano de control.

  • Ahora, los Límites de ID de proceso se han ajustado a la disponibilidad general.

  • La Depuración de kubectl ha alcanzado el estado beta. kubectl debugproporciona soporte para flujos de trabajo comunes de depuración directamente desde kubectl.

  • El tiempo de ejecución del contenedor de Docker se encuentra obsoleto. La comunidad de Kubernetes ha escrito una publicación de blog en detalle sobre esto con una página de preguntas frecuentes. Las imágenes producidas por Docker pueden seguir utilizándose y funcionarán como siempre lo han hecho. Puede ignorar de forma segura el mensaje de advertencia de obsolescencia de dockershim impreso en los registros de inicio de kubelet. Con el tiempo, EKS pasará a containerd como el tiempo de ejecución de la AMI de Amazon Linux 2 optimizada para EKS. Puede seguir el problema del plan de desarrollo de contenedores para obtener más información.

  • El nombre de anfitrión del pod como FQDN se ha ajustado al estado beta. Esta característica permite establecer el nombre de anfitrión de un pod en su nombre de dominio completo (FQDN), lo que permite establecer el campo de nombre de anfitrión del kernel en el FQDN de un pod.

  • Ahora, los complementos de credenciales client-go se pueden pasar en la información actual del clúster a través de la variable de entorno KUBERNETES_EXEC_INFO. Esta mejora permite a los clientes Go autenticarse mediante proveedores de credenciales externos, como Key Management Systems (KMS).

Para completar el registro de cambios de Kubernetes 1.20, consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md.

Kubernetes 1.19

Para obtener más información acerca de Kubernetes 1.19, consulte el anuncio del lanzamiento oficial.

Important

  • A partir de la versión 1.19, Amazon EKS ya no agrega la etiqueta kubernetes.io/cluster/<cluster-name> a las subredes pasadas durante la creación del clúster. Esta etiqueta de subred solo es necesaria si desea influir en dónde el controlador de servicio de Kubernetes o el controlador del balanceador de carga de AWS coloca Elastic Load Balancers. Para obtener más información sobre los requisitos de las subredes transferidas a Amazon EKS durante la creación de clústeres, consulte las actualizaciones de los Consideraciones sobre la VPC del clúster.

    • Las etiquetas de subred no se modifican en clústeres existentes actualizados a la versión 1.19.

    • La versión v2.1.1, y la anterior, del controlador del balanceador de carga de AWS requirieron la etiqueta de subred <cluster-name>. En la versión v2.1.2 y posterior, puede especificar la etiqueta para refinar la detección de subredes, pero no es necesaria. Para obtener más información sobre el controlador del balanceador de carga de AWS, consulte Controlador del balanceador de carga de AWS. Para obtener más información sobre el etiquetado de subredes cuando se utiliza un balanceador de carga, consulte Equilibrio de carga de aplicaciones en Amazon EKS y Equilibrio de carga de red en Amazon EKS.

  • Ya no es necesario que proporcione un contexto de seguridad para los contenedores no raíz que necesitan acceder al archivo de token de identidad web para su uso con roles de IAM de cuentas de servicio. A fin de obtener más información, consulte Roles de IAM para cuentas de servicio y la propuesta para la gestión de permisos de archivo en el volumen de cuenta de servicio proyectado en GitHub.

  • Se ha actualizado el webhook de identidad del pod para abordar el problema de los sondeos de inicio faltantes en GitHub. Ahora, el webhook también admite anotaciones para controlar el vencimiento del token. Para obtener más información, consulte la solicitud de extracción de GitHub.

  • La versión 1.8.0 de CoreDNS es la versión recomendada para los clústeres 1.19 de Amazon EKS. Esta versión se instala de forma predeterminada en los nuevos clústeres 1.19 de Amazon EKS. Para obtener más información, consulte Administrar el complemento CoreDNS.

  • Las AMI de Amazon Linux 2 optimizadas para Amazon EKS incluyen la versión 5.4 del kernel de Linux para Kubernetes versión 1.19. Para obtener más información, consulte AMI de Amazon Linux optimizada para Amazon EKS.

  • La CertificateSigningRequest API ha sido promovida a certificates.k8s.io/v1 estable con los siguientes cambios:

    • Ahora se requiere spec.signerName. No puede crear solicitudes para kubernetes.io/legacy-unknown con la API certificates.k8s.io/v1.

    • Puede continuar creando CSR con el nombre de firmante kubernetes.io/legacy-unknown con la API certificates.k8s.io/v1beta1.

    • Puede seguir solicitando que se firme una CSR para un certificado de servidor que no sea de nodo, webhooks, por ejemplo, con la API certificates.k8s.io/v1beta1. Estas CSR no se aprueban de forma automática.

    • Para aprobar certificados, un usuario con privilegios requiere kubectl 1.18.8 o posterior.

    Para obtener más información sobre la API de certificado v1, consulte Solicitudes de firma de certificados en la documentación de Kubernetes.

Los siguientes recursos de Amazon EKS Kubernetes son fundamentales para que funcione el plano de control de Kubernetes. Recomendamos que no los elimine ni los modifique.

Permiso Kind Espacio de nombres Motivo
eks:certificate-controller Rolebinding kube-system Afecta la funcionalidad del firmante y el aprobador en el plano de control.
eks:certificate-controller Role kube-system Afecta la funcionalidad del firmante y el aprobador en el plano de control.
eks:certificate-controller ClusterRolebinding Todos Afecta la capacidad de kubelet para solicitar certificados de servidor, lo que modifica ciertas funcionalidades de clúster como kubectl exec y kubectl logs.

Las siguientes características de Kubernetes ya son compatibles con los clústeres de Amazon EKS de Kubernetes 1.19:

  • El controlador de admisión de ExtendedResourceToleration se encuentra habilitado. Este controlador de admisión agrega de forma automática toleraciones para las marcas a los pods que solicitan recursos extendidos, como las GPU, a fin de que no tenga que agregar las toleraciones de forma manual. Para obtener más información, consulte ExtendedResourceToleration en la documentación de Kubernetes.

  • Los balanceadores de carga elásticos (CLB y NLB) que aprovisiona el controlador de servicio de Kubernetes en árbol admiten el filtrado de los nodos incluidos como destinos de instancia. Esto puede ayudar a evitar que se alcancen los límites del grupo de destino en clústeres grandes. Para obtener más información, consulte el problema de GitHub relacionado y la anotación service.beta.kubernetes.io/aws-load-balancer-target-node-labels en Otras anotaciones de ELB en la documentación de Kubernetes.

  • La propagación de topología de pod ha alcanzado el estado estable. Puede utilizar restricciones de propagación de topología para controlar cómo se distribuyen los pods en el clúster entre dominios de error, como regiones, zonas, nodos y otros dominios de topología que define el usuario. Esto puede ayudar a lograr una alta disponibilidad, así como una utilización eficiente de los recursos. Para obtener más información, consulte Restricciones de propagación de topología de pod en la documentación de Kubernetes.

  • La API de entrada ha alcanzado la disponibilidad general. Para obtener más información, consulte Entradas en la documentación de Kubernetes.

  • Las EndpointSlices se encuentran habilitadas de forma predeterminada. Las EndpointSlices son una nueva API que proporciona una alternativa más escalable y extensible a la API de puntos de enlace para el seguimiento de direcciones IP, puertos, preparación e información de topología para pods que respaldan un servicio. Para obtener más información, consulte Scaling Kubernetes Networking With EndpointSlices en el blog de Kubernetes.

  • Ahora, los volúmenes Secret y ConfigMap se pueden marcar como inmutables, lo que reduce la carga en el servidor de API de forma significativa si hay muchos volúmenes Secret y ConfigMap en el clúster. Para obtener más información, consulte ConfigMap y Secret en la documentación de Kubernetes.

Para completar el registro de cambios de Kubernetes 1.19, consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md.

Kubernetes 1.18

Para obtener más información sobre Kubernetes 1.18, consulte el anuncio del lanzamiento oficial.

Las siguientes características de Kubernetes ya son compatibles con los clústeres de Amazon EKS de Kubernetes 1.18:

  • El administrador de topología ha alcanzado el estado beta. Esta característica permite que la CPU y el administrador de dispositivos coordinen las decisiones de asignación de recursos, lo que optimiza la baja latencia con cargas de trabajo de análisis y machine learning. Para obtener más información, consulte Políticas de administración de topología de control en un nodo en la documentación de Kubernetes.

  • Server-side Apply se actualiza con una versión beta nueva. Esta característica realiza un seguimiento y administra los cambios en los campos de todos los objetos de Kubernetes nuevos, lo que permite conocer qué cambió los recursos y cuándo. Para obtener más información, consulte ¿Qué es Server-side Apply? en la documentación de Kubernetes.

  • Un campo de pathType nuevo y un recurso de IngressClass nuevo se han agregado a la especificación de entrada. Estas características simplifican la personalización de la configuración de entrada y son compatibles con el Controlador de balanceador de carga de AWS (anteriormente denominado controlador de entrada de ALB). Para obtener más información, consulte Mejoras en la API de entrada en Kubernetes 1.18 en la documentación de Kubernetes.

  • Comportamiento de escalado automático de pod horizontal configurable. Para obtener más información, consulte Compatibilidad con el comportamiento de escalado configurable en la documentación de Kubernetes.

  • En los clústeres 1.18, ya no es necesario incluir la variable de entorno AWS_DEFAULT_REGION=<region-code> en los pods al utilizar roles de IAM para cuentas de servicio en las regiones de China, ya sea que utilice el enlace web mutante o configure las variables de entorno de forma manual. Todavía debe incluir la variable para todos los pods en versiones anteriores.

Para completar el registro de cambios de Kubernetes 1.18, consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md.

Kubernetes 1.17

Para obtener más información sobre Kubernetes 1.17, consulte el anuncio del lanzamiento oficial.

importante
  • EKS no ha habilitado el indicador de característica CSIMigrationAWS. Esto se habilitará en una versión futura, junto con instrucciones detalladas de migración. Para obtener más información sobre la migración de CSI, consulte el Blog de Kubernetes.

  • La actualización de un clúster de 1.16 a 1.17 fallará si alguno de los pods de AWS Fargate tienen una versión secundaria de kubelet anterior a 1.16. Antes de actualizar el clúster de 1.16 a 1.17, debe reciclar los pods de Fargate para que sus kubelet sean 1.16 antes de intentar actualizar el clúster a 1.17. Para reciclar una implementación de Kubernetes en un clúster 1.15 o posterior, utilice el siguiente comando.

    kubectl rollout restart deployment <deployment-name>

Las siguientes características de Kubernetes ya son compatibles con los clústeres de Amazon EKS de Kubernetes 1.17:

  • Las Etiquetas de proveedores de nube han alcanzado la disponibilidad general. Si utiliza las etiquetas beta en las especificaciones del pod para características como la afinidad de nodos o en cualquier controlador personalizado, recomendamos que comience a migrarlas a las etiquetas nuevas disponibles de manera general. Para obtener información sobre las etiquetas nuevas, consulte la siguiente documentación de Kubernetes:

  • La característica ResourceQuotaScopeSelectors se ha ajustado a la disponibilidad general. Esta característica permite limitar el número de recursos que admite una cuota a solo aquellos que pertenecen al alcance.

  • La característica TaintNodesByCondition se ha ajustado a la disponibilidad general. Esta característica permite marcar nodos que tienen condiciones como presión de disco o memoria alta.

  • La característica Topología de CSI se ha ajustado a la disponibilidad general y es totalmente compatible con el controlador de CSI de EBS. Puede utilizar la topología para restringir la zona de disponibilidad donde se aprovisiona un volumen.

  • La Protección del finalizador para servicios de tipo LoadBalancer se ha ajustado a la disponibilidad general. Esta característica garantiza que un recurso de servicio no se elimine completamente hasta que también se elimine el balanceador de carga correspondiente.

  • Ahora, los recursos personalizados admiten valores predeterminados. Los valores se especifican en un esquema de validación de OpenAPI v3.

  • Ahora, la característica RunAsUsername de los contenedores de Windows se encuentra en la versión beta, lo que permite ejecutar aplicaciones de Windows en un contenedor como un nombre de usuario diferente al predeterminado.

Para completar el registro de cambios de Kubernetes 1.17, consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md.

Kubernetes 1.16

Para obtener más información acerca de Kubernetes 1.16, consulte el anuncio del lanzamiento oficial.

importante

Las siguientes características de Kubernetes ya son compatibles con los clústeres de Amazon EKS de Kubernetes 1.16:

  • La expansión de volumen en la especificación CSI se ha movido a beta, lo que permite que sea redimensionable cualquier complemento de volumen de especificación CSI. Para obtener más información, consulte Volume Expansión en la documentación CSI de Kubernetes. La versión más reciente del controlador CSI de EBS admite la expansión de volumen cuando se ejecuta en un clúster 1.16 de Amazon EKS.

  • La compatibilidad con Windows GMSA ha pasado de alfa a beta y ahora es compatible con Amazon EKS. Para obtener más información, consulte Configure GMSA for Windows Pods and containers en la documentación de Kubernetes.

  • Una nueva anotación: service.beta.kubernetes.io/aws-load-balancer-eip-allocations está disponible en el tipo de servicio LoadBalancer para asignar una dirección IP elástica a los balanceadores de carga de red. Para obtener más información, consulte el problema de GitHub Admitir asignaciones de EIP con AWS NLB.

  • La protección del finalizador para los balanceadores de carga de servicio está ahora en versión beta y está habilitada de forma predeterminada. La protección del finalizador del balanceador de carga de servicio garantiza que los recursos del balanceador de carga asignados a un objeto de servicio Kubernetes, como los balanceadores de carga de red, se destruirán o lanzarán cuando se elimine el servicio. Para obtener más información, consulte Garbage Collecting Load Balancers en la documentación de Kubernetes.

  • Las definiciones de recursos personalizados de Kubernetes y los mecanismos de extensibilidad de los webhooks de admisión han alcanzado la disponibilidad general. Para obtener más información, consulte Custom Resources y Dynamic Admission Control en la documentación de Kubernetes.

  • La característica de aplicación del lado del servidor ha alcanzado el estado beta y está habilitada de forma predeterminada. Para obtener más información, consulte Server Side Apply en la documentación de Kubernetes.

  • La característica CustomResourceDefaulting se ha promovido a beta y se habilita de forma predeterminada. Los valores predeterminados se pueden especificar en esquemas estructurales a través de la API apiextensions.k8s.io/v1. Para obtener más información, consulte Specifying a structural schema en la documentación de Kubernetes.

Para completar el registro de cambios de Kubernetes 1.16, consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md.

Calendario de lanzamiento de Amazon EKS Kubernetes

nota

Las fechas con solo un mes y un año son aproximadas y se actualizan con una fecha exacta cuando se conoce.

Versión de Kubernetes Versión anterior Versión de Amazon EKS Fin de la compatibilidad de Amazon EKS
1.16 8 de septiembre de 2019 30 de abril de 2020 27 de septiembre de 2021
1,17 9 de diciembre de 2019 10 de julio de 2020 2 de noviembre de 2021
1.18 23 de marzo de 2020 13 de octubre de 2020 18 de febrero de 2022
1.19 26 de agosto de 2020 16 de febrero de 2021 Abril de 2022
1.20 8 de diciembre de 2020 18 de mayo de 2021 Junio de 2022
1.21 8 de abril de 2021 19 de julio de 2021 Septiembre de 2022

Preguntas frecuentes y soporte de versión de Amazon EKS

De conformidad con el soporte que ofrece la comunidad de Kubernetes para las versiones de Kubernetes, Amazon EKS se compromete a admitir al menos cuatro versiones de Kubernetes listas para producción en cualquier momento. Anunciaremos la fecha de finalización del soporte de una versión secundaria de Kubernetes determinada al menos 60 días antes de la fecha de finalización del soporte. Debido al proceso de cualificación y lanzamiento de Amazon EKS de versiones de Kubernetes nuevas, la fecha de finalización del soporte de la versión de Kubernetes en Amazon EKS será en la fecha en que el proyecto de Kubernetes deje de ser compatible con la versión anterior o después de ello.

Preguntas frecuentes

P: ¿Cuánto tiempo es compatible con Amazon EKS una versión de Kubernetes?

R: Una versión de Kubernetes es totalmente compatible durante 14 meses después de encontrarse disponible por primera vez en Amazon EKS. Esto es cierto incluso si la versión anterior de Kubernetes ya no admite una versión disponible en Amazon EKS. Creamos parches de seguridad que se pueden aplicar a las versiones de Kubernetes compatibles con Amazon EKS.

P: ¿Se me notifica cuándo finaliza el soporte para una versión de Kubernetes en Amazon EKS?

R: Sí. Si alguno de los clústeres de su cuenta ejecuta la versión que está cerca del final del soporte, Amazon EKS envía un aviso a través de AWS Personal Health Dashboard aproximadamente 12 meses después del lanzamiento de la versión de Kubernetes en Amazon EKS. El aviso incluye la fecha de finalización del soporte, que es de al menos 60 días a partir de la fecha del aviso.

P: ¿Qué sucede cuando llega la fecha de finalización del soporte?

R: Cuando llega la fecha de finalización del soporte, ya no podrá crear nuevos clústeres de Amazon EKS con la versión que no es compatible. Amazon EKS actualiza los planos de control existentes a la versión admitida más antigua de forma automática mediante un proceso de implementación gradual tras la fecha de finalización del soporte. Después de la actualización automática del plano de control, debe actualizar los complementos del clúster y los nodos de Amazon EC2 de forma manual. Para obtener más información, consulte Para actualizar la versión de Kubernetes de un clúster de Amazon EKS .

P: ¿Cuándo se actualizará de forma automática mi plano de control después de la fecha de finalización del soporte?

R: Amazon EKS no puede proporcionar plazos específicos. Las actualizaciones automáticas pueden ocurrir en cualquier momento después de la fecha de finalización del soporte. Recomendamos que tome medidas proactivas y actualice su plano de control sin depender del proceso de actualización automática de Amazon EKS. Para obtener más información, consulte Actualización de un clúster.

P: ¿Puedo dejar mi plano de control en una versión de Kubernetes de forma indefinida?

R: No. La seguridad en la nube de AWS es la mayor prioridad. Amazon EKS no permite que los planos de control permanezcan en una versión que haya llegado al final del soporte.

P: ¿Qué características de Kubernetes son compatibles con Amazon EKS?

R: Amazon EKS admite todas las características de disponibilidad general de la API de Kubernetes, así como las características beta que se encuentran habilitadas de forma predeterminada. Las características alfa no son compatibles.

P: ¿Los grupos de nodos administrados por Amazon EKS se actualizan de forma automática junto con la versión del plano de control de clúster?

R: No. Un grupo de nodos administrados crea instancias de Amazon EC2 en su cuenta. Estas instancias no se actualizan de forma automática cuando usted o Amazon EKS actualizan su plano de control. Si Amazon EKS actualiza el plano de control de forma automática, la versión de Kubernetes en el grupo de nodos administrados puede ser más de una versión anterior que el plano de control. Si un grupo de nodos administrados contiene instancias que ejecutan una versión de Kubernetes que es más de una versión anterior que el plano de control, el grupo de nodos tiene un problema de estado en la sección Node Groups (Grupos de nodos) de la pestaña Compute (informática) en la pestaña Configuration (Configuración) del clúster de la consola. Si un grupo de nodos tiene una actualización de versión disponible, Update now (Actualizar ahora) aparece junto al grupo de nodos en la consola. Para obtener más información, consulte Actualización de un grupo de nodos administrados. Recomendamos mantener la misma versión de Kubernetes en el plano de control y los nodos.

P: ¿Los grupos de nodos autoadministrados se actualizan de forma automática junto con la versión del plano de control de clúster?

R: No. Un grupo de nodos autoadministrados incluye instancias de Amazon EC2 en su cuenta. Estas instancias no se actualizan de forma automática cuando usted o Amazon EKS actualizan la versión del plano de control. Un grupo de nodos autoadministrados no tiene indicaciones en la consola de que necesita actualizarse. Puede ver la versión de kubelet instalada en un nodo al seleccionar el nodo en la lista de Nodos en la pestaña Overview (Información general) del clúster para determinar qué nodos deben actualizarse. Debe actualizar los nodos de forma manual. Para obtener más información, consulte Actualizaciones de nodos autoadministrados.

El proyecto de Kubernetes comprueba la compatibilidad entre el plano de control y los nodos de hasta dos versiones secundarias. Por ejemplo, los nodos 1.19 continúan funcionando cuando se organicen mediante un plano de control 1.21. Sin embargo, no se recomienda ejecutar un clúster con nodos que son dos versiones secundarias detrás del plano de control de forma constante. Para obtener más información, consulte la sección sobre la política de compatibilidad de versiones y diferencia de versiones de Kubernetes en la documentación de Kubernetes. Recomendamos mantener la misma versión de Kubernetes en el plano de control y los nodos.

P: ¿Los pods que se ejecutan en Fargate se actualizan automáticamente con una actualización automática de la versión del plano de control de clúster?

Sí. Los pods de Fargate se ejecutan en la infraestructura en cuentas de AWS en el lado de Amazon EKS del modelo de responsabilidad compartida. Amazon EKS utiliza la API de expulsión de Kubernetes para intentar drenar de forma correcta los pods que se ejecutan en Fargate. Para obtener más información, consulte La API de expulsión en la documentación de Kubernetes. Si no se puede expulsar un pod, Amazon EKS emite un comando delete pod de Kubernetes. Recomendamos encarecidamente ejecutar pods de Fargate como parte de un controlador de replicación, como una implementación de Kubernetes, de modo que el pod se reprograme de forma automática después de su eliminación. Para obtener más información, consulte Implementaciones en la documentación de Kubernetes. La versión nueva del pod de Fargate se implementa con una versión de kubelet que es la misma que la versión actualizada del plano de control de clúster.

importante

Si actualiza el plano de control, debe actualizar los nodos de Fargate por su cuenta. Para actualizar los nodos de Fargate, elimine el pod de Fargate representado por el nodo y vuelva a implementarlo. El pod nuevo se implementa con una versión de kubelet que es la misma versión del clúster.