Kubernetes OOMKilled: Diagnóstico Avanzado de Fugas de Memoria en Go - Dev.

No hay nada más frustrante para un ingeniero de backend que ver un Pod reiniciarse constantemente con el infame Exit Code 137. El uso de memoria crece como una "diente de sierra" hasta que el OOM Killer de Linux interviene y mata el proceso. Si estás gestionando microservicios en Go dentro de Kubernetes, este comportamiento no siempre indica una fuga de memoria clásica; a menudo es una mala configuración entre el Garbage Collector (GC) de Go y los límites del contenedor.

Análisis del Problema: RSS vs. Heap

En un incidente reciente con un servicio de procesamiento de pagos que manejaba 15k TPS, observamos que aunque el Heap de Go reportaba 500MB de uso, el contenedor consumía 1.2GB de RAM, provocando el OOMKilled. Esto sucede porque Go no libera memoria al sistema operativo inmediatamente (madvise) para reutilizarla rápidamente.

Es vital diferenciar entre una "Fuga de Memoria" (referencias perdidas que nunca se limpian) y una "Retención de Memoria" (el Runtime de Go guardando memoria para el futuro). El primer paso para el diagnóstico es confirmar el error en Kubernetes.

Síntoma Crítico: Ejecuta kubectl describe pod [nombre-pod] y busca el estado "LastState".

State:          Waiting
Reason:         CrashLoopBackOff
LastState:      Terminated
Reason:         OOMKilled
Exit Code:      137

Implementación de pprof para Profiling en Vivo

Para encontrar la raíz del problema, necesitamos "mirar dentro" del proceso en ejecución. La herramienta estándar es pprof. A continuación, mostramos cómo inyectar el servidor de profiling de manera segura en producción, exponiéndolo en un puerto dedicado para evitar exponer datos sensibles públicamente.

// main.go
package main

import (
    "log"
    "net/http"
    _ "net/http/pprof" // IMPORTANTE: Efecto secundario para registrar rutas
    "os"
)

func main() {
    // Iniciar servidor de pprof en un puerto separado (ej. 6060)
    // Solo accesible internamente o vía port-forward
    go func() {
        log.Println("Iniciando pprof en :6060")
        if err := http.ListenAndServe("0.0.0.0:6060", nil); err != nil {
            log.Printf("Error al iniciar pprof: %v", err)
        }
    }()

    // ... lógica principal de la aplicación ...
    startApp()
}

Extracción y Análisis del Heap Dump

Una vez desplegado el código con pprof, utiliza port-forward de Kubernetes para conectar tu máquina local al pod afectado. No esperes a que el pod muera; captura los datos cuando la memoria esté cerca del 80% del límite.

Comando de Diagnóstico:
1. Port-forward: kubectl port-forward pod-name 6060:6060
2. Captura: go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap

Al abrir la interfaz web, enfócate en la vista "Alloc Space" (memoria total asignada históricamente) y "Inuse Space" (memoria actualmente en uso). Si "Inuse Space" crece indefinidamente sin bajar después de un ciclo de GC, tienes un leak.

El culpable común: Goroutine Leaks

A menudo, el problema no está en grandes estructuras de datos, sino en miles de Goroutines bloqueadas esperando canales o I/O que nunca completan. Cada Goroutine consume un stack inicial (aprox 2KB) que puede crecer.

// Patrón de Fuga de Goroutine Común
func processRequest(ch <-chan int) {
    // Si 'ch' nunca recibe datos o se cierra, esta goroutine vive para siempre
    val := <-ch 
    fmt.Println(val)
}

La Solución Definitiva: GOMEMLIMIT (Go 1.19+)

Antes de Go 1.19, era difícil decirle al Runtime que era consciente del contenedor. Ahora, configurar GOMEMLIMIT es obligatorio en Kubernetes. Esto instruye al GC a ser más agresivo cuando se acerca al límite, previniendo el OOMKilled.

Configura la variable de entorno en tu manifiesto de Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-service
spec:
  template:
    spec:
      containers:
      - name: app
        resources:
          limits:
            memory: "1Gi"
          requests:
            memory: "512Mi"
        env:
        # Recomendación: Establecer al 90% del límite del contenedor
        - name: GOMEMLIMIT
          value: "900MiB"

Métrica	Sin GOMEMLIMIT	Con GOMEMLIMIT + Fix
Estabilidad del Pod	Reinicio cada 4 horas	Uptime > 30 días
Pico de Memoria (RSS)	1.1 GB (OOM)	850 MB (Estable)
Uso de CPU (GC)	Bajo (GC perezoso)	Moderado (GC proactivo)

Resultado: Al establecer un límite suave (soft limit) vía GOMEMLIMIT, forzamos al Runtime a priorizar la recolección de basura antes de solicitar más memoria al OS, eliminando el error OOMKilled en un 99% de los casos de "falsas fugas".

Conclusión

Solucionar errores OOMKilled en Go sobre Kubernetes requiere una combinación de instrumentación de código (pprof) y configuración de entorno consciente (GOMEMLIMIT). No te limites a aumentar la RAM ciegamente; analiza el perfil de heap y asegúrate de que tus goroutines tengan ciclos de vida finitos. La estabilidad de tu clúster depende de ello.