Нашите констатации от година на мигриране на GitLab.com към Kubernetes

Забележка. превод: Възприемането на Kubernetes от GitLab се счита за един от двата основни фактора, допринасящи за растежа на компанията. Въпреки това доскоро инфраструктурата на онлайн услугата GitLab.com беше изградена върху виртуални машини и едва преди около година започна нейната миграция към K8s, която все още не е завършена. Радваме се да ви представим превод на скорошна статия от инженер на GitLab SRE за това как се случва това и какви заключения правят инженерите, участващи в проекта.

Вече около година нашето инфраструктурно подразделение мигрира всички услуги, работещи на GitLab.com, към Kubernetes. През това време се сблъскахме с предизвикателства не само с преместването на услуги към Kubernetes, но и с управлението на хибридни внедрявания по време на прехода. Ценните уроци, които научихме, ще бъдат обсъдени в тази статия.

От началото на GitLab.com неговите сървъри работят в облака във виртуални машини. Тези виртуални машини се управляват от Chef и се инсталират с помощта на нашия официален linux пакет. Стратегия за внедряване в случай, че приложението трябва да бъде актуализирано, е просто да актуализирате сървърния парк по координиран последователен начин, като използвате CI тръбопровода. Този метод, макар и бавен и малко тъп - гарантира, че GitLab.com използва същите методи за инсталиране и конфигуриране като самостоятелни потребители (самоуправляващ се) Инсталации на GitLab, използващи нашите Linux пакети за това.

Ние използваме този метод, защото е изключително важно да изпитате болката и радостта, през които преминава средностатистическият член на общността, когато инсталира и конфигурира своите копия на GitLab. Този подход работеше добре известно време, но когато броят на проектите в GitLab надхвърли 10 милиона, осъзнахме, че той вече не отговаря на нашите нужди от мащабиране и внедряване.

Първи стъпки към Kubernetes и родния за облак GitLab

Проектът е създаден през 2017 г Графики на GitLab да подготви GitLab за внедряване в облака и да позволи на потребителите да инсталират GitLab на клъстери на Kubernetes. Тогава знаехме, че мигрирането на GitLab към Kubernetes ще увеличи скалируемостта на платформата SaaS, ще опрости внедряването и ще подобри изчислителната ефективност. В същото време много функции на нашето приложение зависеха от монтирани NFS дялове, което забави прехода от виртуални машини.

Фокусът върху родния облак и Kubernetes позволи на нашите инженери да планират постепенен преход, по време на който премахнахме някои от NAS зависимостите на приложението, като същевременно продължихме да разработваме нови функции по пътя. Откакто започнахме да планираме нашата миграция през лятото на 2019 г., много от тези ограничения бяха премахнати и процесът на мигриране на GitLab.com към Kubernetes вече е в ход!

Характеристики на GitLab.com в Kubernetes

За GitLab.com използваме единичен регионален GKE клъстер, който обработва целия трафик на приложения. За да минимизираме сложността на една (вече трудна) миграция, ние се фокусираме върху услуги, които не разчитат на локално хранилище или NFS. GitLab.com използва предимно монолитна кодова база на Rails и ние маршрутизираме трафик въз основа на характеристиките на работното натоварване към различни крайни точки, изолирани в техните собствени пулове от възли.

В случая на интерфейса тези типове са разделени на заявки към мрежата, API, Git SSH/HTTPS и регистър. В случая на бекенда, ние разделяме заданията в опашката според различни характеристики, в зависимост от предварително определени граници на ресурсите, които ни позволяват да задаваме цели на ниво на обслужване (SLO) за различни натоварвания.

Всички тези услуги на GitLab.com са конфигурирани с немодифицирана диаграма GitLab Helm. Конфигурирането се извършва в поддиаграми, които могат да бъдат избирателно активирани, докато постепенно мигрираме услуги към клъстера. Дори с решението да не включваме някои от нашите услуги със състояние като Redis, Postgres, GitLab Pages и Gitaly в миграцията, използването на Kubernetes ни позволява да намалим драстично броя на виртуалните машини, управлявани в момента от Chef.

Прозрачност и управление на конфигурацията на Kubernetes

Всички настройки се управляват от самия GitLab. За това се използват три конфигурационни проекта, базирани на Terraform и Helm. Опитваме се да използваме самия GitLab, когато е възможно, за да стартираме GitLab, но за оперативни задачи имаме отделна инсталация на GitLab. Това е необходимо, за да не зависи от наличността на GitLab.com при извършване на внедрявания и актуализации на GitLab.com.

