Actualización de una versión de Kubernetes de clúster de Amazon EKS - Amazon EKS

Actualización de una versión de Kubernetes de clúster de Amazon EKS

Cuando hay una nueva versión de Kubernetes disponible en Amazon EKS, puede actualizar el clúster de Amazon EKS a la versión más reciente.

importante

Recomendamos que antes de actualizar a una nueva versión de Kubernetes revise la información en Versiones de Amazon EKS de Kubernetes y los pasos de actualización de este tema. Si está actualizando a la versión 1.22, debe realizar los cambios enumerados en Requisitos previos de la versión 1.22 de Kubernetes al clúster antes de actualizarlo.

Las nuevas versiones de Kubernetes suelen presentar cambios significativos. Por ende, recomendamos que pruebe el comportamiento de las aplicaciones en la nueva versión de Kubernetes antes de realizar la actualización en los clústeres de producción. Para ello, puede crear un flujo de trabajo de integración continua con el fin de probar el comportamiento de la aplicación antes de pasar a una nueva versión de Kubernetes.

El proceso de actualización consiste en que Amazon EKS lance nodos de servidor de API nuevos con la versión actualizada de Kubernetes para sustituir a los existentes. Amazon EKS lleva a cabo una infraestructura estándar y una comprobación de estado de la disponibilidad del tráfico de red en estos nodos nuevos para verificar que funcionan según lo esperado. Si cualquiera de estas comprobaciones falla, Amazon EKS revierte la implementación de la infraestructura y su clúster se mantiene en la versión anterior de Kubernetes. Las aplicaciones en ejecución no se ven afectadas y su clúster nunca queda en un estado no determinista o irrecuperable. Si fuese necesario, Amazon EKS realiza copias de seguridad de forma habitual a todos los clústeres administrados y existe un mecanismo de recuperación de clústeres. Evaluamos y mejoramos de forma constante nuestros procesos de administración de la infraestructura de Kubernetes.

Para actualizar el clúster, Amazon EKS requiere hasta cinco direcciones IP libres de las subredes que se especificaron cuando creó el clúster. Amazon EKS crea nuevas interfaces de red elástica de clúster (interfaces de red) en cualquiera de las subredes especificadas. Las interfaces de red se pueden crear en subredes diferentes a las que están las interfaces de red existentes, así que asegúrese de que las reglas del grupo de seguridad permitan la comunicación de clúster necesaria para cualquiera de las subredes que especificó al crear su clúster. Si alguna de las subredes especificadas al crear el clúster no existe, no tiene suficientes direcciones IP libres o no tiene reglas de grupo de seguridad que permitan la comunicación del clúster necesaria, la actualización puede fallar.

nota

Aunque Amazon EKS ejecuta un plano de control de alta disponibilidad, podría experimentar interrupciones menores del servicio durante una actualización. Por ejemplo, supongamos que intenta conectarse a un servidor de API cuando se termina y se sustituya por un nuevo servidor de API que ejecuta la nueva versión de Kubernetes. Es posible que tengas errores de llamada a la API o problemas de conectividad. Si esto ocurre, repita las operaciones de la API hasta que realicen correctamente.

Actualice la versión de Kubernetes de un clúster de Amazon EKS

