Za svaki Kubernetes resurs moguće je konfigurirati dvije vrste zahtjeva – zahtjeve i ograničenja. Prvi opisuje minimalne zahtjeve za slobodne resurse čvora koji su potrebni za pokretanje kontejnera ili pod, drugi ozbiljno ograničava resurse dostupne kontejneru.
Kada Kubernetes planira podove, veoma je važno da kontejneri imaju dovoljno resursa za normalno funkcionisanje. Ako planirate implementirati veliku aplikaciju na host s ograničenim resursima, moguće je da se neće pokrenuti jer hostu ponestaje memorije ili snage procesora. U ovom članku ćemo pogledati kako možete riješiti probleme nedostatka računarske snage koristeći zahtjeve za resurse i ograničenja.
Zahtjevi i ograničenja su mehanizmi koje Kubernetes koristi za upravljanje resursima kao što su CPU i memorija. Zahtjevi su ono što osigurava da kontejner dobije traženi resurs. Ako kontejner zatraži resurs, Kubernetes će ga zakazati samo na čvoru koji ga može pružiti. Ograničava kontrolu da resursi koje traži kontejner nikada ne prelaze određenu vrijednost.
Kontejner može povećati računarsku snagu samo do određene granice, nakon čega će biti ograničena. Hajde da vidimo kako to radi. Dakle, postoje dvije vrste resursa - procesor i memorija. Kubernetes planer koristi ove resurse da otkrije gdje da pokrene vaše podove. Tipična specifikacija resursa za pod izgleda ovako.
Svaki kontejner u pod-u može postaviti svoje zahtjeve i ograničenja, sve je aditivno. Resursi procesora definirani su u milikorima. Ako su vašem kontejneru potrebna dva puna jezgra za rad, postavite vrijednost na 2000m. Ako kontejneru treba samo 1/4 snage jezgre, vrijednost će biti 250m. Imajte na umu da ako dodijelite vrijednost CPU resursa veću od broja jezgara najvećeg čvora, tada vaš pod uopće neće biti zakazan za pokretanje. Slična situacija će se dogoditi ako imate pod koji treba četiri jezgra, a Kubernetes klaster se sastoji od samo dvije glavne virtuelne mašine.
Osim ako vaša aplikacija nije posebno dizajnirana da iskoristi prednosti više jezgri (tako vam na pamet padaju programi kao što su složeni naučni proračuni i operacije baze podataka), onda je najbolja praksa postaviti CPU zahtjeve na 1 ili niže, a zatim pokrenuti više replika za skalabilnost. Ovo rješenje će sistemu dati veću fleksibilnost i pouzdanost.
Kada su u pitanju ograničenja CPU-a, stvari postaju zanimljivije jer se smatra kompresibilnim resursom. Ako se vaša aplikacija počne približavati CPU limitu, Kubernetes će početi prigušivati vaš kontejner pomoću CPU Throttling. To znači da će procesor biti umjetno ograničen, dajući aplikaciji potencijalno lošije performanse, ali proces neće biti prekinut ili prikazan.
Memorijski resursi su definirani u bajtovima. Obično se vrijednost u postavkama mjeri u mib mebibajtima, ali možete je postaviti na bilo koju vrijednost, od bajtova do petabajta. Ovdje je situacija ista kao i sa CPU-om - ako postavite zahtjev za količinu memorije koja premašuje količinu memorije na vašim čvorovima, izvršenje ovog pod-a neće biti zakazano. Ali za razliku od CPU resursa, memorija nije komprimirana jer ne postoji način da se ograniči njena upotreba. Stoga će izvođenje spremnika biti zaustavljeno čim ponestane memorije koja mu je dodijeljena.
Važno je zapamtiti da ne možete konfigurirati zahtjeve koji premašuju količinu resursa koje vaši čvorovi mogu pružiti. Podijelite specifikacije za GKE VM-ove možete pronaći na linkovima ispod ovog videa.
U idealnom svijetu, zadane postavke kontejnera bile bi dovoljne za nesmetano odvijanje radnih tokova. Ali stvarni svijet nije takav, ljudi lako mogu zaboraviti prilagoditi korištenje resursa ili će hakeri postaviti zahtjeve i ograničenja koja prevazilaze stvarne mogućnosti infrastrukture. Da biste spriječili razvoj takvih scenarija, možete konfigurirati kvote resursa ResourceQuota i LimitRange opsege.
Jednom kada se kreira prostor imena, oni se mogu zaključati pomoću kvota. Na primjer, ako imate prostore imena prod i dev, obrazac je da uopće ne postoje proizvodne kvote, a razvojne kvote su vrlo stroge. Ovo omogućava prod-u da preuzme sve raspoložive resurse u slučaju naglog povećanja prometa, potpuno blokirajući dev.
Kvota resursa može izgledati ovako. U ovom primjeru postoje 4 odjeljka - ovo su 4 donje linije koda.
Pogledajmo svaki od njih. Requests.cpu je maksimalni broj kombinovanih zahtjeva za CPU snagu koji mogu doći iz svih kontejnera imenskog prostora. U ovom primjeru možete imati 50 kontejnera sa 10m zahtjeva, pet kontejnera sa 100m zahtjeva ili samo jedan kontejner sa 500m zahtjeva. Sve dok je ukupan broj requests.cpu datog imenskog prostora manji od 500m, sve će biti u redu.
Zatraženi memorijski zahtjevi.memory je maksimalna količina kombinovanih memorijskih zahtjeva koju mogu imati svi kontejneri u imenskom prostoru. Kao iu prethodnom slučaju, možete imati 50 kontejnera od 2 mib, pet kontejnera od 20 mib ili jedan kontejner od 100 mib sve dok je ukupna količina tražene memorije u imenskom prostoru manja od 100 mebibajta.
Limits.cpu je maksimalna kombinovana količina procesorske snage koju svi kontejneri prostora imena mogu koristiti. Možemo pretpostaviti da je ovo ograničenje zahtjeva za napajanjem procesora.
Konačno, limits.memory je maksimalna količina dijeljene memorije koju svi kontejneri u imenskom prostoru mogu koristiti. Ovo je ograničenje ukupnog broja zahtjeva za memorijom.
Dakle, prema zadanim postavkama, kontejneri u Kubernetes klasteru rade s neograničenim računarskim resursima. Sa kvotama resursa, administratori klastera mogu ograničiti potrošnju resursa i kreiranje resursa na osnovu prostora imena. U imenskom prostoru, pod ili kontejner može potrošiti onoliko CPU i memorijske snage koliko je definirano kvotom resursa prostora imena. Međutim, postoji zabrinutost da jedna kapsula ili kontejner može monopolizirati sve dostupne resurse. Da bi se spriječila ova situacija, koristi se limit Range - politika za ograničavanje alokacije resursa (za podove ili kontejnere) u imenskom prostoru.
Granični raspon pruža ograničenja koja mogu:
- osigurati minimalnu i maksimalnu upotrebu računarskih resursa za svaki modul ili kontejner u imenskom prostoru;
- nametnuti minimalni i maksimalni Starage zahtjev za svaki PersistentVolumeClaim u imenskom prostoru;
- forsirati odnos između zahtjeva i ograničenja za resurs u imenskom prostoru;
- postavite zadane zahtjeve/ograničenja za računske resurse u imenskom prostoru i automatski ih ubacite u kontejnere u vrijeme izvođenja.
Tako možete kreirati ograničeni raspon u svom imenskom prostoru. Za razliku od kvote, koja se primjenjuje na cijeli prostor imena, Limit Range se koristi za pojedinačne kontejnere. Ovo može spriječiti korisnike da kreiraju male ili ogromne kontejnere unutar imenskog prostora. Granični raspon bi mogao izgledati ovako.
Kao iu prethodnom slučaju, ovdje se mogu razlikovati 4 odjeljka. Hajde da pogledamo svaki.
Podrazumevani odeljak postavlja podrazumevana ograničenja za kontejner u pod. Ako postavite ove vrijednosti u ekstremni raspon, tada će svi kontejneri za koje ove vrijednosti nisu eksplicitno postavljene slijediti zadane vrijednosti.
U odjeljku defaultRequest, zadani zahtjevi su konfigurisani za kontejner u Podu. Opet, ako ove vrijednosti postavite na ekstremni raspon, tada će svi kontejneri za koje ovi parametri nisu eksplicitno postavljeni koristiti ove vrijednosti prema zadanim postavkama.
Odjeljak max specificira maksimalna ograničenja koja se mogu postaviti za kontejner u Podu. Vrijednosti u zadanom odjeljku i ograničenja kontejnera ne mogu se postaviti iznad ovog ograničenja. Važno je napomenuti da ako je max postavljen i ne postoji zadani odjeljak, tada maksimalna vrijednost postaje zadana vrijednost.
Odjeljak min specificira minimalne zahtjeve koji se mogu postaviti za kontejner u pod. Međutim, vrijednosti u zadanom odjeljku i zahtjevi za kontejner ne mogu se postaviti ispod ove granice.
Opet, važno je napomenuti da ako je ova vrijednost postavljena, a zadana vrijednost nije, tada minimalna vrijednost postaje zadani upit.
Na kraju krajeva, ove zahtjeve za resurse koristi Kubernetes planer za izvršavanje vaših radnih opterećenja. Da biste pravilno postavili svoje kontejnere, vrlo je važno razumjeti kako oni funkcioniraju. Recimo da želite pokrenuti više podova na svom klasteru. Pod pretpostavkom da su specifikacije pod validne, Kubernetes raspored će koristiti kružni rad za odabir čvora za pokretanje radnog opterećenja.
Kubernetes će provjeriti da li čvor 1 ima dovoljno resursa da ispuni zahtjeve pod kontejnera, a ako ne, preći će na sljedeći čvor. Ako nijedan od čvorova u sistemu ne može zadovoljiti zahtjeve, podovi će preći u stanje na čekanju. Koristeći funkcije Google Kubernetes motora kao što je automatsko skaliranje čvorova, GKE može automatski otkriti stanje na čekanju i kreirati još nekoliko dodatnih čvorova.
Ako kasnije dođe do prevelikog kapaciteta čvorova, automatsko skaliranje će smanjiti broj čvorova kako bi vam uštedio novac. Zbog toga Kubernetes zakazuje Podove na osnovu zahtjeva. Međutim, ograničenje može biti veće od zahtjeva, a u nekim slučajevima host može stvarno ostati bez resursa. Ovo stanje nazivamo stanjem preopterećenosti.
Kao što sam rekao, kada je u pitanju CPU, Kubernetes će početi ograničavati Podove. Svaka kapsula će dobiti onoliko koliko je tražila, ali ako ne dostigne ograničenje, tada će se početi primjenjivati prigušivanje.
Što se tiče memorijskih resursa, ovdje Kubernetes mora donijeti odluke o tome koje podove će izbrisati, a koje zadržati dok ne oslobodite sistemske resurse, inače će se cijeli sistem srušiti.
Zamislimo scenario u kojem mašini ponestaje memorije – kako bi Kubernetes ovo podneo?
Kubernetes će tražiti Podove koji koriste više resursa nego što je traženo. Dakle, ako vaši kontejneri uopće nemaju Zahtjeve, to znači da po defaultu koriste više nego što su tražili, jednostavno zato što uopće ništa nisu tražili! Takvi kontejneri postaju glavni kandidati za gašenje. Sljedeći kandidati su kontejneri koji su zadovoljili sve njihove zahtjeve, ali su još uvijek ispod maksimalnog ograničenja.
Dakle, ako Kubernetes pronađe nekoliko podova koji su premašili svoje parametre zahtjeva, sortiraće ih po prioritetu, a zatim ukloniti podove najnižeg prioriteta. Ako svi podovi imaju isti prioritet, tada će Kubernetes ugasiti one podove koji su premašili svoje zahtjeve za više od ostalih podova.
U vrlo rijetkim slučajevima, Kubernetes može ukinuti Podove koji su još uvijek u okviru njihovih zahtjeva. Ovo se može desiti kada kritične komponente sistema kao što su Kubelet agent ili Docker počnu da troše više resursa nego što su rezervisani za njih.
Dakle, u ranim fazama male kompanije, Kubernetes klaster može dobro funkcionirati bez postavljanja zahtjeva za resursima i ograničenja, ali kako vaši timovi i projekti počnu da rastu, rizikujete da naiđete na probleme u ovoj oblasti. Dodavanje upita i ograničenja vašim modulima i imenskim prostorima zahtijeva vrlo malo dodatnog truda i može vam uštedjeti mnogo muke.
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com