Ek het Kube Eagle geskep - 'n Prometheus-uitvoerder. Dit het geblyk 'n gawe ding te wees wat help om die hulpbronne van klein en mediumgrootte groepe beter te verstaan. Op die ou end het ek honderde dollars gespaar omdat ek die regte masjientipes gekies het en toepassingshulpbronlimiete vir werkladings opgestel het.
Ek sal jou vertel van die voordele , maar ek sal eers verduidelik wat die bohaai veroorsaak het en hoekom hoëgehalte-monitering nodig was.
Ek het verskeie groepe van 4–50 nodusse bestuur. Elke groepering bevat tot 200 mikrodienste en toepassings. Om bestaande hardeware beter te gebruik, is die meeste ontplooiings opgestel met barsbare RAM en SVE-hulpbronne. Op hierdie manier kan peule beskikbare hulpbronne neem indien nodig, en terselfdertyd nie inmeng met ander toepassings op hierdie nodus nie. Wel, is dit nie wonderlik nie?
En alhoewel die groep relatief min SVE (8%) en RAM (40%) verbruik het, het ons voortdurend probleme gehad met peule wat voorrang gekry het toe hulle probeer het om meer geheue toe te ken as wat op die nodus beskikbaar was. Destyds het ons net een dashboard gehad om Kubernetes-hulpbronne te monitor. Soos hierdie:
Grafana-dashboard met slegs cAdvisor-statistieke
Met so 'n paneel is dit nie 'n probleem om nodusse te sien wat baie geheue en SVE eet nie. Die probleem is om uit te vind wat die rede is. Om die peule in plek te hou, kan 'n mens natuurlik gewaarborgde hulpbronne op alle peule opstel (versoek hulpbronne gelyk aan die limiet). Maar dit is nie die slimste gebruik van hardeware nie. Die groep het etlike honderde gigagrepe geheue gehad, terwyl sommige nodusse uitgehonger was, terwyl ander 4–10 GB in reserwe gehad het.
Dit blyk dat die Kubernetes-skeduleerder werkladings oneweredig oor beskikbare hulpbronne versprei het. Die Kubernetes-skeduleerder neem verskillende konfigurasies in ag: affiniteit, vlekke en verdraagsaamheidsreëls, noduskiesers wat die beskikbare nodusse kan beperk. Maar in my geval was daar niks so nie, en die peule is beplan na gelang van die gevraagde hulpbronne op elke nodus.
Die nodus wat die meeste gratis hulpbronne het en wat aan die versoekvoorwaardes voldoen, is vir die peul gekies. Ons het gevind dat die aangevraagde hulpbronne op die nodusse nie ooreenstem met die werklike gebruik nie, en dit is waar Kube Eagle en sy hulpbronmoniteringvermoëns tot die redding gekom het.
Ek het byna alle Kubernetes-klusters wat net gemonitor word и . Node-uitvoerder verskaf statistieke oor I/O en skyf-, SVE- en RAM-gebruik, terwyl Kube State Metrics Kubernetes-objekmetrieke soos versoeke en SVE- en geheuehulpbronlimiete wys.
Ons moet die gebruiksmetrieke kombineer met die versoeke en limiete in Grafana, en dan sal ons al die inligting oor die probleem kry. Dit klink eenvoudig, maar die twee instrumente noem die etikette eintlik anders, en sommige metrieke het glad nie enige metadata-etikette nie. Kube Eagle doen alles self en die paneel lyk so:
Ons het daarin geslaag om baie probleme met hulpbronne op te los en toerusting te bespaar:
- Sommige ontwikkelaars het nie geweet hoeveel hulpbronne mikrodienste benodig nie (of het eenvoudig nie gepla nie). Daar was geen manier vir ons om verkeerde versoeke vir hulpbronne te vind nie - hiervoor moet ons verbruik plus versoeke en limiete ken. Nou sien hulle Prometheus-statistieke, monitor werklike gebruik en pas versoeke en limiete aan.
- JVM-toepassings neem soveel RAM as wat hulle kan hanteer. Die vullisverwyderaar stel geheue slegs vry wanneer meer as 75% gebruik word. En aangesien die meeste dienste barsbare geheue het, was dit altyd deur die JVM beset. Daarom het al hierdie Java-dienste baie meer RAM opgevreet as wat verwag is.
- Sommige toepassings het te veel geheue aangevra, en die Kubernetes-skeduleerder het nie hierdie nodusse aan ander toepassings gegee nie, al was hulle in werklikheid vryer as ander nodusse. Een ontwikkelaar het per ongeluk 'n ekstra syfer in die versoek bygevoeg en 'n groot stuk RAM gegryp: 20 GB in plaas van 2. Niemand het opgemerk nie. Die toepassing het 3 replikas gehad, so soveel as 3 nodusse is geraak.
- Ons het hulpbronlimiete ingestel, peule herskeduleer met die korrekte versoeke en 'n ideale balans van hardewaregebruik oor alle nodusse gekry. 'n Paar nodusse kon heeltemal gesluit gewees het. En toe sien ons dat ons die verkeerde masjiene het (CPU-georiënteerd, nie geheue-georiënteerd nie). Ons het die tipe verander en nog verskeie nodusse uitgevee.
Resultate van
Met barsbare hulpbronne in die groepering gebruik jy die beskikbare hardeware meer doeltreffend, maar die Kubernetes skeduleerder skeduleer peule gebaseer op versoeke vir hulpbronne, en dit is belaai. Om twee vlieë in een klap te slag: om probleme te vermy en hulpbronne ten volle te gebruik, het jy goeie monitering nodig. Dit is hoekom dit nuttig sal wees (Prometheus-uitvoerder en Grafana-paneelbord).
Bron: will.com