Wanneer u met Kubernetes begint, is het gebruikelijk dat u het instellen van containerresources vergeet. Op dit punt is het voldoende om ervoor te zorgen dat de Docker-image werkt en kan worden geïmplementeerd in het Kubernetes-cluster.
Maar later moet de applicatie samen met andere applicaties in een productiecluster worden ingezet. Om dit te doen, moet u bronnen voor de container toewijzen en ervoor zorgen dat er voldoende bronnen zijn om de applicatie aan de praat te krijgen, en dat andere actieve applicaties geen problemen zullen ondervinden.
Team vertaalde een artikel over containerbronnen (CPU & MEM), verzoeken en resourcebeperkingen. U leert de voordelen van deze instellingen en wat er gebeurt als u ze niet instelt.
Rekenhulpmiddelen
We hebben twee soorten grondstoffen met de volgende eenheden:
- Centrale verwerkingseenheid (CPU) - kernen;
- Geheugen (MEM) - bytes.
Voor elke container worden resources gespecificeerd. In het volgende Pod YAML-bestand ziet u een bronnensectie die de gevraagde en beperkte bronnen bevat:
- Aangevraagde podbronnen = som van de aangevraagde bronnen van alle containers;
- Pod-bronlimiet = Som van alle pod-bronlimieten.
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 middelen
Veld resources.requested uit de specificatie Pod is een van de elementen die wordt gebruikt om het gewenste knooppunt te vinden. U kunt de Pod-implementatie er al voor plannen. Hoe vind je een geschikt knooppunt?
Kubernetes bestaat uit verschillende componenten, waaronder een masternode of masternode (Kubernetes Control Plane). Het masterknooppunt heeft verschillende processen: kube-apiserver, kube-controller-manager en kube-scheduler.
Het kube-scheduler-proces is verantwoordelijk voor het beoordelen van nieuw gemaakte pods en het vinden van mogelijke werkknooppunten die overeenkomen met alle pod-aanvragen, inclusief het aantal aangevraagde resources. De lijst met knooppunten gevonden door kube-scheduler wordt gerangschikt. De pod wordt gepland op het knooppunt met de hoogste scores.
Waar wordt de paarse Pod geplaatst?
Op de afbeelding zie je dat de kube-scheduler een nieuwe paarse Pod moet plannen. Het Kubernetes-cluster bevat twee knooppunten: A en B. Zoals u kunt zien, kan kube-scheduler geen pod plannen op knooppunt A: de beschikbare (ongevraagde) bronnen komen niet overeen met de verzoeken van de paarse pod. De door de paarse Pod gevraagde 1 GB geheugen past dus niet op knooppunt A, aangezien het beschikbare geheugen 0,5 GB bedraagt. Maar knooppunt B heeft voldoende bronnen. Als gevolg hiervan besluit de kube-scheduler dat de bestemming van de paarse Pod knooppunt B is.
Nu weten we hoe de gevraagde bronnen de keuze van het knooppunt beïnvloeden waarop de Pod moet worden uitgevoerd. Maar wat is de impact van marginale hulpbronnen?
De resourcelimiet is een grens die de CPU/MEM niet kan overschrijden. De CPU-bron is echter flexibel, dus containers die hun CPU-limiet bereiken, zullen er niet voor zorgen dat de Pod wordt afgesloten. In plaats daarvan begint de CPU-throttling. Als de MEM-gebruikslimiet wordt bereikt, wordt de container gestopt vanwege OOM-Killer en opnieuw gestart als dit wordt toegestaan door de RestartPolicy-instelling.
Gevraagde en maximale middelen in detail
Resourcecommunicatie tussen Docker en Kubernetes
De beste manier om uit te leggen hoe resourceverzoeken en resourcelimieten werken, is door de relatie tussen Kubernetes en Docker te introduceren. In de afbeelding hierboven kun je zien hoe de Kubernetes-velden en Docker-opstartvlaggen met elkaar samenhangen.
Geheugen: verzoek en beperking
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Zoals hierboven vermeld, wordt geheugen gemeten in bytes. Gebaseerd op , kunnen we het geheugen als een getal specificeren. Meestal is het een geheel getal, bijvoorbeeld 2678 - dat wil zeggen 2678 bytes. Je kunt ook achtervoegsels gebruiken G и Gi, het belangrijkste is om te onthouden dat ze niet gelijkwaardig zijn. De eerste is decimaal en de tweede is binair. Zoals het voorbeeld genoemd in de k8s-documentatie: 128974848, 129e6, 129M, 123Mi - ze zijn praktisch gelijkwaardig.
Kubernetes-optie limits.memory past bij de vlag --memory van Docker. In het geval van request.memory Er is geen pijl voor Docker omdat Docker dit veld niet gebruikt. Je kunt je afvragen: is dit überhaupt wel nodig? Ja nodig. Zoals ik al eerder zei, is het veld van belang voor Kubernetes. Op basis van de informatie daaruit beslist kube-scheduler welk knooppunt de Pod moet plannen.
Wat gebeurt er als u onvoldoende geheugen instelt voor een verzoek?
Als de container de limiet van het gevraagde geheugen heeft bereikt, wordt de Pod in een groep Pods geplaatst die stopt als er niet genoeg geheugen in het knooppunt is.
Wat gebeurt er als u de geheugenlimiet te laag instelt?
Als de container de geheugenlimiet overschrijdt, wordt deze beëindigd vanwege OOM-Killed. En zal indien mogelijk opnieuw opstarten op basis van RestartPolicy waar de standaardwaarde is Always.
Wat gebeurt er als u het gevraagde geheugen niet opgeeft?
Kubernetes neemt de limietwaarde en stelt deze in als de standaardwaarde.
Wat kan er gebeuren als u geen geheugenlimiet opgeeft?
De container kent geen beperkingen; hij kan zoveel geheugen gebruiken als hij wil. Als hij al het beschikbare geheugen van het knooppunt gaat gebruiken, zal OOM hem doden. Vervolgens wordt de container indien mogelijk opnieuw opgestart op basis van RestartPolicy.
Wat gebeurt er als u geen geheugenlimieten opgeeft?
Dit is het worstcasescenario: de planner weet niet hoeveel bronnen de container nodig heeft, en dit kan ernstige problemen op het knooppunt veroorzaken. In dit geval zou het prettig zijn om standaardlimieten voor de naamruimte te hebben (ingesteld door LimitRange). Er zijn geen standaardlimieten - de Pod heeft geen limieten, hij kan zoveel geheugen gebruiken als hij wil.
Als het gevraagde geheugen meer is dan het knooppunt kan bieden, wordt de Pod niet gepland. Het is belangrijk om dat te onthouden Requests.memory - niet de minimumwaarde. Dit is een beschrijving van de hoeveelheid geheugen die voldoende is om de container continu te laten draaien.
Het wordt doorgaans aanbevolen om dezelfde waarde in te stellen voor request.memory и limit.memory. Dit zorgt ervoor dat Kubernetes geen Pod plant op een knooppunt dat voldoende geheugen heeft om de Pod uit te voeren, maar niet genoeg om deze uit te voeren. Houd er rekening mee: bij de planning van Kubernetes Pod wordt alleen rekening gehouden met requests.memoryEn limits.memory houdt geen rekening mee.
CPU: verzoek en limiet
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Met een CPU is alles iets ingewikkelder. Terugkomend op het beeld van de relatie tussen Kubernetes en Docker, dat zie je request.cpu komt overeen met --cpu-sharesOverwegende dat de limit.cpu past bij de vlag cpus in Docker.
De CPU die Kubernetes vraagt, wordt vermenigvuldigd met 1024, het aandeel CPU-cycli. Als u 1 volledige kern wilt aanvragen, moet u toevoegen cpu: 1zoals hierboven getoond.
Het aanvragen van een volledige kernel (proportie = 1024) betekent niet dat uw container deze zal ontvangen. Als uw hostmachine slechts één kern heeft en u meer dan één container gebruikt, moeten alle containers de beschikbare CPU onderling delen. Hoe gebeurde dit? Laten we naar de foto kijken.
CPU-verzoek - Single Core-systeem
Laten we ons voorstellen dat u een single-core hostsysteem heeft waarop containers draaien. Moeder (Kubernetes) heeft een taart gebakken (CPU) en wil deze verdelen over de kinderen (containers). Drie kinderen willen een hele taart (proportie = 1024), een ander kind wil een halve taart (512). Moeder wil eerlijk zijn en maakt een eenvoudige berekening.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Op basis van de berekening krijgen drie kinderen 28% van de kern, en niet de hele kern. Het vierde kind krijgt 14% van de volledige kernel, niet de helft. Maar de dingen zullen anders zijn als je een multi-core systeem hebt.
CPU-verzoek - Multi-Core (4) systeem
In de afbeelding hierboven zie je dat drie kinderen een hele taart willen, en één de helft. Omdat moeder vier taarten heeft gebakken, krijgt elk van haar kinderen er zoveel als ze willen. In een multi-coresysteem worden processorbronnen verdeeld over alle beschikbare processorkernen. Als een container beperkt is tot minder dan één volledige CPU-kern, kan deze deze nog steeds voor 100% gebruiken.
De bovenstaande berekeningen zijn vereenvoudigd om te begrijpen hoe de CPU over containers wordt verdeeld. Naast de containers zelf zijn er natuurlijk nog andere processen die ook CPU-bronnen gebruiken. Wanneer processen in één container inactief zijn, kunnen anderen de bron ervan gebruiken. CPU: "200m" komt overeen met CPU: 0,2, wat ongeveer 20% van één kern betekent.
Laten we het nu hebben over limit.cpu. De CPU die Kubernetes beperkt, wordt vermenigvuldigd met 100. Het resultaat is de hoeveelheid tijd die de container per 100 µs kan gebruiken (cpu-period).
limit.cpu komt overeen met de Docker-vlag --cpus. Dit is een nieuwe combinatie van oud --cpu-period и --cpu-quota. Door dit in te stellen, geven we aan hoeveel beschikbare CPU-bronnen de container maximaal kan gebruiken voordat de beperking begint:
- cpu's - combinatie
cpu-periodиcpu-quota. cpus = 1.5gelijk aan instellingcpu-period = 100000иcpu-quota = 150000; - CPU-periode - periode , standaard 100 microseconden;
- CPU-quota - aantal microseconden binnen
cpu-period, die wordt begrensd door de container.
Wat gebeurt er als u onvoldoende gevraagde CPU installeert?
Als de container meer nodig heeft dan hij heeft geïnstalleerd, steelt hij de CPU van andere processen.
Wat gebeurt er als je de CPU-limiet te laag instelt?
Omdat de CPU-bron aanpasbaar is, wordt de beperking ingeschakeld.
Wat gebeurt er als u geen CPU-verzoek opgeeft?
Net als bij geheugen is de verzoekwaarde gelijk aan de limiet.
Wat gebeurt er als u geen CPU-limiet opgeeft?
De container gebruikt zoveel CPU als nodig is. Als er een standaard CPU-beleid (LimitRange) is gedefinieerd in de naamruimte, wordt deze limiet ook gebruikt voor de container.
Wat gebeurt er als u geen verzoek of CPU-limiet opgeeft?
Net als bij het geheugen is dit het worstcasescenario. De planner weet niet hoeveel bronnen uw container nodig heeft, en dit kan ernstige problemen op het knooppunt veroorzaken. Om dit te voorkomen, moet u standaardlimieten voor naamruimten instellen (LimitRange).
Let op: als u meer CPU aanvraagt dan de knooppunten kunnen bieden, wordt de Pod niet gepland. Requests.cpu - niet de minimumwaarde, maar een waarde die voldoende is om de Pod te starten en zonder fouten te werken. Als de applicatie geen complexe berekeningen uitvoert, is installeren de beste optie request.cpu <= 1 en lanceer zoveel replica's als nodig is.
Ideale hoeveelheid gevraagde bronnen of resourcelimiet
We leerden over de beperkingen van computerbronnen. Nu is het tijd om de vraag te beantwoorden: “Hoeveel bronnen heeft mijn Pod nodig om de applicatie zonder problemen uit te voeren? Wat is het ideale bedrag?
Helaas bestaan er geen duidelijke antwoorden op deze vragen. Als u niet weet hoe uw applicatie werkt of hoeveel CPU of geheugen deze nodig heeft, is de beste optie om de applicatie veel geheugen en CPU te geven en vervolgens prestatietests uit te voeren.
Houd naast prestatietests het gedrag van de applicatie tijdens de monitoring een week lang in de gaten. Als uit de grafieken blijkt dat uw toepassing minder bronnen verbruikt dan u had aangevraagd, kunt u de gevraagde hoeveelheid CPU of geheugen verminderen.
Als voorbeeld zie dit . Het geeft het verschil weer tussen de aangevraagde bronnen of resourcelimiet en het huidige resourcegebruik.
Conclusie
Door resources aan te vragen en te beperken, blijft uw Kubernetes-cluster gezond. Een juiste limietconfiguratie minimaliseert de kosten en zorgt ervoor dat applicaties te allen tijde actief blijven.
Kortom, er zijn een paar dingen waar u rekening mee moet houden:
- De aangevraagde bronnen zijn een configuratie waarmee rekening wordt gehouden tijdens het opstarten (wanneer Kubernetes van plan is de applicatie te hosten). Het beperken van bronnen is daarentegen belangrijk tijdens runtime, wanneer de applicatie al op het knooppunt draait.
- Vergeleken met het geheugen is de CPU een gereguleerde hulpbron. Als er niet genoeg CPU is, wordt uw Pod niet uitgeschakeld en wordt het beperkingsmechanisme ingeschakeld.
- Aangevraagde bronnen en resourcelimiet zijn geen minimum- en maximumwaarden! Door de gevraagde resources te definiëren, zorgt u ervoor dat de applicatie zonder problemen draait.
- Een goede gewoonte is om het geheugenverzoek gelijk te stellen aan de geheugenlimiet.
- Ok installatie aangevraagd
CPU <=1, als de toepassing geen complexe berekeningen uitvoert. - Als u meer bronnen aanvraagt dan beschikbaar zijn op een knooppunt, zal de Pod nooit op dat knooppunt worden gepland.
- Om de juiste hoeveelheid aangevraagde resources/resourcelimieten te bepalen, gebruikt u loadtests en monitoring.
Ik hoop dat dit artikel je helpt het basisconcept van beperkte middelen te begrijpen. En deze kennis kun je toepassen in je werk.
Good Luck!
Wat nog meer te lezen:
- .
- .
- .
Bron: www.habr.com