Módulo 7: Eks Specifics For Production
1. Introducción al módulo: por qué este es distinto a los seis anteriores
Descripción
Los Módulos 1-6 tienen algo en común que no se dijo en voz alta hasta ahora porque no hacía falta: todo lo que corriste, corrió de verdad. kind create cluster, cada kubectl apply, metrics-server, ingress-nginx, Gitea, ArgoCD, OPA Gatekeeper, Kyverno, trivy image — seis módulos completos contra un clúster de Kubernetes real, en tu máquina, sin límite de plan de pago y sin cuenta de AWS de por medio. Este módulo rompe ese patrón, y lo hace a propósito, con la razón exacta declarada antes de que llegues a preguntarte por qué: EKS no es un servicio que este ecosistema pueda ejecutar en $0, ni siquiera con el plan de pago más caro de LocalStack.
Esta lección existe para que esa honestidad llegue primero, antes que cualquier YAML de EKS. El resto del módulo —node groups, Karpenter, IRSA, el AWS Load Balancer Controller— se muestra, se explica a fondo y se verifica contra documentación oficial de AWS. Nada de eso se ejecuta contra una cuenta AWS real. Cada vez que aparezca, va a estar etiquetado como (representativo), con la razón técnica exacta, no como una promesa vaga de "esto normalmente funcionaría así".
Conexión con el módulo
El Módulo 1 te dejó andes-cargo-cluster corriendo en kind. Los Módulos 2-6 construyeron, capa por capa, un sistema completo de producción encima: Pods con réplicas, configuración externalizada, autoscaling por métricas, Ingress, NetworkPolicy, GitOps con ArgoCD, y guardrails de runtime con dos motores de admission control. Todo eso es, literalmente, Kubernetes — el mismo kube-apiserver, el mismo etcd, el mismo modelo de objetos que corre en un nodo de EKS. Lo que este módulo agrega no es "más Kubernetes": es lo que cambia alrededor de ese mismo Kubernetes cuando, en vez de kind administrando tu plano de control en un contenedor Docker de tu laptop, es AWS quien lo administra, con un contrato de nivel de servicio (SLA) de por medio, dentro de tu cuenta.
La cita exacta: por qué EKS no corre en este laboratorio
docs.localstack.cloud, la documentación oficial de LocalStack, marca cada servicio con una insignia que indica en qué plan de precios está disponible. Para EKS (Elastic Kubernetes Service), esa insignia dice, textualmente:
"Included in Plans: Ultimate"
No está en el plan gratuito (Hobby/Community, el que usó esta guía para todo lo demás). No está tampoco en el plan Base de pago intermedio, el que sí cubre otros servicios nombrados en guías hermanas de este ecosistema (ECR, ECS). EKS es, de todos los servicios de AWS que aparecen en cualquier guía de este ecosistema hasta ahora, el que exige el escalón de precio más alto de LocalStack.
Pero hay un segundo hallazgo, verificado en la misma documentación, que importa más que el primero para las decisiones de diseño de este módulo: incluso si alguien pagara el plan Ultimate, lo que LocalStack ofrece bajo el nombre "EKS" no es una réplica fiel del plano de control gestionado de AWS. La documentación describe, en sus propias palabras, cómo funciona por debajo:
"The default approach for creating Kubernetes clusters using the local EKS API is by setting up an embedded k3d kube cluster within Docker."
Traducido sin perder precisión: cuando le pides a LocalStack que cree un clúster "EKS", lo que arranca por debajo es un clúster k3d — un empaquetado de k3s, una distribución liviana de Kubernetes, corriendo en contenedores Docker — envuelto en las llamadas de API que imitan a EKS. Es, en la práctica, la misma idea de fondo que kind (Kubernetes-en-Docker), con otro nombre de distribución liviana por debajo, disfrazado de API de EKS. No hay IRSA evaluado de verdad contra un OIDC provider de una cuenta AWS real. No hay AWS Load Balancer Controller creando un ALB real, porque no existe ningún Elastic Load Balancing real detrás de LocalStack para que ese controlador hable con él. No hay node groups gestionados por Auto Scaling Groups reales, porque no hay EC2 real detrás.
LO QUE "EKS" SIGNIFICA EN CADA CAPA
EKS real (AWS) "EKS" en LocalStack Ultimate
kube-apiserver/etcd k3s embebido en k3d
administrados por AWS, con SLA corriendo en contenedores Docker
│ │
IRSA / EKS Pod Identity sin evaluación real de
contra un OIDC provider real trust policy de IAM
│ │
AWS Load Balancer Controller sin ELB real detrás —
crea un ALB real en tu VPC no hay nada que crear
│ │
Node groups → Auto Scaling Groups sin EC2 real detrás
→ instancias EC2 reales
CONCLUSIÓN: pagar Ultimate por esto compra una segunda
distribución liviana de Kubernetes-en-Docker, envuelta en
llamadas de API de EKS — no compra el plano de control
gestionado real que este módulo enseña.Por esta razón exacta, esta guía no usa LocalStack para EKS, ni siquiera como opción de pago mostrada por completitud. El valor pedagógico de simular una simulación es bajo, comparado con lo que ya tienes: kind, que es Kubernetes real, sin ninguna capa de imitación de por medio.
Qué corrió, y qué no — la tabla de honestidad de este módulo
| Módulo | Qué se ejecutó | Contra qué |
|---|---|---|
| M1 | kind create cluster, arquitectura del plano de control, carga de imagen | Docker real, en tu máquina |
| M2 | Pod, Deployment, Service, balanceo real | andes-cargo-cluster (kind) |
| M3 | ConfigMap, Secret, probes, HorizontalPodAutoscaler con carga real | andes-cargo-cluster (kind) |
| M4 | ingress-nginx instalado, Ingress, NetworkPolicy default-deny | andes-cargo-cluster (kind) |
| M5 | Gitea, ArgoCD, sincronización pull-based real, selfHeal demostrado | andes-cargo-cluster (kind) |
| M6 | OPA Gatekeeper v3.23.0, Kyverno v1.18.2, trivy image, ambos motores activos a la vez | andes-cargo-cluster (kind) |
| M7 (este) | Nada contra AWS real — plano de control gestionado, node groups, Fargate profiles, Karpenter, IRSA/Pod Identity, AWS Load Balancer Controller | Representativo: YAML/CLI real, verificado contra docs.aws.amazon.com/eks y eksctl.io, nunca aplicado contra una cuenta |
| M8 | El documento de migración de este módulo, y el recorrido end-to-end final | andes-cargo-cluster (kind), documentación honesta |
Fíjate en el patrón: seis módulos ejecutados, uno representativo, uno que documenta la frontera entre ambos. No es una guía que se vuelve representativa poco a poco — es una guía que ejecuta casi todo, y declara con precisión el único bloque que no puede ejecutar y por qué.
Analogía: alquilar un departamento con mantenimiento incluido, frente a tener casa propia
Imagina dos formas de tener un techo sobre la cabeza. La primera es alquilar un departamento en un edificio con administración: si se rompe una cañería, hay un encargado que la arregla; si el ascensor falla, alguien lo repara sin que tú levantes una herramienta; pagas una cuota mensual, y a cambio nunca tienes que preocuparte por la estructura del edificio en sí — solo por lo que pasa dentro de tu unidad. La segunda es tener una casa propia: si el techo gotea, lo arreglas tú (o contratas a alguien y lo supervisas tú); si la caldera se rompe un domingo a la noche, es tu problema resolverlo, no el de nadie más.
Un clúster EKS es el departamento con mantenimiento incluido: AWS administra el edificio (kube-apiserver, etcd, el plano de control completo), con un contrato de nivel de servicio de por medio, y tu equipo se concentra en lo que pasa dentro de la unidad (tus cargas de trabajo, tus Deployment, tus políticas). Un clúster kind, el que construiste desde el Módulo 1, es la casa propia: tú construiste el "edificio" completo con un solo comando (kind create cluster), y aunque nunca tuviste que pensarlo en esos términos, tú eras responsable de todo el plano de control — simplemente no había nada roto para que lo notaras. La próxima lección hace ese contraste explícito, componente por componente.
El mapa de este módulo: las 8 lecciones
MÓDULO 7 — LO ESPECÍFICO DE EKS PARA PRODUCCIÓN
(representativo, con la razón técnica declarada en cada lección)
M7.1 Introducción (esta) la honestidad de costo, primero
M7.2 El plano de control gestionado qué administra AWS, qué no
M7.3 Node groups, self-managed, Fargate profiles las 3 formas de cómputo
M7.4 Karpenter vs Cluster Autoscaler HPA escala Pods; esto escala nodos
M7.5 IRSA y EKS Pod Identity OIDC aplicado a un Pod
M7.6 AWS Load Balancer Controller el Ingress real de producción
M7.7 Manos a la obra: el YAML de EKS representativo, verificado
M7.8 Proyecto: el plan de migración EJECUTADO — el documento real| # | Lección | Qué construye |
|---|---|---|
| 1 | Introducción (esta) | La honestidad de costo central; qué se ejecutó en M1-M6, qué no se ejecuta en M7 |
| 2 | El plano de control gestionado | kube-apiserver/etcd de AWS vs lo que el equipo sigue administrando; contraste con kind |
| 3 | Node groups: gestionados, autogestionados, Fargate profiles | Las tres formas de cómputo detrás de EKS, eksctl/Terraform mostrado |
| 4 | Autoscaling de nodos: Karpenter vs Cluster Autoscaler | Contraste con el HPA del M3 — Pods fijos en nodos vs nodos que aparecen |
| 5 | IRSA y su sucesor, EKS Pod Identity | El patrón OIDC aplicado a un Pod, cierre con StatusApiTaskRole |
| 6 | El AWS Load Balancer Controller | Mismo objeto Ingress, distinto controlador — contraste con ingress-nginx (M4) |
| 7 | Manos a la obra: el YAML de EKS, mostrado y explicado | eksctl create cluster, IAMServiceAccount, IngressClass — representativo, verificado |
| 8 | Proyecto: el plan de migración de Andes Cargo | EJECUTADO — el documento real, kind → EKS, recurso por recurso |
Al cerrar este módulo vas a tener algo distinto de lo que dejaron los seis anteriores: no un sistema corriendo más, sino el criterio completo para leer, evaluar y planificar una migración real de kind a EKS — sin haber gastado un centavo, y sin ninguna afirmación fingida de que algo corrió cuando no corrió.
Errores comunes
Esperar un "manos a la obra" con kubectl apply contra una cuenta AWS real en algún punto de este módulo (de expectativa). Qué pasa: alguien, acostumbrado al patrón de los seis módulos anteriores —cada concepto seguido de un kubectl ejecutado de verdad—, busca el mismo patrón aquí y se frustra al no encontrarlo. Por qué pasa: es el patrón que esta misma guía instaló, con toda intención, durante seis módulos seguidos. Cómo detectarlo: si llegas a la lección 7 (el "manos a la obra" de este módulo) esperando ver salida real de un eksctl create cluster contra AWS. Cómo corregirlo: esta misma lección lo declaró primero — la 7 se llama, con toda intención, "el YAML mostrado y explicado", no "manos a la obra ejecutado". Es sintaxis real, verificada contra documentación oficial, nunca corrida contra una cuenta.
Pensar que "representativo" significa "inventado" o "no confiable" (de interpretación). Qué pasa: alguien lee la etiqueta "(representativo)" y la confunde con "esto podría estar mal, nadie lo verificó". Por qué pasa: en muchos contextos, "no ejecutado" se usa como sinónimo de "no verificado". Cómo detectarlo: si dudas de un comando o un campo YAML de este módulo solo porque no corrió contra una cuenta real. Cómo corregirlo: cada pieza representativa de este módulo está contrastada contra documentación oficial vigente (docs.aws.amazon.com/eks, eksctl.io, karpenter.sh), citada con su fuente exacta — "representativo" describe que no hubo ejecución contra AWS, no que la sintaxis o el comportamiento descrito sean dudosos.
Asumir que este módulo va a intentar EKS vía LocalStack Ultimate, "aunque sea de forma parcial" (de expectativa sobre el laboratorio). Qué pasa: alguien, sabiendo que LocalStack ofrece EKS en su plan más caro, espera que este módulo al menos lo mencione como una opción viable para ejecutar algo. Por qué pasa: parece razonable que "pagar más" resuelva el problema de "no puedo ejecutarlo gratis". Cómo detectarlo: si buscas en este módulo un paso de docker run localstack/localstack-pro con EKS habilitado. Cómo corregirlo: esta lección ya explicó por qué esa vía se descartó — no por costo (aunque también es una barrera real), sino porque lo que hay detrás de esa API, incluso pagando, es otra distribución liviana de Kubernetes-en-Docker, no el plano de control gestionado real que este módulo enseña.
Ejercicios
Ejercicio 1 — Reescribe la cita clave sin copiarla. Sin volver a mirar la sección "La cita exacta" de esta lección, escribe de memoria: (a) la insignia de plan que LocalStack asigna a EKS, y (b) qué tecnología dice la documentación de LocalStack que corre por debajo cuando alguien crea un clúster "EKS" en ese entorno.
Ver solución
(a) "Included in Plans: Ultimate" — el plan de pago más caro que ofrece LocalStack, más alto que el plan Base que sí cubre otros servicios del ecosistema. (b) Un clúster k3d (empaquetado de k3s, una distribución liviana de Kubernetes), corriendo dentro de Docker, envuelto en llamadas de API que imitan a EKS — no una réplica fiel del plano de control gestionado de AWS.
Ejercicio 2 — Explica, en dos frases, por qué pagar el plan Ultimate no resolvería el problema de fondo. Un colega te pregunta: "¿por qué no simplemente pagas LocalStack Ultimate y ejecutas EKS de verdad en este módulo?". Respóndele sin usar la palabra "costo" ni "dinero" en tu explicación.
Ver solución
Una respuesta completa suena, más o menos, así: "Aunque pagáramos, lo que esa API entrega por debajo no es el plano de control gestionado real de AWS —es otra distribución liviana de Kubernetes corriendo en Docker, disfrazada de EKS—, así que no habría IRSA evaluado contra un OIDC real, ni un AWS Load Balancer Controller creando un balanceador real, ni node groups respaldados por EC2 real. Pagar compraría una segunda simulación, no el sistema que este módulo enseña." Si tu respuesta mencionó que el problema es de fidelidad, no solo de precio, capturaste el punto central de esta lección.
Ejercicio 3 — Predice qué SÍ va a tener evidencia ejecutada en este módulo, si nada corre contra AWS. Basándote en la tabla de honestidad de esta lección, predice qué lección de este módulo va a tener la etiqueta "EJECUTADO" en vez de "representativo", y por qué esa lección sí puede ejecutarse sin cuenta de AWS.
Ver solución
La lección 8, el proyecto final del módulo: el plan de migración de andes-cargo-k8s/ de kind a EKS. Puede ejecutarse de verdad porque no requiere ninguna llamada a AWS — es un documento, una tabla recurso por recurso construida contra los manifiestos reales que ya existen en el repositorio (Módulos 1-5), no contra una API externa. Es la misma distinción que otras guías del ecosistema ya usaron: un documento de análisis, escrito contra evidencia real ya existente, puede ser "ejecutado" (el documento en sí es el entregable real) incluso cuando el sistema que describe (EKS) no lo es.
Resumen y siguiente paso
Esta lección estableció, antes que cualquier otro contenido de este módulo, la honestidad de costo central de esta guía: EKS está marcado "Included in Plans: Ultimate" en la documentación oficial de LocalStack — el escalón de precio más alto de cualquier servicio nombrado en este ecosistema — y, más importante, ni siquiera pagando esa API reproduce fielmente el plano de control gestionado real de AWS, porque corre sobre una distribución liviana de Kubernetes-en-Docker (k3d/k3s) por debajo. Por esta razón, el Módulo 7 completo queda representativo: mostrado, explicado a fondo, y verificado contra documentación oficial, pero nunca ejecutado contra una cuenta AWS real.
Antes de avanzar deberías poder: citar la insignia exacta de LocalStack para EKS; explicar por qué pagar el plan Ultimate no resolvería el problema de fidelidad; y nombrar, de memoria, cuál de las ocho lecciones de este módulo sí tiene evidencia ejecutada, y por qué.
Siguiente lección: el plano de control gestionado — qué administra AWS, qué sigue siendo tuyo. Ahí vas a ver, componente por componente, el contraste directo con lo que kind te hizo administrar sin que lo supieras.
Recursos
- LocalStack — Elastic Kubernetes Service (EKS) — la fuente exacta de la insignia "Included in Plans: Ultimate" y de la descripción de la implementación embebida vía k3d/k3s.
- Amazon EKS — What is Amazon EKS? — la definición oficial del servicio que este módulo enseña sin ejecutar.
kubernetes-and-eks-in-production-guide(NIEVA), Módulo 1, lección 6 — la arquitectura dekindque la siguiente lección contrasta directamente contra EKS.cloud-security-and-guardrails-guide(NIEVA), Módulo 2, lección 6 — el mismo límite de fondo (LocalStack Hobby no evalúa identidad ni enforcement de pago) documentado ahí para OIDC de GitHub Actions, el mismo patrón que este módulo documenta para IRSA en la lección 5.