Kubernetesi parimad praktikad. Ressursside päringute ja piirangute seadistamine

Kubernetesi parimad praktikad. Väikeste konteinerite loomine
Kubernetesi parimad praktikad. Kubernetesi korraldamine nimespetsiifiliste ruumide abil
Kubernetesi parimad praktikad. Kubernetesi elujõudluse kontrollimine Readiness ja Liveness testide abil

Iga Kubernetesi ressursi jaoks on võimalik seadistada kahte tüüpi nõudeid — Requests ja Limits. Esimene kirjeldab minimaalseid nõudeid vabade ressursside olemasolule sõlmes, mis on vajalik konteineri või podi käivitamiseks, teine ​​piirab rangelt neid ressursse, mis on konteinerile kättevõetavad.

Kui Kubernetes planeerib podi, on väga oluline, et konteineritel oleks piisavalt ressursse normaalseks tööks. Kui plaanite suure rakenduse juurutamist sõlmes, mille ressursside maht on piiratud, on täiesti võimalik, et rakendus ei tööta, kuna sõlmest lõppeb mälu või tal puuduvad protsessorivõimsus. Selles artiklis vaatleme, kuidas saab lahendada arvutusvõimsuse puudujäägi probleeme ressursside päringute ja piirangute kaudu.

Requests ja Limits on mehhanismid, mida Kubernetes kasutab selliste ressursside, nagu näiteks protsessor ja mälu, haldamiseks. Requests tagab, et konteiner saab garanteeritud koguse küsitud ressurssi. Kui konteiner küsib ressursse, plaanib Kubernetes selle ainult sellele sõlmele, mis suudab seda pakkuda. Limits piirab, et konteineri küsitud ressursid ei ületaks kunagi kindlaksmääratud väärtust.

Konteiner võib suurendada oma arvutusvõimet kuni teatud piirini, pärast mida see piirdub. Vaatame, kuidas see toimib. On olemas kaks tüüpi ressursse — protsessor ja mälu. Kubernetes'i planeerija kasutab nende ressursside andmeid, et selgitada välja, kus teie podid käivitada. Tüüpiline ressursside spetsifikatsioon podi jaoks näeb välja järgmiselt.

Igas podis saab konteiner seadistada omaenda nõudmised ja piirangud, ning kõik need on kumulatiivsed. Kõigepealt määratakse protsessorivõimsus millikohtades. Kui teie konteiner vajab käitamiseks kahe täis tuuma jõudlust, peate seadistama väärtuse 2000m. Kui konteiner vajab ainult 1/4 tuuma jõudlust, on väärtus 250m. Pidage meeles, et kui määrate protsessorivõimsuse väärtuse, mis ületab suurima sõlme tuumade arvu, siis teie podi ei plaanita üldse. Sama juhtub, kui teil on pod, mis vajab nelja tuuma, samas kui Kubernetes klaster koosneb vaid kahest põhilisest virtuaalmasinast.

Ainult siis, kui teie rakendus ei ole mõeldud mitme tuuma eeliste maksimaalseks kasutamiseks (silmas peetakse selliseid programme nagu keerulised teaduslikud arvutused ja andmebaasi operatsioonid), on parim praktika seadistada CPU nõudmised väärtusele 1 või madalam ja seejärel käivitada rohkem replikaid skaleeritavuse saavutamiseks. See lahendus annab süsteemile suurema paindlikkuse ja usaldusväärsuse.

Kuna tegemist on CPU piirangutega, muutub olukord huvitavamaks, kuna see loetakse kokkusurutavaks ressursiks. Kui teie rakendus hakkab lähenema protsessori võimsuse piirile, hakkab Kubernetes teie konteinerit aeglustama, kasutades CPU Throttling'ut — protsessori sageduse vähendamist. See tähendab, et protsessorit piiratakse kunstlikult, andes rakendusele potentsiaalselt halvemad tulemused, kuid protsess ei peatuks ega oleks eemaldatud.

Mäluressursid määratakse baitides. Tüüpiliselt mõõdetakse seadistustes väärtust mebibaitides (Mib), kuid saate määrata mis tahes väärtuse alates baitidest kuni petabaitideni. Siin kehtib sama olukord nagu CPU puhul — kui esitate mäluhulga taotluse, mis ületab sõlmede mälu, ei planeerita selle pod'i täitmist. Kuid erinevalt protsessori ressursidest ei ole mälu kokkusurutav, kuna pole viisi selle kasutamise piiramise jaoks. Seetõttu peatatakse konteineri täitmine, kui see ületab sellele määratud mälu.

