Voor elke Kubernetes-bron kunt u twee soorten vereisten configureren: Verzoeken en Limieten. De eerste beschrijft de minimale vereisten voor de beschikbaarheid van vrije knooppuntbronnen die nodig zijn om een container of pod uit te voeren, de tweede beperkt strikt de bronnen die beschikbaar zijn voor de container.
Wanneer Kubernetes pods plant, is het erg belangrijk dat de containers over voldoende middelen beschikken om goed te kunnen functioneren. Als u van plan bent een grote toepassing te implementeren op een knooppunt met beperkte bronnen, is het mogelijk dat deze niet kan worden uitgevoerd omdat het knooppunt onvoldoende geheugen of onvoldoende CPU-vermogen heeft. In dit artikel bekijken we hoe u tekorten aan rekenkracht kunt oplossen met behulp van resourceverzoeken en -limieten.
Verzoeken en limieten zijn mechanismen die Kubernetes gebruikt om bronnen zoals CPU en geheugen te beheren. Verzoeken zorgen ervoor dat de container de gevraagde bron ontvangt. Als een container om een resource vraagt, plant Kubernetes deze alleen op een knooppunt dat deze kan leveren. Limieten bepalen dat de door de container gevraagde bronnen nooit een bepaalde waarde zullen overschrijden.
Een container kan zijn rekenkracht slechts tot een bepaalde limiet vergroten, daarna wordt deze beperkt. Laten we kijken hoe het werkt. Er zijn dus twee soorten bronnen: processor en geheugen. De Kubernetes-planner gebruikt gegevens over deze bronnen om erachter te komen waar uw pods moeten worden uitgevoerd. Een typische resourcespecificatie voor een pod ziet er als volgt uit.
Elke container in een pod kan zijn eigen query's en limieten instellen, het is allemaal additief. Processorbronnen worden gedefinieerd in millicores. Als uw container twee volle kernen nodig heeft om te kunnen draaien, stelt u de waarde in op 2000m. Als de container slechts 1/4 van de kern nodig heeft, is de waarde 250m. Houd er rekening mee dat als u een CPU-bronwaarde toewijst die groter is dan het aantal kernen van het grootste knooppunt, uw pod helemaal niet zal starten. Een soortgelijke situatie zal zich voordoen als u een Pod heeft die vier cores nodig heeft, en het Kubernetes-cluster uit slechts twee virtuele hoofdmachines bestaat.
Tenzij uw toepassing specifiek is ontworpen om te profiteren van meerdere cores (denk aan programma's als complex wetenschappelijk computergebruik en databasebewerkingen), is het het beste om CPU Requests in te stellen op 1 of lager en vervolgens meer replica's uit te voeren voor schaalbaarheid. Deze oplossing geeft het systeem meer flexibiliteit en betrouwbaarheid.
Als het gaat om CPU-beperkingen, worden de zaken interessanter omdat het als een samendrukbare bron wordt beschouwd. Als uw applicatie de limiet van het processorvermogen begint te naderen, begint Kubernetes uw container te vertragen met behulp van CPU Throttling, waardoor de processorfrequentie wordt verlaagd. Dit betekent dat de CPU kunstmatig wordt beperkt, waardoor de applicatie potentieel slechtere prestaties krijgt, maar het proces wordt niet beëindigd of verwijderd.
Geheugenbronnen worden gedefinieerd in bytes. Normaal gesproken wordt de waarde in de instellingen gemeten in mebibytes Mib, maar u kunt elke waarde instellen, van bytes tot petabytes. Dezelfde situatie is hier van toepassing als bij de CPU: als u een verzoek plaatst voor een hoeveelheid geheugen die groter is dan de hoeveelheid geheugen op uw knooppunten, zal de uitvoering van die pod niet worden gepland. Maar in tegenstelling tot CPU-bronnen wordt het geheugen niet gecomprimeerd omdat er geen manier is om het gebruik ervan te beperken. Daarom wordt de uitvoering van de container gestopt zodra deze het toegewezen geheugen overschrijdt.
Het is belangrijk om te onthouden dat u geen verzoeken kunt configureren die de resources overschrijden die uw knooppunten kunnen bieden. Specificaties voor gedeelde bronnen voor virtuele GKE-machines vindt u via de links onder deze video.
In een ideale wereld zouden de standaardinstellingen van de container voldoende zijn om workflows soepel te laten verlopen. Maar zo is de echte wereld niet: mensen kunnen gemakkelijk vergeten het gebruik van bronnen te configureren, of hackers zullen verzoeken en beperkingen instellen die de werkelijke mogelijkheden van de infrastructuur te boven gaan. Om te voorkomen dat dergelijke scenario's optreden, kunt u resourcequota voor ResourceQuota en LimitRange configureren.
Zodra een naamruimte is aangemaakt, kan deze worden geblokkeerd met behulp van quota. Als u bijvoorbeeld de naamruimten prod en dev heeft, is het patroon dat er helemaal geen productiequota zijn en zeer strikte ontwikkelingsquota. Hierdoor kan prod, in het geval van een sterke toename van het verkeer, de gehele beschikbare bron overnemen, waardoor dev.
Het resourcequotum kan er als volgt uitzien. In dit voorbeeld zijn er 4 secties: dit zijn de 4 onderste regels code.
Laten we ze allemaal bekijken. Requests.cpu is het maximale aantal gecombineerde CPU-aanvragen dat afkomstig kan zijn van alle containers in de naamruimte. In dit voorbeeld kunt u 50 containers hebben met verzoeken van 10 miljoen, vijf containers met verzoeken van 100 miljoen of slechts één container met verzoeken van 500 miljoen. Zolang het totale aantal request.cpu van een bepaalde naamruimte minder dan 500 m bedraagt, komt alles goed.
Geheugen aangevraagde verzoeken. Memory is de maximale hoeveelheid gecombineerde geheugenverzoeken die alle containers in de naamruimte kunnen hebben. Net als in het vorige geval kunt u 50 containers van 2 mib, vijf containers van 20 mib of een enkele container van 100 mib hebben, zolang de totale hoeveelheid gevraagd geheugen in de naamruimte minder dan 100 mebibytes bedraagt.
Limits.cpu is de maximale gecombineerde hoeveelheid CPU-kracht die alle containers in de naamruimte kunnen gebruiken. We kunnen dit beschouwen als de limiet voor verzoeken om processorvermogen.
Tenslotte is limit.memory de maximale hoeveelheid gedeeld geheugen die alle containers in de naamruimte kunnen gebruiken. Dit is een limiet voor het totale geheugenverzoek.
Containers in een Kubernetes-cluster draaien dus standaard met onbeperkte rekenbronnen. Met resourcequota kunnen clusterbeheerders het resourceverbruik en het maken van resources beperken op basis van de naamruimte. In een naamruimte kan een pod of container evenveel CPU-kracht en geheugen verbruiken als wordt bepaald door het resourcequotum voor de naamruimte. Er bestaat echter bezorgdheid dat één pod of container alle beschikbare hulpbronnen kan monopoliseren. Om deze situatie te voorkomen wordt een limietbereik gebruikt: een beleid voor het beperken van de toewijzing van bronnen (voor pods of containers) in de naamruimte.
Het limietbereik biedt beperkingen die:
- Zorg voor minimaal en maximaal gebruik van computerbronnen voor elke module of container in de naamruimte;
- het afdwingen van minimale en maximale Starage Request-opslagverzoeken voor elke PersistentVolumeClaim in de naamruimte;
- een relatie afdwingen tussen een verzoek en een limiet voor een bron in een naamruimte;
- stel standaardverzoeken/limieten in voor rekenbronnen in de naamruimte en injecteer deze tijdens runtime automatisch in containers.
Op deze manier kunt u een limietbereik in uw naamruimte creëren. In tegenstelling tot een quotum, dat van toepassing is op de gehele naamruimte, wordt Limit Range gebruikt voor individuele containers. Dit kan voorkomen dat gebruikers zeer kleine of, omgekeerd, gigantische containers binnen de naamruimte maken. Het limietbereik kan er zo uitzien.
Net als in het vorige geval kunnen hier 4 secties worden onderscheiden. Laten we ze allemaal bekijken.
In de standaardsectie worden de standaardlimieten voor de container in de pod ingesteld. Als u deze waarden instelt op het extreme bereik, volgen alle containers waarvoor deze waarden niet expliciet zijn ingesteld de standaardwaarden.
De standaardaanvraagsectie defaultRequest configureert de standaardaanvragen voor de container in de pod. Nogmaals, als u deze waarden instelt op het extreme bereik, zullen alle containers die deze opties niet expliciet instellen, standaard deze waarden gebruiken.
In het gedeelte Max worden de maximale limieten opgegeven die kunnen worden ingesteld voor een container in de pod. Waarden in de standaardsectie en containerlimieten kunnen niet boven deze limiet worden ingesteld. Het is belangrijk op te merken dat als de waarde is ingesteld op max en er geen standaardsectie is, de maximale waarde de standaardwaarde wordt.
In de sectie min worden de minimale aanvragen opgegeven die kunnen worden ingesteld voor een container in een pod. De waarden in de standaardsectie en queries voor de container kunnen echter niet onder deze limiet worden ingesteld.
Nogmaals, het is belangrijk op te merken dat als deze waarde is ingesteld, de standaardwaarde dat niet is, en dat de minimumwaarde de standaardprompt wordt.
Deze resourceaanvragen worden uiteindelijk door de Kubernetes-planner gebruikt om uw workloads uit te voeren. Om uw containers correct te configureren, is het erg belangrijk om te begrijpen hoe het werkt. Stel dat u meerdere peulen in uw cluster wilt uitvoeren. Ervan uitgaande dat de podspecificaties geldig zijn, gebruikt het Kubernetes-schema round robin-balancering om een knooppunt te selecteren om de werklast uit te voeren.
Kubernetes controleert of knooppunt 1 voldoende bronnen heeft om aan verzoeken van de podcontainers te voldoen, en als dat niet het geval is, gaat het door naar het volgende knooppunt. Als geen van de knooppunten in het systeem aan de verzoeken kan voldoen, gaan de pods naar de status In behandeling. Met behulp van Google Kubernetes-enginefuncties, zoals het automatisch schalen van knooppunten, kan GKE automatisch de wachtstatus detecteren en nog een aantal extra knooppunten maken.
Als u vervolgens geen knooppuntcapaciteit meer heeft, vermindert automatisch schalen het aantal knooppunten, waardoor u geld bespaart. Dit is de reden waarom Kubernetes pods plant op basis van verzoeken. De limiet kan echter hoger zijn dan de verzoeken, en in sommige gevallen kan het knooppunt feitelijk geen bronnen meer hebben. We noemen deze staat een staat van overcommitment.
Zoals ik al zei, als het op CPU aankomt, zal Kubernetes de pods gaan beperken. Elke pod ontvangt zoveel als gevraagd, maar als de limiet niet wordt bereikt, wordt de beperking toegepast.
Als het om geheugenbronnen gaat, wordt Kubernetes gedwongen beslissingen te nemen over welke pods moeten worden verwijderd en welke moeten worden bewaard totdat u systeembronnen vrijmaakt, anders zal het hele systeem crashen.
Laten we ons een scenario voorstellen waarin een machine onvoldoende geheugen heeft. Hoe zou Kubernetes daarmee omgaan?
Kubernetes zoekt naar pods die meer bronnen gebruiken dan ze hebben gevraagd. Dus als uw containers helemaal geen verzoeken hebben, betekent dit dat ze standaard meer gebruiken dan waar ze om hebben gevraagd, simpelweg omdat ze helemaal niets hebben gevraagd! Dergelijke containers worden belangrijke kandidaten voor sluiting. De volgende kandidaten zijn containers die aan al hun verzoeken hebben voldaan, maar nog steeds onder de maximumlimiet zitten.
Dus als Kubernetes verschillende pods vindt die hun verzoekparameters hebben overschreden, worden deze op prioriteit gesorteerd en vervolgens de pods met de laagste prioriteit verwijderd. Als alle pods dezelfde prioriteit hebben, beëindigt Kubernetes de pods die hun verzoeken meer overschrijden dan andere pods.
In zeer zeldzame gevallen kan Kubernetes pods afbreken die nog binnen het bereik van hun verzoeken vallen. Dit kan gebeuren wanneer kritieke systeemcomponenten zoals de Kubelet-agent of Docker meer bronnen beginnen te verbruiken dan wat voor hen was gereserveerd.
In de beginfase van kleine bedrijven kan een Kubernetes-cluster dus prima werken zonder resourceverzoeken en beperkingen in te stellen, maar naarmate uw teams en projecten in omvang beginnen te groeien, loopt u het risico op problemen op dit gebied te stuiten. Het toevoegen van queries en beperkingen aan uw modules en naamruimten vergt heel weinig extra inspanning en kan een hoop gedoe besparen.
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com