Para actualizar la versión de Kubernetes del clúster

  1. Compare la versión de Kubernetes de su plano de control de clúster con la versión de Kubernetes de sus nodos.

    • Obtenga la versión de Kubernetes del plano de control de clúster con el comando kubectl version --short.

      kubectl version --short
    • Obtenga la versión de Kubernetes de los nodos con el comando kubectl get nodes. Este comando devuelve todos los nodos autoadministrados y administrados de Amazon EC2 y Fargate. Cada pod de Fargate aparece como su propio nodo.

      kubectl get nodes

    Antes de actualizar un plano de control a una nueva versión de Kubernetes, asegúrese de que la versión secundaria de Kubernetes de ambos notos administrados y de Fargate en el clúster debe ser la misma que la de la versión actual del plano de control. Por ejemplo, si el plano de control está ejecutando la versión 1.22 y uno de sus nodos está ejecutando la versión 1.21, debe actualizar los nodos a la versión 1.22 antes de actualizar el plano de control a 1.23. También recomendamos que actualice los nodos autoadministrados a la misma versión que el plano de control antes de actualizar el plano de control. Para obtener más información, consulte Actualización de un grupo de nodos administrados y Actualizaciones de nodos autoadministrados. Para actualizar la versión de un nodo de Fargate, elimine primero el pod que representa el nodo. Luego, actualice su plano de control. Los pods restantes se actualizarán a la nueva versión después de volver a implementarlos.

  2. De manera predeterminada, el controlador de admisión de la política de seguridad del pod se encuentra habilitado en clústeres de Amazon EKS. Antes de actualizar el clúster, asegúrese de que las políticas de seguridad del pod adecuadas estén implementadas. Esto ocurre para evitar posibles problemas de seguridad. Puede consultar la política predeterminada con el comando kubectl get psp eks.privileged.

    kubectl get psp eks.privileged

    Si recibe el siguiente error, consulte política de seguridad del pod predeterminada antes de continuar.

    Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found
  3. Si la versión de Kubernetes con la que implementó originalmente el clúster era Kubernetes 1.18 o posterior, omita este paso.

    Es posible que deba eliminar un término interrumpido de su manifiesto CoreDNS.

    1. Verifique si su manifiesto CoreDNS cuenta con una línea que solo tiene la palabra upstream.

      kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream

      Si no se devuelve un resultado, significa que el manifiesto no cuenta con la línea. En tal caso, continúe en el paso siguiente Si se devuelve la palabra upstream, elimine la línea.

    2. Elimine la línea que está cerca de la parte superior del archivo que solo tiene la palabra upstream en el archivo de configmap. No cambie nada más en el archivo. Después de eliminar la línea, guarde los cambios.

      kubectl edit configmap coredns -n kube-system -o yaml
  4. Actualice el clúster mediante eksctl, la AWS Management Console o la AWS CLI.

    importante
    • Si está actualizando a la versión 1.22, debe realizar los cambios enumerados en Requisitos previos de la versión 1.22 de Kubernetes al clúster antes de actualizarlo.

    • Si va a actualizar a la versión 1.23 y usar volúmenes de Amazon EBS en el clúster, debe instalar el controlador CSI de Amazon EBS en el clúster antes de actualizar el clúster a la versión 1.23 para evitar interrupciones en la carga de trabajo. Para obtener más información, consulte Kubernetes 1.23 y Controlador de CSI de Amazon EBS.

    • Puesto que Amazon EKS ejecuta un plano de control de alta disponibilidad, puede actualizar solo una versión secundaria a la vez. Para obtener más información acerca de este requisito, consulte Política de compatibilidad de versiones y diferencia de versiones de Kubernetes. Supongamos que la versión del clúster actual es 1.21 y quiere actualizar a 1.23. Primero debe actualizar el clúster a 1.22 y, a continuación, actualizar su clúster 1.22 a 1.23.

    • Asegúrese de que kubelet en sus nodos administrados y de Fargate se encuentren en la misma versión de Kubernetes que su plano de control antes de actualizar. Le recomendamos que los nodos autoadministrados sean la misma versión que el plano de control. Solo pueden estar hasta una versión detrás de la versión actual del plano de control.

    • Si el clúster está configurado con una versión del complemento CNI de Amazon VPC anterior a 1.8.0, recomendamos que actualice el plugin a la versión 1.11.4 antes de actualizar el clúster a la versión 1.21 o posterior. Para obtener más información, consulte Actualización del complemento Amazon VPC CNI plugin for Kubernetes o Actualizar el complemento autoadministrado Amazon VPC CNI plugin for Kubernetes.

    eksctl

    En este procedimiento, se requiere la versión eksctl o posterior de la 0.117.0. Puede verificar la versión con el siguiente comando:

    eksctl version

    Para obtener instrucciones sobre cómo instalar y actualizar eksctl, consulte Instalación o actualización del eksctl.

    Actualice la versión de Kubernetes de su plano de control de Amazon EKS. Reemplace my-cluster por el nombre de su clúster. Reemplace 1.23 por el número de versión compatible con Amazon EKS al que desea actualizar su clúster. Para ver una lista de los números de versiones compatibles, consulte Versiones de Amazon EKS de Kubernetes.

    eksctl upgrade cluster --name my-cluster --version 1.23 --approve

    La actualización puede tardar varios minutos en completarse.

    AWS Management Console
    1. Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.

    2. Elija el nombre del clúster de Amazon EKS que desea actualizar y elija Update cluster version (Actualizar versión del clúster).

    3. En Kubernetes version (Versión de Kubernetes), seleccione la versión a la que desea actualizar el clúster y elija Update (Actualizar).

    4. En Cluster name (Nombre del clúster), escriba el nombre del clúster y seleccione Confirm (Confirmar).

      La actualización puede tardar varios minutos en completarse.

    AWS CLI
    1. Actualice el clúster de Amazon EKS con el comando de la AWS CLI siguiente. Reemplace los example values por los de su propiedad. Reemplace 1.23 por el número de versión compatible con Amazon EKS al que desea actualizar su clúster. Para ver una lista de los números de versiones compatibles, consulte Versiones de Amazon EKS de Kubernetes.

      aws eks update-cluster-version --region region-code --name my-cluster --kubernetes-version 1.23

      A continuación, se muestra un ejemplo de resultado.

      { "update": { "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f", "status": "InProgress", "type": "VersionUpdate", "params": [ { "type": "Version", "value": "1.23" }, { "type": "PlatformVersion", "value": "eks.1" } ], ... "errors": [] } }
    2. Monitoree el estado de la actualización del clúster con el comando siguiente. Utilice el nombre del clúster e ID de actualización devueltos por el comando anterior. Cuando se muestra el estado Successful, la actualización se ha completado. La actualización puede tardar varios minutos en completarse.

      aws eks describe-update --region region-code --name my-cluster --update-id b5f0ba18-9a87-4450-b5a0-825e6e84496f

      A continuación, se muestra un ejemplo de resultado.

      { "update": { "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f", "status": "Successful", "type": "VersionUpdate", "params": [ { "type": "Version", "value": "1.23" }, { "type": "PlatformVersion", "value": "eks.1" } ], ... "errors": [] } }
  5. Una vez que se complete la actualización del clúster, actualice los nodos a la misma versión secundaria de Kubernetes de su clúster actualizado. Para obtener más información, consulte Actualizaciones de nodos autoadministrados y Actualización de un grupo de nodos administrados. Los pods nuevos que se lancen en Fargate tienen una versión de kubelet que coinciden con la versión del clúster. Los pods de Fargate existentes no cambian.

  6. (Opcional) Si implementó el Cluster Autoscaler de Kubernetes en el clúster antes de actualizar este último, actualice dicho Cluster Autoscaler a la versión más reciente que coincida con la versión principal y secundaria de Kubernetes a las que actualizó.

    1. Abra la página de versiones del escalador automático del clúster en un navegador web y busque la versión más reciente del escalador automático del clúster que coincida con la versión principal y secundaria de Kubernetes de su clúster. Por ejemplo, si la versión de Kubernetes del clúster es 1.23, busque la última versión del escalador automático del clúster que comience por 1.23. Registre el número de versión semántica (1.23.n, por ejemplo) de esa versión para usarlo en el siguiente paso.

    2. Establezca la etiqueta de la imagen del escalador automático del clúster en la versión que ha registrado en el paso anterior con el comando siguiente. Si es necesario, reemplace 1.23.n por su propio valor.

      kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v1.23.n
  7. (Solo para clústeres con nodos de GPU) Si el clúster tiene grupos de nodos compatibles con GPU (por ejemplo, p3.2xlarge), debe actualizar el complemento del dispositivo NVIDIA para Kubernetes DaemonSet de su clúster con el siguiente comando.

    kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/nvidia-device-plugin.yml
  8. Actualice los complementos Amazon VPC CNI plugin for Kubernetes, CoreDNS y kube-proxy. Si ha actualizado el clúster a la versión 1.21 o posterior, de lo que recomendamos actualizar los complementos a las versiones mínimas enumeradas en Tokens de cuenta de servicio.

    • Si está usando complementos de Amazon EKS, seleccione Clusters (Clústeres) en la consola de Amazon EKS y, a continuación, seleccione el nombre del clúster que actualizó en el panel de navegación izquierdo. Las notificaciones aparecen en la consola. Le informan que hay una versión nueva disponible para cada complemento que tenga una actualización disponible. Para actualizar un complemento, seleccione la pestaña Add-ons (Complementos). En uno de los cuadros de un complemento que tenga una actualización disponible, seleccione Update now (Actualizar ahora), seleccione una versión disponible y, a continuación, seleccione Update (Actualizar).

    • Como alternativa, puede utilizar la AWS CLI o eksctl para actualizar los complementos Amazon VPC CNI plugin for Kubernetes, CoreDNS y kube-proxy de Amazon EKS.

  9. De ser necesario, actualice su versión de kubectl. Debe utilizar una versión de kubectl con una diferencia de versión de menos de un número que el plano del control del clúster de Amazon EKS. Por ejemplo, un cliente de kubectl 1.22 trabaja con los clústeres Kubernetes, 1.21, 1.22 y 1.23. Puede comprobar su versión instalada actualmente con el siguiente comando.

    kubectl version --short | grep Client | cut -d : -f2

