Ko začnete uporabljati Kubernetes, je pogosto pozabiti na nastavitev virov vsebnika. Na tej točki je dovolj zagotoviti, da slika Docker deluje in jo je mogoče namestiti v gručo Kubernetes.
Kasneje pa je treba aplikacijo namestiti v produkcijski gruči skupaj z drugimi aplikacijami. Če želite to narediti, morate dodeliti vire za vsebnik in se prepričati, da jih je dovolj, da lahko aplikacija začne delovati in da druge delujoče aplikacije ne bodo imele težav.
Ekipa prevedel članek o virih vsebnika (CPE & MEM), zahtevah in omejitvah virov. Spoznali boste prednosti teh nastavitev in kaj se zgodi, če jih ne nastavite.
Računalniški viri
Imamo dve vrsti virov z naslednjimi enotami:
- Centralna procesna enota (CPU) - jedra;
- Pomnilnik (MEM) - bajtov.
Viri so določeni za vsak vsebnik. V naslednji datoteki Pod YAML boste videli razdelek z viri, ki vsebuje zahtevane in omejene vire:
- Zahtevani viri sklopa = vsota zahtevanih virov vseh vsebnikov;
- Omejitev virov pod = vsota vseh omejitev virov 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: 1GiPrimer zahtevanih in omejenih virov
Polje resources.requested iz specifikacije Pod je eden od elementov, ki se uporablja za iskanje želenega vozlišča. Zanj lahko že načrtujete uvedbo Poda. Kako najdete primerno vozlišče?
Kubernetes je sestavljen iz več komponent, vključno z glavnim vozliščem ali glavnim vozliščem (Kubernetes Control Plane). Glavno vozlišče ima več procesov: kube-apiserver, kube-controller-manager in kube-scheduler.
Proces kube-scheduler je odgovoren za pregledovanje na novo ustvarjenih podov in iskanje možnih delovnih vozlišč, ki se ujemajo z vsemi zahtevami podov, vključno s številom zahtevanih virov. Seznam vozlišč, ki jih najde kube-scheduler, je razvrščen. Pod je načrtovan na vozlišču z najvišjimi ocenami.
Kje bo postavljen vijolični Pod?
Na sliki lahko vidite, da bi moral kube-scheduler načrtovati nov vijolični Pod. Gruča Kubernetes vsebuje dve vozlišči: A in B. Kot lahko vidite, kube-scheduler ne more načrtovati Poda na vozlišču A - razpoložljivi (nezahtevani) viri se ne ujemajo z zahtevami vijoličnega Poda. Torej 1 GB pomnilnika, ki ga zahteva vijolični Pod, ne bo ustrezal vozlišču A, ker je razpoložljiv pomnilnik 0,5 GB. Toda vozlišče B ima dovolj virov. Posledično se kube-scheduler odloči, da je cilj vijoličnega Poda vozlišče B.
Zdaj vemo, kako zahtevani viri vplivajo na izbiro vozlišča za zagon Poda. Kakšen pa je vpliv mejnih virov?
Omejitev virov je meja, ki je CPE/MEM ne more prestopiti. Vendar pa je vir CPE prilagodljiv, tako da vsebniki, ki dosežejo svoje omejitve CPE, ne bodo povzročili izhoda Poda. Namesto tega se bo začelo dušenje procesorja. Če je dosežena omejitev uporabe MEM, bo vsebnik ustavljen zaradi OOM-Killer in znova zagnan, če to dovoljuje nastavitev RestartPolicy.
Podrobno o zahtevanih in največjih virih
Komunikacija virov med Dockerjem in Kubernetesom
Najboljši način, da pojasnite, kako delujejo zahteve za vire in omejitve virov, je predstaviti razmerje med Kubernetesom in Dockerjem. Na zgornji sliki lahko vidite, kako so povezana polja Kubernetes in zastavice za zagon Dockerja.
Spomin: zahteva in omejitev
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Kot je navedeno zgoraj, se pomnilnik meri v bajtih. Temelji na , lahko določimo pomnilnik kot število. Običajno je celo število, na primer 2678 - to je 2678 bajtov. Uporabite lahko tudi pripone G и Gi, glavna stvar je, da se spomnimo, da niso enakovredni. Prvi je decimalni, drugi pa binarni. Kot primer, omenjen v dokumentaciji k8s: 128974848, 129e6, 129M, 123Mi - sta praktično enakovredna.
Možnost Kubernetes limits.memory se ujema z zastavo --memory iz Dockerja. V primeru request.memory Za Docker ni puščice, ker Docker ne uporablja tega polja. Lahko se vprašate, ali je to sploh potrebno? Da potrebujem. Kot sem že rekel, je polje pomembno za Kubernetes. Na podlagi informacij iz njega se kube-scheduler odloči, katero vozlišče bo načrtovalo Pod.
Kaj se zgodi, če nastavite premalo pomnilnika za zahtevo?
Če je vsebnik dosegel meje zahtevanega pomnilnika, se Pod postavi v skupino Podov, ki se ustavijo, ko v vozlišču ni dovolj pomnilnika.
Kaj se zgodi, če omejitev pomnilnika nastavite prenizko?
Če vsebnik preseže omejitev pomnilnika, bo prekinjen zaradi OOM-Killed. In se bo znova zagnal, če bo mogoče, na podlagi RestartPolicy, kjer je privzeta vrednost Always.
Kaj se zgodi, če ne določite zahtevanega pomnilnika?
Kubernetes bo prevzel mejno vrednost in jo nastavil kot privzeto vrednost.
Kaj se lahko zgodi, če ne določite omejitve pomnilnika?
Vsebnik nima omejitev, uporablja lahko toliko pomnilnika, kot želi. Če začne uporabljati ves razpoložljivi pomnilnik vozlišča, ga bo OOM ubil. Vsebnik se bo nato znova zagnal, če bo to mogoče, na podlagi RestartPolicy.
Kaj se zgodi, če ne določite omejitev pomnilnika?
To je najslabši možni scenarij: razporejevalnik ne ve, koliko virov potrebuje vsebnik, kar lahko povzroči resne težave v vozlišču. V tem primeru bi bilo lepo imeti privzete omejitve imenskega prostora (nastavljene z LimitRange). Ni privzetih omejitev - Pod nima omejitev, uporablja lahko toliko pomnilnika, kot želi.
Če je zahtevani pomnilnik večji, kot ga lahko ponudi vozlišče, Pod ne bo načrtovan. Pomembno si je to zapomniti Requests.memory - ni minimalna vrednost. To je opis količine pomnilnika, ki zadostuje za neprekinjeno delovanje vsebnika.
Običajno je priporočljivo nastaviti enako vrednost za request.memory и limit.memory. To zagotavlja, da Kubernetes ne bo načrtoval Poda na vozlišču, ki ima dovolj pomnilnika za zagon Poda, vendar ne dovolj za njegovo izvajanje. Upoštevajte: načrtovanje Kubernetes Pod upošteva samo requests.memoryIn limits.memory ne upošteva.
CPU: zahteva in omejitev
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
S procesorjem je vse malo bolj zapleteno. Če se vrnemo k sliki odnosa med Kubernetesom in Dockerjem, to lahko vidite request.cpu соответствующий --cpu-shares, medtem ko limit.cpu se ujema z zastavo cpus v Dockerju.
CPE, ki ga zahteva Kubernetes, se pomnoži z 1024, kar je delež ciklov CPE. Če želite zahtevati 1 polno jedro, morate dodati cpu: 1kot je prikazano zgoraj.
Če zahtevate polno jedro (delež = 1024), to ne pomeni, da ga bo prejel vaš vsebnik. Če ima vaš gostiteljski stroj samo eno jedro in uporabljate več kot en vsebnik, si morajo vsi vsebniki deliti razpoložljivo CPU. Kako se to zgodi? Poglejmo sliko.
Zahteva CPE - enojedrni sistem
Predstavljajmo si, da imate enojedrni gostiteljski sistem, ki izvaja vsebnike. Mama (Kubernetes) je spekla pito (CPE) in jo želi razdeliti med otroke (posode). Trije otroci želijo celo pito (razmerje = 1024), drugi otrok želi polovico pite (512). Mama želi biti poštena in naredi preprost izračun.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Po izračunu bodo trije otroci prejeli 28 % jedra in ne celotnega jedra. Četrti otrok bo dobil 14 % celotnega jedra, ne polovice. Toda stvari bodo drugačne, če imate večjedrni sistem.
Zahteva CPE - Večjedrni (4) sistem
Na zgornji sliki lahko vidite, da si trije otroci želijo celo pito, eden pa polovico. Ker je mama spekla štiri pite, jih bo vsak od njenih otrok dobil, kolikor jih bo želel. V večjedrnem sistemu so procesorski viri porazdeljeni po vseh razpoložljivih procesorskih jedrih. Če je vsebnik omejen na manj kot eno polno jedro procesorja, ga lahko še vedno uporablja pri 100 %.
Zgornji izračuni so poenostavljeni, da bi razumeli, kako je CPU porazdeljen med vsebnike. Seveda poleg samih vsebnikov obstajajo tudi drugi procesi, ki prav tako uporabljajo vire procesorja. Ko so procesi v enem vsebniku nedejavni, lahko drugi uporabljajo njegov vir. CPU: "200m" соответствующий CPU: 0,2, kar pomeni približno 20% enega jedra.
Zdaj pa se pogovorimo o limit.cpu. CPU, ki ga Kubernetes omejuje, se pomnoži s 100. Rezultat je čas, ki ga vsebnik lahko porabi vsakih 100 µs (cpu-period).
limit.cpu se ujema z zastavico Docker --cpus. To je nova kombinacija starega --cpu-period и --cpu-quota. Z nastavitvijo navedemo, koliko razpoložljivih virov CPU lahko vsebnik maksimalno uporabi, preden se začne dušenje:
- cpus - kombinacija
cpu-periodиcpu-quota. cpus = 1.5enakovredna nastavitvicpu-period = 100000иcpu-quota = 150000; - CPE-obdobje - pika , privzeto 100 mikrosekund;
- cpu-kvota - število mikrosekund znotraj
cpu-period, ki je omejena s posodo.
Kaj se zgodi, če namestite premalo zahtevanega procesorja?
Če vsebnik potrebuje več, kot je nameščen, bo ukradel CPU drugim procesom.
Kaj se zgodi, če omejitev procesorja nastavite prenizko?
Ker je vir CPE nastavljiv, se bo vklopilo dušenje.
Kaj se zgodi, če ne podate zahteve CPE?
Kot pri pomnilniku je vrednost zahteve enaka omejitvi.
Kaj se zgodi, če ne določite omejitve procesorja?
Vsebnik bo uporabljal toliko procesorja, kot ga potrebuje. Če je v imenskem prostoru definiran privzeti pravilnik CPU (LimitRange), se ta omejitev uporablja tudi za vsebnik.
Kaj se zgodi, če ne podate niti zahteve niti omejitve procesorja?
Kot pri spominu je tudi to najslabši možni scenarij. Razporejevalnik ne ve, koliko sredstev potrebuje vaš vsebnik, kar lahko povzroči resne težave v vozlišču. Da bi se temu izognili, morate nastaviti privzete omejitve za imenske prostore (LimitRange).
Ne pozabite: če zahtevate več procesorja, kot ga lahko zagotovijo vozlišča, Pod ne bo načrtovan. Requests.cpu - ne minimalna vrednost, ampak vrednost, ki zadostuje za zagon Poda in delovanje brez napak. Če aplikacija ne izvaja zapletenih izračunov, je najboljša možnost namestitev request.cpu <= 1 in zaženite toliko replik, kot je potrebno.
Idealna količina zahtevanih virov ali omejitev virov
Spoznali smo omejenost računalniških virov. Zdaj je čas, da odgovorite na vprašanje: »Koliko virov potrebuje moj Pod, da brez težav zažene aplikacijo? Kakšna je idealna količina?
Na ta vprašanja žal ni jasnih odgovorov. Če ne veste, kako deluje vaša aplikacija ali koliko CPE-ja ali pomnilnika potrebuje, je najboljša možnost, da aplikaciji zagotovite veliko pomnilnika in CPE-ja ter nato izvedete preizkuse zmogljivosti.
Poleg preizkusov zmogljivosti teden dni spremljajte obnašanje aplikacije pri spremljanju. Če grafi kažejo, da vaša aplikacija porabi manj virov, kot ste zahtevali, lahko zmanjšate zahtevano količino procesorja ali pomnilnika.
Kot primer si oglejte to . Prikazuje razliko med zahtevanimi viri ali omejitvijo virov in trenutno porabo virov.
Zaključek
Zahtevanje in omejevanje virov pomaga ohranjati zdravo gručo Kubernetes. Pravilna konfiguracija omejitev zmanjša stroške in omogoča, da aplikacije ves čas delujejo.
Skratka, upoštevati je treba nekaj stvari:
- Zahtevani viri so konfiguracija, ki se upošteva ob času zagona (ko Kubernetes načrtuje gostovanje aplikacije). Nasprotno pa je omejevanje virov pomembno med izvajanjem – ko se aplikacija že izvaja v vozlišču.
- V primerjavi s pomnilnikom je CPE reguliran vir. Če ni dovolj procesorja, se vaš Pod ne bo zaustavil in mehanizem za dušenje se bo vklopil.
- Zahtevani viri in omejitev virov niso minimalne in maksimalne vrednosti! Z definiranjem zahtevanih virov zagotovite, da bo aplikacija delovala brez težav.
- Dobra praksa je, da zahtevo po pomnilniku nastavite enako omejitvi pomnilnika.
- V redu zahtevana namestitev
CPU <=1, če aplikacija ne izvaja zapletenih izračunov. - Če zahtevate več virov, kot jih je na voljo v vozlišču, Pod ne bo nikoli načrtovan za to vozlišče.
- Če želite določiti pravilno količino zahtevanih virov/omejitev virov, uporabite obremenitveno testiranje in spremljanje.
Upam, da vam bo ta članek pomagal razumeti osnovni koncept omejevanja virov. In to znanje boste lahko uporabili pri svojem delu.
Srečno!
Kaj še prebrati:
- .
- .
- .
Vir: www.habr.com