Най-добри практики за Kubernetes. Настройка на заявки и лимити на ресурсите

Най-добри практики за Kubernetes. Създаване на малки контейнери
Най-добри практики за Kubernetes. Организиране на Kubernetes с пространство за имена
Най-добри практики за Kubernetes. Проверка на жизненоспособността на Kubernetes с тестове за готовност и жизненост

За всеки ресурс на Kubernetes има възможност за настройка на два типа изисквания — Requests и Limits. Първото описва минималните изисквания за наличието на свободни ресурси на възела, необходими за стартиране на контейнер или под, а второто строго ограничава ресурсите, достъпни за контейнера.

Когато Kubernetes планира pod, е много важно контейнерите да имат достатъчно ресурси за нормална работа. Ако планирате да разположите голямо приложение на възел с ограничени ресурси, е напълно възможно то да не работи поради недостиг на памет или недостатъчна процесорна мощ. В тази статия ще разгледаме как можем да решим проблемите с недостатъчните компютърни ресурси чрез заявки за ресурси и ограничения.

Заявките Requests и ограниченията Limits са механизми, които Kubernetes използва за управление на ресурси като процесор и памет. Requests са това, при което контейнерът гарантиирано получава запитания ресурс. Ако контейнерът поиска ресурс, Kubernetes ще го планира само на този възел, който може да го предостави. Ограниченията Limits контролират, че ресурсите, поискани от контейнера, никога не надвишават определена стойност.

Контейнерът може да увеличава изчислителните си мощности само до определен праг, след което ще бъде ограничен. Нека видим как това работи. И така, съществуват два типа ресурси — процесор и памет. Планиращият на Kubernetes използва данни за тези ресурси, за да определи къде да стартира вашите подове. Типичната спецификация на ресурсите за pod изглежда така.

Всеки контейнер в pod може да задава свои собствени заявки и ограничения, като всички те са адитивни. Ресурсите на процесора се определят в миликори. Ако вашият контейнер за работа изисква две цели ядра, задавате стойност 2000m. Ако контейнерът се нуждае само от 1/4 ядро, стойността ще е 250m. Имайте предвид, че ако зададете стойност на ресурсите на процесора, която надвишава броя на ядрата на най-голямата възлова система, вашият pod няма да бъде планиран за стартиране. Подобна ситуация ще се случи, ако имате pod, който изисква четири ядра, а клъстерът Kubernetes съдържа само две основни виртуални машини.

Освен ако вашето приложение не е разработено специално, за да се възползва от предимствата на многото ядра (като примери за такива програми са сложните научни изчисления и операциите с бази данни), най-добрата практика е да зададете CPU Requests на 1 или по-малко, последвано от стартиране на по-голям брой реплики за мащабируемост. Такова решение ще придаде на системата по-голяма гъвкавост и надеждност.

Когато става въпрос за ограничения на процесора, всичко става по-интересно, тъй като той се счита за компресируем ресурс. Ако вашето приложение започне да достигне лимита на процесорната мощност, Kubernetes ще започне да забавя вашия контейнер, използвайки CPU Throttling — намаляване на честотата на процесора. Това означава, че процесорът ще бъде изкуствено ограничен, което води до потенциално по-лоша производителност на приложението, но процесът няма да бъде спиран или прекратяван.

Ресурсите на паметта се определят в байтове. Обикновено стойността в настройките се измерва в мебибайтове Mib, но можете да зададете всяка стойност, от байтове до петабайтове. Тук се случва същата ситуация, както с CPU — ако зададете заявка за количество памет, което надвишава наличната памет на вашите възли, изпълнението на този pod няма да бъде планирано. Но за разлика от ресурсите на процесора, паметта не може да бъде компресирана, тъй като няма начин да се ограничи нейното използване. Следователно, изпълнението на контейнера ще бъде спряно, веднага щом надхвърли предоставената му памет.

Важно е да запомните, че не можете да настроите заявки, които надвишават размера на ресурсите, които вашите възли могат да предоставят. Характеристиките на общите ресурси за виртуалните машини GKE можете да намерите на връзките, публикувани под това видео.

