ProHoster > Blogs > Administrācija > Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Kubernetes labākā prakse. Mazo konteineru veidoŔana
Kubernetes labākā prakse. Kubernetes organizācija ar nosaukumvietu
Kubernetes labākā prakse. Kubernetes dzīvīguma apstiprināŔana, izmantojot gatavības un dzīvīguma testus

Katram Kubernetes resursam varat konfigurēt divu veidu prasÄ«bas ā€” pieprasÄ«jumus un ierobežojumus. Pirmajā ir aprakstÄ«tas minimālās prasÄ«bas brÄ«vo mezglu resursu pieejamÄ«bai, kas nepiecieÅ”ami konteinera vai podziņas palaiÅ”anai, otrajā ir stingri ierobežoti konteineram pieejamie resursi.

Kad Kubernetes plāno podiņus, ir ļoti svarÄ«gi, lai konteineriem bÅ«tu pietiekami daudz resursu, lai tie darbotos pareizi. Ja plānojat izvietot lielu lietojumprogrammu mezglā, kurā ir ierobežoti resursi, iespējams, ka tā nedarbosies, jo mezglam ir maz atmiņas vai CPU jauda. Å ajā rakstā mēs apskatÄ«sim, kā jÅ«s varat atrisināt skaitļoÅ”anas jaudas trÅ«kumu, izmantojot resursu pieprasÄ«jumus un ierobežojumus.

PieprasÄ«jumi un ierobežojumi ir mehānismi, ko Kubernetes izmanto, lai pārvaldÄ«tu tādus resursus kā CPU un atmiņa. PieprasÄ«jumi nodroÅ”ina, ka konteiners saņem pieprasÄ«to resursu. Ja konteiners pieprasa resursu, Kubernetes to ieplānos tikai mezglā, kas to var nodroÅ”ināt. Ierobežo kontroli, ka konteinera pieprasÄ«tie resursi nekad nepārsniegs noteiktu vērtÄ«bu.

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Konteiners var palielināt savu skaitļoÅ”anas jaudu tikai lÄ«dz noteiktai robežai, pēc kuras tā tiks ierobežota. ApskatÄ«sim, kā tas darbojas. Tātad ir divu veidu resursi - procesors un atmiņa. Kubernetes plānotājs izmanto datus par Å”iem resursiem, lai noskaidrotu, kur palaist savus aplikumus. Tipiska resursa specifikācija podam izskatās Ŕādi.

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Katrs podā esoÅ”ais konteiners var iestatÄ«t savus vaicājumus un ierobežojumus, tas viss ir aditÄ«vs. Procesora resursi ir definēti milicores. Ja konteinera darbÄ«bai ir nepiecieÅ”ami divi pilni serdeņi, iestatiet vērtÄ«bu uz 2000 m. Ja konteineram nepiecieÅ”ama tikai 1/4 kodola jauda, ā€‹ā€‹vērtÄ«ba bÅ«s 250 m. Ņemiet vērā: ja pieŔķirat CPU resursa vērtÄ«bu, kas ir lielāka par lielākā mezgla kodolu skaitu, jÅ«su podziņa vispār netiks ieplānota. LÄ«dzÄ«ga situācija notiks, ja jums ir Pod, kuram nepiecieÅ”ami četri kodoli, un Kubernetes klasteris sastāv tikai no divām galvenajām virtuālajām maŔīnām.

Ja vien jÅ«su lietojumprogramma nav Ä«paÅ”i izstrādāta, lai izmantotu vairāku kodolu sniegtās priekÅ”rocÄ«bas (jÅ«su prātā nāk tādas programmas kā sarežģītas zinātniskas skaitļoÅ”anas un datu bāzes darbÄ«bas), vislabākā prakse ir iestatÄ«t CPU pieprasÄ«jumu vērtÄ«bu uz 1 vai mazāku un pēc tam palaist vairāk reprodukciju, lai nodroÅ”inātu mērogojamÄ«bu. Å is risinājums nodroÅ”inās sistēmai lielāku elastÄ«bu un uzticamÄ«bu.

Runājot par CPU ierobežojumiem, lietas kļūst interesantākas, jo tas tiek uzskatīts par saspiežamu resursu. Ja jūsu lietojumprogramma sāk tuvoties procesora jaudas ierobežojumam, Kubernetes sāks palēnināt jūsu konteinera darbību, izmantojot CPU droseles, samazinot procesora frekvenci. Tas nozīmē, ka centrālais procesors tiks mākslīgi nobloķēts, radot lietojumprogrammai potenciāli sliktāku veiktspēju, taču process netiks pārtraukts vai izņemts.

