Wanneer jy met Kubernetes begin, is dit algemeen om te vergeet van die opstel van houerhulpbronne. Op hierdie stadium is dit genoeg om te verseker dat die Docker-beeld werk en na die Kubernetes-kluster ontplooi kan word.
Maar later moet die toepassing saam met ander toepassings in 'n produksiekluster ontplooi word. Om dit te doen, moet jy hulpbronne vir die houer toewys en seker maak dat daar genoeg van hulle is om die toepassing aan die gang te kry, en dat ander lopende toepassings nie probleme sal ondervind nie.
Span het 'n artikel oor houerhulpbronne (CPU & MEM), versoeke en hulpbronbeperkings vertaal. Jy sal die voordele van hierdie instellings leer en wat gebeur as jy dit nie stel nie.
Rekenaarhulpbronne
Ons het twee tipes hulpbronne met die volgende eenhede:
- Sentrale verwerkingseenheid (CPU) - kerns;
- Geheue (MEM) - grepe.
Hulpbronne word vir elke houer gespesifiseer. In die volgende Pod YAML-lêer sal jy 'n hulpbronafdeling sien wat die gevraagde en beperkende hulpbronne bevat:
- Versoekte Pod-hulpbronne = som van aangevraagde hulpbronne van alle houers;
- Peulhulpbronlimiet = Som van alle Peulhulpbronlimiete.
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: 1GiVoorbeeld van gevraagde en beperkte hulpbronne
Veld resources.requested uit die spesifikasie Pod is een van die elemente wat gebruik word om die verlangde nodus te vind. Jy kan reeds Pod-ontplooiing daarvoor beplan. Hoe vind jy 'n geskikte nodus?
Kubernetes bestaan uit verskeie komponente, insluitend 'n hoofnodus of hoofnodus (Kubernetes Control Plane). Die hoofnodus het verskeie prosesse: kube-apibediener, kube-beheerder-bestuurder en kube-skeduleerder.
Die kube-skeduleerder-proses is verantwoordelik vir die hersiening van nuutgeskepte peule en om moontlike werkernodusse te vind wat ooreenstem met alle peulversoeke, insluitend die aantal hulpbronne wat versoek word. Die lys nodusse wat deur kube-skeduleerder gevind word, word gerangskik. Die peul is geskeduleer op die nodus met die hoogste tellings.
Waar sal die pers Peul geplaas word?
In die prentjie kan jy sien dat kube-skeduleerder 'n nuwe pers Peul moet skeduleer. Die Kubernetes-kluster bevat twee nodusse: A en B. Soos jy kan sien, kan kube-skeduleerder nie 'n Pod op nodus A skeduleer nie - die beskikbare (onversoekte) hulpbronne stem nie ooreen met die versoeke van die pers Peul nie. Dus, die 1 GB geheue wat deur die pers Pod versoek word, sal nie op nodus A pas nie, aangesien die beskikbare geheue 0,5 GB is. Maar nodus B het genoeg hulpbronne. As gevolg hiervan besluit kube-skeduleerder dat die bestemming van die pers Peul nodus B is.
Nou weet ons hoe die gevraagde hulpbronne die keuse van nodus beïnvloed om die Pod te laat loop. Maar wat is die impak van marginale hulpbronne?
Die hulpbronlimiet is 'n grens wat die SVE/MEM nie kan oorsteek nie. Die SVE-hulpbron is egter buigsaam, so houers wat hul SVE-limiete bereik, sal nie die Pod laat verlaat nie. In plaas daarvan sal SVE-versnelling begin. As die MEM-gebruiklimiet bereik word, sal die houer gestop word as gevolg van OOM-Killer en herbegin word as dit toegelaat word deur die RestartPolicy-instelling.
Gevra en maksimum hulpbronne in detail
Hulpbronkommunikasie tussen Docker en Kubernetes
Die beste manier om te verduidelik hoe hulpbronversoeke en hulpbronlimiete werk, is om die verhouding tussen Kubernetes en Docker bekend te stel. In die prent hierbo kan u sien hoe die Kubernetes-velde en Docker-opstartvlae verband hou.
Geheue: versoek en beperking
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Soos hierbo genoem, word geheue in grepe gemeet. Gebaseer op , kan ons geheue as 'n getal spesifiseer. Gewoonlik is dit 'n heelgetal, byvoorbeeld 2678 - dit wil sê 2678 grepe. Jy kan ook agtervoegsels gebruik G и Gi, die belangrikste ding is om te onthou dat hulle nie gelykstaande is nie. Die eerste is desimale en die tweede is binêr. Soos die voorbeeld wat in die k8s-dokumentasie genoem word: 128974848, 129e6, 129M, 123Mi - hulle is feitlik gelykwaardig.
Kubernetes opsie limits.memory pas by die vlag --memory van Docker. In die geval van request.memory Daar is geen pyltjie vir Docker nie, want Docker gebruik nie hierdie veld nie. Jy mag dalk vra, is dit selfs nodig? Ja nodig. Soos ek voorheen gesê het, maak die veld saak vir Kubernetes. Gebaseer op die inligting daaruit, besluit kube-skeduleerder op watter nodus om die Pod te skeduleer.
Wat gebeur as jy onvoldoende geheue vir 'n versoek stel?
As die houer die limiete van die gevraagde geheue bereik het, word die Peul in 'n groep Peule geplaas wat stop wanneer daar nie genoeg geheue in die nodus is nie.
Wat gebeur as jy die geheuelimiet te laag stel?
As die houer die geheuelimiet oorskry, sal dit beëindig word as gevolg van OOM-Killed. En sal herbegin indien moontlik gebaseer op RestartPolicy waar die verstekwaarde is Always.
Wat gebeur as jy nie die gevraagde geheue spesifiseer nie?
Kubernetes sal die limietwaarde neem en dit as die verstekwaarde stel.
Wat kan gebeur as jy nie 'n geheuelimiet spesifiseer nie?
Die houer het geen beperkings nie; dit kan soveel geheue gebruik as wat dit wil. As hy al die beskikbare geheue van die nodus begin gebruik, sal OOM hom doodmaak. Die houer sal dan herbegin word indien moontlik gebaseer op RestartPolicy.
Wat gebeur as jy nie geheuelimiete spesifiseer nie?
Dit is die ergste scenario: die skeduleerder weet nie hoeveel hulpbronne die houer benodig nie, en dit kan ernstige probleme op die nodus veroorsaak. In hierdie geval sal dit lekker wees om versteklimiete op die naamruimte te hê (gestel deur LimitRange). Daar is geen versteklimiete nie - die Pod het geen perke nie, dit kan soveel geheue gebruik as wat hy wil.
As die gevraagde geheue meer is as wat die nodus kan bied, sal die Pod nie geskeduleer word nie. Dit is belangrik om dit te onthou Requests.memory - nie die minimum waarde nie. Dit is 'n beskrywing van die hoeveelheid geheue wat voldoende is om die houer voortdurend aan die gang te hou.
Dit word gewoonlik aanbeveel om dieselfde waarde vir te stel request.memory и limit.memory. Dit verseker dat Kubernetes nie 'n Pod sal skeduleer op 'n nodus wat genoeg geheue het om die Pod te laat loop, maar nie genoeg om dit te laat loop nie. Hou in gedagte: Kubernetes Pod-beplanning neem slegs in ag requests.memoryEn limits.memory in ag neem nie.
SVE: versoek en beperk
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Met 'n SVE is alles 'n bietjie meer ingewikkeld. As u terugkeer na die prentjie van die verhouding tussen Kubernetes en Docker, kan u dit sien request.cpu соответствует --cpu-shares, terwyl limit.cpu pas by die vlag cpus in Docker.
Die SVE wat Kubernetes versoek word vermenigvuldig met 1024, die proporsie SVE-siklusse. As jy 1 volle kern wil aanvra, moet jy byvoeg cpu: 1soos hierbo getoon.
Om 'n volle kern (proporsie = 1024) te versoek, beteken nie dat jou houer dit sal ontvang nie. As jou gasheermasjien net een kern het en jy gebruik meer as een houer, dan moet alle houers die beskikbare SVE tussen hulle deel. Hoe gebeur dit? Kom ons kyk na die prentjie.
SVE-versoek - Enkelkernstelsel
Kom ons stel ons voor dat u 'n enkelkern-gasheerstelsel het wat houers gebruik. Ma (Kubernetes) het 'n pastei (CPU) gebak en wil dit tussen kinders (houers) verdeel. Drie kinders wil 'n hele pastei hê (proporsie = 1024), 'n ander kind wil 'n halwe pastei hê (512). Ma wil regverdig wees en maak 'n eenvoudige berekening.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Op grond van die berekening sal drie kinders 28% van die kern ontvang, en nie die hele kern nie. Die vierde kind sal 14% van die volle pit kry, nie die helfte nie. Maar dinge sal anders wees as jy 'n multi-kern stelsel het.
SVE-versoek - Multi-Core (4) Stelsel
In die prent hierbo kan jy sien dat drie kinders 'n hele pastei wil hê, en een wil die helfte hê. Aangesien ma vier pasteie gebak het, sal elkeen van haar kinders soveel kry as wat hulle wil. In 'n multikernstelsel word verwerkerhulpbronne oor alle beskikbare verwerkerkerne versprei. As 'n houer tot minder as een volle SVE-kern beperk is, kan dit dit steeds teen 100% gebruik.
Bogenoemde berekeninge is vereenvoudig om te verstaan hoe SVE tussen houers versprei word. Natuurlik, behalwe die houers self, is daar ander prosesse wat ook SVE-hulpbronne gebruik. Wanneer prosesse in een houer ledig is, kan ander sy hulpbron gebruik. CPU: "200m" соответствует CPU: 0,2, wat ongeveer 20% van een kern beteken.
Kom ons praat nou oor limit.cpu. Die SVE wat Kubernetes beperk, word vermenigvuldig met 100. Die resultaat is die hoeveelheid tyd wat die houer elke 100 µs kan gebruik (cpu-period).
limit.cpu pas by die Docker-vlag --cpus. Dit is 'n nuwe kombinasie van oud --cpu-period и --cpu-quota. Deur dit in te stel, dui ons aan hoeveel beskikbare SVE-hulpbronne die houer maksimaal kan gebruik voordat versperring begin:
- cpus - kombinasie
cpu-periodиcpu-quota. cpus = 1.5gelykstaande aan instellingcpu-period = 100000иcpu-quota = 150000; - SVE-tydperk - tydperk , verstek 100 mikrosekondes;
- cpu-kwota - aantal mikrosekondes binne
cpu-period, wat deur die houer begrens word.
Wat gebeur as jy onvoldoende versoekte SVE installeer?
As die houer meer benodig as wat dit geïnstalleer het, sal dit SVE van ander prosesse steel.
Wat gebeur as jy die SVE-limiet te laag stel?
Aangesien die SVE-hulpbron verstelbaar is, sal versnelling aanskakel.
Wat gebeur as jy nie 'n SVE-versoek spesifiseer nie?
Soos met geheue, is die versoekwaarde gelyk aan die limiet.
Wat gebeur as jy nie 'n SVE-limiet spesifiseer nie?
Die houer sal soveel SVE gebruik as wat dit nodig het. As 'n verstek SVE-beleid (LimitRange) in die naamruimte gedefinieer word, word hierdie limiet ook vir die houer gebruik.
Wat gebeur as jy nie 'n versoek of 'n SVE-limiet spesifiseer nie?
Soos met geheue, is dit die ergste scenario. Die skeduleerder weet nie hoeveel hulpbronne jou houer benodig nie, en dit kan ernstige probleme op die nodus veroorsaak. Om dit te vermy, moet jy versteklimiete vir naamruimtes (LimitRange) stel.
Onthou: as jy meer SVE aanvra as wat die nodusse kan voorsien, sal die Pod nie geskeduleer word nie. Requests.cpu - nie die minimum waarde nie, maar 'n waarde wat voldoende is om die Pod te begin en sonder mislukkings te werk. As die toepassing nie komplekse berekeninge uitvoer nie, is die beste opsie om te installeer request.cpu <= 1 en begin soveel replikas as wat nodig is.
Ideale hoeveelheid aangevraagde hulpbronne of hulpbronlimiet
Ons het geleer oor die beperking van rekenaarhulpbronne. Nou is dit tyd om die vraag te beantwoord: "Hoeveel hulpbronne benodig my Pod om die toepassing sonder enige probleme te laat loop? Wat is die ideale hoeveelheid?
Ongelukkig is daar geen duidelike antwoorde op hierdie vrae nie. As jy nie weet hoe jou toepassing werk of hoeveel SVE of geheue dit benodig nie, is die beste opsie om die toepassing baie geheue en SVE te gee en dan prestasietoetse uit te voer.
Benewens prestasietoetse, monitor die toepassing se gedrag in monitering vir 'n week. As die grafieke aandui dat jou toepassing minder hulpbronne verbruik as wat jy versoek het, kan jy die hoeveelheid SVE of geheue wat versoek word verminder.
Sien dit as voorbeeld . Dit wys die verskil tussen die gevraagde hulpbronne of hulpbronlimiet en die huidige hulpbrongebruik.
Gevolgtrekking
Om hulpbronne te versoek en te beperk help om jou Kubernetes-groepering gesond te hou. Behoorlike limietkonfigurasie verminder koste en hou toepassings te alle tye aan die gang.
Kortliks, daar is 'n paar dinge om in gedagte te hou:
- Aangevraagde hulpbronne is 'n konfigurasie wat in ag geneem word tydens aanvangstyd (wanneer Kubernetes beplan om die toepassing aan te bied). Daarteenoor is die beperking van hulpbronne belangrik tydens looptyd—wanneer die toepassing reeds op die nodus loop.
- In vergelyking met geheue, is die SVE 'n gereguleerde hulpbron. As daar nie genoeg SVE is nie, sal jou Pod nie afskakel nie en die smoormeganisme sal aanskakel.
- Aangevraagde hulpbronne en hulpbronlimiet is nie minimum en maksimum waardes nie! Deur die hulpbronne wat versoek word te definieer, verseker jy dat die toepassing sonder probleme sal loop.
- 'n Goeie praktyk is om die geheueversoek gelyk aan die geheuelimiet te stel.
- Ok installasie versoek
CPU <=1, as die toepassing nie komplekse berekeninge uitvoer nie. - As jy meer hulpbronne aanvra as wat op 'n nodus beskikbaar is, sal die Pod nooit na daardie nodus geskeduleer word nie.
- Om die korrekte hoeveelheid aangevraagde hulpbronne/hulpbronlimiete te bepaal, gebruik lastoetsing en monitering.
Ek hoop dat hierdie artikel jou help om die basiese konsep van hulpbronbeperking te verstaan. En jy sal hierdie kennis in jou werk kan toepas.
Good Luck!
Wat anders om te lees:
- .
- .
- .
Bron: will.com