Sync Waves: ordenar despliegues complejos
Un despliegue de aplicación complejo puede tener dependencias: la base de datos debe estar disponible antes de que inicie la API, la API debe estar disponible antes de que inicie el worker, las migraciones deben completarse antes de que el nuevo código empiece a servir tráfico. Sync Waves permiten definir el orden de creación de recursos dentro de una Application de ArgoCD.
# Wave 0: CRDs y namespaces — siempre primero
apiVersion: v1
kind: Namespace
metadata:
name: production
annotations:
argocd.argoproj.io/sync-wave: "0"
---
# Wave 1: ConfigMaps y Secrets — antes que los Deployments
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
annotations:
argocd.argoproj.io/sync-wave: "1"
---
# Wave 2: Deployments y StatefulSets
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
annotations:
argocd.argoproj.io/sync-wave: "2"
---
# Wave 3: Ingress — después de que los servicios estén listos
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-ingress
annotations:
argocd.argoproj.io/sync-wave: "3"ArgoCD respeta el orden de las waves: no pasa a la wave N+1 hasta que todos los recursos de la wave N estén Healthy. Esto garantiza que el Ingress nunca se crea antes de que el Deployment esté listo, y que las migraciones se completan antes de que el tráfico llegue al nuevo código.
Resource Hooks: operaciones de pre y post-sync
Los hooks permiten ejecutar Jobs de Kubernetes en momentos específicos del ciclo de sync de ArgoCD. Los hooks más útiles en producción:
# PreSync hook — ejecutar migraciones antes del deploy
apiVersion: batch/v1
kind: Job
metadata:
name: db-migration
annotations:
argocd.argoproj.io/hook: PreSync
argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: empresa/api:latest
command: ["npm", "run", "db:migrate"]
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: db-credentials
key: url# PostSync hook — smoke test después del deploy
apiVersion: batch/v1
kind: Job
metadata:
name: smoke-test
annotations:
argocd.argoproj.io/hook: PostSync
argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
template:
spec:
restartPolicy: Never
containers:
- name: test
image: curlimages/curl:latest
command:
- /bin/sh
- -c
- |
for i in $(seq 1 5); do
curl -sf http://api.production.svc.cluster.local/health && exit 0
sleep 5
done
exit 1ApplicationSets: gestión de múltiples clusters y environments
ApplicationSet es el generador de Applications de ArgoCD. En lugar de crear manualmente una Application por cada cluster × environment × servicio, defines una plantilla y el generador crea todas las Applications automáticamente.
# ApplicationSet — deploy del mismo servicio en múltiples clusters
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: api-all-clusters
namespace: argocd
spec:
generators:
- matrix:
generators:
- clusters:
selector:
matchLabels:
region: latam
- list:
elements:
- env: staging
- env: production
template:
metadata:
name: 'api-{{name}}-{{env}}'
spec:
project: default
source:
repoURL: https://github.com/empresa/infra.git
path: 'apps/api/{{env}}'
targetRevision: main
destination:
server: '{{server}}'
namespace: '{{env}}'
syncPolicy:
automated:
prune: true
selfHeal: '{{eq env "staging"}}' # solo auto-sync en stagingExternal Secrets Operator: el patrón correcto para secretos
External Secrets Operator (ESO) sincroniza secretos desde AWS Secrets Manager, GCP Secret Manager, Azure Key Vault o HashiCorp Vault directamente a Kubernetes Secrets. La ventaja sobre Sealed Secrets: los secretos se rotan en el vault y se propagan automáticamente al cluster sin redeploy.
# ExternalSecret — sincronizar desde AWS Secrets Manager
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-credentials
namespace: production
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: ClusterSecretStore
target:
name: db-credentials
creationPolicy: Owner
data:
- secretKey: DATABASE_URL
remoteRef:
key: prod/api/database
property: url
- secretKey: DATABASE_PASSWORD
remoteRef:
key: prod/api/database
property: passwordDiff personalizado: ignorar campos que cambian en runtime
ArgoCD puede marcar una Application como OutOfSync por campos que cambian en runtime sin ser cambios de código (replicas manejadas por HPA, timestamps de last-applied-configuration, annotations de monitoring). La configuración ignoreDifferences previene false positives de drift.
spec:
ignoreDifferences:
- group: apps
kind: Deployment
jsonPointers:
- /spec/replicas # ignorar réplicas gestionadas por HPA
- group: ""
kind: ConfigMap
name: kube-root-ca.crt
jsonPointers:
- /data # ignorar ConfigMap de CA gestionado por KubernetesPreguntas frecuentes
¿Cuántas Applications puede gestionar ArgoCD antes de degradar el rendimiento?
¿Cómo gestiono el RBAC de ArgoCD para que cada equipo solo vea sus aplicaciones?
¿Qué pasa con las aplicaciones stateful (bases de datos) en ArgoCD?
¿Cómo implemento rollback automático si el PostSync hook falla?
¿Es necesario ArgoCD Image Updater o es mejor actualizar imágenes desde el pipeline CI?
¿Tu equipo quiere implementar patrones avanzados de despliegue con ArgoCD en producción? Tenemos experiencia operando ArgoCD en clusters empresariales.
Habla con el equipo