Atmiņas resursi ir definēti baitos. Parasti vērtÄ«ba iestatÄ«jumos tiek mērÄ«ta mebibaitos Mib, taču jÅ«s varat iestatÄ«t jebkuru vērtÄ«bu, sākot no baitiem lÄ«dz petabaitiem. Å eit ir tā pati situācija, kas attiecas uz centrālo procesoru ā€” ja izvietojat pieprasÄ«jumu pēc atmiņas apjoma, kas ir lielāks par jÅ«su mezglu atmiņas apjomu, Ŕī podziņa izpilde netiks ieplānota. Bet atŔķirÄ«bā no CPU resursiem atmiņa netiek saspiesta, jo nav iespējas ierobežot tās izmantoÅ”anu. Tāpēc konteinera izpilde tiks apturēta, tiklÄ«dz tā pārsniegs tam pieŔķirto atmiņu.

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Ir svarÄ«gi atcerēties, ka nevarat konfigurēt pieprasÄ«jumus, kas pārsniedz resursus, ko var nodroÅ”ināt jÅ«su mezgli. KopÄ«goto resursu specifikācijas GKE virtuālajām maŔīnām var atrast saitēs zem Ŕī videoklipa.

Ideālā pasaulē konteinera noklusējuma iestatÄ«jumi bÅ«tu pietiekami, lai darbplÅ«smas darbotos nevainojami. Taču reālā pasaule nav tāda, cilvēki var viegli aizmirst konfigurēt resursu izmantoÅ”anu, vai arÄ« hakeri uzstādÄ«s pieprasÄ«jumus un ierobežojumus, kas pārsniedz infrastruktÅ«ras reālās iespējas. Lai novērstu Ŕādu scenāriju raÅ”anos, varat konfigurēt ResourceQuota un LimitRange resursu kvotas.

Kad nosaukumvieta ir izveidota, to var bloķēt, izmantojot kvotas. Piemēram, ja jums ir prod un dev nosaukumvietas, tad vispār nav ražoÅ”anas kvotu un ļoti stingras izstrādes kvotas. Tas ļauj prod straujas satiksmes pieauguma gadÄ«jumā pārņemt visu pieejamo resursu, pilnÄ«bā bloķējot izstrādātāju.

Resursu kvota varētu izskatÄ«ties Ŕādi. Å ajā piemērā ir 4 sadaļas - tās ir 4 koda apakŔējās rindas.

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

ApskatÄ«sim katru no tiem. Requests.cpu ir maksimālais kombinēto CPU pieprasÄ«jumu skaits, kas var nākt no visiem nosaukumvietas konteineriem. Å ajā piemērā jums varētu bÅ«t 50 konteineri ar 10 m pieprasÄ«jumiem, pieci konteineri ar 100 m pieprasÄ«jumiem vai tikai viens konteiners ar 500 m pieprasÄ«jumiem. Kamēr kopējais pieprasÄ«jumu.cpu skaits konkrētajā nosaukumvietā ir mazāks par 500 m, viss bÅ«s kārtÄ«bā.

Atmiņai pieprasÄ«tie pieprasÄ«jumi.atmiņa ir maksimālais kombinēto atmiņas pieprasÄ«jumu skaits, kas var bÅ«t visiem nosaukumvietas konteineriem. Tāpat kā iepriekŔējā gadÄ«jumā, jums var bÅ«t 50 2 mib konteineri, pieci 20 mib konteineri vai viens 100 mib konteiners, ja kopējais nosaukumvietā pieprasÄ«tās atmiņas apjoms ir mazāks par 100 mib.

Limits.cpu ir maksimālais apvienotais CPU jaudas daudzums, ko var izmantot visi nosaukumvietas konteineri. Mēs varam uzskatīt, ka tas ir procesora jaudas pieprasījumu ierobežojums.

Visbeidzot limits.memory ir maksimālais koplietotās atmiņas apjoms, ko var izmantot visi nosaukumvietas konteineri. Šis ir kopējais atmiņas pieprasījumu ierobežojums.
Tātad pēc noklusējuma konteineri Kubernetes klasterÄ« darbojas ar neierobežotiem skaitļoÅ”anas resursiem. Izmantojot resursu kvotas, klasteru administratori var ierobežot resursu patēriņu un resursu izveidi, pamatojoties uz nosaukumvietu. Nosaukumvietā pods vai konteiners var patērēt tik daudz CPU jaudas un atmiņas, ko nosaka nosaukumvietas resursu kvota. Tomēr pastāv bažas, ka viens pods vai konteiners var monopolizēt visus pieejamos resursus. Lai novērstu Å”o situāciju, tiek izmantots ierobežojuma diapazons - politika resursu pieŔķirÅ”anas ierobežoÅ”anai (podiem vai konteineriem) nosaukumvietā.

