Для поўнага засваення Kubernetes трэба ведаць розныя спосабы маштабавання кластарных рэсурсаў: па , гэта адна з галоўных задач Kubernetes. Мы падрыхтавалі высокаўзроўневы агляд механізмаў гарызантальнага і вертыкальнага аўтамаштабавання і змены памеру кластараў, а таксама рэкамендацыі, як іх эфектыўна выкарыстоўваць.
Артыкул перавяла каманда, якая рэалізавала аўтамаштабаванне ў .
Чаму важна падумаць аб маштабаванні
- Інструмент для кіравання рэсурсамі і аркестроўкі. Вядома, нядрэнна павазіцца з класнымі функцыямі разгортвання, маніторынгу і кіравання подами (модуль pod - група кантэйнераў, якія запускаюцца ў адказ на запыт).
Аднак трэба падумаць і пра такія пытанні:
- Як маштабаваць модулі і прыкладанні?
- Як падтрымліваць кантэйнеры ў працоўным і эфектыўным стане?
- Як рэагаваць на пастаянныя змены ў кодзе і працоўных нагрузках ад карыстальнікаў?
Настройка кластараў Kubernetes для балансавання рэсурсаў і прадукцыйнасці можа быць складанай задачай, яна патрабуе экспертных ведаў аб унутранай працы Kubernetes. Рабочая нагрузка на ваша прыкладанне або сэрвісы можа вагацца на працягу дня ці нават адной гадзіны, таму балансаванне лепш прадстаўляць як бесперапынны працэс.
Узроўні аўтамаштабавання Kubernetes
Эфектыўнае аўтамаштабаванне патрабуе каардынацыі паміж двума ўзроўнямі:
- Узровень pod'ов, улучальны гарызантальнае (Horizontal Pod Autoscaler, HPA) і вертыкальнае аўтамаштабаванне (Vertical Pod Autoscaler, VPA). Гэта маштабаванне наяўных рэсурсаў для вашых кантэйнераў.
- Узровень кластара, якім кіруе сістэма аўтамаштабавання кластара (Cluster Autoscaler, CA), яна павялічвае або памяншае колькасць вузлоў ўнутры кластара.
Модуль гарызантальнага аўтамаштабавання (HPA)
Як след з назову, HPA маштабуе колькасць рэплік pod'ов. У якасці трыгераў для змены колькасці рэплік большасць дэвопсаў выкарыстоўваюць нагрузку на працэсар і памяць. Аднак можна маштабаваць сістэму на аснове , іх ці нават .
Высокаўзроўневая схема працы HPA:
- HPA бесперапынна правярае значэнні метрык, паказаныя пры ўсталёўцы, з інтэрвалам па змаўчанні 30 секунд.
- HPA спрабуе павялічыць колькасць модуляў, калі дасягнуты зададзены парог.
- HPA абнаўляе колькасць рэплік ўнутры кантролера разгортвання/рэплікацыі.
- Кантролер разгортвання/рэплікацыі затым разгортвае ўсе неабходныя дадатковыя модулі.
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, нядосыць памяці). Для змены працэсарнага часу і аб'ёму памяці патрабуецца перазапуск пад'аў. Пры перазапуску VPA выконвае бюджэт размеркавання (), каб гарантаваць мінімальна неабходную колькасць модуляў.
Вы можаце ўсталяваць мінімальны і максімальны аб'ём рэсурсаў для кожнага модуля. Так, можна абмежаваць максімальны аб'ём вылучаемай памяці мяжой у 8 ГБ. Гэта карысна, калі бягучыя вузлы сапраўды не могуць вылучыць больш за 8 ГБ памяці на кантэйнер. Падрабязныя спецыфікацыі і механізм працы апісаны ў .
Акрамя таго, у VPA ёсць цікавая функцыя рэкамендацый (VPA Recommender). Яна адсочвае выкарыстанне рэсурсаў і падзеі OOM ўсіх модуляў, каб прапанаваць новыя значэнні памяці і працэсарнага часу на аснове інтэлектуальнага алгарытму з улікам гістарычных метрык. Таксама ёсць API-інтэрфейс, які прымае дэскрыптар pod і аддае прапанаваныя значэнні рэсурсаў.
Варта адзначыць, што VPA Recommender не адсочвае "ліміт" рэсурсаў. Гэта можа прывесці да таго, што модуль манапалізуе рэсурсы ўсярэдзіне вузлоў. Лепш усталяваць лімітавае значэнне на ўзроўні прасторы імёнаў, каб пазбегнуць велізарнага выдатку памяці ці працэсарнага часу.
Высокаўзроўневая схема працы VPA:
- VPA бесперапынна правярае значэнні метрык, паказаныя пры ўсталёўцы, з інтэрвалам па змаўчанні 10 секунд.
- Калі дасягнуты зададзены парог, VPA спрабуе змяніць выдзеленую колькасць рэсурсаў.
- VPA абнаўляе колькасць рэсурсаў унутры кантролера разгортвання/рэплікацыі.
- Пры перазапуску модуляў усе новыя рэсурсы прымяняюцца да створаных інстанс.
VPA дадае неабходную колькасць рэсурсаў
Улічвайце наступныя моманты пры выкарыстанні VPA:
- Маштабаванне патрабуе абавязковага перазапуску pod'а. Гэта трэба, каб пазбегнуць нестабільнай працы пасля занясення змен. Для надзейнасці модулі перазапускаюць і размяркоўваюць па вузлах на аснове новых выдзеленых рэсурсаў.
- VPA і HPA пакуль несумяшчальныя сябар з сябрам і не могуць працаваць на адных і тых жа pod'ах. Калі вы ўжываеце ў адным кластары абодва механізма маштабавання, пераканаецеся, што налады не дазволяць ім актывавацца на адных і тых жа аб'ектах.
- VPA настройвае запыты кантэйнераў на рэсурсы, зыходзячы толькі з мінулага і бягучага іх выкарыстання. Ён не ўстанаўлівае ліміты выкарыстання рэсурсаў. Могуць узнікнуць праблемы з некарэктнай працай прыкладанняў, якія пачнуць захопліваць усё больш рэсурсаў, гэта прывядзе да таго, што Kubernetes выключыць дадзены pod.
- VPA пакуль на ранняй стадыі распрацоўкі. Будзьце гатовыя, што ў бліжэйшы час сістэма можа зведаць некаторыя змены. Можна пачытаць пра и . Так, у планах рэалізаваць сумесную працу VPA і HPA, а таксама разгортванне модуляў разам з палітыкай вертыкальнага аўтамаштабавання для іх (напрыклад, адмысловая пазнака 'requires VPA').
Аўтамаштабаванне кластара Kubernetes
Аўтамаштабаванне кластара (Cluster Autoscaler, CA) змяняе колькасць вузлоў, зыходзячы з колькасці якія чакаюць модуляў pod. Сістэма перыядычна правярае наяўнасць якія чакаюць модуляў - і павялічвае памер кластара, калі патрабуецца больш рэсурсаў і калі кластар не выходзіць за межы ўсталяваных лімітаў. CA ўзаемадзейнічае з пастаўшчыком хмарных паслуг, запытвае ў яго дадатковыя вузлы або вызваляе бяздзейныя. Першая агульнадаступная версія CA была прадстаўлена ў Kubernetes 1.8.
Высокаўзроўневая схема працы СA:
- CA правярае наяўнасць модуляў у стане чакання з інтэрвалам па змаўчанні 10 секунд.
- Калі адзін ці некалькі модуляў знаходзяцца ў стане чакання з-за таго, што ў кластары недастаткова даступных рэсурсаў для іх размеркавання, ён спрабуе падрыхтаваць адзін ці некалькі дадатковых вузлоў.
- Калі пастаўшчык хмарных паслуг вылучае неабходны вузел, той далучаецца да кластара і гатовы абслугоўваць модулі pod.
- Планавальнік Kubernetes размяркоўвае якія чакаюць модулі на новы вузел. Калі пасля гэтага некаторыя модулі ўсё роўна застаюцца ў стане чакання, працэс паўтараецца – і ў кластар дадаюцца новыя вузлы.
Аўтаматычнае выдзяленне вузлоў кластара ў воблаку
Улічвайце наступнае пры выкарыстанні СA:
- CA гарантуе, што ва ўсіх модуляў у кластары ёсць месца для запуску, незалежна ад узроўня нагрузкі на працэсар. Акрамя таго, ён спрабуе гарантаваць, што ў кластары няма непатрэбных вузлоў.
- CA рэгіструе неабходнасць маштабавання прыкладна праз 30 секунд.
- Пасля таго як вузел становіцца непатрэбным, CA па змаўчанні чакае 10 хвілін, перш чым маштабаваць сістэму.
- У сістэме аўтамаштабавання ёсць паняцце пашыральнікаў (expanders). Гэта розныя стратэгіі для выбару групы вузлоў, у якую будуць дададзены новыя.
- Адказна прымяняйце опцыю cluster-autoscaler.kubernetes.io/safe-to-evict (true). Калі ўсталяваць шмат pod'аў ці калі многія з іх будуць раскіданыя па ўсіх вузлах, вы ў значнай ступені страціце магчымасць памяншаць маштаб кластара.
- выкарыстоўвайце , Каб прадухіліць выдаленне pod'ов, з-за чаго частка вашага дадатку можа цалкам выйсці з ладу.
Як сістэмы аўтамаштабавання Kubernetes ўзаемадзейнічаюць паміж сабой
Для ідэальнай гармоніі варта ўжыць аўтамаштабаванне і на ўзроўні pod'ов (HPA/VPA), і на ўзроўні кластара. Яны адносна проста ўзаемадзейнічаюць паміж сабой:
- HPA або VPA абнаўляюць рэплікі pod'аў ці рэсурсы, вылучаныя для існуючых pod'аў.
- Калі для запланаванага маштабавання бракуе вузлоў, CA заўважае наяўнасць pod'ов у стане чакання.
- CA вылучае новыя вузлы.
- Модулі размяркоўваюцца па новых вузлах.
Сумесная сістэма сістэм маштабавання Kubernetes
Тыповыя памылкі ў аўтамаштабаванні Kubernetes
Існуе некалькі тыповых праблем, з якімі дэвапсы сутыкаюцца, калі спрабуюць прымяніць аўтамаштабаванне.
HPA і VPA залежаць ад метрык і некаторых гістарычных дадзеных. Калі выдзелена недастаткова рэсурсаў, модулі будуць згорнуты і не змогуць генераваць метрыкі. У гэтым выпадку аўтамаштабаванне ніколі не адбудзецца.
Сама аперацыя маштабавання адчувальная да часу. Нам жадаецца, каб модулі і кластар маштабаваліся хутка - да таго, як карыстачы заўважаць нейкія праблемы і збоі. Таму варта ўлічваць сярэдні час маштабавання pod'ов і кластара.
Ідэальны сцэнар - 4 хвіліны:
- 30 секунд. Абнаўленне мэтавых метрык: 30-60 секунд.
- 30 секунд. HPA правярае значэння метрык: 30 секунд.
- Менш за 2 секунды. Модулі pod створаны і пераходзяць у стан чакання: 1 секунда.
- Менш за 2 секунды. CA бачыць якія чакаюць модулі і адпраўляе выклікі на падрыхтоўку вузлоў: 1 секунда.
- 3 хвіліны. Воблачнае правайдэр вылучае вузлы. K8s чакае, пакуль яны не будуць гатовыя: да 10 хвілін (залежыць ад некалькіх фактараў).
Горшы (больш рэалістычны) сцэнар - 12 хвілін:
- 30 секунд. Абнаўленне мэтавых метрык.
- 30 секунд. HPA правярае значэння метрык.
- Менш за 2 секунды. Модулі pod створаны і пераходзяць у стан чакання.
- Менш за 2 секунды. CA бачыць якія чакаюць модулі і адпраўляе выклікі на падрыхтоўку вузлоў.
- 10 хвілін. Воблачнае правайдэр вылучае вузлы. K8s чакае, пакуль яны не будуць гатовыя. Час чакання залежыць ад некалькіх фактараў, такіх як затрымка пастаўшчыка, затрымка АС, праца дапаможных прылад.
Не блытайце механізмы маштабавання хмарных правайдэраў з нашай CA. Апошняя працуе ўнутры кластара Kubernetes, у той час як механізм хмарнага правайдэра працуе на аснове размеркавання вузлоў. Ён не ведае, што адбываецца з вашымі pod'амі ці дадаткам. Гэтыя сістэмы працуюць паралельна.
Як кіраваць маштабаваннем у Kubernetes
- Kubernetes - інструмент кіравання рэсурсамі і аркестроўкі. Аперацыі па кіраванні pod'амі і рэсурсамі кластара - ключавая вяха ў засваенні Kubernetes.
- Засвойце логіку маштабаванасці pod'аў з улікам HPA і VPA.
- CA варта выкарыстоўваць, толькі калі вы добра разумееце патрэбнасці сваіх pod'аў і кантэйнераў.
- Для аптымальнай налады кластара трэба зразумець, як розныя сістэмы маштабавання працуюць разам.
- Пры ацэнцы часу маштабавання майце на ўвазе горшы і лепшы сцэнары.
Крыніца: habr.com