För varje Kubernetes-resurs kan du konfigurera två typer av krav – förfrågningar och begränsningar. Den första beskriver minimikraven för tillgängligheten av lediga nodresurser som krävs för att köra en behållare eller pod, den andra begränsar strikt de resurser som är tillgängliga för behållaren.
När Kubernetes schemalägger poddar är det mycket viktigt att behållarna har tillräckligt med resurser för att fungera korrekt. Om du planerar att distribuera en stor applikation på en resursbegränsad nod, är det möjligt att den inte kommer att köras eftersom noden har ont om minne eller tar slut på CPU-kraft. I den här artikeln kommer vi att titta på hur du kan lösa datorkraftsbrist med hjälp av resursbegäranden och begränsningar.
Förfrågningar och begränsningar är mekanismer som Kubernetes använder för att hantera resurser som CPU och minne. Förfrågningar är det som säkerställer att behållaren tar emot den begärda resursen. Om en behållare begär en resurs kommer Kubernetes bara att schemalägga den på en nod som kan tillhandahålla den. Begränsar kontroll att resurserna som begärs av behållaren aldrig kommer att överstiga ett visst värde.
En container kan bara öka sin datorkraft upp till en viss gräns, varefter den kommer att begränsas. Låt oss se hur det fungerar. Så det finns två typer av resurser - processor och minne. Kubernetes-schemaläggaren använder data om dessa resurser för att ta reda på var du ska köra dina poddar. En typisk resursspecifikation för en pod ser ut så här.
Varje behållare i en pod kan ställa in sina egna frågor och gränser, allt är additivt. Processorresurser definieras i millikärnor. Om din behållare behöver två hela kärnor för att köras, ställer du in värdet på 2000m. Om behållaren bara behöver kraften på 1/4 av kärnan blir värdet 250m. Tänk på att om du tilldelar ett CPU-resursvärde som är större än antalet kärnor i den största noden, kommer din pod inte att schemaläggas att starta alls. En liknande situation kommer att inträffa om du har en Pod som behöver fyra kärnor, och Kubernetes-klustret består av endast två virtuella huvudmaskiner.
Om inte din applikation är utformad specifikt för att dra nytta av flera kärnor (program som komplexa vetenskapliga beräkningar och databasoperationer kommer att tänka på), är den bästa praxisen att ställa in CPU-begäranden till 1 eller lägre och sedan köra fler repliker för skalbarhet. Denna lösning kommer att ge systemet större flexibilitet och tillförlitlighet.
När det gäller CPU-begränsningar blir det mer intressant eftersom det anses vara en komprimerbar resurs. Om din applikation börjar närma sig gränsen för processorkraft kommer Kubernetes att börja sakta ner din behållare med CPU Throttling - vilket minskar processorfrekvensen. Detta innebär att processorn kommer att strypas på konstgjord väg, vilket ger applikationen potentiellt sämre prestanda, men processen kommer inte att avslutas eller tas bort.
Minnesresurser definieras i byte. Vanligtvis mäts värdet i inställningarna i mebibyte Mib, men du kan ställa in vilket värde som helst, från byte till petabyte. Samma situation gäller här som med CPU - om du lägger en begäran om en mängd minne som är större än mängden minne på dina noder, kommer den podden inte att schemaläggas att köras. Men till skillnad från CPU-resurser är minnet inte komprimerat eftersom det inte finns något sätt att begränsa dess användning. Därför kommer exekveringen av behållaren att stoppas så snart den går utöver det minne som tilldelats den.
Det är viktigt att komma ihåg att du inte kan konfigurera förfrågningar som överskrider de resurser som dina noder kan tillhandahålla. Specifikationer för delade resurser för virtuella GKE-maskiner finns i länkarna under den här videon.
I en idealisk värld skulle behållarens standardinställningar vara tillräckliga för att hålla arbetsflöden igång smidigt. Men den verkliga världen är inte så, människor kan lätt glömma att konfigurera användningen av resurser, annars kommer hackare att ställa förfrågningar och begränsningar som överstiger infrastrukturens verkliga kapacitet. För att förhindra att sådana scenarier inträffar kan du konfigurera resurskvoter för ResourceQuota och LimitRange.
När ett namnområde har skapats kan det blockeras med kvoter. Om du till exempel har prod- och dev-namnområdena är mönstret att det inte finns några produktionskvoter alls och mycket strikta utvecklingskvoter. Detta gör att prod, i händelse av en kraftig ökning av trafiken, kan ta över hela den tillgängliga resursen, vilket helt blockerar dev.
Resurskvoten kan se ut så här. I det här exemplet finns det 4 sektioner - det här är de 4 nedersta kodraderna.
Låt oss titta på var och en av dem. Requests.cpu är det maximala antalet kombinerade CPU-förfrågningar som kan komma från alla behållare i namnområdet. I det här exemplet kan du ha 50 containrar med 10m-förfrågningar, fem containrar med 100m-förfrågningar eller bara en container med 500m-förfrågningar. Så länge det totala antalet requests.cpu för ett givet namnutrymme är mindre än 500m kommer allt att bli bra.
Memory requested requests.memory är den maximala mängden kombinerade minnesbegäranden som alla behållare i namnområdet kan ha. Som i det föregående fallet kan du ha 50 2 mib-containrar, fem 20 mib-containrar eller en enda 100 mib-behållare så länge som den totala mängden minne som begärs i namnutrymmet är mindre än 100 mebibyte.
Limits.cpu är den maximala kombinerade mängden CPU-kraft som alla behållare i namnområdet kan använda. Vi kan betrakta detta som gränsen för begäranden om processorkraft.
Slutligen är limits.memory den maximala mängden delat minne som alla behållare i namnområdet kan använda. Detta är en gräns för det totala antalet minnesförfrågningar.
Så som standard körs behållare i ett Kubernetes-kluster med obegränsade beräkningsresurser. Med resurskvoter kan klusteradministratörer begränsa resursförbrukning och resursskapande baserat på namnutrymme. I ett namnområde kan en pod eller behållare förbruka så mycket CPU-kraft och minne som bestäms av namnområdets resurskvot. Det finns dock en oro för att en kapsel eller behållare kan monopolisera alla tillgängliga resurser. För att förhindra denna situation används ett gränsintervall - en policy för att begränsa allokeringen av resurser (för poddar eller behållare) i namnområdet.
Gränsintervallet ger begränsningar som kan:
- Säkerställ minimal och maximal användning av beräkningsresurser för varje modul eller behållare i namnområdet;
- upprätthålla minimi- och högsta lagringsbegäranden för Starage Request för varje PersistentVolumeClaim i namnområdet;
- upprätthålla en relation mellan en begäran och en gräns för en resurs i ett namnområde;
- ställ in standardbegäranden/gränser för beräkningsresurser i namnområdet och injicera dem automatiskt i behållare vid körning.
På så sätt kan du skapa ett gränsintervall i ditt namnområde. Till skillnad från en kvot, som gäller för hela namnområdet, används Limit Range för enskilda behållare. Detta kan förhindra användare från att skapa mycket små eller, omvänt, gigantiska behållare inom namnområdet. Limit Range kan se ut så här.
Liksom i föregående fall kan 4 sektioner urskiljas här. Låt oss titta på var och en.
Standardavsnittet anger standardgränserna för behållaren i podden. Om du ställer in dessa värden till det extrema intervallet, kommer alla behållare för vilka dessa värden inte uttryckligen har ställts in att följa standardvärdena.
Standardbegäransavsnittet defaultRequest konfigurerar standardbegäran för behållaren i podden. Återigen, om du ställer in dessa värden till det extrema intervallet, kommer alla behållare som inte uttryckligen ställer in dessa alternativ att ha dessa värden som standard.
Max-sektionen anger de maxgränser som kan ställas in för en behållare i podden. Värden i standardavsnittet och behållargränser kan inte ställas över denna gräns. Det är viktigt att notera att om värdet är satt till max och det inte finns något standardavsnitt, så blir maxvärdet standardvärdet.
Min-sektionen anger de minimikrav som kan ställas in för en behållare i en pod. Värdena i standardavsnittet och frågorna för behållaren kan dock inte ställas in under denna gräns.
Återigen är det viktigt att notera att om det här värdet är inställt är standard inte det, då blir minimivärdet standardprompten.
Dessa resursbegäranden används i slutändan av Kubernetes-schemaläggaren för att utföra dina arbetsbelastningar. För att du ska kunna konfigurera dina containrar korrekt är det mycket viktigt att förstå hur det fungerar. Låt oss säga att du vill köra flera pods i ditt kluster. Förutsatt att podspecifikationerna är giltiga kommer Kubernetes-schemat att använda round robin-balansering för att välja en nod för att köra arbetsbelastningen.
Kubernetes kommer att kontrollera om Nod 1 har tillräckligt med resurser för att uppfylla förfrågningar från podbehållarna, och om den inte gör det kommer den att gå vidare till nästa nod. Om ingen av noderna i systemet kan tillgodose förfrågningarna, kommer podarna att gå in i väntande tillstånd. Genom att använda Google Kubernetes-motorfunktioner som nodautoskalning kan GKE automatiskt upptäcka väntetillståndet och skapa flera ytterligare noder.
Om du sedan får slut på nodkapacitet kommer autoskalning att minska antalet noder för att spara pengar. Det är därför Kubernetes schemalägger poddar baserat på förfrågningar. Gränsen kan dock vara högre än förfrågningarna, och i vissa fall kan noden faktiskt få slut på resurser. Vi kallar detta tillstånd för överengagemang.
Som sagt, när det kommer till CPU kommer Kubernetes att börja begränsa poddarna. Varje pod kommer att få så mycket som den begärde, men om den inte når gränsen kommer strypning att börja tillämpas.
När det kommer till minnesresurser tvingas Kubernetes fatta beslut om vilka poddar som ska tas bort och vilka som ska behållas tills du frigör systemresurser eller så kraschar hela systemet.
Låt oss föreställa oss ett scenario där du har en maskin som tar slut på minne – hur skulle Kubernetes hantera det?
Kubernetes kommer att leta efter poddar som använder fler resurser än de begärde. Så om dina behållare inte har några förfrågningar alls, betyder det att de som standard använder mer än de bad om, helt enkelt för att de inte bad om någonting alls! Sådana containrar blir främsta kandidater för avstängning. Nästa kandidater är containrar som har uppfyllt alla sina önskemål men som fortfarande ligger under maxgränsen.
Så om Kubernetes hittar flera pods som har överskridit deras begäran parametrar, kommer den att sortera dem efter prioritet och sedan ta bort de lägsta prioriterade podarna. Om alla poddar har samma prioritet, kommer Kubernetes att avsluta de poddar som överskrider deras förfrågningar mer än andra pods.
I mycket sällsynta fall kan Kubernetes avbryta pods som fortfarande är inom ramen för deras begäran. Detta kan hända när kritiska systemkomponenter som Kubelet-agenten eller Docker börjar förbruka mer resurser än vad som var reserverat för dem.
Så i de tidiga stadierna av små företag kan ett Kubernetes-kluster fungera bra utan att ställa in resursbegäranden och begränsningar, men när dina team och projekt börjar växa i storlek riskerar du att stöta på problem inom detta område. Att lägga till frågor och begränsningar till dina moduler och namnutrymmen kräver mycket lite extra ansträngning och kan spara mycket krångel.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com