Куб-на-кубе, метакластэры, соты, размеркаванне рэсурсаў

Мал. 1. Экасістэма Kubernetes у воблаку Alibaba Cloud

З 2015 года Alibaba Cloud Container Service for Kubernetes (ACK) з'яўляецца адным з самых хуткарослых хмарных сэрвісаў у Alibaba Cloud. Ён абслугоўвае шматлікіх кліентаў, а таксама падтрымлівае ўнутраную інфраструктуру Alibaba і іншыя хмарныя сэрвісы кампаніі.

Як і ў аналагічных кантэйнерных сэрвісах ад хмарных правайдэраў сусветнага ўзроўню, нашы галоўныя прыярытэты - надзейнасць і даступнасць. Таму для дзясяткаў тысяч кластараў Kubernetes створана якая маштабуецца і глабальна даступная платформа.

У гэтым артыкуле мы падзелімся досведам кіравання вялікай колькасцю кластараў Kubernetes на хмарнай інфраструктуры, а таксама архітэктурай базавай платформы.

Уступленне

Kubernetes стаў фактычна стандартам для розных працоўных нагрузак у воблаку. Як паказана на мал. 1 уверсе, усё больш і больш прыкладанняў Alibaba Cloud цяпер працуюць у кластарах Kubernetes: гэта прыкладанні з захаваннем стану і без (stateful/stateless), а таксама менеджэры прыкладанняў. Упраўленне Kubernetes заўсёды ўяўляла цікавую і сур'ёзную тэму абмеркавання для інжынераў, якія займаюцца пабудовай і абслугоўваннем інфраструктуры. Калі гаворка ідзе аб хмарных правайдэрах, такіх як Alibaba Cloud, на першы план выходзіць праблема маштабавання. Як кіраваць кластарамі Kubernetes у такім маштабе? Мы ўжо распавядалі аб лепшых практыках кіравання вялізнымі кластарамі Kubernetes з 10 000 вузламі. Канешне, гэта цікавая праблема маштабавання. Але ёсць і іншая шкала маштабу: колькасць саміх кластараў.

Мы абмяркоўвалі гэтую тэму з многімі карыстальнікамі ACK. Большасць з іх аддаюць перавагу запускаць дзясяткі, калі не сотні, невялікіх або сярэдніх кластараў Kubernetes. На гэта ёсць разумныя прычыны: абмежаванне патэнцыйнай шкоды, падзел кластараў для розных каманд, стварэнне віртуальных кластараў для тэставання. Калі ACK імкнецца абслугоўваць глабальную аўдыторыю па такой мадэлі выкарыстання, то павінна надзейна і эфектыўна кіраваць вялікай колькасцю кластараў у больш за 20 рэгіёнах.

Мал. 2. Праблемы кіравання вялікай колькасцю кластараў Kubernetes

Якія асноўныя праблемы кіравання кластарамі ў такім маштабе? Як паказана на малюнку, неабходна разабрацца з чатырма праблемамі:

• Гетэрагеннасць

ACK павінен падтрымліваць розныя тыпы кластараў, у тым ліку стандартныя, бессерверныя, Edge, Windows і некаторыя іншыя. Розныя кластары патрабуюць розных параметраў, кампанентаў і мадэляў хостынгу. Некаторым кліентам патрэбна дапамога па наладзе для іх спецыфічных выпадкаў.

• Розны памер кластараў

Кластары адрозніваюцца па памеры: ад пары вузлоў з некалькімі pod'амі да дзясяткаў тысяч вузлоў з тысячамі pod'ов. Патрабаванні да рэсурсаў таксама моцна адрозніваюцца. Няправільнае размеркаванне рэсурсаў можа паўплываць на прадукцыйнасць ці нават прывесці да збою.

• Розныя версіі

Kubernetes вельмі хутка развіваецца. Новыя версіі выходзяць кожныя некалькі месяцаў. Кліенты заўсёды гатовы спрабаваць новыя функцыі. Такім чынам, яны хочуць размясціць тэставую нагрузку на новых версіях Kubernetes, а працоўную нагрузку - на стабільных. Каб задаволіць гэтае патрабаванне, ACK павінна стала пастаўляць кліентам новыя версіі Kubernetes, у той жа час падтрымліваючы стабільныя версіі.

• Адпаведнасць патрабаванням бяспекі

Кластары размеркаваны па розных рэгіёнах. Такім чынам, яны павінны адпавядаць розным патрабаванням да бяспекі і афіцыйным нормам рэгулявання. Напрыклад, кластар у Еўропе павінен адпавядаць GDPR, а ў фінансавага аблокі ў Кітаі павінны быць дадатковыя ўзроўні абароны. Гэтыя патрабаванні абавязковыя да выканання, ігнараваць іх непрымальна, паколькі гэта стварае вялізныя рызыкі для кліентаў хмарнай платформы.