Ierobežojumu diapazons nodroŔina ierobežojumus, kas var:

  • NodroÅ”ināt minimālo un maksimālo skaitļoÅ”anas resursu izmantoÅ”anu katram modulim vai konteineram nosaukumu telpā;
  • ieviest minimālo un maksimālo Starage Request krātuves pieprasÄ«jumus katram PersistentVolumeClaim nosaukumvietā;
  • ieviest attiecÄ«bas starp PieprasÄ«jumu un Limit resursam nosaukumvietā;
  • iestatiet noklusējuma pieprasÄ«jumus/ierobežojumus skaitļoÅ”anas resursiem nosaukumvietā un automātiski ievadiet tos konteineros izpildlaikā.

Tādā veidā jÅ«s varat izveidot ierobežojumu diapazonu savā nosaukumvietā. AtŔķirÄ«bā no kvotas, kas attiecas uz visu nosaukumvietu, ierobežojuma diapazons tiek izmantots atseviŔķiem konteineriem. Tas var neļaut lietotājiem izveidot ļoti mazus vai, gluži pretēji, milzÄ«gus konteinerus nosaukumvietā. Ierobežojumu diapazons varētu izskatÄ«ties Ŕādi.

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Tāpat kā iepriekŔējā gadÄ«jumā, Å”eit var izdalÄ«t 4 sadaļas. ApskatÄ«sim katru.
Noklusējuma sadaļā tiek iestatÄ«ti noklusējuma ierobežojumi podā esoÅ”ajam konteineram. Ja Ŕīs vērtÄ«bas iestatāt galējā diapazonā, visi konteineri, kuriem Ŕīs vērtÄ«bas nav skaidri iestatÄ«tas, izmantos noklusējuma vērtÄ«bas.

Noklusējuma pieprasÄ«juma sadaļa defaultRequest konfigurē noklusējuma pieprasÄ«jumus konteineram podā. Atkal, ja iestatāt Ŕīs vērtÄ«bas uz galējo diapazonu, visiem konteineriem, kas Ŕīs opcijas nav skaidri iestatÄ«tas, pēc noklusējuma tiks izmantotas Ŕīs vērtÄ«bas.

Maks. sadaļā ir norādÄ«ti maksimālie ierobežojumi, ko var iestatÄ«t podā esoÅ”ajam konteineram. Noklusējuma sadaļas vērtÄ«bas un konteineru ierobežojumus nevar iestatÄ«t virs Ŕī ierobežojuma. Ir svarÄ«gi atzÄ«mēt, ka, ja vērtÄ«ba ir iestatÄ«ta uz max un nav noklusējuma sadaļas, maksimālā vērtÄ«ba kļūst par noklusējuma vērtÄ«bu.

Minimālajā sadaļā ir norādÄ«ti minimālie pieprasÄ«jumi, ko var iestatÄ«t podā esoÅ”ajam konteineram. Tomēr vērtÄ«bas noklusējuma sadaļā un konteinera vaicājumos nevar iestatÄ«t zem Ŕī ierobežojuma.

Atkal ir svarÄ«gi atzÄ«mēt, ka, ja Ŕī vērtÄ«ba ir iestatÄ«ta, noklusējuma vērtÄ«ba nav, tad minimālā vērtÄ«ba kļūst par noklusējuma uzvedni.

Å os resursu pieprasÄ«jumus galu galā izmanto Kubernetes plānotājs, lai izpildÄ«tu jÅ«su darba slodzes. Lai pareizi konfigurētu konteinerus, ir ļoti svarÄ«gi saprast, kā tas darbojas. Pieņemsim, ka vēlaties savā klasterÄ« palaist vairākus aplikumus. Pieņemot, ka pod specifikācijas ir derÄ«gas, Kubernetes grafiks izmantos apļveida balansÄ“Å”anu, lai atlasÄ«tu mezglu darba slodzes izpildei.

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Kubernetes pārbaudÄ«s, vai 1. mezglam ir pietiekami daudz resursu, lai izpildÄ«tu pieprasÄ«jumus no pod konteineriem, un, ja tā nav, tas pāries uz nākamo mezglu. Ja neviens no sistēmas mezgliem nevar apmierināt pieprasÄ«jumus, podi pāries gaidÄ«Å”anas stāvoklÄ«. Izmantojot Google Kubernetes dzinēja funkcijas, piemēram, mezglu automātisko mērogoÅ”anu, GKE var automātiski noteikt gaidÄ«Å”anas stāvokli un izveidot vēl vairākus papildu mezglus.

