Módulo 8: Capstone Andes Cargo On Kubernetes

1. Introducción al capstone

Descripción

Los siete módulos anteriores construyeron, pieza por pieza, un clúster de Kubernetes completo: primitivas de carga de trabajo (Módulo 2), configuración y salud (Módulo 3), red e Ingress (Módulo 4), GitOps pull-based con ArgoCD (Módulo 5), admission control y escaneo de imagen (Módulo 6), y lo específico de EKS en producción, representativo (Módulo 7). Este módulo no agrega ninguna pieza nueva. Es el capstone: toma el sistema completo, ya corriendo, y lo somete a la prueba que de verdad importa — un cambio real que atraviesa todas las capas a la vez, dos veces, una que pasa y una que el sistema detiene.

Conexión con el módulo

Todo lo que sigue en las próximas siete lecciones usa, sin ningún cambio, el mismo clúster andes-cargo-cluster que dejaste sano al cerrar el Módulo 6 — el mismo repositorio andes-cargo-k8s que Gitea sirve, el mismo Application que ArgoCD sincroniza, los mismos dos motores de políticas activos a la vez. Esta lección no ejecuta ningún comando — establece qué se va a entregar, y por qué el orden de las siete lecciones que siguen no es arbitrario.

Qué construyeron los siete módulos anteriores, en una sola tabla

Módulo	Qué dejó corriendo, hoy	Estado
1	`andes-cargo-cluster` (`kind v0.32.0`, Kubernetes `v1.36.1`), un plano de control y dos nodos de trabajo; la imagen `andes-cargo-status-api:latest` cargada en los tres	Ejecutado
2	El `Deployment andes-cargo-status-api` y el `Service status-api-service` (`ClusterIP`), con réplicas administradas por un `ReplicaSet`	Ejecutado
3	`ConfigMap`/`Secret` externalizados, tres `probes` (`startup`/`readiness`/`liveness`), y un `HorizontalPodAutoscaler` reaccionando a CPU real vía `metrics-server`	Ejecutado
4	`ingress-nginx` instalado a mano, `Ingress` exponiendo `status-api-service` por `http://andes-cargo.local`, y dos `NetworkPolicy` (default-deny + permiso explícito desde `ingress-nginx`)	Ejecutado
5	Gitea (`andes-cargo/andes-cargo-k8s`) y ArgoCD `v3.5.1`, ambos dentro del clúster; un `Application` sincronizando diez manifiestos, con `selfHeal`/`prune` activos	Ejecutado
6	OPA Gatekeeper `v3.23.0` y Kyverno `v1.18.2`, ambos activos a la vez sobre `andes-cargo`, exigiendo `resources.requests`/`limits` en todo `Pod`; `trivy image` como gate antes de cargar una imagen nueva	Ejecutado
7	Qué cambia con un plano de control gestionado real: node groups, Fargate, IRSA/EKS Pod Identity, Karpenter, el AWS Load Balancer Controller	Representativo, honestidad de costo declarada

Nueve tipos de objeto conviven hoy en el namespace andes-cargo: Deployment, Service, ConfigMap, Secret, HorizontalPodAutoscaler, Ingress, dos NetworkPolicy, y el propio Namespace — todos sincronizados por ArgoCD desde un solo repositorio Git, todos evaluados por dos motores de admission control independientes en el instante de cada cambio.

Qué entrega este módulo, lección por lección

   MÓDULO 8 — CAPSTONE: ANDES CARGO EN KUBERNETES

   M8.1  Introducción (esta)                     qué se entrega, el mapa de M1-M7
   M8.2  Repaso de arquitectura                   diagrama completo del clúster + flujo GitOps
   M8.3  Un cambio que cruza el gate               EJECUTADO — Git → ArgoCD → admitido, sin kubectl apply
   M8.4  Un cambio que el gate detiene              EJECUTADO — rechazado antes de crear el Pod, dos motores
   M8.5  Lo que esta guía dejó representativo       honestidad final, EKS en un solo lugar
   M8.6  La corrección de continuidad               "Andes Cargo no tiene contenedores" — ya no
   M8.7  Lo que Andes Cargo todavía necesita         FinOps, SRE, GenAI/GPU — el resto del ecosistema
   M8.8  Proyecto final: andes-cargo-k8s/           el repositorio completo como pieza de portafolio

