{"id":119,"date":"2026-03-08T05:22:41","date_gmt":"2026-03-08T05:22:41","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/08\/configuracin-de-argocd-para-gitops-tutorial-paso-a\/"},"modified":"2026-03-18T22:00:24","modified_gmt":"2026-03-18T22:00:24","slug":"configuracin-de-argocd-para-gitops-tutorial-paso-a","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/08\/configuracin-de-argocd-para-gitops-tutorial-paso-a\/","title":{"rendered":"C\u00f3mo configur\u00e9 ArgoCD para GitOps en Kubernetes: lo que nadie te cuenta"},"content":{"rendered":"

Un viernes por la tarde, hace unos 14 meses, desplegu\u00e9 la versi\u00f3n incorrecta de nuestro servicio de pagos en producci\u00f3n<\/a>. No fue un error de c\u00f3digo<\/a> \u2014 fue un error de proceso. Corr\u00ed kubectl apply -f .<\/code> desde mi laptop con cambios locales sin commitear, y durante 23 minutos el sistema respondi\u00f3 con errores 500. Cuatro personas en el<\/a> equipo, silencio total en Slack, y yo mirando los logs sin saber exactamente qu\u00e9 hab\u00eda pasado.<\/p>\n

Esa semana empec\u00e9 a investigar GitOps de verdad<\/a>.<\/p>\n

Por qu\u00e9 termin\u00e9 con ArgoCD y no con Flux<\/h2>\n

Revis\u00e9 las dos opciones principales: Flux v2 y ArgoCD. Ambas resuelven el mismo problema fundamental \u2014 que el estado de tu cl\u00faster refleje lo que<\/a> est\u00e1 en Git, no lo que<\/a> alguien corri\u00f3 desde su terminal. Pero hay diferencias que importan dependiendo de tu contexto.<\/p>\n

Flux es m\u00e1s “nativo de Kubernetes<\/a>” en el<\/a> sentido de que todo son CRDs y controladores peque\u00f1os. Si te gusta componer piezas, Flux tiene esa filosof\u00eda. ArgoCD viene con una UI bastante buena out of the box, un modelo de<\/a> Application m\u00e1s expl\u00edcito, y \u2014 honestamente \u2014 m\u00e1s documentaci\u00f3n de comunidad cuando algo falla a las<\/a> 2am.<\/p>\n

Para un equipo peque\u00f1o como el m\u00edo, la UI fue el factor decisivo. No porque sea indispensable, sino porque cuando alguien que no vive en la terminal necesita saber el estado de un despliegue, puede abrir un navegador en vez de pedirme que corra kubectl<\/code>. Eso vale mucho.<\/p>\n

(Hay una versi\u00f3n de este art\u00edculo donde termino eligiendo Flux. Depende mucho de si tu equipo ya tiene familiaridad con el modelo operacional de cada herramienta.)<\/p>\n

Instalaci\u00f3n: la parte que los tutoriales resumen en dos l\u00edneas<\/h2>\n

La mayor\u00eda de gu\u00edas hacen esto:<\/p>\n

kubectl create namespace argocd\nkubectl apply -n argocd -f https:\/\/raw.githubusercontent.com\/argoproj\/argo-cd\/stable\/manifests\/install.yaml\n<\/code><\/pre>\n
Y s\u00ed, funciona. Pero hay problemas espec\u00edficos que me encontr\u00e9 en mi setup (EKS en AWS<\/a>, con un ALB Controller ya instalado) que me hubiera gustado saber antes.<\/p>\n
Primero: si est\u00e1s en un cl\u00faster con restricciones de red, el pod argocd-server<\/code> va a tener problemas para hacer git clone<\/code> desde dentro del cl\u00faster. Esto me tom\u00f3 dos horas diagnosticar porque los logs no son particularmente descriptivos al respecto. Termin\u00e9 configurando un egress rule expl\u00edcito en los security groups.<\/p>\n
Segundo: la versi\u00f3n stable<\/code> del manifiesto no siempre apunta a lo que<\/a> uno espera. Yo instal\u00e9 ArgoCD 2.9.3 creyendo instalar algo m\u00e1s reciente. Verifica siempre:<\/p>\n
kubectl get pods -n argocd -o jsonpath='{range .items[*]}{.spec.containers[0].image}{"\\n"}{end}'\n<\/code><\/pre>\n
Para producci\u00f3n<\/a>, yo recomendar\u00eda instalar con Helm. Tienes m\u00e1s control sobre los valores y el upgrade path es m\u00e1s limpio:<\/p>\n
helm repo add argo https:\/\/argoproj.github.io\/argo-helm\nhelm repo update\n\nhelm install argocd argo\/argo-cd \\\n  --namespace argocd \\\n  --create-namespace \\\n  --version 6.7.3 \\\n  --set server.service.type=ClusterIP \\\n  --set configs.params."server\\.insecure"=true\n<\/code><\/pre>\n
El flag server.insecure=true<\/code> lo us\u00e9 porque ten\u00eda terminaci\u00f3n TLS en el<\/a> ALB, no en ArgoCD directamente. Si tu setup es diferente, probablemente no lo necesitas.<\/p>\n
Para acceder al servidor inicialmente:<\/p>\n
# Obt\u00e9n la contrase\u00f1a inicial del admin\nkubectl get secret argocd-initial-admin-secret \\\n  -n argocd \\\n  -o jsonpath="{.data.password}" | base64 -d\n\n# Port-forward para acceder localmente\nkubectl port-forward svc\/argocd-server -n argocd 8080:443\n<\/code><\/pre>\n
Una cosa que me sorprendi\u00f3: la contrase\u00f1a inicial est\u00e1 en un Secret llamado argocd-initial-admin-secret<\/code>, que ArgoCD borra autom\u00e1ticamente<\/strong> despu\u00e9s de<\/a> que la cambias por primera vez. Bien pensado, pero me agarr\u00f3 desprevenido cuando fui a buscarla semanas despu\u00e9s y no estaba.<\/p>\n
Conectando tu repositorio y creando tu primera Application<\/h2>\n
Aqu\u00ed es donde GitOps empieza a tomar forma real. La idea: tienes un repositorio con tus manifiestos de Kubernetes<\/a> en DigitalOcean<\/a>” rel=”nofollow sponsored” target=”_blank”>Kubernetes<\/a> (o charts de Helm, o Kustomize), y ArgoCD observa ese repositorio y sincroniza el estado del cl\u00faster con \u00e9l.<\/p>\n
Primero, registra tu repositorio. Si es privado \u2014 que probablemente lo es \u2014 necesitas credenciales:<\/p>\n
# Con SSH (mi preferencia)\nargocd repo add git@github.com:tu-org\/tu-repo-k8s.git \\\n  --ssh-private-key-path ~\/.ssh\/id_rsa\n\n# O con HTTPS y un token de GitHub<\/a>\nargocd repo add https:\/\/github.com\/tu-org\/tu-repo-k8s.git \\\n  --username tu-usuario \\\n  --password ghp_tu_token_aqui\n<\/code><\/pre>\n
Luego, creas tu primera Application. Puedes hacerlo desde la UI o con un manifiesto YAML \u2014 yo prefiero YAML porque vive en Git (GitOps hasta el final):<\/p>\n
# argocd\/apps\/mi-servicio.yaml\napiVersion: argoproj.io\/v1alpha1\nkind: Application\nmetadata:\n  name: mi-servicio\n  namespace: argocd\n  finalizers:\n    # Borra los recursos del cl\u00faster al eliminar esta Application\n    - resources-finalizer.argocd.argoproj.io\nspec:\n  project: default\n  source:\n    repoURL: https:\/\/github.com\/tu-org\/tu-repo-k8s.git\n    targetRevision: main\n    path: manifests\/mi-servicio\n  destination:\n    server: https:\/\/kubernetes.default.svc\n    namespace: mi-servicio\n  syncPolicy:\n    automated:\n      prune: true      # Borra recursos que ya no est\u00e1n en Git\n      selfHeal: true   # Revierte cambios manuales en el<\/a> cl\u00faster\n    syncOptions:\n      - CreateNamespace=true\n<\/code><\/pre>\n
El campo selfHeal: true<\/code> es el que hace que GitOps sea GitOps de verdad<\/a>. Si alguien (yo, a las<\/a> 11pm, “solo para probar algo r\u00e1pido”) hace un kubectl edit<\/code> directamente en el<\/a> cl\u00faster, ArgoCD lo detecta y lo revierte. Al principio esto molesta. Despu\u00e9s lo agradeces.<\/p>\n
prune: true<\/code> tambi\u00e9n merece atenci\u00f3n. Con esta opci\u00f3n, si eliminas un manifiesto del repositorio, ArgoCD elimina el recurso correspondiente del cl\u00faster. Sin ella, los recursos hu\u00e9rfanos se acumulan silenciosamente. Lo aprend\u00ed por las malas<\/a> \u2014 ten\u00eda Services de versiones anteriores flotando por ah\u00ed sin hacer nada \u00fatil.<\/p>\n
El error que me cost\u00f3 tres horas un martes por la noche<\/h2>\n
Aqu\u00ed va la parte que me da un poco de verg\u00fcenza documentar, pero que probablemente le ahorrar\u00e1 tiempo a alguien.<\/p>\n
Configur\u00e9 ArgoCD con sync autom\u00e1tico habilitado y prune: true<\/code>. Funcion\u00f3 perfectamente durante semanas. Luego, durante una refactorizaci\u00f3n, mov\u00ed varios manifiestos de directorio \u2014 b\u00e1sicamente reorganic\u00e9 la estructura de carpetas del repositorio.<\/p>\n
ArgoCD detect\u00f3 que los recursos en las rutas antiguas ya no exist\u00edan en Git. Con prune: true<\/code>, los borr\u00f3. Los recursos en las rutas nuevas todav\u00eda no hab\u00edan sido sincronizados. Por cuatro minutos, varios Deployments estuvieron en cero r\u00e9plicas.<\/p>\n
El problema no fue ArgoCD \u2014 el comportamiento es exactamente el documentado. El problema fue que yo no hab\u00eda pensado en el<\/a> orden de operaciones de una migraci\u00f3n de estructura de directorios.<\/p>\n
Lo que deber\u00eda haber hecho:
\n1. Deshabilitar el sync autom\u00e1tico antes del PR
\n2. Hacer el merge de la reorganizaci\u00f3n
\n3. Sincronizar manualmente y verificar que todo est\u00e9 correcto
\n4. Volver a habilitar el sync autom\u00e1tico<\/p>\n
Right, so \u2014 si vas a hacer cambios estructurales en tu repositorio de manifiestos, trata ese PR como si fuera una migraci\u00f3n de base de datos<\/a>. Con cuidado, con un plan de rollback, y de preferencia no un martes por la noche.<\/p>\n
Desde entonces uso syncWindows<\/code> para limitar cu\u00e1ndo ArgoCD puede sincronizar autom\u00e1ticamente en producci\u00f3n<\/a>:<\/p>\n
# Configurado en el<\/a> Project de ArgoCD, no en la Application\nspec:\n  syncWindows:\n    - kind: allow\n      schedule: '0 9-17 * * 1-5'  # Solo horario laboral, lunes a viernes\n      duration: 8h\n      applications:\n        - 'produccion-*'\n      namespaces:\n        - produccion\n<\/code><\/pre>\n
Esto no es para todo el mundo. Si despliegas con mucha frecuencia fuera de horario, va a ser un obst\u00e1culo. Pero para nuestro equipo, eliminar los syncs sorpresa a las<\/a> 3am vali\u00f3 la configuraci\u00f3n extra.<\/p>\n
Multi-cl\u00faster y lo que<\/a> los docs no enfatizan suficiente<\/h2>\n
Tenemos tres cl\u00fasteres: desarrollo, staging y producci\u00f3n<\/a>. ArgoCD corre en uno solo \u2014 producci\u00f3n<\/a>, con acceso muy restringido \u2014 y gestiona los tres. Para registrar un cl\u00faster externo:<\/p>\n
# Aseg\u00farate de tener el contexto correcto en<\/a> tu kubeconfig\nkubectl config get-contexts\n\n# Registra el cl\u00faster de staging\nargocd cluster add arn:aws<\/a>:eks:us-east-1:123456789:cluster\/staging \\\n  --name staging\n<\/code><\/pre>\n
Lo que los docs no enfatizan suficientemente: el ServiceAccount que ArgoCD crea en el<\/a> cl\u00faster remoto tiene permisos de cluster-admin<\/code> por defecto. Para empezar est\u00e1 bien, pero en producci\u00f3n<\/a> querr\u00e1s ajustar eso. Yo no lo hice hasta que<\/a> alguien de seguridad me pregunt\u00f3 expl\u00edcitamente \u2014 mejor enterarse antes de que te lo pregunten.<\/p>\n
Una cosa que todav\u00eda no tengo completamente resuelta: la gesti\u00f3n de secrets entre entornos. Usamos AWS Secrets Manager con el External Secrets Operator, pero la integraci\u00f3n con ArgoCD a veces produce sync states confusos cuando el external secret tarda en popularse. No es exactamente un bug \u2014 es m\u00e1s una cuesti\u00f3n de timing y de c\u00f3mo ArgoCD eval\u00faa el health de los recursos. No estoy 100% seguro de que nuestra soluci\u00f3n actual escale bien m\u00e1s all\u00e1 de los 12 servicios que tenemos ahora. Si alguien tiene una soluci\u00f3n elegante para esto, genuinamente me interesa saberlo.<\/p>\n
Lo que recomendar\u00eda hoy<\/h2>\n
Despu\u00e9s de usar esto en producci\u00f3n<\/a> por m\u00e1s de un a\u00f1o con un equipo de 4 personas y unos 12 servicios, esto es lo que<\/a> dir\u00eda:<\/p>\n
Empieza sin sync autom\u00e1tico. Dos semanas<\/a> manejando sincronizaci\u00f3n manual te ense\u00f1an m\u00e1s que cualquier tutorial \u2014 entiendes qu\u00e9 hace prune<\/code>, c\u00f3mo leer el diff que ArgoCD muestra antes de aplicar, y por qu\u00e9<\/a> el selfHeal<\/code> eventualmente te va a salvar de algo. Habilita el sync autom\u00e1tico solo cuando conf\u00edes en tus manifiestos y en tu proceso de revisi\u00f3n de PRs. No antes.<\/p>\n
Usa ApplicationSets si tienes m\u00e1s de tres o cuatro Applications con estructura similar. Te ahorras repetici\u00f3n y los cambios de configuraci\u00f3n global son mucho m\u00e1s manejables. Tard\u00e9 demasiado en adoptar esto.<\/p>\n
Invierte tiempo en el<\/a> control de acceso desde el principio \u2014 no despu\u00e9s. ArgoCD tiene RBAC basado en proyectos con pol\u00edticas de Casbin: flexible, pero bastante m\u00e1s dif\u00edcil de retrofitear cuando ya tienes diez personas tocando el sistema y no quieres romper nada mientras ajustas permisos.<\/p>\n
Y sobre el debate ArgoCD vs Flux: si tu equipo usa la UI para operaciones del d\u00eda a d\u00eda, ArgoCD. Si todo el mundo vive en la terminal y prefiere componer controladores peque\u00f1os, Flux. No hay una respuesta universal, pero s\u00ed hay una respuesta correcta para tu contexto espec\u00edfico.<\/p>\n
Para mi equipo, ArgoCD fue la decisi\u00f3n correcta. El viernes siguiente al incidente del servicio de pagos, hicimos un despliegue que tard\u00f3 exactamente lo que<\/a> tard\u00f3 el merge del PR. Nadie corri\u00f3 comandos locales. Nadie tuvo que confiar en que alguien hab\u00eda hecho checkout del branch correcto. El historial de despliegues estaba en Git, con el nombre del autor y el mensaje del commit.<\/p>\n
Eso, m\u00e1s que cualquier feature espec\u00edfica, es lo que<\/a> hace que GitOps valga la pena<\/a> el esfuerzo inicial.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Un viernes por la tarde, hace unos 14 meses, desplegu\u00e9 la versi\u00f3n incorrecta de nuestro servicio de pagos en producci\u00f3n .<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-119","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=119"}],"version-history":[{"count":27,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/119\/revisions"}],"predecessor-version":[{"id":660,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/119\/revisions\/660"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}