Módulo 7: Eks Specifics For Production

3. Node groups: gestionados, autogestionados, y Fargate profiles

Descripción

La lección anterior dejó claro que los nodos —el hardware o las VMs donde de verdad corren tus Pods— son responsabilidad tuya en EKS, sin importar cuánto administre AWS el plano de control. Lo que esa lección no cubrió es que "tener nodos" no es una sola decisión: AWS ofrece tres formas distintas de tener cómputo detrás de un clúster EKS, con niveles de control y de trabajo operativo muy diferentes entre sí. Esta lección las diseca una por una, con la sintaxis real de eksctl y de Terraform para cada una — la primera lección de este módulo con volumen real de YAML/CLI, todo verificado contra documentación oficial, nada ejecutado.

Conexión con el módulo

En kind (Módulo 1), esta decisión no existió — tu kind-config.yaml declaró un control-plane y dos worker, y kind los creó a todos como contenedores Docker en tu misma máquina, sin ninguna opción de "gestionado" vs "autogestionado" de por medio, porque no hay ninguna nube real detrás que gestione nada. EKS, al ser un servicio real de AWS con EC2 y Fargate reales disponibles, sí tiene que ofrecerte esa elección — y cada una implica un contrato distinto sobre quién hace qué trabajo.

Las tres formas de cómputo, de un vistazo

              CUÁNTO ADMINISTRAS TÚ, DE MENOS A MÁS

  Fargate profiles          Node groups gestionados       Nodos autogestionados
  ────────────────          ────────────────────────       ─────────────────────
  Sin EC2 visible            EC2, pero AWS ayuda con         EC2, tú administras
  para ti — AWS ejecuta      el ciclo de vida (crear,        todo: AMI, parcheo,
  cada Pod en su propia      actualizar, terminar) —         escalado manual o
  micro-VM aislada           tú sigues eligiendo             con tu propia
                              tipo de instancia y AMI         herramienta

  Ideal para: cargas         Ideal para: la mayoría          Ideal para: casos
  esporádicas, aislamiento    de equipos, el punto de         especiales — AMI
  fuerte, sin querer          partida recomendado por          propia obligatoria,
  administrar ningún           AWS para casi todo               hardware específico,
  servidor                                                       control total del
                                                                   ciclo de arranque

EKS managed node groups: el punto de partida recomendado

Un managed node group es un grupo de instancias EC2 que AWS crea y administra en tu nombre, respaldado por un Auto Scaling Group que tú no tocas directamente. "Gestionado" no significa "invisible" —siguen siendo instancias EC2 reales, en tu cuenta, que aparecen en tu factura— significa que AWS te da herramientas de un clic para las operaciones que más fricción generan: crear el node group con la AMI optimizada de EKS ya lista, actualizar todos los nodos a una versión nueva de Kubernetes sin downtime orquestado a mano, y drenar (cordon/drain) los nodos automáticamente antes de terminarlos.

Con eksctl (representativo):

eksctl create nodegroup \
  --cluster andes-cargo-cluster \
  --name andes-cargo-managed-ng \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 2 \
  --nodes-max 4 \
  --managed

Con Terraform (representativo) — el mismo recurso, para quien ya construyó infraestructura de este ecosistema con terraform-and-iac-guide:

resource "aws_eks_node_group" "andes_cargo_managed_ng" {
  cluster_name    = "andes-cargo-cluster"
  node_group_name = "andes-cargo-managed-ng"
  node_role_arn   = aws_iam_role.eks_node_role.arn
  subnet_ids      = var.private_subnet_ids

  scaling_config {
    desired_size = 2
    min_size     = 2
    max_size     = 4
  }

  instance_types = ["t3.medium"]
}

Fíjate en el campo node_role_arn: un managed node group necesita, igual que un rol de tarea de ECS que ya conoces de aws-serverless-and-containers-guide, un rol IAM propio para que cada instancia EC2 pueda registrarse contra el plano de control y descargar imágenes de contenedor — la política administrada oficial es AmazonEKSWorkerNodePolicy, el equivalente de nodo del mismo patrón que EcsTaskExecutionRole resolvía para ECS.

Nodos autogestionados: control total, trabajo total

