Alauda DevOps Pipelines Docs
  • Русский

    • Отсутствуют результаты TaskRun при использовании Sidecar Logs

    Содержание

    Описание проблемыПроявление ошибкиАнализ первопричиныУстранение неполадокРешениеПрофилактические мерыСвязанное содержимое

    Описание проблемы

    Когда включен results-from: sidecar-logs, PipelineRun или TaskRun может не суметь разрешить результаты, если контроллер не может прочитать логи Pod. Обычно это проявляется как отсутствие результатов Task или Pipeline во время сбора результатов.

    Проявление ошибки

    • PipelineRun показывает сбой сбора результатов:

      Failed to get PipelineResult from TaskRun Results for PipelineRun <pipelinerun-name>: invalid pipelineresults [<result-name>], the referenced results don't exist

    • TaskRun показывает отсутствующую ссылку на результат Task:

      Invalid task result reference: Could not find result with name variables for task <task-name>

    • Pod по-прежнему существует, но лог sidecar получить нельзя:

      unable to retrieve container logs for containerd://<container-id>

    Анализ первопричины

    Чтобы обойти ограничение в 4 KB для termination message, Tekton может читать результаты из логов sidecar с помощью results-from: sidecar-logs (beta-функция начиная с Tekton v0.61.0). Этот механизм опирается на Kubernetes pod logs API для получения вывода sidecar. Если log API не может вернуть данные, Tekton не может разобрать результаты, что приводит к отсутствующим ссылкам TaskResult или PipelineResult.

    К типичным причинам относятся:

    • Логи Pod недоступны, хотя сам Pod все еще существует.
    • На узлах, использующих файловые логи, записи в /var/log/containers или /var/log/pods удаляются либо ротируются слишком агрессивно.
    • kubelet или container runtime временно работает некорректно либо был перезапущен.
    • Сборщик garbage collection для Pod или контейнера удаляет логи до того, как результаты будут собраны.

    Устранение неполадок

    1. Убедитесь, что results-from: sidecar-logs включен в TektonConfig и ConfigMap feature-flags. 
      $ kubectl get tektonconfig config -o yaml

spec:
  pipeline:
    results-from: sidecar-logs
      $ kubectl get configmap feature-flags -n tekton-pipelines -o yaml

data:
  results-from: sidecar-logs
    2. Проверьте события PipelineRun и TaskRun, чтобы подтвердить сбои при сборе результатов. 
      $ kubectl describe pipelinerun -n ${namespace} ${pipelinerun_name}

Failed to get PipelineResult from TaskRun Results for PipelineRun <pipelinerun-name>: invalid pipelineresults [<result-name>], the referenced results don't exist
      $ kubectl describe taskrun -n ${namespace} ${taskrun_name}

Invalid task result reference: Could not find result with name variables for task <task-name>
    3. Проверьте логи sidecar напрямую. Если следующая команда возвращает ошибку, подобную приведенной ниже, это означает, что логи больше недоступны: 
      $ kubectl logs -n ${namespace} ${taskrun_pod} -c sidecar-tekton-log-results

unable to retrieve container logs for containerd://<container-id>
    4. Проверьте, настроен ли pod log RBAC для Tekton controller. Отсутствие RBAC-разрешений тоже может приводить к ошибкам получения логов: 
      $ kubectl auth can-i get pods/log \
  -n ${namespace} \
  --as=system:serviceaccount:tekton-pipelines:tekton-pipelines-controller

yes
    5. На узле проверьте, что файлы логов Pod и symlink'и по-прежнему существуют, а kubelet/containerd работают корректно.

    Решение

    Рекомендуется дольше сохранять завершенные Pod, чтобы логи sidecar оставались доступны во время сбора результатов.

    1. Увеличьте terminated-pod-gc-threshold (например, до 1000) на control plane и наблюдайте за поведением.
      • Почему это помогает: В загруженных средах многие Pod из TaskRun могут завершаться примерно одновременно. Если число завершенных Pod превышает порог, pod GC немедленно удаляет их. После удаления Pod log API для sidecar становится недоступен, поэтому результаты невозможно собрать. Увеличение порога откладывает это окно очистки и дает Tekton больше времени на чтение логов sidecar и извлечение результатов.
      • Как изменить: См. флаги kube-controller-manager для --terminated-pod-gc-threshold.
      • Как подобрать значение: Оцените, сколько Pod переходят в Succeeded или Failed за короткий интервал (например, за 1 минуту), затем добавьте запас. Используйте метрики нагрузки платформы или количество завершений pipeline, чтобы приблизительно определить пик завершений в минуту, и задайте порог выше этого пика.
      • Примечание: Этот параметр может быть недоступен для настройки в управляемых сервисах Kubernetes (таких как EKS, AKS или GKE), где у пользователей нет доступа к control plane.
    2. Убедитесь, что на узлах достаточно дискового пространства.
      • Почему это помогает: Когда на узлах возникает disk pressure, kubelet и containerd могут агрессивно очищать логи и каталоги Pod. Это может удалить или обрезать логи sidecar до того, как контроллер их прочитает.
      • Как изменить: Изучите конфигурацию eviction у kubelet в KubeletConfiguration и настройте пороги disk pressure в соответствии с планированием емкости.
      • Операционная рекомендация: Отслеживайте использование хранилища на узлах сборки в вашей платформе и выполняйте предварительную очистку до того, как disk pressure вызовет eviction или очистку логов.
    3. Убедитесь, что настройки хранения логов (например, ротация логов kubelet) соответствуют ожидаемой длительности pipeline.
      • Почему это помогает: Если логи ротируются слишком быстро или сохраняется слишком мало файлов, вывод sidecar может исчезнуть до того, как результаты будут разобраны, даже если Pod все еще существует.
      • Как изменить: Проверьте containerLogMaxSize и containerLogMaxFiles в KubeletConfiguration.
    4. Рассмотрите возможность возврата к методу termination-message по умолчанию.
      • Почему это помогает: Подход termination-message не зависит от логов pod, поэтому полностью исключает описанные выше проблемы с доступностью логов.
      • Компромисс: У этого метода есть ограничение на размер результатов в 4 KB. Если результаты Task превышают этот предел, pipeline завершится с ошибкой. Это может негативно сказаться на пользовательском опыте, когда нужны более крупные результаты.
      • Как изменить: Установите results-from: termination-message в TektonConfig. Обратите внимание, что прямое изменение ConfigMap feature-flags не вступит в силу, если Tekton развернут через TektonConfig, поскольку operator выполнит reconciliation и перезапишет изменения ConfigMap.

    Профилактические меры

    • Отслеживайте доступность pod logs API в кластере.
    • Поддерживайте разумный размер результатов Task и собирайте результаты как можно раньше.
    • Рассматривайте beta-функции как потенциально менее стабильные, чем GA-функции, в нестабильных средах с логами и периодически проверяйте их использование.

    Связанное содержимое