DEV Community: Rubén Rodríguez

EKS Auto Mode: Kubernetes sin drama😝

Rubén Rodríguez — Mon, 23 Mar 2026 08:07:05 +0000

Llevábamos tiempo queriendo dedicarle un rato a EKS Auto Mode, pero entre proyectos, eventos y vacaciones no conseguíamos encontrar ese hueco. Hoy lo hemos encontrado.

Y es que una de las conversaciones recurrentes con compañeros, clientes y jefes es precisamente cómo la tecnología está evolucionando para automatizar capas de infraestructura que antes requerían expertise y horas de configuración.
Nuestra respuesta es siempre la misma: la tecnología no elimina el conocimiento. Donde antes necesitabas configurar Karpenter, gestionar AMIs, parchear nodos y mantener add-ons... ahora puedes focalizarte en arquitectura, seguridad y en construir cosas que aporten valor de otra manera.

¿Qué es EKS Auto Mode?

Podríamos explicarlo de muchas maneras pero ya nos conocéis, nos gusta ser directos:

AWS gestiona por ti el autoscaling de nodos (con Karpenter), networking de pods, load balancing, DNS, almacenamiento EBS, parches del SO y rotación de nodos. Tú te centras en tus cargas de trabajo.

¿Qué ventajas nos da esto?

AWS gestiona los add-ons core. No los ves, no los tocas, no los parcheas.
Karpenter gestionado por AWS, sin instalación ni configuración.
NodePools y NodeClasses disponibles para tener flexibilidad sobre tus nodos.
Optimización de costes gracias a la consolidación automática de Karpenter.

¡Al lio!

Para el test hemos utilizado el módulo oficial de la community eks-auto-mode, modificando la llamada para adaptarla a este caso. Lo importante del módulo es que con "compute_config.enabled = true" activamos Auto Mode completo.

Parece broma pero sí.🥶Es así de fácil.🥶

¿Qué crea Auto Mode automáticamente?

Una vez desplegado el cluster, veamos como se gestiona Karpenter:

kubectl get nodeclass NAME ROLE READY AGE default awtwins-cluster-eks-auto-20260322210213399200000003 True 55m

kubectl get nodepools NAME NODECLASS NODES READY AGE general-purpose default 0 True 56m

Auto Mode crea automáticamente el NodeClass y el NodePool correspondiente.
Puedes añadir configuración extra de almacenamiento, restricciones de instancias, límites de capacidad o tags.

El test de autoscaling

Para validar que todo funciona usamos el deployment de pause que usa AWS en sus ejemplos oficiales de Karpenter y que ya hemos utilizado anteriormente. No hace nada, solo consume recursos.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 5
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: "1"
              memory: "1Gi"

Aplicamos el manifest y vemos que tenemos los pods creandose correctamente:

Vamos a EC2 mediante la consola y podremos ver como Karpenter está creando el nodo necesario para desplegar este tipo de carga.

Para validar que el desescalado también funciona sin problema procedemos a escalar el deployment a 0 replicas:

kubectl scale deployment inflate --replicas=0

El resultado habla por sí solo: nodos provisionados en segundos, pods corriendo, y consolidación automática al bajar la carga. Sin tocar nada más.

En este post solo estamos validando el autoscaling, pero el mismo principio aplica para todo lo que mencionamos antes como load balancing, networking, DNS, almacenamiento, parches de nodos... Todo eso se gestiona por AWS sin que tengas que instalar, configurar ni actualizar nada. Como ya sabéis, somos muy fans de Karpenter, pero la gracia de Auto Mode es que Karpenter es solo una pieza de todo lo que te quitas de encima.

Adjuntamos una imagen descriptiva como comparación:

¿Cuánto cuesta?

El modelo de precios de EKS Auto Mode tiene tres componentes importantes:

Precio del cluster igual que en EKS estándar.
Precio de las EC2 desplegadas.
Precio de Auto Mode, aprox un 12% extra sobre el coste de cada instancia.

Nuestra opinión

Como hemos hablado de estos temas en diferentes foros con muchos compañeros, llega el momento más esperado...🥁

EKS Auto Mode no es solo una feature más. Es un cambio en cómo operar Kubernetes en AWS. Pasamos de gestionar un cluster a consumirlo. Y eso, bien entendido, desgasta menos y minimiza problemas.

Además, como ya vimos en nuestro anterior post de awtwins, si le sumamos features como ArgoCD Capability la vida nos vuelve a sonreír con un cluster magnífico con mucha menos gestión que antes. Los que ya nos conocéis sabéis que para nosotros este tipo de soluciones siempre son un SÍ... si lo puedes pagar, claro💰😄

Como siempre, esperamos vuestros comentarios y feedback👇

Automatiza el despliegue de EKS y Argo CD con Terraform

Rubén Rodríguez — Sun, 05 Jan 2025 21:25:48 +0000

Sabemos que 2024 ha sido una locura y, seamos sinceros, no hemos tenido todo el tiempo que nos gustaría para dedicarle a esas horas extras para la comunidad 😝. Pero, aprovechando los primeros días de 2025, hemos encontrado el hueco que necesitábamos para seguir dándole caña a esta serie que teníamos en mente.

En el capítulo anterior, vimos cómo Argo CD nos ayuda a gestionar nuestras aplicaciones en EKS con ese enfoque GitOps que tanto nos gusta. Sin embargo, sabemos que la teoría siempre se queda corta 🥶. Por eso, en este capítulo vamos a desplegar un clúster de EKS con Argo CD utilizando Terraform. Hablaremos de los requisitos, cómo conectar repositorios y cómo validar que todo está funcionando para que puedas empezar a hacer tus propias pruebas.

