Прывітанне, мяне клічуць Дзмітрый Красноў. Ужо больш за пяць гадоў я займаюся адміністраваннем кластараў Kubernetes і пабудовай складаных мікрасэрвісных архітэктур. У пачатку гэтага года мы запусцілі сэрвіс па кіраванні кластарамі Kubernetes на базе Containerum. Карыстаючыся падставай распавяду, што ўяўляе сабою гэты самы Kubernetes і чым інтэграцыя з вендарам адрозніваецца ад open source.
Для пачатку, што такое . Гэта сістэма для кіравання кантэйнерамі на вялікай колькасці хастоў. З грэчаскай, дарэчы, перакладаецца як "пілот" або "рулявы". Першапачаткова распрацавана Google, пасля чаго ў якасці тэхналагічнага ўкладу перададзена Cloud Native Computing Foundation, міжнароднай некамерцыйнай арганізацыі, якая аб'ядноўвае вядучых сусветных распрацоўшчыкаў, канчатковых карыстальнікаў і пастаўшчыкоў кантэйнерных тэхналогій.
Руліць вялікай колькасцю кантэйнераў
Цяпер разбяромся, што гэта яшчэ за кантэйнеры. Гэта дадатак з усім яго асяроддзем - у асноўным, бібліятэкамі, ад якіх залежыць праца праграмы. Усё гэта запакавана ў архівы і прадстаўлена ў выглядзе выявы, які можна запускаць па-за залежнасцю ад аперацыйнай сістэмы, тэставаць і не толькі. Але ёсць праблема - кіраваць кантэйнерамі на вялікай колькасці хастоў вельмі складана. Таму і быў створаны Kubernetes.
Выява кантэйнера ўяўляе сабой дадатак плюс яго залежнасці. Прыкладанне, яго залежнасці і выява файлавай сістэмы АС размяшчаюцца ў розных частках выявы, так званых пластах. Пласты могуць перавыкарыстоўвацца для розных кантэйнераў. Напрыклад, для ўсіх прыкладанняў у кампаніі можа выкарыстоўвацца базавы пласт Ubuntu. Пры запуску кантэйнераў няма патрэбы захоўваць на хасце мноства дзід аднаго базавага пласта. Гэта дазваляе аптымізаваць захоўванне і дастаўку выяў.
Калі мы жадаем запусціць прыкладанне з кантэйнера, патрэбныя пласты накладваюцца сябар на сябра і ўтворыцца оверлейная файлавая сістэма. Зверху накладваецца пласт для запісу, які, пры прыпынку кантэйнера, выдаляецца. Гэта гарантуе, што пры запуску кантэйнера ў дадатку заўсёды будзе аднолькавае асяроддзе, якое не можа быць зменена. Гэта гарантуе ўзнаўляльнасць асяроддзя на розных хостовых АС. Будзь то Ubuntu або CentOS, - асяроддзе заўсёды будзе аднолькавым. Да таго ж кантэйнер ізаляваны ад хаста пры дапамозе ўбудаваных у ядро Linux механізмаў. Прыкладанні ў кантэйнеры не бачаць файлы, працэсы хаста і суседніх кантэйнераў. Такая ізаляцыя прыкладанняў ад хаставой АС дае дадатковы пласт бяспекі.
Для кіравання кантэйнерамі на хасце ёсць мноства прылад. Самы папулярны з іх, - гэта Docker. Ён дазваляе забяспечыць поўны жыццёвы цыкл працы кантэйнераў. Аднак ён працуе толькі на адным хасце. Пры неабходнасці кіравання кантэйнерамі на мностве хастоў Docker можа ператварыць жыццё інжынераў у пекла. Таму і быў створаны Kubernetes.
Запатрабаванасць Kubernetes як раз і абумоўлена магчымасцю руліць групамі кантэйнераў на мностве хастоў як нейкімі адзінымі сутнасцямі. Папулярнасць сістэме забяспечвае магчымасць пабудаваць DevOps ці Development Operations, у якіх Kubernetes выкарыстоўваецца для запуску працэсаў гэтага самага DevOps.
Малюнак 1. Схематычны малюнак прынцыпу працы Kubernetes
Поўная аўтаматызацыя
DevOps, у прынцыпе, уяўляе сабой аўтаматызацыю працэсу распрацоўкі. Грубіянска кажучы, распрацоўшчыкі пішуць код, які заліваецца ў рэпазітар. Затым гэты код можа аўтаматычна збірацца адразу ў кантэйнер са ўсімі бібліятэкамі, тэставацца і "выкочвацца" на наступную стадыю – Staging, а затым адразу і на Production.
Разам з Kubernetes DevOps дазваляе аўтаматызаваць гэты працэс, каб ён працякаў практычна без удзелу саміх распрацоўшчыкаў. За кошт гэтага значна паскараецца зборка, паколькі распрацоўніку не даводзіцца займацца гэтым у сябе на кампутары - ён проста піша кавалак кода, пушыць код у рэпазітар, пасля чаго запускаецца pipeline, які можа ўключаць у сябе працэс зборкі, тэсціравання, выкаткі. І так адбываецца з кожным коммітам, таму тэсціраванне адбываецца бесперапынна.
Пры гэтым выкарыстанне кантэйнера дазваляе быць упэўненым у тым, што ўсё асяроддзе гэтай праграмы выйдзе ў production менавіта ў тым выглядзе, у якім тэставалася. Гэта значыць не ўзнікне праблем з разраду "на цесцю былі адны версіі, у production - іншыя, а паставілі - усё ўпала". А паколькі сёння мы маем трэнд на мікрасэрвісную архітэктуру, калі замест аднаго велізарнага прыкладання ёсць сотні маленькіх, то для таго каб адміністраваць іх уручную, - запатрабуецца велізарны штат супрацоўнікаў. Таму мы і выкарыстоўваем Kubernetes.
Плюсы, плюсы, плюсы
Калі казаць пра добрыя якасці Kubernetes як платформы, то ў яго істотныя плюсы з пункта гледжання кіравання мікрасэрвіснай архітэктурай.
- Упраўленне мноствам рэплік. Самае галоўнае - гэта кіраванне кантэйнерамі на мностве хастоў. І што больш важна, - кіраванне мноствам рэплік прыкладанняў у кантэйнерах як адзінай сутнасцю. Дзякуючы гэтаму інжынерам не трэба клапаціцца аб кожным асобным кантэйнеры. Калі адзін з кантэйнераў ўпадзе, то Kubernetes ўбачыць гэта і перазапусціць яго зноў.
- Кластарная сетка. Таксама ў Kubernetes ёсць так званая кластарная сетка з уласнай адраснай прасторай. Дзякуючы гэтаму кожны пад мае свой адрас. Пад подом разумеецца мінімальная структурная адзінка кластара, у якой непасрэдна запускаюцца кантэйнеры. Да таго ж у Kubernetes ёсць функцыянал, які сумяшчае ў сабе балансавальнік нагрузкі і Service Discovery. Гэта дазваляе пазбавіцца ад ручнога кіравання IP-адрасамі і ўскласці гэтую задачу на плечы Kubernetes. А аўтаматычныя health check`і дапамогуць выявіць праблемы і перанакіраваць трафік на працоўныя поды.
- Упраўленне канфігурацыямі. Пры кіраванні вялікай колькасцю прыкладанняў становіцца складана кіраваць канфігурацыяй прыкладанняў. Для гэтага ў Kubernetes ёсць спецыяльныя рэсурсы ConfigMap`ы. Яны дазваляюць цэнтралізавана захоўваць канфігурацыі і падстаўляць іх у поды пры запуску прыкладанняў. Такі механізм дазваляе гарантаваць кансістэнтнасць канфігурацыі хоць у дзесяці, хоць у сотні рэплік прыкладанняў.
- Persistent Volumes. Кантэйнеры па сваёй сутнасці імутабельныя і пры прыпынку кантэйнера ўсе дадзеныя, запісаныя на файлавую сістэму, будуць знішчаны. Але некаторыя прыкладанні захоўваюць дадзеныя прама на дыску. Для вырашэння гэтай праблемы ў Kubernetes ёсць функцыянал кіравання дыскавым сховішчам – Persistent Volumes. Гэты механізм выкарыстоўвае вонкавае сховішча для дадзеных, можа пракідваць у кантэйнеры сталае сховішча, блокавае ці файлавае. Такое рашэнне дазваляе захоўваць дадзеныя асобна ад воркераў, што ратуе іх пры паломцы гэтых самых воркераў.
- Load Balancer. Нягледзячы на тое, што ў Kubernetes мы кіруем абстрактнымі сутнасцямі тыпу Deployment, StatefulSet і г.д., у канчатковым рахунку кантэйнеры запускаюцца на звычайных віртуальных машынах ці жалезных серверах. Яны не ідэальныя і могуць зваліцца ў любы момант. Kubernetes гэта ўбачыць і перанакіруе ўнутраны трафік на іншыя рэплікі. Але што рабіць з трафікам, які прыходзіць звонку? Калі проста накіраваць трафік на адзін з воркераў, што ў выпадку яго падзення сэрвіс стане недаступны. Для вырашэння гэтай праблемы ў Kubernetes ёсць сервісы тыпу Load Balancer. Яны прызначаны для аўтаматычнай налады вонкавага хмарнага балансавальніка на ўсе воркеры ў кластары. Гэты вонкавы балансавальнік накіроўвае вонкавы трафік на воркеры і сам сочыць за іх статутам. Калі адзін ці некалькі воркераў становяцца недаступныя, то трафік перанакіроўваецца на іншыя. Гэта дазваляе ствараць высокадаступныя сервісы з дапамогай Kubernetes.
Лепш за ўсё Kubernetes сябе выяўляе менавіта пры запуску мікрасэрвіснай архітэктуры. Укараняць сістэму ў класічную архітэктуру можна, але бессэнсоўна. Калі прыкладанне не можа працаваць у некалькіх рэпліках, то якая сутнасць розніца - у Kubernetes ці не?
Open source Kubernetes
Open source Kubernetes - выдатная рэч: паставіў і працуе. Можна разгарнуць на сваіх жалезных серверах, на сваёй інфраструктуры, паставіць майстры і воркеры, на якіх будуць запускацца ўсе прыкладанні. А галоўнае - усё гэта бясплатна. Аднак ёсць нюансы.
- Першы - патрабавальнасць да ведаў і досведу адміністратараў і інжынераў, якія будуць усё гэта разгортваць і суправаджаць. Паколькі кліент атрымлівае поўную свабоду дзеянняў у кластары, то адказнасць за працаздольнасць кластара ён нясе сам. А зламаць тут усё вельмі проста.
- Другі - адсутнасць інтэграцый. Калі запускаць Kubernetes, не маючы нейкай папулярнай платформы віртуалізацыі, то не атрымаеце ўсіх пераваг праграмы. Такіх як выкарыстанне Persistent Volumes і сервісаў Load balancer.
Малюнак 2. Архітэктура k8s
Kubernetes ад вендара
Інтэграцыя з хмарным правайдэрам дае дзве магчымасці:
- Па-першае, чалавек можа проста націснуць на кнопку "стварыць кластар" і атрымаць ужо наладжаны і гатовы да працы кластар.
- Па-другое, вендар сам ставіць кластар і наладжвае інтэграцыю з воблакам.
Як гэта робіцца ў нас. Інжынер, які запускае кластар, паказвае, колькі яму трэба воркераў і з якімі параметрамі (напрыклад, 5 воркераў, кожны на 10 ЦПУ, 16 ГБ аператыўнай памяці і, скажам, 100 ГБ дыска). Пасля чаго атрымлівае доступ ва ўжо сфарміраваны кластар. Пры гэтым воркеры, на якіх запускаецца нагрузка, цалкам аддаюцца кліенту, але ўвесь management plane застаецца ў зоне адказнасці вендара (у выпадку, калі сэрвіс падаецца па мадэлі managed service).
Аднак такая схема мае свае недахопы. З-за таго, што management plane застаецца ў вендара, то вендар не дае поўны доступ кліенту, і гэта зніжае гнуткасць у працы з Kubernetes. Часам бывае, што кліент жадае прыкруціць да Kubernetes нейкі спецыфічны функцыянал, напрыклад, аўтэнтыфікацыю праз LDAP, а канфігурацыя management plane гэтага не дазваляе.
Малюнак 3. Прыклад кластара Kubernetes ад хмарнага правайдэра
Што абраць: open source або вендорскі
Такім чынам, open source Kubernetes або вендорскі? Калі браць open source Kubernetes, то карыстач што жадае, то з ім і робіць. Але вялікі шанец самому сабе стрэліць у нагу. З вендорскім гэта складаней, бо за кампанію ўсё прадумана і настроена. Самым вялікім недахопам апенсорснага Kubernetes з'яўляецца патрабаванне да спецыялістаў. З вендорскім кампанія ад гэтага галаўнога болю пазбаўлена, але ёй давядзецца вырашаць: плаціць сваім спецыялістам або вендару.
Ну што, плюсы відавочныя, мінусы таксама вядомы. Нязменна адно: Kubernetes вырашае масу праблем, аўтаматызуючы кіраванне мноствам кантэйнераў. А які абраць, open source або вендорскі, - кожны прымае рашэнне сам.
Артыкул падрыхтаваў Дзмітрый Красноў, вядучы архітэктар сэрвісу Containerum правайдэра #CloudMTS
Крыніца: habr.com