Три нива на автоматично мащабиране в Kubernetes: как да ги използваме ефективно

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

Статията Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler и Vertical Pod Autoscaler преведе екип, който внедри автоматичното мащабиране в Kubernetes aaS от Mail.ru.

Защо е важно да помислите за мащабиране

Kubernetes — инструмент за управление на ресурсите и оркестрация. Разбира се, приятно е да се работи с страхотни функции за разгръщане, мониторинг и управление на подовете (модул pod — група от контейнери, които се стартират в отговор на заявка).

Обаче, трябва да се помисли и за следните въпроси:

1. Как да мащабираме модулите и приложенията?
2. Как да поддържаме контейнерите в работно и ефективно състояние?
3. Как да реагираме на постоянните промени в кода и натоварванията от потребителите?

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

Нива на автоматично мащабиране в Kubernetes

Ефективното автоматично мащабиране изисква координация между два уровня:

1. Нивото на pod-ове, включващо хоризонтално (Horizontal Pod Autoscaler, HPA) и вертикално автоматично мащабиране (Vertical Pod Autoscaler, VPA). Това е мащабиране на наличните ресурси за вашите контейнери.
2. Нивото на клъстера, което се управлява от системата за автоматично мащабиране на клъстера (Cluster Autoscaler, CA), увеличава или намалява броя на възлите в клъстера.

Модулът за хоризонтално автоматично мащабиране (HPA)

Както подсказва името, HPA мащабира броя на репликите на pod-овете. Като тригери за промяна на броя на репликите, повечето девопс специалисти използват натоварването на процесора и паметта. Въпреки това, системата може да се мащабира въз основа на потребителски метрики,съчетания на външни метрики. или дори Високонадеждната схема на работа на HPA:.

Високоуровнева схема на работа HPA:

1. HPA непрекъснато проверява стойностите на метриките, зададени при инсталацията, с подразбираем интервал от 30 секунди.
2. HPA се опитва да увеличи броя на модулите, ако е достигната зададената граница.
3. HPA актуализира броя на репликите вътре в контролера на разгръщане/репликация.
4. Контролерът на разгръщане/репликация след това разгръща всичките необходими допълнителни модули.

HPA стартира процеса на разгръщане на модулите при достигане на прагова стойност на метриките.

Когато използвате HPA, имайте предвид следното:

• Подразбираемият интервал на проверка на HPA е 30 секунди. Той се задава с флага horizontal-pod-autoscaler-sync-period в контролера на диспетчера.
• Подразбираемата относителна грешка е 10%.
• След последното увеличение на броя на модулите HPA очаква стабилизация на метриките в продължение на три минути. Този интервал се задава с флага horizontal-pod-autoscaler-upscale-delay.
• След последното намаление на броя на модулите HPA очаква стабилизация в продължение на пет минути. Този интервал се задава с флага horizontal-pod-autoscaler-downscale-delay.
• HPA работи най-добре с обекти на разгръщане, а не с контролери на репликация. Хоризонталното автоматично мащабиране е несъвместимо с последователното обновяване (rolling update), което манипулира директно контролерите на репликация. При разгръщането броят на репликите зависи директно от обектите на разгръщане.

Вертикалното автоматично мащабиране на pod-овете

Вертикалното автоматично мащабиране (VPA) предоставя повече (или по-малко) CPU време или памет за съществуващите pod-ове. Подходящо е за pod-ове с опазване на състоянието (stateful) или без, но основно е предназначено за stateful услуги. Въпреки това, можете да приложите VPA и за безсъстояниe модули, ако е необходимо автоматично да коригирате първоначално зададените ресурси.

VPA също така реагира на OOM (изчерпване на паметта) събития. За промяна на CPU времето и обема памет изисква перезапуск на pod-овете. При перезапуск VPA спазва бюджета за разпределение (pods distribution budget, PDB), за да осигури минимално необходимото количество модули.

