Bästa praxis för Kubernetes. Inställning av begärningar och resursbegränsningar

Bästa praxis för Kubernetes. Skapa små containrar
Bästa praxis för Kubernetes. Organisera Kubernetes med namnrymder
Bästa praxis för Kubernetes. Kontroll av Kubernetes livskraft med hjälp av Readiness- och Liveness-tester

För varje Kubernetes-resurs är det möjligt att ställa in två typer av krav — Requests och Limits. Den första beskriver de minimala kraven på tillgången till fria resurser på noden, som behövs för att starta en container eller pod, den andra sätter en strikt gräns för de resurser som är tillgängliga för containern.

När Kubernetes planerar en pod är det mycket viktigt att containrarna har tillräckligt med resurser för att fungera normalt. Om du planerar att distribuera en stor applikation på en nod med begränsade resurser, är det mycket möjligt att den inte kommer att fungera på grund av att noden får slut på minne eller saknar processorkraft. I den här artikeln kommer vi att undersöka hur man kan lösa problem med brist på datorkraft genom att använda resursförfrågningar och begränsningar.

Requests och Limits är mekanismer som Kubernetes använder för att hantera resurser som processor och minne. Requests är det som gör att containern garanterat får den begärda resursen. Om en container begär en resurs kommer Kubernetes endast att schemalägga den på den nod som kan tillhandahålla den. Begränsningar Limits kontrollerar att resurserna som begärs av containern aldrig överstiger ett visst värde.

En container kan öka beräkningskraften endast upp till en viss gräns, efter vilken den kommer att begränsas. Låt oss titta på hur detta fungerar. Så, det finns två typer av resurser — processor och minne. Kubernetes schemaläggare använder data om dessa resurser för att ta reda på var du ska köra dina pods. En typisk resurs specification för en pod ser ut så här.

Varje container i en pod kan ställa in sina egna krav och begränsningar, allt detta är additivt. CPU-resurser anges i millikärnor. Om din container kräver två fulla kärnor för att köra, anger du värdet 2000m. Om containment endast behöver kraften från 1/4 kärna, kommer värdet att vara 250m. Tänk på att om du anger en resursallokering som är högre än antalet kärnor i den största noden, kommer din pod inte att schemaläggas överhuvudtaget. En liknande situation uppstår om du har en pod som kräver fyra kärnor, medan Kubernetes-klustret endast består av två huvud virtuella maskiner.

Om inte din applikation är specifikt utvecklad för att utnyttja fördelarna med flera kärnor (exempelvis komplicerade vetenskapliga beräkningar och databashantering), är det bästa praxis att ställa in CPU-requests på 1 eller lägre, och sedan köra fler repliker för skalbarhet. Detta beslut ger systemet större flexibilitet och pålitlighet.

När det kommer till begränsningar av CPU blir allt mer intressant eftersom det anses vara en komprimerbar resurs. Om din applikation börjar närma sig gränsen för CPU-kraft, kommer Kubernetes att börja dämpa din container med hjälp av CPU Throttling - en sänkning av processorfrekvensen. Det innebär att processorn kommer att begränsas artificiellt, vilket kan ge applikationen en potentiellt sämre prestanda, men processen kommer inte att stoppas eller avslutas.

Minne resurser anges i byte. Vanligtvis mäts värdet i inställningarna i mebibyte (MiB), men du kan ange vilket värde som helst, från byte till petabyte. Här gäller samma situation som för CPU - om du begär mer minne än mängden minne i dina noder, kommer körningen av denna pod inte att schemaläggas. Men till skillnad från CPU-resurser kan minne inte komprimeras, eftersom det inte finns något sätt att begränsa dess användning. Därför kommer körningen av containern att stoppas så snart den överskrider det tilldelade minnet.

Det är viktigt att komma ihåg att du inte kan konfigurera begärningar som överskrider de resurser som dina noder kan tillhandahålla. Specifikationerna för gemensamma resurser för GKE-virtuella maskiner finns i länkarna som finns under denna video.