Ja pēc tam beigsies mezgla jauda, ā€‹ā€‹automātiskā mērogoÅ”ana samazinās mezglu skaitu, lai ietaupÄ«tu naudu. Tāpēc Kubernetes ieplāno aplikumus, pamatojoties uz pieprasÄ«jumiem. Tomēr ierobežojums var bÅ«t lielāks par pieprasÄ«jumiem, un dažos gadÄ«jumos mezglam faktiski var beigties resursi. Mēs Å”o stāvokli saucam par pārmērÄ«gas saistÄ«bas stāvokli.

Kubernetes labākā prakse. Resursu pieprasījumu un ierobežojumu iestatīŔana

Kā jau teicu, kad runa ir par centrālo procesoru, Kubernetes sāks ierobežot podziņus. Katrs pods saņems tik daudz, cik tas ir pieprasījis, bet, ja tas nesasniegs ierobežojumu, tiks piemērota drosele.

Runājot par atmiņas resursiem, Kubernetes ir spiests pieņemt lēmumus par to, kuras podziņas dzēst un kuras paturēt, līdz tiek atbrīvoti sistēmas resursi vai visa sistēma avarēsies.

Iedomāsimies scenāriju, kurā maŔīnai pietrÅ«kst atmiņas ā€” kā Kubernetes to risinātu?

Kubernetes meklēs aplikumus, kas patērē vairāk resursu, nekā prasÄ«ts. Tātad, ja jÅ«su konteineriem vispār nav pieprasÄ«jumu, tas nozÄ«mē, ka tie pēc noklusējuma izmanto vairāk, nekā pieprasÄ«ja, vienkārÅ”i tāpēc, ka viņi vispār neko neprasÄ«ja. Šādi konteineri kļūst par galvenajiem slēgÅ”anas kandidātiem. Nākamie kandidāti ir konteineri, kas ir apmierinājuÅ”i visus viņu pieprasÄ«jumus, bet joprojām ir zem maksimālās robežas.

Tātad, ja Kubernetes atrod vairākus aplikumus, kas ir pārsnieguÅ”i pieprasÄ«jumu parametrus, tas sakārtos tos pēc prioritātes un pēc tam noņems zemākās prioritātes aplikumus. Ja visiem podiem ir vienāda prioritāte, Kubernetes pārtrauks tos aplikumus, kas pārsniedz to pieprasÄ«jumus vairāk nekā citi podi.

Ļoti retos gadījumos Kubernetes var pārtraukt pākstis, kas joprojām ir viņu pieprasījumu darbības jomā. Tas var notikt, ja kritiskie sistēmas komponenti, piemēram, Kubelet aģents vai Docker, sāk patērēt vairāk resursu, nekā tiem bija rezervēts.
Tātad mazo uzņēmumu sākumposmā Kubernetes klasteris var darboties labi, nenosakot resursu pieprasÄ«jumus un ierobežojumus, taču, kad jÅ«su komandas un projekti sāk pieaugt, jÅ«s riskējat saskarties ar problēmām Å”ajā jomā. Vaicājumu un ierobežojumu pievienoÅ”ana moduļiem un nosaukumvietām prasa ļoti maz papildu pūļu un var ietaupÄ«t daudz problēmu.

Kubernetes labākā prakse. Pareiza izslēgÅ”ana Pārtraukt

Dažas reklāmas šŸ™‚

Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, mākoņa VPS izstrādātājiem no 4.99 USD, unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: Visa patiesība par VPS (KVM) E5-2697 v3 (6 kodoli) 10GB DDR4 480GB SSD 1Gbps no 19$ vai kā koplietot serveri? (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).

Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai Å”eit 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV no 199$ NÄ«derlandē! Dell R420 ā€” 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā€” no 99 USD! LasÄ«t par Kā izveidot infrastruktÅ«ras uzņēmumu klase ar Dell R730xd E5-2650 v4 serveru izmantoÅ”anu 9000 eiro par santÄ«mu?

Avots: www.habr.com

Pievieno komentāru