У канцы траўня правялі анлайн-мітап на тэму . Пагаварылі аб кантэйнерах, Kubernetes і аркестрацыі ў прынцыпе, аб крытэрах выбару інфраструктуры і многае іншае. Удзельнікі падзяліліся кейсамі з уласнай практыкі.
Удзельнікі:
- Яўген Патапаў, CEO "ITSumma". Больш за палову яго кліентаў альбо ўжо пераходзяць, альбо жадаюць перайсці на Kubernetes.
- Зміцер Сталяроў, CTO «Флант». Валодае 10+ гадамі досведу працы з кантэйнернымі сістэмамі.
- Дзяніс Рамчукоў (aka Eric Oldmann), COO argotech.io, ex-РАА ЕЭС. Паабяцаў расказаць пра кейс у «крывавым» энтэрпрайзе.
- Андрэй Фёдараўскі, CTO "News360.com"Пасля пакупкі кампаніі іншым гульцом адказвае за шэраг ML і AI праектаў і за інфраструктуру.
- Іван Круглоў, сістэмны інжынер, ex-Booking.com.Той самы чалавек, які сваімі рукамі зрабіў з Kubernetes вельмі шматлікае.
тэмы:
- Інсайты ўдзельнікаў пра кантэйнеры і аркестрацыю (Docker, Kubernetes і іншае); што спрабавалі на практыцы ці аналізавалі.
- Кейс: У кампаніі будуюць плян разьвіцьця інфраструктуры на гады. Як прымаецца рашэнне, будаваць (або пераводзіць бягучую) інфраструктуру на кантэйнерах і Кубер ці не?
- Праблемы ў свеце cloud-native, чаго не хапае, давайце пафантазіруем, што будзе заўтра.
Завязалася цікавая дыскусія, меркаванні ўдзельнікаў аказаліся настолькі рознымі і выклікалі столькі каментароў, што хочацца падзяліцца імі з вамі. Ёсць , А ніжэй - выцісканне з дыскусіі.
Kubernetes гэта ўжо стандарт ці выдатны маркетынг?
«Мы да яго (Kubernetes. - Рэд.) прыйшлі тады, калі пра яго яшчэ ніхто не ведаў. Мы да яго прыйшлі яшчэ тады, калі яго не было. Мы яго хацелі да гэтага». Дзмітрый Сталяроў
Фота з Reddit.com
Гадоў 5-10 таму існавала велізарная колькасць прылад, і не было адзінага стандарта. Кожныя паўгода з'яўляўся новы прадукт, а то і не адзін. Спачатку Vagrant, затым Salt, Chef, Puppet,… і ты кожныя паўгода перабудоўваеш сваю інфраструктуру. У цябе пяць адмінаў, якія ўвесь час занятыя тым, што перапісваюць канфігі» — узгадвае Андрэй Фёдараўскі. Ён лічыць, што Docker і Kubernetes "задушылі" астатніх. Docker стаў стандартам на працягу апошніх пяці гадоў, Kubernetes – у апошнія два гады. І гэта добра для індустрыі.
Дзмітрый Сталяроў і яго каманда любяць Кубер. Яны хацелі такі інструмент да таго, як ён з'явіўся, і прыйшлі да яго калі пра яго яшчэ ніхто не ведаў. На бягучы момант, з меркаванняў выгоды, яны не бяруць кліента, калі разумеюць, што не ўкарэняць у яго Kubernetes. Пры гэтым, па словах Зміцера, у кампаніі «мноства гіганцкіх success story па пераробцы жудаснага legacy».
Kubernetes – гэта не толькі кантэйнерная аркестрацыя, гэта сістэма кіравання канфігурацыяй з развітым API, кампанентам працы з сеткай, L3 балансаваннем і Ingress кантролерамі, якая дазваляе адносна лёгка кіраваць рэсурсамі, маштабавацца і абстрагавацца ад ніжніх пластоў інфраструктуры.
Нажаль, у нашым жыцці за ўсё трэба плаціць. І гэты падатак вялікі, асабліва калі казаць аб пераходзе на Kubernetes кампаніі з развітой інфраструктурай, як лічыць Іван Круглоў. Ён свабодна мог бы працаваць як у кампаніі з традыцыйнай інфраструктурай, так і з Куберам. Галоўнае, разумець асаблівасці кампаніі і рынка. Але, напрыклад, для Яўгена Патапава, які абагульніў бы Kubernetes да любой прылады аркестрацыі кантэйнераў, такое пытанне не стаіць.
Яўген правёў аналогію з сітуацыяй у 1990-х гадах, калі з'явілася аб'ектна-арыентаванае праграмаванне, як спосаб праграмавання складаных дадаткаў. На той момант не спыняліся дэбаты і з'яўляліся новыя інструменты, якія падтрымліваюць ААП. Затым з'явіліся мікрасэрвісы як спосаб адысці ад маналітнай канцэпцыі. Гэта, у сваю чаргу, прывяло да з'яўлення кантэйнераў і прылад іх кіравання. "Я думаю, што хутка мы прыйдзем да таго часу, калі не будзе стаяць пытанне аб тым, ці варта пісаць мікрасэрвісна маленькае прыкладанне, яго будуць пісаць па дэфолце мікрасэрвісам", – лічыць ён. Аналагічна, Docker і Kubernetes са часам стануць стандартным рашэннем без неабходнасці выбару.
Праблема баз у stateless
Фота
У наш час знойдзецца шмат рэцэптаў запуску баз даных у Kubernetes. Нават як аддзяляць частку, якая працуе з дыскам I/O ад, умоўна, application – часткі базы. Ці магчыма, што ў будучыні базы дадзеных відазменяцца настолькі, што будуць пастаўляцца ў скрынцы, дзе адна частка будзе аркестравацца праз Docker і Kubernetes, а ў іншай частцы інфраструктуры, праз асобны софт, будзе давацца storage частка? Базы відазменяцца як прадукт?
Гэта апісанне падобна на менеджмент чэргаў, але патрабаванні да надзейнасці і сінхроннасці інфармацыі ў традыцыйных базах даных прад'яўляюцца значна вышэй, лічыць Андрэй. Cache hit ratio у нармальных базах трымаецца на ўзроўні 99%. Калі worker кладзецца, запускаецца новы, і кэш "разаграваецца" з нуля. Пакуль кэш не разагрэты, worker працуе павольна, значыць на яго нельга пускаць карыстацкую нагрузку. Пакуль няма карыстацкай нагрузкі, кэш не разаграваецца. Гэта замкнёнае кола.
Зміцер у корані не згодзен, - кворумы і шаліраванне вырашаюць праблему. Але Андрэй настойвае, што рашэньне падыходзіць ня ўсім. У некаторых сітуацыях падыдзе кворум, але ён дае дадатковую нагрузку на сетку. База NoSQL падыходзіць не ва ўсіх выпадках.
Удзельнікі мітапа падзяліліся на два лагеры.
Дзяніс і Андрэй сцвярджаюць, што ўсё, што піша на дыск - базы і іншае, - у бягучай экасістэме Кубера зрабіць немагчыма. Немагчыма захаваць цэласнасць і кансістэнтнасць прадуктыўных дадзеных у Kubernetes. Гэта фундаментальная асаблівасць. Рашэнне: гібрыдная інфраструктура.
Нават сучасныя cloud native базы, такія як MongoDB і Cassandra, ці чэргі паведамленняў, як Kafka або RabbitMQ, патрабуюць пастаянныя сховішчы дадзеных па-за Kubernetes.
Яўген пярэчыць: "Базы ў Куберы - траўма калярасійскай, або каляэнтэрпрайзная, якая звязана з тым, што ў Расіі Cloud Adoption няма". Малыя ці сярэднія кампаніі на Захадзе - гэта Cloud. Базы Amazon RDS выкарыстоўваць прасцей, чым самім важдацца з Kubernetes. У Расіі выкарыстоўваюць Кубер "on-premise" і пераносяць у яго базы, калі спрабуюць пазбавіцца ад заапарка.
Зміцер таксама не пагадзіўся са сцвярджэннем, што ніякія базы нельга трымаць у Kubernetes: «База базе розніца. І калі пхаць гіганцкую рэляцыйную базу - то ні ў якім разе. Калі піхаць нешта невялікае і cloud native, што маральна гатова да паўэфемернага жыцця, усё будзе добра. Зміцер згадаў таксама, што прылады кіравання базамі не гатовыя ні да Docker, ні да Kuber, таму ўзнікаюць вялікія складанасці.
Іван, у сваю чаргу, упэўнены, што нават калі абстрагавацца ад паняццяў stateful і stateless, экасістэма энтерпрайзных рашэнняў у Kubernetes яшчэ не гатова. З Кубер складана падтрымліваць патрабаванні заканадаўчых і якія рэгулююць органаў. Напрыклад, немагчыма зрабіць рашэнне падавання identity, дзе патрабуюцца строгія гарантыі ідэнтыфікацыі сервера, аж да жалеза, якое ўстаўляецца ў серверы. Гэтая сфера развіваецца, але пакуль што рашэння няма.
Удзельнікам не ўдалося дамовіцца, таму ў гэтай частцы высноў не рушыць услед. Лепш прывядзем пару практычных прыкладаў.
Кейс 1. Кібэрбясьпека мэгарэгулятара з базамі па-за Кубэрам.
У выпадку развітой сістэмы кібербяспекі, выкарыстанне кантэйнераў і аркестрацыі дазваляе адбівацца ад нападаў і ўварванняў. Напрыклад, у адным мегарэгулятары Дзяніс і яго каманда рэалізавалі звязку аркестратара з навучаным SIEM-сэрвісам, які аналізуе логі ў рэальным часе і вызначае працэс нападу, узлому або збою. У выпадку нападу, спробы нешта пакласці, ці пры ўварванні віруса-вымагальніка, ён праз аркестратар паднімае кантэйнеры з application'амі хутчэй, чым яны заражаюцца, ці хутчэй, чым іх атакуе зламыснік.
Кейс 2. Частковы пераезд баз дадзеных Booking.com у Kubernetes
У Booking.com асноўная база дадзеных – гэта MySQL з асінхроннай рэплікацыяй – ёсць master і цэлая іерархія слейваў. Да моманту сыходу Івана з кампаніі быў запушчаны праект па пераносе cлейваў, якія можна «адстрэліць» з вызначанай шкодай.
Апроч асноўнай базы ёсць усталёўка Cassandra з самапіснай аркестрацыяй, якую пісалі яшчэ да таго як Кубер выйшаў у мэйнстрым. Праблем у гэтым плане няма, але ў яе persistent на лакальныя SSD. Выдалены сховішчы, нават у рамках аднаго дата-цэнтра, не выкарыстоўваюцца з-за праблемы з высокай затрымкай.
Трэці клас баз даных - гэта пошукавы сэрвіс Booking.com, дзе кожная нода сэрвісу з'яўляецца базай даных. Спробы перанесці пошукавы сэрвіс у Кубер не выдаліся, таму што кожная нода – гэта 60-80 Гб лакальнага storage, якія складана "падняць" і "разагрэць".
У выніку пошукавы рухавік у Kubernetes не перанеслі, і Іван не думае, што будуць новыя спробы ў бліжэйшы час. База MySQL была перанесена напалову: толькі Слейвы, якія не страшна "адстрэліць". Cassandra прыжылася выдатна.
Выбар інфраструктуры як задача без агульнага рашэння
Фота
Выкажам здагадку, у нас ёсць новая кампанія, ці кампанія, дзе частка інфраструктуры пабудавана па-старому. У ёй будуюць план развіцця інфраструктуры на гады. Як прымаецца рашэнне, будаваць інфраструктуру на кантэйнерах і Кубер ці не?
Кампаніі, якія б'юцца за нанасекунды выключаны з дыскусіі. Здаровы кансерватызм акупляецца з меркаванняў надзейнасці, але тым не менш ёсць кампаніі, якім варта разгледзець новыя падыходы.
Іван: «Я б зараз, безумоўна, стартаваў кампанію ў сloud, проста таму, што гэта хутчэй», хаця не абавязкова танней. З развіццём венчурнага капіталізму ў стартапаў з грашыма вялікіх праблем няма, і асноўная задача - заваяваць рынак.
Іван прытрымліваецца погляду, што развітасць бягучай інфраструктуры з'яўляецца крытэрам выбару. Калі ў мінулым былі сур'ёзныя ўкладанні, і гэта працуе, то няма сэнсу перарабляць. Калі ж інфраструктура не развіта, і ёсць праблемы з інструментамі, бяспекай і маніторынгам, то ёсць сэнс паглядзець на размеркаваную інфраструктуру.
Падатак заплаціць давядзецца ў любым выпадку, і Іван плаціў бы той, які дазволіў яму ў будучыні плаціць менш. «Таму што проста за кошт таго, што я еду ў цягніку, які рухаюць іншыя, я праеду нашмат далей, чым калі я сяду ў іншы цягнік, у які мне давядзецца паліва закідваць самому.»- Кажа Іван. Калі кампанія новая, і патрабаванні да latency – дзясяткі мілісекунд, то Іван глядзеў бы ў бок «аператараў», у якія сёння «заварочваюць» класічныя базы дадзеных. Яны паднімаюць replication chain, які сам перамыкаецца ў выпадку failover і да т.п.
Для маленькай кампаніі з парай сервераў у Кубер сэнсу няма, - сцвярджае Андрэй. Але калі яна плануе вырасці да сотні сервераў і больш, то патрэбная аўтаматызацыя і сістэма кіравання рэсурсамі. 90% выпадкаў апраўдваюць выдаткі. Прычым незалежна ад узроўню нагрузкі і рэсурсаў. Усім, пачынаючы ад стартапаў, заканчваючы буйнымі кампаніямі з мільённай аўдыторыяй, мае сэнс паступова глядзець у бок прадуктаў для аркестрацыі кантэйнераў. "Так, гэта сапраўды будучыня", - упэўнены Андрэй.
Дзяніс абазначыў два галоўныя крытэрыі. маштабаванасць і ўстойлівасць працы. Ён выбера тыя інструменты, якія лепш за ўсё падыходзяць для гэтай задачы. «Гэта можа быць на каленцы сабраны ноўнэйм, і на ім Nutanix Community Edition. Гэта можа быць другая лінія ў выглядзе application на Kuber з базай дадзеных на бэкендзе, якая рэплікуецца і мае зададзеныя параметры RTO і RPO» (recovery time/point objectives — прым).
Яўген абазначыў магчымую праблему з кадрамі. На бягучы момант на рынку не так шмат высакакласных спецыялістаў, якія разбіраюцца "ў кішках". Сапраўды, калі абраная тэхналогія старая, то складана наняць кагосьці, акрамя немаладых нудных і стомленых ад жыцця людзей. Хаця іншыя ўдзельнікі лічаць, што гэта пытанне падрыхтоўкі кадраў.
Калі паставіць пытанне выбару: запускаць невялікую кампанію ў Public Cloud з базамі ў Amazon RDS ці "on premise" з базамі ў Kubernetes, то нягледзячы на некаторыя недахопы, выбарам удзельнікаў стаў Amazon RDS.
Бо большасць слухачоў мітапу не з «крывавага» энтэрпрайзу, то размеркаваныя рашэнні - гэта тое, да чаго трэба імкнуцца. Сістэмы захоўвання дадзеных павінны быць размеркаванымі, надзейнымі, і ствараць latency, якія вымяраюцца адзінкамі мілісекунд, максімум дзясяткамі, - Рэзюмаваў Андрэй.
Ацэнка выкарыстання Kubernetes
Слухач Антон Жбанкоў задаў пытанне-пастку апалагетам Kubernetes: як выбіралі і праводзілі тэхніка-эканамічнае абгрунтаванне? Чаму Kubernetes, чаму не віртуальныя машыны, напрыклад?
Фота
На яго адказалі Зміцер і Іван. У абодвух выпадках метадам спроб і памылак, была зроблена паслядоўнасць рашэнняў, у выніку якой абодва ўдзельніка прыйшлі да Kubernetes. Цяпер бізнэс пачынае самастойна распрацоўваць софт, які мае сэнс пераносіць у Кубер. Гаворка не ідзе аб класічных іншых сістэмах, тыпу 1С. Kubernetes дапамагае, калі распрацоўнікам трэба аператыўна рабіць рэлізы, пры няспынным Continuous Improvement.
Каманда Андрэя спрабавала рабіць маштабаваны кластар на аснове віртуальных машын. Ноды падалі як даміно, што часам прыводзіла да падзення кластара. «Тэарэтычна можна дарабіць і падтрымліваць рукамі, але моташна. І калі на рынку ёсць рашэнне, якое дазваляе працаваць са скрынкі, то мы з задавальненнем ідзём да яго. І мы перайшлі ў выніку.», - распавядае Андрэй.
Стандарты для падобнага аналізу і разліку маюцца, але ніхто не скажа, наколькі яны дакладныя на рэальным жалезе ў эксплуатацыі. Для разлікаў таксама важна разбірацца ў кожнай прыладзе і экасістэме, але гэта немагчыма.
Што нас чакае
Фота
Калі тэхналогіі развіваюцца, з'яўляецца ўсё больш разрозненых кавалачкаў, а затым адбываецца фазавы пераход, з'яўляецца вендар, які забіў дастаткова «бабла», каб усё злучылася разам у адзінай прыладзе.
Ці не здаецца вам, што наступіць момант, калі з'явіцца прылада, якім стала Ubuntu для міру Linux? Магчыма, адзіны інструмент кантэйнерызацыі і аркестрацыі ўключыць у сябе і Кубер. З ім стане проста будаваць on-premise аблокі.
Адказ даў Іван: «Google зараз будуе Anthos – гэта іх пакетная прапанова, якая разгортвае воблака і ўключае ў сябе Kuber, Service Mesh, маніторынг, – усю абвязку, якая патрэбна для мікрасэрвісаў у «on-premise». Мы амаль у будучыні.»
Дзяніс таксама згадаў Nutanix і VMWare з прадуктам vRealize Suite, якія могуць спраўляюцца з падобнай задачай без кантэйнерызацыі.
Зміцер падзяліўся меркаваннем, што памяншэнне «болю» і зніжэнне падатку - гэта два напрамкі, дзе варта чакаць паляпшэнняў.
Падводзячы вынік дыскусіі, вылучым наступныя праблемы сучаснай інфраструктуры.
- Адразу трое ўдзельнікаў абазначылі праблему са stateful.
- Рознага роду праблемы падтрымкі бяспекі, у тым ліку верагоднасць таго, што выніку ў Docker апынуцца некалькі версій Python, application-сервераў і кампанент.
Перарасход, аб якім лепш зрабіць асобны мітап.
Праблема навучання, бо аркестрацыя уяўляе сабой складаную экасістэму.
Агульная праблема галіны - выкарыстанне інструментаў не па прызначэнні.Астатнія высновы рабіць вам. Пакуль застаецца адчуванне, што звязку Docker + Kubernetes няпроста стаць "цэнтральнай" часткай сістэмы. Напрыклад, аперацыйныя сістэмы ставяцца на жалязяку першымі, чаго нельга сказаць аб кантэйнерах і аркестрацыі. Магчыма, у будучыні зрастуцца аперацыёнкі і кантэйнеры з cloud management софтам.
ФотаКарыстаючыся выпадкам хачу перадаць прывітанне маме нагадаю, што ў нас ёсць фэйсбук-група , канал з цікавымі публікацыямі з розных тэхна-блогаў. І мой канал , Дзе я распавядаю аб кіраванні распрацоўкай у прадуктовых кампаніях.
Крыніца: habr.com