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
30 días de Claude para negocios freelance: 5 indicaciones que funcionan
Un freelancer probó Claude a diario durante 30 días y comparte 5 prompts que redujeron la redacción de propuestas de 45 a 5 minutos, aumentaron las tarifas un 30% sin resistencia, y triplicaron las tasas de respuesta en presentaciones en frío.
Reduzca los costos de token en un 95% con las siete técnicas de optimización de OpenClaw
Una guía completa que detalla siete técnicas para reducir el consumo de tokens de agentes de IA en más del 95%, incluyendo archivos de arranque en estructura de árbol, autocompresión de IA, descarga de modelos locales y tareas de CPU basadas en cron.
Actualización de OpenClaw v2.0: Lista de Verificación Crítica Previo a la Actualización para Evitar Cambios Disruptivos
La última actualización de OpenClaw introduce 12 cambios importantes, un nuevo sistema de complementos y más de 30 parches de seguridad. Esta guía describe cinco verificaciones esenciales que realizar antes de actualizar, incluyendo el cambio de nombre de variables de entorno, la migración del directorio de estado y la reconfiguración de la automatización del navegador.
Automatización de actualizaciones de OpenClaw con un agente de IA: Un manual probado en el campo
Un desarrollador comparte cómo entrenó a un agente de IA Hermes para manejar las actualizaciones de OpenClaw, reduciendo una migración de varias horas y llena de tensión a 'ejecutar el manual, encontrarse con dos problemas conocidos'.