Requisitos previos de la versión 1.22 de Kubernetes

Varias API beta obsoletas (v1beta1) se han eliminado en la versión 1.22 a favor de la GA (v1) de esas mismas API. Como se indica en el Blog de eliminación de API y funciones de la versión 1.22 de Kubernetes y la Guía de migración de la API obsoleta, se requieren cambios de API para los siguientes recursos implementados antes de actualizar un clúster a la versión 1.22.

Antes de actualizar el clúster a la versión 1.22 de Kubernetes, asegúrese de hacer lo siguiente:

  • Cambie su archivos de manifiesto y clientes de YAML para que hagan referencia a las nuevas API.

  • Actualice las integraciones y los controladores personalizados para que llamen a las nuevas API.

  • Asegúrese de utilizar una versión actualizada de cualquier herramienta de terceros. Estas herramientas incluyen controladores de entrada, controladores de malla de servicio, sistemas de entrega continua y otras herramientas que llaman a las nuevas API. A fin de verificar fácilmente el uso de API interrumpido en el clúster, asegúrese de que el registro del plano de control de auditoría se encuentre habilitado y especifique v1beta como filtro para los eventos. Las API de reemplazo están disponibles en Kubernetes para varias versiones.

  • Si actualmente ha implementado el controlador del equilibrador de carga AWS en el clúster, debe actualizarlo a la versión 2.4.1 antes de actualizar el clúster a la versión 1.22 de Kubernetes.

