{"id":82920,"date":"2020-05-26T13:42:37","date_gmt":"2020-05-26T11:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov"},"modified":"2020-05-26T13:42:37","modified_gmt":"2020-05-26T11:42:37","slug":"luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Beste praktijken voor Kubernetes. Instellen van verzoeken en resource-limieten.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Beste Kubernetes-praktijken. Het cre\u00ebren van kleine containers<\/a><\/noindex>
\nBeste Kubernetes-praktijken. Organisatie van Kubernetes met namespaces<\/a><\/noindex>
\nBeste Kubernetes-praktijken. Het testen van de levensvatbaarheid van Kubernetes met Readiness- en Liveness-tests<\/a><\/noindex><\/p>\n

Voor elke Kubernetes-resource is het mogelijk om twee soorten vereisten in te stellen \u2014 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. <\/p>\n

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.<\/p>\n

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.<\/p>\n

\"Beste<\/a><\/noindex><\/p>\n

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 \u2014 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.<\/p>\n

\"Beste
\n
\nElke 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.<\/p>\n

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.<\/p>\n

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 \u2014 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\u00ebindigd. <\/p>\n

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 \u2014 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.<\/p>\n

\"Beste
\n
\nHet 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Een resourcequota kan er als volgt uitzien. In dit voorbeeld zijn er 4 secties - dat zijn de 4 onderste regels code.<\/p>\n

\"Beste
\n
\nLaten 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 \u00e9\u00e9n container met een aanvraag van 500m. Zolang het totale aantal requests.cpu voor deze namespace minder is dan 500m, is alles in orde.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.
\nStandaard 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 \u2013 een beleid voor het beperken van de verdeling van resources (voor pods of containers) in de namespace.<\/p>\n

Het limietbereik biedt beperkingen die kunnen:<\/p>\n