Un nodo autogestionado (self-managed) es, en esencia, una instancia EC2 normal que tú lanzas, configuras y unes al clúster con tus propias herramientas —un launch template, tu propio Auto Scaling Group, o incluso una instancia suelta— sin que AWS medie el ciclo de vida por ti. AWS sigue dando la AMI optimizada de EKS como punto de partida, pero a partir de ahí, actualizar la versión de Kubernetes de esos nodos, parchear el sistema operativo, o reemplazar una instancia dañada son tareas que tu equipo orquesta, no un botón de la consola de EKS.

Con Terraform (representativo) — el patrón típico: un launch template + un Auto Scaling Group propio:

resource "aws_launch_template" "andes_cargo_self_managed" {
  name_prefix   = "andes-cargo-self-managed-"
  image_id      = data.aws_ssm_parameter.eks_ami.value
  instance_type = "t3.medium"

  user_data = base64encode(<<-EOF
    #!/bin/bash
    /etc/eks/bootstrap.sh andes-cargo-cluster
  EOF
  )
}

resource "aws_autoscaling_group" "andes_cargo_self_managed" {
  desired_capacity    = 2
  min_size            = 2
  max_size            = 4
  vpc_zone_identifier = var.private_subnet_ids

  launch_template {
    id      = aws_launch_template.andes_cargo_self_managed.id
    version = "$Latest"
  }
}

El script /etc/eks/bootstrap.sh —invocado dentro del user data de la instancia— es el detalle que separa "una EC2 cualquiera" de "un nodo de EKS": es el que registra la instancia contra el plano de control de andes-cargo-cluster en el momento del arranque. ¿Cuándo elige un equipo esta vía, sabiendo que implica más trabajo? Casos concretos: necesitas una AMI personalizada que EKS no ofrece de forma optimizada (por ejemplo, con un hardening de seguridad específico de tu industria pre-instalado), necesitas hardware o configuración de arranque que el flujo de un managed node group no expone, o ya tienes una plataforma interna madura de administración de flotas EC2 que prefieres reutilizar en vez de aprender el modelo de AWS.

Fargate profiles: sin servidor que administrar, ni gestionado ni no

Un Fargate profile es la tercera vía, y la más distinta de las tres: no hay ningún nodo EC2 —ni gestionado ni autogestionado— que tú administres. Cada Pod que cumple con los criterios de selección de un Fargate profile arranca en su propia micro-VM aislada, administrada enteramente por AWS. Es el mismo modelo serverless de cómputo que aws-serverless-and-containers-guide ya te presentó para ECS/Fargate — aplicado aquí a Pods de Kubernetes en vez de a tareas de ECS.

Un Fargate profile no despliega sobre "todo el clúster": selecciona qué Pods usan Fargate, mediante namespace (obligatorio) y, opcionalmente, etiquetas (labels) — hasta cinco selectores por perfil, y un Pod que cumple cualquiera de ellos se programa en Fargate.

Con eksctl (representativo), un perfil que envía a Fargate cualquier Pod del namespace andes-cargo:

eksctl create fargateprofile \
  --cluster andes-cargo-cluster \
  --name andes-cargo-fargate-profile \
  --namespace andes-cargo

Y con una etiqueta adicional, para que solo los Pods marcados explícitamente usen Fargate dentro de ese mismo namespace:

eksctl create fargateprofile \
  --cluster andes-cargo-cluster \
  --name andes-cargo-fargate-batch \
  --namespace andes-cargo \
  --labels workload-type=batch

Tres límites documentados, verificados contra AWS Docs, que valen la pena conocer antes de elegir esta vía:

Los Pods de Fargate solo se programan en subredes privadas, sin ruta directa a un Internet Gateway — necesitan un NAT Gateway para salir a internet.
No soporta DaemonSet — un patrón que este módulo no usó todavía, pero que herramientas como el AWS Load Balancer Controller (Módulo 7.6) o el agente de EKS Pod Identity (Módulo 7.5) sí necesitan correr en cada nodo; esos componentes, si el clúster es solo Fargate, requieren una estrategia de instalación distinta.
Cada Fargate profile necesita su propio Pod execution role —un rol IAM análogo, en espíritu, a EcsTaskExecutionRole: permite que el kubelet que corre en la infraestructura de Fargate descargue imágenes y se registre contra el clúster, no que tu código de aplicación haga nada— separado, otra vez, del rol que usa el código de tu aplicación (el patrón de IRSA/Pod Identity que la lección 5 retoma).

Tabla de decisión: cuándo cada una