En esta ocasión, no vamos a complicarnos con pipelines de despliegue ni nos centraremos demasiado en best practices, gestión de secretos u optimización del código. Lo que buscamos aquí es entender cómo Argo CD puede hacer que nuestros despliegues sean más ágiles y los beneficios que aporta. Pero no os preocupéis, si el tiempo (y la motivación 😅) nos lo permite, ampliaremos el scope de estos posts para cubrir todos esos temas más adelante.

🛠️Requisitos🛠️

Terraform - https://developer.hashicorp.com/terraform/install
GitHub - https://github.com/
Kubectl - https://kubernetes.io/docs/tasks/tools/
CLI de Argo CD - https://argo-cd.readthedocs.io/en/stable/cli_installation/

Como ya hemos comentado, el clúster de EKS con Argo CD lo desplegaremos utilizando Terraform. Para que podáis probarlo por vuestra cuenta, hemos subido el código al siguiente repositorio:
https://github.com/rnanudevops/eks-argocd-awsespanol

Este módulo ya lo utilizamos en un post anterior para el despliegue y test de Karpenter (dale un vistazo aquí: https://dev.to/aws-espanol/optimiza-tu-cluster-eks-con-karpenter-3mk1).
Esta vez, hemos añadido la configuración necesaria para incluir el despliegue de Argo CD.

Antes de utilizar este código, recomendamos revisar lo siguiente:

TAGS: Modifica los tags para personalizar el despliegue según tus necesidades.
Bucket S3: Asegúrate de configurar el bucket donde se almacenará el estado de Terraform.

Este módulo despliega todos los servicios necesarios para el despliegue de un clúster de EKS, incluyendo la configuración de networking.

Una vez desplegado el código de Terraform, veamos cómo acceder tanto al clúster EKS como a Argo CD.

En nuestro caso, hemos llamado al clúster awtwins-cluster:

Para acceder al clúster, necesitamos actualizar el contexto de kubectl mediante el siguiente comando:

aws eks --region eu-west-1 update-kubeconfig --name awtwins-cluster

Para validar que la conexión se ha establecido correctamente, podemos ejecutar:

kubectl get pods -A

Esto nos devolverá:

NAMESPACE     NAME                                                READY   STATUS    RESTARTS   AGE
argocd        argocd-application-controller-0                     1/1     Running   0          6m23s
argocd        argocd-applicationset-controller-5db4d64b99-72k5m   1/1     Running   0          6m23s
argocd        argocd-dex-server-67d695d958-4p4dt                  1/1     Running   0          6m23s
argocd        argocd-notifications-controller-5795d744fd-sxhjz    1/1     Running   0          6m23s
argocd        argocd-redis-5688bd4c9f-hg7zk                       1/1     Running   0          6m23s
argocd        argocd-repo-server-84d9d8fcfb-dsnfj                 1/1     Running   0          6m23s
argocd        argocd-server-d5f5767b6-4ffw8                       1/1     Running   0          6m23s
kube-system   aws-node-kzx4v                                      2/2     Running   0          7m28s
kube-system   aws-node-wwn2g                                      2/2     Running   0          7m23s
kube-system   coredns-844dbb9f6f-52lv9                            1/1     Running   0          9m53s
kube-system   coredns-844dbb9f6f-7khjt                            1/1     Running   0          9m53s
kube-system   kube-proxy-2dm9t                                    1/1     Running   0          7m23s
kube-system   kube-proxy-zn2lv                                    1/1     Running   0          7m28s

El siguiente paso es obtener la dirección de Argo CD, expuesta mediante un LoadBalancer que se incluye en el código de Terraform. Para ello, ejecutamos:

kubectl -n argocd get svc argocd-server

NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)                      AGE
argocd-server   LoadBalancer   172.20.193.200   ab577983472254f28a7ae93e22a478af-2061443254.eu-west-1.elb.amazonaws.com   80:30482/TCP,443:30189/TCP   10m

Copiaremos el valor de EXTERNAL-IP y accederemos a esta dirección desde el navegador.

Por defecto, Argo CD genera un usuario administrador (admin) y un password inicial. Para obtener este password, ejecuta el siguiente comando:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Con estas credenciales (usuario: admin y el password generado), accedemos a Argo CD.
🚨Este usuario nunca debe usarse en entornos productivos y se recomienda deshabilitarlo.🚨

Una vez dentro de Argo CD, el primer paso es configurar el repositorio donde almacenaremos nuestras aplicaciones. Para simplificar el escenario, utilizaremos la CLI de Argo CD. Esto nos permitirá realizar la configuración de forma sencilla y eficiente.

Primero, conectamos la CLI a Argo CD utilizando el siguiente comando e introduciendo las credenciales:

argocd login ab577983472254f28a7ae93e22a478af-2061443254.eu-west-1.elb.amazonaws.com --insecure
Username: admin
Password:
'admin:login' logged in successfully
Context 'ab577983472254f28a7ae93e22a478af-2061443254.eu-west-1.elb.amazonaws.com' updated

En este ejemplo, utilizaremos GitHub como repositorio, pero puedes usar otros como BitBucket o GitLab. Debes generar un repositorio y un usuario con los permisos necesarios.

Una vez listo, añade el repositorio a Argo CD utilizando:

argocd repo add <URL repositorio> --username <user> --password <token/password>

Accede a Argo CD y comprueba que el repositorio aparece en la sección Settings > Repositories, confirmando que se ha conectado correctamente.

