В этом материале
Kubectl logs --previous помогает получить журнал предыдущего контейнера, но не является долговременным архивом. Ротация, пересоздание Pod и потеря узла ограничивают локальные данные. Для расследований за пределами этого lifecycle нужен отдельный сбор и сохранение событий.
Kubectl logs —previous помогает получить журнал предыдущего контейнера, но не является долговременным архивом. Ротация, пересоздание Pod и потеря узла ограничивают локальные данные. Для расследований за пределами этого lifecycle нужен отдельный сбор и сохранение событий.
Уточните identity журнала
Сохраните namespace, Pod UID, container name и restartCount. Имя Pod не всегда достаточно, если объект был удалён и создан заново. Обычный kubectl logs и —previous относятся к разным экземплярам контейнера. У многоконтейнерного Pod явно укажите нужный container. Сначала получите доступные данные, затем приступайте к исправлению, способному пересоздать объект. Перезапуск ради диагностики может убрать именно тот локальный след, который объяснял исходный отказ, если внешнего сбора пока нет.
Проверьте ротацию kubelet
Kubelet управляет ротацией container logs через CRI и соответствующие настройки размера/числа файлов. Kubectl logs не следует считать интерфейсом ко всей произвольной истории rotated files. Также учитывайте отдельное файловое логирование приложения, которое может не попадать в stdout/stderr. Путь журналов и правила агента должны совпадать с конфигурацией узла. Если сборщик ожидает стандартный каталог, а kubelet использует другой, отсутствие событий в backend не доказывает, что приложение ничего не записывало.
Разберите потерю после замены
В учебном случае worker падает, оператор получает —previous, затем Deployment создаёт новый Pod на другом узле. После этого старая локальная история может больше не быть доступна обычным обращением к новому Pod. Внешний node agent, успевший отправить записи, сохраняет отдельную копию согласно backend retention. Пример показывает границу ответственности, а не гарантирует полную доставку: агент сам может отставать, терять буфер или не читать нужный файл.
| Источник | Какая история ожидается |
|---|---|
| Текущий logs | Доступный текущий контейнер |
| Previous | Предыдущий экземпляр в доступной области |
| Rotated files | По локальным правилам узла |
| Внешний backend | По доставке и retention системы сбора |
Выберите архитектуру сбора
Kubernetes описывает node-level agent, logging sidecar и прямую отправку приложением. Node agent часто разворачивают как DaemonSet для чтения журналов узла. Sidecar полезен для особого формата или потока, но добавляет собственный lifecycle. Выберите способ по фактическому пути данных, разрешениям и требованиям сохранения. Не копируйте все host logs в приложение без нужного scope. Для каждого перехода определите buffering и что произойдёт при недоступности backend.
Проверьте полный жизненный цикл
Создайте синтетические пронумерованные события, затем проверьте rotation, container restart и Pod replacement на стенде. Сравните полученные диапазоны без объявления exactly-once. Артефакт должен включать пути, агент, UID и границы возможных пробелов. После исправления убедитесь, что записи доступны независимо от существования исходного Pod. Долговременное хранение требует собственной политики доступа и retention; само наличие DaemonSet не является доказательством, что нужные события сохранятся после потери узла.
Связанные разборы: gpu owner network outage log; gpu maintenance change register.