Ескерту. аударма: GitLab-те Kubernetes-ті қабылдау компанияның өсуіне ықпал ететін екі негізгі фактордың бірі болып саналады. Дегенмен, соңғы уақытқа дейін GitLab.com онлайн-сервисінің инфрақұрылымы виртуалды машиналарда салынған және шамамен бір жыл бұрын оның K8-ге көшуі басталды, ол әлі аяқталмаған. Біз GitLab SRE инженерінің бұл қалай болатыны және жобаға қатысушы инженерлер қандай қорытынды жасайтыны туралы жақында жазған мақаласының аудармасын ұсынуға қуаныштымыз.
Шамамен бір жыл бойы біздің инфрақұрылымдық бөлімше GitLab.com сайтында жұмыс істейтін барлық қызметтерді Kubernetes-ке көшіруде. Осы уақыт ішінде біз қызметтерді Kubernetes-ке жылжытуға ғана емес, сонымен қатар ауысу кезінде гибридті орналастыруды басқаруға қатысты қиындықтарға тап болдық. Біз алған құнды сабақтар осы мақалада талқыланады.
GitLab.com басынан бастап оның серверлері виртуалды машиналарда бұлтта жұмыс істеді. Бұл виртуалды машиналарды аспаз басқарады және біздің көмегімен орнатылады . егер қолданбаны жаңарту қажет болса, CI құбырын пайдалану арқылы серверлер паркін келісілген, дәйекті түрде жаңартудан тұрады. Бұл әдіс - баяу және аз болса да - GitLab.com офлайн пайдаланушылар сияқты орнату және конфигурациялау тәжірибесін қолдануын қамтамасыз етеді (өзін-өзі басқаратын) Бұл үшін Linux пакеттерімізді пайдаланатын GitLab қондырғылары.
Біз бұл әдісті қолданамыз, өйткені GitLab көшірмелерін орнату және конфигурациялау кезінде қауымдастықтың қарапайым мүшелері бастан кешіретін барлық қайғы мен қуаныштарды сезіну өте маңызды. Бұл тәсіл біраз уақыт жақсы жұмыс істеді, бірақ GitLab жобаларының саны 10 миллионнан асқанда, біз оның бұдан былай масштабтау және орналастыру қажеттіліктерімізді қанағаттандырмайтынын түсіндік.
Kubernetes және бұлттық GitLab-қа алғашқы қадамдар
Жоба 2017 жылы құрылған GitLab бағдарламасын бұлтты орналастыруға дайындау және пайдаланушыларға GitLab-ті Kubernetes кластерлеріне орнату мүмкіндігін беру. Біз GitLab-ті Kubernetes-ке көшіру SaaS платформасының ауқымдылығын арттыратынын, орналастыруды жеңілдететінін және есептеу ресурстарының тиімділігін арттыратынын білдік. Сонымен қатар, біздің қосымшамыздың көптеген функциялары орнатылған NFS бөлімдеріне байланысты болды, бұл виртуалды машиналардан өтуді баяулатты.
Бұлтқа және Кубернетеске итермелеу инженерлерімізге бірте-бірте ауысуды жоспарлауға мүмкіндік берді, оның барысында біз жаңа мүмкіндіктерді дамытуды жалғастыра отырып, желі жадына қосымшаның кейбір тәуелділіктерін тастадық. 2019 жылдың жазында көшіруді жоспарлауды бастағаннан бері осы шектеулердің көпшілігі шешілді және GitLab.com сайтын Кубернетеске көшіру процесі қазірде жақсы жүріп жатыр!
Kubernetes ішіндегі GitLab.com мүмкіндіктері
GitLab.com үшін біз барлық қолданба трафигін өңдейтін жалғыз аймақтық GKE кластерін қолданамыз. Көшірудің күрделілігін (қазірдің өзінде қиын) азайту үшін біз жергілікті жадқа немесе NFS-ге сүйенбейтін қызметтерге назар аударамыз. GitLab.com негізінен монолитті Rails код базасын пайдаланады және біз жұмыс жүктемесінің сипаттамаларына негізделген трафикті өздерінің түйіндік пулдарына оқшауланған әртүрлі соңғы нүктелерге бағыттаймыз.
Frontend жағдайында бұл түрлер вебке, API, Git SSH/HTTPS және тізілімге сұрауларға бөлінеді. Backend жағдайында біз кезектегі тапсырмаларды әртүрлі сипаттамаларға байланысты бөлеміз , бұл бізге әртүрлі жұмыс жүктемелері үшін Қызмет деңгейінің мақсаттарын (SLOs) орнатуға мүмкіндік береді.
Осы GitLab.com қызметтерінің барлығы өзгертілмеген GitLab Helm диаграммасы арқылы конфигурацияланған. Конфигурация қызметтерді кластерге біртіндеп көшірген кезде таңдаулы түрде қосуға болатын ішкі диаграммаларда орындалады. Redis, Postgres, GitLab Pages және Gitaly сияқты кейбір мемлекеттік қызметтерімізді тасымалдауға қоспауды шешкенімізбен, Kubernetes-ті пайдалану қазіргі уақытта аспаз басқаратын VM-лердің санын түбегейлі азайтуға мүмкіндік береді.
Kubernetes конфигурациясының көрінуі және басқаруы
Барлық параметрлерді GitLab өзі басқарады. Ол үшін Terraform және Helm негізіндегі үш конфигурациялық жоба қолданылады. Біз GitLab-ті іске қосу үшін мүмкіндігінше GitLab-тің өзін пайдалануға тырысамыз, бірақ операциялық тапсырмалар үшін бізде GitLab-тың бөлек орнатылымы бар. Бұл GitLab.com орналастырулары мен жаңартуларын орындау кезінде GitLab.com қолжетімділігіне тәуелді емес екеніңізді қамтамасыз ету үшін қажет.
Kubernetes кластеріне арналған құбырларымыз бөлек GitLab орнатуында жұмыс істейтін болса да, келесі мекенжайларда жалпыға қолжетімді код репозитарийлерінің айналары бар:
- — GitLab Helm диаграммасы үшін GitLab.com конфигурация құрылымы;
- - GitLab қолданбасымен тікелей байланысты емес қызметтерге арналған конфигурацияларды қамтиды. Оларға тіркеу және кластерді бақылауға арналған конфигурациялар, сондай-ақ PlantUML сияқты біріктірілген құралдар кіреді;
- — Kubernetes және бұрынғы VM инфрақұрылымы үшін Terraform конфигурациясы. Мұнда кластерді іске қосу үшін қажетті барлық ресурстарды, соның ішінде кластердің өзін, түйін пулдарын, қызмет тіркелгілерін және IP мекенжайын резервтеуді теңшейсіз.
Қоғамдық көрініс өзгертулер енгізілген кезде көрсетіледі. кластерге өзгертулер енгізу алдында SRE талдайтын егжей-тегжейлі айырмашылыққа сілтемемен.
SRE үшін сілтеме GitLab орнатуындағы егжей-тегжейлі айырмашылыққа әкеледі, ол өндіріс үшін пайдаланылады және оған қол жеткізу шектеледі. Бұл қызметкерлерге және қауымдастыққа операциялық жобаға қатынассыз (ол тек SRE үшін ашық) ұсынылған конфигурация өзгерістерін көруге мүмкіндік береді. Кодқа арналған жалпыға ортақ GitLab данасын CI құбырларына арналған жеке данасымен біріктіру арқылы конфигурация жаңартулары үшін GitLab.com сайтынан тәуелсіздігін қамтамасыз ете отырып, бір жұмыс үрдісін сақтаймыз.
Көші-қон кезінде не білдік
Қозғалыс барысында біз Кубернетестегі жаңа көшірулер мен орналастыруларға қолданылатын тәжірибе жинақталды.
1. Қол жетімділік аймақтары арасындағы трафикке байланысты шығындардың өсуі
GitLab.com сайтындағы Git репозиторийлер флоты үшін күнделікті шығу статистикасы (күніне байт)
Google өз желісін аймақтарға бөледі. Олар, өз кезегінде, қолжетімділік аймақтарына (AZ) бөлінеді. Git хостингі деректердің үлкен көлемімен байланысты, сондықтан біз үшін желінің шығуын бақылау маңызды. Ішкі трафик үшін шығу бір қолжетімділік аймағында қалса ғана тегін болады. Осы жазу кезінде біз әдеттегі жұмыс күнінде шамамен 100 ТБ деректерге қызмет көрсетеміз (және бұл тек Git репозиторийлері үшін). Біздің ескі VM негізіндегі топологиямыздағы бірдей виртуалды машиналарда орналасқан қызметтер қазір әртүрлі Kubernetes қосқыштарында жұмыс істейді. Бұл VM үшін бұрын жергілікті болған кейбір трафик қолжетімділік аймақтарынан тыс жүруі мүмкін дегенді білдіреді.
Аймақтық GKE кластерлері артық болу үшін бірнеше қолжетімділік аймақтарын қамтуға мүмкіндік береді. Мүмкіндігін қарастырып жатырмыз трафиктің үлкен көлемін тудыратын қызметтер үшін. Бұл кластер деңгейіндегі резервтілікті сақтай отырып, шығу шығындарын азайтады.
2. Лимиттер, ресурстарды сұрау және масштабтау
registry.gitlab.com сайтындағы өндірістік трафикті өңдейтін көшірмелер саны. Трафиктің шыңы UTC ~15:00-де.
Біздің көшіру тарихымыз 2019 жылдың тамызында басталды, біз GitLab контейнер тізілімі бірінші қызметімізді Кубернетеске көшірген кезде. Бұл өте маңызды, трафикті жоғары қызмет бірінші көшіру үшін жақсы таңдау болды, себебі ол сыртқы тәуелділіктері аз азаматтығы жоқ қолданба. Біз кездестірген бірінші мәселе түйіндерде жадтың болмауына байланысты шығарылған блоктардың көп саны болды. Осыған байланысты сұраулар мен шектеулерді өзгертуге тура келді.
Уақыт өте келе жадты тұтыну ұлғайатын қолданба жағдайында сұраныстардың төмен мәндері (әр подвод үшін жадты сақтау) пайдаланудың «жомарт» қатаң шектеуімен бірге қанықтыруға әкелетіні анықталды. (қанықтыру) түйіндер мен шығарудың жоғары деңгейі. Бұл проблемамен күресу үшін болды . Бұл түйіндердегі қысымды алып тастады және түйіндердің түйінге тым көп қысым жасамайтын өмірлік циклін қамтамасыз етті. Енді біз қажет болған жағдайда оларды реттей отырып, жомарт (және бірдей дерлік) сұраумен және шектеу мәндерімен тасымалдауды бастаймыз.
3. Көрсеткіштер және журналдар
Инфрақұрылымдық бөлім кідірістерге, қателер жылдамдығына және орнатылғанмен қанықтылыққа назар аударады (SLO) байланысты .
Өткен жылдың ішінде инфрақұрылымдық бөлімшедегі басты оқиғалардың бірі мониторингті жақсарту және ЕҰО-мен жұмыс істеу болды. SLO бізге көшу кезінде мұқият бақыланатын жеке қызметтерге мақсаттар қоюға мүмкіндік берді. Бірақ бұл жақсартылған бақылау мүмкіндігінің өзінде метрика мен ескертулерді пайдалану арқылы ақауларды бірден көру әрқашан мүмкін емес. Мысалы, кідіріс пен қате жылдамдығына назар аудара отырып, біз тасымалдаудан өтіп жатқан қызмет үшін барлық пайдалану жағдайларын толық қамтымаймыз.
Бұл мәселе кейбір жұмыс жүктемелерін кластерге көшіргеннен кейін бірден табылды. Сұраныс саны аз, бірақ конфигурацияға өте нақты тәуелділіктері бар функцияларды тексеру қажет болғанда, бұл әсіресе өткір болды. Көші-қонның негізгі сабақтарының бірі бақылау кезінде тек көрсеткіштерді ғана емес, сонымен қатар журналдар мен «ұзын құйрықты» да ескеру қажеттілігі болды. (бұл туралы диаграммада - шамамен. аудар.) қателер. Енді әрбір тасымалдау үшін журнал сұрауларының егжей-тегжейлі тізімін қосамыз (журнал сұраулары) және проблемалар туындаған жағдайда бір ауысымнан келесі ауысымға көшіруге болатын нақты кері қайтару процедураларын жоспарлаңыз.
Ескі VM инфрақұрылымында және Кубернетес негізіндегі жаңа инфрақұрылымда бірдей сұрауларға параллель қызмет көрсету бірегей қиындық туғызды. Көтеру және ауыстыру көші-қонынан айырмашылығы (қосымшаларды жаңа инфрақұрылымға «сол қалпында» жылдам тасымалдау; қосымша мәліметтерді оқуға болады, мысалы, - шамамен. аудар.), «ескі» VM және Kubernetes бойынша параллель жұмыс бақылау құралдарының екі ортамен де үйлесімді болуын және көрсеткіштерді бір көрініске біріктіре алуын талап етеді. Өтпелі кезеңде тұрақты бақылауға қол жеткізу үшін бірдей бақылау тақталары мен журнал сұрауларын пайдалану маңызды.
4. Трафикті жаңа кластерге ауыстыру
GitLab.com үшін серверлердің бір бөлігі арналған . Canary Park біздің ішкі жобаларымызға қызмет етеді және де мүмкін . Бірақ ол ең алдымен инфрақұрылымға және қолданбаға енгізілген өзгерістерді тексеруге арналған. Бірінші көшірілген қызмет ішкі трафиктің шектеулі көлемін қабылдаудан басталды және біз бұл әдісті кластерге барлық трафикті жібермес бұрын SLO сәйкестігін қамтамасыз ету үшін пайдалануды жалғастырамыз.
Тасымалдау жағдайында бұл ішкі жобаларға сұраулар алдымен Kubernetes-ке жіберілетінін білдіреді, содан кейін біз HAProxy арқылы сервердің салмағын өзгерту арқылы трафиктің қалған бөлігін біртіндеп кластерге ауыстырамыз. VM-ден Кубернетеске көшу кезінде ескі және жаңа инфрақұрылым арасындағы трафикті қайта бағыттаудың оңай жолы болғаны және сәйкесінше ескі инфрақұрылымды көшіруден кейінгі алғашқы бірнеше күнде кері қайтаруға дайын ұстау өте тиімді екені белгілі болды.
5. Бұршақтардың резервтік қуаттары және оларды пайдалану
Бірден дерлік келесі мәселе анықталды: Тіркеу қызметіне арналған бөлімшелер жылдам іске қосылды, бірақ Sidekiq үшін подкасттарды іске қосу . Біз жұмыстарды жылдам өңдеуді және жылдам масштабтауды қажет ететін жұмысшылар үшін жұмыс жүктемелерін Kubernetes-ке көшіруді бастағанда Sidekiq подкасттарын іске қосудың ұзақ уақыты мәселе болды.
Бұл жағдайда сабақ Kubernetes's' Horizontal Pod Autoscaler (HPA) трафиктің өсуін жақсы басқарғанымен, жұмыс жүктемелерінің сипаттамаларын ескеру және подводтарға бос сыйымдылықты бөлу маңызды (әсіресе сұраныс біркелкі бөлінген кезде). Біздің жағдайда жұмыс орындарының кенеттен өсуі болды, бұл жылдам масштабтауға әкелді, бұл түйін пулын масштабтауға уақыт болмай тұрып CPU ресурстарының қанығуына әкелді.
Әрқашан кластерден мүмкіндігінше сығуға азғырылады, дегенмен, бастапқыда өнімділік мәселелеріне тап болғаннан кейін, біз қазір жомарт pod бюджетінен бастап, оны кейінірек азайтып, SLO-ларды мұқият қадағалаймыз. Sidekiq қызметіне арналған қосқыштарды іске қосу айтарлықтай жылдамдады және қазір орта есеппен шамамен 40 секундты алады. GitLab.com сайтында да, GitLab Helm ресми диаграммасымен жұмыс істейтін өзін-өзі басқаратын қондырғыларды пайдаланушыларымыз да жеңіске жетті.
қорытынды
Әрбір қызметті көшіргеннен кейін біз Kubernetes-ті өндірісте пайдаланудың артықшылықтарына қуандық: қолданбаны жылдамырақ және қауіпсіз орналастыру, масштабтау және ресурстарды тиімдірек бөлу. Сонымен қатар, көші-қонның артықшылықтары GitLab.com қызметінен асып түседі. Ресми Helm диаграммасының әрбір жақсаруы оның пайдаланушыларына пайда әкеледі.
Сізге біздің Кубернетес көші-қон оқиғаларының тарихы ұнады деп үміттенемін. Біз барлық жаңа қызметтерді кластерге көшіруді жалғастырамыз. Қосымша ақпаратты келесі басылымдардан табуға болады:
- ««;
- ««;
- .
Аудармашыдан PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com