Stworzyłem Kube Eagle - eksportera Prometheusa. Okazało się to fajną rzeczą, która pozwala lepiej zrozumieć zasoby małych i średnich klastrów. Ostatecznie zaoszczędziłem setki dolarów, ponieważ wybrałem odpowiednie typy maszyn i skonfigurowałem limity zasobów aplikacji dla obciążeń.
Opowiem Ci o korzyściach , ale najpierw wyjaśnię, co spowodowało to zamieszanie i dlaczego potrzebny był wysokiej jakości monitoring.
Zarządzałem kilkoma klastrami po 4–50 węzłów. Każdy klaster zawiera do 200 mikrousług i aplikacji. Aby lepiej wykorzystać istniejący sprzęt, większość wdrożeń skonfigurowano z możliwością przełączania zasobów pamięci RAM i procesora. W ten sposób pody mogą w razie potrzeby pobierać dostępne zasoby, a jednocześnie nie zakłócać innych aplikacji na tym węźle. Czyż to nie wspaniałe?
I chociaż klaster zużywał stosunkowo mało procesora (8%) i pamięci RAM (40%), stale występowały problemy z wywłaszczaniem podów, gdy próbowały przydzielić więcej pamięci, niż było dostępne w węźle. Mieliśmy wtedy tylko jeden dashboard do monitorowania zasobów Kubernetesa. Lubię to:
Panel Grafana zawierający wyłącznie dane cAdvisor
Przy takim panelu nie jest problemem zobaczyć węzły zużywające dużo pamięci i procesora. Problem polega na ustaleniu przyczyny. Aby utrzymać kapsuły na miejscu, można oczywiście ustawić gwarantowane zasoby na wszystkich kapsułach (żądane zasoby równe limitowi). Ale to nie jest najmądrzejsze wykorzystanie sprzętu. Klaster miał kilkaset gigabajtów pamięci, niektóre węzły głodowały, a innym pozostawało 4–10 GB rezerwy.
Okazuje się, że harmonogram Kubernetesa rozkłada obciążenia nierównomiernie pomiędzy dostępne zasoby. Harmonogram Kubernetes uwzględnia różne konfiguracje: reguły powinowactwa, taintów i tolerancji, selektory węzłów, które mogą ograniczać dostępne węzły. Ale w moim przypadku nic takiego nie było, a pody zostały zaplanowane w zależności od żądanych zasobów na każdym węźle.
Dla poda wybrano węzeł, który ma najwięcej wolnych zasobów i spełnia warunki żądania. Odkryliśmy, że żądane zasoby w węzłach nie odpowiadały faktycznemu wykorzystaniu i w tym momencie na ratunek przyszedł Kube Eagle i jego możliwości monitorowania zasobów.
Prawie wszystkie klastry Kubernetes monitoruję tylko za pomocą и . Node Exporter zapewnia statystyki dotyczące operacji we/wy oraz użycia dysku, procesora i pamięci RAM, podczas gdy Kube State Metrics pokazuje metryki obiektów Kubernetes, takie jak żądania oraz limity zasobów procesora i pamięci.
Musimy połączyć metryki użycia z metrykami żądań i limitów w Grafanie, a wtedy otrzymamy wszystkie informacje o problemie. Brzmi to prosto, ale te dwa narzędzia w rzeczywistości nazywają etykiety inaczej, a niektóre metryki w ogóle nie mają żadnych etykiet metadanych. Kube Eagle wszystko robi sam i panel wygląda tak:
Udało nam się rozwiązać wiele problemów z zasobami i zaoszczędzić sprzęt:
- Niektórzy programiści nie wiedzieli, ile zasobów potrzeba mikrousług (lub po prostu nie zawracali sobie tym głowy). Nie mogliśmy znaleźć nieprawidłowych żądań zasobów - w tym celu musimy znać zużycie oraz żądania i limity. Teraz widzą wskaźniki Prometheus, monitorują rzeczywiste wykorzystanie i dostosowują żądania i limity.
- Aplikacje JVM zajmują tyle pamięci RAM, ile mogą obsłużyć. Moduł zbierający elementy bezużyteczne zwalnia pamięć tylko wtedy, gdy jest wykorzystane więcej niż 75%. A ponieważ większość usług ma pamięć przerywaną, zawsze była ona zajęta przez maszynę JVM. Dlatego wszystkie te usługi Java pochłaniały znacznie więcej pamięci RAM, niż oczekiwano.
- Niektóre aplikacje żądały zbyt dużo pamięci, a harmonogram Kubernetesa nie udostępniał tych węzłów innym aplikacjom, mimo że w rzeczywistości były one bardziej swobodne niż inne węzły. Jeden z programistów przez przypadek dodał do żądania dodatkową cyfrę i zabrał duży fragment pamięci RAM: 20 GB zamiast 2. Nikt tego nie zauważył. Aplikacja miała 3 repliki, więc dotknięte zostały aż 3 węzły.
- Wprowadziliśmy limity zasobów, przesunęliśmy harmonogram podów z właściwymi żądaniami i uzyskaliśmy idealną równowagę wykorzystania sprzętu we wszystkich węzłach. Kilka węzłów mogło zostać całkowicie zamkniętych. A potem zobaczyliśmy, że mamy złe maszyny (zorientowane na procesor, a nie na pamięć). Zmieniliśmy typ i usunęliśmy kilka kolejnych węzłów.
Wyniki
Dzięki zasobom, które można rozdzielać w klastrze, dostępny sprzęt jest wykorzystywany bardziej efektywnie, ale moduł planujący Kubernetes planuje planowanie podów na podstawie żądań zasobów, a to jest obarczone dużym ryzykiem. Aby upiec dwie pieczenie na jednym ogniu: aby uniknąć problemów i maksymalnie wykorzystać zasoby, potrzebny jest dobry monitoring. Dlatego będzie to przydatne (eksporter Prometheus i pulpit Grafana).
Źródło: www.habr.com