Con esto, ya hemos configurado nuestro entorno de EKS y Argo CD y hemos conectado un repositorio para empezar a gestionar nuestras aplicaciones. 🚀

En el próximo post, veremos cómo desplegar aplicaciones en Argo CD y qué estrategias y buenas prácticas podemos utilizar para nuestros despliegues.

💬 Y recuerda, tus comentarios y opiniones son más que bienvenidos. 😝

Optimiza tu cluster EKS con Karpenter

Rubén Rodríguez — Wed, 11 Sep 2024 22:42:17 +0000

¡Después de unas merecidas vacaciones, volvemos a la carga!😁

En nuestra última publicación, hablamos de Backstage, la plataforma open-source de Spotify para gestionar infraestructura en AWS con Terraform.

Esta vez, vamos a hablar sobre uno de los temas que está siendo ‘trending topic’ en la gestión de escalado de Kubernetes: Karpenter. Durante este mes de Agosto se ha lanzado su primera versión estable y sin duda merecía un post relacionado. 🎉

Una de las grandes ventajas de Kubernetes es su capacidad de escalar según la demanda. Pero gestionar este escalado de los nodos puede ser complicado. Necesitas asegurarte de que haya suficientes nodos para desplegar tus aplicaciones, pero tampoco quieres pagar por más recursos de los necesarios. Aquí es donde entra Karpenter.🧙‍♂️

Karpenter ofrece un escalado rápido y flexible, seleccionando automáticamente las instancias más optimizadas y rentables en función de la demanda. Además, es una solución relativamente fácil de implementar... ¡suena difícil de creer, ¿verdad?!😱

Para desplegar esta solución, hemos utilizado el siguiente repositorio:

Karpenter Example

El código utilizado automatiza el despliegue de un clúster de EKS con 2 nodos m5.large, las VPC necesarias, y los addons coredns, eks-pod-identity-agent, kube-proxy, vpc-cni, además de la solución de Karpenter, incluyendo el NodePool y el EC2NodeClass necesarios para su funcionamiento. Adicionalmente, también despliega un Deployment que utilizaremos para pruebas.

Para su uso, debemos modificar las llamadas a los módulos para que apunten directamente al repositorio correspondiente.

Para ello copiaremos el fichero main.tf y realizaremos las siguientes modificaciones:

module "eks" {
  source = "github.com/terraform-aws-modules/terraform-aws-eks"
}

module "karpenter" {
  source = "github.com/terraform-aws-modules/terraform-aws-eks/modules/karpenter"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
}

Una vez que tenemos el Terraform preparado, desplegamos la solución. El proceso tarda unos 15 minutos aproximadamente en estar completo y operativo.

Como podemos ver, ya tenemos nuestro clúster desplegado y configurado para utilizar Karpenter.

Actualizamos kubeconfig para poder interaccionar con el cluster:

aws eks --region eu-west-1 update-kubeconfig --name awtwins-cluster

Verificamos que tenemos acceso al clúster y que los pods se han desplegado correctamente, como hemos comentado con anterioridad el propio código de Terraform ya despliega los addons necesarios por lo que deberíamos tener el siguiente escenario:

kubectl get pods -A
NAMESPACE     NAME                           READY   STATUS    RESTARTS   AGE
kube-system   aws-node-8sd7q                 2/2     Running   0          2m7s
kube-system   aws-node-vjj8q                 2/2     Running   0          2m11s
kube-system   coredns-67d68bcfdc-hww5k       1/1     Running   0          6m39s
kube-system   coredns-67d68bcfdc-vv5h6       1/1     Running   0          6m39s
kube-system   eks-pod-identity-agent-5xzdr   1/1     Running   0          2m12s
kube-system   eks-pod-identity-agent-hdg4k   1/1     Running   0          2m12s
kube-system   karpenter-7868758ccf-7npdb     1/1     Running   0          3m56s
kube-system   karpenter-7868758ccf-t564r     1/1     Running   0          3m56s
kube-system   kube-proxy-9tj27               1/1     Running   0          3m2s
kube-system   kube-proxy-ppkr5               1/1     Running   0          3m5s

También verificamos que se han creado tanto el Nodepool como el Nodeclass y el Deployment de prueba correspondiente

kubectl get nodepool
NAME      NODECLASS   NODES   READY   AGE
default   default     0       True    6m34s

kubectl get ec2nodeclass
NAME      READY   AGE
default   True    7m4s

kubectl get deployments
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
inflate   0/0     0            0           9m7s

Finalmente, habilitaremos nuestra cuenta de AWS para la creación de instancias spot, ejecutando el siguiente comando desde la CLI:

aws iam create-service-linked-role --aws-service-name spot.amazonaws.com || true

¡Llegados a este punto, ya tenemos un clúster completamente operativo! Ahora, podemos jugar con Karpenter. Antes de empezar, vamos a intentar dar algunas pinceladas sobre sus componentes clave:

NodePools
Los NodePools permiten configurar:

Tipo de instancia: Puedes elegir entre tipos como c, m o r (según tus necesidades de cómputo, memoria, etc.).
Arquitectura: Por ejemplo, amd64.
Tipo de instancia: Selecciona entre instancias on-demand o spot.
Sistema operativo: Configura el OS que mejor se adapte a tus aplicaciones.
Tiempo de vida de los nodos o consolidación de los mismos.

Estas configuraciones permiten ajustar los recursos de manera precisa, optimizando el uso de la infraestructura.
Importante: Para que Karpenter funcione, debes tener al menos un NodePool creado.

Link NodePools

