Parimad praktikad Kuberneteses. Ressursside päringute ja piirangute seadistamine

Parimad Kubernetes'i praktikad. Väikeste konteinerite loomine
Kubernetes'i parimad tavad. Kubernetes'i korraldamine nimede ruumi abil
Kubernetes'i parimad praktikad. Kubernetes'i elujõu kontrollimine Readiness ja Liveness testide abil

Iga Kubernetes ressursi jaoks on võimalik seadistada kahte tüüpi nõudeid — Requests ja Limits. Esimene kirjeldab minimaalset nõuet vabade ressurside olemasolu kohta sõlmides, mis on vajalik konteineri või pod'i käivitamiseks, teine ​​piirab jämedalt ressursse, mis on konteinerile kergesti kättesaadavad.

Kui Kubernetes planeerib pod'i, on väga oluline, et konteineritel oleks piisavalt ressursse normaalseks töötamiseks. Kui plaanite suurte rakenduste juurutamist piiratud ressurssidega sõlmisse, võib juhtuda, et see ei tööta, kuna sõlmel on mälu otsas või tal ei ole piisavalt protsessorivõimet. Selles artiklis vaatleme, kuidas saab lahendada arvutusvõimsuse puudumist ressursinõuete ja piirangute abil.

Nõuded Requests ja piirangud Limits on mehhanismid, mida Kubernetes kasutab selliste ressursside haldamiseks nagu protsessor ja mälu. Requests on see, mille alusel konteiner garantii alusel saab nõutud ressursi. Kui konteiner nõuab ressurssi, siis Kubernetes plaanib selle ainult sellele sõlmele, mis suudab seda pakkuda. Piirangud Limits kontrollivad, et konteineri poolt nõutud ressursid ei ületaks kunagi kindlaksmääratud väärtust.

Konteiner võib arvutusvõimet suurendada ainult teatud piirini, pärast mida see piirdub. Vaatame, kuidas see toimib. Seega on olemas kaks ressurssi — protsessor ja mälu. Kubernetes'i planeerija kasutab nende ressursside andmeid, et välja selgitada, kus teie pod'id käivitada. Tüüpiline ressursside spetsifikatsioon pod'i jaoks näeb välja järgmiselt.

Iga konteiner podis saab seada oma kehtestatud nõuded ja piirangud, mis kõik on liituvad. Protsessori ressursid määratakse millikraadi kaupa. Kui teie konteiner vajab käivitamiseks kahte täisprotsessori tuuma, peate seadistama väärtuse 2000m. Kui aga konteiner vajab vaid 1/4 tuuma võimsust, on väärtus 250m. Pidage meeles, et kui määrate protsessoriressursi väärtuse, mis ületab suurima sõlme tuumade arvu, ei kavandata teie poodi üldse. Sarnane olukord tekib, kui teil on pod, mis vajab nelja tuuma, ja Kubernetes klaster koosneb vaid kahest põhisest virtuaalmasinast.

Kui teie rakendus ei ole spetsiaalselt loodud mitme tuuma eeliste kasutamiseks (millele tulevad meelde sellised programmid nagu keerulised teaduslikud arvutused ja andmebaasioperatsioonid), siis parim praktika on seadistada CPU Requests väärtuseks 1 või madalam, käivitades rohkem replikaid skaleeritavuse saavutamiseks. See lahendus annab süsteemile suurema paindlikkuse ja usaldusväärsuse.

Kui rääkida protsessori piirangutest, siis asjad muutuvad huvitavamaks, kuna see on kokku surutav ressurss. Kui teie rakendus hakkab lähenema protsessorivõimsuse piirile, hakkab Kubernetes teie konteinerit aeglustama, kasutades CPU Throttling'ut — protsessori sageduse vähendamist. See tähendab, et protsessor on kunstlikult piiratud, andes rakendusele potentsiaalselt halvemad jõudluskaumad, kuid protsess ei lõpetata ega katkestata.

Mälu ressursid määratakse baitides. Tüüpiliselt mõõdetakse väärtust seadistustes mebibaitide Mib kaupa, kuid võite määrata mistahes väärtuse alates baitidest kuni petabaitideni. Siin kehtib sama olukord nagu protsessoriga — kui määrate mälunõude, mis ületab teie sõlmede mälumahtu, ei kavandata selle pod'i täitmist. Kuid erinevalt protsessoriressurssidest ei ole mälu kokku surutav, kuna pole mingit viisi selle kasutamise piiramise kohaldamiseks. Seetõttu peatatakse konteineri täitmine, kui see ületab talle määratud mälu.