Въпреки че нашите тръбопроводи за клъстера Kubernetes работят на отделна инсталация на GitLab, има огледални копия на хранилищата на кодове, публично достъпни на следните адреси:

• k8s-workloads/gitlab-com — Обвързване на конфигурацията на GitLab.com за GitLab Helm-диаграма;
• k8s-workloads/gitlab-helmfiles - съдържа конфигурации за услуги, които не са пряко свързани с приложението GitLab. Те включват конфигурации за регистриране и наблюдение на клъстери, както и интегрирани инструменти като PlantUML;
• gitlab-com-инфраструктура - Конфигурация на Terraform за Kubernetes и наследена VM инфраструктура. Тук конфигурирате всички ресурси, необходими за стартиране на клъстера, включително самия клъстер, пулове от възли, акаунти за услуги, резервиране на IP адрес.

Когато се направят промени, се показва публичният изглед. кратко обобщение с връзка към подробна разлика, която SRE анализира, преди да направи промени в клъстера.

За SRE връзката води до подробна разлика в инсталацията на GitLab, която се използва за производство и достъпът до която е ограничен. Това позволява на служителите и общността без достъп до оперативния дизайн (който е отворен само за SRE) да преглеждат предложените промени в конфигурацията. Чрез комбиниране на публичен екземпляр на GitLab за код с частен екземпляр за CI тръбопроводи, ние поддържаме един работен поток, като същевременно гарантираме независимост от GitLab.com за актуализации на конфигурацията.

Какво научихме по време на миграцията

По време на преместването беше натрупан опит, който прилагаме към нови миграции и внедрявания в Kubernetes.

1. Повишени разходи поради трафика между зоните на достъпност

Ежедневна статистика за излизане (байтове на ден) за парка за съхранение на Git на GitLab.com

Google разделя мрежата си на региони. Те от своя страна са разделени на зони на достъпност (AZ). Git хостингът е свързан с големи количества данни, така че за нас е важно да контролираме излизането от мрежата. В случай на вътрешен трафик излизането е безплатно само ако остане в границите на една зона на достъпност. Към момента на писане на това, ние раздаваме приблизително 100TB данни на типичен работен ден (и това е само за Git хранилища). Услугите, които бяха в едни и същи виртуални машини в нашата стара VM-базирана топология, сега се изпълняват в различни Kubernetes pods. Това означава, че част от трафика, който преди е бил локален за VM, потенциално може да излезе извън зоните на достъпност.

Регионалните GKE клъстери ви позволяват да обхванете множество зони на наличност за резервиране. Обмисляме възможността разделете регионалния клъстер на GKE на еднозонови клъстери за услуги, които генерират големи количества трафик. Това ще намали разходите за излизане, като същевременно поддържа излишък на ниво клъстер.

2. Ограничения, заявки за ресурси и мащабиране

Броят реплики, обработващи производствен трафик към registry.gitlab.com. Пик на трафика в ~15:00 UTC.

Нашата история за миграция започна през август 2019 г., когато мигрирахме първата услуга, GitLab Container Registry, към Kubernetes. Тази критично важна за мисията услуга с голям трафик беше подходяща за първата миграция, защото е приложение без състояние с малко външни зависимости. Първият проблем, който срещнахме, беше голям брой подове, които бяха изтласкани поради липса на памет на възлите. Поради това трябваше да променим заявките и лимитите.

Беше установено, че в случай на приложение, чието потребление на памет нараства с течение на времето, ниските стойности за заявки (запазване на памет за всяка капсула), съчетано с „щедър“ твърд лимит за използване, водят до насищане (насищане) възли и високо ниво на измествания. За да се справи с този проблем, беше беше решено да се увеличат заявките и да се намалят лимитите. Това премахна натиска върху възлите и осигури жизнен цикъл на под, който не оказва прекалено голям натиск върху възела. Сега започваме миграции с щедри (и почти идентични) заявки и гранични стойности, като ги коригираме според нуждите.

3. Метрики и дневници

Отделът за инфраструктура се фокусира върху латентността, процента на грешки и насищането с установени цели за ниво на обслужване (SLO), свързан с цялостна наличност на нашата система.

През изминалата година едно от ключовите развития в инфраструктурния отдел бяха подобренията в наблюдението и работата със SLO. SLO ни позволиха да зададем цели за отделни услуги, които наблюдавахме внимателно по време на миграцията. Но дори и с тази подобрена видимост, не винаги е възможно незабавно да видите проблеми с помощта на показатели и сигнали. Например, като се съсредоточаваме върху забавянето и процентите на грешки, ние не покриваме напълно всички случаи на употреба за услуга, която се мигрира.

