{"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\/hr\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Najbolje prakse Kubernetes-a. Konfiguracija zahtjeva i ograni\u010denja resursa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Najbolje prakse Kubernetes-a. Kreiranje malih kontejnera.<\/a><\/noindex>
\nNajbolje prakse Kubernetes-a. Organiziranje Kubernetes-a s prostorima imena.<\/a><\/noindex>
\nNajbolje prakse Kubernetes-a. Provjera \u017eivotne sposobnosti Kubernetes-a pomo\u0107u Readiness i Liveness testova.<\/a><\/noindex><\/p>\n

Za svaki Kubernetes resurs postoji mogu\u0107nost postavljanja dva tipa zahtjeva \u2014 Requests i Limits. Prvi opisuje minimalne zahtjeve za slobodnim resursima \u010dvora koji su potrebni za pokretanje kontejnera ili poda, dok drugi strogo ograni\u010dava resurse dostupne kontejneru. <\/p>\n

Kada Kubernetes planira pod, vrlo je va\u017eno da kontejneri imaju dovoljno resursa za normalan rad. Ako planirate implementirati veliku aplikaciju na \u010dvoru s ograni\u010denim resursima, mogu\u0107e je da ne\u0107e raditi zbog nedostatka memorije ili procesorske snage na \u010dvoru. U ovom \u010dlanku \u0107emo razmotriti kako rije\u0161iti probleme nedostatka ra\u010dunalnih resursa kroz zahtjeve za resursima i ograni\u010denja.<\/p>\n

Zahtjevi Requests i ograni\u010denja Limits su mehanizmi koje Kubernetes koristi za upravljanje resursima poput procesora i memorije. Requests osiguravaju da kontejner dobije tra\u017eeni resurs. Ako kontejner tra\u017ei resurs, Kubernetes \u0107e ga planirati samo na onom \u010dvoru koji ga mo\u017ee pru\u017eiti. Ograni\u010denja Limits kontroliraju da resursi koje kontejner tra\u017ei nikada ne prema\u0161e odre\u0111enu vrijednost.<\/p>\n

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

Kontejner mo\u017ee pove\u0107ati ra\u010dunalne resurse samo do odre\u0111enog limita, nakon \u010dega \u0107e biti ograni\u010den. Pogledajmo kako to funkcionira. Dakle, postoje dva tipa resursa \u2014 procesor i memorija. Kubernetesov planirnik koristi podatke o tim resursima kako bi utvrdio gdje pokrenuti va\u0161e pode. Tipi\u010dna specifikacija resursa za pod izgleda ovako.<\/p>\n

\"Najbolje
\n
\nSvaka posuda u podu mo\u017ee postaviti svoje vlastite zahtjeve i ograni\u010denja, a sve je to aditivno. Resursi procesora odre\u0111uju se u milikorama. Ako va\u0161 kontejner treba dva puna jezgra za pokretanje, postavljate vrijednost na 2000m. Ako kontejneru treba samo 1\/4 jezgra, vrijednost \u0107e biti 250m. Imajte na umu da ako dodijelite vrijednost resursa procesora ve\u0107u od broja jezgra najve\u0107e nodne jedinice, va\u0161a pod jedinica ne\u0107e biti planirana. Sli\u010dna situacija \u0107e se dogoditi ako imate pod koji zahtijeva \u010detiri jezgra, a Kubernetes klaster se sastoji od samo dva glavna virtualna stroja.<\/p>\n

Osim ako va\u0161a aplikacija nije posebno dizajnirana za iskori\u0161tavanje prednosti vi\u0161e jezgara (na umu imamo programe poput slo\u017eenih znanstvenih prora\u010duna i operacija s bazama podataka), najbolja praksa je postaviti zahtjeve za CPU na 1 ili ni\u017ee, a zatim pokrenuti ve\u0107i broj replika radi skalabilnosti. Ovo rje\u0161enje \u0107e sustavu dati ve\u0107u fleksibilnost i pouzdanost.<\/p>\n

Kada su u pitanju ograni\u010denja procesora, situacija postaje zanimljivija, jer se processor smatra kompresibilnim resursom. Ako va\u0161a aplikacija po\u010dne dolaziti do limita procesorske snage, Kubernetes \u0107e po\u010deti usporavati va\u0161 kontejner koriste\u0107i CPU Throttling \u2014 smanjenje frekvencije procesora. To zna\u010di da \u0107e procesor biti umjetno ograni\u010den, \u0161to mo\u017ee dovesti do lo\u0161ije izvedbe aplikacije, ali proces ne\u0107e biti prekinut ili isklju\u010den. <\/p>\n

Resursi memorije odre\u0111uju se u bajtovima. Obi\u010dno se vrijednost u postavkama mjeri u mebibajtima Mib, ali mo\u017eete postaviti bilo koju vrijednost, od bajtova do petabajta. Ovdje vrijedi ista situacija kao i s CPU-om \u2014 ako postavite zahtjev za memorijom koji prema\u0161uje kapacitet memorije va\u0161ih nodova, izvr\u0161enje te pod jedinice ne\u0107e biti planirano. No, za razliku od resursa procesora, memorija se ne mo\u017ee komprimirati jer ne postoji na\u010din da se ograni\u010di njezina upotreba. Stoga \u0107e izvr\u0161enje kontejnera biti zaustavljeno \u010dim prema\u0161i dodijeljenu memoriju.<\/p>\n

\"Najbolje
\n
\nVa\u017eno je zapamtiti da ne mo\u017eete postaviti zahtjeve koji prema\u0161uju veli\u010dinu resursa koje va\u0161i \u010dvorovi mogu osigurati. Zna\u010dajke zajedni\u010dkih resursa za GKE virtualne strojeve mo\u017eete prona\u0107i putem poveznica postavljenih ispod ovog videozapisa.<\/p>\n

U idealnom svijetu, zadane postavke kontejnera su sasvim dovoljne da radni procesi pro\u0111u glatko. No, stvarni svijet nije takav; ljudi lako mogu zaboraviti postaviti upotrebu resursa ili hakeri mogu postaviti zahtjeve i ograni\u010denja koja prema\u0161uju stvarne mogu\u0107nosti infrastrukture. Kako biste sprije\u010dili razvoj takvih scenarija, mo\u017eete postaviti kvote resursa ResourceQuota i raspon ograni\u010denja LimitRange.<\/p>\n

Nakon stvaranja prostora imena, mo\u017eete ih zaklju\u010dati pomo\u0107u kvota. Na primjer, ako imate prostore imena prod i dev, koristi se predlo\u017eak u kojem kvote za produkciju uop\u0107e ne postoje, dok su kvote za razvoj vrlo stroge. To omogu\u0107ava da prod u slu\u010daju naglog porasta prometa preuzme sve dostupne resurse, potpuno blokiraju\u0107i dev.<\/p>\n

Kvote resursa mogu izgledati ovako. U ovom primjeru postoje 4 odjeljka \u2013 to su 4 donje linije koda.<\/p>\n

\"Najbolje
\n
\nPogledajmo svaki od njih. Requests.cpu \u2014 to je maksimalni broj kombiniranih zahtjeva procesorske snage koji mogu dolaziti od svih kontejnera u prostoru imena. U ovom primjeru mo\u017eete imati 50 kontejnera s zahtjevima od 10m, pet kontejnera s zahtjevima od 100m ili jednostavno jedan kontejner s zahtjevom od 500m. Dok ukupni broj requests.cpu ovog prostora imena bude manji od 500m, sve \u0107e biti u redu.<\/p>\n

Zahtijevana memorija requests.memory \u2014 to je maksimalna koli\u010dina kombiniranih zahtjeva memorije koju svi kontejneri u prostoru imena mogu imati. Kao i u prethodnom slu\u010daju, mo\u017eete imati 50 kontejnera po 2 mib, pet kontejnera po 20 Mib ili jedan kontejner s 100 Mib, sve dok ukupna koli\u010dina zahtijevane memorije u prostoru imena bude manja od 100 mebibajta.<\/p>\n

Limits.cpu \u2014 to je maksimalna kombinirana vrijednost procesorske snage koju mogu koristiti svi kontejneri u prostoru imena. Mo\u017ee se smatrati da je to limit za zahtjeve procesorske snage.<\/p>\n

Na kraju, limits.memory \u2013 maksimalna koli\u010dina ukupne memorije koju mogu koristiti svi kontejneri u imenskom prostoru. Ova ograni\u010denja su zbirni zahtevi memorije.
\nDakle, prema zadanim postavkama, kontejneri u Kubernetes klasteru rade s neograni\u010denim ra\u010dunalnim resursima. Pomo\u0107u kvota resursa, administratori klastera mogu ograni\u010diti potro\u0161nju resursa i njihovo stvaranje na osnovu imenskih prostora. U imenskom prostoru, pod moduli ili kontejneri mogu konzumirati onoliko CPU snage i memorije koliko je odre\u0111eno kvotom resursa imenog prostora. Me\u0111utim, postoji zabrinutost da jedan pod ili kontejner mo\u017ee monopolizovati sve dostupne resurse. Da bi se sprije\u010dila takva situacija, koristi se predjelni opseg limit Range \u2013 politika ograni\u010davanja raspodjele resursa (za podove ili kontejnere) u imenskom prostoru.<\/p>\n

Predjelni opseg pru\u017ea ograni\u010denja koja mogu:<\/p>\n