GitLab CI: koniec crashy runnerów
Pięć hostów z runnerami Docker, pipeline'y saturujące CPU do 100% kilka razy w tygodniu i crashe runnerów wymagające ręcznych restartów. Tak wyglądał punkt wyjścia.
Przed
- 5 hostów z runnerami Docker executor
- Pipeline saturuje 100% CPU: 8–9 razy w tygodniu
- Crash runnera: ~3 razy w tygodniu
- Spowolnienie jobów odczuwalne codziennie
- Limity cgroups nie izolują obciążeń
Po
- Kubernetes executor na klastrze RKE2
- ResourceQuota per projekt
- Shell-operator nadaje limity per service
- 0 crashów runnerów miesięcznie
- 40–60% szybsze pipeline'y
Przebieg projektu
Problemem nie była moc obliczeniowa — 200 vCPU i 320 GB RAM to dużo — tylko brak izolacji. Joby CI współdzieliły hosty bez realnych limitów, więc jeden ciężki pipeline potrafił zagłodzić wszystkie pozostałe i wywrócić runnera.
Przenieśliśmy wykonywanie jobów na Kubernetes executor: każdy job dostaje własny pod z jawnie zadeklarowanymi requestami i limitami CPU/RAM. ResourceQuota per projekt gwarantuje, że żaden zespół nie zje całego klastra, a shell-operator automatycznie nadaje limity per service — bez ręcznego dopisywania ich w każdym repozytorium.
Efekt: scheduler Kubernetesa upakowuje joby gęściej i bezpieczniej niż statyczny podział na hosty, pipeline'y przyspieszyły o 40–60%, a od wdrożenia nie wystąpił ani jeden crash runnera.
Wersja techniczna tego case study na blogu →
Wasze CI też dławi się w godzinach szczytu?
Pokażemy, jak to naprawić — pierwsza konsultacja bezpłatna.
Darmowa konsultacja →