Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Mejores prácticas para las actualizaciones de clústeres

Esta guía muestra a los administradores de clústeres cómo planificar y ejecutar su estrategia de actualización de Amazon EKS. También describe cómo actualizar los nodos autogestionados, los grupos de nodos gestionados, los nodos Karpenter y los nodos Fargate. No incluye orientación sobre EKS Anywhere, Kubernetes autogestionado, AWS Outposts ni AWS Local Zones.

Descripción general de

Una versión de Kubernetes abarca tanto el plano de control como el plano de datos. Para garantizar un funcionamiento sin problemas, tanto el plano de control como el plano de datos deben ejecutar la misma versión secundaria de Kubernetes, como la 1.24. Mientras AWS administra y actualiza el plano de control, la actualización de los nodos de trabajo en el plano de datos es su responsabilidad.

Antes de actualizar

Si tiene pensado actualizar su versión de Kubernetes en Amazon EKS, hay algunas políticas, herramientas y procedimientos importantes que debe implementar antes de iniciar la actualización.

Mantén tu clúster actualizado

Mantenerse al día con las actualizaciones de Kubernetes es fundamental para un entorno EKS seguro y eficiente, que refleje el modelo de responsabilidad compartida de Amazon EKS. Al integrar estas estrategias en su flujo de trabajo operativo, se posiciona para mantener clústeres seguros y actualizados que aprovechen al máximo las funciones y mejoras más recientes. Tácticas:

Consulte el calendario de lanzamientos de EKS

Consulta el calendario de lanzamientos de EKS Kubernetes para saber cuándo llegarán nuevas versiones y cuándo finalizará el soporte para versiones específicas. Por lo general, EKS publica tres versiones secundarias de Kubernetes al año, y cada versión secundaria tiene soporte durante unos 14 meses.

Además, consulta la información sobre las versiones iniciales de Kubernetes.

Comprenda cómo se aplica el modelo de responsabilidad compartida a las actualizaciones de los clústeres

Usted es responsable de iniciar la actualización tanto para el plano de control del clúster como para el plano de datos. Obtenga información sobre cómo iniciar una actualización. Al iniciar una actualización de un clúster, AWS gestiona la actualización del plano de control del clúster. Usted es responsable de actualizar el plano de datos, incluidos los módulos y complementos de Fargate. Debes validar y planificar las actualizaciones de las cargas de trabajo que se ejecutan en tu clúster para garantizar que su disponibilidad y sus operaciones no se vean afectadas tras la actualización del clúster

Actualice los clústeres in situ

EKS admite una estrategia de actualización de clústeres in situ. Esto mantiene los recursos del clúster y mantiene la coherencia de la configuración del clúster (por ejemplo, el punto final de la API, el OIDC, los ENis y los balanceadores de carga). Esto es menos molesto para los usuarios del clúster y utilizará las cargas de trabajo y los recursos existentes en el clúster sin que sea necesario volver a implementar las cargas de trabajo ni migrar los recursos externos (por ejemplo, el DNS o el almacenamiento).

Al realizar una actualización local del clúster, es importante tener en cuenta que solo se puede ejecutar una actualización de versión secundaria a la vez (por ejemplo, de la 1.24 a la 1.25).

Esto significa que si necesitas actualizar varias versiones, necesitarás una serie de actualizaciones secuenciales. Planificar las actualizaciones secuenciales es más complicado y conlleva un mayor riesgo de tiempo de inactividad. En esta situación, consulteEvalúe Blue/Green los clústeres como una alternativa a las actualizaciones de clústeres locales.

Actualice el plano de control y el plano de datos en secuencia

Para actualizar un clúster, tendrá que realizar las siguientes acciones:

Utilice la documentación de EKS para crear una lista de verificación de actualización

La documentación de la versión de EKS Kubernetes incluye una lista detallada de los cambios para cada versión. Cree una lista de verificación para cada actualización.

Para obtener una guía específica sobre la actualización de la versión de EKS, consulte la documentación para ver los cambios y consideraciones importantes para cada versión.

Actualiza los complementos y componentes con la API de Kubernetes

