Módulo 8: Capstone Andes Cargo On Kubernetes
7. Lo que Andes Cargo todavía necesita
Descripción
Esta guía cierra el capítulo de orquestación de contenedores del ecosistema aws-cloud-ecosystem — andes-cargo-status-api corre de verdad, con GitOps y admission control reales encima. Pero un clúster corriendo, con buenos guardrails de admisión, no es un sistema completo: le falta saber cuánto cuesta, qué hacer cuando algo falla a las tres de la mañana, y qué pasaría si Andes Cargo alguna vez necesitara inferencia de IA sobre esta misma infraestructura. Esta lección mapea, con precisión y sin inventar nada, las tres guías reales del ecosistema que cubren exactamente esos tres huecos — dos de ellas, completas, existen hoy.
Conexión con el módulo
Esta lección retoma, con nombres reales en vez de placeholders, la frontera que el DISENO.md de esta guía declaró desde el principio: FinOps de Kubernetes, SRE del propio clúster, y GenAI/GPU sobre EKS quedan fuera del alcance de esta guía por diseño — no por olvido. Lo que esta lección agrega es la confirmación, verificada contra el contenido real de cada una, de que dos de esas tres guías ya existen, completas, en este ecosistema.
1. FinOps de Kubernetes — finops-and-cost-guardrails-guide
La frontera declarada por esta guía, desde su propio diseño: un guardrail de esta guía nunca es "esto es caro", es "esto viola una política" o "esto no pasó el escaneo" — la disciplina de costo es, deliberadamente, de otra guía.
El estado real: finops-and-cost-guardrails-guide ya existe, completa, en producción (src/guides/finops-and-cost-guardrails-guide). Cubre rightsizing de Lambda con datos reales de Infracost, PAY_PER_REQUEST frente a PROVISIONED en DynamoDB, y presupuestos por equipo — sobre Lambda, DynamoDB y S3, no sobre Kubernetes (la lección anterior de este mismo módulo documentó, con cita textual, que su premisa sobre "Andes Cargo no tiene contenedores" sigue sin corregir, aunque su alcance técnico sea correcto).
Qué le falta a Andes Cargo, concretamente, en este dominio: todo lo que un equipo de Kubernetes en producción necesitaría preguntarse sobre el costo de este mismo clúster, que ninguna guía del ecosistema construye todavía: rightsizing de requests/limits de CPU y memoria a nivel de Pod (el equivalente del ajuste de memoria de Lambda que finops-and-cost-guardrails-guide sí hizo, aplicado a un manifiesto de Kubernetes en vez de a una función); Compute Optimizer aplicado a nodos de un clúster real, en vez de a una función serverless; y la economía de node groups con instancias Spot frente a On-Demand mixtas — una decisión de costo real de EKS que ninguna guía de este ecosistema construyó todavía, porque ninguna tiene un node group real con el que experimentar.
2. SRE del propio clúster — sre-and-incident-response-guide
La frontera declarada por esta guía, desde su propio diseño: un Pod que entra en CrashLoopBackOff en producción y despierta a alguien a las 3 a.m. es el tipo de incidente que una disciplina de SRE operaría — esta guía construyó el sistema que lo previene (probes, HPA, admission control), no la disciplina de responder cuando falla igual.
El estado real: sre-and-incident-response-guide ya existe, completa, en producción (src/guides/sre-and-incident-response-guide), con ocho módulos: qué es SRE y confiabilidad como característica, SLI/SLO y el presupuesto de error, observabilidad como insumo de SLI, alertas por burn rate, el ciclo de vida de un incidente, operar un incidente con Claude Code, postmortems sin culpa y runbooks, y un capstone propio. Su capstone (Módulo 8, lección 7, ya citada en la lección anterior de este módulo) nombra explícitamente a kubernetes-and-eks-in-production-guide como el lugar donde su mismo vocabulario —SLI, SLO, error budget, burn rate, postmortem sin culpa— se volvería a aplicar, con señales completamente distintas, si Andes Cargo migrara de Lambda a un clúster.
Qué le falta a Andes Cargo, concretamente, en este dominio: un SLI real definido sobre andes-cargo-status-api corriendo en andes-cargo-cluster (latencia de /shipments/<id>, tasa de error del Service, no de un API Gateway); un PodDisruptionBudget explícito, que ninguna lección de esta guía construyó; y un postmortem real escrito sobre un incidente de este clúster —por ejemplo, el hallazgo de la lección 4 de este mismo módulo (Kyverno bloqueando un Deployment que Gatekeeper no cubría) sería, en un equipo real, exactamente el tipo de sorpresa operativa que un postmortem documentaría, con acciones de seguimiento concretas.
3. GenAI e inferencia sobre infraestructura de AWS — genai-on-aws-production-guide
La frontera declarada por esta guía, desde su propio diseño: GPU en nodos, inferencia, Karpenter para cargas de IA, costo por token — nombrado por contraste en el Módulo 7 de esta guía, sin construirse, porque Andes Cargo, con el volumen de manifiestos de este caso, no necesita capacidad de GPU dedicada.
El estado real, y el matiz honesto que vale la pena precisar aquí: genai-on-aws-production-guide ya existe, completa, en producción (src/guides/genai-on-aws-production-guide), con ocho módulos sobre GenAI en producción real de AWS: el modelo de costo de Bedrock, infraestructura como código para un endpoint de IA, guardrails de Bedrock y defensa en profundidad, seguridad de la carga de trabajo de IA, FinOps para tokens, y observabilidad/latencia/evals en producción. Pero esa guía, en su propio diseño, tampoco construye GPU dedicada sobre EKS — declara explícitamente que GPU en nodos, inferencia sobre Kubernetes y Karpenter para cargas de IA quedan nombrados por contraste, no construidos, por la misma razón de fondo que esta guía usa para EKS completo: GPU dedicada no tiene ningún camino $0 en LocalStack, ni siquiera en el plan Ultimate. Es decir: GPU/inferencia sobre EKS sigue siendo un hueco real del ecosistema completo, nombrado por dos guías distintas, construido por ninguna — no por falta de una guía asignada, sino porque ninguna guía de este ecosistema tiene, hoy, un camino gratuito para ejecutarlo de verdad.
Qué le falta a Andes Cargo, concretamente, en este dominio: si el volumen de Andes Cargo alguna vez creciera al punto de justificar inferencia propia (en vez de un modelo gestionado por Bedrock, que sí cubre genai-on-aws-production-guide), ahí es donde entrarían GPU dedicada, nodos con Karpenter provisionando instancias con aceleradores, y el costo por token calculado sobre infraestructura propia en vez de sobre una API gestionada — un escenario que, con la evidencia de mercado actual del ecosistema, ninguna guía cubre todavía de punta a punta, y que quedaría como el faltante honesto más claro para quien continúe expandiendo este ecosistema.
La tabla resumen: tres huecos, tres estados reales
| Dominio | Guía asignada | Estado, verificado | Qué falta, concretamente |
|---|---|---|---|
| FinOps de Kubernetes | finops-and-cost-guardrails-guide | ✅ Existe, completa — pero sin cobertura de Kubernetes | Rightsizing de Pods, Compute Optimizer de nodos, economía Spot/On-Demand de node groups |
| SRE del clúster | sre-and-incident-response-guide | ✅ Existe, completa — nombra esta guía por contraste, no construye sobre ella | SLI real de andes-cargo-status-api, PodDisruptionBudget, postmortem de un incidente real de este clúster |
| GenAI/GPU sobre EKS | genai-on-aws-production-guide | ⚠️ Existe, completa — pero declara GPU/EKS fuera de su propio alcance $0, igual que esta guía | Inferencia propia con GPU dedicada, Karpenter para cargas de IA, costo por token sobre infraestructura propia — hueco real, sin guía que lo cubra hoy |
Analogía: el mapa de rutas, con dos caminos pavimentados y uno todavía sin abrir
Si el ecosistema aws-cloud-ecosystem fuera un mapa de rutas desde Andes Cargo hacia el resto de sus necesidades de plataforma, dos de los tres caminos que esta lección señala ya están pavimentados, con señalización completa y tráfico real circulando: el camino hacia el costo (finops-and-cost-guardrails-guide) y el camino hacia la confiabilidad operativa (sre-and-incident-response-guide) — ninguno de los dos pasa todavía por el territorio específico de Kubernetes, pero los dos existen, completos, listos para que alguien construya el tramo que falta. El tercer camino, hacia inferencia de IA con GPU dedicada, tiene dos letreros apuntando hacia él —uno desde esta guía, otro desde genai-on-aws-production-guide— y ningún tramo de asfalto real todavía: los dos letreros son honestos sobre hacia dónde llevaría ese camino, pero ninguna de las dos guías lo pavimentó, por la misma razón de fondo (GPU real cuesta dinero real, sin excepción de plan).
Errores comunes
Asumir que "nombrado por contraste" en dos guías distintas significa "cubierto dos veces" (de conteo apresurado). Qué pasa: alguien, al ver que tanto esta guía como genai-on-aws-production-guide mencionan GPU/EKS, asume que entre las dos suman una cobertura completa. Cómo detectarlo: si tu conclusión es "entre las dos guías, GPU sobre EKS ya está resuelto". Cómo corregirlo: las dos guías declaran, cada una en su propio diseño, que GPU/EKS queda fuera de su alcance ejecutable — nombrarlo dos veces por contraste no equivale a construirlo una vez. Sigue siendo un hueco real del ecosistema, documentado con más precisión (dos fuentes, no una), pero sin resolver.
Confundir "la guía existe" con "cubre el caso Andes Cargo sobre Kubernetes" (de lectura superficial del estado). Qué pasa: alguien lee "✅ Existe, completa" en la tabla y asume que finops-and-cost-guardrails-guide o sre-and-incident-response-guide ya resolvieron el caso específico de este clúster. Cómo detectarlo: si buscas, en cualquiera de esas dos guías, un ejemplo concreto sobre andes-cargo-status-api corriendo en Kubernetes, y no lo encuentras. Cómo corregirlo: las dos guías existen y son completas en su propio alcance (Lambda/DynamoDB/S3 para FinOps; Lambda/API para SRE) — ninguna de las dos extiende ese alcance hacia Kubernetes, y las dos lo dicen explícitamente en su frontera. "Existe" no es lo mismo que "cubre este caso".
Tratar el hueco de GPU/EKS como una falla de diseño de esta guía (de responsabilidad mal ubicada). Qué pasa: alguien concluye que kubernetes-and-eks-in-production-guide "debería haber construido" GPU sobre EKS, ya que es la guía de Kubernetes del ecosistema. Cómo detectarlo: si tu pregunta es "¿por qué esta guía no lo hizo, si es la guía de Kubernetes?". Cómo corregirlo: la razón, declarada desde el DISENO.md de esta guía y confirmada, de forma independiente, por el propio DISENO.md de genai-on-aws-production-guide, es la misma en las dos: GPU dedicada no tiene ningún camino $0 en LocalStack. No es una decisión de alcance evitable — es un límite real de la herramienta de simulación que sostiene todo el ecosistema con costo cero.
Ejercicios
Ejercicio 1 — Reconstruye la tabla de tres dominios de memoria. Sin volver a esta lección, indica, para cada uno de los tres dominios (FinOps, SRE, GenAI/GPU), qué guía lo cubre y si esa cobertura incluye o no el caso específico de Kubernetes.
Ver solución
FinOps → finops-and-cost-guardrails-guide, existe completa, no cubre Kubernetes. SRE → sre-and-incident-response-guide, existe completa, no cubre Kubernetes (aunque nombra esta guía por contraste). GenAI/GPU sobre EKS → genai-on-aws-production-guide, existe completa, pero declara GPU/EKS explícitamente fuera de su propio alcance ejecutable — sigue siendo un hueco real del ecosistema.
Ejercicio 2 — Explica por qué GenAI/GPU es un caso distinto a FinOps y SRE. En dos o tres frases, explica a un colega la diferencia de fondo entre "una guía existe pero no cubre Kubernetes" (FinOps, SRE) y "una guía existe pero declara el tema fuera de su propio alcance ejecutable" (GenAI/GPU).
Ver solución
Una explicación razonable: "En FinOps y SRE, la guía cubre completamente su propio dominio —simplemente ese dominio nunca incluyó Kubernetes, porque el caso Andes Cargo, cuando esas guías se escribieron, no tenía un clúster todavía. En GenAI/GPU, la guía sí reconoce el tema (GPU sobre EKS) como relevante, pero decide, de forma explícita, no construirlo porque no existe ningún camino gratuito para ejecutarlo — es un hueco reconocido y nombrado, no una ausencia de alcance por historia del caso."
Ejercicio 3 — Propón el ejemplo concreto que cerraría el hueco de SRE para Andes Cargo. Basándote en el hallazgo real de la lección 4 de este mismo módulo (Kyverno bloqueando un Deployment que Gatekeeper no cubría), describe, en dos o tres frases, cómo se vería un postmortem sin culpa (el formato de sre-and-incident-response-guide) escrito sobre ese mismo hallazgo.
Ver solución
Una propuesta razonable: "El postmortem describiría el hecho sin buscar culpables: un cambio real intentó remover límites de recursos del Deployment de producción; Kyverno lo bloqueó gracias a su cobertura de autogen, pero Gatekeeper, configurado desde el Módulo 6 con match.kinds: [\"Pod\"], no habría reaccionado si Kyverno no hubiera estado activo. La acción de seguimiento (no una culpa, una mejora del sistema) sería agregar Deployment explícitamente al match.kinds del Constraint de Gatekeeper, para que la protección no dependa de que un solo motor cubra el alcance completo — exactamente el tipo de hallazgo que un postmortem convierte en una mejora concreta, verificable, del propio sistema de guardrails."
Resumen y siguiente paso
Esta lección mapeó, con precisión verificada contra el contenido real de cada guía, los tres dominios que quedan fuera del alcance de esta guía por diseño: FinOps de Kubernetes y SRE del clúster tienen, cada uno, una guía completa ya escrita en este ecosistema —finops-and-cost-guardrails-guide y sre-and-incident-response-guide—, aunque ninguna de las dos extiende todavía su disciplina hacia el caso específico de Kubernetes. GenAI/GPU sobre EKS también tiene una guía completa (genai-on-aws-production-guide), pero esa guía, con la misma honestidad de costo que esta, declara el tema fuera de su propio alcance ejecutable — sigue siendo, de las tres, el único hueco genuinamente sin cubrir del ecosistema completo.
Antes de avanzar deberías poder: nombrar las tres guías reales de este mapa sin dudar; explicar por qué GenAI/GPU es un caso distinto a FinOps/SRE en términos de qué falta; y proponer, con un ejemplo concreto de esta misma guía, cómo se vería el primer paso de cada una de las tres disciplinas aplicada a andes-cargo-status-api.
Siguiente lección: proyecto final, andes-cargo-k8s/ como entregable del capstone. Ahí se cierra esta guía completa con el repositorio real —código, políticas, configuración de clúster— presentado como una pieza de portafolio, con el checklist honesto de qué corrió de verdad y qué quedó representativo.
Recursos
finops-and-cost-guardrails-guide(NIEVA) — la guía completa de FinOps del ecosistema, verificada en esta lección.sre-and-incident-response-guide(NIEVA) — la guía completa de SRE e incident response del ecosistema, verificada en esta lección.genai-on-aws-production-guide(NIEVA) — la guía completa de GenAI en producción de AWS del ecosistema, verificada en esta lección, incluida su propia declaración de límite sobre GPU/EKS.src/paths/aws-cloud-ecosystem/VALIDACION.md— la auditoría de mercado que originó el diseño completo de este ecosistema, incluida la frontera de Kubernetes que esta guía resolvió.