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

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

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

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

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

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

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

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

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

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

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

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

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

Една квота за ресурси може да изглежда така. В този пример има 4 секции - това са 4-те долни реда на кода.

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

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

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

И накрая, limits.memory е максималното количество споделена памет, която всички контейнери в пространството от имена могат да използват. Това е ограничението за общи заявки за памет.
Така че по подразбиране контейнерите в клъстер на Kubernetes работят с неограничени изчислителни ресурси. С квотите за ресурси администраторите на клъстери могат да ограничат потреблението на ресурси и създаването на ресурси въз основа на пространството от имена. В пространството от имена под или контейнер може да консумира толкова мощност на процесора и паметта, колкото е определено от квотата за ресурси на пространството от имена. Съществува обаче опасение, че една капсула или контейнер може да монополизира всички налични ресурси. За да се предотврати тази ситуация, се използва ограничението Range - политиката за ограничаване на разпределението на ресурси (за подове или контейнери) в пространството от имена.

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

• гарантира минимално и максимално използване на изчислителни ресурси за всеки модул или контейнер в пространството от имена;
• прилагане на минимална и максимална Starage Request за всеки PersistentVolumeClaim в пространството от имена;
• налага връзка между Заявка и Лимит за ресурс в пространство от имена;
• задайте заявки/ограничения по подразбиране за изчислителни ресурси в пространството от имена и автоматично ги инжектирайте в контейнери по време на изпълнение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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