Белешка. трансл.: Запослени у светски познатом сервису Тиндер недавно су поделили неке техничке детаље миграције своје инфраструктуре на Кубернетес. Процес је трајао скоро две године и резултирао је лансирањем платформе веома великих размера на К8с, која се састоји од 200 сервиса смештених на 48 хиљада контејнера. На које занимљиве потешкоће су наишли Тиндер инжењери и до којих су резултата дошли? Прочитајте овај превод.
Зашто?
Пре скоро две године, Тиндер је одлучио да премести своју платформу на Кубернетес. Кубернетес би омогућио Тиндер тиму да се контејнеризује и пређе на производњу уз минималан напор кроз непроменљиву примену (непроменљиво постављање). У овом случају, склапање апликација, њихово постављање и сама инфраструктура били би јединствено дефинисани кодом.
Такође смо тражили решење за проблем скалабилности и стабилности. Када је скалирање постало критично, често смо морали да чекамо неколико минута да се покрену нове ЕЦ2 инстанце. Идеја о покретању контејнера и покретању саобраћаја за неколико секунди уместо минута постала нам је веома привлачна.
Испоставило се да је процес тежак. Током наше миграције почетком 2019. године, Кубернетес кластер је достигао критичну масу и почели смо да се сусрећемо са разним проблемима због обима саобраћаја, величине кластера и ДНС-а. Успут смо решили много занимљивих проблема везаних за миграцију 200 сервиса и одржавање Кубернетес кластера који се састоји од 1000 чворова, 15000 48000 подова и XNUMX XNUMX активних контејнера.
Како?
Од јануара 2018. године прошли смо кроз различите фазе миграције. Почели смо тако што смо спремили све наше услуге у контејнер и применили их у Кубернетес тестна окружења у облаку. Почевши од октобра, почели смо методично да мигрирамо све постојеће услуге на Кубернетес. До марта следеће године смо завршили миграцију и сада Тиндер платформа ради искључиво на Кубернетесу.
Прављење слика за Кубернетес
Имамо преко 30 спремишта изворног кода за микросервисе који раде на Кубернетес кластеру. Код у овим репозиторијумима је написан на различитим језицима (на пример, Ноде.јс, Јава, Сцала, Го) са више окружења за извршавање за исти језик.
Систем изградње је дизајниран да обезбеди потпуно прилагодљив „контекст изградње“ за сваку микроуслугу. Обично се састоји од Доцкерфиле-а и листе команди љуске. Њихов садржај је потпуно прилагодљив, а у исто време, сви ови контексти изградње су написани према стандардизованом формату. Стандардизовање контекста изградње омогућава да један систем за изградњу рукује свим микросервисима.
Слика 1-1. Стандардизовани процес изградње преко Буилдер контејнера
Да бисте постигли максималну доследност између времена извршавања (окружења за извршавање) исти процес изградње се користи током развоја и тестирања. Суочили смо се са веома интересантним изазовом: морали смо да развијемо начин да обезбедимо конзистентност окружења за изградњу на целој платформи. Да би се то постигло, сви процеси монтаже се изводе унутар посебног контејнера. Градитељ.
Његова имплементација контејнера захтевала је напредне Доцкер технике. Буилдер наслеђује ИД локалног корисника и тајне (као што су ССХ кључ, АВС акредитиви, итд.) потребне за приступ приватним Тиндер репозиторијумима. Он монтира локалне директоријуме који садрже изворе за природно складиштење артефаката изградње. Овај приступ побољшава перформансе јер елиминише потребу за копирањем артефаката изградње између контејнера Буилдер-а и хоста. Похрањени артефакти израде могу се поново користити без додатне конфигурације.
За неке услуге, морали смо да креирамо други контејнер да мапирамо окружење за компилацију у окружење за извршавање (на пример, библиотека Ноде.јс бцрипт генерише бинарне артефакте специфичне за платформу током инсталације). Током процеса компилације, захтеви могу да варирају између услуга, а коначни Доцкерфиле се компајлира у ходу.
Архитектура и миграција Кубернетес кластера
Управљање величином кластера
Одлучили смо да користимо кубе-авс за аутоматску примену кластера на Амазон ЕЦ2 инстанцама. На самом почетку, све је функционисало у једном заједничком пулу чворова. Брзо смо схватили потребу да одвојимо радна оптерећења према величини и типу инстанце да бисмо ефикасније користили ресурсе. Логика је била да се испоставило да је покретање неколико учитаних вишенитних подова предвидљивије у смислу перформанси од њиховог коегзистенције са великим бројем једнонитних подова.
На крају смо се одлучили на:
- м5.4кларге — за праћење (Прометеј);
- ц5.4кларге - за Ноде.јс радно оптерећење (сингле-тхреадед ворклоад);
- ц5.2кларге - за Јава анд Го (вишенитно радно оптерећење);
- ц5.4кларге — за контролну таблу (3 чвора).
Миграција
Један од припремних корака за миграцију са старе инфраструктуре на Кубернетес био је преусмеравање постојеће директне комуникације између услуга на нове балансере оптерећења (Еластиц Лоад Баланцерс (ЕЛБ). Направљени су на одређеној подмрежи виртуелног приватног облака (ВПЦ). Ова подмрежа је била повезана на Кубернетес ВПЦ. Ово нам је омогућило да постепено мигрирамо модуле, не узимајући у обзир специфичан редослед зависности услуга.
Ове крајње тачке су креиране коришћењем пондерисаних скупова ДНС записа који су имали ЦНАМЕ-ове који указују на сваки нови ЕЛБ. Да бисмо се пребацили, додали смо нови унос који указује на нови ЕЛБ Кубернетес услуге са тежином од 0. Затим смо поставили Тиме То Ливе (ТТЛ) уноса постављеног на 0. Након тога, стари и нови пондери су били полако прилагођавао, и на крају је 100% оптерећења послато на нови сервер. Након што је пребацивање завршено, ТТЛ вредност се вратила на адекватнији ниво.
Јава модули које смо имали могли су да се носе са ниским ТТЛ ДНС-ом, али апликације Ноде нису могле. Један од инжењера је поново написао део кода скупа веза и умотао га у менаџер који је ажурирао скупове сваких 60 секунди. Одабрани приступ је функционисао веома добро и без икакве приметне деградације перформанси.
Лекције
Границе мрежног ткива
У рано јутро 8. јануара 2019. године платформа Тиндер се неочекивано срушила. Као одговор на неповезано повећање кашњења платформе раније тог јутра, повећао се број подова и чворова у кластеру. Ово је довело до исцрпљивања АРП кеша на свим нашим чворовима.
Постоје три Линук опције везане за АРП кеш:
()
гц_тхресх3 - ово је тврда граница. Појава уноса „преклапања суседне табеле“ у дневнику значила је да чак и након синхроног сакупљања смећа (ГЦ), није било довољно простора у АРП кешу за складиштење суседног уноса. У овом случају, кернел је једноставно потпуно одбацио пакет.
Користимо као мрежно ткиво у Кубернетесу. Пакети се преносе преко ВКСЛАН-а. ВКСЛАН је Л2 тунел подигнут на врху Л3 мреже. Технологија користи МАЦ-ин-УДП (МАЦ Аддресс-ин-Усер Датаграм Протоцол) енкапсулацију и омогућава проширење сегмената мреже Лаиер 2. Транспортни протокол на мрежи физичког центра података је ИП плус УДП.
Слика 2–1. фланел дијаграм ()
Слика 2-2. ВКСЛАН пакет ()
Сваки Кубернетес радни чвор додељује виртуелни адресни простор са /24 маском из већег /9 блока. За сваки чвор ово је један унос у табели рутирања, један унос у АРП табели (на интерфејсу фланел.1) и један унос у табели пребацивања (ФДБ). Додају се када се први пут покрене радни чвор или сваки пут када се открије нови чвор.
Поред тога, комуникација чвор-под (или под-под) на крају иде кроз интерфејс етхКСНУМКС (као што је приказано на дијаграму фланела изнад). Ово резултира додатним уносом у АРП табели за сваки одговарајући изворни и одредишни хост.
У нашем окружењу овај вид комуникације је веома чест. За објекте услуге у Кубернетес-у, креира се ЕЛБ и Кубернетес региструје сваки чвор са ЕЛБ-ом. ЕЛБ не зна ништа о подовима и изабрани чвор можда није коначно одредиште пакета. Поента је да када чвор прими пакет од ЕЛБ-а, он то сматра узимајући у обзир правила iptables за одређену услугу и насумично бира под на другом чвору.
У тренутку квара, у кластеру је било 605 чворова. Из горе наведених разлога, ово је било довољно да се превазиђе значај гц_тхресх3, што је подразумевано. Када се то деси, не само да пакети почињу да се испуштају, већ цео Фланнел виртуелни адресни простор са маском /24 нестаје из АРП табеле. Комуникација чвора-под и ДНС упити су прекинути (ДНС се налази у кластеру; прочитајте касније у овом чланку за детаље).
Да бисте решили овај проблем, потребно је да повећате вредности гц_тхресх1, гц_тхресх2 и гц_тхресх3 и поново покрените Фланнел да бисте поново регистровали недостајуће мреже.
Неочекивано ДНС скалирање
Током процеса миграције, активно смо користили ДНС за управљање саобраћајем и постепени пренос услуга са старе инфраструктуре на Кубернетес. Поставили смо релативно ниске ТТЛ вредности за повезане скупове записа у Роуте53. Када је стара инфраструктура радила на ЕЦ2 инстанцама, наша конфигурација резолвера је указивала на Амазон ДНС. Узели смо ово здраво за готово и утицај ниског ТТЛ-а на наше услуге и Амазонове услуге (као што је ДинамоДБ) остао је углавном непримећен.
Док смо мигрирали услуге на Кубернетес, открили смо да ДНС обрађује 250 хиљада захтева у секунди. Као резултат тога, апликације су почеле да доживљавају стална и озбиљна временска ограничења за ДНС упите. Ово се десило упркос невероватним напорима да се оптимизује и пребаци ДНС провајдер на ЦореДНС (који је при врхунском оптерећењу достигао 1000 подова који раде на 120 језгара).
Истражујући друге могуће узроке и решења, открили смо , који описује услове трке који утичу на оквир за филтрирање пакета нетфилтер у Линуку. Тајм-аути које смо приметили, заједно са све већим бројачем инсерт_фаилед у интерфејсу Фланнел били су у складу са налазима чланка.
Проблем се јавља у фази превода изворне и одредишне мрежне адресе (СНАТ и ДНАТ) и накнадног уноса у табелу цоннтрацк. Једно од рјешења о којима се интерно расправљало и које је заједница предложила било је премјештање ДНС-а на сам радни чвор. У овом случају:
- СНАТ није потребан јер саобраћај остаје унутар чвора. Не мора да се усмерава кроз интерфејс етхКСНУМКС.
- ДНАТ није потребан јер је одредишна ИП адреса локална за чвор, а не насумично одабрана подна у складу са правилима iptables.
Одлучили смо да се држимо овог приступа. ЦореДНС је распоређен као ДаемонСет у Кубернетес-у и имплементирали смо ДНС сервер локалног чвора у ресолв.цонф сваки под постављањем заставице --цлустер-днс команде кубелет . Испоставило се да је ово решење делотворно за ДНС временска ограничења.
Међутим, и даље смо видели губитак пакета и повећање бројача инсерт_фаилед у интерфејсу Фланнел. Ово се наставило након што је заобилазно решење имплементирано јер смо успели да елиминишемо СНАТ и/или ДНАТ само за ДНС саобраћај. Услови трке су очувани и за остале видове саобраћаја. На срећу, већина наших пакета је ТЦП, и ако дође до проблема они се једноставно поново преносе. Још увек покушавамо да пронађемо одговарајуће решење за све врсте саобраћаја.
Коришћење програма Енвои за боље балансирање оптерећења
Како смо мигрирали позадинске услуге на Кубернетес, почели смо да патимо од неуравнотеженог оптерећења између подова. Открили смо да је ХТТП Кеепаливе проузроковао да ЕЛБ везе закаче на првим спремним подовима сваке имплементације. Дакле, највећи део саобраћаја је прошао кроз мали проценат доступних махуна. Прво решење које смо тестирали било је подешавање МакСурге-а на 100% за нове примене за најгоре сценарије. Испоставило се да је ефекат безначајан и необећавајући у смислу већих распоређивања.
Друго решење које смо користили било је вештачко повећање захтева за ресурсима за критичне услуге. У овом случају, махуне постављене у близини имале би више простора за маневрисање у поређењу са другим тешким махунама. Ни то не би функционисало на дуге стазе јер би било губљење ресурса. Поред тога, наше Ноде апликације су биле једнонитне и, сходно томе, могле су да користе само једно језгро. Једино право решење било је коришћење бољег балансирања оптерећења.
Дуго смо желели да у потпуности ценимо . Тренутна ситуација нам је омогућила да га применимо на веома ограничен начин и добијемо тренутне резултате. Енвои је хигх-перформанце, опен-соурце, лаиер-7 проки дизајниран за велике СОА апликације. Може да имплементира напредне технике балансирања оптерећења, укључујући аутоматске поновне покушаје, прекидаче и глобално ограничавање брзине. (Белешка. трансл.: Више о овоме можете прочитати у о Истиу, који је заснован на Енвои.)
Смислили смо следећу конфигурацију: имати бочну приколицу Енвои за сваку капсулу и једну руту и повежите кластер са контејнером локално преко порта. Да бисмо минимизирали потенцијално каскадно слање и одржали мали радијус поготка, користили смо флоту Енвои фронт-проки модула, по једну по зони доступности (АЗ) за сваку услугу. Ослонили су се на једноставан механизам за откривање услуга који је написао један од наших инжењера који је једноставно вратио листу подова у сваком АЗ за дату услугу.
Предњи изасланици услуге су затим користили овај механизам за откривање услуге са једним узводним кластером и рутом. Поставили смо одговарајуће временско ограничење, повећали све поставке прекидача и додали минималну конфигурацију поновних покушаја да бисмо помогли код појединачних кварова и обезбедили несметано коришћење. Поставили смо ТЦП ЕЛБ испред сваког од ових изасланика сервиса. Чак и ако је одржавање активности са нашег главног прокси слоја заглављено на неким Енвои подовима, они су и даље могли много боље да поднесу оптерећење и били су конфигурисани да балансирају кроз минимум_рекуест у позадини.
За примену, користили смо преСтоп куку и на модулима за апликације и на бочним колицима. Закачива је покренула грешку у провери статуса крајње тачке администратора која се налази на бочном контејнеру и прешла је на неко време у стање мировања да би омогућила прекид активних веза.
Један од разлога зашто смо успели да се крећемо тако брзо је због детаљних метрика које смо могли лако да интегришемо у типичну инсталацију Прометеја. Ово нам је омогућило да видимо шта се тачно дешава док смо прилагођавали конфигурационе параметре и прерасподелили саобраћај.
Резултати су били тренутни и очигледни. Почели смо са најнеуравнотеженијим сервисима, а тренутно послује испред 12 најважнијих сервиса у кластеру. Ове године планирамо прелазак на мрежу пуне услуге са напреднијим откривањем услуга, прекидом струјног кола, откривањем одступања, ограничавањем брзине и праћењем.
Слика 3–1. ЦПУ конвергенција једне услуге током преласка на Енвои
Крајњи резултат
Кроз ово искуство и додатна истраживања, изградили смо снажан инфраструктурни тим са јаким вештинама у пројектовању, примени и управљању великим Кубернетес кластерима. Сви Тиндер инжењери сада имају знање и искуство да пакују контејнере и постављају апликације у Кубернетес.
Када се појавила потреба за додатним капацитетом на старој инфраструктури, морали смо да чекамо неколико минута да се покрену нове ЕЦ2 инстанце. Сада контејнери почињу да раде и почињу да обрађују саобраћај у року од неколико секунди уместо минута. Заказивање више контејнера на једној ЕЦ2 инстанци такође обезбеђује побољшану хоризонталну концентрацију. Као резултат тога, предвиђамо значајно смањење трошкова ЕЦ2019 у 2. у односу на прошлу годину.
Миграција је трајала скоро две године, али смо је завршили у марту 2019. Тренутно, Тиндер платформа ради искључиво на Кубернетес кластеру који се састоји од 200 услуга, 1000 чворова, 15 подова и 000 активних контејнера. Инфраструктура више није једини домен оперативних тимова. Сви наши инжењери деле ову одговорност и контролишу процес изградње и примене својих апликација само користећи код.
ПС од преводиоца
Прочитајте и серију чланака на нашем блогу:
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
Извор: ввв.хабр.цом