В идеалния свят настройките на контейнера по подразбиране биха били напълно достатъчни, за да протичат работните процеси гладко. Но реалният свят е различен, хората могат лесно да забравят да настроят използването на ресурси или хакерите могат да установят заявки и ограничения, които надвишават реалните възможности на инфраструктурата. За да се предотвратят подобни сценарии, можете да настроите квоти за ресурси ResourceQuota и диапазони на ограничения LimitRange.

След създаването на именни пространства, те могат да бъдат заключени с квоти. Например, ако имате именни пространства prod и dev, можете да използвате модел, при който няма квоти за продукция, а квотите за разработка са много строги. Това позволява на prod, в случай на рязък скок на трафика, да поеме всички налични ресурси, напълно блокирайки dev.

Квотата за ресурси може да изглежда по следния начин. В този пример имаме 4 секции – това са 4 реда код.

Нека разгледаме всеки от тях. Requests.cpu — това е максималният брой комбинирани заявки за процесорна мощност, които могат да постъпват от всички контейнери в именното пространство. В този пример можете да имате 50 контейнера с заявки от 10m, пет контейнера с заявки от 100m или просто един контейнер с заявка от 500m. Докато общият брой requests.cpu за това именно пространство е по-малко от 500m, всичко ще бъде наред.

Запрашаваната памет requests.memory — това е максималната величина на комбинираните заявки за памет, която могат да имат всички контейнери в именното пространство. Както и в предишния случай, можете да имате 50 контейнера по 2 MiB, пет контейнера по 20 MiB или един контейнер с 100 MiB, стига общото количество заявена памет в именното пространство да е под 100 мебибайта.

Limits.cpu — това е максималната комбинирана стойност на процесорната мощност, която могат да използват всички контейнери в именното пространство. Можете да го считате за предел на заявките за процесорна мощност.

Най-накрая, limits.memory – максималният обем обща памет, който могат да използват всички контейнери в пространството на имената. Това е ограничение на общите запитвания за памет.
Така че, по подразбиране контейнерите в кластера Kubernetes работят с неограничени изчислителни ресурси. Чрез ресурсни квоти, администраторите на кластера могат да ограничат потреблението на ресурси и тяхното създаване на базата на пространството на имената. В пространството на имената модулът pod или контейнер може да консумира толкова CPU и памет, колкото е определено от ресурсната квота на пространствата на имената. Въпреки това, има опасение, че един pod или контейнер може да монополизира всички налични ресурси. За да се предотврати подобна ситуация, се използва пределен обхват limit Range – политика за ограничаване на разпределението на ресурси (за pods или контейнери) в пространството на имената.

Пределният обхват предоставя ограничения, които могат да:

• осигуряват минимално и максимално използване на изчислителни ресурси за всеки модул или контейнер в пространството на имената;
• задължително да прилагат минималното и максимално запитване за хранилище Storage Request за всеки PersistentVolumeClaim в пространството на имената;
• задължително да определят съотношение между запитването Request и ограничението Limit за ресурса в пространството на имената;
• да задават Requests/Limits по подразбиране за изчислителни ресурси в пространството на имената и автоматично да ги въвеждат в контейнерите по време на изпълнение.

Така можете да създадете пределен обхват в своето пространство на имената. За разлика от квотата, която обхваща всичко в пространството на имената, Limit Range се използва за отделни контейнери. Това може да предотврати създаването на изключително малки или, от друга страна, гигантски контейнери вътре в пространството на имената. Пределният обхват Limit Range може да изглежда така.

Както и в предишния случай, тук могат да се откроят 4 раздела. Нека разгледаме всеки от тях.
В раздела default се задават ограничения по подразбиране за контейнера в pod. Ако зададете тези стойности в пределния обхват, то всички контейнери, за които тези стойности не са били изрично зададени, ще бъдат ръководени от стойностите по подразбиране.

В раздела за заявка по подразбиране defaultRequest са настроени заявки по подразбиране за контейнера в пода. Отново, ако зададете тези стойности в пределите, всички контейнери, за които тези параметри не са явно зададени, ще използват тези стойности по подразбиране.

