#Доставка Harbor Webhook задерживается или не выполняется

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

После того как в проекте Harbor происходит событие, например загрузка образа, настроенная конечная точка Webhook не получает уведомление своевременно. Симптомы включают:

• Получатели Webhook, например триггеры артефактов в конвейере CI/CD, реагируют с большой задержкой (через минуты и более) или не реагируют вовсе.
• В Harbor UI → Job Service Dashboard растет число заданий WEBHOOK в очереди ожидания.

#Корневая причина

Harbor доставляет Webhook по следующему пути:

1. harbor-core помещает ключ в Redis для каждого события.
2. harbor-jobservice потребляет очередь и вызывает настроенные конечные точки Webhook.
3. Если HTTP-вызов завершается сбоем, harbor-jobservice выполняет повторные попытки до 10 раз перед тем, как отбросить событие.

Две распространенные ситуации приводят к накоплению заданий в конвейере:

• Недоступные конечные точки Webhook накапливают повторные попытки. Если одна или несколько конечных точек, настроенных для проекта, больше недоступны (служба выведена из эксплуатации, неверный URL, изменены правила firewall), каждое событие, направленное на них, использует все 10 попыток, прежде чем будет отброшено. При достаточном количестве недействительных конечных точек jobservice большую часть времени тратит на повторные попытки к недоступным адресатам, а легитимные Webhook ждут в очереди.
• Перезапуск harbor-jobservice (например, из-за OOM-kill). Если Pod многократно перезапускается под давлением памяти, выполняющиеся задания прерываются, а очередь продолжает расти.

#Диагностика

#Шаг 1 — Проверьте Job Service Dashboard

В интерфейсе Harbor откройте Job Service Dashboard и посмотрите задания с Type = WEBHOOK. Обратите внимание на:

• Pending Count — число заданий Webhook, ожидающих отправки.
• Latency — как долго ожидает самое старое задание в очереди.

Постоянный рост Pending Count — явный признак того, что накапливаются повторные попытки.

#Шаг 2 — Проверьте состояние jobservice

Убедитесь, что harbor-jobservice не находится в состоянии crash loop:

kubectl -n <NAMESPACE> get pods -l component=jobservice
kubectl -n <NAMESPACE> describe pod <RELEASE>-harbor-jobservice-xxxxx

Если вы видите частые перезапуски или причину OOMKilled в статусе Pod, значит jobservice испытывает нехватку ресурсов. Увеличьте его request и limit для CPU/памяти в Harbor CR.

#Шаг 3 — Проверьте журналы jobservice на наличие сбоев конечных точек

kubectl -n <NAMESPACE> logs <RELEASE>-harbor-jobservice-xxxxx | grep -i webhook

Повторяющиеся ошибки для одного и того же URL указывают на недоступную конечную точку, которую следует удалить.

#Шаг 4 — Проверьте конечные точки вручную

Из Pod, имеющего сетевой доступ, аналогичный jobservice, проверьте каждый URL Webhook, настроенный для затронутого проекта:

curl -v -X POST <WEBHOOK_URL>

Любой URL, который здесь завершает тайм-аут или возвращает ошибку, является кандидатом на удаление.

#Решение

#1. Удалите недействительные конфигурации Webhook

В интерфейсе Harbor откройте затронутый проект → Webhooks и удалите каждую конечную точку, определенную на шаге 4 как недоступную. Это остановит поступление новых событий в цикл повторных попыток.

#2. Очистите зависшую очередь

В Job Service Dashboard выберите ожидающие задания WEBHOOK и нажмите STOP. После этого Pending Count для WEBHOOK должен снизиться до 0, и легитимные события снова начнут обрабатываться.

#3. Перезапустите jobservice, если очередь не восстанавливается

Если после остановки заданий очередь по-прежнему зависла, перезапустите harbor-jobservice:

kubectl -n <NAMESPACE> rollout restart deployment <RELEASE>-harbor-jobservice

#4. Подберите ресурсы jobservice под нагрузку

Если на шаге 2 было обнаружено, что Pod завершался с OOMKilled, увеличьте лимиты ресурсов в Harbor CR, чтобы у jobservice было достаточно памяти для рабочего набора. Для небольшого Harbor при активном использовании обычно требуется не менее 4 CPU / 8 Gi memory, чтобы jobservice оставался стабильным.

#Примечания

• Даже при применении всех трех мер доставка Webhook осуществляется по принципу best-effort. Потребители не должны предполагать, что каждое событие будет доставлено: бюджет повторных попыток ограничен (10 попыток), после чего события отбрасываются.
• При проектировании интеграций, которые зависят от Webhook Harbor, предпочтение следует отдавать идемпотентным потребителям и периодически выполнять сверку через API Harbor, а не полагаться на одно уведомление.