Qué está activo
Git como fuente única de la verdad
Toda la plataforma MKA1 está definida como un único chart de Helm (mka1-platform) almacenado en el repositorio de Git infra-resources.
Ningún cambio llega a un clúster sin antes ser confirmado y revisado mediante una pull request.
- El chart de Helm y los archivos de valores definen cada carga de trabajo, servicio, plantilla de secretos, HPA y PDB de la plataforma.
- Anulaciones específicas por entorno separan la configuración de staging y producción mientras comparten la misma definición de chart.
- Secretos cifrados se gestionan con SOPS y se confirman junto al chart, asegurando que incluso la configuración sensible quede registrada en el historial de Git.
Despliegues atómicos con Helm
Las releases de Helm se ejecutan con la opción--atomic, que envuelve toda la actualización en una transacción.
Si algún recurso de la release falla su verificación de disponibilidad, Helm revierte automáticamente toda la release a la última revisión conocida como válida.
--atomic— Si la actualización falla en cualquier punto, Helm elimina los nuevos recursos y restaura la release anterior. El clúster nunca queda en un estado parcialmente desplegado.--wait— Helm espera a que todos los Pods, Servicios y otros recursos reporten estar listos antes de marcar la release como exitosa.--timeout 15m— Un límite configurable evita que los despliegues queden colgados indefinidamente. Si no se alcanza la disponibilidad dentro del tiempo, la release se considera fallida y se revierte.
Reconciliación automatizada vía CI/CD
Los flujos de trabajo de GitHub Actions se disparan automáticamente en cada push amain que modifique rutas de infraestructura.
El pipeline se autentica con AWS, configura kubectl para el clúster EKS de destino y aplica el estado deseado definido en Git:
- Un desarrollador fusiona una pull request en
main. - GitHub Actions detecta el cambio y dispara el flujo de despliegue.
- El flujo extrae el repositorio en el SHA del commit fusionado.
helm upgrade --install --atomicreconcilia el clúster para que coincida con el estado deseado definido en Git.- Si no se puede alcanzar el estado deseado, la reversión atómica garantiza que el clúster permanezca en la última revisión exitosa.
Historial de despliegue inmutable
Cada release de Helm crea una revisión versionada almacenada en el clúster. Esto proporciona una pista de auditoría completa de lo que se desplegó, cuándo y desde qué commit de Git.Cómo lo validamos
Validamos el flujo de trabajo GitOps inspeccionando el estado de la release de Helm desplegada y confirmando que coincide con la configuración definida en Git.main dispara un ciclo completo de reconciliación.
Si el estado del clúster se desvía del estado deseado definido en Git, la siguiente ejecución del pipeline lo corrige.