Criterio	Managed node groups	Self-managed	Fargate profiles
Quién administra el ciclo de vida de EC2	AWS (crear, actualizar, terminar)	Tú, con tu propia herramienta	Nadie — no hay EC2 visible
Puedes usar una AMI personalizada	Sí, vía launch template	Sí, sin restricción	No
Soporta `DaemonSet`	Sí	Sí	No
SSH a la instancia	Sí	Sí	No — no existe una instancia a la que conectarte
Trabajo operativo	Bajo — el recomendado por defecto	Alto — control total, mantenimiento total	Nulo sobre servidores, pero con límites de red y de compatibilidad
Caso típico	La mayoría de las cargas de producción, punto de partida de esta guía si migrara `andes-cargo-status-api`	Requisitos de AMI/hardware muy específicos, plataforma interna ya madura	Cargas esporádicas, batch, o equipos que priorizan cero mantenimiento de servidor sobre flexibilidad

Para andes-cargo-status-api — un servicio HTTP always-on, de baja complejidad operativa, sin necesidad de AMI personalizada — un managed node group sería la elección por defecto en una migración real: es el punto medio que AWS recomienda para la gran mayoría de cargas de trabajo, sin renunciar a la capacidad de correr un DaemonSet si más adelante el equipo necesita uno (por ejemplo, un agente de observabilidad).

Errores comunes

Asumir que "gestionado" significa "sin instancias EC2 reales", confundiéndolo con Fargate (de vocabulario). Qué pasa: alguien escucha "managed node group" y asume que, como suena a "administrado", no hay servidores reales de por medio — la confusión típica es con Fargate, que sí elimina la instancia visible. Cómo detectarlo: si esperas no ver ninguna instancia EC2 en tu factura después de crear un managed node group. Cómo corregirlo: un managed node group sí crea instancias EC2 reales, visibles en tu cuenta y en tu factura — lo único que AWS gestiona es el ciclo de vida operativo (creación, actualización, terminación ordenada), no la existencia del servidor en sí. Solo Fargate elimina la instancia visible por completo.

Elegir Fargate sin verificar primero si el clúster necesita algún DaemonSet (de planificación). Qué pasa: un equipo migra su carga de trabajo completa a Fargate profiles, y descubre después que necesita instalar un agente de observabilidad o de seguridad de runtime que depende de un DaemonSet para correr en cada nodo. Cómo detectarlo: si tu lista de add-ons o herramientas de plataforma incluye algo que la documentación describe explícitamente como DaemonSet. Cómo corregirlo: revisa esa lista antes de comprometerte a Fargate como única forma de cómputo del clúster — muchos equipos reales usan una combinación (managed node groups para lo que necesita DaemonSet, Fargate profiles para cargas puntuales que no lo necesitan), no una elección exclusiva.

Pensar que un Fargate profile de Kubernetes es idéntico, sin diferencia, al Fargate que ya conoces de ECS (de continuidad con aws-serverless-and-containers-guide). Qué pasa: alguien que ya construyó una tarea Fargate de ECS en la guía anterior asume que la sintaxis y el modelo de selección son los mismos aquí. Cómo detectarlo: si buscas un campo taskDefinition o desiredCount dentro de un Fargate profile de EKS. Cómo corregirlo: el concepto de fondo —cómputo serverless, sin servidor visible— es el mismo, pero el mecanismo de selección es completamente distinto: ECS Fargate arranca tareas definidas explícitamente; un Fargate profile de EKS no define qué correr, solo qué Pods, ya definidos en Kubernetes, califican para correr ahí, vía namespace/etiquetas — es un filtro sobre objetos de Kubernetes, no una definición de carga de trabajo en sí misma.

Ejercicios

Ejercicio 1 — Clasifica cinco escenarios. Para cada uno, decide si managed node groups, self-managed, o Fargate profiles es la elección más razonable: (a) un equipo necesita correr un DaemonSet de seguridad de runtime en cada nodo; (b) una carga de procesamiento por lotes que corre 20 minutos, dos veces al día, y el equipo no quiere pagar por instancias EC2 ociosas el resto del tiempo; (c) un equipo con una AMI corporativa obligatoria por política de seguridad, con un hardening específico que EKS no ofrece de fábrica; (d) el servicio andes-cargo-status-api, always-on, sin requisitos especiales de AMI.

Ver solución

