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

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

статия Kubernetes Autoscaling 101: Автоматично мащабиране на клъстери, Хоризонтално автоматично мащабиране и Вертикално автоматично мащабиране на под преведе командата, която реализира автоматично мащабиране в Kubernetes aaS от Mail.ru.

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

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

Трябва обаче да помислите и върху следните въпроси:

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

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

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

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

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

Хоризонтален автоскалер (HPA)

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

Схема на високо ниво на работа на 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 работи най-добре с обекти за разполагане, а не с контролери за репликация. Хоризонталното автоматично мащабиране е несъвместимо с непрекъснатата актуализация, която директно манипулира контролерите за репликация. При внедряването броят на репликите зависи пряко от обектите за внедряване.

Вертикално автоматично мащабиране на подс

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

VPA също реагира на OOM (изчерпана памет, липса на памет) събития. Необходимо е рестартиране на pods, за да промените процесорното време и паметта. Когато се рестартира, VPA зачита бюджета за разпределение (бюджет за разпределение на подс, ППБ), за да се гарантира минимално необходимия брой модули.

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

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

Струва си да се отбележи, че VPA Recommender не следи „лимита“ на ресурсите. Това може да накара модула да монополизира ресурсите в рамките на възлите. По-добре е да зададете ограничение на ниво пространство от имена, за да избегнете огромна употреба на памет или процесор.

VPA работен процес на високо ниво:

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

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

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

• Мащабирането изисква задължително рестартиране на групата. Това е необходимо, за да се избегне нестабилна работа след извършване на промени. За надеждност модулите се рестартират и разпределят между възлите въз основа на новите разпределени ресурси.
• VPA и HPA все още не са съвместими помежду си и не могат да работят на едни и същи модули. Ако използвате и двата механизма за мащабиране в един и същи клъстер, уверете се, че настройките не позволяват те да бъдат активирани на едни и същи обекти.
• VPA адаптира заявките за контейнери за ресурси въз основа само на минало и текущо използване на ресурси. Не поставя ограничения за използването на ресурси. Възможно е да има проблеми с неправилна работа на приложения, които ще започнат да отнемат все повече и повече ресурси, това ще накара Kubernetes да изключи този под.
• VPA все още е в ранен етап на развитие. Бъдете готови, че системата може да претърпи някои промени в близко бъдеще. Можете да прочетете за известни ограничения и планове за развитие. И така, плановете са да се приложи съвместната работа на VPA и HPA, както и внедряването на модули заедно с политика за вертикално автоматично мащабиране за тях (например специален етикет „изисква VPA“).

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

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

Работен процес на CA на високо ниво:

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

Автоматично осигуряване на клъстерни възли в облака

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

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

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

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

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

Споделена система за мащабиране Kubernetes

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

Има няколко често срещани проблема, с които devops се сблъсква, когато се опитва да използва автоматично мащабиране.

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

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

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

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

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

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

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

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

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

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