Ik makke Kube Eagle - in Prometheus eksporteur. It blykte in cool ding te wêzen dat helpt om de middels fan lytse en middelgrutte klusters better te begripen. Oan 'e ein haw ik hûnderten dollars besparre, om't ik de juste masinesoarten selekteare en limyten foar applikaasjeboarnen ynstelde foar workloads.
Ik sil jo fertelle oer de foardielen , mar earst sil ik útlizze wat de drokte feroarsake hat en wêrom heechweardige kontrôle nedich wie.
Ik slagge ferskate klusters fan 4-50 knopen. Elk kluster befettet maksimaal 200 mikrotsjinsten en applikaasjes. Om better gebrûk te meitsjen fan besteande hardware, waarden de measte ynset konfigureare mei burstable RAM en CPU-boarnen. Op dizze manier kinne pods beskikbere boarnen nimme as it nedich is, en tagelyk net bemuoie mei oare applikaasjes op dit knooppunt. No, is it net geweldich?
En hoewol it kluster relatyf lyts CPU (8%) en RAM (40%) konsumearre, hienen wy konstant problemen mei pods dy't foarôfgeand wiene doe't se besochten mear ûnthâld te allocearjen dan op 'e node beskikber wie. Doe hiene wy mar ien dashboard foar it kontrolearjen fan Kubernetes-boarnen. Lykas dit:
Grafana-dashboard mei allinich cAdvisor-metriken
Mei sa'n paniel is it gjin probleem om knopen te sjen dy't in protte ûnthâld en CPU ite. It probleem is om út te finen wat de reden is. Om de podden op it plak te hâlden, koe men fansels garandearre middels op alle podden opsette (oanfrege middels lyk oan de limyt). Mar dit is net it slimste gebrûk fan hardware. It kluster hie ferskate hûnderten gigabytes oan ûnthâld, wylst guon knooppunten úthongere, wylst oaren 4–10 GB yn reserve hiene.
It docht bliken dat de Kubernetes-planner wurkloads uneven ferdielde oer beskikbere boarnen. De Kubernetes-planner hâldt rekken mei ferskate konfiguraasjes: regels foar affiniteit, tinzen en toleraasjes, knooppuntselektors dy't de beskikbere knooppunten beheine kinne. Mar yn myn gefal wie d'r neat as dat, en de pods waarden pland ôfhinklik fan 'e frege middels op elke knooppunt.
It knooppunt dat de measte frije boarnen hat en dat foldocht oan de fersykbetingsten is selektearre foar de pod. Wy fûnen dat de oanfrege boarnen op 'e knopen net oerienkomme mei it eigentlike gebrûk, en dit is wêr't Kube Eagle en har mooglikheden foar tafersjoch op boarnen ta de rêding kamen.
Ik haw hast alle Kubernetes klusters kontrolearre allinnich mei и . Node Exporter jout statistiken oer I / O en skiif, CPU, en RAM gebrûk, wylst Kube State Metrics toant Kubernetes foarwerp metriken lykas oanfragen en CPU en ûnthâld boarne grinzen.
Wy moatte de gebrûksmetriken kombinearje mei de oanfragen en limitenmetriken yn Grafana, en dan krije wy alle ynformaasje oer it probleem. Dit klinkt ienfâldich, mar de twa ark neame de labels eins oars, en guon metriken hawwe hielendal gjin metadata-labels. Kube Eagle docht alles sels en it paniel sjocht der sa út:
Wy slaggen in protte problemen op te lossen mei boarnen en besparje apparatuer:
- Guon ûntwikkelders wisten net hoefolle boarnen mikrotsjinsten nedich wiene (of makken it gewoan net lestich). D'r wie gjin manier foar ús om ferkearde oanfragen foar boarnen te finen - hjirfoar moatte wy konsumpsje plus oanfragen en grinzen witte. No sjogge se Prometheus-metriken, kontrolearje it werklike gebrûk en oanpasse oanfragen en grinzen.
- JVM-applikaasjes nimme safolle RAM as se kinne omgean. De garbage collector makket allinich ûnthâld frij as mear as 75% wurdt brûkt. En om't de measte tsjinsten burstable ûnthâld hawwe, waard it altyd beset troch de JVM. Dêrom ieten al dizze Java-tsjinsten folle mear RAM op dan ferwachte.
- Guon applikaasjes fregen tefolle ûnthâld, en de Kubernetes-planner joech dizze knopen net oan oare applikaasjes, ek al wiene se yn feite frijer as oare knopen. Ien ûntwikkeler by ûngelok tafoege in ekstra sifer yn it fersyk en pakte in grut stik RAM: 20 GB ynstee fan 2. Gjinien fernaam. De applikaasje hie 3 replika's, sadat safolle as 3 knooppunten waarden beynfloede.
- Wy hawwe boarnegrinzen yntrodusearre, pods opnij ynsteld mei de juste oanfragen, en krigen in ideaal lykwicht fan hardwaregebrûk oer alle knooppunten. In pear knopen koene hielendal ôfsletten wurde. En doe seagen wy dat wy hiene de ferkearde masines (CPU rjochte, net ûnthâld rjochte). Wy hawwe it type feroare en ferskate mear knopen wiske.
Resultaten
Mei burstable boarnen yn it kluster brûke jo de beskikbere hardware effisjinter, mar de Kubernetes-planner plant pods basearre op oanfragen foar boarnen, en dit is fraught. Om twa fûgels yn ien stien te deadzjen: om problemen te foarkommen en de boarnen folslein te brûken, hawwe jo goede tafersjoch nedich. Dêrom sil it nuttich wêze (Prometheus eksporteur en Grafana dashboard).
Boarne: www.habr.com