Guía: auditar tu GitOps en Kubernetes como hizo LinkedIn con Argo CD

Qué descubrió LinkedIn al llevar Argo CD al límite y cómo comprobar en tu propio clúster los dos síntomas que más duelen a escala, sin reescribir nada.

Ingeniería de software

LinkedIn ha contado que sustituyó Argo CD por un motor GitOps propio, según recoge InfoQ. Opera más de 250 clústeres, 4.000 servicios y más de 100.000 despliegues por semana. Los fallos de infraestructura de despliegue bajaron de 925 a 63 pese a multiplicar por 3,7 el volumen.

Tu entorno probablemente sea mucho menor, pero algunos de sus problemas aparecen antes de lo que se piensa. Esta guía no te pide migrar: propone dos comprobaciones que el propio artículo sugiere para equipos que ya usan Argo CD a escala, más unas cuantas preguntas de diagnóstico.

Lo que necesitas

Necesitas acceso de lectura al clúster con kubectl, permiso para consultar las métricas de sincronización de tu instalación de Argo CD y un par de objetos de larga vida (Deployments o recursos propios) con muchos años de ediciones. Conviene tener a mano la documentación de Argo CD. Hazlo primero en un clúster de pruebas o en modo solo lectura.

1. Elige uno o dos objetos de larga vida y cuenta cuántos gestores de campos distintos aparecen en su managedFields.
2. Anota si alguno supera los diez gestores distintos, el umbral a partir del cual Kubernetes trunca esa información.
3. Recoge el tiempo de sincronización de tus aplicaciones y el número total de pods del clúster durante varios días.
4. Comprueba si el tiempo de sincronización crece al hacerlo el número de pods, aunque las aplicaciones no cambien.
5. Revisa si tienes la poda (prune) desactivada y si eso deja recursos huérfanos en producción.

Primera comprobación: gestores de campos

LinkedIn descubrió que Kubernetes trunca managedFields cuando un objeto ha tenido más de diez gestores distintos. Entonces el servidor de API olvida quién es propietario de cada campo. En sus cargas de IA, con varios contenedores por pod, un contenedor eliminado del manifiesto podía sobrevivir en el pod vivo, sin ningún error visible.

kubectl get deployment mi-servicio -n mi-namespace \
  --show-managed-fields -o yaml | grep -c 'manager:'

El recuento es solo orientativo: un mismo gestor puede aparecer varias veces con operaciones distintas. Lo importante es detectar objetos con historial largo y comparar su estado real con el manifiesto que crees haber desplegado. Si la poda está desactivada, como en el caso de LinkedIn por exigir aprobación en producción, esta divergencia puede pasar inadvertida.

Un contenedor retirado del manifiesto puede seguir vivo si se pierde la propiedad de sus campos.

Segunda comprobación: latencia frente a número de pods

Argo CD mantiene una observación por cada tipo de recurso. En clústeres con poca diversidad de tipos, el ruido de etcd de una aplicación puede ralentizar las sincronizaciones de todas. LinkedIn midió menos de 3 minutos con 60.000 pods y más de 10 minutos con más de 80.000. Si tu tiempo de sincronización sube con el total de pods, sospecha de esta contención.

Para decidir qué hacer, compara con lo que hicieron otros: LinkedIn lanza un pod efímero por despliegue sin estado compartido, mientras que la plataforma Up de Uber asigna un controlador dedicado a cada despliegue. Flux fue descartado por compartir el mismo paradigma de controlador.

Truco Antes de plantearte construir nada, mide. Si ninguna de las dos comprobaciones muestra síntomas, ajustar tu instalación actual casi siempre costará menos que mantener un motor propio. Recuerda además que LinkedIn tardó de julio de 2025 a abril de 2026 en migrar, y que mantener más de 200 instancias de Argo CD convertía cada actualización en un proyecto de semanas.

Cómo interpretar los resultados

• Muchos gestores de campos y poda desactivada: riesgo de recursos huérfanos silenciosos; revisa manifiestos frente a estado real.
• Sincronización que crece con el número de pods: contención de observaciones; valora repartir en más instancias o clústeres.
• Ninguno de los dos síntomas: tu problema es otro; no copies la solución de LinkedIn.
• Recuerda que el motor de LinkedIn es interno y no se ha anunciado ninguna versión de código abierto.

Una cautela final: LinkedIn aclara que su mejora no se debe solo al motor nuevo, porque la clasificación de errores y la fiabilidad del orquestador también progresaron en ese periodo. Si quieres profundizar, QCon San Francisco reúne sesiones técnicas de operadores que enfrentan problemas similares.

Opinión · El contexto que falta

Mi lectura: el titular es la migración, pero lo útil es el diagnóstico. Desde fuera no se puede saber cuánto de la mejora de 925 a 63 fallos viene del motor nuevo, porque el propio artículo reconoce que la clasificación de errores y la fiabilidad del orquestador también avanzaron. Yo no tomaría esa cifra como argumento para construir nada. Con 250 clústeres y 4.000 servicios, los problemas de LinkedIn son de escala que casi nadie tiene, y su motor es interno. Lo transferible es medir antes de decidir: latencia frente a pods y objetos con historial largo cuestan una tarde y evitan migrar por moda.

Artículos relacionados de LaRebelión

Cloudflare compra Deno: guía para preparar tus proyectos WorkersLong Polling, SSE, WebSockets y Webhooks: cómo elegir el patrón en tiempo realGuía para evaluar tu dependencia de GitHub en la era de los agentes

• Ingeniería de software
• Guía: perfilar CPU y memoria en Workers de Cloudflare en producción
• tsrs de Cloudflare: guía para evaluar el port de TypeScript a Rust

Fuente original: infoq.com

Artículo generado mediante AI.larebelion

Kernel · Dirección de tecnología · España

«Antes de copiar a LinkedIn, mide tu latencia de sincronización: muchas veces el problema no es Argo CD, es otro.»