NodeClasses
Permiten definir clases específicas de nodos dentro de un clúster de Kubernetes en AWS. Aquí puedes configurar aspectos como:

Capacidad de almacenamiento.
Opciones de red y configuraciones de seguridad.

Esto te permite ajustar los nodos a las necesidades de cada aplicación, mejorando tanto el rendimiento como el coste de la infraestructura.

Link NodeClasses

Gracias a estas configuraciones, Karpenter puede gestionar los nodos de forma automática, ajustando el tamaño y las características de los nodos en tiempo real según la demanda. Esto asegura que siempre tengas los recursos óptimos para tus aplicaciones sin desperdiciar capacidad.

Al jugar con las configuraciones de NodePools y NodeClasses, puedes personalizar el comportamiento de Karpenter y adaptarlo a las necesidades específicas de tu clúster. Es fundamental ir probando y ajustando según tu caso de uso para encontrar la máxima eficiencia y reducir costes.

Dicho esto… 🕹️¡vamos a jugar!🕹️

Como hemos podido observar anteriormente el código de Terraform utilizado nos ha desplegado automáticamente los siguientes recursos de Karpenter:

NodePool
NodeClass
Deployment de pruebas

Si analizamos los ficheros de configuración observaremos lo siguiente:

NodePool

    apiVersion: karpenter.sh/v1beta1
    kind: NodePool
    metadata:
      name: default
    spec:
      template:
        spec:
          nodeClassRef:
            name: default
          requirements:
            - key: "karpenter.k8s.aws/instance-category"
              operator: In
              values: ["c", "m", "r"]
            - key: "karpenter.k8s.aws/instance-cpu"
              operator: In
              values: ["4", "8", "16", "32"]
            - key: "karpenter.k8s.aws/instance-hypervisor"
              operator: In
              values: ["nitro"]
            - key: "karpenter.k8s.aws/instance-generation"
              operator: Gt
              values: ["2"]
      limits:
        cpu: 1000
      disruption:
        consolidationPolicy: WhenEmpty
        consolidateAfter: 30s

EC2NodeClass

    apiVersion: karpenter.k8s.aws/v1beta1
    kind: EC2NodeClass
    metadata:
      name: default
    spec:
      amiFamily: AL2023
      role: ${module.karpenter.node_iam_role_name}
      subnetSelectorTerms:
        - tags:
            karpenter.sh/discovery: ${module.eks.cluster_name}
      securityGroupSelectorTerms:
        - tags:
            karpenter.sh/discovery: ${module.eks.cluster_name}
      tags:
        karpenter.sh/discovery: ${module.eks.cluster_name}

Karpenter desplegará los nodos con las siguientes caracteristicas:

Instancias de las categorías c, m o r (optimizadas para cómputo, uso general y memoria).
Instancias con 4, 8, 16 o 32 vCPUs.
Instancias que utilicen el hipervisor Nitro.
Instancias de generaciones superiores a la segunda.
El escalado de nodos no superará un total de 1000 vCPUs.
Las instancias se eliminarán automáticamente cuando no tengan cargas de trabajo durante más de 30 segundos.
Utilizará una Amazon Machine Image (AMI) de la familia AL2023.
Se asignará el rol IAM definido por ${module.karpenter.node_iam_role_name}.
Los nodos se desplegarán en subnets que tengan la etiqueta karpenter.sh/discovery: ${module.eks.cluster_name}.
Los nodos estarán asociados a grupos de seguridad con la etiqueta karpenter.sh/discovery: ${module.eks.cluster_name}.
Los nodos estarán etiquetados con karpenter.sh/discovery: ${module.eks.cluster_name} para facilitar su identificación.

Para verificar su funcionamiento vamos a escalar el numero de replicas del deployment generado (mediante Terraform) lo que forzará el despliegue de nodos puesto que el clúster requerirá de nuevos nodos para asignar la carga correspondiente.

Para ello, ejecutamos el siguiente comando:
kubectl scale deployment inflate --replicas=15

Como podremos observar disponemos de 15 pods en estado "pending"

NAMESPACE     NAME                           READY   STATUS    RESTARTS   AGE
default       inflate-66fb68585c-4nzbw       0/1     Pending   0          11s
default       inflate-66fb68585c-6hdft       0/1     Pending   0          11s
default       inflate-66fb68585c-7h2vr       0/1     Pending   0          11s
default       inflate-66fb68585c-bh66g       0/1     Pending   0          11s
default       inflate-66fb68585c-c4w9r       0/1     Pending   0          11s
default       inflate-66fb68585c-d2n7s       0/1     Pending   0          11s
default       inflate-66fb68585c-hpzdw       0/1     Pending   0          11s
default       inflate-66fb68585c-ljqgf       0/1     Pending   0          11s
default       inflate-66fb68585c-lkp4t       0/1     Pending   0          11s
default       inflate-66fb68585c-nbfcd       0/1     Pending   0          11s
default       inflate-66fb68585c-pkwvb       0/1     Pending   0          11s
default       inflate-66fb68585c-qx27z       0/1     Pending   0          11s
default       inflate-66fb68585c-sxzs9       0/1     Pending   0          11s
default       inflate-66fb68585c-tqwkd       0/1     Pending   0          11s
default       inflate-66fb68585c-vw4dw       0/1     Pending   0          11s
kube-system   aws-node-jb5sb                 2/2     Running   0          11m
kube-system   aws-node-wfj2q                 2/2     Running   0          11m
kube-system   coredns-67d68bcfdc-m5dg2       1/1     Running   0          15m
kube-system   coredns-67d68bcfdc-tqj44       1/1     Running   0          15m
kube-system   eks-pod-identity-agent-7hsb7   1/1     Running   0          11m
kube-system   eks-pod-identity-agent-vzkls   1/1     Running   0          11m
kube-system   karpenter-7ffd65448-nmld6      1/1     Running   0          13m
kube-system   karpenter-7ffd65448-t94wh      1/1     Running   0          13m
kube-system   kube-proxy-twfgp               1/1     Running   0          12m
kube-system   kube-proxy-vpk6s               1/1     Running   0          12m