I en perfekt värld skulle standardinställningarna för containern vara tillräckliga för att arbetsflödena ska flyta smidigt. Men verkligheten är en annan; människor kan lätt glömma att konfigurera resursanvändning eller så kan hackare ställa in begärningar och begränsningar som överstiger infrastrukturens verkliga kapacitet. För att förhindra sådana scenarier kan du konfigurera resurskvoter med ResourceQuota och begränsningsintervall med LimitRange.

Efter att namnrymder har skapats kan de blockeras med hjälp av kvoter. Till exempel, om du har namnrymderna prod och dev, används en mall där kvoter för produktion helt saknas medan kvoter för utveckling är mycket strikta. Detta gör att prod, vid en plötslig trafikökning, kan ta hela den tillgängliga resursen och helt blockera dev.

Resurskvoten kan se ut på följande sätt. I det här exemplet finns det 4 sektioner – det är de 4 nedersta raderna av kod.

Låt oss titta på var och en av dem. Requests.cpu är det maximala antalet sammanlagda begärningar om processorkraft som kan komma från alla containrar i namnrymden. I det här exemplet kan du ha 50 containrar med begärningar på 10m, fem containrar med begärningar på 100m, eller bara en container med en begäran på 500m. Så länge det totala antalet requests.cpu för namnrymden är mindre än 500m kommer allt att fungera.

Begärd minne, requests.memory, är den maximala mängden sammanlagda begärningar om minne som alla containrar i namnrymden kan ha. Som i föregående fall kan du ha 50 containrar med 2 MiB, fem containrar med 20 MiB, eller en enda container med 100 MiB, så länge den totala mängden begärt minne i namnrymden är mindre än 100 mebibyte.

Limits.cpu är det maximala sammanlagda värdet av processorkraft som alla containrar i namnrymden kan använda. Det kan betraktas som en gräns för begärningar om processorkraft.

Slutligen anger limits.memory det maximala beloppet av total minne som alla containrar inom namnutrymmet kan använda. Detta är en begränsning för det totala minnesanvändandet.
Så, som standard arbetar containrar i Kubernetes-klustret med obegränsade beräkningsresurser. Genom resurskvoter kan klusteradministratörer begränsa resursanvändningen och skapandet baserat på namnutrymmet. Inom namnutrymmet kan en pod eller container använda så mycket CPU och minne som definieras av resurskvoten för namnutrymmet. Det finns dock en oro för att en pod eller container kan monopolera alla tillgängliga resurser. För att förhindra en sådan situation används limit Range – en policy för resursfördelningsbegränsning (för pods eller containrar) inom namnutrymmet.

Limit Range tillhandahåller begränsningar som kan:

• säkerställa minimalt och maximalt utnyttjande av beräkningsresurser för varje pod eller container inom namnutrymmet;
• tvinga fram minimum och maximum Storage Request för varje PersistentVolumeClaim inom namnutrymmet;
• tvinga fram förhållandet mellan Request och Limit för en resurs inom namnutrymmet;
• ställa in standard Requests/Limits för beräkningsresurser inom namnutrymmet och automatiskt införa dem i containrar under körning.

Således kan du skapa en limit Range i ditt namnutrymme. Till skillnad från kvoten, som gäller för hela namnutrymmet, används Limit Range för vissa containrar. Detta kan förhindra att användare skapar mycket små eller å andra sidan, gigantiska containrar inom namnutrymmet. Limit Range kan se ut så här.

Liksom i det tidigare fallet finns här fyra sektioner. Låt oss titta på var och en.
I avsnittet default ställs standardbegränsningar för containern i podden. Om du anger dessa värden i limit range, kommer alla containrar för vilka dessa värden inte har angetts uttryckligen att följa standardvärdena.

I avsnittet defaultRequest ställs standardförfrågningar in för containern i podden. Återigen, om du sätter dessa värden inom det maximala intervallet kommer alla containrar som inte explicit har dessa parametrar angivna att använda dessa värden som standard.

