Módulo 8: Capstone Andes Cargo On Kubernetes
5. Lo que esta guía dejó representativo, honestidad final
Descripción
Las lecciones 3 y 4 de este módulo confirmaron, con evidencia literal, que la inmensa mayoría de esta guía corrió de verdad contra un clúster real. Esta lección reúne, en un solo lugar, la otra mitad de esa honestidad: el Módulo 7 completo —lo específico de EKS como servicio gestionado— nunca corrió contra una cuenta de AWS real, y una sexta pieza, presente desde el Módulo 2 y ajena a EKS —la capa de datos DynamoDB, servida vía /shipments— tampoco corrió nunca dentro de este laboratorio $0. Esta lección explica, pieza por pieza, la razón técnica exacta de cada límite, sin generalidades.
Conexión con el módulo
Esta lección no ejecuta ningún comando — es una síntesis deliberada, la misma disciplina que el Módulo 7 aplicó lección por lección, ahora en una sola tabla que puedas citar de memoria en una entrevista sin tener que repasar ocho lecciones distintas.
La honestidad de fondo, en una frase
Todo lo que corrió contra kind en esta guía —Pods, Deployments, Services, ConfigMaps, Secrets, probes, HorizontalPodAutoscaler, Ingress, NetworkPolicy, GitOps con ArgoCD, admission control con Gatekeeper y Kyverno, trivy image— es Kubernetes real, el mismo binario que corre en un nodo de EKS. Lo único que cambia con un clúster EKS real es todo lo que rodea a ese Kubernetes: quién administra el plano de control, de dónde salen los nodos, cómo un Pod obtiene identidad de AWS, quién crea el balanceador. Esta lección cubre exactamente esas cinco piezas, cada una con la razón exacta por la que no corrió — y agrega una sexta, de una naturaleza distinta: la capa de datos (DynamoDB, servida vía /shipments), presente desde el Módulo 2, nunca EKS-específica, y fuera del alcance $0 de esta guía completa, no solo del Módulo 7.
Las seis piezas representativas, con su razón técnica exacta
1. El plano de control gestionado
Qué es: kube-apiserver/etcd, administrados por AWS, con un SLA formal, sin que ningún ingeniero de Andes Cargo tenga acceso SSH a la máquina donde corren.
Por qué quedó representativo: la razón central de todo el Módulo 7, verificada contra la documentación oficial de LocalStack (Módulo 7, lección 1): el servicio EKS de AWS tiene el badge "Included in Plans: Ultimate" — no está disponible ni en el plan gratuito Hobby que sostiene el resto de esta guía, ni en el plan Base de pago intermedio que sí cubre ECS/ECR. Y hay una segunda razón, más importante que la primera para el diseño de esta guía: incluso pagando 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 propia documentación de LocalStack describe la funcionalidad como "clústeres Kubernetes embebidos en el motor Docker local" a través de las APIs de EKS, es decir, algo funcionalmente parecido a lo que kind ya hace directo y gratis, envuelto en llamadas de API. El valor pedagógico de pagar por esto es bajo comparado con kind real.
Qué sí viste: el contraste directo, explicado a fondo (Módulo 7, lección 2) — en kind, tú mismo administraste el plano de control sin saberlo (los cinco componentes corriendo como contenedores Docker en tu propia máquina, Módulo 1, lección 6); en EKS, AWS se queda con esa responsabilidad, y tú te quedas con la parte que sigue siendo tuya: nodos, add-ons, RBAC.
2. Node groups gestionados, autogestionados, y Fargate profiles
Qué es: las tres formas reales de tener cómputo (instancias EC2) detrás de un clúster EKS.
Por qué quedó representativo: ninguna API de LocalStack, ni siquiera en el plan Ultimate, ofrece un camino gratuito para node groups reales, porque node groups son, en el fondo, Auto Scaling Groups de EC2 reales, con instancias reales que cuestan dinero real desde el primer minuto — no hay ninguna forma de simular esto sin una cuenta de AWS con tarjeta de crédito.
Qué sí viste: el YAML/eksctl completo (Módulo 7, lecciones 3 y 7), explicado a fondo, con el contraste directo de su equivalente ya ejecutado en kind: los contenedores andes-cargo-cluster-worker/worker2 que el Módulo 1 creó con kind create cluster son, funcionalmente, lo que un node group gestionado reemplazaría con instancias EC2 reales — mismo rol (dónde corren los Pods), implementación completamente distinta.
3. Autoscaling de nodos: Karpenter frente a Cluster Autoscaler
Qué es: el mecanismo que lanza una instancia EC2 nueva cuando el clúster necesita más capacidad de la que los nodos actuales pueden ofrecer.
Por qué quedó representativo: la misma razón que node groups — lanzar una instancia EC2 real cuesta dinero real, sin ningún camino $0.
Qué sí viste, y la distinción que vale la pena repetir aquí porque es la más fácil de confundir en una entrevista: el HorizontalPodAutoscaler del Módulo 3 sí corrió de verdad en kind, y lo probaste con carga real hasta ver las réplicas subir y bajar (Módulo 3, lección 8). Pero el HPA escala Pods dentro de nodos que ya existen — nunca crea un nodo nuevo. Karpenter (o Cluster Autoscaler, nombrado por contraste para entornos multi-nube) es quien decide lanzar una instancia EC2 nueva cuando ni siquiera hay espacio para el Pod adicional que el HPA querría crear. Son dos capas de autoscaling completamente distintas —escalar Pods frente a escalar nodos— y solo la primera corrió de verdad en esta guía.
4. IRSA y su sucesor, EKS Pod Identity
Qué es: el mecanismo por el cual un Pod obtiene credenciales de AWS temporales y federadas, sin que nadie tenga que guardar un AWS_ACCESS_KEY_ID permanente en un Secret.
Por qué quedó representativo: el mismo límite de fondo que ya documentó cloud-security-and-guardrails-guide (Módulo 2) para el OIDC de GitHub Actions — la evaluación real de una trust policy de IAM (quién puede asumir qué rol, bajo qué condiciones) es parte de "IAM Policy Enforcement" de LocalStack, funcionalidad de los planes Base/Ultimate, no del plan Hobby que esta guía usó.
Qué sí viste: el mecanismo completo en YAML/CLI real (Módulo 7, lecciones 5 y 7), con el paralelo explícito que cierra un círculo abierto desde aws-serverless-and-containers-guide: el rol StatusApiTaskRole —creado en esa guía, nunca aplicado porque ECS no era ejecutable ahí— es, en un EKS real, exactamente el rol que un ServiceAccount de Kubernetes asumiría vía IRSA. El secret.yaml de esta guía, con las credenciales dummy test/test, es la pieza que IRSA/Pod Identity haría innecesaria por completo (Módulo 7, lección 8) — el SDK de AWS detectaría las credenciales federadas por su cuenta, sin leer ningún Secret.
5. El AWS Load Balancer Controller
Qué es: el controlador oficial de AWS que traduce un objeto Ingress de Kubernetes en un balanceador ALB real, creado en la cuenta de AWS, fuera del clúster.
Por qué quedó representativo: un ALB real es un recurso de AWS con costo real, sin ningún camino $0 en LocalStack Hobby.
Qué sí viste: el contraste directo y preciso (Módulo 7, lección 6) con ingress-nginx, que sí corrió de verdad en kind (Módulo 4) — el mismo objeto Ingress de Kubernetes, exactamente la misma sintaxis YAML, pero un controlador completamente distinto por debajo: ingress-nginx es un proceso más dentro del clúster; el AWS Load Balancer Controller crea un recurso de infraestructura fuera del clúster. El Módulo 7, lección 8, tradujo esta diferencia a un cambio de campo concreto y acotado: ingressClassName: nginx → ingressClassName: alb, más anotaciones específicas del controlador — host, path, pathType y backend.service, los campos que de verdad definen el enrutamiento, no cambian en absoluto.
6. La capa de datos: DynamoDB, servida vía /shipments
Qué es: el backend real de datos que andes-cargo-status-api necesita para responder /shipments/<id> con datos reales de envíos — una tabla DynamoDB, accesible vía LocalStack o una cuenta AWS real, con credenciales válidas.
Por qué quedó representativo — y por qué es distinto a las otras cinco piezas: a diferencia de las cinco piezas anteriores, esta no es específica de EKS — está presente desde el Módulo 2, la primera vez que curl /shipments/4471 devolvió 500, y se mantiene así hasta esta misma lección. Ningún módulo de esta guía instala LocalStack dentro del clúster ni conecta una cuenta AWS real: la capa de datos completa queda fuera del alcance $0 de kubernetes-and-eks-in-production-guide, que se enfoca en deployment, networking, GitOps y guardrails — no en servir datos reales de negocio.
Qué sí viste: /health respondió 200 OK de verdad en cada módulo que lo probó (Módulo 2, lección 7; Módulo 4, lección 8; Módulo 5, lección 4), confirmando que el camino de red completo —Pod, Service, Ingress, NetworkPolicy— funciona de punta a punta. /shipments/<id> se mantuvo como el endpoint representativo: el traceback exacto (NoCredentialsError) quedó documentado desde el Módulo 2, y el ConfigMap/Secret del Módulo 3 resolvió la mitad de la ecuación (la configuración), sin resolver la otra (un backend real al cual conectarse).
La tabla resumen: seis piezas, una razón cada una
| Pieza representativa | Por qué no corrió | Qué sí corrió, como equivalente ejecutado |
|---|---|---|
| Plano de control gestionado | EKS: "Included in Plans: Ultimate"; ni pagando reproduce el plano real | kind (Módulo 1) — el mismo Kubernetes, administrado por ti |
| Node groups / Fargate profiles | Instancias EC2 reales, costo real, sin camino $0 | Contenedores -worker/-worker2 de kind (Módulo 1) |
| Autoscaling de nodos (Karpenter/Cluster Autoscaler) | Lanzar una instancia EC2 nueva cuesta dinero real | HorizontalPodAutoscaler (Módulo 3) — escala Pods, no nodos |
| IRSA / EKS Pod Identity | IAM Policy Enforcement es de planes Base/Ultimate | ConfigMap/Secret con credenciales dummy (Módulo 3) |
| AWS Load Balancer Controller | Un ALB real es un recurso de AWS con costo real | ingress-nginx (Módulo 4) — mismo objeto Ingress, otro controlador |
Capa de datos (DynamoDB vía /shipments) | Presente desde el Módulo 2; fuera del alcance $0 de toda la guía, no solo del M7 | /health (Módulos 2, 4, 5) — camino de red completo, sin datos reales |
Seis piezas, seis razones distintas, ninguna genérica ("cuesta dinero" sin más) — las primeras cinco específicas de EKS como servicio gestionado, verificadas contra documentación oficial en el momento en que el Módulo 7 se escribió; la sexta (la capa de datos) presente desde el Módulo 2, fuera del alcance $0 de la guía completa. Todas citadas de nuevo aquí para que queden en un solo lugar.
Analogía: el plano del segundo piso, nunca construido, siempre honesto
Si esta guía completa fuera un edificio, el primer piso —todo lo que corrió en kind— es concreto real, con inspectores reales que lo aprobaron (Gatekeeper, Kyverno) y gente real viviendo adentro (andes-cargo-status-api, sirviendo tráfico real). El segundo piso —EKS— existe solo como plano arquitectónico: cada medida está calculada, cada material especificado, cada norma de construcción verificada contra el código municipal real (la documentación oficial de AWS). Un arquitecto competente puede leer ese plano y saber exactamente qué se construiría y por qué funcionaría — pero nadie ha caminado todavía sobre ese piso, porque construirlo de verdad cuesta el precio real del terreno, el cemento y los permisos, y esta guía nunca prometió pagarlo por ti.
Errores comunes
Buscar en esta lección un paso de "manos a la obra" contra AWS real (de expectativa persistente). Qué pasa: alguien, después de siete módulos de práctica ejecutada, espera que el capstone incluya, aunque sea una vez, un comando corrido contra una cuenta AWS real. Cómo detectarlo: si tu pregunta al terminar esta lección es "¿y ahora cómo lo pruebo de verdad?". Cómo corregirlo: el Módulo 7, lección 1, ya declaró esto de forma explícita, antes de que llegaras a este punto — el M7 completo es representativo, por la razón de costo exacta de cada pieza. Esta lección no cambia esa decisión; la resume.
Confundir "representativo" con "sin verificar" (de rigor). Qué pasa: alguien asume que, como el YAML de EKS nunca corrió, podría estar mal escrito o desactualizado. Cómo detectarlo: si tu duda frente a cualquier fragmento de YAML del Módulo 7 es "¿esto realmente funciona así?". Cómo corregirlo: cada pieza de sintaxis del Módulo 7 —eksctl, IAMServiceAccount, IngressClass— está verificada contra la documentación oficial de AWS y eksctl, con fuentes citadas explícitamente (Módulo 7, lección 7). "Representativo" describe que no corrió contra una cuenta real, no que su exactitud sea menor.
Tratar las seis piezas como si fueran igual de costosas entre sí (de simplificación). Qué pasa: alguien asume que "todo lo representativo de esta guía cuesta dinero, por eso no corrió nada". Cómo detectarlo: si no puedes explicar por qué IRSA, un node group y la capa de datos tienen razones técnicas distintas para no correr. Cómo corregirlo: repasa la tabla de esta lección — IRSA falla por falta de IAM Policy Enforcement (un límite de funcionalidad, no solo de precio, ya que ni el plan Ultimate lo resuelve del todo para EKS); un node group falla porque instancias EC2 reales cuestan dinero real desde el primer segundo, sin relación con qué plan de LocalStack tengas; la capa de datos, en cambio, no falló por costo en absoluto —LocalStack simula DynamoDB gratis, incluso en el plan Hobby— sino porque esta guía nunca decidió instalarlo dentro del clúster: es una decisión de alcance, no de precio.
Ejercicios
Ejercicio 1 — Reconstruye la tabla de seis piezas de memoria. Sin volver a esta lección, enumera las seis piezas representativas y, para cada una, la razón técnica exacta (no genérica) por la que no corrió.
Ver solución
(1) Plano de control gestionado — EKS es "Included in Plans: Ultimate" en LocalStack, y ni pagando reproduce el plano real. (2) Node groups/Fargate profiles — instancias EC2 reales, costo real, sin camino $0. (3) Autoscaling de nodos (Karpenter/Cluster Autoscaler) — lanzar una instancia EC2 nueva cuesta dinero real. (4) IRSA/EKS Pod Identity — la evaluación de trust policies de IAM es de los planes Base/Ultimate de LocalStack. (5) AWS Load Balancer Controller — un ALB real es un recurso de AWS con costo real. (6) Capa de datos (DynamoDB, vía /shipments) — presente desde el Módulo 2, no específica de EKS, fuera del alcance $0 de esta guía completa por decisión de alcance, no por costo.
Ejercicio 2 — Distingue "escalar Pods" de "escalar nodos" sin mirar la lección. En una frase, explica a un colega la diferencia exacta entre lo que el HorizontalPodAutoscaler (Módulo 3, ejecutado) hace, y lo que Karpenter (Módulo 7, representativo) haría.
Ver solución
Una explicación razonable: "El HorizontalPodAutoscaler cambia cuántas réplicas de un Pod corren, dentro de los nodos que el clúster ya tiene disponibles — nunca crea un nodo nuevo. Karpenter entra en juego cuando ni siquiera hay espacio en los nodos existentes para el Pod adicional que el HPA querría — su trabajo es lanzar una instancia EC2 nueva para que ese Pod tenga dónde correr. Son dos capas distintas del mismo problema de capacidad: una la resolví de verdad en este laboratorio, la otra requiere una cuenta AWS real con tarjeta."
Ejercicio 3 — Explica por qué IRSA es un caso más honesto que "simplemente falta dinero". El AWS Load Balancer Controller falla por costo puro (un ALB real cuesta dinero). IRSA falla por una razón distinta. En dos frases, explica cuál es esa diferencia y por qué importa para alguien que evalúa si vale la pena pagar por un plan más caro de LocalStack.
Ver solución
Una respuesta razonable: "Un ALB real cuesta dinero sin importar qué plan de LocalStack tengas — es un límite de la nube real, no de la herramienta de simulación. IRSA, en cambio, falla porque LocalStack específicamente no implementa la evaluación completa de trust policies de IAM ni en su plan gratuito ni, según la documentación citada en el Módulo 7, de forma completamente fiel ni siquiera en el plan de pago más caro — así que pagar por un plan superior no resolvería este límite en particular, a diferencia de otros servicios del ecosistema (como ECS/ECR) donde sí lo haría."
Resumen y siguiente paso
Esta lección reunió, en un solo lugar, la honestidad completa sobre las seis piezas de esta guía que quedaron representativas: las cinco del Módulo 7 que nunca corrieron contra una cuenta de AWS real —el plano de control gestionado, node groups/Fargate, autoscaling de nodos, IRSA/EKS Pod Identity, y el AWS Load Balancer Controller—, y una sexta, presente desde el Módulo 2 y ajena a EKS: la capa de datos (DynamoDB, vía /shipments), fuera del alcance $0 de la guía completa. Ninguna de las seis es una omisión — cada una está documentada, con fuente citada, desde el módulo en que se introdujo.
Antes de avanzar deberías poder: reconstruir la tabla de seis piezas de memoria, con la razón exacta de cada una; distinguir "escalar Pods" de "escalar nodos" sin dudar; explicar por qué el límite de IRSA es distinto, en naturaleza, del límite del AWS Load Balancer Controller; y explicar por qué la capa de datos, a diferencia de las otras cinco, no es un límite de EKS sino una decisión de alcance de toda la guía.
Siguiente lección: la corrección de continuidad que esta guía deja para el ecosistema. Ahí se documenta, con la misma honestidad de esta lección, un hallazgo sobre las guías hermanas de este ecosistema — no sobre esta guía en sí.
Recursos
- LocalStack — Elastic Kubernetes Service (EKS) — la fuente exacta del badge "Included in Plans: Ultimate", citada en el Módulo 7 y en esta lección.
- AWS — Scale cluster compute with Karpenter and Cluster Autoscaler — documentación oficial que distingue el autoscaling de nodos del autoscaling de Pods.
- AWS EKS — IAM roles for service accounts — referencia oficial de IRSA, el mecanismo representativo del Módulo 7, lección 5.
- AWS EKS — Route internet traffic with AWS Load Balancer Controller — referencia oficial del controlador contrastado contra
ingress-nginxen esta lección. kubernetes-and-eks-in-production-guide(NIEVA), Módulo 7, lecciones 1-8 — la fuente completa, con evidencia y citas, de las cinco piezas específicas de EKS resumidas aquí.kubernetes-and-eks-in-production-guide(NIEVA), Módulo 2, lección 7 — la fuente original de la sexta pieza (la capa de datos,NoCredentialsError,/shipmentsrepresentativo), documentada desde el primer módulo donde se ejecutó código real.