importante

Al actualizar clústeres a la versión 1.22, se puede acceder a los objetos persistentes existentes mediante las nuevas API. Sin embargo, debe migrar manifiestos y actualizar clientes para utilizar estas nuevas API. La actualización de los clústeres evita posibles fallos de carga de trabajo.

La versión 1.22 de Kubernetes elimina el soporte de las siguientes API beta. Migre sus manifiestos y clientes API basándose en la siguiente información:

Resource Versión Beta Versión de GA Notas
ValidatingWebhookConfiguration MutatingWebhookConfiguration admissionregistration.k8s.io/v1beta1 admissionregistration.k8s.io/v1
  • webhooks[*].failurePolicy predeterminado cambió de Ignore a Fail para v1.

  • webhooks[*].matchPolicy predeterminado cambió de Exact a Equivalent para v1.

  • webhooks[*].timeoutSeconds predeterminado cambió de 30s a 10s para v1.

  • Se eliminó el valor predeterminado webhooks[*].sideEffects y el campo se hizo obligatorio, y solo se permiten None y NoneOnDryRun para v1.

  • Se eliminó el valor predeterminado webhooks[*].admissionReviewVersions y se hizo obligatorio el campo para v1 (versiones compatibles para AdmissionReview son v1 y v1beta1).

  • webhooks[*].name debe ser único en la lista de objetos creados mediante admissionregistration.k8s.io/v1.

