MKA1 sigue un modelo de despliegue alineado con GitOps donde el repositorio de Git es la única fuente de la verdad para toda la infraestructura y el estado de las aplicaciones. Cada despliegue es una transacción atómica de Helm: si algún recurso no llega a estar saludable, toda la publicación se revierte automáticamente sin intervención manual.Documentation Index
Fetch the complete documentation index at: https://docs.mka1.com/llms.txt
Use this file to discover all available pages before exploring further.
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 para 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 con el chart, asegurando que incluso la configuración sensible quede registrada en el historial de Git.
Despliegues atómicos con Helm
Las publicaciones 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 publicación falla su comprobación de disponibilidad, Helm revierte automáticamente toda la publicación a la última revisión conocida como buena.
--atomic— Si la actualización falla en cualquier punto, Helm elimina los nuevos recursos y restaura la publicación anterior. El clúster nunca queda en un estado de despliegue parcial.--wait— Helm espera a que todos los Pods, Servicios y otros recursos reporten estar listos antes de marcar la publicación como exitosa.--timeout 15m— Un límite configurable evita que los despliegues queden colgados indefinidamente. Si no se logra la disponibilidad dentro de ese tiempo, la publicación 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 objetivo 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 publicación 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 publicación 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.