Título del artículo: Caza de errores: Bloqueos de WireGuard y desajuste de MTU en GKE
El equipo de infraestructura de Lovable depuró un problema de red que afectaba a todo un clúster en Google Kubernetes Engine (GKE), causando fallos de conexión intermitentes. Usando un agente de IA para escanear los registros de Clickhouse, descubrieron que los pods anetd (la implementación de Cilium de Google) se caían ~120 veces por pod en seis días, casi una vez por hora. Los volcados de fallo revelaron un pánico de acceso concurrente a un mapa en el código de integración de WireGuard de Google, no en WireGuard mismo.
Primera solución: Deshabilitar el cifrado transparente
El soporte de Google recomendó deshabilitar el cifrado de nodo a nodo para evitar el error de WireGuard. El equipo aplicó el cambio y reinició todos los pods anetd. Las caídas cesaron durante unas cuatro horas, pero luego los usuarios comenzaron a ver fallos de conexión aleatorios a Valkey (su almacén de datos en memoria).
Segundo error: Desajuste de MTU
El ingeniero Erik usó tcpdump y Wireshark para capturar paquetes. La prueba irrefutable: "Destination unreachable (Fragmentation needed)". Esta es la causa:
- Con WireGuard habilitado, la MTU del clúster se había configurado en 1420 bytes (considerando la sobrecarga de encapsulación de 80 bytes de WireGuard).
- Tras deshabilitar WireGuard, las configuraciones deberían haber revertido al estándar de 1500 bytes, pero algunos nodos no se reiniciaron y seguían usando la MTU antigua de 1420.
- Las conexiones a Valkey que cruzaban nodos con MTU diferentes fallaban de manera intermitente.
Resolución
La solución: reinicio progresivo de todos los nodos para garantizar una configuración de MTU consistente en todo el clúster. Esto eliminó los errores de fragmentación y restauró la estabilidad.
Conclusiones clave
- El primer error estaba en la integración de WireGuard por parte de Google en
anetd: un error de concurrencia en el acceso a un mapa. Es específico de la implementación de GKE. - Deshabilitar el cifrado evitó el pánico, pero introdujo un desajuste de MTU que requirió un despliegue completo de nodos.
- Los agentes de IA ayudaron a detectar rápidamente el patrón de caídas de anetd entre millones de líneas de registro.
📖 Read the full source: HN AI Agents
👀 Ver también
Deja de preguntar qué modelo de IA usar: enruta tareas a los niveles Haiku, Soneto y Opus
Utiliza al menos tres modelos por tipo de tarea: nivel Haiku para leer/resumir, nivel Sonnet para escribir código, y nivel Opus solo para refactorizaciones de múltiples archivos y depuración. La configuración de un usuario envía el 40% a modelos baratos, 35% a intermedios, 25% a avanzados, con un costo de ~$30-40 al mes.
Solucionando el Inflado de Indicaciones y los Bucles Lentos de Respuesta en OpenClaw
Usuarios que experimentan demoras prolongadas desde 2026.4.26 pueden recuperar rendimiento reduciendo la hinchazón del contexto: recortar archivos siempre inyectados, limitar habilidades visibles y evitar pegar grandes salidas de herramientas en el chat principal.
Cómo solucionar problemas de configuración de OpenClaw: problemas de respuesta de múltiples agentes y modelos.
¿Tienes problemas configurando OpenClaw? Descubre los problemas comunes con configuraciones de múltiples agentes y modelos que no responden, y aprende cómo resolverlos.
DeepSeek-V4-Flash W4A16+FP8 con autospeculación MTP: 85 tok/s en 2x RTX PRO 6000 Max-Q
DeepSeek-V4-Flash cuantizado a W4A16+FP8 alcanza 85.52 tok/s en contexto de 524k en 2× RTX PRO 6000 Max-Q usando un vLLM modificado con cabezal MTP adaptado, frente a 52.85 tok/s de referencia.