Entrega a Kubernetes¶

El flujo conserva los manifiestos en Git y los aplica desde un job de GitLab a través del agente del clúster seleccionado. El mecanismo versionado es una entrega impulsada por CI. No hay reconciliación continua de un controlador GitOps ni despliegue simultáneo a las dos nubes.

Paso 1: actualizar el estado deseado¶

update-k8s-manifests clona CD_PROJECT_PATH, cambia a main y sustituye la referencia de imagen de deployment.yaml. Si hay diferencias, crea un commit cuyo mensaje es el SHA de la aplicación y lo envía a main; si no, termina sin crear un commit vacío.

Las credenciales se reciben mediante CD_DEPLOY_USER y CD_DEPLOY_TOKEN. Ese nombre de variable no determina el tipo de token: el push requiere un token/identidad con permiso de escritura en el repositorio de manifiestos y en su rama protegida. Un Deploy Token de GitLab con read_repository no basta para escribir. Los permisos reales no están versionados.

La rama está fijada a main. El reemplazo usa sed y busca una referencia que empiece por CI_REGISTRY_IMAGE; si se renombra el registro o el manifiesto cambia de estructura, verificar el diff antes de dar por actualizada la imagen.

Paso 2: seleccionar un destino¶

Valor	Contexto por defecto de la plantilla
`eks`	`gabriel-canals-tfm/terraform-modules:eks-agent`
`gke`	`gabriel-canals-tfm/terraform-modules:gke-agent`

La plantilla define eks por defecto, pero los dos proyectos de aplicación lo sobrescriben con gke. CLOUD_PROVIDER del pipeline de infraestructura y DEPLOY_TARGET del pipeline de aplicación son variables independientes. Crear AWS no cambia automáticamente el destino de una entrega de aplicación.

El job utiliza el kubeconfig inyectado por GitLab Agent. Lista contextos, selecciona uno y comprueba la existencia del namespace app, que intenta crear si no existe. Esto requiere las autorizaciones de GitLab y Kubernetes descritas en acceso mediante agentes.

Paso 3: aplicar manifiestos¶

El job deploy instala herramientas y descarga el kubectl estable disponible en ese momento. Vuelve a clonar main del repositorio de manifiestos y ejecuta kubectl apply sobre todos sus YAML en el namespace. Termina listando los recursos con kubectl get all.

sequenceDiagram
  participant A as Pipeline de aplicación
  participant M as Repositorio de manifiestos
  participant G as GitLab Agent
  participant K as API Kubernetes
  A->>M: Actualizar imagen y enviar commit
  A->>M: Clonar main para el job deploy
  A->>G: Seleccionar contexto y aplicar YAML
  G->>K: Crear o actualizar recursos
  K-->>A: Respuesta del comando

La respuesta de apply indica aceptación de los objetos. No garantiza que termine el RollingUpdate ni que la aplicación responda correctamente. El snapshot no ejecuta rollout status ni smoke tests y no declara un bloque environment: en estos jobs.

Contratos de Kubernetes¶

Cada proyecto de manifiestos contiene un Deployment, Service y ServiceAccount. Los servicios rest y web son ClusterIP sobre 8080. Ambos Deployments necesitan imagePullSecrets: registry, pero ningún repositorio revisado crea ese Secret de registro. Debe suministrarse por el mecanismo de bootstrap elegido, con permisos de lectura y rotación adecuados.

El frontend añade un Ingress de clase alb con TLS ACM, dominio específico y rutas para ambos servicios. Terraform AWS instala el controlador ALB; GCP no declara una implementación equivalente. Aplicar ese YAML en GKE no demuestra que exista una URL pública funcional. El capítulo GCP delimita esa parte pendiente de confirmar.

Límites y mejoras propuestas¶

Aspecto	Snapshot	Mejora propuesta
Versión de manifiestos	El segundo job lee `main` de nuevo	Propagar el SHA exacto creado en el primer job
Concurrencia	Sin `resource_group` en aplicación	Serializar por servicio y destino
Salud	`apply` y listado	Rollout con timeout y prueba HTTP/API
Helm	Se detecta `Chart.yaml`, pero deploy termina con error	Implementar Helm antes de anunciar soporte
Cliente Kubernetes	Descarga la versión estable sin fijar	Fijar una versión compatible con cada clúster
Eliminación de objetos	`apply` no elimina objetos retirados de Git	Procedimiento explícito de retirada y ownership

Dos pipelines concurrentes pueden actualizar el mismo main o aplicar una revisión más reciente que la del pipeline inicial. También un revert en el repositorio de manifiestos no despliega por sí solo porque ese repositorio no tiene CI. El runbook de rollback explica cómo cerrar el circuito.