Kada počinjete sa Kubernetesom, uobičajeno je da zaboravite na postavljanje resursa kontejnera. U ovom trenutku, dovoljno je osigurati da Docker slika radi i da se može primijeniti na Kubernetes klaster.
Ali kasnije se aplikacija mora implementirati u proizvodni klaster zajedno s drugim aplikacijama. Da biste to učinili, morate dodijeliti resurse za kontejner i osigurati da ih ima dovoljno da se aplikacija pokrene i da druge pokrenute aplikacije neće imati problema.
tim preveo je članak o resursima kontejnera (CPU & MEM), zahtjevima i ograničenjima resursa. Naučit ćete koje su prednosti ovih postavki i šta će se dogoditi ako ih ne postavite.
Računalni resursi
Imamo dvije vrste resursa sa sljedećim jedinicama:
- Centralna procesorska jedinica (CPU) - jezgre;
- Memorija (MEM) - bajtovi.
Resursi su specificirani za svaki kontejner. U sljedećoj pod YAML datoteci vidjet ćete odjeljak resursa koji sadrži tražene i ograničene resurse:
- Zatraženi resursi pod = zbir traženih resursa svih kontejnera;
- Ograničenje resursa pod = zbir svih ograničenja resursa pod.
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: 1GiPrimjer traženih i ograničenih resursa
polje resources.requested iz specifikacije Pod je jedan od elemenata koji se koristi za pronalaženje željenog čvora. Već možete planirati implementaciju Poda za to. Kako pronaći odgovarajući čvor?
Kubernetes se sastoji od nekoliko komponenti, uključujući glavni čvor ili glavni čvor (Kubernetes Control Plane). Glavni čvor ima nekoliko procesa: kube-apiserver, kube-controller-manager i kube-scheduler.
Proces kube-schedulera odgovoran je za pregled novokreiranih podova i pronalaženje mogućih radnih čvorova koji odgovaraju svim zahtjevima pod, uključujući broj traženih resursa. Lista čvorova koje je pronašao kube-scheduler je rangirana. Pod je zakazan na čvoru sa najvišim rezultatima.
Gdje će biti postavljena ljubičasta Pod?
Na slici možete vidjeti da bi kube-scheduler trebao zakazati novi ljubičasti Pod. Kubernetes klaster sadrži dva čvora: A i B. Kao što vidite, kube-scheduler ne može zakazati Pod na čvoru A - dostupni (nezatraženi) resursi se ne podudaraju sa zahtjevima ljubičastog Poda. Dakle, 1 GB memorije koju traži ljubičasti Pod neće stati na čvor A, budući da je raspoloživa memorija 0,5 GB. Ali čvor B ima dovoljno resursa. Kao rezultat toga, kube-scheduler odlučuje da je odredište ljubičastog Poda čvor B.
Sada znamo kako traženi resursi utiču na izbor čvora za pokretanje Poda. Ali kakav je uticaj marginalnih resursa?
Ograničenje resursa je granica koju CPU/MEM ne može prijeći. Međutim, resurs CPU-a je fleksibilan, tako da kontejneri koji dosegnu svoja CPU ograničenja neće uzrokovati izlazak Pod-a. Umjesto toga, CPU throttling će početi. Ako se dostigne ograničenje upotrebe MEM-a, kontejner će biti zaustavljen zbog OOM-Killer-a i ponovo pokrenut ako to dozvoljava postavka RestartPolicy.
Traženi i maksimalni resursi detaljno
Komunikacija resursa između Dockera i Kubernetesa
Najbolji način da se objasni kako funkcionišu zahtjevi za resursima i ograničenja resursa je uvođenje odnosa između Kubernetesa i Dockera. Na gornjoj slici možete vidjeti kako su Kubernetes polja i Docker startup zastavice povezane.
Memorija: zahtjev i ograničenje
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Kao što je gore spomenuto, memorija se mjeri u bajtovima. Na osnovu , možemo odrediti memoriju kao broj. Obično je to cijeli broj, na primjer 2678 - odnosno 2678 bajtova. Možete koristiti i sufikse G и Gi, glavna stvar je zapamtiti da oni nisu ekvivalentni. Prvi je decimalni, a drugi binarni. Kao primjer spomenut u k8s dokumentaciji: 128974848, 129e6, 129M, 123Mi - oni su praktično ekvivalentni.
Kubernetes opcija limits.memory odgovara zastavi --memory od Dockera. U slučaju da request.memory Ne postoji strelica za Docker jer Docker ne koristi ovo polje. Možete pitati da li je ovo uopšte potrebno? Da treba. Kao što sam već rekao, polje je važno za Kubernetes. Na osnovu informacija iz njega, kube-scheduler odlučuje koji će čvor zakazati Pod.
Šta se događa ako postavite nedovoljno memorije za zahtjev?
Ako je kontejner dostigao granice tražene memorije, onda se Pod se stavlja u grupu Podova koji se zaustavljaju kada nema dovoljno memorije u čvoru.
Šta se dešava ako postavite prenisko ograničenje memorije?
Ako kontejner premaši ograničenje memorije, bit će prekinut zbog OOM-Killed. I ponovo će se pokrenuti ako je moguće na osnovu RestartPolicy gdje je zadana vrijednost Always.
Šta se dešava ako ne navedete traženu memoriju?
Kubernetes će uzeti graničnu vrijednost i postaviti je kao zadanu vrijednost.
Šta se može dogoditi ako ne odredite ograničenje memorije?
Kontejner nema ograničenja; može koristiti memoriju koliko želi. Ako počne koristiti svu dostupnu memoriju čvora, onda će ga OOM ubiti. Kontejner će se zatim ponovo pokrenuti ako je moguće na osnovu RestartPolicy.
Šta se dešava ako ne navedete ograničenja memorije?
Ovo je najgori scenario: planer ne zna koliko resursa zahtijeva kontejner, a to može uzrokovati ozbiljne probleme na čvoru. U ovom slučaju, bilo bi lijepo imati zadana ograničenja na imenskom prostoru (postavljena od strane LimitRange). Nema zadanih ograničenja - Pod nema ograničenja, može koristiti memoriju koliko želi.
Ako je tražena memorija veća nego što čvor može ponuditi, Pod neće biti zakazan. Važno je to zapamtiti Requests.memory - nije minimalna vrijednost. Ovo je opis količine memorije koja je dovoljna da kontejner radi kontinuirano.
Obično se preporučuje postavljanje iste vrijednosti za request.memory и limit.memory. Ovo osigurava da Kubernetes neće zakazati Pod na čvoru koji ima dovoljno memorije za pokretanje Poda, ali nedovoljno da ga pokrene. Imajte na umu: Kubernetes Pod planiranje uzima samo u obzir requests.memoryi limits.memory ne uzima u obzir.
CPU: zahtjev i ograničenje
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Sa CPU-om je sve malo komplikovanije. Ako se vratimo na sliku odnosa između Kubernetesa i Dockera, to možete vidjeti request.cpu odgovara --cpu-shares, dok limit.cpu odgovara zastavi cpus u Docker.
CPU koji Kubernetes traži množi se sa 1024, što je udio CPU ciklusa. Ako želite zatražiti 1 puno jezgro, morate dodati cpu: 1kao što je prikazano iznad.
Zahtjev za puni kernel (proporcija = 1024) ne znači da će ga vaš kontejner primiti. Ako vaša host mašina ima samo jednu jezgru i koristite više od jednog kontejnera, tada svi kontejneri moraju dijeliti raspoloživi CPU između sebe. Kako se to događa? Pogledajmo sliku.
CPU zahtjev - Jednojezgreni sistem
Zamislimo da imate jednojezgreni host sistem koji pokreće kontejnere. Mama (Kubernetes) je ispekla pitu (CPU) i želi je podijeliti između djece (kontejneri). Troje djece želi cijelu pitu (proporcija = 1024), drugo dijete želi pola pite (512). Mama želi da bude poštena i pravi jednostavnu kalkulaciju.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Na osnovu proračuna, troje djece će dobiti 28% jezgra, a ne cijelo jezgro. Četvrto dijete će dobiti 14% punog kernela, a ne polovinu. Ali stvari će biti drugačije ako imate sistem sa više jezgara.
CPU zahtjev - Višejezgreni (4) sistem
Na gornjoj slici možete vidjeti da troje djece želi cijelu pitu, a jedno pola. Pošto je mama ispekla četiri pite, svako njeno dete će dobiti koliko želi. U sistemu sa više jezgara, procesorski resursi su raspoređeni na sva dostupna procesorska jezgra. Ako je kontejner ograničen na manje od jedne pune CPU jezgre, i dalje ga može koristiti 100%.
Gore navedene kalkulacije su pojednostavljene da bi se razumjelo kako je CPU raspoređen među kontejnerima. Naravno, osim samih kontejnera, postoje i drugi procesi koji također koriste CPU resurse. Kada procesi u jednom kontejneru miruju, drugi mogu koristiti njegov resurs. CPU: "200m" odgovara CPU: 0,2, što znači otprilike 20% jednog jezgra.
Hajde sada da pričamo o tome limit.cpu. CPU koji Kubernetes ograničava se množi sa 100. Rezultat je količina vremena koju kontejner može koristiti svakih 100 µs (cpu-period).
limit.cpu odgovara Docker zastavici --cpus. Ovo je nova kombinacija starog --cpu-period и --cpu-quota. Postavljanjem označavamo koliko raspoloživih CPU resursa kontejner može maksimalno iskoristiti prije nego što prigušivanje počne:
- cpus - kombinacija
cpu-periodиcpu-quota. cpus = 1.5ekvivalentno podešavanjucpu-period = 100000иcpu-quota = 150000; - CPU-period - tačka , zadano 100 mikrosekundi;
- procesorska kvota - broj mikrosekundi unutra
cpu-period, koji je omeđen kontejnerom.
Šta se dešava ako instalirate nedovoljno traženi CPU?
Ako kontejneru treba više nego što je instalirao, on će ukrasti CPU od drugih procesa.
Šta će se dogoditi ako postavite prenisko CPU limit?
Pošto je CPU resurs podesiv, prigušivanje će se uključiti.
Šta se dešava ako ne navedete CPU zahtjev?
Kao i kod memorije, vrijednost zahtjeva je jednaka ograničenju.
Šta se dešava ako ne navedete CPU limit?
Kontejner će koristiti onoliko CPU-a koliko mu je potrebno. Ako je zadana politika CPU-a (LimitRange) definirana u imenskom prostoru, tada se ovo ograničenje također koristi za kontejner.
Šta se događa ako ne navedete ni zahtjev ni CPU ograničenje?
Kao i kod pamćenja, ovo je najgori scenario. Planer ne zna koliko resursa treba vašem kontejneru, a to može uzrokovati ozbiljne probleme na čvoru. Da biste to izbjegli, morate postaviti zadana ograničenja za prostore imena (LimitRange).
Zapamtite: ako zatražite više CPU-a nego što čvorovi mogu pružiti, Pod neće biti zakazan. Requests.cpu - ne minimalna vrijednost, već vrijednost dovoljna da pokrene Pod i radi bez kvarova. Ako aplikacija ne obavlja složene proračune, najbolja opcija je instalacija request.cpu <= 1 i lansirati onoliko replika koliko je potrebno.
Idealna količina traženih resursa ili ograničenje resursa
Naučili smo o ograničenosti računarskih resursa. Sada je vrijeme da odgovorite na pitanje: „Koliko resursa je potrebno mom Podu za pokretanje aplikacije bez ikakvih problema? Koja je idealna količina?
Nažalost, na ova pitanja nema jasnih odgovora. Ako ne znate kako vaša aplikacija radi ili koliko joj je CPU-a ili memorije potrebno, najbolja opcija je da aplikaciji date puno memorije i CPU-a, a zatim pokrenete testove performansi.
Pored testova performansi, pratite ponašanje aplikacije u praćenju nedelju dana. Ako grafikoni pokazuju da vaša aplikacija troši manje resursa nego što ste tražili, možete smanjiti traženu količinu CPU-a ili memorije.
Kao primjer pogledajte ovo . Prikazuje razliku između traženih resursa ili ograničenja resursa i trenutne upotrebe resursa.
zaključak
Zahtjev i ograničavanje resursa pomaže da vaš Kubernetes klaster bude zdrav. Ispravna konfiguracija ograničenja minimizira troškove i održava aplikacije u radu u svakom trenutku.
Ukratko, treba imati na umu nekoliko stvari:
- Traženi resursi su konfiguracija koja se uzima u obzir prilikom pokretanja (kada Kubernetes planira da ugosti aplikaciju). Nasuprot tome, ograničavanje resursa je važno u vrijeme izvođenja—kada se aplikacija već izvodi na čvoru.
- U poređenju sa memorijom, CPU je regulisan resurs. Ako nema dovoljno CPU-a, vaš Pod se neće isključiti i mehanizam za prigušivanje će se uključiti.
- Traženi resursi i ograničenje resursa nisu minimalne i maksimalne vrijednosti! Definiranjem traženih resursa osiguravate da će aplikacija raditi bez problema.
- Dobra praksa je postaviti zahtjev za memorijom jednak ograničenju memorije.
- Ok instalacija je zatražena
CPU <=1, ako aplikacija ne izvodi složene proračune. - Ako zatražite više resursa nego što je dostupno na čvoru, Pod nikada neće biti zakazan za taj čvor.
- Da odredite ispravnu količinu traženih resursa/ograničenja resursa, koristite testiranje opterećenja i praćenje.
Nadam se da će vam ovaj članak pomoći da shvatite osnovni koncept ograničenja resursa. I ovo znanje ćete moći primijeniti u svom radu.
Sretno!
Šta još pročitati:
- .
- .
- .
izvor: www.habr.com