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

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

    Содержание

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

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

    Когда включен results-from: sidecar-logs, PipelineRun или TaskRun может не суметь разрешить результаты, если controller не может прочитать логи 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 log недоступен для получения:

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

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

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

    Наиболее распространенные причины:

    • Логи Pod недоступны, хотя сам Pod еще существует.
    • На узлах, использующих файловые логи, записи в /var/log/containers или /var/log/pods удаляются либо ротируются слишком агрессивно.
    • kubelet или container runtime временно работают нестабильно или были перезапущены.
    • Сборщик мусора для 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 logs напрямую. Если следующая команда возвращает ошибку вроде указанной ниже, это означает, что логи больше недоступны: 
      $ kubectl logs -n ${namespace} ${taskrun_pod} -c sidecar-tekton-log-results

unable to retrieve container logs for containerd://<container-id>
    4. Проверьте, что для Tekton controller настроен pod log RBAC. Отсутствие разрешений 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 logs оставались доступны во время сбора результатов.

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

    Предотвращение

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

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