Kun aloitat Kubernetesin käytön, on yleistä unohtaa säilöresurssien määrittäminen. Tässä vaiheessa riittää varmistaa, että Docker-kuva toimii ja voidaan ottaa käyttöön Kubernetes-klusteriin.
Mutta myöhemmin sovellus on otettava käyttöön tuotantoklusterissa muiden sovellusten kanssa. Tätä varten sinun on allokoitava resurssit säilölle ja varmistettava, että niitä on tarpeeksi sovelluksen käynnistämiseen ja että muut käynnissä olevat sovellukset eivät aiheuta ongelmia.
Joukkue käänsi artikkelin säilöresursseista (CPU & MEM), pyynnöistä ja resurssirajoituksista. Opit näiden asetusten edut ja mitä tapahtuu, jos et määritä niitä.
Laskentaresurssit
Meillä on kahdentyyppisiä resursseja seuraavilla yksiköillä:
- Keskusyksikkö (CPU) - ytimet;
- Muisti (MEM) - tavua.
Resurssit on määritelty jokaiselle säilölle. Seuraavassa Pod YAML -tiedostossa näet resurssiosion, joka sisältää pyydetyt ja rajalliset resurssit:
- Requested Pod Resources = kaikkien säiliöiden pyydettyjen resurssien summa;
- Pod Resource Limit = kaikkien Pod Resource Limits -rajojen summa.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiEsimerkki pyydetyistä ja rajoitetuista resursseista
Kenttä resources.requested spesifikaatiosta Pod on yksi niistä elementeistä, joita käytetään etsimään haluttu solmu. Voit jo suunnitella Pod-käyttöönoton sille. Miten löydät sopivan solmun?
Kubernetes koostuu useista komponenteista, mukaan lukien pääsolmu tai pääsolmu (Kubernetes Control Plane). Pääsolmussa on useita prosesseja: kube-apiserver, kube-controller-manager ja kube-scheduler.
Kube-scheduler-prosessi on vastuussa äskettäin luotujen ryhmien tarkistamisesta ja mahdollisten työntekijöiden solmujen löytämisestä, jotka vastaavat kaikkia pod-pyyntöjä, mukaan lukien pyydettyjen resurssien määrä. Kube-schedulerin löytämien solmujen luettelo on rankattu. Pod on ajoitettu solmulle, jolla on korkeimmat pisteet.
Mihin violetti Pod sijoitetaan?
Kuvassa näkyy, että kube-schedulerin pitäisi ajoittaa uusi violetti Pod. Kubernetes-klusteri sisältää kaksi solmua: A ja B. Kuten näette, kube-scheduler ei voi ajoittaa Podia solmulle A - käytettävissä olevat (pyydämättömät) resurssit eivät vastaa purppuranvärisen Podin pyyntöjä. Purppuranvärisen Podin pyytämä 1 Gt muistia ei siis mahdu solmuun A, koska käytettävissä olevaa muistia on 0,5 Gt. Mutta solmulla B on tarpeeksi resursseja. Tämän seurauksena kube-scheduler päättää, että purppuranpunaisen Podin määränpää on solmu B.
Nyt tiedämme, kuinka pyydetyt resurssit vaikuttavat Podin suorittamiseen käytettävän solmun valintaan. Mutta mikä on marginaaliresurssien vaikutus?
Resurssiraja on raja, jota CPU/MEM ei voi ylittää. Prosessoriresurssit ovat kuitenkin joustavat, joten prosessorirajansa saavuttavat säiliöt eivät aiheuta Podin poistumista. Sen sijaan suorittimen kuristus alkaa. Jos MEM-käyttöraja saavutetaan, säilö pysäytetään OOM-Killerin takia ja käynnistetään uudelleen, jos RestartPolicy-asetus sallii sen.
Pyydetyt ja enimmäisresurssit yksityiskohtaisesti
Resurssiviestintä Dockerin ja Kubernetesin välillä
Paras tapa selittää, miten resurssipyynnöt ja resurssirajoitukset toimivat, on esitellä Kubernetesin ja Dockerin suhde. Yllä olevasta kuvasta näet, kuinka Kubernetes-kentät ja Dockerin käynnistysliput liittyvät toisiinsa.
Muisti: pyyntö ja rajoitus
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Kuten edellä mainittiin, muisti mitataan tavuissa. Perustuen , voimme määrittää muistin numerona. Yleensä se on kokonaisluku, esimerkiksi 2678 - eli 2678 tavua. Voit myös käyttää jälkiliitteitä G и Gi, tärkeintä on muistaa, että ne eivät ole vastaavia. Ensimmäinen on desimaaliluku ja toinen binäärinen. Kuten k8s-dokumentaatiossa mainittu esimerkki: 128974848, 129e6, 129M, 123Mi - Ne ovat käytännössä samanarvoisia.
Kubernetes vaihtoehto limits.memory vastaa lippua --memory Dockerilta. Siinä tapauksessa request.memory Dockerille ei ole nuolta, koska Docker ei käytä tätä kenttää. Saatat kysyä, onko tämä edes välttämätöntä? Kyllä tarvitaan. Kuten aiemmin sanoin, kentällä on merkitystä Kubernetesille. Sen tietojen perusteella kube-scheduler päättää, mikä solmu ajoittaa Podin.
Mitä tapahtuu, jos asetat pyynnölle liian vähän muistia?
Jos säiliö on saavuttanut pyydetyn muistin rajat, Pod sijoitetaan Pod-ryhmään, joka pysähtyy, kun solmussa ei ole tarpeeksi muistia.
Mitä tapahtuu, jos asetat muistirajan liian pieneksi?
Jos säilö ylittää muistirajan, se suljetaan OOM-Killedin takia. Ja käynnistyy uudelleen, jos mahdollista RestartPolicyn perusteella, jossa oletusarvo on Always.
Mitä tapahtuu, jos et määritä pyydettyä muistia?
Kubernetes ottaa raja-arvon ja asettaa sen oletusarvoksi.
Mitä voi tapahtua, jos et määritä muistirajaa?
Säilöllä ei ole rajoituksia; se voi käyttää niin paljon muistia kuin haluaa. Jos hän alkaa käyttää kaikkea solmun käytettävissä olevaa muistia, OOM tappaa hänet. Säilö käynnistetään sitten uudelleen, jos mahdollista RestartPolicyn perusteella.
Mitä tapahtuu, jos et määritä muistirajoja?
Tämä on pahin skenaario: ajoittaja ei tiedä kuinka monta resurssia kontti vaatii, ja tämä voi aiheuttaa vakavia ongelmia solmussa. Tässä tapauksessa olisi mukavaa, jos nimiavaruudessa olisi oletusrajat (asettaa LimitRange). Ei ole oletusrajoja - Podilla ei ole rajoja, se voi käyttää niin paljon muistia kuin haluaa.
Jos pyydetty muisti on enemmän kuin solmu pystyy tarjoamaan, Pod:ta ei ajasteta. On tärkeää muistaa se Requests.memory - ei vähimmäisarvo. Tämä on kuvaus muistin määrästä, joka riittää pitämään säiliön käynnissä jatkuvasti.
Yleensä on suositeltavaa asettaa sama arvo request.memory и limit.memory. Tämä varmistaa, että Kubernetes ei ajoita Podia solmuun, jossa on tarpeeksi muistia Podin suorittamiseen mutta ei tarpeeksi sen suorittamiseen. Muista: Kubernetes Pod -suunnittelu ottaa huomioon vain requests.memoryJa limits.memory ei ota huomioon.
CPU: pyyntö ja raja
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Prosessorilla kaikki on hieman monimutkaisempaa. Palatakseni kuvaan Kubernetesin ja Dockerin välisestä suhteesta, näet sen request.cpu соответствует --cpu-shares, kun taas limit.cpu vastaa lippua cpus Dockerissa.
Kubernetesin pyytämä CPU kerrotaan 1024:llä, prosessorijaksojen osuudella. Jos haluat pyytää yhden täyden ytimen, sinun on lisättävä cpu: 1kuten yllä näkyy.
Täyden ytimen pyytäminen (suhde = 1024) ei tarkoita, että säilösi vastaanottaa sen. Jos isäntäkoneessasi on vain yksi ydin ja käytät useampaa kuin yhtä säilöä, kaikkien säilöjen on jaettava käytettävissä oleva suoritin keskenään. Miten tämä tapahtuu? Katsotaanpa kuvaa.
CPU-pyyntö – yhden ytimen järjestelmä
Oletetaan, että sinulla on yksiytiminen isäntäjärjestelmä, joka käyttää säilöjä. Äiti (Kubernetes) leipoi piirakan (CPU) ja haluaa jakaa sen lapsille (astiat). Kolme lasta haluaa kokonaisen piirakan (osuus = 1024), toinen lapsi puolikkaan piirakan (512). Äiti haluaa olla oikeudenmukainen ja tekee yksinkertaisen laskelman.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Laskelman perusteella kolme lasta saa 28 % ytimestä, ei koko ydintä. Neljäs lapsi saa 14% täydestä ytimestä, ei puolta. Mutta asiat ovat toisin, jos sinulla on moniytiminen järjestelmä.
CPU Request - Multi-Core (4) järjestelmä
Yllä olevasta kuvasta näet, että kolme lasta haluaa kokonaisen piirakan ja yksi puolikkaan. Koska äiti leipoi neljä piirakkaa, jokainen hänen lapsensa saa niin monta kuin haluaa. Moniytimisjärjestelmässä prosessoriresurssit on jaettu kaikkien käytettävissä olevien prosessoriytimien kesken. Jos säiliössä on vähemmän kuin yksi täysi prosessoriytime, se voi silti käyttää sitä 100%.
Yllä olevat laskelmat on yksinkertaistettu ymmärtämään, kuinka CPU on jaettu säiliöiden kesken. Tietenkin itse säilöjen lisäksi on muita prosesseja, jotka käyttävät myös prosessoriresursseja. Kun yhden säilön prosessit ovat käyttämättömänä, muut voivat käyttää sen resurssia. CPU: "200m" соответствует CPU: 0,2, mikä tarkoittaa noin 20 % yhdestä ytimestä.
Nyt puhutaan limit.cpu. Kubernetesin rajoittama CPU kerrotaan 100:lla. Tuloksena on aika, jonka säiliö voi käyttää 100 µs:n välein (cpu-period).
limit.cpu vastaa Dockerin lippua --cpus. Tämä on uusi yhdistelmä vanhaa --cpu-period и --cpu-quota. Asettamalla sen osoitamme, kuinka monta käytettävissä olevaa CPU-resurssia säilö voi käyttää maksimissaan ennen kuristuksen alkamista:
- suorittimia - yhdistelmä
cpu-periodиcpu-quota. cpus = 1.5vastaa asetustacpu-period = 100000иcpu-quota = 150000; - CPU-jakso - kausi , oletusarvo 100 mikrosekuntia;
- cpu-kiintiö - sisällä olevien mikrosekuntien määrä
cpu-period, joka on säiliön rajoittama.
Mitä tapahtuu, jos asennat liian vähän pyydettyä prosessoria?
Jos kontti tarvitsee enemmän kuin se on asentanut, se varastaa suorittimen muista prosesseista.
Mitä tapahtuu, jos asetat CPU-rajan liian alhaiseksi?
Koska suorittimen resurssit ovat säädettävissä, kuristus kytkeytyy päälle.
Mitä tapahtuu, jos et määritä CPU-pyyntöä?
Kuten muistissa, pyynnön arvo on yhtä suuri kuin raja.
Mitä tapahtuu, jos et määritä suoritinrajaa?
Säiliö käyttää niin paljon prosessoria kuin se tarvitsee. Jos nimiavaruudessa on määritetty oletussuoritinkäytäntö (LimitRange), tätä rajaa käytetään myös säilössä.
Mitä tapahtuu, jos et määritä pyyntöä tai suoritinrajaa?
Kuten muistin kohdalla, tämä on pahin skenaario. Ajastin ei tiedä, kuinka monta resurssia säilösi tarvitsee, ja tämä voi aiheuttaa vakavia ongelmia solmussa. Tämän välttämiseksi sinun on asetettava nimiavaruille oletusrajat (LimitRange).
Muista: jos pyydät enemmän prosessoria kuin solmut voivat tarjota, Pod:ta ei ajasteta. Requests.cpu - ei vähimmäisarvoa, vaan arvoa, joka riittää käynnistämään Podin ja toimimaan ilman vikoja. Jos sovellus ei suorita monimutkaisia laskelmia, paras vaihtoehto on asentaa request.cpu <= 1 ja käynnistä niin monta kopiota kuin on tarpeen.
Ihanteellinen määrä pyydettyjä resursseja tai resurssiraja
Opimme laskentaresurssien rajoituksista. Nyt on aika vastata kysymykseen: "Kuinka monta resurssia Pod vaatii sovelluksen suorittamiseen ilman ongelmia? Mikä on ihanteellinen määrä?
Valitettavasti näihin kysymyksiin ei ole selkeitä vastauksia. Jos et tiedä, miten sovelluksesi toimii tai kuinka paljon suoritinta tai muistia se tarvitsee, paras vaihtoehto on antaa sovellukselle paljon muistia ja suoritinta ja suorittaa sitten suorituskykytestejä.
Suorituskykytestien lisäksi seurata sovelluksen käyttäytymistä monitoroinnissa viikon ajan. Jos kaaviot osoittavat, että sovelluksesi kuluttaa vähemmän resursseja kuin pyysit, voit vähentää vaaditun suorittimen tai muistin määrää.
Katso esimerkkinä tämä . Se näyttää eron pyydettyjen resurssien tai resurssirajan ja nykyisen resurssin käytön välillä.
Johtopäätös
Resurssien pyytäminen ja rajoittaminen auttaa pitämään Kubernetes-klusterin terveenä. Oikea raja-asetus minimoi kustannukset ja pitää sovellukset käynnissä koko ajan.
Lyhyesti sanottuna on muutamia asioita, jotka on pidettävä mielessä:
- Pyydetyt resurssit ovat kokoonpano, joka otetaan huomioon käynnistyshetkellä (kun Kubernetes aikoo isännöidä sovellusta). Sitä vastoin resurssien rajoittaminen on tärkeää ajon aikana – kun sovellus on jo käynnissä solmussa.
- Muistiin verrattuna CPU on säännelty resurssi. Jos suoritinta ei ole tarpeeksi, Pod ei sammu ja kuristusmekanismi käynnistyy.
- Pyydetyt resurssit ja resurssirajat eivät ole minimi- ja maksimiarvoja! Määrittämällä pyydetyt resurssit varmistat, että sovellus toimii ilman ongelmia.
- Hyvä käytäntö on asettaa muistipyyntö yhtä suureksi kuin muistiraja.
- Ok asennusta pyydettiin
CPU <=1, jos sovellus ei suorita monimutkaisia laskelmia. - Jos pyydät enemmän resursseja kuin solmussa on käytettävissä, Pod:ta ei koskaan ajoiteta kyseiseen solmuun.
- Voit määrittää oikean määrän pyydettyjä resursseja/resurssirajoja käyttämällä kuormitustestausta ja valvontaa.
Toivon, että tämä artikkeli auttaa sinua ymmärtämään resurssien rajoittamisen peruskäsitteen. Ja voit soveltaa tätä tietoa työssäsi.
Good Luck!
Mitä muuta luettavaa:
- .
- .
- .
Lähde: will.com