← Volver al listado de tecnologías ← Índice de K3s

Capitulo 15: Logs y Debugging

Por: Artiko
k3skubernetesdebugginglogskubectl

Capitulo 15: Logs y Debugging

< Volver al Indice del Tutorial

kubectl logs

El comando kubectl logs muestra la salida estandar (stdout/stderr) de los contenedores.

Uso basico

# Logs de un pod
kubectl logs mi-pod

# Logs en tiempo real (follow)
kubectl logs -f mi-pod

# Ultimas 50 lineas
kubectl logs --tail=50 mi-pod

# Logs de la ultima hora
kubectl logs --since=1h mi-pod

Contenedor anterior

Si un pod se reinicio, puedes ver los logs del contenedor que fallo:

kubectl logs mi-pod --previous

Contenedor especifico

Cuando un pod tiene multiples contenedores, especifica cual:

# Listar contenedores del pod
kubectl get pod mi-pod -o jsonpath='{.spec.containers[*].name}'

# Logs de un contenedor especifico
kubectl logs mi-pod -c mi-sidecar

Logs por label

# Logs de todos los pods con un label
kubectl logs -l app=mi-app --all-containers=true

kubectl describe

Muestra informacion detallada de cualquier recurso. La seccion Events al final es clave para diagnosticar problemas.

# Describir un pod
kubectl describe pod mi-pod

# Describir un nodo
kubectl describe node mi-nodo

# Describir un servicio
kubectl describe svc mi-servicio

# Describir un PVC
kubectl describe pvc mi-volumen

La salida de describe incluye:

Los Events se limpian despues de 1 hora por defecto. Si necesitas ver eventos mas antiguos, revisa los logs del componente correspondiente.

kubectl exec

Ejecuta comandos dentro de un contenedor en ejecucion.

# Ejecutar un comando
kubectl exec mi-pod -- ls /app

# Shell interactivo
kubectl exec -it mi-pod -- /bin/sh

# En un contenedor especifico
kubectl exec -it mi-pod -c mi-contenedor -- /bin/bash

Casos de uso comunes:

# Verificar conectividad de red
kubectl exec -it mi-pod -- ping otro-servicio

# Ver variables de entorno
kubectl exec mi-pod -- env

# Revisar archivos de configuracion
kubectl exec mi-pod -- cat /etc/app/config.yaml

# Probar conectividad a base de datos
kubectl exec -it mi-pod -- nc -zv db-service 5432

kubectl port-forward

Accede a servicios del cluster desde tu maquina local sin exponerlos:

# Forward a un pod
kubectl port-forward mi-pod 8080:80

# Forward a un servicio
kubectl port-forward svc/mi-servicio 8080:80

# Forward a un deployment
kubectl port-forward deployment/mi-app 8080:80

# Escuchar en todas las interfaces (no solo localhost)
kubectl port-forward --address 0.0.0.0 svc/mi-servicio 8080:80

Es util para acceder a dashboards internos, bases de datos o APIs sin crear un Ingress.

kubectl events

Ver los eventos del cluster ordenados cronologicamente:

# Eventos del namespace actual
kubectl get events --sort-by='.lastTimestamp'

# Eventos de un namespace especifico
kubectl get events -n kube-system --sort-by='.lastTimestamp'

# Solo warnings
kubectl get events --field-selector type=Warning

# Eventos de un pod especifico
kubectl get events --field-selector involvedObject.name=mi-pod

Diagnosticar Problemas Comunes

CrashLoopBackOff

El pod arranca, falla y Kubernetes lo reinicia en bucle con backoff exponencial.

Diagnostico:

# Ver logs del contenedor que fallo
kubectl logs mi-pod --previous

# Ver detalles del pod
kubectl describe pod mi-pod

Causas frecuentes:

ImagePullBackOff

Kubernetes no puede descargar la imagen del contenedor.

Diagnostico:

kubectl describe pod mi-pod | grep -A5 "Events"

Causas frecuentes:

Solucion para registros privados:

# Crear secret con credenciales
kubectl create secret docker-registry mi-registro \
  --docker-server=registry.ejemplo.com \
  --docker-username=usuario \
  --docker-password=password

Referencialo en el pod con imagePullSecrets.

Pending

El pod queda en estado Pending y nunca se programa en un nodo.

Diagnostico:

kubectl describe pod mi-pod
# Buscar en Events mensajes como "FailedScheduling"

Causas frecuentes:

Verificar recursos disponibles:

kubectl describe nodes | grep -A5 "Allocated resources"

OOMKilled

El kernel de Linux mata el contenedor porque excedio su limite de memoria.

Diagnostico:

kubectl describe pod mi-pod | grep -i oom
# El estado mostrara "OOMKilled" como razon de terminacion

Solucion:

# Incrementar el limite de memoria en el manifiesto
resources:
  limits:
    memory: 512Mi   # Aumentar segun necesidad
  requests:
    memory: 256Mi

Antes de subir el limite, verifica que la aplicacion no tenga un memory leak revisando su consumo historico en Grafana.

kubectl debug

Crea un contenedor efimero de debugging adjunto a un pod existente. Util cuando el pod no tiene herramientas de diagnostico instaladas.

# Crear contenedor de debug en un pod existente
kubectl debug -it mi-pod --image=busybox --target=mi-contenedor

# Crear una copia del pod con imagen de debug
kubectl debug mi-pod -it --copy-to=mi-pod-debug \
  --image=ubuntu -- bash

# Debug de un nodo
kubectl debug node/mi-nodo -it --image=ubuntu

El contenedor efimero comparte el namespace de red y proceso del pod original, permitiendo inspeccionar la red, sistema de archivos y procesos.

Flujo de Diagnostico Recomendado

Cuando algo falla, sigue este orden:

  1. kubectl get pods - identificar el estado del pod
  2. kubectl describe pod <nombre> - leer los Events
  3. kubectl logs <nombre> - revisar la salida de la aplicacion
  4. kubectl logs <nombre> --previous - si el pod se reinicio
  5. kubectl exec -it <nombre> -- sh - investigar dentro del contenedor
  6. kubectl get events --sort-by='.lastTimestamp' - contexto general del cluster

Resumen

Las herramientas de debugging de kubectl son tu primera linea de defensa para diagnosticar problemas. logs para ver la salida de la aplicacion, describe para el estado del recurso y sus eventos, exec para investigar dentro del contenedor y port-forward para acceder a servicios internos. Conocer los patrones de error comunes te permite resolver la mayoria de los problemas rapidamente.

Siguiente: Capitulo 16: Cluster Multi-Nodo —>

← Volver al listado de tecnologías ← Índice de K3s