Skip to content
NeuralSkills
Despliegue

Solucionador de Kubernetes

Depura pods, servicios y problemas de red en Kubernetes — desde CrashLoopBackOff hasta timeouts de conexion misteriosos.

Avanzado Gratis Publicado: 15 de abril de 2026
Herramientas Compatibles claude-codechatgptgeminicopilotcursorwindsurfuniversal

El Problema

Kubernetes es poderoso pero opaco. Cuando un pod esta atrapado en CrashLoopBackOff, un servicio devuelve 502, o la comunicacion entre pods falla silenciosamente, la superficie de depuracion es enorme. Necesitas revisar logs de pods, eventos, limites de recursos, readiness probes, politicas de red, selectores de servicio, reglas de ingress y resolucion DNS — frecuentemente todo a la vez. La mayoria de los desarrolladores pierden horas saltando entre comandos kubectl sin un enfoque sistematico.

El Prompt

Eres un especialista en depuracion de Kubernetes. Ayudame a diagnosticar y corregir este problema de K8s.

SINTOMAS:
[Describe que esta sucediendo — ej., "El pod se reinicia cada 30 segundos", "El servicio devuelve 502", "No puedo conectar entre servicios"]

INFO DEL CLUSTER:
- Version de K8s: [ej., 1.29]
- Plataforma: [ej., EKS, GKE, AKS, minikube, k3s]
- Namespace: [ej., production, default]

SALIDA RELEVANTE (pega lo que tengas):
- kubectl describe pod [nombre]: [pega la salida]
- kubectl logs [nombre]: [pega la salida]
- kubectl get events: [pega la salida]

Realiza un diagnostico sistematico:
1. **Clasificacion de sintomas**: Categoriza el problema (scheduling, runtime, red, recursos, configuracion).
2. **Comandos de diagnostico**: Lista los comandos kubectl exactos que debo ejecutar, en orden de prioridad.
3. **Analisis de causa raiz**: Basado en los sintomas, identifica las 3 causas raiz mas probables.
4. **Solucion para cada causa**: Proporciona el patch YAML exacto o comando kubectl para resolver cada causa potencial.
5. **Verificacion**: Como confirmar que la solucion funciono.
6. **Prevencion**: Que agregar a los manifiestos para prevenir esta clase de problema.

Ejemplo de Salida

Sintoma: CrashLoopBackOff — clasificado como problema de RUNTIME
Diagnostico: kubectl logs pod/api-7d8f --previous (revisar salida del ultimo crash)
Causa raiz #1 (70%): OOMKilled — limite de memoria del contenedor 256Mi muy bajo para heap de Node.js
  Solucion: kubectl patch deploy api -p '{"spec":{"template":{"spec":{"containers":[{"name":"api","resources":{"limits":{"memory":"512Mi"}}}]}}}}'
Causa raiz #2 (20%): Variable de entorno faltante causando crash en el arranque
  Solucion: kubectl set env deploy/api DATABASE_URL=postgresql://...
Verificacion: kubectl rollout status deploy/api && kubectl get pods -w

Cuando Usarlo

Usa este skill cuando cualquier recurso de Kubernetes no se comporte como se espera — pods que no arrancan, servicios que no rutean, volumenes persistentes que no montan, o autoescalado que no se activa. Esencial durante incidentes en produccion cuando necesitas un enfoque estructurado en lugar de comandos kubectl aleatorios.

Consejos Pro

  • Siempre revisa eventos primero — kubectl get events --sort-by=.lastTimestamp -n <namespace> te da la linea de tiempo de lo que Kubernetes intento hacer y donde fallo.
  • Usa el flag --previous para pods crasheados — kubectl logs <pod> --previous muestra los logs de la ultima instancia del contenedor antes del crash, que es donde vive el error real.
  • Depuracion de red con contenedores efimeros — kubectl debug -it <pod> --image=nicolaka/netshoot adjunta un contenedor de depuracion con curl, dig, nslookup y tcpdump sin modificar el spec del pod.
  • Describe es mas util que get — kubectl describe pod muestra eventos, condiciones y detalles de recursos que kubectl get pod -o yaml entierra en ruido.