{"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\/pl\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Najlepsze praktyki Kubernetes. Konfiguracja \u017c\u0105da\u0144 i limit\u00f3w zasob\u00f3w","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Najlepsze praktyki Kubernetes. Tworzenie ma\u0142ych kontener\u00f3w<\/a><\/noindex>
\nNajlepsze praktyki Kubernetes. Organizacja Kubernetes z przestrzeni\u0105 nazw<\/a><\/noindex>
\nNajlepsze praktyki Kubernetes. Sprawdzanie \u017cywotno\u015bci Kubernetes za pomoc\u0105 test\u00f3w Readiness i Liveness<\/a><\/noindex><\/p>\n

Dla ka\u017cdego zasobu Kubernetes istnieje mo\u017cliwo\u015b\u0107 skonfigurowania dw\u00f3ch typ\u00f3w wymaga\u0144 - Requests i Limits. Pierwsze opisuje minimalne wymagania dotycz\u0105ce dost\u0119pno\u015bci wolnych zasob\u00f3w w\u0119z\u0142a, niezb\u0119dnych do uruchomienia kontenera lub poda, a drugie sztywno ogranicza zasoby dost\u0119pne dla kontenera. <\/p>\n

Kiedy Kubernetes planuje pod, bardzo wa\u017cne jest, aby kontenery mia\u0142y wystarczaj\u0105ce zasoby do normalnego dzia\u0142ania. Je\u015bli planujesz wdro\u017cy\u0107 du\u017c\u0105 aplikacj\u0119 na w\u0119\u017ale z ograniczonymi zasobami, istnieje du\u017ce prawdopodobie\u0144stwo, \u017ce nie b\u0119dzie ona dzia\u0142a\u0107 z powodu braku pami\u0119ci lub niewystarczaj\u0105cej mocy procesora. W tym artykule om\u00f3wimy, jak mo\u017cna rozwi\u0105za\u0107 problemy z brakiem mocy obliczeniowej za pomoc\u0105 \u017c\u0105da\u0144 zasob\u00f3w i ogranicze\u0144.<\/p>\n

\u017b\u0105dania Requests i ograniczenia Limits to mechanizmy, kt\u00f3re Kubernetes wykorzystuje do zarz\u0105dzania takimi zasobami jak procesor i pami\u0119\u0107. Requests to to, dzi\u0119ki czemu kontener gwarantowanie otrzymuje \u017c\u0105dany zas\u00f3b. Je\u015bli kontener \u017c\u0105da zasobu, Kubernetes zaplanuje go tylko na tym w\u0119\u017ale, kt\u00f3ry jest w stanie go zapewni\u0107. Ograniczenia Limits kontroluj\u0105, \u017ce zasoby \u017c\u0105dane przez kontener nigdy nie przekrocz\u0105 okre\u015blonej warto\u015bci.<\/p>\n

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

Kontener mo\u017ce zwi\u0119ksza\u0107 moce obliczeniowe tylko do okre\u015blonego limitu, po czym b\u0119dzie ograniczony. Przyjrzyjmy si\u0119, jak to dzia\u0142a. Istniej\u0105 dwa typy zasob\u00f3w - procesor i pami\u0119\u0107. Planista Kubernetes wykorzystuje dane o tych zasobach, aby ustali\u0107, gdzie uruchamia\u0107 Twoje pady. Typowa specyfikacja zasob\u00f3w dla poda wygl\u0105da tak.<\/p>\n

\"Najlepsze
\n
\nKa\u017cdy kontener w podzie mo\u017ce ustawia\u0107 w\u0142asne limity i zapotrzebowania, wszystko odbywa si\u0119 w spos\u00f3b addytywny. Zasoby procesora okre\u015blane s\u0105 w mili-core'ach. Je\u015bli tw\u00f3j kontener potrzebuje do dzia\u0142ania dw\u00f3ch pe\u0142nych rdzeni, ustalasz warto\u015b\u0107 2000m. Je\u015bli natomiast kontener wymaga tylko 1\/4 rdzenia, warto\u015b\u0107 wyniesie 250m. Pami\u0119taj, \u017ce je\u015bli przydzielisz warto\u015b\u0107 zasob\u00f3w procesora wi\u0119ksz\u0105 ni\u017c liczba rdzeni najwi\u0119kszego w\u0119z\u0142a, uruchomienie twojego poda w og\u00f3le nie zostanie zaplanowane. Podobna sytuacja zajdzie, je\u015bli b\u0119dziesz mia\u0142 pod, kt\u00f3ry potrzebuje czterech rdzeni, a klaster Kubernetes sk\u0142ada si\u0119 tylko z dw\u00f3ch podstawowych maszyn wirtualnych.<\/p>\n

O ile twoja aplikacja nie jest specjalnie zaprojektowana do wykorzystania zalet wielu rdzeni (na my\u015bli mam takie programy jak zaawansowane obliczenia naukowe oraz operacje na bazach danych), to najlepsz\u0105 praktyk\u0105 jest ustawienie zapotrzebowania CPU na 1 lub mniej, a nast\u0119pnie uruchomienie wi\u0119kszej liczby replik dla skalowalno\u015bci. Takie rozwi\u0105zanie nada systemowi wi\u0119ksz\u0105 elastyczno\u015b\u0107 i niezawodno\u015b\u0107.<\/p>\n

Kiedy mowa o limitach procesora, sytuacja staje si\u0119 ciekawsza, poniewa\u017c jest on uwa\u017cany za zas\u00f3b kompresowalny. Je\u015bli twoja aplikacja zacznie zbli\u017ca\u0107 si\u0119 do limitu mocy procesora, Kubernetes zacznie spowalnia\u0107 tw\u00f3j kontener, wykorzystuj\u0105c CPU Throttling \u2014 obni\u017cenie cz\u0119stotliwo\u015bci procesora. Oznacza to, \u017ce procesor b\u0119dzie sztucznie ograniczany, co mo\u017ce prowadzi\u0107 do gorszej wydajno\u015bci aplikacji, jednak proces nie zostanie przerwany ani zako\u0144czony. <\/p>\n

Zasoby pami\u0119ci okre\u015blane s\u0105 w bajtach. Zazwyczaj warto\u015b\u0107 w ustawieniach mierzona jest w mebibajtach Mib, ale mo\u017cesz ustawi\u0107 dowoln\u0105 warto\u015b\u0107, od bajt\u00f3w do petabajt\u00f3w. Sytuacja z pami\u0119ci\u0105 jest podobna do tej z CPU \u2014 je\u015bli umie\u015bcisz zapotrzebowanie na ilo\u015b\u0107 pami\u0119ci przekraczaj\u0105c\u0105 dost\u0119pno\u015b\u0107 pami\u0119ci na twoich w\u0119z\u0142ach, wykonanie tego poda nie b\u0119dzie zaplanowane. Jednak w odr\u00f3\u017cnieniu od zasob\u00f3w procesora, pami\u0119\u0107 nie jest kompresowalna, poniewa\u017c nie ma sposobu na ograniczenie jej u\u017cycia. Dlatego wykonanie kontenera zostanie zatrzymane, gdy tylko przekroczy przydzielon\u0105 mu pami\u0119\u0107.<\/p>\n

\"Najlepsze
\n
\nWa\u017cne jest, aby pami\u0119ta\u0107, \u017ce nie mo\u017cesz ustawi\u0107 zapyta\u0144, kt\u00f3re przekraczaj\u0105 rozmiar zasob\u00f3w, jakie mog\u0105 zapewni\u0107 twoje w\u0119z\u0142y. Cechy wsp\u00f3lnych zasob\u00f3w dla maszyn wirtualnych GKE mo\u017cna znale\u017a\u0107 w linkach umieszczonych poni\u017cej tego wideo.<\/p>\n

W idealnym \u015bwiecie domy\u015blne ustawienia kontenera powinny by\u0107 wystarczaj\u0105ce, aby procesy przebiega\u0142y g\u0142adko. Jednak rzeczywisto\u015b\u0107 jest inna \u2013 ludzie mog\u0105 \u0142atwo zapomnie\u0107 o konfiguracji wykorzystania zasob\u00f3w, a hakerzy mog\u0105 ustawi\u0107 zapytania i ograniczenia przekraczaj\u0105ce rzeczywiste mo\u017cliwo\u015bci infrastruktury. Aby zapobiec takim scenariuszom, mo\u017cna skonfigurowa\u0107 kwoty zasob\u00f3w ResourceQuota oraz zakresy limit\u00f3w LimitRange.<\/p>\n

Po utworzeniu przestrzeni nazw mo\u017cna je zablokowa\u0107 za pomoc\u0105 kwot. Na przyk\u0142ad, je\u015bli masz przestrzenie nazw prod i dev, stosuje si\u0119 wz\u00f3r, w kt\u00f3rym kwoty dla produkcji s\u0105 ca\u0142kowicie nieobecne, a kwoty dla rozwoju s\u0105 bardzo rygorystyczne. Pozwala to na to, aby w przypadku nag\u0142ego wzrostu ruchu, prod m\u00f3g\u0142 zaj\u0105\u0107 ca\u0142y dost\u0119pny zas\u00f3b, ca\u0142kowicie blokuj\u0105c dev.<\/p>\n

Kwota zasob\u00f3w mo\u017ce wygl\u0105da\u0107 w ten spos\u00f3b. W tym przyk\u0142adzie mamy 4 sekcje \u2013 to 4 dolne linie kodu.<\/p>\n

\"Najlepsze
\n
\nPrzyjrzyjmy si\u0119 ka\u017cdemu z nich. Requests.cpu to maksymalna liczba skumulowanych zapyta\u0144 mocy procesora, kt\u00f3re mog\u0105 pochodzi\u0107 ze wszystkich kontener\u00f3w w przestrzeni nazw. W tym przyk\u0142adzie mo\u017cesz mie\u0107 50 kontener\u00f3w z zapytaniami po 10m, pi\u0119\u0107 kontener\u00f3w z zapytaniami po 100m lub po prostu jeden kontener z zapytaniem 500m. Dop\u00f3ki ca\u0142kowita liczba requests.cpu tej przestrzeni nazw b\u0119dzie mniejsza ni\u017c 500m, wszystko b\u0119dzie w porz\u0105dku.<\/p>\n

Zapytana pami\u0119\u0107 requests.memory to maksymalna warto\u015b\u0107 skumulowanych zapyta\u0144 pami\u0119ci, kt\u00f3re mog\u0105 mie\u0107 wszystkie kontenery w przestrzeni nazw. Podobnie jak wcze\u015bniej, mo\u017cesz mie\u0107 50 kontener\u00f3w po 2 MiB, pi\u0119\u0107 kontener\u00f3w po 20 MiB lub jeden kontener z 100 MiB, dop\u00f3ki ca\u0142kowita liczba zapytanej pami\u0119ci w przestrzeni nazw b\u0119dzie mniejsza ni\u017c 100 mebibajt\u00f3w.<\/p>\n

Limits.cpu to maksymalna skumulowana warto\u015b\u0107 mocy procesora, kt\u00f3r\u0105 mog\u0105 wykorzysta\u0107 wszystkie kontenery w przestrzeni nazw. Mo\u017cna to postrzega\u0107 jako limit zapyta\u0144 mocy procesora.<\/p>\n

Ostatecznie, limits.memory to maksymalna ilo\u015b\u0107 pami\u0119ci og\u00f3lnej, kt\u00f3r\u0105 mog\u0105 wykorzysta\u0107 wszystkie kontenery w przestrzeni nazw. To ograniczenie sumarycznych \u017c\u0105da\u0144 pami\u0119ci.
\nDomy\u015blnie kontenery w klastrze Kubernetes dzia\u0142aj\u0105 z nieograniczonymi zasobami obliczeniowymi. Dzi\u0119ki kwotom zasob\u00f3w, administratorzy klastra mog\u0105 ograniczy\u0107 zu\u017cycie zasob\u00f3w oraz ich tworzenie na podstawie przestrzeni nazw. W przestrzeni nazw modu\u0142 pod lub kontener mo\u017ce zu\u017cywa\u0107 tyle mocy CPU i pami\u0119ci, ile zosta\u0142o okre\u015blone przez kwot\u0119 zasob\u00f3w przestrzeni nazw. Istnieje jednak obawa, \u017ce jeden pod lub kontener mo\u017ce zmonopolizowa\u0107 wszystkie dost\u0119pne zasoby. Aby zapobiec takiej sytuacji, stosuje si\u0119 zakres limit\u00f3w Limit Range - polityk\u0119 ograniczaj\u0105c\u0105 przydzia\u0142 zasob\u00f3w (dla pod\u00f3w lub kontener\u00f3w) w przestrzeni nazw.<\/p>\n

Zakres limit\u00f3w zapewnia ograniczenia, kt\u00f3re mog\u0105:<\/p>\n