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

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

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

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

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

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

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

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

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

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

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

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

Както подсказва името, 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) предоставя повече (или по-малко) процесорно време или памет на съществуващите pod'ове. Подходящо е за pod'ове с запазено състояние (stateful) или без него (stateless), но основно е предназначено за stateful услуги. Въпреки това, можете да приложите VPA и за модули без запазено състояние, ако е необходимо автоматично да се коригира обемът на първоначално предоставените ресурси.

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

Можете да зададете минимален и максимален обем ресурси за всеки модул. Например, можете да ограничите максималния обем на разпределената памет до 8 ГБ. Това е полезно, когато текущите възли не могат да разпределят повече от 8 ГБ памет на контейнер. Подробните спецификации и механизмите на работа са описани в официалната wiki на 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 настройва запитвания на ресурси на контейнери, основавайки се единствено на минало и текущо им използване. Той не задава лимити за използване на ресурси. Могат да възникнат проблеми с неправилното функциониране на приложенията, които започват да изискват все повече ресурси, което ще доведе до това, че Kubernetes ще изключи съответния pod.
• 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 секунди. Подмодулите са създадени и преминават в състояние на изчакване.
4. По-малко от 2 секунди. CA вижда очакващите модули и изпраща искания за подготвяне на възлите.
5. 10 минути. Облачният доставчик разпределя възли. K8s изчаква те да бъдат готови. Времето на изчакване зависи от няколко фактора, като закъснение на доставчика, закъснение на ОС, работата на спомагателните инструменти.

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

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

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

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