Kada počinjete s Kubernetesom, uobičajeno je zaboraviti na postavljanje resursa spremnika. U ovom trenutku dovoljno je osigurati da Docker slika radi i da se može implementirati u Kubernetes klaster.
Ali kasnije se aplikacija mora implementirati u proizvodni klaster zajedno s drugim aplikacijama. Da biste to učinili, morate dodijeliti resurse za spremnik i pobrinuti se da ih ima dovoljno za pokretanje aplikacije te da druge pokrenute aplikacije neće imati problema.
Momčad preveo članak o resursima spremnika (CPU & MEM), zahtjevima i ograničenjima resursa. Naučit ćete prednosti ovih postavki i što ć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 navedeni za svaki spremnik. U sljedećoj Pod YAML datoteci vidjet ćete odjeljak resursa koji sadrži tražene i ograničene resurse:
- Requested Pod Resources = zbroj traženih resursa svih spremnika;
- Ograničenje resursa jedinice = zbroj svih ograničenja resursa jedinice.
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 služi za pronalaženje željenog čvora. Već možete planirati njegovu implementaciju Poda. 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-scheduler odgovoran je za pregled novostvorenih podova i pronalaženje mogućih radnih čvorova koji odgovaraju svim pod zahtjevima, uključujući broj zatraženih resursa. Popis čvorova koje je kube-scheduler pronašao je rangiran. Grupa je zakazana na čvoru s najvišim rezultatima.
Gdje će biti postavljena ljubičasta Pod?
Na slici možete vidjeti da kube-scheduler treba 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 ne odgovaraju zahtjevima ljubičastog Poda. Dakle, 1 GB memorije koju traži ljubičasti Pod neće stati na čvor A, budući da je dostupna memorija 0,5 GB. Ali čvor B ima dovoljno resursa. Kao rezultat toga, kube-scheduler odlučuje da je odredište ljubičaste jedinice čvor B.
Sada znamo kako traženi resursi utječu na izbor čvora za pokretanje Poda. Ali kakav je utjecaj marginalnih resursa?
Ograničenje resursa je granica koju CPU/MEM ne može prijeći. Međutim, CPU resurs je fleksibilan, tako da spremnici koji dosegnu svoja CPU ograničenja neće uzrokovati izlaz Poda. Umjesto toga, pokrenut će se prigušivanje CPU-a. Ako se dosegne ograničenje upotrebe MEM-a, spremnik će se zaustaviti zbog OOM-Killer-a i ponovno pokrenuti ako to dopušta postavka RestartPolicy.
Detaljno traženi i maksimalni resursi
Komunikacija resursa između Dockera i Kubernetesa
Najbolji način da objasnite kako funkcioniraju zahtjevi za resursima i ograničenja resursa jest uvesti odnos između Kubernetesa i Dockera. Na gornjoj slici možete vidjeti kako su Kubernetes polja i zastavice za pokretanje Dockera povezani.
Pamćenje: zahtjev i ograničenje
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Kao što je gore spomenuto, memorija se mjeri u bajtovima. Na temelju , memoriju možemo odrediti kao broj. Obično je to cijeli broj, na primjer 2678 - odnosno 2678 bajtova. Također možete koristiti sufikse G и Gi, glavna stvar je zapamtiti da oni nisu ekvivalentni. Prvi je decimalni, a drugi je binarni. Kao primjer spomenut u k8s dokumentaciji: 128974848, 129e6, 129M, 123Mi - praktički su jednaki.
Kubernetes opcija limits.memory odgovara zastavi --memory iz Dockera. U slučaju request.memory Ne postoji strelica za Docker jer Docker ne koristi ovo polje. Možda se pitate je li to uopće potrebno? Da treba. Kao što sam već rekao, polje je važno za Kubernetes. Na temelju informacija iz njega, kube-scheduler odlučuje koji će čvor rasporediti Pod.
Što se događa ako postavite nedovoljno memorije za zahtjev?
Ako je spremnik dosegao granice tražene memorije, tada se Pod postavlja u grupu Podova koji se zaustavljaju kada u čvoru nema dovoljno memorije.
Što se događa ako ograničenje memorije postavite prenisko?
Ako spremnik premaši ograničenje memorije, bit će prekinut zbog OOM-killed. I ponovno će se pokrenuti ako je moguće na temelju RestartPolicy gdje je zadana vrijednost Always.
Što se događa ako ne navedete traženu memoriju?
Kubernetes će uzeti graničnu vrijednost i postaviti je kao zadanu vrijednost.
Što se može dogoditi ako ne navedete ograničenje memorije?
Spremnik nema ograničenja; može koristiti onoliko memorije koliko želi. Ako počne koristiti svu dostupnu memoriju čvora, tada će ga OOM ubiti. Spremnik će se zatim ponovno pokrenuti ako je moguće na temelju RestartPolicy.
Što se događa ako ne navedete ograničenja memorije?
Ovo je najgori mogući scenarij: planer ne zna koliko resursa zahtijeva spremnik, a to može uzrokovati ozbiljne probleme na čvoru. U ovom slučaju, bilo bi lijepo imati zadana ograničenja na prostoru imena (koja postavlja LimitRange). Nema zadanih ograničenja - Pod nema ograničenja, može koristiti onoliko memorije 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 spremnik neprekidno radi.
Obično se preporučuje postaviti istu vrijednost za request.memory и limit.memory. Ovo osigurava da Kubernetes neće zakazati Pod na čvoru koji ima dovoljno memorije za pokretanje Poda, ali ne dovoljno za njegovo pokretanje. Imajte na umu: Kubernetes Pod planiranje uzima u obzir samo requests.memoryI limits.memory ne uzima u obzir.
CPU: zahtjev i ograničenje
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
S CPU-om sve je malo kompliciranije. Vraćajući se na sliku odnosa između Kubernetesa i Dockera, to možete vidjeti request.cpu odgovara --cpu-shares, dok limit.cpu odgovara zastavi cpus u Dockeru.
CPU koji Kubernetes zahtijeva množi se s 1024, omjerom CPU ciklusa. Ako želite zatražiti 1 punu jezgru, morate dodati cpu: 1kao što je gore prikazano.
Zahtjev za puni kernel (proporcija = 1024) ne znači da će ga vaš spremnik primiti. Ako vaš glavni stroj ima samo jednu jezgru i koristite više od jednog spremnika, tada svi spremnici moraju međusobno dijeliti dostupni CPU. Kako se to događa? Pogledajmo sliku.
CPU Zahtjev - Jednojezgreni sustav
Zamislimo da imate jednojezgreni host sustav koji pokreće spremnike. Mama (Kubernetes) je ispekla pitu (CPU) i želi je podijeliti djeci (kontejneri). Troje djece želi cijelu pitu (proporcija = 1024), drugo dijete želi pola pite (512). Mama želi biti poštena i napravi jednostavan izračun.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Prema izračunu, troje djece će dobiti 28% jezgre, a ne cijelu jezgru. Četvrto dijete će dobiti 14% punog kernela, a ne pola. Ali stvari će biti drugačije ako imate višejezgreni sustav.
Zahtjev za CPU - višejezgreni (4) sustav
Na gornjoj slici možete vidjeti da troje djece želi cijelu pitu, a jedno pola. Budući da je mama ispekla četiri pite, svako će njezino dijete dobiti koliko želi. U višejezgrenom sustavu resursi procesora raspoređeni su na sve dostupne procesorske jezgre. Ako je spremnik ograničen na manje od jedne pune CPU jezgre, još uvijek ga može koristiti na 100%.
Gore navedeni izračuni su pojednostavljeni kako bi se razumjelo kako se CPU raspoređuje među spremnicima. Naravno, osim samih spremnika, postoje i drugi procesi koji također koriste CPU resurse. Kada procesi u jednom spremniku miruju, drugi mogu koristiti njegove resurse. CPU: "200m" odgovara CPU: 0,2, što znači otprilike 20% jedne jezgre.
Sada razgovarajmo o limit.cpu. CPU koji Kubernetes ograničava množi se sa 100. Rezultat je količina vremena koju spremnik može koristiti svakih 100 µs (cpu-period).
limit.cpu odgovara zastavi Docker --cpus. Ovo je nova kombinacija starog --cpu-period и --cpu-quota. Postavljanjem, pokazujemo koliko dostupnih CPU resursa spremnik može maksimalno koristiti prije nego što započne prigušivanje:
- procesor - kombinacija
cpu-periodиcpu-quota. cpus = 1.5ekvivalent postavljanjucpu-period = 100000иcpu-quota = 150000; - CPU-razdoblje - točka , zadano 100 mikrosekundi;
- cpu-kvota - broj mikrosekundi unutra
cpu-period, koji je omeđen kontejnerom.
Što se događa ako instalirate nedovoljno traženog CPU-a?
Ako spremnik treba više nego što je instalirano, ukrast će CPU drugim procesima.
Što se događa ako postavite ograničenje CPU-a prenisko?
Budući da je CPU resurs podesiv, prigušivanje će se uključiti.
Što se događa ako ne navedete CPU zahtjev?
Kao i kod memorije, vrijednost zahtjeva jednaka je ograničenju.
Što se događa ako ne navedete CPU ograničenje?
Spremnik će koristiti onoliko procesora koliko mu je potrebno. Ako je zadana CPU politika (LimitRange) definirana u prostoru imena, tada se ovo ograničenje također koristi za spremnik.
Što se događa ako ne navedete zahtjev ili CPU ograničenje?
Kao i kod pamćenja, ovo je najgori mogući scenarij. Planer ne zna koliko resursa treba vašem spremniku, a to može uzrokovati ozbiljne probleme na čvoru. Da biste to izbjegli, trebate 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 za pokretanje Poda i rad bez kvarova. Ako aplikacija ne izvodi složene izračune, najbolja opcija je instalirati 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čunalnih resursa. Sada je vrijeme da odgovorite na pitanje: “Koliko resursa moj Pod zahtijeva da pokrene aplikaciju bez ikakvih problema? Koji je idealan iznos?
Nažalost, na ova pitanja nema jasnih odgovora. Ako ne znate kako vaša aplikacija radi ili koliko CPU-a ili memorije treba, najbolja opcija je dati aplikaciji puno memorije i CPU-a, a zatim pokrenuti testove performansi.
Uz testove performansi, pratite ponašanje aplikacije u nadzoru tjedan 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
Zahtijevanje i ograničavanje resursa pomaže u održavanju zdravog Kubernetes klastera. Pravilna konfiguracija ograničenja smanjuje troškove i omogućuje rad aplikacija u svakom trenutku.
Ukratko, morate imati na umu nekoliko stvari:
- Traženi resursi su konfiguracija koja se uzima u obzir prilikom pokretanja (kada Kubernetes planira ugostiti aplikaciju). Nasuprot tome, ograničavanje resursa važno je tijekom izvođenja—kada se aplikacija već izvodi na čvoru.
- U usporedbi s memorijom, CPU je regulirani 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 memoriju jednak memorijskom ograničenju.
- Zatražena u redu instalacija
CPU <=1, ako aplikacija ne izvodi složene izračune. - Ako zatražite više resursa nego što je dostupno na čvoru, Pod nikada neće biti zakazan za taj čvor.
- Za određivanje točne količine traženih resursa/ograničenja resursa, koristite testiranje opterećenja i praćenje.
Nadam se da će vam ovaj članak pomoći razumjeti osnovni koncept ograničenja resursa. I moći ćete to znanje primijeniti u svom radu.
Sretno!
Što još pročitati:
- .
- .
- .
Izvor: www.habr.com