Las lecciones 3 y 4 son el corazón del capstone, y las dos comparten una misma estructura de prueba: un cambio real, subido con git push a Gitea, sin que nadie ejecute kubectl apply contra el clúster en ningún momento. La lección 3 muestra qué pasa cuando ese cambio es inocuo — cruza las tres capas (Git, ArgoCD, admission control) sin fricción, y queda corriendo. La lección 4 muestra qué pasa cuando ese cambio viola la política de recursos que el Módulo 6 construyó — y el resultado, verificado dos veces contra este mismo clúster, tiene un matiz real que ningún módulo anterior mostró: los dos motores de políticas no cubren exactamente el mismo territorio, y este capstone es el primer lugar donde esa diferencia se vuelve visible.

Las lecciones 5, 6 y 7 cierran el arco de honestidad de todo el ecosistema Andes Cargo: qué quedó representativo y por qué (5), qué corrección de continuidad esta guía le debe al resto del ecosistema (6), y qué le falta todavía a Andes Cargo más allá de esta guía (7). La lección 8 es el proyecto final: el repositorio andes-cargo-k8s/ completo, con gatekeeper/, kyverno/ y kind-config.yaml, presentado como una pieza de portafolio defendible frente a cualquiera que pregunte "¿qué de esto corrió de verdad?".

Analogía: la inspección final de la fábrica automatizada

Todo este módulo se puede leer bajo una sola imagen, la misma que gobierna cada lección que sigue: andes-cargo-cluster es una fábrica completamente automatizada. La orden de producción entra por una sola puerta —Git, el repositorio que Gitea sirve—, nunca por una orden verbal a un operario. La línea de ensamblaje se reconfigura sola cuando la orden cambia —ArgoCD, el mecanismo del Módulo 5, que hace watch del repositorio y ajusta la línea sin que nadie mueva una palanca—. Y antes de que cualquier pieza entre a la línea, un control de calidad la revisa —Gatekeeper y Kyverno, el portero del Módulo 6, parado en la única puerta de entrada al clúster— y la rechaza si no cumple la especificación, antes de que ocupe espacio en la línea.

Este módulo es la inspección final de esa fábrica: no se abre ninguna máquina nueva, no se instala ninguna herramienta nueva. Se manda una orden de producción inocua por la puerta correcta, y se confirma que sale, sola, del otro lado, funcionando (lección 3). Se manda una orden de producción defectuosa, y se confirma que el control de calidad la detiene antes de que llegue a la línea (lección 4). Y al final, se entrega el manual completo de la fábrica —el repositorio— con la etiqueta honesta de qué parte de esa fábrica es de verdad, y qué parte es el plano de la ampliación que todavía no se construyó (EKS, Módulo 7).

Qué NO hace este módulo

Vale la pena decirlo antes de empezar, con la misma honestidad que sostuvo toda esta guía: este módulo no agrega ninguna primitiva de Kubernetes nueva, ningún motor de políticas nuevo, ninguna herramienta nueva. Todo lo que corre en las lecciones 3 y 4 ya corrió, individualmente, en algún módulo anterior — lo único genuinamente nuevo es verlo correr junto, de punta a punta, con la disciplina completa (Git como única fuente de verdad, cero kubectl apply manual) que cada módulo anterior enseñó por separado.

Errores comunes

Esperar contenido técnico nuevo en este módulo, y sentirse defraudado al no encontrarlo (de expectativa). Qué pasa: alguien llega a este módulo esperando un motor de políticas nuevo, una primitiva de Kubernetes que los siete módulos anteriores no cubrieron, o un servicio de AWS adicional. Cómo detectarlo: si tu pregunta al empezar esta lección es "¿qué voy a aprender de nuevo aquí?". Cómo corregirlo: la pregunta correcta para este módulo es "¿qué pasa cuando junto todo lo que ya aprendí?" — el valor de un capstone no está en el contenido nuevo, está en la integración verificada de contenido que ya existe, disperso en siete módulos distintos.

Asumir que este módulo repite las pruebas del Módulo 6 con otro nombre (de solapamiento aparente). Qué pasa: alguien, al ver "Gatekeeper" y "Kyverno" mencionados otra vez en la lección 4, asume que es la misma prueba de bad-pod-no-limits.yaml del Módulo 6. Cómo detectarlo: si tu resumen mental es "ya vi esto". Cómo corregirlo: el Módulo 6 probó los dos motores contra Pods de prueba aislados, aplicados con kubectl apply directo. Este módulo prueba los dos motores contra el propio Deployment de producción, a través del flujo completo de GitOps — y el resultado, como vas a ver en la lección 4, no es idéntico al del Módulo 6.

