El almacenamiento de todos los recursos y registros de Argo Workflows directamente en el clúster de Kubernetes puede generar una presión significativa en etcd, impactando la estabilidad del sistema. Este artículo detalla cómo implementar mecanismos de limpieza automática (GC) y archivado externo para mitigar este problema.
Recopilación de basura (Garbage Collection) para Workflows
El mecanismo GC de Argo Workflows elimina de forma periódica los objetos Workflow completados o con errores, según una política definida. Esto evita la saturación de etcd.
Configuración del controlador
La política de retención se configura en el ConfigMap del controlador. Primero, identifica el ConfigMap en uso:
kubectl -n argo get deploy argo-workflows-workflow-controller -o jsonpath='{.spec.template.spec.containers[0].args}' | grep -o '\-\-configmap=[^ ]*'
Suponiendo que es argo-workflows-controller-config, edítalo para añadir la sección retentionPolicy:
apiVersion: v1
data:
controller-config.yaml: |
retentionPolicy:
completed: 5
failed: 2
errored: 2
kind: ConfigMap
metadata:
name: argo-workflows-controller-config
namespace: argo
Esta configuración retiene los 5 workflows completados con éxito y 2 de los que fallaron o tuvieron error. Tras guardar los cambios, reinicia el controlador para que tome efecto:
kubectl -n argo rollout restart deployment argo-workflows-workflow-controller
Verificación del GC
Para comprobar el funcionamiento, crea varios workflows y observa cómo se eliminan los más antiguos al alcanzar el límite definido. Un script simple de ejemplo:
for idx in $(seq 1 8); do
cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: gc-test-${idx}-
spec:
entrypoint: echo-task
templates:
- name: echo-task
container:
image: alpine
command: [echo, "Prueba de GC número ${idx}"]
EOF
sleep 2
done
Después de que todos finalicen, ejecuta kubectl get wf -n argo repetidamente. Deberías ver que solo se conservan los 5 más recientes con estado Succeeded.
Archivado de Workflows en una base de datos externa
El GC borra los registros del clúster. Para mantener un historial consultable, Argo puede archivar los objetos Workflow en una base de datos como PostgreSQL.
Preparación del almacenamiento
Despliega una instancia de PostgreSQL. Usando Helm:
helm install argo-db oci://registry-1.docker.io/bitnamicharts/postgresql \
--set auth.postgresPassword=miPasswordSeguro \
--set auth.database=argo_archive \
--set primary.persistence.size=5Gi
Configuración del archivado
Modifica el ConfigMap del controlador para activar el archivado y proporcionar los detalles de conexión:
apiVersion: v1
data:
controller-config.yaml: |
persistence:
archive: true
archiveTTL: 90d # Los registros se eliminan después de 90 días
postgresql:
host: argo-db-postgresql.argo.svc.cluster.local
port: 5432
database: argo_archive
tableName: workflow_history
userNameSecret:
name: db-credentials
key: username
passwordSecret:
name: db-credentials
key: password
kind: ConfigMap
metadata:
name: argo-workflows-controller-config
namespace: argo
Crea el Secret con las credenciales:
kubectl -n argo create secret generic db-credentials \
--from-literal=username=postgres \
--from-literal=password=miPasswordSeguro
Asegúrate de que el controlador tenga permisos para leer este Secret. Si es necesario, ajusta los permisos RBAC. Reinicia los componentes tras la configuración.
kubectl -n argo rollout restart deploy argo-workflows-server
kubectl -n argo rollout restart deploy argo-workflows-workflow-controller
El controlador creará automáticamente las tablas necesarias en la base de datos, como workflow_history e archived_workflows_labels.
Limpieza de los registros archivados
El parámetro archiveTTL define la duración de los registros archivados. La tarea de limpieza correspondiente se ejecuta periódicamente (por defecto, cada 24 horas). Puedes ajustar su frecuencia añadiendo una variable de entorno al Deployment del controlador:
env:
- name: ARCHIVED_WORKFLOW_GC_PERIOD
value: "12h"
Después de modificar el Deployment, los registros archivados más antiguos que el TTL especificado se borrarán automáticamente en el próximo ciclo de limpieza.
Archivado de logs de los Pods
Los logs de ejecución residen en los Pods. Si estos se eliminan, los logs se pierden. La solución es configurar el archivado de logs hacia un almacenamiento de objetos compatible con S3.
Configuración global del repositorio de artefactos
En el ConfigMap del controlador, define un artifactRepository global con el habilitador de logs y la configuración de S3 (ej. MinIO):
artifactRepository:
archiveLogs: true
s3:
endpoint: minio-service.argo.svc:9000
bucket: argo-workflow-logs
insecure: true
accessKeySecret:
name: s3-creds
key: accesskey
secretKeySecret:
name: s3-creds
key: secretkey
Esta configuración se añade al archivo controller-config.yaml dentro del ConfigMap. También necesitas crear el Secret s3-creds con las claves de acceso.
Jerarquía y granularidad de la configuración
La decisión de archivar logs puede configurarse en tres niveles con la siguiente prioridad:
- Configuración del controlador (global): Tiene la mayor prioridad. Si está activada (
true), se archivan los logs a menos que se desactive explícitamente a un nivel inferior. - Especificación del Workflow (
spec): Puede anular la configuración del controlador si este último no fuerza la activación. - Template individual: Nivel de mayor granularidad.
Un enfoque recomendable es activar el archivado globalmente y desactivarlo solo en templates específicos que no requieran persistencia de logs.
Prueba y verificación
Crea un workflow simple con la configuración global activa. Una vez completado, localiza el archivo de log en el bucket de S3 configurado. La ruta típica sigue el patrón: <bucket>/<nombre-workflow>/<nombre-paso>/main.log.
Puedes descargar el archivo para verificar que contiene la salida estándar y de error del contenedor del Pod.
Consideraciones para producción
En un entorno de producción, es crucial implementar una combinación de estas estrategias:
- Política de GC estricta para controlar el uso de recursos del clúster.
- Archivado a base de datos para auditoría y consultas históricas a largo plazo.
- Archivado de logs a S3 para depuración y cumplimiento, asegurando que los logs sobrevivan a la vida de los Pods.
- Monitoreo del espacio utilizado en PostgreSQL y S3, y ajuste de los TTLs según sea necesario.