Заўв. перав.: адаптацыю Kubernetes у GitLab лічаць адным з двух галоўных фактараў, якія садзейнічаюць росту кампаніі. Тым не менш, да нядаўняга часу інфраструктура анлайн-сэрвісу GitLab.com была пабудавана на віртуальных машынах, і толькі каля года таму пачалася яе міграцыя ў K8s, якая да гэтага часу не завершана. Рады прадставіць пераклад нядаўняга артыкула SRE-інжынера GitLab аб тым, як гэта адбываецца і якія высновы робяць інжынеры, якія ўдзельнічаюць у праекце.
Вось ужо каля года наша інфраструктурнае падраздзяленне займаецца міграцыяй усіх сэрвісаў, якія працуюць на GitLab.com, у Kubernetes. За гэты час мы сутыкнуліся з праблемамі, злучанымі не толькі з перасоўваннем сэрвісаў у Kubernetes, але і з кіраваннем гібрыдным deployment'ам падчас пераходу. Аб каштоўных уроках, атрыманых намі, і пайдзе прамову ў гэтым артыкуле.
З самага пачатку GitLab.com яго серверы працавалі ў воблаку на віртуальных машынах. Гэтымі віртуальнымі машынамі кіруе Chef, а іх усталёўка адбываецца з дапамогай нашага . на выпадак, калі трэба абнавіць прыкладанне, складаецца ў простым абнаўленні парка сервераў скаардынаваным паслядоўным чынам з дапамогай CI-пайплайну. Гэты метад - хай павольны і крышачку - гарантуе, што GitLab.com прымяняе тыя ж спосабы ўстаноўкі і канфігуравання, што і карыстальнікі аўтаномных (self-managed) усталёвак GitLab, якія ўжываюць для гэтага нашы Linux-пакеты.
Мы выкарыстоўваем такі метад, паколькі выключна важна адчуць на сабе ўсе смутку і радасці, якія адчуваюць радавыя прадстаўнікі супольнасці, калі ўстанаўліваюць і настройваюць свае копіі GitLab. Гэты падыход добра працаваў на працягу некаторага часу, аднак калі колькасць праектаў на GitLab пераваліла за 10 млн, мы зразумелі, што ён больш не задавальняе нашым патрэбам у маштабаванні і разгортванні.
Першыя крокі да Kubernetes і cloud-native GitLab
У 2017-м быў створаны праект для падрыхтоўкі GitLab да разгортвання ў воблаку, а таксама для таго, каб даць карыстачам магчымасць усталёўваць GitLab у кластары Kubernetes. Тады мы ведалі, што перанос GitLab у Kubernetes павялічыць магчымасці маштабавання SaaS-платформы, спросціць разгортванні і падвысіць эфектыўнасць выкарыстання вылічальных рэсурсаў. У той жа час шматлікія функцыі нашага прыкладання залежалі ад прымантаваных NFS-частак, што запавольвала пераход з віртуальных машын.
Імкненне да cloud native і Kubernetes дазволіла нашым інжынерам планаваць паступовы пераход, падчас якога мы адмовіліся ад некаторых залежнасцяў прыкладання ад сеткавых сховішчаў, адначасна працягваючы распрацоўваць новыя функцыі. З таго часу, як мы пачалі планаваць міграцыю летам 2019-га, многія з гэтых абмежаванняў былі ліквідаваны, і працэс перакладу GitLab.com на Kubernetes зараз ідзе поўным ходам!
Асаблівасці працы GitLab.com у Kubernetes
Для GitLab.com мы выкарыстоўваем адзіны рэгіянальны кластар GKE, які апрацоўвае ўвесь трафік прыкладання. Каб мінімізаваць складанасць (без таго складанай) міграцыі, мы канцэнтруемся на сэрвісах, якія не залежаць ад лакальнага сховішча ці NFS. GitLab.com выкарыстоўвае пераважна маналітную кодавую базу на Rails, і мы накіроўваем трафік у залежнасці ад характарыстык працоўнай нагрузкі на розныя endpoint'ы, ізаляваныя ў свае ўласныя пулы вузлоў.
У выпадку фронтэнда гэтыя тыпы падзяляюцца на запыты да web, API, Git SSH/HTTPS і Registry. У выпадку бэкенда мы разбіваем job'ы ў чарзе па розных характарыстыках у залежнасці ад , якія дазваляюць нам усталёўваць мэтавыя паказчыкі ўзроўня абслугоўвання (Service-Level Objectives, SLOs) для розных нагрузак.
Усе гэтыя сэрвісы GitLab.com настроены з дапамогай немадыфікаванага Helm-чарта GitLab. Канфігурацыя праводзіцца ў субчартах, якія могуць быць выбарачна ўключаны па меры таго, як мы паступова пераносім сэрвісы ў кластар. Нават з улікам таго, што было вырашана не ўключаць у міграцыю некаторыя з нашых stateful-сэрвісаў, такія як Redis, Postgres, GitLab Pages і Gitaly, выкарыстанне Kubernetes дазваляе радыкальна скараціць лік VM, якімі кіруе Chef у наш час.
Празрыстасць і кіраванне канфігурацыяй Kubernetes
Усе налады кіруюцца самім GitLab'ам. Для гэтага выкарыстоўваюцца тры канфігурацыйных праекты на аснове Terraform і Helm. Мы стараемся ўсюды па магчымасці выкарыстоўваць сам GitLab для запуску GitLab'а, але для эксплуатацыйных задач у нас функцыянуе асобная інсталяцыя GitLab. Яна патрэбная для таго, каб не залежаць ад даступнасці GitLab.com пры правядзенні разгортванняў і абнаўленняў GitLab.com.
Хоць нашы пайплайны для кластара Kubernetes працуюць на асобнай усталёўцы GitLab, ёсць у рэпазітароў кода ёсць люстэркі, публічна даступныя па наступных адрасах:
- - канфігурацыйная абвязка GitLab.com для Helm-чарта GitLab;
- - Змяшчае канфігурацыі для сэрвісаў, якія не звязаны з дадаткам GitLab непасрэдна. У іх лік уваходзяць канфігурацыі для вядзення логаў і маніторынгу кластара, а таксама для інтэграваных прылад накшталт PlantUML;
- – канфігурацыя Terraform для Kubernetes і старой (legacy) VM-інфраструктуры. Тут наладжваюцца ўсе рэсурсы, неабходныя для запуску кластара, у тым ліку сам кластар, пулы вузлоў, уліковыя запісы службаў, рэзерваванне IP-адрасоў.
Пры занясенні змен паказваецца агульнадаступнае са спасылкай на падрабязны diff, які SRE аналізуе перад унясеннем змен у кластар.
Для SRE спасылка вядзе на падрабязны diff у інсталяцыі GitLab, якая выкарыстоўваецца для эксплуатацыі і доступ да якой абмежаваны. Гэта дазваляе супрацоўнікам і супольнасці без доступу да эксплуатацыйнага праекту (ён адкрыты толькі для SRE) праглядаць прапанаваныя змены ў канфігурацыі. Спалучаючы агульнадаступны асобнік GitLab'а для кода з зачыненым асобнікам для CI-пайплайнаў, мы захоўваем адзіны працоўны працэс, у той жа час гарантуючы незалежнасць ад GitLab.com пры абнаўленнях канфігурацыі.
Што мы высветлілі за час міграцыі
У працэсе пераезду быў назапашаны досвед, які мы ўжываем да новых міграцый і deployment'ам у Kubernetes.
1. Рост выдаткаў з-за трафіку паміж зонамі даступнасці
Штодзённая egress-статыстыка (байт у суткі) па парку Git-сховішчаў на GitLab.com
Google дзеліць сваю сетку на рэгіёны. Тыя, у сваю чаргу, разбіваюцца на зоны даступнасці (AZ). Git-хостынг звязаны з вялікімі аб'ёмамі дадзеных, таму нам важна кантраляваць сеткавы egress. У выпадку ўнутранага трафіку egress бясплатны толькі ў тым выпадку, калі ён застаецца ў межах адной зоны даступнасці. На момант напісання гэтага артыкула мы аддаём прыкладна 100 Тб дадзеных у звычайны працоўны дзень (і гэта толькі для Git-рэпазітароў). Сэрвісы, якія ў нашай старой тапалогіі, заснаванай на VM, знаходзіліся на адных і тых жа віртуальных машынах, зараз працуюць у розных pod'ах Kubernetes. Гэта азначае, што некаторая частка трафіку, якая раней была лакальнай для VM, можа патэнцыйна выходзіць за межы зон даступнасці.
Рэгіянальныя кластары GKE дазваляюць ахопліваць некалькі зон даступнасці для рэзервавання. Мы разглядаем магчымасць для сэрвісаў, якія генеруюць вялікія аб'ёмы трафіку. Гэта дазволіць скараціць выдаткі на egress пры захаванні рэзервавання на ўзроўні кластара.
2. Limit'ы, request'ы рэсурсаў і маштабаванне
Лік рэплік, якія апрацоўваюць production-трафік на registry.gitlab.com. Трафік дасягае свайго піка ў ~15:00 UTC.
Наша гісторыя з міграцыяй пачалася ў жніўні 2019-га, калі мы перанеслі першы сэрвіс - рэестр кантэйнераў GitLab (GitLab Container Registry) - у Kubernetes. Гэты крытычна важны сэрвіс з высокім трафікам добра падышоў для першай міграцыі, паколькі ўяўляе сабой stateless-дадатак з малым лікам вонкавых залежнасцяў. Першай праблемай, з якой мы сутыкнуліся, стала вялікая колькасць выцесненых pod'аў з-за недахопу памяці на вузлах. З-за гэтага нам прыйшлося змяняць request'ы і limit'ы.
Было выяўлена, што ў выпадку прыкладання, у якога спажыванне памяці расце з часам, нізкія значэнні для request'аў (якія рэзервуюць памяць для кожнага pod'а) разам з "шчодрым" цвёрдым limit'ам на выкарыстанне прыводзілі да насычэння (saturation) вузлоў і высокаму ўзроўню выцяснення. Каб справіцца з гэтай праблемай, было . Гэта зняло ціск з вузлоў і забяспечыла жыццёвы цыкл pod'аў, які не аказваў занадта высокага ціску на вузел. Цяпер мы пачынаем міграцыі са шчодрымі (і амаль аднолькавымі) значэннямі request'аў і limit'аў, карэктуючы іх па неабходнасці.
3. Метрыкі і логі
Інфраструктурнае падраздзяленне факусуюць на затрымках, працэнце памылак і сатурацыі з усталяванымі (SLO), прывязанымі да .
За мінулы год адной з ключавых падзей у інфраструктурным падраздзяленні сталі паляпшэнні ў маніторынгу і працы са SLO. SLO дазволілі нам усталёўваць мэты па асобных сэрвісах, за якімі мы пільна сачылі падчас міграцыі. Але нават з такой палепшанай назіральнасцю не заўсёды можна адразу ўбачыць праблемы, выкарыстоўваючы метрыкі і алерты. Напрыклад, засяродзіўшыся на затрымках і працэнце памылак, мы не цалкам ахопліваем усе сцэнары выкарыстання сэрвісу, які праходзіць міграцыю.
Гэтая праблема была выяўлена амаль адразу пасля пераносу часткі працоўных нагрузак у кластар. Асабліва востра яна заявіла аб сабе, калі прыйшлося правяраць функцыі, колькасць запытаў да якіх невяліка, але ў якіх вельмі спецыфічныя канфігурацыйныя залежнасці. Адным з ключавых урокаў па выніках міграцыі стала неабходнасць улічваць пры маніторынгу не толькі метрыкі, але таксама логі і «доўгі хвост» (гаворка ідзе аб на графіцы - заўв. перав.) памылак. Цяпер для кожнай міграцыі мы ўключаем дэталёвы спіс запытаў да логаў. (log queries) і плануем выразныя працэдуры адкату, якія ў выпадку ўзнікнення праблем можна перадаваць ад адной змены да іншай.
Паралельнае абслугоўванне адных і тых жа запытаў на старой VM-інфраструктуры і новай, заснаванай на Kubernetes, уяўляла сабой унікальную задачу. У адрозненне ад міграцыі кшталту lift-and-shift (хуткі перанос прыкладанняў «як ёсць» у новую інфраструктуру; падрабязней можна прачытаць, напрыклад, - заўв. перав.), паралельная праца на "старых" VM і Kubernetes патрабуе, каб прылады для маніторынгу былі сумяшчальныя з абодвума асяроддзямі і ўмелі аб'ядноўваць метрыкі ў адзін выгляд. Важна, што мы выкарыстоўваем адны і тыя ж dashboard'ы і запыты да логаў, каб дамагчыся ўзгодненай назіральнасці падчас пераходнага перыяду.
4. Пераключэнне трафіку на новы кластар
Для GitLab.com частка сервераў вылучаецца пад . Канарэчны парк абслугоўвае нашы ўнутраныя праекты, а таксама можа . Але ў першую чаргу ён прызначаны для праверкі змен, якія ўносяцца ў інфраструктуру і дадатак. Першы перанесены сэрвіс пачаў з прыёму абмежаванага аб'ёму ўнутранага трафіку, і мы працягваем выкарыстоўваць гэты метад, каб пераканацца ў захаванні SLO перад тым, як накіраваць увесь трафік у кластар.
У выпадку міграцыі гэта азначае, што спачатку ў Kubernetes накіроўваюцца запыты да ўнутраных праектаў, а затым мы паступова пераключаем на кластар астатні трафік шляхам змены вагі для бэкенда праз HAProxy. У працэсе пераходу з VM на Kubernetes стала зразумела, што вельмі выгадна мець у запасе просты спосаб перанакіравання трафіку паміж старой і новай інфраструктурай і, адпаведна, трымаць старую інфраструктуру напагатове для адкату ў першыя некалькі дзён пасля міграцыі.
5. Рэзервовыя магутнасці pod'ов і іх выкарыстанне
Амаль адразу была выяўлена наступная праблема: pod'ы для сэрвісу Registry стартавалі хутка, аднак запуск pod'аў для Sidekiq займаў да . Працяглы запуск pod'аў для Sidekiq стаў праблемай, калі мы прыступілі да міграцыі ў Kubernetes працоўных нагрузак для worker'ов, якім трэба хутка апрацоўваць job'ы і хутка маштабавацца.
У дадзеным выпадку ўрок складаўся ў тым, што, хоць Horizontal Pod Autoscaler (HPA) у Kubernetes добра спраўляецца з ростам трафіку, важна прымаць да ўвагі характарыстыкі працоўных нагрузак і вылучаць рэзервовыя магутнасці pod'ов (асабліва ва ўмовах нераўнамернага размеркавання попыту). У нашым выпадку назіраўся раптоўны ўсплёск job'аў, які вабіць за сабой імклівае маштабаванне, што прыводзіла да насычэння рэсурсаў CPU да таго, як мы паспявалі маштабаваць пул вузлоў.
Заўсёды ёсць спакуса як мага больш "выціснуць" з кластара, аднак мы, першапачаткова сутыкнуўшыся з праблемамі з прадукцыйнасцю, зараз пачынаем з шчодрага pod budget'а і памяншаем яго пасля, пільна сочачы за SLO. Запуск pod'аў для сэрвісу Sidekiq значна паскорыўся і зараз у сярэднім займае каля 40 секунд. выйграў як GitLab.com, так і нашы карыстачы усталёвак self-managed, якія працуюць з афіцыйным Helm-чартам GitLab.
Заключэнне
Пасля пераносу кожнага сэрвісу мы цешыліся перавагамі выкарыстання Kubernetes у production: хутчэйшаму і бяспечнаму дэплою прыкладання, маштабаванню і больш эфектыўнаму размеркаванню рэсурсаў. Прычым плюсы міграцыі выходзяць за рамкі сервісу GitLab.com. Ад кожнага паляпшэння афіцыйнага Helm-чарта выйграюць і яго карыстачы.
Спадзяюся, вам спадабалася гісторыя пра нашы прыгоды з міграцыяй у Kubernetes. Мы працягваем пераносіць усе новыя сэрвісы ў кластар. Дадатковую інфармацыю можна атрымаць з наступных публікацый:
- «»;
- «»;
- .
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com