Voit määrittää kullekin Kubernetes-resurssille kahdentyyppisiä vaatimuksia - pyynnöt ja rajoitukset. Ensimmäinen kuvaa vähimmäisvaatimukset ilmaisten solmuresurssien saatavuudelle, jotka ovat välttämättömiä kontin tai ryhmittymän suorittamiseksi, ja toinen rajoittaa tiukasti säilön käytettävissä olevia resursseja.
Kun Kubernetes ajoittaa podeja, on erittäin tärkeää, että säilöillä on riittävästi resursseja toimiakseen kunnolla. Jos aiot ottaa käyttöön suuren sovelluksen resurssirajoitteisessa solmussa, on mahdollista, että se ei käynnisty, koska solmun muisti on vähissä tai suorittimen teho loppumassa. Tässä artikkelissa tarkastellaan, kuinka voit ratkaista laskentatehon puutteen käyttämällä resurssipyyntöjä ja rajoituksia.
Pyynnöt ja rajoitukset ovat mekanismeja, joita Kubernetes käyttää resurssien, kuten suorittimen ja muistin, hallintaan. Pyynnöt varmistavat, että säilö vastaanottaa pyydetyn resurssin. Jos säilö pyytää resurssia, Kubernetes ajoittaa sen vain solmulle, joka voi tarjota sen. Rajoittaa, että säilön pyytämät resurssit eivät koskaan ylitä tiettyä arvoa.
Säiliö voi kasvattaa laskentatehoaan vain tiettyyn rajaan asti, jonka jälkeen sitä rajoitetaan. Katsotaan kuinka se toimii. Joten on olemassa kahdenlaisia resursseja - prosessori ja muisti. Kubernetes-ajastin käyttää näitä resursseja koskevia tietoja selvittääkseen, missä podit ajaa. Tyypillinen resurssimääritys podille näyttää tältä.
Jokainen säiliön säiliö voi asettaa omat kyselynsä ja rajoituksensa, se kaikki on additiivinen. Prosessoriresurssit määritellään milliytimissä. Jos konttisi tarvitsee kaksi täyttä ydintä toimiakseen, aseta arvoksi 2000 m. Jos kontti tarvitsee vain 1/4 ytimen tehoa, arvoksi tulee 250m. Muista, että jos määrität prosessoriresurssiarvon, joka on suurempi kuin suurimman solmun ytimien lukumäärä, podia ei ajoiteta käynnistymään ollenkaan. Samanlainen tilanne tapahtuu, jos sinulla on Pod, joka tarvitsee neljä ydintä, ja Kubernetes-klusteri koostuu vain kahdesta virtuaalikoneesta.
Ellei sovellustasi ole suunniteltu erityisesti hyödyntämään useita ytimiä (tulevat mieleen ohjelmat, kuten monimutkainen tieteellinen laskeminen ja tietokantatoiminnot), paras käytäntö on asettaa CPU Requests -arvoksi 1 tai pienempi ja suorittaa sitten lisää kopioita skaalautuvuuden parantamiseksi. Tämä ratkaisu lisää järjestelmään joustavuutta ja luotettavuutta.
Mitä tulee suorittimen rajoituksiin, asiat muuttuvat mielenkiintoisemmiksi, koska sitä pidetään pakattavana resurssina. Jos sovelluksesi alkaa lähestyä prosessorin tehorajaa, Kubernetes alkaa hidastaa konttia CPU Throttling -toiminnolla, mikä vähentää prosessorin taajuutta. Tämä tarkoittaa, että prosessoria kuristetaan keinotekoisesti, mikä heikentää sovelluksen suorituskykyä, mutta prosessia ei lopeteta tai poisteta.
Muistiresurssit määritellään tavuina. Yleensä asetusten arvo mitataan mebitavuina Mib, mutta voit asettaa minkä tahansa arvon tavuista petatavuihin. Sama tilanne pätee tässä kuin CPU:ssa - jos sijoitat pyynnön suuremmalle muistimäärälle kuin solmujen muistimäärä, kyseistä podia ei ajoiteta suorittamaan. Mutta toisin kuin prosessoriresurssit, muistia ei pakata, koska sen käyttöä ei voida rajoittaa. Siksi säilön suoritus lopetetaan heti, kun se ylittää sille varatun muistin.
On tärkeää muistaa, että et voi määrittää pyyntöjä, jotka ylittävät solmujesi tarjoamat resurssit. GKE-virtuaalikoneiden yhteiset resurssimääritykset löytyvät tämän videon alla olevista linkeistä.
Ihanteellisessa maailmassa säilön oletusasetukset riittäisivät pitämään työnkulut sujuvasti käynnissä. Mutta todellinen maailma ei ole sellainen, ihmiset voivat helposti unohtaa määrittää resurssien käytön tai hakkerit asettavat pyyntöjä ja rajoituksia, jotka ylittävät infrastruktuurin todelliset mahdollisuudet. Voit estää tällaisten skenaarioiden esiintymisen määrittämällä ResourceQuota- ja LimitRange-resurssikiintiöt.
Kun nimiavaruus on luotu, se voidaan estää kiintiöillä. Jos sinulla on esimerkiksi prod- ja dev-nimitilat, malli on sellainen, että tuotantokiintiöitä ei ole ollenkaan ja kehityskiintiöt ovat erittäin tiukat. Tämä sallii prodin liikenteen jyrkän nousun sattuessa ottaa haltuunsa koko käytettävissä olevan resurssin, mikä estää kehittäjät kokonaan.
Resurssikiintiö saattaa näyttää tältä. Tässä esimerkissä on 4 osiota - nämä ovat koodin 4 alariviä.
Katsotaanpa jokaista niistä. Requests.cpu on yhdistettyjen CPU-pyyntöjen enimmäismäärä, joka voi tulla kaikista nimitilan säilöistä. Tässä esimerkissä sinulla voi olla 50 konttia 10 metrin pyynnöillä, viisi konttia 100 metrin pyynnöillä tai vain yksi kontti 500 metrin pyynnöillä. Niin kauan kuin tietyn nimitilan requests.cpu:n kokonaismäärä on alle 500 miljoonaa, kaikki on kunnossa.
Muistin pyydetyt pyynnöt.muisti on yhdistettyjen muistipyyntöjen enimmäismäärä, joka kaikilla nimiavaruuden säilöillä voi olla. Kuten edellisessä tapauksessa, sinulla voi olla 50 2 mib säilöä, viisi 20 mib säilöä tai yksi 100 mib säilö, kunhan nimiavaruudessa pyydetyn muistin kokonaismäärä on alle 100 mebitavua.
Limits.cpu on suurin yhdistetty CPU-tehon määrä, jonka kaikki nimitilan säilöt voivat käyttää. Voimme pitää tätä prosessorin tehopyyntöjen rajana.
Lopuksi limits.memory on jaetun muistin enimmäismäärä, jota kaikki nimitilan säilöt voivat käyttää. Tämä on kokonaismuistipyyntöjen raja.
Joten oletuksena Kubernetes-klusterin säilöt toimivat rajoittamattomilla laskentaresursseilla. Resurssikiintiöiden avulla klusterin ylläpitäjät voivat rajoittaa resurssien kulutusta ja resurssien luomista nimitilan perusteella. Nimiavaruudessa pod tai säilö voi kuluttaa niin paljon suorittimen tehoa ja muistia kuin nimitilan resurssikiintiö määrittää. On kuitenkin olemassa huoli siitä, että yksi kotelo tai säiliö saattaa monopolisoida kaikki käytettävissä olevat resurssit. Tämän tilanteen estämiseksi käytetään raja-aluetta - käytäntöä, jolla rajoitetaan resurssien allokointia (jakoille tai säilöille) nimiavaruudessa.
Raja-alue tarjoaa rajoituksia, jotka voivat:
- Varmistaa laskentaresurssien vähimmäis- ja enimmäismäärän jokaiselle nimitilan moduulille tai säilölle;
- pakottaa vähimmäis- ja enimmäismäärä Starage Request -tallennuspyynnöt kullekin nimiavaruuden PersistentVolumeClaim-pyynnölle;
- pakottaa suhde Pyynnön ja Limitin välillä resurssille nimiavaruudessa;
- aseta oletuspyynnöt/rajoitukset laskentaresursseille nimiavaruudessa ja lisää ne automaattisesti säilöihin suorituksen aikana.
Tällä tavalla voit luoda raja-alueen nimiavaruuteen. Toisin kuin kiintiö, joka koskee koko nimiavaruutta, raja-aluetta käytetään yksittäisille säilöille. Tämä voi estää käyttäjiä luomasta hyvin pieniä tai päinvastoin jättimäisiä säiliöitä nimiavaruuteen. Limit Range saattaa näyttää tältä.
Kuten edellisessä tapauksessa, tässä voidaan erottaa 4 osiota. Katsotaanpa jokaista.
Oletusosio asettaa oletusrajat pod-säilölle. Jos asetat nämä arvot äärimmäiselle alueelle, kaikki säiliöt, joille näitä arvoja ei ole erikseen asetettu, noudattavat oletusarvoja.
Oletuspyyntöosio defaultRequest määrittää oletuspyynnöt pod-säiliölle. Jälleen, jos asetat nämä arvot äärimmäiselle alueelle, kaikki säiliöt, jotka eivät nimenomaisesti määritä näitä asetuksia, käyttävät oletusarvoja.
Max-osio määrittää enimmäisrajat, jotka voidaan asettaa säiliössä olevalle säiliölle. Oletusosion arvoja ja säilörajoja ei voi asettaa tämän rajan yläpuolelle. On tärkeää huomata, että jos arvoksi on asetettu max eikä oletusosiota ole, enimmäisarvo tulee oletusarvoksi.
Min-osio määrittää vähimmäispyynnöt, jotka voidaan asettaa pod-säiliölle. Oletusosion arvoja ja säilön kyselyitä ei kuitenkaan voida asettaa tämän rajan alapuolelle.
Jälleen on tärkeää huomata, että jos tämä arvo on asetettu, oletusarvo ei ole, niin vähimmäisarvosta tulee oletuskehote.
Kubernetes-ajastin käyttää viime kädessä näitä resurssipyyntöjä työkuormiesi suorittamiseen. Jotta voit määrittää säilösi oikein, on erittäin tärkeää ymmärtää, miten se toimii. Oletetaan, että haluat käyttää useita podeja klusterissasi. Olettaen, että pod-määritykset ovat kelvollisia, Kubernetes-aikataulu käyttää round robin -tasapainotusta valitakseen solmun työkuorman suorittamista varten.
Kubernetes tarkistaa, onko solmulla 1 tarpeeksi resursseja pod-säilöjen pyyntöjen täyttämiseen, ja jos ei, se siirtyy seuraavaan solmuun. Jos mikään järjestelmän solmuista ei pysty täyttämään pyyntöjä, podit siirtyvät Odottaa-tilaan. Käyttämällä Google Kubernetes -moottorin ominaisuuksia, kuten solmun automaattista skaalausta, GKE voi automaattisesti havaita odotustilan ja luoda useita muita solmuja.
Jos solmukapasiteetti loppuu myöhemmin, automaattinen skaalaus vähentää solmujen määrää säästääkseen rahaa. Tästä syystä Kubernetes ajoittaa podeja pyyntöjen perusteella. Raja voi kuitenkin olla suurempi kuin pyynnöt, ja joissakin tapauksissa solmun resurssit voivat loppua. Kutsumme tätä tilaa ylisitoutumistilaksi.
Kuten sanoin, prosessorin suhteen Kubernetes alkaa rajoittaa podeja. Jokainen pod saa niin paljon kuin se pyysi, mutta jos se ei saavuta rajaa, kuristus alkaa.
Mitä tulee muistiresursseihin, Kubernetes joutuu tekemään päätöksiä siitä, mitkä podit poistetaan ja mitkä säilytetään, kunnes vapautat järjestelmäresursseja tai koko järjestelmä kaatuu.
Kuvitellaan skenaario, jossa koneen muisti loppuu – miten Kubernetes hoitaisi sen?
Kubernetes etsii podeja, jotka käyttävät enemmän resursseja kuin he pyysivät. Joten jos säilöilläsi ei ole lainkaan pyyntöjä, se tarkoittaa, että ne käyttävät oletusarvoisesti enemmän kuin pyysivät, yksinkertaisesti koska he eivät pyytäneet mitään! Tällaisista säiliöistä tulee ensisijaisia sulkemisehdokkaita. Seuraavat ehdokkaat ovat kontit, jotka ovat täyttäneet kaikki pyyntönsä, mutta ovat edelleen enimmäisrajan alapuolella.
Joten jos Kubernetes löytää useita ryhmiä, jotka ovat ylittäneet pyyntöparametrinsa, se lajittelee ne prioriteetin mukaan ja poistaa sitten alhaisimman prioriteetin podit. Jos kaikilla podeilla on sama prioriteetti, Kubernetes lopettaa ne podit, jotka ylittävät pyyntönsä enemmän kuin muut podit.
Hyvin harvoissa tapauksissa Kubernetes voi keskeyttää pyyntöjensä piiriin kuuluvia paloja. Näin voi tapahtua, kun tärkeät järjestelmäkomponentit, kuten Kubelet-agentti tai Docker, alkavat kuluttaa enemmän resursseja kuin niille oli varattu.
Pienyritysten alkuvaiheessa Kubernetes-klusteri voi siis toimia hyvin asettamatta resurssipyyntöjä ja rajoituksia, mutta kun tiimisi ja projektisi alkavat kasvaa, on vaarana joutua ongelmiin tällä alueella. Kyselyjen ja rajoitusten lisääminen moduuleihisi ja nimiavaruuksiin vaatii vain vähän ylimääräistä vaivaa ja voi säästää paljon vaivaa.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com