I avsnittet max anges de maximala begränsningar som kan ställas in för containern i podden. Värdena i avsnittet default och begränsningar för containern kan inte ställas in högre än denna gräns. Det är viktigt att notera att om ett max-värde är angivet och avsnittet default saknas, blir max-värdet standardvärdet.

I avsnittet min anges de minimala förfrågningarna som kan ställas in för containern i podden. Värdena i avsnittet default och förfrågningar för containern kan inte ställas in under denna gräns.

Det är återigen viktigt att notera att om detta värde är angivet och default-värdet saknas, blir det minimi-värdet standardförfrågan.

I slutändan används dessa resursförfrågningar av Kubernetes schemaläggare för att köra dina arbetsbelastningar. För att du ska kunna konfigurera dina containrar korrekt är det mycket viktigt att förstå hur detta fungerar. Låt oss säga att du vill köra flera moduler i din kluster. Förutsatt att pod-specifikationerna är giltiga kommer Kubernetes schemaläggare att använda cyklisk belastningsutjämning för att välja en nod för att utföra arbetsbelastningen.

Kubernetes kommer att kontrollera om Node 1 har tillräckligt med resurser för att hantera förfrågningarna från containrarna i podden, och om inte, går den vidare till nästa nod. Om ingen av noderna i systemet kan tillfredsställa förfrågningarna, kommer poddarna att gå in i väntande tillstånd. Med funktioner som autoskalning av noder i Google Kubernetes Engine (GKE) kan GKE automatiskt identifiera det väntande tillståndet och skapa fler extra noder.

Om det senare uppstår överflöd av noder, kommer autoskalningsfunktionen att minska antalet för att spara pengar. Det är därför Kubernetes planerar poddar baserat på förfrågningar. Men gränsen kan vara högre än förfrågningarna, och i vissa fall kan en nod faktiskt uttömma resurser. Vi kallar detta tillstånd för överkommittment-tillstånd.

Som jag redan nämnt, när det gäller processorer kommer Kubernetes att börja begränsa pods. Varje pod får så mycket som den har begärt, men om den inte når sin gräns, kommer throttling att tillämpas.

När det kommer till minnesresurser måste Kubernetes ta beslut om vilka pods som ska tas bort och vilka som ska behållas, tills ni frigör systemresurser; annars kollapsar hela systemet.

Låt oss föreställa oss ett scenario där ni har en maskin som har nått sitt minnesgräns – hur kommer Kubernetes att agera då?

Kubernetes kommer att leta efter pods som använder mer resurser än de har begärt. Så om era containrar överhuvudtaget inte har några begärningar (Requests), betyder det att de per standard använder mer än de har begärt, helt enkelt för att de inte har begärt något! Sådana containrar blir de främsta kandidaterna för avstängning. Följande kandidater är containrar som har uppfyllt alla sina begärningar men fortfarande ligger under den maximala gränsen.

Om Kubernetes hittar några pods som har överskridit sina begärningar, kommer de att sorteras efter prioritet och sedan kommer de med lägst prioritet att tas bort. Om alla pods har samma prioritet kommer Kubernetes att stoppa de pods som har överskridit sina begärningar mer än de andra.

I mycket sällsynta fall kan Kubernetes avbryta pods som fortfarande ligger inom sina begärningar. Detta kan hända när kritiska systemkomponenter, som Kubelet-agenten eller Docker, börjar använda mer resurser än vad som var reserverat för dem.
Så i början av arbetet för små företag kan en Kubernetes-kluster fungera utmärkt utan att ställa in resursbegärningar och begränsningar, men när era team och projekt börjar växa, riskerar ni att stöta på problem på detta område. Att lägga till begärningar och begränsningar i era moduler och namnrymder kräver väldigt lite ytterligare insats och kan spara er från mycket besvär.

Bästa praxis för Kubernetes. Korrekt nedstängning Terminate

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com