(a) Managed node groups (o self-managed) — Fargate no soporta DaemonSet. (b) Fargate profiles — cómputo esporádico, sin servidor que mantener ocioso entre corridas. (c) Self-managed — requiere control total sobre la AMI, más allá de lo que un launch template de un managed node group permite de forma estándar. (d) Managed node groups — el punto de partida recomendado para una carga always-on sin requisitos especiales, el mismo criterio que esta lección aplicó a Andes Cargo.

Ejercicio 2 — Explica el Pod execution role sin usar la palabra "infraestructura". Un colega te pregunta por qué un Fargate profile necesita su propio rol IAM si "los Pods ya tienen su propio rol vía IRSA". Respóndele en dos o tres frases, sin usar la palabra "infraestructura".

Ver solución

Una respuesta completa suena, más o menos, así: "Son dos preguntas distintas, igual que ya viste con EcsTaskExecutionRole y StatusApiTaskRole en ECS. Antes de que tu Pod exista siquiera, alguien tiene que poder descargar la imagen del contenedor y registrar ese Pod contra el clúster — eso lo resuelve el Pod execution role del Fargate profile. Una vez que el Pod está corriendo, lo que tu código puede hacer contra otros servicios de AWS es un permiso completamente distinto, resuelto por IRSA o Pod Identity — el mismo patrón de separación de roles que ya conoces, aplicado a una capa nueva."

Ejercicio 3 — Predice el resultado de un DaemonSet en un clúster solo-Fargate. Si un clúster EKS tiene únicamente Fargate profiles (ningún node group), y alguien aplica un manifiesto DaemonSet, ¿qué esperarías que pase? Justifica tu respuesta con lo que aprendiste sobre las limitaciones de Fargate en esta lección.

Ver solución

El DaemonSet no encontraría ningún nodo válido donde programarse — Fargate no soporta el patrón DaemonSet porque no hay un conjunto fijo de nodos "reales" sobre los cuales garantizar "un Pod por nodo": cada Pod de Fargate vive en su propia micro-VM aislada, sin ningún nodo persistente compartido al que un DaemonSet pueda anclarse. En la práctica, el objeto DaemonSet se crearía en etcd sin error de sintaxis, pero sus Pods quedarían indefinidamente sin programar (Pending), porque el scheduler no encontraría ningún nodo compatible.

Resumen y siguiente paso

Esta lección diseccionó las tres formas de tener cómputo detrás de un clúster EKS: managed node groups (el punto de partida recomendado, AWS administra el ciclo de vida de instancias EC2 reales), nodos autogestionados (control total, trabajo total, para requisitos de AMI o hardware muy específicos), y Fargate profiles (sin ningún servidor visible, con límites reales de red y de compatibilidad como la falta de soporte para DaemonSet). Confirmaste, con sintaxis real de eksctl y Terraform, cómo se declara cada una, y aplicaste el criterio a andes-cargo-status-api: un managed node group, sin requisitos especiales.

Antes de avanzar deberías poder: explicar, sin confundirlos, qué gestiona AWS en cada una de las tres formas de cómputo; nombrar un límite real de Fargate profiles que afecta una decisión de arquitectura; y justificar, en una frase, por qué andes-cargo-status-api elegiría un managed node group en una migración real.

Siguiente lección: autoscaling de nodos — Karpenter frente a Cluster Autoscaler. Ahí vas a ver la distinción exacta con el HorizontalPodAutoscaler que ya ejecutaste en el Módulo 3: ese escala Pods sobre nodos que ya existen; esto escala los nodos mismos.

Recursos

Amazon EKS — Manage compute resources by using nodes — la comparación oficial de las opciones de cómputo, fuente de la tabla de decisión de esta lección.
Amazon EKS — Amazon EKS managed node groups — referencia completa de managed node groups.
Amazon EKS — Define which Pods use AWS Fargate when launched — la fuente exacta de los límites de Fargate profiles citados en esta lección (subredes privadas, sin DaemonSet, selectores por namespace/etiqueta).
eksctl — Nodegroups — sintaxis completa de eksctl create nodegroup/eksctl create fargateprofile.
aws-serverless-and-containers-guide (NIEVA), Módulo 7 — el modelo de ECS/Fargate y EcsTaskExecutionRole/StatusApiTaskRole, el punto de comparación directo del Pod execution role de esta lección.

← Anterior2. El plano de control gestionado: qué administra AWS, qué sigue siendo tuyo Siguiente →4. Autoscaling de nodos: Karpenter frente a Cluster Autoscaler