Voor elke Kubernetes-resource is het mogelijk om twee soorten vereisten in te stellen ā Requests en Limits. De eerste beschrijft de minimale vereisten voor beschikbare knooppuntbronnen die nodig zijn voor het starten van een container of pod, de tweede beperkt strikt de middelen die beschikbaar zijn voor de container.
Wanneer Kubernetes een pod plant, is het van cruciaal belang dat de containers voldoende bronnen hebben voor een normale werking. Als je van plan bent een grote applicatie op een knooppunt met beperkte middelen in te zetten, is het heel goed mogelijk dat deze niet werkt omdat het knooppunt geen geheugen meer heeft of niet genoeg verwerkingskracht heeft. In dit artikel bespreken we hoe je problemen met een tekort aan computerkracht kunt oplossen met behulp van resource-aanvragen en beperkingen.
Requests en Limits zijn mechanismen die Kubernetes gebruikt om middelen zoals CPU en geheugen te beheren. Requests zijn datgene waardoor de container gegarandeerd de aangevraagde bron ontvangt. Als een container een bron aanvraagt, plant Kubernetes deze alleen op de knooppunt dat in staat is om deze te leveren. Limits controleren dat de resources die door de container worden aangevraagd, nooit boven een bepaalde waarde uitkomen.
Een container kan zijn rekenkracht alleen tot een bepaald niveau verhogen, waarna deze beperkt zal worden. Laten we eens kijken hoe dit werkt. Er zijn dus twee soorten middelen ā CPU en geheugen. De Kubernetes-scheduler gebruikt gegevens over deze middelen om te bepalen waar je pods moeten worden uitgevoerd. Een typische specificatie van middelen voor een pod ziet er als volgt uit.
Elke container in een pod kan zijn eigen verzoeken en beperkingen instellen, en dit is allemaal optioneel. De CPU-hulpmiddelen worden gedefinieerd in milli-cores. Als uw container twee volledige kernen nodig heeft om te draaien, stelt u de waarde in op 2000m. Als de container echter slechts 1/4 kern nodig heeft, is de waarde 250m. Houd er rekening mee dat als u een waarde voor CPU-hulpmiddelen toewijst die hoger is dan het aantal kernen van de grootste knoop, uw pod helemaal niet zal worden gepland. Een soortgelijke situatie doet zich voor als u een pod heeft die vier kernen nodig heeft, terwijl uw Kubernetes-cluster slechts uit twee fysieke virtuele machines bestaat.
Tenzij uw applicatie speciaal is ontwikkeld om de voordelen van meerdere kernen te benutten (denk hierbij aan programma's zoals complexe wetenschappelijke berekeningen en databasebewerkingen), is het beste om de CPU Requests in te stellen op 1 of minder, gevolgd door het draaien van meer replica's voor schaalbaarheid. Deze benadering geeft het systeem meer flexibiliteit en betrouwbaarheid.
Wat betreft CPU-limieten wordt het interessanter, omdat het als een samendrukbaar hulpbron wordt beschouwd. Als uw applicatie dichtbij de limiet van de CPU-kracht komt, begint Kubernetes uw container af te remmen door CPU Throttling toe te passen ā dit vermindert de kloksnelheid van de CPU. Dit betekent dat de CPU kunstmatig wordt beperkt, waardoor de applicatie mogelijk slechter presteert, maar het proces zal niet worden stopgezet of beĆ«indigd.
Geheugeneisen worden in bytes gedefinieerd. Gewoonlijk wordt de waarde in instellingen gemeten in mebibytes (MiB), maar u kunt elke waarde opgeven, van bytes tot petabytes. Hier geldt hetzelfde als voor CPU ā als u een geheugenvraag indient die groter is dan de beschikbare geheugencapaciteit op uw knopen, zal de uitvoering van deze pod niet worden gepland. Maar in tegenstelling tot CPU-hulpmiddelen kan geheugengebruik niet worden ingedamd, omdat er geen manier is om het gebruik ervan te beperken. Daarom zal de uitvoering van de container worden stopgezet zodra deze de aan hem toegewezen geheugengrens overschrijdt.
Het is belangrijk om te onthouden dat je geen aanvragen kunt configureren die de hoeveelheid resources overschrijden die jouw nodes kunnen bieden. De specificaties van gedeelde resources voor GKE virtuele machines zijn te vinden via de links onder deze video.
In een ideale wereld zouden de standaard containerinstellingen voldoende zijn om workflows soepel te laten verlopen. Maar de echte wereld is niet zo; mensen vergeten gemakkelijk het gebruik van resources te configureren of hackers kunnen aanvragen en beperkingen instellen die de werkelijke capaciteiten van de infrastructuur overschrijden. Om de ontwikkeling van dergelijke scenario's te voorkomen, kunnen resourcequota's in ResourceQuota en grenswaarden in LimitRange worden ingesteld.
Na het aanmaken van namespaces kunnen ze worden geblokkeerd met quota's. Bijvoorbeeld, als je namespaces prod en dev hebt, kan een sjabloon worden gebruikt waarbij er helemaal geen quota's voor productie zijn, terwijl de quota's voor ontwikkeling zeer streng zijn. Dit stelt prod in staat om bij een plotselinge toename van het verkeer alle beschikbare resources te gebruiken, waardoor dev volledig geblokkeerd wordt.
Een resourcequota kan er als volgt uitzien. In dit voorbeeld zijn er 4 secties - dat zijn de 4 onderste regels code.
Laten we elk van hen bekijken. Requests.cpu is de maximale hoeveelheid gecombineerde aanvragen voor CPU-kracht die kunnen komen van alle containers in de namespace. In dit voorbeeld kunnen er 50 containers zijn met aanvragen van 10m, vijf containers met aanvragen van 100m of gewoon Ć©Ć©n container met een aanvraag van 500m. Zolang het totale aantal requests.cpu voor deze namespace minder is dan 500m, is alles in orde.
De aangevraagde geheugen requests.memory is de maximale hoeveelheid gecombineerde geheugenaanvragen die alle containers in de namespace kunnen hebben. Zoals in het vorige geval, kun je 50 containers van 2 MiB hebben, vijf containers van 20 MiB of een enkele container van 100 MiB zolang het totale aantal aangevraagd geheugen in de namespace minder dan 100 mebibyte is.
Limits.cpu is de maximale gecombineerde waarde van CPU-kracht die alle containers in de namespace kunnen gebruiken. Dit kan worden gezien als de limiet voor CPU-aanvragen.
Ten slotte is limits.memory het maximale totale geheugen dat door alle containers in de namespace kan worden gebruikt. Dit is de grens voor het totale geheugengebruik.
Standaard hebben containers in een Kubernetes-cluster onbeperkte rekenkracht. Met behulp van resourcequota's kunnen clusterbeheerders het verbruik en de creatie van middelen op basis van de namespace beperken. In de namespace kan een pod- of containermodule zoveel CPU-macht en geheugen verbruiken als is gedefinieerd in de resourcequota's. Er is echter bezorgdheid dat een enkele pod of container alle beschikbare resources kan monopoliseren. Om deze situatie te voorkomen, wordt het limietbereik Limit Range gebruikt ā een beleid voor het beperken van de verdeling van resources (voor pods of containers) in de namespace.
Het limietbereik biedt beperkingen die kunnen:
- een minimum- en maximumgebruik van rekenkracht voor elke module of container in de namespace garanderen;
- geforceerd een minimum- en maximumopslagverzoek Storage Request voor elke PersistentVolumeClaim in de namespace toepassen;
- geforceerd een verhouding tussen aanvraag Request en limiet Limit voor de resource in de namespace instellen;
- standaard Requests/Limits voor rekenkracht in de namespace instellen en deze automatisch in containers invoeren tijdens uitvoering.
Zo kunt u een limietbereik in uw namespace aanmaken. In tegenstelling tot quota, die voor de hele namespace gelden, wordt Limit Range gebruikt voor individuele containers. Dit kan het creƫren van uiterst kleine of juist enorme containers door gebruikers binnen de namespace voorkomen. Een limietbereik Limit Range kan er als volgt uitzien.
Net als in het vorige geval zijn hier 4 secties te onderscheiden. Laten we elk van deze bekijken.
In de sectie default worden de standaardbeperkingen voor de container in de pod ingesteld. Als u deze waarden in het limietbereik instelt, zullen alle containers waarvoor deze waarden niet expliciet zijn ingesteld, worden geregeld door de standaardwaarden.
In de sectie standaardverzoek defaultRequest zijn de standaardverzoeken voor de container in de pod ingesteld. Nogmaals, als u deze waarden binnen het limietbereik instelt, zullen alle containers waarvoor deze parameters niet expliciet zijn ingesteld, deze standaardwaarden gebruiken.
In de sectie max worden de maximale limieten opgegeven die voor de container in de pod kunnen worden ingesteld. De waarden in de sectie default en de limieten voor de container kunnen niet boven deze grens worden ingesteld. Het is belangrijk op te merken dat als er een max-waarde is ingesteld en de sectie default ontbreekt, de maximale waarde de standaardwaarde wordt.
In de sectie min worden de minimale verzoeken opgegeven die voor de container in de pod kunnen worden ingesteld. De waarden in de sectie default en de verzoeken voor de container kunnen niet onder deze grens worden ingesteld.
Het is opnieuw belangrijk op te merken dat als deze waarde is ingesteld en de default-waarde niet, de minimale waarde de standaardverzoekwaarde wordt.
Uiteindelijk worden deze resourceverzoeken door de Kubernetes-scheduler gebruikt voor het uitvoeren van uw workloads. Om uw containers correct in te stellen, is het zeer belangrijk om te begrijpen hoe dit werkt. Stel dat u verschillende modules in uw cluster wilt draaien. Aangenomen dat de pod-specificaties geldig zijn, zal de Kubernetes-scheduler cyclische belastingverdeling gebruiken om een knooppunt te kiezen voor het uitvoeren van de workload.
Kubernetes zal controleren of er voldoende resources zijn op knooppunt Node 1 om de verzoeken van de container in de pod uit te voeren, en als dat niet zo is, gaat het naar het volgende knooppunt. Als geen van de knooppunten in het systeem aan de verzoeken kan voldoen, zullen de pods in de Pending state terechtkomen. Met functies zoals automatische schaalvergroting van knooppunten in Google Kubernetes Engine kan GKE automatisch de status Pending detecteren en enkele aanvullende knooppunten maken.
Als er later overcapaciteit van knooppunten ontstaat, zal de autoscalingfunctie het aantal verminderen om u geld te besparen. Daarom plant Kubernetes pods op basis van verzoeken. Het is echter mogelijk dat de limiet hoger is dan de verzoeken, en in sommige gevallen kan een knooppunt daadwerkelijk zijn resources uitgeput raken. We noemen deze toestand overcommitment state.
Zoals ik al zei, als het om de processor gaat, gaat Kubernetes beginnen met het limiteren van pods. Elke pod krijgt zoveel als hij vraagt, maar als hij niet de limiet bereikt, zal throttling worden toegepast.
Wat betreft geheugbronnen, is Kubernetes genoodzaakt beslissingen te nemen over welke pods te verwijderen en welke te behouden, totdat je systeembronnen vrijmaakt, anders zal het gehele systeem instorten.
Laten we ons een scenario voorstellen waarin je een machine hebt die de geheuglimiet heeft bereikt ā hoe zal Kubernetes hierop reageren?
Kubernetes zal zoeken naar pods die meer middelen gebruiken dan ze hebben aangevraagd. Dus als je containers helemaal geen requests hebben, betekent dit dat ze in feite meer gebruiken dan ze vroegen, gewoon omdat ze helemaal niets hebben aangevraagd! Dergelijke containers zijn de belangrijkste kandidaten voor uitschakeling. De volgende kandidaten zijn containers die al hun aanvragen hebben vervuld, maar nog steeds onder de maximale limiet blijven.
Dus als Kubernetes meerdere pods vindt die hun aanvraagparameters hebben overschreden, zal het ze op prioriteit sorteren en vervolgens de laagste prioriteitsmodules verwijderen. Als alle modules dezelfde prioriteit hebben, zal Kubernetes de pods uitschakelen die hun aanvragen meer hebben overschreden dan de andere pods.
In zeer zeldzame gevallen kan Kubernetes pods beƫindigen die nog steeds binnen hun aanvragen vallen. Dit kan gebeuren wanneer kritische systeemcomponenten, zoals de Kubelet-agent of Docker, meer middelen beginnen te verbruiken dan voor hen gereserveerd was.
Dus in de beginfase van kleine bedrijven kan een Kubernetes-cluster prima werken zonder resource-aanvragen en -limieten, maar naarmate je teams en projecten groter worden, loop je het risico problemen op dit gebied tegen te komen. Het toevoegen van aanvragen en limieten aan je modules en namespaces vereist slechts een beetje extra inspanning en kan veel problemen voorkomen.
Een beetje reclame š
Bedankt dat je bij ons blijft. Houd je van onze artikelen? Wil je meer interessante inhoud zien? Ondersteun ons door een bestelling te plaatsen of ons aan vrienden aan te bevelen, , een unieke variant van entry-level servers, die we voor jou hebben bedacht: (opties beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd is 2 keer goedkoper in datacenter Equinix Tier IV in Amsterdam? Alleen bij ons in Nederland! Dell R420 ā 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB ā vanaf $99! Lees over hoe
Bron: habr.com