En este punto Karpenter estará desplegando nuevos nodos con los requisitos facilitados en los ficheros de configuración para poder cumplir con las cargas necesarias, accedemos a la consola y podemos ver que ya disponemos de una nueva instancia:

Si vemos el estado de los pods veremos como han sido desplegados y asignados correctamente y la instancia desplegada cumple con los requisitos facilitados en los ficheros de configuración.

NAMESPACE     NAME                           READY   STATUS    RESTARTS   AGE
default       inflate-66fb68585c-4nzbw       1/1     Running   0          4m55s
default       inflate-66fb68585c-6hdft       1/1     Running   0          4m55s
default       inflate-66fb68585c-7h2vr       1/1     Running   0          4m55s
default       inflate-66fb68585c-bh66g       1/1     Running   0          4m55s
default       inflate-66fb68585c-c4w9r       1/1     Running   0          4m55s
default       inflate-66fb68585c-d2n7s       1/1     Running   0          4m55s
default       inflate-66fb68585c-hpzdw       1/1     Running   0          4m55s
default       inflate-66fb68585c-ljqgf       1/1     Running   0          4m55s
default       inflate-66fb68585c-lkp4t       1/1     Running   0          4m55s
default       inflate-66fb68585c-nbfcd       1/1     Running   0          4m55s
default       inflate-66fb68585c-pkwvb       1/1     Running   0          4m55s
default       inflate-66fb68585c-qx27z       1/1     Running   0          4m55s
default       inflate-66fb68585c-sxzs9       1/1     Running   0          4m55s
default       inflate-66fb68585c-tqwkd       1/1     Running   0          4m55s
default       inflate-66fb68585c-vw4dw       1/1     Running   0          4m55s
kube-system   aws-node-gdx8l                 2/2     Running   0          4m28s
kube-system   aws-node-jb5sb                 2/2     Running   0          16m
kube-system   aws-node-wfj2q                 2/2     Running   0          16m
kube-system   coredns-67d68bcfdc-m5dg2       1/1     Running   0          20m
kube-system   coredns-67d68bcfdc-tqj44       1/1     Running   0          20m
kube-system   eks-pod-identity-agent-7hsb7   1/1     Running   0          16m
kube-system   eks-pod-identity-agent-vzkls   1/1     Running   0          16m
kube-system   eks-pod-identity-agent-w9tcq   1/1     Running   0          4m27s
kube-system   karpenter-7ffd65448-nmld6      1/1     Running   0          18m
kube-system   karpenter-7ffd65448-t94wh      1/1     Running   0          18m
kube-system   kube-proxy-r65c2               1/1     Running   0          4m28s
kube-system   kube-proxy-twfgp               1/1     Running   0          17m
kube-system   kube-proxy-vpk6s               1/1     Running   0          17m

Si procedemos a eliminar las replicas desplegadas podremos ver que los nodos se eliminan bajo las condiciones facilitadas.

Para ello ejecutamos el siguiente comando:

kubectl scale deployment inflate --replicas=0

Esperamos 30 segundos y podremos ver como el nodo se elimina sin problemas.

Una vez visto el funcionamiento, podemos empezar a "jugar" con los archivos de configuración según las necesidades específicas de nuestro clúster. Al ajustar los parámetros de los NodePools y NodeClasses, es posible controlar aspectos clave como el tipo de instancias, la cantidad de CPU o memoria, el tiempo de vida de los nodos, o el uso de instancias spot para reducir costes.

En nuestra opinión, Karpenter es una de esas soluciones que no pueden faltar en tus proyectos si buscas optimizar la gestión de tus clústeres en Kubernetes. Su capacidad para automatizar el escalado y aprovisionamiento de nodos hace que la complejidad operativa y la sobrecarga manual no sean uno de nuestros problemas.

🚨Recomendación🚨
Antes de implementar Karpenter en tu clúster de Kubernetes, se recomienda configurar algunos elementos que optimizan el funcionamiento y aseguran una eficiente gestión de recursos como pueden ser:

Optimización de la infraestructura: Se recomienda configurar PodDisruptionBudgets (PDB) para garantizar la disponibilidad de las aplicaciones durante mantenimientos o interrupciones.
Alta disponibilidad: Tener al menos 2 réplicas por aplicación asegura redundancia en caso de fallos de nodos.
Escalado automático: Implementar el Vertical Pod Autoscaler (VPA) para ajustar recursos automáticamente y el Horizontal Pod Autoscaler (HPA) para gestionar el número de réplicas según las métricas.
Visualización del clúster: Herramientas como Kubernetes Dashboard, KubeOpsView y otras facilitan la administración y ofrecen una visión mas "amigable" del clúster.

👀Enlaces interesantes👀

Documentación Oficial de Karpenter
Post Community AWS - Christian Melendez (AWS)
Video Explicativo Karpenter
Workshop Karpenter (AWS)

¡Y hasta aquí llegamos por hoy! Como siempre, estamos deseando leer tus comentarios y preguntas. Nos ayudan a mejorar y seguir creando contenido interesante.

