{"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\/sv\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"B\u00e4sta praxis f\u00f6r Kubernetes. Inst\u00e4llning av beg\u00e4rningar och resursbegr\u00e4nsningar","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

B\u00e4sta praxis f\u00f6r Kubernetes. Skapa sm\u00e5 containrar<\/a><\/noindex>
\nB\u00e4sta praxis f\u00f6r Kubernetes. Organisera Kubernetes med namnrymder<\/a><\/noindex>
\nB\u00e4sta praxis f\u00f6r Kubernetes. Kontroll av Kubernetes livskraft med hj\u00e4lp av Readiness- och Liveness-tester<\/a><\/noindex><\/p>\n

F\u00f6r varje Kubernetes-resurs \u00e4r det m\u00f6jligt att st\u00e4lla in tv\u00e5 typer av krav \u2014 Requests och Limits. Den f\u00f6rsta beskriver de minimala kraven p\u00e5 tillg\u00e5ngen till fria resurser p\u00e5 noden, som beh\u00f6vs f\u00f6r att starta en container eller pod, den andra s\u00e4tter en strikt gr\u00e4ns f\u00f6r de resurser som \u00e4r tillg\u00e4ngliga f\u00f6r containern. <\/p>\n

N\u00e4r Kubernetes planerar en pod \u00e4r det mycket viktigt att containrarna har tillr\u00e4ckligt med resurser f\u00f6r att fungera normalt. Om du planerar att distribuera en stor applikation p\u00e5 en nod med begr\u00e4nsade resurser, \u00e4r det mycket m\u00f6jligt att den inte kommer att fungera p\u00e5 grund av att noden f\u00e5r slut p\u00e5 minne eller saknar processorkraft. I den h\u00e4r artikeln kommer vi att unders\u00f6ka hur man kan l\u00f6sa problem med brist p\u00e5 datorkraft genom att anv\u00e4nda resursf\u00f6rfr\u00e5gningar och begr\u00e4nsningar.<\/p>\n

Requests och Limits \u00e4r mekanismer som Kubernetes anv\u00e4nder f\u00f6r att hantera resurser som processor och minne. Requests \u00e4r det som g\u00f6r att containern garanterat f\u00e5r den beg\u00e4rda resursen. Om en container beg\u00e4r en resurs kommer Kubernetes endast att schemal\u00e4gga den p\u00e5 den nod som kan tillhandah\u00e5lla den. Begr\u00e4nsningar Limits kontrollerar att resurserna som beg\u00e4rs av containern aldrig \u00f6verstiger ett visst v\u00e4rde.<\/p>\n

\"B\u00e4sta<\/a><\/noindex><\/p>\n

En container kan \u00f6ka ber\u00e4kningskraften endast upp till en viss gr\u00e4ns, efter vilken den kommer att begr\u00e4nsas. L\u00e5t oss titta p\u00e5 hur detta fungerar. S\u00e5, det finns tv\u00e5 typer av resurser \u2014 processor och minne. Kubernetes schemal\u00e4ggare anv\u00e4nder data om dessa resurser f\u00f6r att ta reda p\u00e5 var du ska k\u00f6ra dina pods. En typisk resurs specification f\u00f6r en pod ser ut s\u00e5 h\u00e4r.<\/p>\n

\"B\u00e4sta
\n
\nVarje container i en pod kan st\u00e4lla in sina egna krav och begr\u00e4nsningar, allt detta \u00e4r additivt. CPU-resurser anges i millik\u00e4rnor. Om din container kr\u00e4ver tv\u00e5 fulla k\u00e4rnor f\u00f6r att k\u00f6ra, anger du v\u00e4rdet 2000m. Om containment endast beh\u00f6ver kraften fr\u00e5n 1\/4 k\u00e4rna, kommer v\u00e4rdet att vara 250m. T\u00e4nk p\u00e5 att om du anger en resursallokering som \u00e4r h\u00f6gre \u00e4n antalet k\u00e4rnor i den st\u00f6rsta noden, kommer din pod inte att schemal\u00e4ggas \u00f6verhuvudtaget. En liknande situation uppst\u00e5r om du har en pod som kr\u00e4ver fyra k\u00e4rnor, medan Kubernetes-klustret endast best\u00e5r av tv\u00e5 huvud virtuella maskiner.<\/p>\n

Om inte din applikation \u00e4r specifikt utvecklad f\u00f6r att utnyttja f\u00f6rdelarna med flera k\u00e4rnor (exempelvis komplicerade vetenskapliga ber\u00e4kningar och databashantering), \u00e4r det b\u00e4sta praxis att st\u00e4lla in CPU-requests p\u00e5 1 eller l\u00e4gre, och sedan k\u00f6ra fler repliker f\u00f6r skalbarhet. Detta beslut ger systemet st\u00f6rre flexibilitet och p\u00e5litlighet.<\/p>\n

N\u00e4r det kommer till begr\u00e4nsningar av CPU blir allt mer intressant eftersom det anses vara en komprimerbar resurs. Om din applikation b\u00f6rjar n\u00e4rma sig gr\u00e4nsen f\u00f6r CPU-kraft, kommer Kubernetes att b\u00f6rja d\u00e4mpa din container med hj\u00e4lp av CPU Throttling - en s\u00e4nkning av processorfrekvensen. Det inneb\u00e4r att processorn kommer att begr\u00e4nsas artificiellt, vilket kan ge applikationen en potentiellt s\u00e4mre prestanda, men processen kommer inte att stoppas eller avslutas. <\/p>\n

Minne resurser anges i byte. Vanligtvis m\u00e4ts v\u00e4rdet i inst\u00e4llningarna i mebibyte (MiB), men du kan ange vilket v\u00e4rde som helst, fr\u00e5n byte till petabyte. H\u00e4r g\u00e4ller samma situation som f\u00f6r CPU - om du beg\u00e4r mer minne \u00e4n m\u00e4ngden minne i dina noder, kommer k\u00f6rningen av denna pod inte att schemal\u00e4ggas. Men till skillnad fr\u00e5n CPU-resurser kan minne inte komprimeras, eftersom det inte finns n\u00e5got s\u00e4tt att begr\u00e4nsa dess anv\u00e4ndning. D\u00e4rf\u00f6r kommer k\u00f6rningen av containern att stoppas s\u00e5 snart den \u00f6verskrider det tilldelade minnet.<\/p>\n

\"B\u00e4sta
\n
\nDet \u00e4r viktigt att komma ih\u00e5g att du inte kan konfigurera beg\u00e4rningar som \u00f6verskrider de resurser som dina noder kan tillhandah\u00e5lla. Specifikationerna f\u00f6r gemensamma resurser f\u00f6r GKE-virtuella maskiner finns i l\u00e4nkarna som finns under denna video.<\/p>\n

I en perfekt v\u00e4rld skulle standardinst\u00e4llningarna f\u00f6r containern vara tillr\u00e4ckliga f\u00f6r att arbetsfl\u00f6dena ska flyta smidigt. Men verkligheten \u00e4r en annan; m\u00e4nniskor kan l\u00e4tt gl\u00f6mma att konfigurera resursanv\u00e4ndning eller s\u00e5 kan hackare st\u00e4lla in beg\u00e4rningar och begr\u00e4nsningar som \u00f6verstiger infrastrukturens verkliga kapacitet. F\u00f6r att f\u00f6rhindra s\u00e5dana scenarier kan du konfigurera resurskvoter med ResourceQuota och begr\u00e4nsningsintervall med LimitRange.<\/p>\n

Efter att namnrymder har skapats kan de blockeras med hj\u00e4lp av kvoter. Till exempel, om du har namnrymderna prod och dev, anv\u00e4nds en mall d\u00e4r kvoter f\u00f6r produktion helt saknas medan kvoter f\u00f6r utveckling \u00e4r mycket strikta. Detta g\u00f6r att prod, vid en pl\u00f6tslig trafik\u00f6kning, kan ta hela den tillg\u00e4ngliga resursen och helt blockera dev.<\/p>\n

Resurskvoten kan se ut p\u00e5 f\u00f6ljande s\u00e4tt. I det h\u00e4r exemplet finns det 4 sektioner \u2013 det \u00e4r de 4 nedersta raderna av kod.<\/p>\n

\"B\u00e4sta
\n
\nL\u00e5t oss titta p\u00e5 var och en av dem. Requests.cpu \u00e4r det maximala antalet sammanlagda beg\u00e4rningar om processorkraft som kan komma fr\u00e5n alla containrar i namnrymden. I det h\u00e4r exemplet kan du ha 50 containrar med beg\u00e4rningar p\u00e5 10m, fem containrar med beg\u00e4rningar p\u00e5 100m, eller bara en container med en beg\u00e4ran p\u00e5 500m. S\u00e5 l\u00e4nge det totala antalet requests.cpu f\u00f6r namnrymden \u00e4r mindre \u00e4n 500m kommer allt att fungera.<\/p>\n

Beg\u00e4rd minne, requests.memory, \u00e4r den maximala m\u00e4ngden sammanlagda beg\u00e4rningar om minne som alla containrar i namnrymden kan ha. Som i f\u00f6reg\u00e5ende fall kan du ha 50 containrar med 2 MiB, fem containrar med 20 MiB, eller en enda container med 100 MiB, s\u00e5 l\u00e4nge den totala m\u00e4ngden beg\u00e4rt minne i namnrymden \u00e4r mindre \u00e4n 100 mebibyte.<\/p>\n

Limits.cpu \u00e4r det maximala sammanlagda v\u00e4rdet av processorkraft som alla containrar i namnrymden kan anv\u00e4nda. Det kan betraktas som en gr\u00e4ns f\u00f6r beg\u00e4rningar om processorkraft.<\/p>\n

Slutligen anger limits.memory det maximala beloppet av total minne som alla containrar inom namnutrymmet kan anv\u00e4nda. Detta \u00e4r en begr\u00e4nsning f\u00f6r det totala minnesanv\u00e4ndandet.
\nS\u00e5, som standard arbetar containrar i Kubernetes-klustret med obegr\u00e4nsade ber\u00e4kningsresurser. Genom resurskvoter kan klusteradministrat\u00f6rer begr\u00e4nsa resursanv\u00e4ndningen och skapandet baserat p\u00e5 namnutrymmet. Inom namnutrymmet kan en pod eller container anv\u00e4nda s\u00e5 mycket CPU och minne som definieras av resurskvoten f\u00f6r namnutrymmet. Det finns dock en oro f\u00f6r att en pod eller container kan monopolera alla tillg\u00e4ngliga resurser. F\u00f6r att f\u00f6rhindra en s\u00e5dan situation anv\u00e4nds limit Range \u2013 en policy f\u00f6r resursf\u00f6rdelningsbegr\u00e4nsning (f\u00f6r pods eller containrar) inom namnutrymmet.<\/p>\n

Limit Range tillhandah\u00e5ller begr\u00e4nsningar som kan:<\/p>\n