Iga Kubernetese ressursi jaoks saate konfigureerida kahte tüüpi nõudeid – taotlused ja piirangud. Esimene kirjeldab konteineri või kausta käitamiseks vajalike tasuta sõlmeressursside saadavuse miinimumnõudeid, teine piirab rangelt konteineri jaoks saadaolevaid ressursse.
Kui Kubernetes ajastab kaustasid, on väga oluline, et konteineritel oleks nõuetekohaseks toimimiseks piisavalt ressursse. Kui plaanite ressursipiiranguga sõlmes juurutada suurt rakendust, on võimalik, et see ei tööta, kuna sõlme mälu hakkab otsa saama või protsessori võimsus hakkab otsa saama. Selles artiklis vaatleme, kuidas saate ressursitaotluste ja piirangute abil lahendada arvutusvõimsuse puudujääke.
Taotlused ja piirangud on mehhanismid, mida Kubernetes kasutab selliste ressursside haldamiseks nagu protsessor ja mälu. Päringud tagavad, et konteiner saab nõutud ressursi. Kui konteiner taotleb ressurssi, ajastab Kubernetes selle ainult sõlmes, mis suudab seda pakkuda. Piirab kontrolli, et konteineri taotletud ressursid ei ületaks kunagi teatud väärtust.
Konteiner saab oma arvutusvõimsust suurendada ainult teatud piirini, pärast mida see piiratakse. Vaatame, kuidas see toimib. Seega on kahte tüüpi ressursse - protsessor ja mälu. Kubernetese ajakava kasutab nende ressursside andmeid, et välja selgitada, kus oma kaustasid käitada. Podi tüüpiline ressursi spetsifikatsioon näeb välja selline.
Iga kausta konteiner võib seada oma päringud ja piirangud, see kõik on aditiivne. Protsessori ressursid on määratletud millituumades. Kui teie konteiner vajab käitamiseks kahte täissüdamikku, määrate väärtuseks 2000 m. Kui konteiner vajab ainult 1/4 südamiku võimsust, on väärtuseks 250 m. Pidage meeles, et kui määrate CPU ressursi väärtuse, mis on suurem kui suurima sõlme tuumade arv, siis teie pod ei käivitu üldse. Sarnane olukord tekib siis, kui teil on Pod, mis vajab nelja tuuma ja Kubernetese klaster koosneb ainult kahest peamisest virtuaalmasinast.
Kui teie rakendus pole spetsiaalselt loodud mitme tuuma ärakasutamiseks (tulevad meelde sellised programmid nagu keerukad teaduslikud andmetöötlused ja andmebaasitoimingud), on parim tava määrata CPU Requests väärtuseks 1 või madalam ja seejärel käivitada skaleeritavusele rohkem koopiaid. See lahendus annab süsteemile suurema paindlikkuse ja töökindluse.
Kui rääkida protsessori piirangutest, muutuvad asjad huvitavamaks, kuna seda peetakse tihendatavaks ressursiks. Kui teie rakendus hakkab lähenema protsessori võimsuse piirangule, hakkab Kubernetes teie konteinerit CPU Throttlingi abil aeglustama, vähendades protsessori sagedust. See tähendab, et protsessorit piiratakse kunstlikult, mis annab rakendusele potentsiaalselt halvema jõudluse, kuid protsessi ei lõpetata ega eemaldata.
Mälu ressursid on määratletud baitides. Tavaliselt mõõdetakse seadete väärtust mebibaitides Mib, kuid saate määrata mis tahes väärtuse, alates baitidest kuni petabaitideni. Siin kehtib sama olukord, mis protsessori puhul – kui esitate oma sõlmede mälumahust suurema mälumahu taotluse, ei plaanita seda podi täitma. Kuid erinevalt protsessori ressurssidest ei tihendata mälu, kuna selle kasutamist pole võimalik piirata. Seetõttu peatatakse konteineri täitmine niipea, kui see ületab sellele eraldatud mälu.
Oluline on meeles pidada, et te ei saa konfigureerida taotlusi, mis ületavad teie sõlmede pakutavaid ressursse. GKE virtuaalmasinate jagatud ressursside spetsifikatsioonid leiate selle video all olevatelt linkidelt.
Ideaalses maailmas piisaks konteineri vaikesätetest, et töövood toimiksid sujuvalt. Kuid tegelik maailm ei ole selline, inimesed võivad kergesti unustada ressursside kasutamise seadistamise või häkkerid seavad päringuid ja piiranguid, mis ületavad infrastruktuuri tegelikke võimalusi. Selliste stsenaariumide esinemise vältimiseks saate konfigureerida ressursikvoodid ResourceQuota ja LimitRange.
Kui nimeruum on loodud, saab selle kvootide abil blokeerida. Näiteks kui teil on prod ja dev nimeruumid, on muster selline, et tootmiskvoote pole üldse ja arenduskvoodid on väga ranged. See võimaldab prodil liikluse järsu tõusu korral üle võtta kogu saadaoleva ressursi, blokeerides arendaja täielikult.
Ressursikvoot võib välja näha selline. Selles näites on 4 jaotist – need on 4 alumist koodirida.
Vaatame igaüht neist. Requests.cpu on maksimaalne kombineeritud protsessori päringute arv, mis võivad pärineda kõigist nimeruumi konteineritest. Selles näites võib teil olla 50 konteinerit 10 m päringutega, viis konteinerit 100 m päringutega või ainult üks konteiner 500 m päringutega. Kuni antud nimeruumi päringu.cpu koguarv on alla 500 m, on kõik hästi.
Mälu nõutud päringud.mälu on kombineeritud mälupäringute maksimaalne arv, mis võib olla kõikidel nimeruumi konteineritel. Nagu eelmisel juhul, võib teil olla 50 2 mib konteinerit, viis 20 mib konteinerit või üks 100 mib konteiner, kui nimeruumis nõutud mälu kogumaht on alla 100 mebibaidi.
Limits.cpu on maksimaalne kombineeritud protsessori võimsus, mida kõik nimeruumi konteinerid saavad kasutada. Seda võime pidada protsessori võimsuse taotluste piiriks.
Lõpuks on limits.memory maksimaalne jagatud mälu maht, mida kõik nimeruumi konteinerid saavad kasutada. See on kogu mälutaotluste piirang.
Seega töötavad Kubernetese klastri konteinerid vaikimisi piiramatute arvutusressurssidega. Ressursikvootide abil saavad klastri administraatorid piirata ressursside tarbimist ja ressursside loomist nimeruumi alusel. Nimeruumis võib pod või konteiner tarbida nii palju protsessori võimsust ja mälu, mis on määratud nimeruumi ressursikvoodiga. Siiski on mure, et üks kaun või konteiner võib monopoliseerida kõik olemasolevad ressursid. Selle olukorra vältimiseks kasutatakse piiranguvahemikku – poliitikat, mis piirab nimeruumis ressursside jaotamist (kastide või konteinerite jaoks).
Piiranguvahemik pakub piiranguid, mis võivad:
- Tagada iga nimeruumi mooduli või konteineri arvutusressursside minimaalne ja maksimaalne kasutamine;
- jõustada minimaalse ja maksimaalse Starage Request salvestuspäringud iga nimeruumi PersistentVolumeClaim jaoks;
- jõustada seos nimeruumis oleva ressursi taotluse ja piirangu vahel;
- määrake nimeruumis arvutusressurssidele vaikenõuded/piirangud ja sisestage need käitusajal automaatselt konteineritesse.
Nii saate luua oma nimeruumis piiranguvahemiku. Erinevalt kvoodist, mis kehtib kogu nimeruumi kohta, kasutatakse üksikute konteinerite jaoks piirvahemikku. See võib takistada kasutajatel nimeruumis väga pisikesi või, vastupidi, hiiglaslikke konteinereid looma. Limit Range võib välja näha selline.
Nagu ka eelmisel juhul, saab siin eristada 4 sektsiooni. Vaatame igaüks neist.
Vaikejaotis määrab kaustas oleva konteineri vaikepiirangud. Kui määrate need väärtused äärmuslikule vahemikule, järgivad kõik konteinerid, mille jaoks neid väärtusi pole otseselt määratud, vaikeväärtusi.
Vaikimisi päringu jaotis defaultRequest konfigureerib kaustas oleva konteineri vaikepäringud. Jällegi, kui määrate need väärtused äärmuslikule vahemikule, siis kõik konteinerid, mis neid valikuid otseselt ei määra, kasutavad vaikeväärtusi.
Jaotis Max määrab maksimaalsed piirangud, mida saab kaustas olevale konteinerile määrata. Vaikejaotise väärtusi ja konteineripiiranguid ei saa seada sellest limiidist kõrgemale. Oluline on märkida, et kui väärtuseks on seatud max ja vaikimisi jaotist pole, saab vaikeväärtuseks maksimaalne väärtus.
Minimaalne jaotis määrab minimaalsed taotlused, mida saab kaustas olevale konteinerile määrata. Siiski ei saa vaikejaotises olevaid väärtusi ja konteineri päringuid seada allapoole seda piiri.
Jällegi on oluline märkida, et kui see väärtus on määratud, vaikimisi mitte, siis saab vaikeviibaks minimaalne väärtus.
Neid ressursipäringuid kasutab lõpuks Kubernetese planeerija teie töökoormuste täitmiseks. Konteinerite õigeks konfigureerimiseks on väga oluline mõista, kuidas see töötab. Oletame, et soovite oma klastris käitada mitut podi. Eeldusel, et kausta spetsifikatsioonid on kehtivad, kasutab Kubernetese ajakava töökoormuse käitamiseks sõlme valimiseks ümmarguse tasakaalustamise meetodit.
Kubernetes kontrollib, kas sõlmel 1 on pod-konteinerite taotluste täitmiseks piisavalt ressursse, ja kui ei, liigub see järgmisesse sõlme. Kui ükski süsteemi sõlmedest ei suuda taotlusi rahuldada, lähevad kaustad ootelolekusse. Kasutades Google Kubernetese mootori funktsioone, nagu sõlmede automaatne skaleerimine, saab GKE automaatselt tuvastada ooteoleku ja luua veel mitu täiendavat sõlme.
Kui teil hiljem sõlmede maht otsa saab, vähendab automaatne skaleerimine teie raha säästmiseks sõlmede arvu. Seetõttu ajastab Kubernetes kaunad päringu alusel. Limiit võib aga olla taotlustest suurem ja mõnel juhul võivad sõlmel ressursid tegelikult otsa saada. Me nimetame seda seisundit ülekohustuse olekuks.
Nagu ma ütlesin, hakkab Kubernetes protsessori osas piirama kaunasid. Iga pod saab nii palju, kui ta taotles, kuid kui see ei jõua piirini, hakatakse rakendama drosselit.
Mäluressursside osas on Kubernetes sunnitud tegema otsuseid selle kohta, millised kaustad kustutada ja millised alles jätta, kuni vabastate süsteemiressursse või kogu süsteem jookseb kokku.
Kujutagem ette stsenaariumi, kus teie masinal hakkab mälu tühjaks saama – kuidas Kubernetes sellega hakkama saaks?
Kubernetes otsib kaunasid, mis kasutavad taotletust rohkem ressursse. Nii et kui teie konteineritel pole üldse taotlusi, tähendab see, et nad ei kasuta enam, kui nad küsisid, lihtsalt sellepärast, et nad ei küsinud üldse midagi! Sellised konteinerid muutuvad peamisteks sulgemiskandidaatideks. Järgmised kandidaadid on konteinerid, mis on rahuldanud kõik nende soovid, kuid jäävad siiski alla maksimumlimiidi.
Nii et kui Kubernetes leiab mitu kausta, mis on ületanud nende päringu parameetreid, sorteerib see need prioriteedi järgi ja eemaldab seejärel madalaima prioriteediga kaustad. Kui kõigil kaustadel on sama prioriteet, lõpetab Kubernetes need kaustad, mis ületavad nende taotlusi rohkem kui teised kaustad.
Väga harvadel juhtudel võib Kubernetes katkestada kaunad, mis on endiselt nende taotluste ulatuses. See võib juhtuda siis, kui kriitilised süsteemikomponendid, nagu Kubeleti agent või Docker, hakkavad tarbima rohkem ressursse, kui neile oli reserveeritud.
Nii et väikeettevõtete algfaasis võib Kubernetese klaster hästi töötada ilma ressursitaotlusi ja piiranguid seadmata, kuid kui teie meeskonnad ja projektid hakkavad kasvama, on teil oht selles valdkonnas probleemidesse sattuda. Moodulitele ja nimeruumidele päringute ja piirangute lisamine nõuab väga vähe lisapingutusi ja võib säästa palju vaeva.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com