¡Nos vemos en el próximo post! 👌

Administra las credenciales de aplicación con [EKS Pod Identity]

Rubén Rodríguez — Thu, 18 Jan 2024 23:34:16 +0000

¿Quién iba a decir que llegaríamos al cuarto post?🥳¡Increíble!🥳Pero, aquí entre nosotros, hemos decidido hacer un pacto con la pausa y bajarle un poco al estrés. A partir de ahora, intentaremos publicar de forma mensual para que nadie termine en la locura, nosotros incluidos!🕵️
En nuestro último post, exploramos cómo desplegar sin miedo con un ejemplo sobre App Runner. Sin embargo, en estos últimos meses, ha surgido un susurro constante en nuestras conversaciones técnicas:

🚨EKS Pod Identities🚨
Esta nueva funcionalidad se presenta como una herramienta que simplifica la configuración de permisos de IAM para aplicaciones Kubernetes en AWS. Como era de esperar, nos sumergiremos para comprender cómo funciona y compartiremos algunas novedades adicionales que se han publicado en referencia al servicio de EKS.
¡Así que, vamos a por ello! 🚀💻

Requisitos

Clúster EKS
El rol de nodo debe tener permisos para que el agente realice la acción de AssumeRoleForPodIdentity en la API de autenticación de EKS
Bucket S3

https://docs.aws.amazon.com/es_es/eks/latest/userguide/pod-id-agent-setup.html

Para este ejemplo, crearemos un rol de IAM con permisos de lectura sobre S3 y configuraremos todo lo necesario para que un pod de prueba pueda asumir este rol y realizar una lista (list) en un bucket de S3. En este caso, hemos creado un bucket con el nombre "test-pod-demo".

Accedemos a nuestro clúster y añadimos el complemento "Amazon EKS Pod Identity Agent".

Una vez añadimos el complemento al clúster, los pods asociados a este se desplegarán. Deberemos verificar que se han desplegado correctamente revisando su estado.

Creamos el rol de IAM “iam-pod-identities-demo” con los permisos necesarios.

Una vez creado el rol de IAM, regresamos al clúster y configuramos la asociación de la identidad del pod.

IAM role: Rol creado previamente
Namespace: Namespace donde vamos a desplegar el pod (puede estar creado previamente o crearlo más tarde)
ServiceAccount: ServiceAccount que vamos a asociar (puede estar creada o no) En este caso, hemos utilizado la siguiente configuración: Si accedemos nuevamente al clúster, podemos observar que la asociación ya ha sido generada. En caso de no contar con el namespace y la service account, procedemos a crearlos. Podemos realizar esta acción a través de comandos (kubectl) o mediante la definición de un archivo YAML. kubectl create namespace test-demo kubectl create serviceaccount sa-test-demo -n test-demo Creamos un pod de prueba que desplegaremos en el namespace creado previamente y le asociaremos la service account. En este caso, para realizar las pruebas correspondientes, utilizaremos la imagen de aws-cli y le añadiremos un comando de "sleep infinity" para que el pod no se detenga y podamos acceder sin problemas. Verificamos que el pod se ha iniciado correctamente. Accedemos al pod para realizar las validaciones necesarias. Ejecutamos el comando de la CLI de AWS aws s3 ls para listar el contenido del bucket. ¡Y con un toque de magia! El pod ha logrado listar el contenido del bucket sin ningún inconveniente.🎉

🧙‍♂️Ventajas de las identidades de Pod de EKS🧙‍♂️

Privilegio mínimo: puede limitar los permisos de IAM a una cuenta de servicio y solo los Pods que utilizan esa cuenta de servicio tienen acceso a esos permisos.
Aislamiento de credenciales: los contenedores de un Pod's solo pueden recuperar las credenciales para el rol de IAM asociado a la cuenta de servicio que usa el contenedor. Un contenedor nunca tiene acceso a credenciales que utilizan otros contenedores de otros Pods.
Auditabilidad: el acceso y el registro de eventos está disponible a través de AWS CloudTrail para facilitar una auditoría retrospectiva.
No utiliza proveedores de identidad OIDC (menos gestión y más facilidad).
Reutilización: la Pod Identity de EKS utiliza una única entidad principal de IAM en lugar de los principios independientes para cada clúster que utilizan los roles de IAM para las cuentas de servicio.
Escalabilidad: cada conjunto de credenciales temporales lo asume el servicio de EKS Auth en Pod Identity de EKS, en lugar de cada SDK de AWS que se ejecuta en cada pod. A continuación, el agente de Pod Identity de Amazon EKS que se ejecuta en cada nodo emite las credenciales de los SDK.

😱Restricciones de Pod Identity😱

No se admiten los pods de Linux y Windows que se ejecutan en AWS Fargate (Fargate). No se admiten pods que se ejecutan en instancias Windows Amazon EC2.
No se admiten complementos de Amazon EKS que necesitan credenciales de IAM.
No se admiten los clústeres Kubernetes que se crean y ejecutan en Amazon EC2. No se admiten las regiones de AWS GovCloud(EE. UU.), la región China(Beijing, operada por Sinnet) y China(Ningxia, operada por NWCD)
Disponible para las versiones enumeradas en https://docs.aws.amazon.com/es_es/eks/latest/userguide/pod-identities.html#pod-id-cluster-versions ¡Pero espera, hay más! En estos últimos meses, han surgido novedades emocionantes sobre el servicio de EKS. ¡No podíamos dejarlas pasar! 🚀
28/12/2023 - Amazon EKS ahora admite la asignación de grupos de seguridad de EC2 a pods de Kubernetes IPv6
28/12/2023 - Amazon EKS ahora muestra los detalles del estado del clúster
20/12/2023 - Amazon EKS presenta la información sobre actualizaciones ¡Pero eso no es todo! Puedes echarle un vistazo a https://aws.amazon.com/es/new/?whats-new-content-all.sort-by=item.additionalFields.postDateTime&whats-new-content-all.sort-order=desc&awsf.whats-new-categories=*all