Платформа ACK прызначана для вырашэння большасці вышэйпералічаных праблем. У цяперашні час яна надзейна і стабільна кіруе больш за 10 тыс. кластарамі Kubernetes па ўсім свеце. Паглядзім, як атрымалася гэтага дамагчыся, у тым ліку дзякуючы некалькім ключавым прынцыпам дызайну/архітэктуры.

Дызайн

Куб-на-кубе і соты

У адрозненні ад цэнтралізаванай іерархіі, сотавая архітэктура (cell-based architecture) звычайна выкарыстоўваецца для маштабавання платформы за межы аднаго дата-цэнтра ці для пашырэння вобласці аварыйнага ўзнаўлення.

Кожны рэгіён у воблаку Alibaba Cloud складаецца з некалькіх зон (AZ) і звычайна адпавядае канкрэтнаму дата-цэнтру. У вялікім рэгіёне (напрыклад, Хуанчжоу) часцяком сустракаюцца тысячы кліенцкіх кластараў Kubernetes пад кіраваннем ACK.

ACK кіруе гэтымі кластарамі Kubernetes з дапамогай самога Kubernetes, гэта значыць у нас працуе метакластар Kubernetes для кіравання кліенцкімі кластарамі Kubernetes. Такая архітэктура таксама называецца "куб-на-кубе" (kube-on-kube, KoK). Архітэктура KoK спрашчае кіраванне кліенцкімі кластарамі, паколькі разгортванне кластара становіцца простым і дэтэрмінаваным. Што яшчэ больш важна, мы можам паўторна выкарыстоўваць функцыі натыўнага Kubernetes. Напрыклад, кіраванне API-серверамі праз дэплой, выкарыстанне аператара etcd для кіравання некалькімі etcd. Такая рэкурсія заўсёды прыносіць асаблівае задавальненне.

У межах аднаго рэгіёна разгортваюцца некалькі метакластэраў Kubernetes, у залежнасці ад колькасці кліентаў. Гэтыя метакластэры мы называем сотамі (cell). Каб абараніцца ад збою цэлай зоны, ACK падтрымлівае мультыактыўныя разгортванні ў адным рэгіёне: метакластар размяркоўвае кампаненты майстра кліенцкіх кластараў Kubernetes па некалькіх зонам і запускае іх адначасова, гэта значыць у мультыактыўным рэжыме. Каб забяспечыць надзейнасць і эфектыўнасць майстра, ACK аптымізуе размяшчэнне кампанентаў і гарантуе, што сервер API і etcd стаяць блізка сябар да сябра.

Такая мадэль дазваляе эфектыўна, гнутка і надзейна кіраваць Kubernetes.

Планаванне рэсурсаў метакластара

Як мы ўжо згадвалі, колькасць метакластэраў у кожным рэгіёне залежыць ад колькасці кліентаў. Але ў які момант дадаць новы метакластар? Гэта тыповая праблема планавання рэсурсаў. Як правіла, прынята ствараць новы, калі існуючыя метакластэры вычарпалі ўсе свае рэсурсы.

Возьмем, напрыклад, сеткавыя рэсурсы. У архітэктуры KoK кампаненты Kubernetes з кліенцкіх кластараў дэплояцца як pod'ы ў метакластары. Мы выкарыстоўваем Terway (мал. 3) - высокапрадукцыйная ўбудова, распрацаваны Alibaba Cloud для кіравання кантэйнернай сеткай. Ён дае багаты набор палітык бяспекі і дазваляе падлучацца да віртуальных прыватных аблокаў (VPC) кліентаў праз інтэрфейс Alibaba Cloud Elastic Networking Interface (ENI). Каб эфектыўна размяркоўваць сеткавыя рэсурсы па вузлах, pod'ах і сэрвісах у метакластары, мы павінны старанна адсочваць іх выкарыстанне ўнутры метакластара з віртуальных прыватных аблокаў. Калі сеткавыя рэсурсы падыходзяць да канца, ствараецца новая сота.

Для вызначэння аптымальнай колькасці кліенцкіх кластараў у кожным метакластары мы таксама ўлічваем свае выдаткі, патрабаванні да шчыльнасці, квоту рэсурсаў, патрабаванні да надзейнасці і статыстычныя дадзеныя. Рашэнне аб стварэнні новага метакластара прымаецца на падставе ўсёй гэтай інфармацыі. Звярніце ўвагу, што маленькія кластары ў будучыні могуць моцна пашырыцца, таму выдатак рэсурсаў расце нават пры нязменнай колькасці кластараў. Звычайна мы пакідаем дастаткова вольнай прасторы для росту кожнага кластара.