Oluline on meeles pidada, et te ei saa konfigureerida päringuid, mis ületavad ressursside suurust, mida teie sõlmed saavad pakkuda. GKE virtuaalmasinate ühiste ressursside omaduste kohta leiate teavet allpool olevatest linkidest videoaluses.

Ideaalsetes konteineri seadistuste maailmas piisaks vaikeseadistustest, et töövood sujuksid. Kuid reaalne maailm pole selline, inimesed võivad unustada ressursside kasutamise seadistamise või häkkerid seadistavad päringud ja piirangud, mis ületavad infrastruktuuri tegelikke võimalusi. Selliste stsenaariumide vältimiseks saab seadistada ressursside kvooti ResourceQuota ja piirangute vahemikke LimitRange.

Pärast nimede loomist saab neid blokeerida kvotidega. Näiteks kui teil on nimed prod ja dev, kasutatakse mustrit, mille kohaselt on tootmisalustes kvotid üldse puuduvad, samas kui arenduses on kvotid väga ranged. See võimaldab prod-l äkilise liikluse suurenemise korral kogu olemasoleva ressursi ära võtta, blokeerides täielikult dev-i.

Ressursikvoot võib välja näha selline. Selles näites on 4 sektsiooni - need on 4 allolevat koodirida.

Vaadakem igaüht neist. Requests.cpu on maksimaalne kombineeritud protsessoriressursside päringute arv, mis võib tulla kõigilt nimede konteineritelt. Selles näites võivad teil olla 50 konteinerit 10m päringutega, viis konteinerit 100m päringutega või lihtsalt üks konteiner 500m päringuga. Niikaua, kui selle nime ruumi total requests.cpu jääb alla 500m, läheb kõik hästi.

Päritud mälu requests.memory on maksimaalne kombineeritud mälu päringu suurus, mida võivad sisaldada kõik konteinerid nimede ruumis. Nagu eelnevas näites, võite omada 50 konteinerit 2 MiB, viis konteinerit 20 MiB või ühe konteineri 100 MiB, kuni kogu päritud mälu alal on vähem kui 100 mebibaiti.

Limits.cpu on maksimaalne kombineeritud protsessorivõimsuse väärtus, mida saavad kasutada kõik konteinerid nimede ruumis. Seda võib pidada protsessorivõimsuse päringute piiriks.

Lõpuks, limits.memory on maksimaalne kogus üldmälu, mida võivad kasutada kõik konteinerid nimekirjas. See on kogu mälakuude piirang.
Niisiis, vaikimisi töötavad konteinerid Kubernetes'i klastris piiramatute arvutusressurssidega. Ressursikvootide abil saavad klassi administraatorid piirata ressursikasutust ja nende loomist nimekirjade põhjal. Nimekirjas võib podi või konteineri moodul tarbida nii palju CPU ja mälu võimsust, kui on määratud nimekirja ressursside kvoodis. Siiski on mure, et üks pod või konteiner võib monopoliseerida kõik olemasolevad ressursid. Selle olukorra vältimiseks kasutatakse piiride vahemikku limit Range - ressursside jaotamise piirangute poliitikat (podide või konteinerite jaoks) nimekirjas.

Piiride vahemik annab piirangud, mis võivad:

• tagada minimaalne ja maksimaalne arvutusressursside kasutamine iga mooduli või konteineri jaoks nimekirjas;
• sunniviisiliselt täita minimaalne ja maksimaalne salvestusmahu päring Storage Request iga PersistentVolumeClaim jaoks nimekirjas;
• sunniviisiliselt määrata suhe päringu Request ja piirangu Limit vahel ressursi nimekirjas;
• seada Requests/Limits vaikeväärtused arvutusressurssidele nimekirjas ja automaatselt rakendada neid konteinerites töö ajal.

N niisiis, võite luua piiride vahemiku oma nimekirjas. Erinevalt kvoodist, mis katab kogu nimekirja, kasutatakse Limit Range individuaalsetele konteineritele. See võib takistada kasutajate loomast täiesti väikeseid või vastupidi, hiiglaslikke konteinerite nimekirjas. Piiride vahemik Limit Range võib välja näha selline.

Nagu eelnevas juhul, on siin neli sektsiooni. Vaatame igaüht lähemalt.
Default sektsioonis on määratud vaikimisi piirangud konteinerile podis. Kui määrate need väärtused piiride vahemikus, siis kõik konteinerid, mille jaoks neid väärtusi pole selgelt määratud, järgivad vaikimisi väärtusi.

Vaikimisi on lõigul defaultRequest määratud konteinerite vaikeküsimused pod'is. Jällegi, kui seadistate need väärtused piirmäärade vahemikku, kasutatakse vaikimisi neid väärtusi kõigi konteinerite puhul, millele neid parameetreid selgelt ei määratud.

