kubectl get events ordenados por tiempo

kubectl get events --sort-by='.lastTimestamp' pone el evento más reciente del clúster al final, en vez de mostrarlos en el orden que sea que devuelva la API. Los eventos son el primer lugar donde mirar, antes que los logs — los logs dicen qué hizo tu aplicación, los eventos dicen qué le hizo el clúster. La mitad de los fallos que importan (sin espacio en disco, una imagen que no se descarga, recursos insuficientes, un volumen que nunca se montó) no aparecen en ningún log.

1. ¿Cómo ordenar los eventos de kubectl por tiempo?

$ clai muestra los eventos del clúster, los más recientes al final→ kubectl get events --sort-by='.lastTimestamp'

Sin ordenar, los eventos salen en el orden que sea que los guarde la API, lo que los hace inútiles de revisar. La clave de orden empieza con un punto porque es una ruta JSONPath dentro del objeto del evento.

2. ¿Cómo ver solo las advertencias de un namespace?

$ clai muestra las advertencias en el namespace production de un rato para acá→ kubectl get events -n production --field-selector type=Warning --sort-by='.lastTimestamp'

Los eventos tienen dos tipos, Normal y Warning. Normal solo añade ruido cuando estás analizando un incidente. --field-selector filtra del lado del servidor, así que sigue siendo rápido incluso en un clúster grande.

3. ¿Cómo ver los eventos de un pod concreto?

$ clai muestra qué le pasó a este pod→ kubectl describe pod my-app-7d9f8 -n production

describe imprime los eventos al final de su salida, ya asociados al objeto — normalmente más rápido que filtrar la lista completa. Ahí es donde vas a ver razones como FailedScheduling, ImagePullBackOff u OOMKilled.

4. ¿Cómo ver los logs de un contenedor caído?

$ clai muestra los logs de la ejecución anterior de este contenedor→ kubectl logs my-app-7d9f8 -n production --previous

Cuando un contenedor se reinicia, sus logs se reemplazan por los de la nueva instancia. --previous trae los logs de la instancia anterior — los que en realidad registraron por qué murió. Sin ese flag estás mirando un proceso recién arrancado que todavía no tiene nada que decir.

5. ¿Cómo seguir los eventos en tiempo real?

$ clai sigue los eventos de este namespace ahora mismo→ kubectl get events -n production --watch

Útil durante un despliegue: ves al scheduler colocar los pods, las imágenes descargarse y los checks de readiness pasar en tiempo real. Ctrl+C para parar.

6. ¿Por qué un pod no arranca?

$ clai muestra los pods que no están en Running, y sus eventos→ kubectl get pods -n production --field-selector status.phase!=Running

Primero acota a los pods problemáticos, luego revisa cada uno con describe. Pending casi siempre significa que el scheduler no tiene dónde poner el pod — recursos insuficientes, restricciones de ubicación que no encajan, o un volumen que no encontró.

Trampas

• Los eventos duran una hora, más o menos. --event-ttl es de 1 hora por defecto, y después el evento desaparece. Ya no queda nada con qué reconstruir el incidente de ayer a partir de eventos — necesitas un recolector externo.
• --sort-by necesita una ruta JSONPath con punto al inicio. --sort-by='.lastTimestamp', no lastTimestamp. Sin el punto, el comando devuelve una lista sin ordenar sin avisar.
• Los eventos están ligados a un namespace. Sin -n estás mirando el namespace por defecto y no ves nada de production. Para la vista completa usa --all-namespaces.

Preguntas relacionadas

¿Logs o eventos, por dónde empezar? Por los eventos. Dicen si la aplicación siquiera llegó a arrancar. Los logs solo importan una vez que el contenedor ya está corriendo.

¿Por qué kubectl logs sale vacío? O el contenedor nunca arrancó, o no escribe en stdout, o ya se reinició. Los eventos responden los dos primeros casos; el flag --previous responde el tercero.

¿En qué se diferencia kubectl events de kubectl get events? El comando independiente kubectl events llegó después y ordena por tiempo por defecto. get events funciona en todas partes, incluidos clústeres viejos.

Ver también

• Docker y Kubernetes: la memoria muscular, sustituida
• Docker se comió tu disco: cómo recuperar espacio
• Lee los logs de un servicio con journalctl

CliAI convierte una pregunta en español sobre un pod en el comando kubectl correcto, sin que tengas que memorizar selectores de campo ni la sintaxis de JSONPath. Instálalo en una línea.