Za svaki Kubernetes resurs postoji mogućnost postavljanja dva tipa zahtjeva — Requests i Limits. Prvi opisuje minimalne zahtjeve za slobodnim resursima čvora koji su potrebni za pokretanje kontejnera ili poda, dok drugi strogo ograničava resurse dostupne kontejneru.
Kada Kubernetes planira pod, vrlo je važno da kontejneri imaju dovoljno resursa za normalan rad. Ako planirate implementirati veliku aplikaciju na čvoru s ograničenim resursima, moguće je da neće raditi zbog nedostatka memorije ili procesorske snage na čvoru. U ovom članku ćemo razmotriti kako riješiti probleme nedostatka računalnih resursa kroz zahtjeve za resursima i ograničenja.
Zahtjevi Requests i ograničenja Limits su mehanizmi koje Kubernetes koristi za upravljanje resursima poput procesora i memorije. Requests osiguravaju da kontejner dobije traženi resurs. Ako kontejner traži resurs, Kubernetes će ga planirati samo na onom čvoru koji ga može pružiti. Ograničenja Limits kontroliraju da resursi koje kontejner traži nikada ne premaše određenu vrijednost.
Kontejner može povećati računalne resurse samo do određenog limita, nakon čega će biti ograničen. Pogledajmo kako to funkcionira. Dakle, postoje dva tipa resursa — procesor i memorija. Kubernetesov planirnik koristi podatke o tim resursima kako bi utvrdio gdje pokrenuti vaše pode. Tipična specifikacija resursa za pod izgleda ovako.
Svaka posuda u podu može postaviti svoje vlastite zahtjeve i ograničenja, a sve je to aditivno. Resursi procesora određuju se u milikorama. Ako vaš kontejner treba dva puna jezgra za pokretanje, postavljate vrijednost na 2000m. Ako kontejneru treba samo 1/4 jezgra, vrijednost će biti 250m. Imajte na umu da ako dodijelite vrijednost resursa procesora veću od broja jezgra najveće nodne jedinice, vaša pod jedinica neće biti planirana. Slična situacija će se dogoditi ako imate pod koji zahtijeva četiri jezgra, a Kubernetes klaster se sastoji od samo dva glavna virtualna stroja.
Osim ako vaša aplikacija nije posebno dizajnirana za iskorištavanje prednosti više jezgara (na umu imamo programe poput složenih znanstvenih proračuna i operacija s bazama podataka), najbolja praksa je postaviti zahtjeve za CPU na 1 ili niže, a zatim pokrenuti veći broj replika radi skalabilnosti. Ovo rješenje će sustavu dati veću fleksibilnost i pouzdanost.
Kada su u pitanju ograničenja procesora, situacija postaje zanimljivija, jer se processor smatra kompresibilnim resursom. Ako vaša aplikacija počne dolaziti do limita procesorske snage, Kubernetes će početi usporavati vaš kontejner koristeći CPU Throttling — smanjenje frekvencije procesora. To znači da će procesor biti umjetno ograničen, što može dovesti do lošije izvedbe aplikacije, ali proces neće biti prekinut ili isključen.
Resursi memorije određuju se u bajtovima. Obično se vrijednost u postavkama mjeri u mebibajtima Mib, ali možete postaviti bilo koju vrijednost, od bajtova do petabajta. Ovdje vrijedi ista situacija kao i s CPU-om — ako postavite zahtjev za memorijom koji premašuje kapacitet memorije vaših nodova, izvršenje te pod jedinice neće biti planirano. No, za razliku od resursa procesora, memorija se ne može komprimirati jer ne postoji način da se ograniči njezina upotreba. Stoga će izvršenje kontejnera biti zaustavljeno čim premaši dodijeljenu memoriju.
Važno je zapamtiti da ne možete postaviti zahtjeve koji premašuju veličinu resursa koje vaši čvorovi mogu osigurati. Značajke zajedničkih resursa za GKE virtualne strojeve možete pronaći putem poveznica postavljenih ispod ovog videozapisa.
U idealnom svijetu, zadane postavke kontejnera su sasvim dovoljne da radni procesi prođu glatko. No, stvarni svijet nije takav; ljudi lako mogu zaboraviti postaviti upotrebu resursa ili hakeri mogu postaviti zahtjeve i ograničenja koja premašuju stvarne mogućnosti infrastrukture. Kako biste spriječili razvoj takvih scenarija, možete postaviti kvote resursa ResourceQuota i raspon ograničenja LimitRange.
Nakon stvaranja prostora imena, možete ih zaključati pomoću kvota. Na primjer, ako imate prostore imena prod i dev, koristi se predložak u kojem kvote za produkciju uopće ne postoje, dok su kvote za razvoj vrlo stroge. To omogućava da prod u slučaju naglog porasta prometa preuzme sve dostupne resurse, potpuno blokirajući dev.
Kvote resursa mogu izgledati ovako. U ovom primjeru postoje 4 odjeljka – to su 4 donje linije koda.
Pogledajmo svaki od njih. Requests.cpu — to je maksimalni broj kombiniranih zahtjeva procesorske snage koji mogu dolaziti od svih kontejnera u prostoru imena. U ovom primjeru možete imati 50 kontejnera s zahtjevima od 10m, pet kontejnera s zahtjevima od 100m ili jednostavno jedan kontejner s zahtjevom od 500m. Dok ukupni broj requests.cpu ovog prostora imena bude manji od 500m, sve će biti u redu.
Zahtijevana memorija requests.memory — to je maksimalna količina kombiniranih zahtjeva memorije koju svi kontejneri u prostoru imena mogu imati. Kao i u prethodnom slučaju, možete imati 50 kontejnera po 2 mib, pet kontejnera po 20 Mib ili jedan kontejner s 100 Mib, sve dok ukupna količina zahtijevane memorije u prostoru imena bude manja od 100 mebibajta.
Limits.cpu — to je maksimalna kombinirana vrijednost procesorske snage koju mogu koristiti svi kontejneri u prostoru imena. Može se smatrati da je to limit za zahtjeve procesorske snage.
Na kraju, limits.memory – maksimalna količina ukupne memorije koju mogu koristiti svi kontejneri u imenskom prostoru. Ova ograničenja su zbirni zahtevi memorije.
Dakle, prema zadanim postavkama, kontejneri u Kubernetes klasteru rade s neograničenim računalnim resursima. Pomoću kvota resursa, administratori klastera mogu ograničiti potrošnju resursa i njihovo stvaranje na osnovu imenskih prostora. U imenskom prostoru, pod moduli ili kontejneri mogu konzumirati onoliko CPU snage i memorije koliko je određeno kvotom resursa imenog prostora. Međutim, postoji zabrinutost da jedan pod ili kontejner može monopolizovati sve dostupne resurse. Da bi se spriječila takva situacija, koristi se predjelni opseg limit Range – politika ograničavanja raspodjele resursa (za podove ili kontejnere) u imenskom prostoru.
Predjelni opseg pruža ograničenja koja mogu:
- osigurati minimalnu i maksimalnu upotrebu računalnih resursa za svaki modul ili kontejner u imenskom prostoru;
- prisiliti da se minimalni i maksimalni zahtevi za pohranu Storage Request za svaki PersistentVolumeClaim u imenskom prostoru;
- prisiliti da se postavi odnos između zahteva Request i ograničenja Limit za resurs u imenskom prostoru;
- postaviti Requests/Limits po defaultu za računalne resurse u imenskom prostoru i automatski ih primijeniti u kontejnere tijekom izvođenja.
Na taj način, možete stvoriti predjelni opseg u svom imenskom prostoru. Za razliku od kvote koja se primjenjuje na cijeli imenski prostor, Limit Range se koristi za pojedinačne kontejnere. To može spriječiti korisnike da stvaraju vrlo male ili, s druge strane, ogromne kontejnere unutar imenskog prostora. Predjelni opseg Limit Range može izgledati ovako.
Kao i u prethodnom slučaju, ovdje se može istaknuti 4 sekcije. Pogledajmo svaku.
U sekciji default postavljaju se zadana ograničenja za kontejner u podu. Ako postavite ove vrednosti u predjelnom opsegu, svi kontejneri za koje ove vrednosti nisu izričito postavljene, bit će vođeni zadanim vrednostima.
U odjeljku defaultRequest postavljeni su zahtjevi po defaultu za kontejnere u podu. Ponovno, ako postavite ove vrijednosti unutar ograničenja, svi kontejneri za koje ovi parametri nisu izričito postavljeni, koristit će ove vrijednosti kao zadane.
U odjeljku max navedena su maksimalna ograničenja koja se mogu postaviti za kontejnere u podu. Vrijednosti u odjeljku default i ograničenja za kontejnere ne mogu biti postavljene iznad ovog praga. Važno je napomenuti da, ako je postavljena vrijednost max, a odjeljak default ne postoji, tada maksimalna vrijednost postaje zadana vrijednost.
U odjeljku min navedeni su minimalni zahtjevi koji se mogu postaviti za kontejnere u podu. Vrijednosti u odjeljku default i zahtjevi za kontejnere ne mogu biti postavljeni ispod ovog praga.
Ponovno, važno je napomenuti da, ako je ova vrijednost postavljena, a default vrijednost nije, tada minimalna vrijednost postaje zahtjev po defaultu.
Na kraju, ovi zahtjevi resursa koriste Kubernetes scheduler za izvršavanje vaših radnih opterećenja. Da biste mogli ispravno postaviti svoje kontejnere, vrlo je važno razumjeti kako to funkcionira. Pretpostavimo da želite pokrenuti nekoliko modula u svom klasteru. Pod uvjetom da su specifikacije poda valjane, u rasporedu Kubernetes će se koristiti ciklična ravnoteža za odabir čvora za izvršavanje radnog opterećenja.
Kubernetes će provjeriti ima li čvor Node 1 dovoljno resursa za izvršavanje zahtjeva kontejnera poda, a ako ne, preći će na sljedeći čvor. Ako nijedan od čvorova u sustavu ne može zadovoljiti zahtjeve, podovi će preći u stanje čekanja (Pending state). Uz pomoć funkcija kao što su automatsko skaliranje čvorova u Google Kubernetes Engineu, GKE može automatski prepoznati stanje čekanja i stvoriti dodatne čvorove.
Ako kasnije dođe do viška kapaciteta čvorova, funkcija automatskog skaliranja smanjit će njihovu količinu kako bi vam uštedjela novac. Zbog toga Kubernetes planira podove na temelju zahtjeva. Međutim, limit može biti veći od zahtjeva, a u nekim slučajevima čvor može zapravo iscrpiti resurse. Takvo stanje nazivamo stanjem overcommitment.
Kao što sam već rekao, kada je u pitanju procesor, Kubernetes će početi ograničavati podove. Svaki pod će dobiti koliko je zatražio, ali ako ne dostigne limit, počet će se primjenjivati throttling.
Što se tiče resursa memorije, Kubernetes je prisiljen donositi odluke o tome koje podove ukloniti, a koje zadržati, sve dok ne oslobodite sistemske resurse, inače će cijeli sistem pasti.
Zamislimo scenarij u kojem imate stroj koji je dostigao limit memorije – kako će se Kubernetes u tom slučaju ponašati?
Kubernetes će tražiti podove koji koriste više resursa nego što su zatražili. Dakle, ako vaši kontejneri nemaju nikakve zahtjeve, to znači da po defaultu koriste više nego što su zatražili, jednostavno zato što nisu zatražili ništa! Takvi kontejneri postaju glavni kandidati za isključivanje. Sljedeći kandidati su kontejneri koji su zadovoljili sve svoje zahtjeve, ali se i dalje nalaze ispod maksimalnog limita.
Dakle, ako Kubernetes pronađe nekoliko podova koji su premašili svoje zahtjeve, sortira ih prema prioritetu, a zatim uklanja module s najnižim prioritetom. Ako svi moduli imaju isti prioritet, Kubernetes će prekinuti rad onih podova koji su premašili svoje zahtjeve više od ostalih podova.
U vrlo rijetkim slučajevima Kubernetes može prekinuti rad podova koji se još uvijek nalaze unutar svojih zahtjeva. To se može dogoditi kada kritične komponente sistema, poput Kubelet agenta ili Dockera, počnu koristiti više resursa nego što je za njih rezervirano.
Dakle, u ranim fazama rada malih tvrtki, Kubernetes klaster može savršeno raditi bez postavljanja zahtjeva za resursima i ograničenja, ali kako vaše ekipe i projekti počinju rasti, možete se suočiti s problemima u ovom području. Dodavanje zahtjeva i ograničenja u vaše module i prostore imena zahtijeva vrlo malo dodatnog truda i može vas osloboditi mnogih briga.
Malo reklame 🙂
Hvala što ostajete s nama. Sviđa li vam se naše članke? Želite li vidjeti više zanimljivih materijala? Podržite nas narudžbom ili preporučite prijateljima, , jedinstveni analog entry-level servera koji smo razvili za vas: (dostupne opcije s RAID1 i RAID10, do 24 jezgre i do 40GB DDR4).
Dell R730xd je 2 puta jeftiniji u data centaru Equinix Tier IV u Amsterdamu? Samo kod nas u Nizozemskoj! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Pročitajte o tome
Izvor: habr.com