Lõigus max on määratud maksimaalsed piirangud, mida saab seada konteinerile pod'is. Lõigu default ja konteineri piirangud ei tohi olla kõrgemad kui see piir. Oluline on märkida, et kui on seadistatud max väärtus ja lõigul default puudub, siis maksimaalne väärtus muutub vaikimisi väärtuseks.

Lõigus min on määratud minimaalseteks päringuteks, mida saab seada konteinerile pod'is. Sellega seoses ei tohi lõigus default ja konteineri päringud olla madalamad kui see piir.

Jällegi, on oluline märkida, et kui see väärtus on seadistatud, kuid väärtus default puudub, siis minimaalne väärtus muutub vaikimisi päringuks.

Kokkuvõttes kasutab Kubernetes ressursside päringuid teie töökoormuste täitmiseks. Et saaksite oma konteinerid õigesti seadistada, on äärmiselt oluline mõista, kuidas see töötab. Oletame, et soovite käivitada mitmeid mooduleid oma klastri sees. Oletades, et pod'i spetsifikatsioonid on kehtivad, kasutatakse Kubernetesis tsüklitöötlust sõlme valimiseks töökoormuse täitmiseks.

Kubernetes kontrollib, kas sõlmel Node 1 on piisavalt ressursse konteinerite päringute täitmiseks, ja kui ei, siis läheb järgmisele sõlmele. Kui aga ükski sõlm süsteemis ei suuda päringutele vastata, lähevad pod'id ooteseisundisse Pending state. Google Kubernetes Engine'i automaatse sõlmede skaala funktsiooniga suudab GKE automaatselt tuvastada ooteseisundi ja luua veel mõned lisasõlmed.

Kui hiljem tekib sõlmede ülejääk, siis automaatse skaala funktsioon vähendab nende arvu, et säästa raha. Just seetõttu plaanib Kubernetes pod'e päringute alusel. Kuid piir võib olla suurem kui päringud ja mõnel juhul võib sõlm tegelikult ressursid ära kasutada. Me nimetame seda seisundit ülekompenseerimise seisundiks.

Nagu ma juba ütlesin, kui jutt on protsessorist, hakkab Kubernetes piirama pod'e. Iga pod saab täpselt nii palju, kui ta on palunud, kuid kui ta ei saavuta limiiti, siis rakendatakse tõkestamist.

Mäluressursside osas peab Kubernetes tegema otsuseid selle kohta, millised pod'id eemaldada ja millised säilitada, kuni te vabastate süsteemiressursse, vastasel juhul laguneb kogu süsteem.

Kujutame ette olukorda, kus teil on masin, mis on ammendanud mälu limiidi – kuidas toimib sel juhul Kubernetes?

Kubernetes otsib pod'e, mis kasutavad rohkem ressursse, kui nad on palunud. Nii et kui teie konteineritel pole üldse palveid, tähendab see, et nad kasutavad vaikimisi rohkem, kui nad palusid, lihtsalt sellepärast, et nad ei ole üldse midagi palunud! Sellised konteinerid on peamised kandidaadid sulgemiseks. Järgmistena on kandidaadid konteinerid, mis on rahuldanud kõik oma palved, kuid on endiselt allpool maksimaalset limiiti.

Seega, kui Kubernetes leiab mitu pod'i, mis on ületanud oma palveparameetreid, sorteerib ta need prioriteedi järgi ja seejärel eemaldab madalaima prioritiseerumisega moodulid. Kui kõik moodulid on sama prioriteediga, lõpetab Kubernetes töö nende pod'ide puhul, mis on oma palveid rohkem ületanud kui teised pod'id.

Väga harvadel juhtudel võib Kubernetes katkestada pod'e, mis on endiselt oma palvete piires. See võib juhtuda, kui sellised süsteemi kriitilised komponendid nagu Kubeleti agent või Docker hakkavad tarbima rohkem ressursse, kui neile on ette nähtud.
Seega, väikeste ettevõtete algusfaasis võib Kubernetes klaster suurepäraselt töötada ilma ressursipäringute ja piirangute seadmiseks, kuid kui teie meeskonnad ja projektid hakkavad kasvama, võite sattuda sellistes valdkondades probleemidesse. Ressursipäringute ja piirangute lisamine teie moodulitesse ja nimedesse nõuab väga vähe täiendavaid jõupingutusi ja võib päästa teid paljudest muredest.

Kubernetes parimad praktikad. Õige katkestamine Terminate

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level 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 jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com