EKS GitOps Platform
A container delivery platform with declarative releases, health checks and a rehearsed rollback path.
Kubernetes · Argo CD · Helm
Scope: architecture and validation design. The indicators summarize design targets. Implementation evidence will be added as the lab develops.
The scenario
A fictional team deploys containers by hand. Release history lives in chat messages, and recovering the previous version depends on someone remembering an image tag.
Architecture
CI builds and scans a container image, records its immutable digest and proposes a change to a separate configuration repository. Argo CD reconciles Helm manifests into an EKS namespace. Application startup, readiness and liveness checks have separate responsibilities.
Key decisions
The application pipeline never needs cluster-admin credentials. Delivery permissions are separated from build permissions. A previous configuration can be restored through a reviewed Git revert; database migrations still require a separately designed compatibility strategy.
Validation plan
The lab plan deploys a healthy image, a slow-starting image and an image that fails readiness. It observes rollout progress, verifies that unready pods do not receive Service traffic, and tests recovery to the previous digest.
Trade-offs
GitOps adds a controller and repository conventions to maintain. Automatic reconciliation should not be confused with automatic recovery from every application failure. Readiness probes, resource limits and alerting remain part of the platform contract.
Next iteration
Add a small service, publish its manifests and capture a failed rollout and recovery. Release-time improvements remain a hypothesis until repeated runs produce evidence.
El escenario
Un equipo ficticio despliega contenedores manualmente. El historial queda en mensajes y recuperar una versión depende de que alguien recuerde la etiqueta de una imagen.
Arquitectura
CI construye y analiza una imagen, registra su digest inmutable y propone un cambio en un repositorio separado de configuración. Argo CD reconcilia los manifiestos Helm en un namespace de EKS. Las comprobaciones de startup, readiness y liveness tienen responsabilidades distintas.
Decisiones técnicas
El pipeline de la aplicación no necesita credenciales cluster-admin. Los permisos de entrega se separan de los de construcción. Una configuración previa se restaura con un Git revert revisado; las migraciones de base de datos necesitan una estrategia de compatibilidad independiente.
Plan de validación
El laboratorio propone desplegar una imagen sana, otra de arranque lento y otra que falla readiness. Se observa el rollout, se verifica que los pods no preparados no reciban tráfico del Service y se prueba recuperar el digest previo.
Concesiones del diseño
GitOps incorpora un controlador y convenciones que mantener. La reconciliación automática no equivale a recuperarse de cualquier fallo de aplicación. Las probes, los límites de recursos y las alertas siguen formando parte del contrato de la plataforma.
Próxima iteración
Añadir un servicio pequeño, publicar los manifiestos y registrar un rollout fallido y su recuperación. La mejora del tiempo de entrega seguirá siendo una hipótesis hasta contar con ejecuciones repetibles.