Този проблем беше открит почти веднага след преместването на някои от натоварванията към клъстера. Тя се прояви особено остро, когато трябваше да проверяваме функции, към които броят на заявките е малък, но които имат много специфични зависимости от конфигурацията. Един от ключовите поуки от миграцията беше необходимостта да се вземат под внимание при наблюдението не само на показателите, но и на регистрационните файлове и „дългата опашка“ (става дума за такова разпределение на графиката - прибл. превод) грешки. Сега за всяка миграция включваме подробен списък със заявки към регистрационните файлове (регистрационни заявки) и ние планираме ясни процедури за връщане назад, които могат да бъдат прехвърлени от една смяна на друга в случай на проблеми.

Обслужването на едни и същи заявки паралелно на старата VM инфраструктура и новата, базирана на Kubernetes, беше уникално предизвикателство. За разлика от миграцията с повдигане и смяна (бързо прехвърляне на приложения „както са“ към нова инфраструктура; за повече подробности вижте напр. тук - прибл. превод), паралелната работа на „стари“ виртуални машини и Kubernetes изисква инструментите за наблюдение да са съвместими с двете среди и да могат да комбинират показатели в един изглед. Важно е да използваме едни и същи табла за управление и заявки за регистрационни файлове, за да постигнем последователна видимост по време на преходния период.

4. Превключване на трафика към новия клъстер

За GitLab.com някои от сървърите са разпределени под стадий на канарче. Canary Park обслужва нашите вътрешни проекти и може също разрешени от потребителите. Но той е предназначен основно за тестване на промени в инфраструктурата и приложението. Първата мигрирана услуга стартира с приемане на ограничено количество вътрешен трафик и ние продължаваме да използваме този метод, за да гарантираме, че SLO е изпълнено, преди да изпратим целия трафик към клъстера.

В случай на миграция това означава, че първите заявки към вътрешни проекти се изпращат до Kubernetes и след това постепенно превключваме останалия трафик към клъстера, като променяме теглото за бекенда чрез HAProxy. По време на прехода от VM към Kubernetes стана ясно, че е много полезно да имате лесен начин за пренасочване на трафика между старата и новата инфраструктура и съответно да поддържате старата инфраструктура готова за връщане през първите няколко дни след миграцията.

5. Резервна мощност на шушулките и тяхното използване

Почти веднага беше идентифициран следният проблем: pods за услугата Registry стартираха бързо, но стартирането на pods за Sidekiq отне до две минути. Дълго работещите модули на Sidekiq се превърнаха в проблем, когато започнахме да мигрираме работните натоварвания към Kubernetes за работници, които трябва бързо да обработват задачи и да се мащабират бързо.

В този случай урокът беше, че докато Horizontal Pod Autoscaler (HPA) в Kubernetes се справя добре с нарастването на трафика, важно е да се вземат предвид характеристиките на натоварването и да се разпредели резервен капацитет на pod (особено когато търсенето е неравномерно). В нашия случай имаше внезапен взрив от задания, което доведе до бързо мащабиране, което доведе до насищане на ресурсите на процесора, преди да можем да мащабираме пула от възли.

Винаги е изкушаващо да изтръгнем възможно най-много от един клъстер, но първоначално се натъкнахме на проблеми с производителността и сега започваме с щедър бюджет за под и го намаляваме по-късно, следейки внимателно SLO. Стартирането на пакети за услугата Sidekiq е значително ускорено и сега отнема средно около 40 секунди. От намаляване на времето за стартиране на pod спечели както GitLab.com, така и нашите потребители на самоуправлявани инсталации, работещи с официалната GitLab Helm Chart.

Заключение

След мигрирането на всяка услуга се зарадвахме на предимствата от използването на Kubernetes в производството: по-бързо и по-безопасно внедряване на приложения, мащабиране и по-ефективно разпределение на ресурсите. Освен това предимствата на миграцията надхвърлят услугата GitLab.com. С всяко подобрение на официалната Helm Chart, нейните потребители също се възползват.

Надявам се, че сте харесали историята на нашето миграционно приключение на Kubernetes. Продължаваме да мигрираме всички нови услуги към клъстера. Допълнителна информация можете да намерите в следните публикации:

• «Защо мигрираме към Kubernetes?»;
• «GitLab.com на Kubernetes»;
• Епоха за мигрирането на GitLab.com към Kubernetes.

PS от преводача

Прочетете също в нашия блог:

• «3 години с Kubernetes в производство: ето какво разбрахме»;
• «10 често срещани грешки в Kubernetes»;
• «Истории на успеха на Kubernetes в производството. Част 3: GitHub»;
• «Преходът на Tinder към Kubernetes".

Източник: www.habr.com