Ejercicios

Ejercicio 1 — Reconstruye la tabla de memoria. Sin volver a mirar la tabla de este módulo, enumera los siete módulos anteriores y, para cada uno, la pieza principal que dejó corriendo en andes-cargo-cluster.

Ver solución

M1: el clúster mismo, con la imagen cargada. M2: el Deployment/Service de andes-cargo-status-api. M3: ConfigMap/Secret/probes/HorizontalPodAutoscaler. M4: ingress-nginx, Ingress, dos NetworkPolicy. M5: Gitea, ArgoCD, el Application sincronizando el repositorio. M6: Gatekeeper y Kyverno activos, más trivy image como gate. M7: nada ejecutado contra AWS real — representativo, con la razón de costo declarada.

Ejercicio 2 — Explica la analogía de la fábrica con tus propias palabras. Sin copiar el texto de esta lección, explica a un colega qué representa cada una de las tres piezas de la analogía (la puerta de entrada, la línea que se reconfigura sola, el control de calidad) en términos de los objetos reales de Kubernetes que construiste.

Ver solución

Una explicación razonable: "La puerta de entrada es Git —el repositorio que Gitea sirve—, porque cualquier cambio que el clúster vaya a aplicar tiene que pasar por ahí primero. La línea que se reconfigura sola es ArgoCD, que compara el repositorio contra el clúster real cada pocos segundos y corrige la diferencia sin que nadie ejecute ningún comando. El control de calidad son Gatekeeper y Kyverno, los dos motores de admission control que revisan cada objeto antes de que etcd lo guarde — si no cumple la política, nunca llega a existir."

Ejercicio 3 — Predice el resultado de las lecciones 3 y 4 antes de leerlas. Basándote solo en lo que ya sabes de los Módulos 5 y 6, predice: ¿qué tres piezas del sistema tendrían que confirmar, con evidencia real, que un cambio "pasó el gate completo"? ¿Y qué pieza tendría que fallar, primero, para que un cambio "no pase"?

Ver solución

Para que un cambio pase el gate completo, hacen falta tres confirmaciones: (1) Gitea recibió el git push — confirmable con git log/git clone fresco; (2) ArgoCD detectó el cambio y lo aplicó sin intervención manual — confirmable con kubectl get application/argocd app get, viendo el Sync Status avanzar al nuevo commit; (3) el objeto resultante quedó corriendo en el clúster — confirmable con kubectl get pods. Para que un cambio no pase, la pieza que tiene que fallar es la más profunda de las tres: el objeto nunca llega a existir en etcd, porque uno de los dos motores de admission control lo rechaza antes — Git y ArgoCD pueden completar su parte perfectamente (el repositorio tiene el cambio, ArgoCD lo intenta aplicar), y aun así el resultado final es que nada nuevo corre.

Resumen y siguiente paso

Esta lección no ejecutó ningún comando — estableció el mapa de las siete lecciones que siguen y recordó, en una sola tabla, qué dejaron corriendo los siete módulos anteriores: un clúster real, con GitOps pull-based real y admission control real encima, y solo lo específico de EKS quedando representativo por una razón de costo declarada desde el Módulo 7. La analogía de la fábrica automatizada —orden por Git, línea que se ajusta sola, control de calidad antes de la línea— es la imagen que vas a ver aplicada, con evidencia literal, en las lecciones 3 y 4.

Antes de avanzar deberías poder: reconstruir la tabla de los siete módulos anteriores de memoria; explicar la analogía de la fábrica con tus propias palabras; y predecir qué tres confirmaciones hacen falta para decir que un cambio "cruzó el gate completo".

Siguiente lección: repaso de arquitectura, el clúster completo. Ahí vas a ver, en un solo diagrama, los ocho namespaces que conviven hoy en andes-cargo-cluster y el flujo completo Gitea → ArgoCD → clúster, antes de someterlo a la prueba de las lecciones 3 y 4.

Recursos

Kubernetes — Workloads — referencia oficial de las primitivas que este capstone integra, ya construidas en los Módulos 1-4.
Argo CD — Core Concepts — el vocabulario de GitOps que las lecciones 3 y 4 de este módulo ponen a prueba de punta a punta.
kubernetes-and-eks-in-production-guide (NIEVA), Módulos 1-7 — la fuente completa de cada pieza que este capstone integra, sin repetir su construcción.

← Anterior8. Proyecto: el plan de migración de Andes Cargo, `kind` → EKS real Siguiente →2. Repaso de arquitectura: el clúster completo