Мал. 3. Сеткавая архітэктура Terway

Маштабаванне кампанентаў майстра ў кліенцкіх кластарах

У кампанентаў майстра розныя запатрабаванні ў рэсурсах. Яны залежаць ад ліку вузлоў і pod'аў у кластары, колькасці нестандартных кантролераў/аператараў, якія ўзаемадзейнічаюць з APIServer.

У ACK кожны кліенцкі кластар Kubernetes адрозніваецца па памеры і патрабаванням да асяроддзя выканання. Не існуе ўніверсальнай канфігурацыі для месцавання кампанентаў майстра. Калі мы памылкова ўсталюем нізкі ліміт рэсурсаў буйному кліенту, тое яго кластар не зладзіцца з нагрузкай. Калі ўсталяваць кансерватыўна высокі ліміт для ўсіх кластараў, то рэсурсы патрацяцца марна.

Каб знайсці тонкі кампраміс паміж надзейнасцю і коштам, ACK выкарыстоўвае сістэму тыпаў. У прыватнасці, мы вызначаем тры тыпу кластараў: малы, сярэдні і вялікі. У кожнага тыпу асобны профіль размеркавання рэсурсаў. Тып вызначаецца на аснове загрузкі кампанентаў майстра, колькасці вузлоў і іншых фактараў. Тып кластара можа змяняцца з цягам часу. ACK увесь час адсочвае гэтыя фактары і можа якая адпавядае выявай павялічваць/паніжаць тып. Пасля змены тыпу кластара размеркаванне рэсурсаў абнаўляецца аўтаматычна пры мінімальным умяшанні карыстача.

Мы працуем над паляпшэннем гэтай сістэмы ў частцы больш дробназярністага маштабавання і больш дакладнага абнаўлення тыпаў, каб гэтыя змены адбываліся больш плаўна і мелі больш эканамічнага сэнсу.

Мал. 4. Інтэлектуальнае шматступеннае пераключэнне тыпаў

Эвалюцыя кліенцкіх кластараў у маштабе

У папярэдніх раздзелах апісаны некаторыя аспекты кіравання вялікай колькасцю кластараў Kubernetes. Аднак ёсць яшчэ адна праблема, якую неабходна вырашыць: эвалюцыя кластараў.

Kubernetes - гэта "Linux" у свеце аблокаў. Ён бесперапынна абнаўляецца і становіцца больш модульным. Мы павінны ўвесь час пастаўляць нашым кліентам новыя версіі, выпраўляць уразлівасці і абнаўляць існуючыя кластары, а таксама кіраваць вялікай колькасцю звязаных кампанентаў (CSI, CNI, Device Plugin, Scheduler Plugin і многія іншыя).

У якасці прыкладу возьмем кіраванне кампанентамі Kubernetes. Для пачатку мы распрацавалі цэнтралізаваную сістэму рэгістрацыі і кіравання ўсімі гэтымі кампанентамі.

Мал. 5. Гнуткія і якія падключаюцца кампаненты

Перш чым рухацца далей, трэба ўпэўніцца ў паспяховасці абнаўлення. Дзеля гэтага мы распрацавалі сістэму праверкі працаздольнасці кампанентаў. Праверка выконваецца да і пасля абнаўлення.

Мал. 6. Папярэдняя праверка кампанентаў кластара

Для хуткага і надзейнага абнаўлення гэтых кампанентаў працуе сістэма бесперапыннага разгортвання з падтрымкай частковага прасоўвання (grayscale), паўзаў і іншых функцый. Стандартныя кантролеры Kubernetes нядосыць добра падыходзяць для такога выкарыстання. Таму для кіравання кампанентамі кластара мы распрацавалі набор спецыялізаваных кантролераў, уключаючы плягін і дапаможны модуль кіравання (sidecar management).

Напрыклад, кантролер BroadcastJob прызначаны для абнаўлення кампанентаў на кожнай працоўнай машыне ці праверкі вузлоў на кожнай машыне. Заданне Broadcast запускае pod на кожным вузле кластара, нібы DaemonSet. Аднак DaemonSet заўсёды падтрымлівае працяглую працу pod'a, у той час як BroadcastJob згортвае яго. Кантролер Broadcast таксама запускае pod'ы на ізноў далучаных вузлах і ініцыялізуе вузлы з неабходнымі кампанентамі. У чэрвені 2019 года мы адкрылі зыходны код рухавічка аўтаматызацыі OpenKruise, які самі выкарыстоўваем усярэдзіне кампаній.

Мал. 7. OpenKurise арганізуе выкананне задання Broadcast на ўсіх узпах