¡Esperamos vuestras reacciones y comentarios!

EC2: Parches automáticos para liberar tu agenda

Rubén Rodríguez — Thu, 04 Jan 2024 00:51:11 +0000

"¡Hola de nuevo! En el primer post, exploramos el SSO en AWS para despedirnos de esos engorrosos roles de salto que nos han dado más de un dolor de cabeza. En esta segunda parte, nos adentraremos en otro de los problemas comunes que hemos enfrentado a lo largo de nuestra trayectoria. ¿Cómo abordamos el tema de parchear las EC2 que aún necesitamos mantener? ¡Ups! ¿Pero no estamos todos trabajando con containers y serverless? 😜 ¿Cómo resolver este problema sin dedicar ese tiempo del que nunca parece haber suficiente? En este caso, vamos a hablar de nuestro querido aliado..."
System Manager.

Operativa común:

Conexión manual a las EC2.
Descarga y revisión de los parches disponibles.
Creación de una copia de seguridad para una posible recuperación en caso de error.
Instalación de los parches seleccionados.
Reinicio de la instancia.
Verificación del correcto funcionamiento.

Sin duda, un proceso tedioso y "aburrido" con el que nadie quiere lidiar. Para hacerlo más sencillo, AWS nos ofrece un servicio llamado Patch Manager, una herramienta que facilita la administración y automatización de actualizaciones de software y parches tanto en instancias EC2 como en entornos locales. Sin embargo, aún así, vamos a presentar una alternativa (estrechamente relacionada) que nos permite gestionar estas actualizaciones de forma más personalizada.
Documents personalizados de System Manager👌
En esta ocasión, vamos a crear un documento que ejecute los siguientes pasos:

Envío de correo para notificar el inicio del proceso de parcheo.
Actualización del agente de SSM.
Creación de una AMI (backup) para facilitar la recuperación en caso de error.
Aplicación de los parches al sistema.
Envío de correo para notificar la finalización del proceso de parcheo.
Gestión de errores: si se produce algún error en cualquiera de los pasos, el proceso de parcheo se detendrá y se enviará una notificación correspondiente.

👩‍🏭¡Vamos a ello!👨‍🏭

Requisitos

Instancias con System Manager
https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html
Bucket S3 para almacenar logs, en nuestro caso hemos generado el logs-patch-demo

Rol de IAM con los permisos necesarios para ejecutar todas las acciones requeridas. En este ejemplo, y debido a que se trata de una POC (Prueba de Concepto), se han otorgado permisos completos ("full access") sobre los siguientes servicios:

AmazonEC2FullAccess
AmazonSNSFullAccess
AmazonSSMFullAccess Recuerda que siempre debemos aplicar los permisos mínimos necesarios, y que el ejemplo proporcionado nunca debe ser utilizado en entornos de producción

Utilizaremos Amazon SNS para enviar correos electrónicos indicando el inicio, final y cualquier error que pueda surgir. Esto se realizará a través de una suscripción, que especificará el destinatario que recibirá los correos informativos.

Resource group al cual aplicaremos el documento. En nuestro caso, será aplicado a todas las instancias EC2 que tengan la etiqueta 'Patch:yes'.

En este caso, solo hemos desplegado una instancia, pero podríamos incluir todas las que sean necesarias.

Y por supuesto...💎la joya de la corona💎, el documento personalizado de AWS System Manager:

description: Parcheo automatizado
schemaVersion: '0.3'
assumeRole: '{{Rol}}'
parameters:
  TopicArn:
    type: String
    description: (Required) ARN del SNS para enviar eventos.
  Instance:
    type: String
    description: (Required) ID de Instancia EC2.
  Rol:
    type: String
    description: (Required) Rol de IAM con permisos.
  BucketName:
    type: String
    description: (Required) Nombre del bucket donde almacenaremos los logs.
mainSteps:
  - name: Iniciopatch
    action: aws:executeAwsApi
    nextStep: ActualizacionAgenteSSM
    isEnd: false
    onFailure: Abort
    inputs:
      Service: sns
      Api: Publish
      TopicArn: '{{TopicArn}}'
      Message: Empezamos el parcheo de {{Instance}}
  - name: ActualizacionAgenteSSM
    action: aws:runCommand
    maxAttempts: 1
    timeoutSeconds: 3600
    nextStep: CreacionAMI
    isEnd: false
    onFailure: step:Errorpatch
    inputs:
      DocumentName: AWS-UpdateSSMAgent
      InstanceIds:
        - '{{Instance}}'
  - name: CreacionAMI
    action: aws:createImage
    maxAttempts: 3
    nextStep: ParcheoInstancia
    isEnd: false
    onFailure: step:Errorpatch
    inputs:
      InstanceId: '{{Instance}}'
      ImageName: AMI generada el {{global:DATE_TIME}} sobre {{Instance}}
      NoReboot: true
      ImageDescription: AMI generada por parcheo en {{global:DATE_TIME}} para {{Instance}}
  - name: ParcheoInstancia
    action: aws:runCommand
    maxAttempts: 1
    timeoutSeconds: 5400
    nextStep: Finalpatch
    isEnd: false
    onFailure: step:Errorpatch
    inputs:
      DocumentName: AWS-RunPatchBaseline
      InstanceIds:
        - '{{Instance}}'
      OutputS3BucketName: '{{BucketName}}'
      Parameters:
        Operation: Install
        RebootOption: RebootIfNeeded
  - name: Finalpatch
    action: aws:executeAwsApi
    isEnd: true
    onFailure: step:Errorpatch
    inputs:
      Service: sns
      Api: Publish
      TopicArn: '{{TopicArn}}'
      Message: Finalizamos el parcheo de {{ Instance }}
  - name: Errorpatch
    action: aws:executeAwsApi
    isEnd: true
    inputs:
      Service: sns
      Api: Publish
      TopicArn: '{{TopicArn}}'
      Message: El parcheo no ha finalizado correctamente, revisar el estado
