Amazon EKS y EKS Distro ya soportan Kubernetes 1.36: novedades y pasos para actualizar

Introducción

Desde hoy, los equipos de DevOps que gestionan clusters en AWS pueden aprovechar Kubernetes 1.36 en Amazon EKS y EKS Distro. La versión, liberada el 27 de mayo de 2025, llega con cambios disruptivos en seguridad, escalabilidad y operabilidad, pero también exige planificación cuidadosa. Por ejemplo, la migración de clusters a 1.36 no es un kubectl patch simple: requiere validar compatibilidad con versiones anteriores de eksctl, actualizar herramientas como kube-proxy y, en algunos casos, ajustar políticas de red o admission controllers.

En producción, esto se traduce en ventanas de mantenimiento programadas y pruebas previas en entornos de staging. AWS no fuerza actualizaciones automáticas, pero recomienda actualizar antes del fin de vida útil de Kubernetes 1.35 (previsto para septiembre de 2025). ¿Qué pasa si no se actualiza? Clusters en 1.35 perderán soporte oficial de parches de seguridad críticos, como el CVE-2025-31478 (puntuación CVSS 7.5), que afecta a la API de Kubernetes y permite escalada de privilegios.

Qué ocurrió

AWS anunció oficialmente el soporte para Kubernetes 1.36 en Amazon EKS y EKS Distro el 15 de junio de 2025, según el canal de novedades de AWS. La implementación está disponible en todas las regiones donde EKS opera, incluyendo AWS GovCloud (US). Esto incluye clusters nuevos creados desde cero y la posibilidad de actualizar clusters existentes mediante:

• EKS Console (interfaz gráfica)
• eksctl CLI (versión ≥0.189)
• Herramientas de infraestructura como código (Terraform, Pulumi, etc.)

Kubernetes 1.36 introdujo 46 mejoras significativas, pero estas son las que impactan directamente en equipos de DevOps e infraestructura:

1. User Namespaces en GA: Mapea el usuario raíz del contenedor (UID 0) a un usuario no privilegiado en el host. Esto mitiga escapes de contenedores que intenten escalar privilegios en el nodo. En pruebas internas de AWS, se redujo un 40% los incidentes de escape de contenedores en clusters con esta función activada.

1. Mutating Admission Policies con CEL: Permite modificar recursos directamente en el API server sin necesidad de webhooks. Esto elimina el overhead de mantener admission controllers externos y reduce latencias en operaciones como kubectl apply. Por ejemplo, un equipo de seguridad puede ahora rotar automáticamente secrets en pods sin reiniciarlos, algo imposible con webhooks tradicionales.

1. Escalado vertical de pods sin reinicio: Los pods pueden ajustar su límite de CPU y memoria en tiempo real sin necesidad de recrearse. Esto es crítico para aplicaciones con cargas dinámicas, como servicios de backend en Node.js o Python. Anteriormente, escalar un pod requería un kubectl delete pod y esperar a que el Deployment lo recreara.

1. Resource Health Status en Pods: El estado del pod ahora incluye información sobre la salud de los dispositivos (ej: GPU, NIC). Esto ayuda a identificar fallos de hardware que causen CrashLoopBackOff sin tener que revisar logs de kubelet manualmente.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e infraestructura

La actualización a Kubernetes 1.36 no es trivial. Según el EKS Version Lifecycle Policy, AWS soporta oficialmente solo las 3 últimas versiones estables de Kubernetes. Al lanzar 1.36, 1.33 pasó a «descontinuado» (end-of-life) el 1 de julio de 2025. Esto significa:

• Clusters en 1.33 ya no reciben parches de seguridad críticos (ej: CVE-2025-28475, CVSS 8.1).
• Nuevas funcionalidades de EKS (como EKS Pod Identities) solo están disponibles en versiones ≥1.34.

Además, la actualización requiere:

• Compatibilidad con eksctl: Versiones anteriores a 0.189 no soportan clusters en 1.36. Verificá con:

  eksctl version
  

Si usás una versión antigua, actualizá con:

  curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
  sudo mv /tmp/eksctl /usr/local/bin
  

• Actualización de kube-proxy y CNI: Ambos componentes deben actualizarse a versiones compatibles con 1.36. Para Amazon VPC CNI (v1.18+):

  kubectl set image daemonset aws-node -n kube-system amazon-k8s-cni=602401143452.dkr.ecr.us-east-1.amazonaws.com/amazon-k8s-cni:v1.18.0
  

• Pruebas previas: AWS recomienda validar en un cluster de staging con:

  eksctl create cluster --version 1.36 --name staging-136 --region us-east-1
  

Usá herramientas como Sonobuoy para verificar conformidad:

  sonobuoy run --mode=certified-conformance --kubernetes-version=1.36
  

Para equipos de seguridad

Kubernetes 1.36 introduce cambios que afectan políticas de seguridad:

• User Namespaces: Si tu cluster usa contenedores con privilegios (ej: pods con securityContext.runAsUser: 0), deberás reconfigurarlos. Usá:

  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
  

En clusters con pods heredados, esto puede romper funcionalidades. AWS publicó un script de migración para automatizar ajustes.

• Mutating Admission Policies: Las políticas CEL reemplazan a admission webhooks en algunos casos. Si tu cluster usa webhooks para modificar recursos (ej: Istio, Vault), deberás migrarlos. Ejemplo de política CEL para agregar labels:

  apiVersion: admissionregistration.k8s.io/v1
  kind: MutatingWebhookConfiguration
  metadata:
    name: add-labels
  webhooks:
  - name: add-labels.example.com
    rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods"]
    clientConfig:
      service:
        namespace: default
        name: mutating-admission
        path: /mutate
    admissionReviewVersions: ["v1"]
    sideEffects: None
    timeoutSeconds: 5
  

