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

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

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

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

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

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

Все контейнери в 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 или контейнер може да консумира толкова изчислителна мощ и памет, колкото е зададено в ресурсната квота. Въпреки това, съществува опасение, че един pod или контейнер може да монополизира всички налични ресурси. За да се предотврати такава ситуация, се използва пределният диапазон limit Range - политика за ограничаване на разпределението на ресурси (за подове или контейнери) в пространството с имена.

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

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

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

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

В раздела по подразбиране 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 ще търси подове, които използват повече ресурси, отколкото са поискали. Така че, ако вашите контейнери нямат заявки, това означава, че по подразбиране те използват повече, отколкото са поискали, просто защото изобщо не са поискали нищо! Такива контейнери стават основни кандидати за спиране. Следващите кандидати са контейнерите, които са удовлетворили всичките си заявки, но все още са под максималния лимит.

Така че, ако 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 Е5-2650 v4 на стойност 9000 евро за копейки?

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