Oluline on meeles pidada, et te ei saa seadistada päringuid, mis ületavad teie sõlmede pakutavaid ressursimahu. GKE virtuaalmasinate ühiste ressursside omadused on saadaval allpool olevates linkides, mis asuvad selle video all.

Ideaalmaailmas peaks vaikesätete järgi piisama konteinerite seadetest, et tööprotsessid sujuksid probleemideta. Kuid tõeline maailm ei ole selline, inimesed võivad kergesti unustada ressursside kasutamise seadistada või häkkerid võivad seada päringud ja piirangud, mis ületavad infrastruktuuri reaalseid võimalusi. Selliste stsenaariumite vältimiseks saab seadistada ressursside kvote ResourceQuota ja piirangute vahemikke LimitRange.

Pärast nimespetsiifiliste ruumide loomist saab neid kvotade abil piirata. Näiteks, kui teil on prod ja dev nimede ruumid, kasutatakse mustrit, kus tootmisruumid ei ole üldse kvoteeritud, samas kui arendusrühmal on väga ranged kvotad. See võimaldab tootmisruumile teha järsu liiklusetõusu korral kõik olemasolevad ressursid enda kasutusse, blokeerides täielikult arendusrühma.

Ressursskvota võib välja näha selline. Antud näites on 4 jaotust – need on 4 alumist koodirida.

Vaadakem neid kõiki. Requests.cpu on maksimaalne kombinatsiooniliste protsessorivõimsuse päringute arv, mis võivad tulla kõigist konteineritest nimede ruumis. Antud näites võivad teil olla 50 konteinerit, mille päringud on 10m, viis konteinerit, mille päringud on 100m, või lihtsalt üks konteiner, mille päring on 500m. Niikaua kui antud nimede ruumi requests.cpu kogus on alla 500m, on kõik korras.

Küsitav mälu requests.memory on maksimaalne kombinatsiooniliste mälu päringute suurus, mis võivad olla kõigil konteineritel nimede ruumis. Nagu eelmises näites, võite omada 50 konteinerit, millel on 2 MiB, viis konteinerit, millel on 20 MiB, või ühe konteineri, millel on 100 MiB, kuni antud nimede ruumi küsitav mälu jääb alla 100 mebibaiti.

limits.cpu — see on maksimaalne kombineeritud protsessori võimsuse väärtus, mida kõik nimespetsiifilised konteinerid võivad kasutada. Seda võib pidada protsessori võimsuse taotlemise piiriks.