Antes de actualizar un clúster, debes saber qué versiones de los componentes de Kubernetes estás usando. Haz un inventario de los componentes del clúster e identifica los componentes que utilizan directamente la API de Kubernetes. Esto incluye los componentes críticos del clúster, como los agentes de supervisión y registro, los escaladores automáticos del clúster, los controladores de almacenamiento en contenedores (por ejemplo, EBS CSI o EFS CSI), los controladores de entrada y cualquier otra carga de trabajo o complemento que dependa directamente de la API de Kubernetes.

kubectl get ns | grep '-system'

Una vez que hayas identificado los componentes que dependen de la API de Kubernetes, consulta su documentación para conocer los requisitos de actualización y compatibilidad de versiones. Por ejemplo, consulte la documentación de AWS Load Balancer Controller para conocer la compatibilidad de las versiones. Es posible que sea necesario actualizar algunos componentes o cambiar la configuración antes de continuar con la actualización de un clúster. Algunos componentes fundamentales que hay que comprobar son CoreDNS, kube-proxy, VPC CNI y los controladores de almacenamiento.

Los clústeres suelen contener muchas cargas de trabajo que utilizan la API de Kubernetes y son necesarias para la funcionalidad de las cargas de trabajo, como los controladores de entrada, los sistemas de entrega continua y las herramientas de supervisión. Cuando actualizas un clúster de EKS, también debes actualizar los complementos y las herramientas de terceros para asegurarte de que son compatibles.

Consulte los siguientes ejemplos de complementos comunes y su documentación de actualización correspondiente:

Verifique los requisitos básicos de EKS antes de realizar la actualización

AWS requiere ciertos recursos de su cuenta para completar el proceso de actualización. Si estos recursos no están presentes, el clúster no se puede actualizar. La actualización del plano de control requiere los siguientes recursos:

Verifique las direcciones IP disponibles

Para actualizar el clúster, Amazon EKS requiere hasta cinco direcciones IP disponibles de las subredes que se especificaron cuando creó el clúster.

Para comprobar que las subredes tienen suficientes direcciones IP para actualizar el clúster, puede ejecutar el siguiente comando:

CLUSTER=<cluster name>
aws ec2 describe-subnets --subnet-ids \
  $(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.resourcesVpcConfig.subnetIds' \
  --output text) \
  --query 'Subnets[*].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' \
  --output table

----------------------------------------------------
|                  DescribeSubnets                 |
+---------------------------+--------------+-------+
|  subnet-067fa8ee8476abbd6 |  us-east-1a  |  8184 |
|  subnet-0056f7403b17d2b43 |  us-east-1b  |  8153 |
|  subnet-09586f8fb3addbc8c |  us-east-1a  |  8120 |
|  subnet-047f3d276a22c6bce |  us-east-1b  |  8184 |
+---------------------------+--------------+-------+

El asistente de métricas CNI de la VPC se puede utilizar para crear un CloudWatch panel de control para las métricas de la VPC. Amazon EKS recomienda actualizar las subredes del clúster mediante la API UpdateClusterConfiguration "» antes de iniciar la actualización de una versión de Kubernetes si se está quedando sin direcciones IP en las subredes especificadas inicialmente durante la creación del clúster. Compruebe que las nuevas subredes que se le proporcionarán son las siguientes:

Considera la posibilidad de asociar bloques de CIDR adicionales si se agotan las direcciones IP del bloque de CIDR de la VPC existente. AWS permite la asociación de bloques de CIDR adicionales con su VPC de clúster existente, lo que amplía de manera efectiva su conjunto de direcciones IP. Esta expansión se puede lograr mediante la introducción de rangos de IP privadas adicionales (RFC 1918) o, si es necesario, rangos de IP públicas (que no sean RFC 1918). Debe agregar nuevos bloques de CIDR de la VPC y permitir que finalice la actualización de la VPC antes de que Amazon EKS pueda usar el nuevo CIDR. Después, puede actualizar las subredes a la VPC en función de los bloques de CIDR recién configurados.

Verifique el rol de IAM de EKS

Para comprobar que el rol de IAM está disponible y tiene la política de asunción de roles correcta en su cuenta, puede ejecutar los siguientes comandos:

CLUSTER=<cluster name>
ROLE_ARN=$(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.roleArn' --output text)
aws iam get-role --role-name ${ROLE_ARN##*/} \
  --query 'Role.AssumeRolePolicyDocument'

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Migre a EKS Add-ons

Amazon EKS instala automáticamente complementos como el complemento CNI de Amazon VPC para Kubernetes y CoreDNS para cada clústerkube-proxy. Add-ons puede autogestionarse o instalarse como Amazon EKS. Add-ons Amazon EKS Add-ons es una forma alternativa de administrar los complementos mediante la API de EKS.

Puede usar Amazon EKS Add-ons para actualizar versiones con un solo comando. Por ejemplo:

aws eks update-addon —cluster-name my-cluster —addon-name vpc-cni —addon-version version-number \
--service-account-role-arn arn:aws:iam::111122223333:role/role-name —configuration-values '{}' —resolve-conflicts PRESERVE

Compruebe si tiene algún EKS Add-ons con:

aws eks list-addons --cluster-name <cluster name>

Obtenga más información sobre los componentes que están disponibles como EKS Add-ons y cómo empezar.

Aprenda a proporcionar una configuración personalizada a un EKS Add-on.

Identifique y corrija el uso de API eliminado antes de actualizar el plano de control

Debe identificar el uso de las API eliminadas antes de actualizar su plano de control de EKS. Para ello, te recomendamos usar herramientas que puedan comprobar un clúster en ejecución o archivos de manifiesto de Kubernetes renderizados y estáticos.

Por lo general, la comprobación con los archivos de manifiesto estáticos es más precisa. Si se ejecutan en clústeres activos, estas herramientas pueden arrojar falsos positivos.

Una API de Kubernetes obsoleta no significa que la API se haya eliminado. Deberías consultar la política de obsolescencia de Kubernetes para saber cómo afecta la eliminación de la API a tus cargas de trabajo.

Cluster Insights

Cluster Insights es una función que proporciona información sobre problemas que pueden afectar a la capacidad de actualizar un clúster de EKS a versiones más recientes de Kubernetes. Amazon EKS selecciona y administra estos hallazgos y ofrece recomendaciones sobre cómo solucionarlos. Al aprovechar Cluster Insights, puede minimizar el esfuerzo dedicado a actualizar a las versiones más recientes de Kubernetes.

Para ver la información de un clúster de EKS, puedes ejecutar el comando:

aws eks list-insights --region <region-code> --cluster-name <my-cluster>

{
    "insights": [
        {
            "category": "UPGRADE_READINESS",
            "name": "Deprecated APIs removed in Kubernetes v1.29",
            "insightStatus": {
                "status": "PASSING",
                "reason": "No deprecated API usage detected within the last 30 days."
            },
            "kubernetesVersion": "1.29",
            "lastTransitionTime": 1698774710.0,
            "lastRefreshTime": 1700157422.0,
            "id": "123e4567-e89b-42d3-a456-579642341238",
            "description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes v1.29. Upgrading your cluster before migrating to the updated APIs supported by v1.29 could cause application impact."
        }
    ]
}

Para obtener un resultado más descriptivo sobre la información recibida, puede ejecutar el comando:

aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>

También tiene la opción de ver la información en la consola de Amazon EKS. Tras seleccionar su clúster de la lista de clústeres, los datos obtenidos se encuentran en la Upgrade Insights pestaña.

Si encuentra un clúster con Insight"status": ERROR, debe solucionar el problema antes de realizar la actualización del clúster. Ejecute el aws eks describe-insight comando que compartirá los siguientes consejos de corrección:

Recursos afectados:

"resources": [
      {
        "insightStatus": {
          "status": "ERROR"
        },
        "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null"
      }
]

API en desuso:

"deprecationDetails": [
      {
        "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas",
        "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas",
        "stopServingVersion": "1.29",
        "clientStats": [],
        "startServingReplacementVersion": "1.26"
      }
]

Acción recomendada a tomar:

"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."

Utilizar la información del clúster a través de la consola o la CLI de EKS ayuda a acelerar el proceso de actualización satisfactoria de las versiones del clúster de EKS. Obtenga más información en los siguientes recursos: * Documentos oficiales de EKS * Blog de lanzamiento de Cluster Insights.

Kube-no-trouble

Kube-no-troublees una utilidad de línea de comandos de código abierto con el comandokubent. Si la ejecutas kubent sin ningún argumento, usará tu KubeConfig contexto actual, escaneará el clúster e imprimirá un informe con las API que quedarán obsoletas y eliminadas.

kubent

4:17PM INF >>> Kube No Trouble `kubent` <<<
4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042)
4:17PM INF Initializing collectors and retrieving data
4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d
4:l INF Retrieved 93 resources from collector name=Cluster
4:17PM INF Retrieved 16 resources from collector name="Helm v3"
4:17PM INF Loaded ruleset name=custom.rego.tmpl
4:17PM INF Loaded ruleset name=deprecated-1-16.rego
4:17PM INF Loaded ruleset name=deprecated-1-22.rego
4:17PM INF Loaded ruleset name=deprecated-1-25.rego
4:17PM INF Loaded ruleset name=deprecated-1-26.rego
4:17PM INF Loaded ruleset name=deprecated-future.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.25 <<<
------------------------------------------------------------------------------------------
KIND                NAMESPACE     NAME             API_VERSION      REPLACE_WITH (SINCE)
PodSecurityPolicy   <undefined>   eks.privileged   policy/v1beta1   <removed> (1.21.0)

También se puede usar para escanear archivos de manifiesto estáticos y paquetes Helm. Se recomienda ejecutarlo kubent como parte de un proceso de integración continua (CI) para identificar los problemas antes de que se desplieguen los manifiestos. El escaneo de los manifiestos también es más preciso que el escaneo de clústeres activos.

Kube-no-trouble proporciona un ejemplo de cuenta y rol de servicio con los permisos adecuados para escanear el clúster.

Plutón

Otra opción es Plutón, que es similar kubent porque permite escanear un clúster activo, archivos de manifiesto, gráficos de control y tiene una GitHub acción que puedes incluir en tu proceso de CI.

pluto detect-all-in-cluster

NAME             KIND                VERSION          REPLACEMENT   REMOVED   DEPRECATED   REPL AVAIL
eks.privileged   PodSecurityPolicy   policy/v1beta1                 false     true         true

Recursos

Para comprobar que tu clúster no utilice las API obsoletas antes de la actualización, debes supervisar:

kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="podsecuritypolicies",subresource="",version="v1beta1"} 1

CLUSTER="<cluster_name>"
QUERY_ID=$(aws logs start-query \
 --log-group-name /aws/eks/${CLUSTER}/cluster \
 --start-time $(date -u --date="-30 minutes" "+%s") # or date -v-30M "+%s" on MacOS \
 --end-time $(date "+%s") \
 --query-string 'fields @message | filter `annotations.k8s.io/deprecated`="true"' \
 --query queryId --output text)

echo "Query started (query id: $QUERY_ID), please hold ..." && sleep 5 # give it some time to query

aws logs get-query-results --query-id $QUERY_ID

Lo que generará líneas si se utilizan las API obsoletas:

{
    "results": [
        [
            {
                "field": "@message",
                "value": "{\"kind\":\"Event\",\"apiVersion\":\"audit.k8s.io/v1\",\"level\":\"Request\",\"auditID\":\"8f7883c6-b3d5-42d7-967a-1121c6f22f01\",\"stage\":\"ResponseComplete\",\"requestURI\":\"/apis/policy/v1beta1/podsecuritypolicies?allowWatchBookmarks=true\\u0026resourceVersion=4131\\u0026timeout=9m19s\\u0026timeoutSeconds=559\\u0026watch=true\",\"verb\":\"watch\",\"user\":{\"username\":\"system:apiserver\",\"uid\":\"8aabfade-da52-47da-83b4-46b16cab30fa\",\"groups\":[\"system:masters\"]},\"sourceIPs\":[\"::1\"],\"userAgent\":\"kube-apiserver/v1.24.16 (linux/amd64) kubernetes/af930c1\",\"objectRef\":{\"resource\":\"podsecuritypolicies\",\"apiGroup\":\"policy\",\"apiVersion\":\"v1beta1\"},\"responseStatus\":{\"metadata\":{},\"code\":200},\"requestReceivedTimestamp\":\"2023-10-04T12:36:11.849075Z\",\"stageTimestamp\":\"2023-10-04T12:45:30.850483Z\",\"annotations\":{\"authorization.k8s.io/decision\":\"allow\",\"authorization.k8s.io/reason\":\"\",\"k8s.io/deprecated\":\"true\",\"k8s.io/removed-release\":\"1.25\"}}"
            },
[...]

Actualiza las cargas de trabajo de Kubernetes. Usa kubectl-convert para actualizar los manifiestos

Una vez que hayas identificado qué cargas de trabajo y manifiestos deben actualizarse, es posible que tengas que cambiar el tipo de recurso en tus archivos de manifiesto (por ejemplo, a). PodSecurityPolicies PodSecurityStandards Para ello, será necesario actualizar la especificación del recurso e investigar más en función del recurso que se vaya a reemplazar.

Si el tipo de recurso sigue siendo el mismo pero es necesario actualizar la versión de la API, puedes usar el kubectl-convert comando para convertir automáticamente tus archivos de manifiesto. Por ejemplo, para convertir una implementación anterior enapps/v1. Para obtener más información, consulta Cómo instalar el complemento de conversión de kubectl en el sitio web de Kubernetes.

kubectl-convert -f <file> --output-version <group>/<version>

Configure PodDisruptionBudgets la topología SpreadConstraints para garantizar la disponibilidad de sus cargas de trabajo mientras se actualiza el plano de datos

Asegúrese de que sus cargas de trabajo tengan la topología adecuada PodDisruptionBudgets SpreadConstraints para garantizar su disponibilidad mientras se actualiza el plano de datos. No todas las cargas de trabajo requieren el mismo nivel de disponibilidad, por lo que debe validar la escala y los requisitos de su carga de trabajo.

Asegúrese de que las cargas de trabajo estén distribuidas en varias zonas de disponibilidad y en varios hosts con distribuciones de topología para tener un mayor nivel de confianza en que las cargas de trabajo migrarán al nuevo plano de datos automáticamente y sin incidentes.

Este es un ejemplo de carga de trabajo que siempre tendrá el 80% de las réplicas disponibles y distribuirá las réplicas entre zonas y hosts

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp
spec:
  minAvailable: "80%"
  selector:
    matchLabels:
      app: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
        name: myapp
        resources:
          requests:
            cpu: "1"
            memory: 256M
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule

AWS Resilience Hub ha agregado Amazon Elastic Kubernetes Service (Amazon EKS) como recurso compatible. Resilience Hub proporciona un lugar único para definir, validar y realizar un seguimiento de la resiliencia de sus aplicaciones, de modo que pueda evitar tiempos de inactividad innecesarios causados por interrupciones del software, la infraestructura o las operaciones.

Utilice Managed Node Groups o Karpenter para simplificar las actualizaciones del plano de datos

Tanto Managed Node Groups como Karpenter simplifican las actualizaciones de nodos, pero adoptan enfoques diferentes.

Los grupos de nodos administrados automatizan el aprovisionamiento y la administración del ciclo de vida de los nodos. Esto significa que puedes crear, actualizar automáticamente o terminar nodos con una sola operación.

En la configuración predeterminada, Karpenter crea automáticamente nuevos nodos utilizando la última AMI optimizada de EKS compatible. A medida que EKS publique las AMI optimizadas para EKS actualizadas o se actualice el clúster, Karpenter comenzará a usar estas imágenes automáticamente. Karpenter también implementa Node Expiry para actualizar los nodos.

Karpenter se puede configurar para usar AMI personalizadas. Si usa AMI personalizadas con Karpenter, es responsable de la versión de kubelet.

Confirme la compatibilidad de la versión con los nodos existentes y el plano de control

Antes de continuar con la actualización de Kubernetes en Amazon EKS, es fundamental garantizar la compatibilidad entre los grupos de nodos gestionados, los nodos autogestionados y el plano de control. La compatibilidad viene determinada por la versión de Kubernetes que utilice y varía en función de los distintos escenarios. Tácticas:

Habilite la caducidad de los nodos para los nodos gestionados por Karpenter

Una forma en que Karpenter implementa las actualizaciones de nodos es mediante el concepto de caducidad de los nodos. Esto reduce la planificación necesaria para las actualizaciones de los nodos. Cuando estableces un valor para ttl SecondsUntilExpired en tu aprovisionador, se activa la caducidad del nodo. Cuando los nodos alcanzan la antigüedad definida en segundos, se vacían y eliminan de forma segura. Esto es así incluso si están en uso, lo que te permite reemplazar los nodos por instancias actualizadas recién aprovisionadas. Cuando se reemplaza un nodo, Karpenter usa las AMI más recientes. EKS-optimized Para obtener más información, consulte Disruption en el sitio web de Karpenter.

Karpenter no añade automáticamente fluctuación a este valor. Para evitar una interrupción excesiva de la carga de trabajo, defina un presupuesto para interrumpir los módulos, tal y como se muestra en la documentación de Kubernetes.

Si configuras ttl SecondsUntilExpired en un aprovisionador, esto se aplica a los nodos existentes asociados al aprovisionador.

Utilice la función Drift para los nodos administrados por Karpenter

La función Drift de Karpenter puede actualizar automáticamente Karpenter-provisioned los nodos para que permanezcan sincronizados con el plano de control de EKS. Actualmente, Karpenter Drift necesita habilitarse mediante una puerta de funciones. https://karpenter.sh/docs/reference/settings/#feature-gates La configuración predeterminada de Karpenter usa la EKS-Optimized AMI más reciente para la misma versión principal y secundaria que el plano de control del clúster EKS.

Una vez completada la actualización de un clúster de EKS, la función Drift de Karpenter detectará que los Karpenter-provisioned nodos utilizan las EKS-Optimized AMI de la versión anterior del clúster y acordonará, agotará y reemplazará automáticamente esos nodos. Para permitir que los pods se trasladen a nuevos nodos, siga las prácticas recomendadas de Kubernetes y establezca las cuotas de recursos de los pods adecuadas y utilice los presupuestos de interrupción de los pods (PDB). El desaprovisionamiento de Karpenter activará previamente los nodos de reemplazo en función de las solicitudes de recursos del pod y respetará las PDB al desaprovisionar los nodos.

Utilice eksctl para automatizar las actualizaciones de los grupos de nodos autogestionados

Los grupos de nodos autogestionados son instancias de EC2 que se implementaron en su cuenta y se adjuntaron al clúster fuera del servicio EKS. Por lo general, se implementan y administran mediante algún tipo de herramienta de automatización. Para actualizar los grupos de nodos autogestionados, debe consultar la documentación de las herramientas.

Por ejemplo, eksctl admite la eliminación y el drenaje de nodos autogestionados.

Algunas herramientas comunes incluyen:

Haga una copia de seguridad del clúster antes de actualizarlo

Las nuevas versiones de Kubernetes introducen cambios importantes en su clúster de Amazon EKS. Puede deshacer una actualización en un plazo de 7 días, pero le recomendamos que haga una copia de seguridad del clúster antes de la actualización.

Puede hacer una copia de seguridad de su clúster con AWS Backup, un servicio totalmente gestionado. También puede usar Velero, una herramienta de código abierto respaldada por la comunidad.

Tenga en cuenta que solo puede crear clústeres nuevos para las versiones de Kubernetes que EKS admite actualmente. Si la versión que ejecuta actualmente su clúster sigue siendo compatible y se produce un error en la actualización, puede crear un nuevo clúster con la versión original y restaurar el plano de datos. Tenga en cuenta que los recursos de AWS, incluida la IAM, no se incluyen en la copia de seguridad. Debe volver a crear estos recursos.

Reinicie las implementaciones de Fargate después de actualizar el plano de control

Para actualizar los nodos del plano de datos de Fargate, debe volver a implementar las cargas de trabajo. Puede identificar qué cargas de trabajo se están ejecutando en los nodos de Fargate enumerando todos los pods con la opción. -o wide Cualquier nombre de nodo que comience por fargate- tendrá que volver a implementarse en el clúster.

Evalúe Blue/Green los clústeres como una alternativa a las actualizaciones de clústeres locales

Algunos clientes prefieren adoptar una estrategia de blue/green actualización. Esto puede tener beneficios, pero también incluye desventajas que deben tenerse en cuenta.

Los beneficios incluyen:

Algunas desventajas incluyen:

Si bien esta estrategia es posible, es más cara que una actualización local y requiere más tiempo para la coordinación y las migraciones de la carga de trabajo. Puede ser necesaria en algunas situaciones y debe planificarse con cuidado.

Con altos grados de automatización y sistemas declarativos como este GitOps, esto puede ser más fácil de hacer. Tendrá que tomar precauciones adicionales para evitar que las cargas de trabajo estén en buen estado, de modo que se hagan copias de seguridad de los datos y se migren a nuevos clústeres.

Consulte estas publicaciones de blog para obtener más información:

Haga un seguimiento de los principales cambios planificados en el proyecto Kubernetes: piense en el futuro

No te fijes solo en la próxima versión. Revisa las nuevas versiones de Kubernetes a medida que se publiquen e identifica los cambios principales. Por ejemplo, algunas aplicaciones utilizaban directamente la API de Docker y en Kubernetes se eliminó la compatibilidad con la interfaz de ejecución de contenedores (CRI) para Docker (también conocida como Dockershim). 1.24 Este tipo de cambio requiere más tiempo para prepararse.

Revisa todos los cambios documentados de la versión a la que estás actualizando y anota los pasos de actualización necesarios. Además, anote los requisitos o procedimientos específicos de los clústeres gestionados por Amazon EKS.

Guía específica sobre la eliminación de funciones

Eliminación de Dockershim en la versión 1.25: utilice el detector para Docker Socket (DDS)

La AMI optimizada de EKS para la versión 1.25 ya no incluye soporte para Dockershim. Si tienes una dependencia de Dockershim, por ejemplo, si estás montando el socket Docker, tendrás que eliminar esas dependencias antes de actualizar tus nodos de trabajo a la versión 1.25.

Busca instancias en las que dependas del socket Docker antes de actualizar a la versión 1.25. Recomendamos usar Detector for Docker Socket (DDS), un complemento de kubectl. .

Eliminación de la versión PodSecurityPolicy 1.25: migración a los estándares de seguridad de Pod o a una solución de política como código

PodSecurityPolicydejó de estar disponible en Kubernetes 1.21 y se ha eliminado en Kubernetes 1.25. Si lo usas PodSecurityPolicy en tu clúster, debes migrar a los estándares de seguridad para pods (PSS) integrados de Kubernetes o a una solución basada en políticas como código antes de actualizar el clúster a la versión 1.25 para evitar interrupciones en tus cargas de trabajo.

AWS publicó una sección detallada de preguntas frecuentes en la documentación de EKS. https://docs.aws.amazon.com/eks/latest/userguide/pod-security-policy-removal-faq.html

Revisa las mejores prácticas de los estándares de seguridad para cápsulas (PSS) y de admisión de seguridad para cápsulas (PSA).

Consulta la entrada del blog sobre PodSecurityPolicy obsolescencia en el sitio web de Kubernetes.

El controlador de In-Tree almacenamiento en la versión 1.23 dejó de estar disponible: migre a los controladores de la interfaz de almacenamiento en contenedores (CSI)

La interfaz de almacenamiento en contenedores (CSI) se diseñó para ayudar a Kubernetes a reemplazar sus actuales mecanismos de controladores de almacenamiento integrados en el árbol. La característica de migración de la interfaz de almacenamiento de contenedores (CSI) de Amazon EBS está habilitada de forma predeterminada en Amazon EKS 1.23 y los clústeres posteriores. Si tiene pods ejecutándose en una versión 1.22 o un clúster anterior, debe instalar el controlador CSI de Amazon EBS antes de actualizar el clúster a la versión para evitar la interrupción del servicio. 1.23

Consulta las preguntas frecuentes sobre la migración del CSI a Amazon EBS.

Recursos adicionales

ClowdHaus Guía de actualización de EKS

ClowdHaus La guía de actualización de EKS es una CLI que ayuda a actualizar los clústeres de Amazon EKS. Puede analizar un clúster para detectar cualquier problema potencial que pueda solucionarse antes de la actualización.

GoNoGo

GoNoGoes una herramienta de fase inicial que permite determinar la fiabilidad de los complementos de su clúster en cuanto a la actualización.