Архитектура
Я использую Kubernetes для обработки заданий с помощью сканера / скребка. 4 узла (каждый 8G и 4 процессора). Без автоматического масштабирования кластера, с Digital Ocean.
Существует 3 различных контейнера:
- Очередь Redis (реплики 1), для хранения идентификаторов + связанная служба
- Cron. js работает в контейнере (rpeplicas 1, ограничения: 0,5 CPU / 1000Mi), добавляя 37000 идентификаторов в очередь Redis один раз в день.
- Crawler. js для сканирования элементов с помощью Puppeteer. Он берет идентификатор из очереди Redis, удаляет данные и затем удаляет идентификатор из очереди Redis. Он использует nodejs дочерний процесс для ускорения сканирования с 2 рабочими.
=> Crawler использование 1 реплика , и активируйте HPA до 15 модулей , если процессор идет до 75% (при запуске обработки заданий в очереди). Ресурсы искателя: Запросы: память 300Mi, ограничения на 0,3 процессора: 450Mi, 0,4 процессора
При сканировании контейнер искателя всегда потребляет 100% ЦП и 100% на запросах и приближается к пределам .
Ожидаемый объем:
Сканер должен начинать сканирование элементов один раз в день, используйте много ЦП, запускает HPA и затем 15 модулей работают для сканирования элементов. Он должен сканировать в течение нескольких часов (потребляя каждый идентификатор в очереди), а затем возвращаться к нормальному состоянию (1 реплика), когда сканирование завершено.
При очереди в 1000 элементов это должно занять около 10 мин для сканирования и все работает.
Проблема
Использование 37000 элементов в очереди: Через ~ 50 мин. ЦП каждого сканера на узле снижается до 1 (0%) но память остается вокруг запроса. Это происходит сначала с одним узлом, а затем через 10 минут на другом (Изображение из Grafana / Prometheus: Графическое изображение сбоя процессора. Вы можете ясно видеть некоторые стручки теряют процессор, все они принадлежат одному узлу). Память продолжает оставаться почти нормальной. Сканер остается неопределенным при запуске браузера кукловода и больше не сканирует.
Состояние исправно, все работает нормально
Стручки на одном узле имеют свой ЦП при снижении можно увидеть, что память остается стабильной
График модуля с процессором 1/0%
Ошибка 2-го узла
Узлы kubectl top nodes:
CPU(cores) CPU% MEMORY(bytes) MEMORY%
...e-zwl2 2261m 56% 2456Mi 36%
...e-zwll 2240m 56% 2809Mi 41%
...e-zwpb 123m 3% 2562Mi 38%
...e-zwss 159m 3% 2878Mi 43%
График, после ~ 1 часа сканирования
CPU(cores) CPU% MEMORY(bytes) MEMORY%
...e-zwl2 1996m 49% 2395Mi 35%
...e-zwll 2106m 52% 2925Mi 43%
...e-zwpb 204m 5% 2554Mi 38%
...e-zwss 129m 3% 2875Mi 42%
Любые идеи, как отлаживать это?
Что я пробовал:
- Увеличение лимитов и запросов для модуля.
- Уменьшить количество рабочих до 1.
- Добавить больше узлов (8G 4cpu).
- Запустить его в разное время дня.
- Удалить HPA.
- Уничтожение неработающего модуля: он перезагружается и нормально сканируется.
- Проверьте Redis CPU / Mem, регистрирует: все нормально.
- Добавьте больше CPU и памяти к гусеничным коробочкам.
Примечания:
Что-то, что я заметил, стручки ресничек в системе kube иногда перезагружаются, я не знать, связано ли это с моей проблемой или полезно для точного.
Искатель не новый и был закодирован для работы на docker контейнере с pm2, он работает нормально в производство. Мы перемещаем его в Kubernetes.
Я должен использовать 2 других микросервиса и Cluster Auto Scale. Но для упрощения я остановлюсь на 3 микро сервисах, связанных с ошибкой. Кроме того, я отключил хранение списанных данных в другой внешней БД, чтобы упростить проблему и выделить ошибку.