CustomResourceDefinition apiextensions.k8s.io/v1beta1 apiextensions.k8s.io/v1
  • spec.scope ya no está predeterminado en Namespaced y debe especificarse explícitamente.

  • spec.version se eliminó en v1; utilice spec.versions en su lugar

  • spec.validation se elimina en v1; utilice spec.versions[*].schema en su lugar.

  • spec.subresources se elimina en v1; utilice spec.versions[*].subresources en su lugar.

  • spec.additionalPrinterColumns se elimina en v1; utilice spec.versions[*].additionalPrinterColumns en su lugar.

  • spec.conversion.webhookClientConfig se movió a spec.conversion.webhook.clientConfig en v1.

  • spec.conversion.conversionReviewVersions se movió a spec.conversion.webhook.conversionReviewVersions en v1.

  • spec.versions[*].schema.openAPIV3Schema ahora es obligatorio para crear objetos v1 CustomResourceDefinition y debe ser un esquema estructural.

  • spec.preserveUnknownFields: true no está permitido al crear objetos v1 CustomResourceDefinition; debe especificarse dentro de las definiciones de esquema como x-kubernetes-preserve-unknown-fields: true.

  • En los artículos additionalPrinterColumns, se ha cambiado el nombre del campo JSONPath a jsonPath en v1 (correcciones n.° 66531).

APIService apiregistration.k8s.io/v1beta1 apiregistration.k8s.io/v1 Ninguno
TokenReview authentication.k8s.io/v1beta1 authentication.k8s.io/v1 Ninguno
SubjectAccessReview LocalSubjectAccessReview SelfSubjectAccessReview authorization.k8s.io/v1beta1 authorization.k8s.io/v1 Se cambió el nombre de spec.group a spec.groups
CertificateSigningRequest certificates.k8s.io/v1beta1 certificates.k8s.io/v1
  • Para los clientes API que solicitan certificados:

    • Ahora spec.signerName es obligatorio (consulte firmantes conocidos de Kubernetes) y no se permite crear solicitudes para kubernetes.io/legacy-unknown a través de la API certificados.k8s.io/v1

    • spec.usages ahora es obligatorio, puede que no contenga valores duplicados y solo debe contener usos conocidos

  • Para clientes API que aprueban o firman certificados:

    • status.conditions puede no contener tipos duplicados

    • status.conditions[*].status ahora es obligatorio

    • status.certificate debe estar codificado en PEM y contener solo blocks CERTIFICATE

Lease

coordination.k8s.io/v1beta1 coordination.k8s.io/v1 Ninguno

Ingress

  • extensions/v1beta1

  • networking.k8s.io/v1beta1

networking.k8s.io/v1
  • Se cambió el nombre de spec.backend a spec.defaultBackend

  • El campo backend serviceName cambió su nombre a service.name

  • Los campos de backend numérico servicePort cambiaron su nombre a service.port.number

  • Los campos backend de cadena servicePort cambiaron su nombre a service.port.name

  • pathType ahora es obligatorio para cada ruta especificada. Las opciones son Prefix, Exact y ImplementationSpecific. Para coincidir con el comportamiento no definido de v1beta1, use ImplementationSpecific

IngressClass

networking.k8s.io/v1beta1 networking.k8s.io/v1 Ninguno

RBAC

rbac.authorization.k8s.io/v1beta1 rbac.authorization.k8s.io/v1 Ninguno
PriorityClass scheduling.k8s.io/v1beta1 scheduling.k8s.io/v1 Ninguno
CSIDriver CSINode StorageClass VolumeAttachment storage.k8s.io/v1beta1 storage.k8s.io/v1 Ninguno

Para obtener más información sobre la eliminación de la API, consulte la Guía de migración de API obsoleta.