En este artículo veremos cómo implementar una estrategia GitOps usando Flux, un operador para Kubernetes que mantiene tu clúster sincronizado con un repositorio Git. Esta es una guía práctica que puedes seguir para automatizar tus despliegues de manera segura y reproducible.
¿Qué es GitOps?
GitOps es una metodología que utiliza Git como única fuente de verdad para las configuraciones e infraestructura. Cada cambio se realiza mediante pull requests y se refleja automáticamente en el entorno.
Beneficios clave:
- Historial de cambios claro y auditable.
- Reversión sencilla usando
git revert
. - Automatización del ciclo de vida de aplicaciones.
¿Qué es Flux?
Flux es una herramienta CNCF que actúa como un controlador que se ejecuta dentro de tu clúster de Kubernetes y aplica automáticamente los cambios definidos en tus repositorios Git.
Requisitos previos
- Un clúster de Kubernetes (puedes usar kind para pruebas locales o cualquier proveedor cloud).
-
kubectl
configurado. -
flux
CLI instalado (instrucciones). - Un repositorio Git (GitHub, GitLab, etc.).
🧪 Ejemplo simple: Despliegue de una app con Flux
Paso 1: Instalar Flux
flux bootstrap github
--owner=tu-usuario
--repository=tu-repo
--branch=main
--path=clusters/mi-cluster
--personal
Paso 2: Estructura del repositorio
.
├── clusters/
│ └── mi-cluster/
│ ├── kustomization.yaml
│ └── apps/
│ └── nginx/
│ ├── deployment.yaml
│ └── kustomization.yaml
Ejemplo de kustomization.yaml
en apps/nginx/
:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
clusters/mi-cluster/kustomization.yaml
:
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: apps
namespace: flux-system
spec:
interval: 1m
path: ./clusters/mi-cluster/apps
prune: true
sourceRef:
kind: GitRepository
name: flux-system
Paso 3: Despliegue automático
git add .
git commit -m "Agregar despliegue de nginx"
git push
🌱 Ejemplo avanzado: Múltiples entornos (dev y prod)
Una estrategia común en GitOps es separar los entornos por carpetas, usando Kustomize para sobreescribir valores.
Estructura del repositorio
.
├── apps/
│ └── nginx/
│ ├── base/
│ │ ├── deployment.yaml
│ │ └── kustomization.yaml
│ ├── dev/
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── prod/
│ ├── kustomization.yaml
│ └── patch.yaml
├── clusters/
│ ├── dev/
│ │ └── kustomization.yaml
│ └── prod/
│ └── kustomization.yaml
apps/nginx/base/kustomization.yaml
resources:
- deployment.yaml
apps/nginx/dev/kustomization.yaml
resources:
- ../base
patchesStrategicMerge:
- patch.yaml
Y patch.yaml
podría modificar el número de réplicas:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 1
apps/nginx/prod/patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
clusters/dev/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: nginx-dev
namespace: flux-system
spec:
interval: 1m
path: ./apps/nginx/dev
prune: true
sourceRef:
kind: GitRepository
name: flux-system
targetNamespace: dev
Y análogamente para prod
.
Verificación y monitoreo
flux get kustomizations
kubectl get pods -n dev
kubectl get pods -n prod
Conclusión
Flux y GitOps te permiten automatizar múltiples entornos de forma limpia y reproducible. Separar dev
y prod
con Kustomize mantiene tus bases reutilizables y tus entornos consistentes.
¿Te gustaría ver un ejemplo con Helm Charts o integración con ArgoCD? ¡Déjalo en los comentarios! 🙌