Каб дапамагчы кліентам у выбары правільных канфігурацый кластараў, мы таксама прадстаўляем набор наканаваных профіляў, уключаючы профілі Serverless, Edge, Windows і Bare Metal. Паколькі ландшафт пашыраецца, а патрэбы нашых кліентаў растуць, мы дадамо больш профіляў, каб спрасціць стомны працэс наладкі.

Мал. 8. Прасунутыя і гнуткія профілі кластараў для розных сцэнарыяў

Глабальная назіральнасць па дата-цэнтрах

Як паказана ніжэй на мал. 9, хмарная служба Alibaba Cloud Container разгорнута ў дваццаці рэгіёнах свету. Улічваючы такі маштаб, адна з ключавых задач ACK заключаецца ў тым, каб лёгка адсочваць стан запушчаных кластараў: калі кліенцкі кластар сутыкнецца з праблемай, мы зможам хутка адрэагаваць на сітуацыю. Іншымі словамі, трэба прыдумаць рашэнне, якое дазволіць эфектыўна і бяспечна збіраць статыстыку ў рэальным часе з кліенцкіх кластараў ва ўсіх рэгіёнах - і візуальна прадстаўляць вынікі.

Мал. 9. Глабальнае разгортванне службы Alibaba Cloud Container у дваццаці рэгіёнах

Як і ў шматлікіх сістэмах маніторынгу Kubernetes, у нас у якасці асноўнай прылады працуе Prometheus. Для кожнага метакластара агенты Prometheus збіраюць наступныя паказчыкі:

• Метрыкі АС, такія як рэсурсы вузла (працэсар, памяць, дыск і т. д.) і прапускная здольнасць сеткі.
• Метрыкі для сістэмы кіравання метакластарамі і кліенцкімі кластарамі, такія як kube-apiserver, kube-controller-manager і kube-scheduler.
• Метрыкі ад kubernetes-state-metrics і cadvisor.
• Метрыкі etcd, такія як час запісу на дыск, памер БД, прапускная здольнасць сувязей паміж вузламі і т. д.

Збор глабальнай статыстыкі вядзецца па тыповай шматслойнай мадэлі агрэгацыі. Дадзеныя маніторынгу з кожнага метакластара спачатку агрэгуюцца ў кожным рэгіёне, а затым адпраўляюцца на цэнтральны сервер, які паказвае агульную карціну. Усё працуе праз механізм федэрацыі. Сервер Prometheus у кожным дата-цэнтры збірае метрыкі гэтага дата-цэнтра, а цэнтральны сервер Prometheus адказвае за агрэгаванне дадзеных маніторынгу. AlertManager падключаецца да цэнтральнага Prometheus і ў выпадку неабходнасці рассылае абвесткі па DingTalk, электроннай пошце, SMS і г. д. Візуалізацыя - з дапамогай Grafana.

На малюнку 10 сістэма маніторынгу можа быць падзелена на тры ўзроўні:

• Гранічны ўзровень

Самы далёкі ад цэнтра пласт. Гранічны сервер Prometheus працуе ў кожным метакластары, збіраючы метрыкі мета-і кліенцкіх кластараў у межах аднаго сеткавага дамена.

• Каскадны ўзровень

Функцыя каскаднага пласта Prometheus заключаецца ў зборы даных маніторынгу з некалькіх рэгіёнаў. Гэтыя серверы працуюць на ўзроўні буйнейшых геаграфічных адзінак, такіх як Кітай, Азія, Еўропа і Амерыка. Па меры росту кластараў рэгіён ён можа быць падзелены, і тады сервер Prometheus каскаднага ўзроўню з'явіцца ў кожным новым вялікім рэгіёне. З такой стратэгіяй можна плаўна маштабавацца па меры неабходнасці.

• Цэнтральны ўзровень

Цэнтральны сервер Prometheus падлучаецца да ўсіх каскадных сервераў і выконвае канчатковую агрэгацыю дадзеных. Для надзейнасці ў розных зонах паднятыя два цэнтральныя інстансы Prometheus, падлучаныя да адных і тых жа каскадных сервераў.

Мал. 10. Глабальная шматузроўневая архітэктура маніторынгу на базе механізма федэрацыі Prometheus

Рэзюмэ

Хмарныя рашэнні на аснове Kubernetes працягваюць трансфармаваць нашу індустрыю. Кантэйнер-сэрвіс Alibaba Cloud забяспечвае абаронены, надзейны і высокапрадукцыйны хостынг - гэта адзін з лепшых хмарных хостынгаў Kubernetes. Каманда Alibaba Cloud цвёрда верыць у прынцыпы Open Source і апенсорснай супольнасці. Мы абавязкова працягнем дзяліцца сваімі ведамі ў галіне эксплуатацыі і кіравання хмарнымі тэхналогіямі.

Крыніца: habr.com