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

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

    Содержание

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

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

    При включённой опции results-from: sidecar-logs PipelineRun или TaskRun могут не получить результаты, если контроллер не может прочитать логи пода. Обычно это проявляется как отсутствие результатов 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>

    • Под существует, но логи sidecar получить не удаётся:

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

    Анализ причины

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

    Типичные причины:

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

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

    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. Проверьте, что для контроллера Tekton настроены права RBAC на доступ к логам подов. Отсутствие прав может вызвать ошибки при получении логов: 
      $ kubectl auth can-i get pods/log \
  -n ${namespace} \
  --as=system:serviceaccount:tekton-pipelines:tekton-pipelines-controller

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

    Решение

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

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

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

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

    Связанный контент