Loin Kube Eaglen - Prometheus-viejän. Siitä tuli siisti juttu, joka auttaa ymmärtämään paremmin pienten ja keskisuurten klustereiden resursseja. Lopulta säästin satoja dollareita, koska valitsin oikeat konetyypit ja määritin sovellusresurssirajat työkuormille.
Kerron sinulle eduista , mutta ensin selitän, mikä aiheutti hälinän ja miksi laadukasta seurantaa tarvittiin.
Hallinnoin useita 4–50 solmun klustereita. Jokainen klusteri sisältää jopa 200 mikropalvelua ja sovellusta. Jotta olemassa olevaa laitteistoa voitaisiin hyödyntää paremmin, useimmat käyttöönotot määritettiin pursotettavalla RAM- ja CPU-resursseilla. Tällä tavalla podit voivat ottaa käytettävissä olevia resursseja tarvittaessa, eivätkä samalla häiritse muita tämän solmun sovelluksia. No, eikö olekin hienoa?
Ja vaikka klusteri kulutti suhteellisen vähän prosessoria (8 %) ja RAM-muistia (40 %), meillä oli jatkuvasti ongelmia podien ennaltaehkäisyssä, kun ne yrittivät varata enemmän muistia kuin solmussa oli käytettävissä. Tuolloin meillä oli vain yksi kojelauta Kubernetes-resurssien seurantaan. Kuten tämä:
Grafana-kojelauta vain cAdvisor-mittareilla
Tällaisella paneelilla ei ole ongelma nähdä solmuja, jotka syövät paljon muistia ja prosessoria. Ongelmana on selvittää syy. Jotta kotelot pysyisivät paikoillaan, kaikkiin podeihin voidaan tietysti asettaa taatut resurssit (pyydettyjen resurssien määrä vastaa rajaa). Mutta tämä ei ole älykkäin laitteiston käyttö. Klusterissa oli useita satoja gigatavuja muistia, kun jotkut solmut olivat nälkäisiä, kun taas toisilla oli 4–10 Gt varassa.
Osoittautuu, että Kubernetes-ajastin jakoi työkuormat epätasaisesti käytettävissä olevien resurssien kesken. Kubernetes-ajastin ottaa huomioon erilaiset kokoonpanot: affiniteetti-, lika- ja sietosäännöt, solmuvalitsimet, jotka voivat rajoittaa käytettävissä olevia solmuja. Mutta minun tapauksessani ei ollut mitään sellaista, ja podit suunniteltiin kunkin solmun pyydettyjen resurssien mukaan.
Podille valittiin solmu, jolla on eniten vapaita resursseja ja joka täyttää pyynnön ehdot. Huomasimme, että solmujen pyydetyt resurssit eivät vastanneet todellista käyttöä, ja tässä Kube Eagle ja sen resurssien valvontaominaisuudet tulivat apuun.
Olen valvonut melkein kaikkia Kubernetes-klustereita vain и . Node Exporter tarjoaa tilastoja I/O- ja levyn, suorittimen ja RAM:n käytöstä, kun taas Kube State Metrics näyttää Kubernetes-objektimetrit, kuten pyynnöt sekä suoritin- ja muistiresurssirajoitukset.
Meidän on yhdistettävä käyttömittarit Grafanan pyyntö- ja rajoitusmittauksiin, niin saamme kaikki tiedot ongelmasta. Tämä kuulostaa yksinkertaiselta, mutta nämä kaksi työkalua nimeävät tunnisteet eri tavalla, ja joissakin mittareissa ei ole lainkaan metatietotunnisteita. Kube Eagle tekee kaiken itse ja paneeli näyttää tältä:
Onnistuimme ratkaisemaan monia ongelmia resurssien kanssa ja säästämään laitteita:
- Jotkut kehittäjät eivät tienneet kuinka paljon resursseja mikropalvelut tarvitsevat (tai eivät yksinkertaisesti vaivautuneet). Emme voineet löytää vääriä resurssipyyntöjä - tätä varten meidän on tiedettävä kulutus sekä pyynnöt ja rajat. Nyt he näkevät Prometheus-mittarit, valvovat todellista käyttöä ja säätävät pyyntöjä ja rajoja.
- JVM-sovellukset vievät niin paljon RAM-muistia kuin pystyvät käsittelemään. Roskakeräin vapauttaa muistia vain, kun yli 75 % on käytössä. Ja koska useimmissa palveluissa on purskettava muisti, JVM on aina käyttänyt sitä. Siksi kaikki nämä Java-palvelut söivät paljon enemmän RAM-muistia kuin odotettiin.
- Jotkut sovellukset vaativat liikaa muistia, eikä Kubernetes-skedoija antanut näitä solmuja muille sovelluksille, vaikka itse asiassa ne olivat vapaampia kuin muut solmut. Yksi kehittäjä lisäsi vahingossa ylimääräisen numeron pyyntöön ja nappasi suuren palan RAM-muistia: 20 Gt 2:n sijaan. Kukaan ei huomannut. Sovelluksella oli 3 kopiota, joten se vaikutti jopa 3 solmuun.
- Otimme käyttöön resurssirajoitukset, ajoitimme podit oikeilla pyynnöillä ja saimme ihanteellisen tasapainon laitteiston käyttöön kaikissa solmuissa. Pari solmua olisi voitu sulkea kokonaan. Ja sitten näimme, että meillä oli väärät koneet (CPU-suuntautunut, ei muistisuuntautunut). Muutimme tyyppiä ja poistimme useita muita solmuja.
Tulokset
Kun klusterissa on pursottavia resursseja, käytät saatavilla olevaa laitteistoa tehokkaammin, mutta Kubernetes-ajoitusohjelma ajoittaa podit resurssipyyntöjen perusteella, ja tämä on täynnä. Tappaaksesi kaksi kärpästä yhdellä iskulla: ongelmien välttämiseksi ja resurssien täysimääräiseksi käyttämiseksi tarvitaan hyvää seurantaa. Tästä syystä siitä on hyötyä (Prometheus-viejä ja Grafana-kojelauta).
Lähde: will.com