В раздел max са посочени максималните ограничения, които могат да бъдат зададени за контейнера в пода. Стойностите в раздела default и ограниченията за контейнера не могат да бъдат зададени над този предел. Важно е да се отбележи, че ако е зададена стойност max, а разделът default липсва, максималната стойност става стойността по подразбиране.

В раздел min са посочени минималните заявки, които могат да бъдат зададени за контейнера в пода. В същото време стойностите в раздела default и заявките за контейнера не могат да бъдат зададени под този предел.

Отново, важно е да се отбележи, че ако тази стойност е зададена, а стойността default не е, минималната стойност става заявка по подразбиране.

В крайна сметка тези ресурси се използват от планировщика на Kubernetes за изпълнение на вашите работни натоварвания. За да можете правилно да настроите контейнерите си, е много важно да разберете как работи това. Да предположим, че искате да стартирате няколко модула в кластера си. Предполага се, че спецификациите на пода са валидни, в разписанието на Kubernetes ще се използва циклично балансиране за избор на възел за изпълнение на работното натоварване.

Kubernetes ще провери дали узел Node 1 има достатъчно ресурси за изпълнение на заявките на контейнерите от пода, и ако не, ще премине към следващия узел. Ако нито един от узлите в системата не може да отговори на заявките, подовете ще преминат в състояние на изчакване Pending state. С функции като автоматично мащабиране на узлите в Google Kubernetes engine, GKE може автоматично да идентифицира състоянието на изчакване и да създаде допълнителни узли.

Ако впоследствие възникне излишен капацитет на узлите, функцията за автоматично мащабиране ще намали тяхното количество, за да спести пари. Ето защо Kubernetes планира подовете на базата на заявки. Въпреки това, лимитът може да е по-висок от заявките и в някои случаи узелът може действително да изчерпи ресурсите. Ние наричаме това състояние overcommitment state.

Както вече споменах, когато става дума за процесора, Kubernetes ще започне да ограничава подовете. Всеки pod ще получи толкова, колкото е поискал, но ако не достигне лимита, ще започне да се прилага тротлинг.

Що се отнася до ресурсите на паметта, Kubernetes е принуден да взема решения за това кои подове да изтрие и кои да запази, докато не освободите системните ресурси, в противен случай цялата система ще се срине.

Нека си представим сценарий, в който имате машина, изчерпала лимита на паметта – как ще реагира Kubernetes?

Kubernetes ще търси подове, които използват повече ресурси, отколкото са поискали. Така че, ако вашите контейнери изобщо нямат заявки Requests, това означава, че по подразбиране използват повече, отколкото са искали, просто защото не са поискали нищо! Такива контейнери стават основни кандидати за изключване. Следващите кандидати са контейнери, които са удовлетворили всичките си заявки, но все още са под максималния лимит.

Ако Kubernetes открие няколко пода, които надвишават параметрите на своите заявки, ще ги подреди по приоритет и след това ще изтрие най-нископриоритетните модули. Ако всичките модули имат еднакъв приоритет, Kubernetes ще спре работата на тези подове, които надвишават своите заявки повече от останалите подове.

В много редки случаи Kubernetes може да прекъсне работата на подове, които все още са в рамките на своите заявки. Това може да се случи, когато такива критични компоненти на системата, като Kubelet агент или Docker, започнат да потребяват повече ресурси, отколкото са им резервирани.
Така че, на началните етапи на работа на малки компании, Kubernetes клъстър може да работи отлично без задаване на заявки за ресурси и ограничения, но с увеличаването на вашите екипи и проекти рискувате да се сблъскате с проблеми в тази област. Добавянето на заявки и ограничения в вашите модули и имена на пространства изисква много малко допълнителни усилия и може да ви спести много неприятности.

Най-добри практики на Kubernetes. Коректно изключване Terminate

Малко реклама 🙂

Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, облачни VPS за разработчици от $4.99, уникален аналог на entry-level сървъри, който е създаден от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да делите правилно сървър? (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB от 199 $ в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това Как да построим инфраструктура от корпоративен клас с помощта на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за малко пари?

Източник: habr.com