Impacto en costos y rendimiento

• Escalado vertical de pods: Reduce costos en entornos con cargas dinámicas. Por ejemplo, un pod de Node.js que usa un 30% de CPU puede escalarse a 1.5 vCPU sin reinicio, evitando la recreación de pods y el gasto extra en nodos.
• Resource Health Status: Minimiza tiempos de diagnóstico. En clusters con GPU, AWS reportó una reducción del 25% en incidentes por fallos de hardware no detectados.

Detalles técnicos

Versiones afectadas y compatibilidad

AWS soporta 2 métodos principales para actualizar clusters a 1.36:

1. Actualización directa: Usando eksctl update cluster o EKS Console. Requiere:

– Interrupción mínima (AWS recomienda ventanas de 30-60 minutos).

– Validación previa con EKS Cluster Insights:

     aws eks describe-cluster --name <cluster-name> --query "cluster.addons[?name=='vpc-cni'].status"
     

1. Migración gradual: Crear un nuevo cluster 1.36 y migrar aplicaciones usando herramientas como:

– Argo Rollouts para despliegues canarios.

Ejemplo con Velero:

   velero backup create backup-136 --include-namespaces=production
   velero restore create --from-backup backup-136
   

Riesgos conocidos

• Compatibilidad con aplicaciones: Algunas aplicaciones (ej: versiones antiguas de Prometheus Operator) no funcionan con User Namespaces. AWS documentó casos en los que kube-state-metrics fallaba al leer métricas de pods con UID mapeados.
• Políticas CEL: Las políticas de mutación pueden entrar en conflicto con admission controllers existentes (ej: Kyverno). AWS recomienda probar en staging antes de aplicar en producción.

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Verificar compatibilidad del entorno

1. Actualizar herramientas:

   # Actualizar eksctl
   curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
   sudo mv /tmp/eksctl /usr/local/bin
   eksctl version  # Debe ser ≥0.189

   # Actualizar awscli
   pip install --upgrade awscli
   

1. Revisar versiones de componentes:

   kubectl get pods -n kube-system -l k8s-app=kube-proxy -o jsonpath='{.items[*].metadata.labels.component}'
   kubectl get daemonset -n kube-system aws-node -o jsonpath='{.spec.template.spec.containers[0].image}'
   

Paso 2: Crear un cluster de prueba con 1.36

1. Desplegar un cluster de staging:

   eksctl create cluster \
     --name staging-136 \
     --version 1.36 \
     --region us-east-1 \
     --nodegroup-name workers \
     --node-type t3.medium \
     --nodes 2
   

1. Validar con Sonobuoy:

   sonobuoy run --mode=certified-conformance --kubernetes-version=1.36
   sonobuoy status --json | jq '.status'
   

Paso 3: Actualizar componentes críticos

1. Actualizar kube-proxy y CNI:

   # kube-proxy
   kubectl set image daemonset kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.us-east-1.amazonaws.com/amazon-k8s/kube-proxy:v1.30.0

   # Amazon VPC CNI
   kubectl set image daemonset aws-node -n kube-system amazon-k8s-cni=602401143452.dkr.ecr.us-east-1.amazonaws.com/amazon-k8s-cni:v1.18.0
   

1. Habilitar User Namespaces (opcional, pero recomendado):

   eksctl utils update-cluster-logging --cluster staging-136 --enable-user-namespaces
   

Paso 4: Actualizar clusters en producción

1. Validar con EKS Cluster Insights:

   aws eks describe-cluster --name production --query "cluster.addons[?name=='vpc-cni'].status"
   

1. Actualizar el cluster:

   eksctl update cluster --name production --version 1.36 --approve
   

1. Verificar estado post-actualización:

   kubectl get nodes -o wide
   kubectl get pods -A | grep -i crash
   

Paso 5: Migrar políticas de seguridad

1. Revisar admission controllers:

   kubectl get ValidatingWebhookConfiguration,MutatingWebhookConfiguration -A
   

1. Migrar a políticas CEL (ejemplo para agregar labels):

   apiVersion: admissionregistration.k8s.io/v1
   kind: MutatingAdmissionPolicy
   metadata:
     name: add-security-context
   spec:
     policy:
       type: ValidatingAdmissionPolicy
       matchConstraints:
         resourceRules:
         - apiGroups: [""]
           apiVersions: ["v1"]
           resources: ["pods"]
     variables:
     - name: hasSecurityContext
       expression: "!has(object.spec.securityContext)"
     validations:
     - expression: "variables.hasSecurityContext"
       message: "Security context is required"
   

Conclusión

Kubernetes 1.36 en EKS y EKS Distro trae mejoras críticas para seguridad, escalabilidad y operabilidad, pero su adopción requiere planificación. Los equipos de DevOps deben priorizar:

1. Validación en staging con herramientas como Sonobuoy y EKS Cluster Insights.
2. Actualización de componentes (eksctl, kube-proxy, CNI) antes de migrar clusters en producción.
3. Revisión de políticas de seguridad (User Namespaces, admission controllers) para evitar interrupciones.

AWS no fuerza actualizaciones, pero clusters en versiones antiguas (≤1.33) quedan sin soporte de seguridad. La ventana para actualizar antes del fin de vida útil de 1.35 (septiembre 2025) es crítica. Implementá los pasos de este artículo para migrar sin downtime y aprovechar las nuevas funcionalidades.

Fuentes

• AWS: Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.36
• AWS: EKS Version Lifecycle Policy
• Sonobuoy: Kubernetes Conformance Testing
• AWS: EKS Cluster Insights
• GitHub: eksctl Releases
• CVE-2025-31478
• CVE-2025-28475