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 показывает отсутствие ссылки на результат задачи:

      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 минуту), добавьте запас. Используйте метрики нагрузки платформы или количество завершённых pipeline для приближённой оценки пиковых значений в минуту и установите порог выше этого пика.
      • Примечание: Этот параметр может быть недоступен для настройки в управляемых Kubernetes-сервисах (например, EKS, AKS, GKE), где пользователи не имеют доступа к управляющей плоскости.
    2. Убедитесь, что на узлах достаточно свободного места на диске.
      • Почему это помогает: При достижении узлами дискового давления kubelet и containerd могут агрессивно очищать логи и директории подов. Это может привести к удалению или усечению логов sidecar до того, как контроллер их прочитает.
      • Как изменить: Проверьте конфигурацию эвакуации kubelet в KubeletConfiguration и настройте пороги дискового давления в соответствии с планированием ёмкости.
      • Практический совет: Мониторьте использование дискового пространства на сборочных узлах и планируйте своевременную очистку до срабатывания эвакуации или очистки логов.
    3. Убедитесь, что настройки хранения логов (например, ротация логов kubelet) соответствуют ожидаемой длительности pipeline.
      • Почему это помогает: Если логи ротируются слишком быстро или сохраняется слишком мало файлов, вывод sidecar может исчезнуть до разбора результатов, даже если под всё ещё существует.
      • Как изменить: Проверьте параметры containerLogMaxSize и containerLogMaxFiles в KubeletConfiguration.
    4. Рассмотрите возможность возврата к методу по умолчанию termination-message.
      • Почему это помогает: Метод termination-message не зависит от логов пода, поэтому полностью избегает описанных проблем с доступностью логов.
      • Компромисс: Этот метод ограничен размером результата 4 КБ. Если результаты Task превышают этот лимит, pipeline завершится с ошибкой. Это может негативно сказаться на опыте пользователя при необходимости больших результатов.
      • Как изменить: Установите results-from: termination-message в TektonConfig. Обратите внимание, что прямое изменение ConfigMap feature-flags не вступит в силу, если Tekton развернут через TektonConfig, так как оператор будет синхронизировать и перезаписывать изменения ConfigMap.

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

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

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