Можете да зададете минимален и максимален обем ресурси за всеки модул. Например, можете да ограничите максималния размер на оперативната памет до 8 GB. Това е полезно, ако текущите възли не могат да предоставят повече от 8 GB памет на контейнера. Подробните спецификации и механизма на работа са описани в официалната вики страница на VPA.

Освен това, VPA предлага интересна функция за препоръки (VPA Recommender). Тя проследява използването на ресурсите и събитията OOM на всички модули, за да предложи нови стойности на паметта и процесорното време, на базата на интелигентен алгоритъм, вземащ предвид историческите метрики. Има и API интерфейс, който приема дескриптор на pod и предоставя предложените стойности на ресурсите.

Важно е да отбележим, че VPA Recommender не проследява "лимита" на ресурсите. Това може да доведе до ситуация, в която модулът монополизира ресурсите в рамките на възлите. Най-добре е да зададете ограничение на ниво пространство от имена, за да избегнете значителна консумация на памет или процесорно време.

Високо ниво схема на работа на VPA:

1. VPA непрекъснато проверява стойностите на метриките, зададени по време на инсталацията, с подразбиращ се интервал от 10 секунди.
2. Ако се достигне зададеният праг, VPA се опитва да промени зададеното количество ресурси.
3. VPA актуализира количеството ресурси в контролера за разгръщане/репликация.
4. При повторно стартиране на модулите, всички нови ресурси се прилагат към създадените инстанции.

VPA добавя необходимото количество ресурси.

Имайте предвид следните аспекти при използването на VPA:

• Мащабирането изисква задължително повторно стартиране на pod-а. Това е необходимо, за да се избягва нестабилна работа след направените промени. За надеждност модулите се рестартират и разпределят по възлите на базата на новите зададени ресурси.
• VPA и HPA в момента са несъвместими помежду си и не могат да работят на едни и същи pod-ове. Ако прилагате и двата механизма за мащабиране в един и същ клъстер, уверете се, че настройките им не позволяват активирането им на одни и същи обекти.
• VPA настройва заявките на контейнери за ресурси, основавайки се само на миналото и текущото им използване. Той не задава лимити за използването на ресурси. Могат да възникнат проблеми с неправилната работа на приложения, които започнат да използват все повече ресурси, което ще доведе до изключване на съответния pod от Kubernetes.
• VPA е все още на ранен етап на разработка. Бъдете готови, че в близко време системата може да претърпи някои промени. Можете да прочетете за известните ограничения и плановете за разработка. Така че в плановете е реализирана съвместна работа на VPA и HPA, както и разгръщане на модули със специфична политика за вертикално автоматично мащабиране за тях (например, специална етикета 'requires VPA').

Автоматично мащабиране на кластера Kubernetes

Автоматично мащабиране на кластера (Cluster Autoscaler, CA) променя броя на възлите в зависимост от броя на чакащите модули pod. Системата периодично проверява за наличието на чакащи модули — и увеличава размера на кластера, ако е необходимо повече ресурси и ако кластерът не надвишава зададените лимити. CA взаимодейства с доставчика на облачни услуги, запитвайки за допълнителни възли или освобождавайки неактивни. Първата обществено достъпна версия на CA беше представена в Kubernetes 1.8.

Високо ниво на схема на работа на CA:

1. CA проверява за наличието на модули в изчакване с подразбиращ се интервал от 10 секунди.
2. Ако един или повече модули са в изчакване поради недостатъчни налични ресурси в кластера за тяхното разпределение, той се опитва да подготви един или повече допълнителни възли.
3. Когато доставчикът на облачни услуги осигури необходимия възел, той се присъединява към кластера и е готов да обслужва модулите pod.
4. Kubernetes планиращият разпределя чакащите модули на новия възел. Ако след това все още остава някой модул в изчакване, процесът се повтаря — и нови възли се добавят в кластера.

Автоматично разпределение на възлите на клъстера в облака

Имайте предвид следното при използване на CA:

• CA гарантира, че всички модули в кластера имат място за стартиране, независимо от натоварването на процесора. Освен това той се опитва да гарантира, че в кластера няма ненужни възли.
• CA регистрира необходимостта от мащабиране приблизително след 30 секунди.
• След като възел стане ненужен, CA по подразбиране изчаква 10 минути, преди да мащабира системата.
• В системата за автоматично мащабиране съществува концепцията за разширители (expanders). Това са различни стратегии за избор на група възли, в която ще бъдат добавени нови.
• Отговорно прилагайте опцията cluster-autoscaler.kubernetes.io/safe-to-evict (true). Ако зададете много pod’ове или ако много от тях са разпределени по всички възли, в значителна степен ще загубите способността да намаляте мащаба на клъстера.
• Използвайте PodDisruptionBudgets, за да предотвратите изтриването на pod’ове, поради което част от вашето приложение може напълно да спре да работи.

Как системите за автоматично мащабиране в Kubernetes взаимодействат помежду си

За идеална хармония е необходимо да се приложи автоматично мащабиране както на ниво pod’ове (HPA/VPA), така и на ниво клъстер. Те сравнително лесно взаимодействат помежду си:

1. HPA или VPA обновяват репликите на pod’овете или ресурсите, определени за съществуващите pod’ове.
2. Ако за планирано мащабиране липсват възли, CA забелязва наличието на pod’ове в чакане.
3. CA разпределя нови възли.
4. Модулите се разпределят по новите възли.

Съвместна система за мащабиране на Kubernetes

Типични грешки в автоматичното мащабиране на Kubernetes

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

HPA и VPA зависят от метрики и някои исторически данни. Ако ресурсите са недостатъчни, модулите ще бъдат свити и няма да могат да генерират метрики. В този случай автоматичното мащабиране никога няма да се осъществи.

Самата операция по мащабиране е чувствителна към времето. Искаме модулите и клъстера да се мащабира бързо — преди потребителите да забележат проблеми и падания. Затова е необходимо да се вземе предвид средното време за мащабиране на pod’ове и клъстера.

Идеалният сценарий — 4 минути:

1. 30 секунди. Обновление на целевите метрики: 30−60 секунди.
2. 30 секунди. HPA проверява стойностите на метриките: 30 секунди.
3. По-малко от 2 секунди. Модулите pod са създадени и преминават в състояние на чакане: 1 секунда.
4. По-малко от 2 секунди. CA вижда ожидащите модули и изпраща заявки за подготовка на възлите: 1 секунда.
5. 3 минути. Облачният предоставчик разпределя възли. K8s чака, докато те станат готови: до 10 минути (зависи от няколко фактора).

Най-лошият (по-реалистичен) сценарий — 12 минути:

1. 30 секунди. Актуализиране на целевите метрики.
2. 30 секунди. HPA проверява стойностите на метриките.
3. По-малко от 2 секунди. Pod модулите се създават и преминават в изчаквателно състояние.
4. По-малко от 2 секунди. CA вижда изчакващите модули и изпраща заявки за подготовка на възлите.
5. 10 минути. Облачният предоставчик разпределя възли. K8s чака, докато те станат готови. Времето за изчакване зависи от няколко фактора, като забавянето на доставчика, забавянето на ОС, работата на помощните инструменти.

Не бъркайте механизмите за скалиране на облачните провайдери с нашата CA. Последната работи вътре в кластера Kubernetes, докато механизмът на облачния доставчик работи на база разпределението на възлите. Той не знае какво се случва с вашите pod’ове или приложението. Тези системи работят паралелно.

Как да управлявате скалирането в Kubernetes

1. Kubernetes е инструмент за управление на ресурси и оркестрация. Операциите по управление на pod’ове и ресурсите на кластерa са ключова стъпка в овладяването на Kubernetes.
2. Разберете логиката на скалируемостта на pod’овете, като вземете предвид HPA и VPA.
3. CA трябва да се използва, само ако добре разбирате нуждите на вашите pod’ове и контейнери.
4. За оптимално конфигуриране на кластера е необходимо да разберете как различните системи за скалиране работят заедно.
5. При оценка на времето за скалиране, имайте предвид най-лошите и най-добрите сценарии.

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