outputs:
  - CreacionAMI.ImageId

Mientras preparamos el post, hemos notado que actualmente existe la opción de visualizar de manera gráfica las acciones que llevaremos a cabo mediante el documento. Esta función ciertamente resulta de gran ayuda para comprender mejor las operaciones que realizaremos.

Como mencionamos anteriormente, el documento está configurado para enviar un correo indicando el inicio del proceso de parcheo, actualizar el agente de System Manager, crear una AMI de la EC2, aplicar los parches a la instancia y enviar un correo notificando la finalización del proceso de parcheo. Todo esto se realizará de manera automatizada, sin necesidad de supervisión. ¡Fantástico! 👌
Ahora, podrías estar pensando, "¡perfecto! Pero, ¿cómo ejecuto este documento para no tener que estar pendiente de cuándo debo parchear los sistemas?" Para abordar esta inquietud, vamos a profundizar en "Maintenance Windows", un servicio que permite programar y gestionar centralizadamente las tareas de mantenimiento y actualizaciones en los recursos de AWS.
Para comenzar, crearemos una nueva ventana de mantenimiento:

🚨Para ejecutar la ventana de mantenimiento en el grupo de instancias al que queremos aplicarlo, es necesario registrar dicho grupo dentro de la ventana.🚨

Seleccionamos la sección "Task" y creamos una nueva tarea que haga referencia a nuestro documento.

Habiendo alcanzado este punto, es el momento de proporcionar las variables que mencionamos al principio como requisitos:

TopicArn: Arn del SNS generado.
Rol: Rol de IAM con los permisos necesarios.
BucketName: Nombre del bucket donde se almacenarán los logs.

En este caso, el rol no es necesario proporcionarlo en esta última opción, ya que se asume dentro del propio documento.

¡Ha llegado el momento más esperado... es hora de probarlo!

Para garantizar la ejecución de la tarea, hemos modificado el cron de la ventana de mantenimiento para que se ejecute a una hora específica: 23:12 PM (¡Sí, así somos! ¡Con una Coca-Cola en la mano y listos para compartir! 🎉)

Podemos seguir el progreso de la tarea en la pestaña "History" de la propia ventana.

Para ver la ejecución paso a paso, podemos seleccionar "View details", lo cual nos mostrará el proceso de parcheo en detalle, paso por paso.

En cada paso, es posible obtener los resultados y visualizar los logs correspondientes. En el caso de la actualización del agente de System Manager, el resultado es el siguiente.

Una vez ejecutado y completado sin errores (en caso de recibir errores, se recibiría un correo indicando el error y se podrían ver los detalles en esta sección de manera detallada), procedemos a validar que tenemos registros en S3 y que la imagen se ha generado sin problemas.
S3
Al llevar a cabo el parcheo de la instancia, AWS genera una estructura de carpetas dentro de S3 donde se almacenan tanto los registros de resultado como los de error:

En este caso, las horas de los logs no coinciden debido a que se ejecutó en múltiples ocasiones durante la creación del documento. Verificamos que las imágenes se han generado correctamente durante las ejecuciones.

SNS
En el caso de las notificaciones por correo electrónico, se ha seleccionado una cuenta de Gmail como destino para la POC.

Antes de finalizar el post, nos gustaría proporcionar algunos ejemplos donde este tipo de solución puede aplicarse:

Parar y arrancar instancias o RDS de forma automatizada.
Parchear sistemas con aplicaciones que requieran detención o inicio controlado.
Actualizar paquetes personalizados o realizar customizaciones en instancias.

Información adicional

En este caso, hemos utilizado una cuenta única para la POC. Sin embargo, es importante destacar que estos documentos pueden ser compartidos entre cuentas, lo que permite realizar la ejecución de manera centralizada. ¡Mola! ¿no? 👀

Además, es relevante tener en cuenta que el documento ofrece una amplia gama de variables. Por ejemplo, podemos elegir reiniciar la instancia al finalizar el parcheo (tal como se ha ejemplificado), pero también podríamos incluir acciones como el apagado de servicios antes del parcheo, la ejecución de scripts, y muchas otras opciones.

¡Sin duda, esta es una solución muy personalizable que estamos seguros será de gran utilidad en diversas situaciones, simplificando las operaciones y liberando tiempo para seguir aprendiendo y enfrentando nuevos retos!

¿Te has preguntado si este flujo automatizado podría convertirse en una infraestructura como código con Terraform? ¡La respuesta es sí!¿Le damos caña?💯

¡Y eso es todo por hoy! Esperamos que hayas disfrutado de este post sobre automatización. ¿Te ha parecido interesante? ¡Nos encantaría conocer tu opinión! Déjanos tus comentarios, reacciones o preguntas. ¡Estamos ansiosos por saber qué piensas! 🙏