Saltar al contenido principal

Logs en Kubernetes

Los logs son una de las herramientas más importantes para entender el comportamiento de una aplicación. Esta información nos permite saber qué está pasando en el sistema y nos ayuda a depurar errores. En este apartado vamos a ver cómo consumir los logs de los contenedores que se ejecutan en Kubernetes y cómo integrarlos con otras herramientas de monitorización.

Logs de los pods - kubectl logs​

El comando del día a día. Podemos acceder a los logs de un pod usando kubectl logs:

kubectl -n <namespace> logs <pod> # El parámetro de namespace es opcional; si no se especifica, se usa el namespace actual

Algunas variantes que conviene dominar (caen seguro en los exámenes):

kubectl logs <pod> -f                  # Seguir los logs en tiempo real (como tail -f)
kubectl logs <pod> -c <contenedor>     # Pod con varios contenedores: elegir uno
kubectl logs <pod> --all-containers    # Todos los contenedores del pod
kubectl logs <pod> --previous          # Logs del contenedor anterior (clave en CrashLoopBackOff)
kubectl logs <pod> --since=1h          # Solo la última hora
kubectl logs -l app=web                # Logs de todos los pods con un label

Y cuando los logs no bastan, los eventos del cluster suelen tener la respuesta (por qué no arranca un pod, por qué no se programa, etc.):

kubectl get events --sort-by=.metadata.creationTimestamp
kubectl describe pod <pod>   # Incluye los eventos del pod al final

Localización de los ficheros de logs​

Para los clusters de Kubernetes basados en systemd podemos ver los logs del kubelet de cada nodo usando el comando journalctl:

journalctl -u kubelet | less

La mayoría de los componentes del control plane se ejecutan como contenedores. Para encontrar los ficheros de logs del kube-apiserver podemos usar el siguiente comando:

sudo find / -name "*apiserver*log"

Luego podemos usar el comando less para ver el contenido del fichero:

sudo less /var/log/containers/kube-apiserver-k8s-master-1_kube-system_kube-apiserver-1.log # Usa las rutas obtenidas en el comando anterior

Otras rutas donde podemos encontrar logs en función del tipo de nodo son:

/var/log/containers/ # Logs de los contenedores (enlaces simbólicos)
/var/log/pods/       # Logs de los pods
/var/log/kube-apiserver.log         # Api server (si no corre como pod)
/var/log/kube-scheduler.log         # Scheduler
/var/log/kube-controller-manager.log # Controller manager
/var/log/kubelet.log                # Kubelet
/var/log/kube-proxy.log             # Kube-proxy

Documentación oficial de Kubernetes:

Logging centralizado​

Los logs de un pod desaparecen con él, así que en producción es imprescindible agregarlos en un sistema centralizado. El patrón habitual es un agente desplegado como DaemonSet (como vimos en el capítulo de DaemonSets) que recolecta los logs de cada nodo y los envía a un backend:

  • Grafana Loki + Promtail/Alloy: ligero y muy popular en la comunidad.
  • Stack EFK: Elasticsearch + Fluentd/Fluent Bit + Kibana, el clásico para grandes volúmenes.

No entran en los exámenes más allá del concepto, pero en el mundo real son el estándar.

Añadiendo herramientas de monitorización y métricas​

Metrics Server - Métricas (kubectl top)​

Lo primero será instalar metrics-server en nuestro cluster, el componente que recolecta las métricas de uso de recursos:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Para entornos de prueba o desarrollo podemos permitir TLS inseguro, ya que el certificado del kubelet es autofirmado y no será válido. Para ello, editamos el deployment y añadimos la flag --kubelet-insecure-tls. NO RECOMENDADO PARA ENTORNOS DE PRODUCCIÓN.

kubectl -n kube-system edit deployment metrics-server

Añadimos la siguiente línea en la sección args del contenedor:

spec:
  containers:
  - args:
    - --cert-dir=/tmp
    - --secure-port=10250
    - --kubelet-insecure-tls # Añadimos esta línea
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --kubelet-use-node-status-port
    image: registry.k8s.io/metrics-server/metrics-server:v0.7.2

A partir de aquí, ya podríamos consultar las métricas de nuestros pods usando el comando kubectl top:

kubectl top pod --all-namespaces # Muestra las métricas de todos los pods
kubectl top pod -n <namespace> # Muestra las métricas de los pods de un namespace
kubectl top node # Muestra las métricas de los nodos

Dashboard web (Headlamp)​

Durante años la opción clásica fue el Kubernetes Dashboard oficial, pero el proyecto se archivó en enero de 2026 por falta de mantenedores (y su repositorio de Helm ya no está disponible). Su propio README recomienda usar Headlamp, que ahora vive bajo el SIG UI de Kubernetes (kubernetes-sigs/headlamp). Además de la aplicación de escritorio, Headlamp se puede desplegar dentro del cluster con Helm (si no tenemos instalado helm, recomendamos visitar su web para instalarlo):

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/ # Añadimos el repositorio a helm
helm install headlamp headlamp/headlamp --namespace kube-system

Para acceder, hacemos un port-forward al Service (mejor que al pod: el nombre del Service no cambia aunque el pod se recree):

kubectl -n kube-system port-forward svc/headlamp 8080:80

Y abrimos http://localhost:8080 en el navegador.

Si quisiéramos acceder desde otra máquina, podríamos usar el parámetro --address para indicar la dirección de escucha:

kubectl -n kube-system port-forward --address 0.0.0.0 svc/headlamp 8080:80 # Así cualquier usuario de la red podrá acceder, ojo si no es lo que queremos

Durante la instalación, el chart crea una cuenta de servicio headlamp y, por defecto, le asigna el rol cluster-admin (cómodo en un laboratorio, pero en producción conviene cambiarlo con el valor clusterRoleBinding.clusterRoleName del chart por un rol más limitado). Si hemos usado otro nombre de despliegue, podemos consultar el nombre de la cuenta con:

kubectl -n kube-system get serviceaccounts

Para autenticarnos, generamos un token de esa cuenta de servicio (recordemos del capítulo de usuarios que los tokens ahora son efímeros y se crean bajo demanda):

kubectl -n kube-system create token headlamp

Copiamos el token que devuelve el comando y lo pegamos en la pantalla de login de Headlamp.

Volver al índice