kubectl get events по времени: сортировка событий

kubectl get events --sort-by='.lastTimestamp' выводит самое свежее событие кластера последним, а не в произвольном порядке, как отдаёт API. События — это первое, куда стоит смотреть, раньше логов: логи говорят, что делало приложение, события — что с ним делал кластер. Половина проблем, которые действительно важны (кончилось место, не тянется образ, не хватает ресурсов, не примонтировался том), в логах вообще не видна.

1. Как отсортировать события kubectl по времени?

$ clai покажи события кластера, свежие внизу→ kubectl get events --sort-by='.lastTimestamp'

Без сортировки события выводятся в произвольном порядке, и читать их бесполезно. Ключ пишется с точкой в начале — это путь в JSON-структуре объекта.

2. Как показать только предупреждения в одном namespace?

$ clai покажи предупреждения в namespace production за последнее время→ kubectl get events -n production --field-selector type=Warning --sort-by='.lastTimestamp'

У событий два типа — Normal и Warning. При разборе инцидента Normal только мешает. --field-selector фильтрует на стороне сервера, то есть быстро даже на большом кластере.

3. Как посмотреть события конкретного пода?

$ clai покажи что случилось с этим подом→ kubectl describe pod my-app-7d9f8 -n production

describe показывает события внизу вывода, уже привязанные к объекту. Обычно это быстрее, чем фильтровать общий список. Там же видны причины вроде FailedScheduling, ImagePullBackOff, OOMKilled.

4. Как посмотреть логи упавшего контейнера?

$ clai покажи логи предыдущего запуска этого контейнера→ kubectl logs my-app-7d9f8 -n production --previous

При перезапуске контейнера его логи заменяются логами нового. --previous достаёт логи предыдущего экземпляра — то есть именно те, где записана причина падения. Без этого флага вы смотрите на чистый лог только что стартовавшего процесса.

5. Как следить за событиями в реальном времени?

$ clai следи за событиями в этом namespace прямо сейчас→ kubectl get events -n production --watch

Полезно при выкатке: видно, как планировщик размещает поды, тянутся образы и проходят проверки готовности. Прервать по Ctrl+C.

6. Почему под не запускается?

$ clai покажи поды, которые не в состоянии Running, и события по ним→ kubectl get pods -n production --field-selector status.phase!=Running

Сначала сузить до проблемных подов, потом по каждому смотреть describe. Состояние Pending почти всегда означает, что планировщику некуда поставить под — не хватает ресурсов, не подошли ограничения размещения или не нашёлся том.

Грабли

• События живут около часа. По умолчанию --event-ttl равен 1 часу, после чего событие исчезает. Разбирать вчерашний инцидент по событиям уже нечем — нужен внешний сборщик.
• --sort-by требует путь с точкой в начале. --sort-by='.lastTimestamp', а не lastTimestamp. Без точки команда молча вернёт неотсортированный список.
• События привязаны к пространству имён. Без -n вы смотрите namespace по умолчанию и не увидите ничего из production. Для полной картины --all-namespaces.

Похожие вопросы

Логи или события — с чего начинать? С событий. Они отвечают, дошло ли вообще до запуска приложения. Логи имеют смысл только после того, как контейнер стартовал.

Почему kubectl logs пустой? Контейнер не стартовал, либо пишет не в stdout, либо уже перезапустился. На первые два случая ответ дают события, на третий — флаг --previous.

Чем kubectl events отличается от kubectl get events? Отдельная команда kubectl events появилась позже и по умолчанию сортирует по времени. get events есть везде, включая старые кластеры.

Читайте также

• Docker и Kubernetes: мышечная память — на пенсию
• Docker съел диск: как вернуть место
• Читать логи сервиса через journalctl

CliAI превращает вопрос о поде обычными словами в нужную команду kubectl — не надо держать в голове синтаксис field-селекторов и JSONPath. Установка одной строкой.