Lõpuks, limits.memory – see on maksimaalne kogus üldmälu, mida kõik konteinerid nimespetsiifilises ruumis võivad kasutada. See on mälu taotlemise kogupiirang.
Seega töötavad Kubernetes'i klastris konteinerid vaikimisi piiranguteta arvutusressurssidega. Ressursside kvootide abil saavad klastrihaldurid piirata ressursikasutust ja nende loomist nimespetsiifiliste ruumide põhjal. Nimespetsiifilises ruumis võib pod'i või konteineri modulaarne osa tarbida nii palju CPU- ja mälunõudlust, kui on määratud nimespetsiifilise ruumi ressursside kvoodiga. Siiski on mure, et üks pod või konteiner võib monopoliseerida kõik olemasolevad ressursid. Selle olukorra vältimiseks kasutatakse limiidivahemikku, mis on ressursijaotuse piirangupoliitika (pod'ide või konteinerite jaoks) nimespetsiifilises ruumis.

Limiitide vahemik annab piirangud, mis võivad:

• tagada minimaalne ja maksimaalne arvutusressursside kasutamine iga mooduli või konteineri jaoks nimeses.
• sundida täitma minimaalset ja maksimaalset Starage Request'i taotlust iga PersistentVolumeClaim'i jaoks nimeses.
• sundida seadma suhet Request'i ja Limit'i vahel ressursi jaoks nimeses.
• seada vaikimisi Requests/Limits arvutusressursside jaoks nimeses ja automaatselt neid konteineritesse rakendada töö ajal.

Nii et saate oma nimeses luua piirangute vahemiku. Erinevalt kvoodist, mis kehtib kogu nimes, kasutatakse Limit Range'i eraldi konteinerite jaoks. See võib takistada kasutajate loomast ülikitsaid või vastupidi, hiiglaslikke konteinerite nimeses. Limit Range võib välja näha nii.

Nagu eelnevas, on siin võimalik jagada 4 osa. Vaatame igaüht lähemalt.
Määratletud jaotises default on konteineri vaikeseaded podis. Kui määrate need väärtused lubatud vahemikus, siis kõik konteinerid, mille jaoks neid väärtusi pole selgelt määratud, järgivad vaikeseadeid.

Määratletud jaotises defaultRequest on podis konteineri vaikekomplektid. Kui määrate need väärtused lubatud vahemikus, siis kõik konteinerid, mille jaoks neid sätteid ei ole selgelt määratud, kasutavad vaikeseadeid.

Määratletud jaotises max on määratud maksimaalsed piirangud, mida saab konteineri jaoks podis seadistada. Default ja konteineri piirangud ei saa olla kõrgemal sellest piirist. Oluline on märkida, et kui on määratud max väärtus ja jaotis default puudub, siis maksimaalne väärtus muutub vaikeseendeks.

Määratletud jaotises min on määratud konteineri minimaalset arvamust, mida saab podis seadistada. Samal ajal ei saa default väärtused ja konteineri arvamused olla madalamad kui see piir.

Oluline on märkida, et kui see väärtus on määratud, on vaikimisi väärtus - ei, siis minimaalne väärtus muutub vaikimisi päringuks.

Lõppkokkuvõttes kasutatakse neid ressursipäringuid Kubernetes'i planeerija teie töökoormuste täitmiseks. Et saaksite oma konteinerid õigesti seadistada, on väga oluline mõista, kuidas see töötab. Oletame, et soovite käivitada oma klastris mitu moodulit. Kui pod'ide spetsifikatsioonid on kehtivad, siis kasutatakse Kubernetes'i ajakavas ringikujulist koormuse tasakaalustamist sõlme valimiseks, kus töökoormust täita.

Kubernetes kontrollib, kas Node 1 sõlmel on piisavalt ressursse pod'i konteinerite päringute täitmiseks ja kui ei ole, siis liikuda järgmisele sõlmele. Kui aga ükski süsteemi sõlm ei suuda päringutele vastata, siis lähevad pod'id ooteolekusse Pending state. Google Kubernetes Engine'i funktsioonide, nagu näiteks sõlmede automaatne skaleerimine, abil suudab GKE automaatselt tuvastada ooteoleku ja luua veel mõned lisasõlmed.

Kui sõlmedel tekib ülemäärane maht, vähendab automaatne skaleerimine nende arvu, et säästa raha. Just seetõttu planeerib Kubernetes pod'e nõudmiste põhjal. Siiski võib piir olla suurem kui nõudmised ning mõnel juhul võib sõlm tegelikult ressursid ammendada. Seda olukorda nimetatakse ülekuuluvaks olekuks.

Nagu ma juba mainisin, kui tegemist on protsessoriga, hakkab Kubernetes pod'e piirama. Iga pod saab just nii palju, kui ta palus, kuid kui ta ei saavuta limiiti, siis algab piiritlemine.

Mäluressursside osas peab Kubernetes langetama otsuseid, milliseid pod'e eemaldada ja milliseid säilitada, kuni vabastate süsteemi ressursid, vastasel juhul võib kogu süsteem kokku variseda.

Kujutame ette stsenaariumi, kus teil on masin, mille mälu on ammendatud – kuidas käitub sel juhul Kubernetes?

Kubernetes otsib pod'e, mis kasutavad rohkem ressursse, kui nad on taotlenud. Seega, kui teie konteineritel ei ole üldse Requests'e, tähendab see, et vaikimisi kasutavad nad rohkem kui palusid, kuna nad ei ole midagi taotlenud! Sellised konteinerid on peamised kandidaadid välja lülitamiseks. Järgmised kandidaadid on konteinerid, mis on rahuldanud kõik oma taotlused, kuid on endiselt allpool maksimaalset piiri.

Niisiis, kui Kubernetes leiab mitu pod'i, mis on oma taotluste parameetreid ületanud, sorteerib ta need prioriteedi alusel ja seejärel eemaldab madalaima prioriteediga moodulid. Kui kõik moodulid on sama prioriteediga, lõpetab Kubernetes nendel pod'idel töötamise, mis on oma taotlusi rohkem ületanud kui teised pod'id.

Väga harvadel juhtudel võib Kubernetes katkestada pod'e, mis on endiselt oma taotluste piirides. See võib juhtuda siis, kui sellised süsteemi kriitilised komponendid nagu Kubeleti agent või Docker hakkavad tarbima rohkem ressursse, kui neile on reserveeritud.
Seega, väikeste ettevõtete algusfaasis võib Kubernetes klaster suurepäraselt töötada ilma ressursside nõudmiste ja piiranguteta, kuid kui teie meeskonnad ja projektid hakkavad kasvama, võite riskida probleemide tekkimisega. Nõudmiste ja piirangute lisamine teie moodulitele ja ruumidele nõuab vaid veidi lisatööd ja võib päästa teid paljusid muresid.

Kubernetes parimad praktikad. Korralik lõpetamine Terminate

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com