Тиндер сели у Кубернетес

Написао: Цхрис О'Бриен, инжењерски менаџер | Цхрис Тхомас, инжењерски менаџер | Јинионг Лее, старији софтверски инжењер | Уредио: Цоопер Јацксон, софтвер инжењер

Зашто

Пре скоро две године, Тиндер је одлучио да своју платформу пресели у Кубернетес. Кубернетес нам је пружио прилику да Тиндер Енгинееринг кренемо ка контејнеризацији и раду са малим додиром кроз непромењиву примену. Изградња, имплементација и инфраструктура апликација биће дефинисани као код.

Такође смо желели да одговоримо на изазове размера и стабилности. Када је скалирање постало критично, често смо патили од неколико минута чекања да се нови ЕЦ2 примери појаве на мрежи. Идеја о распореду контејнера и опслуживању саобраћаја у року од неколико секунди, за разлику од минута, била нам је привлачна.

Није било лако. Током наше миграције почетком 2019. године, достигли смо критичну масу унутар нашег Кубернетес кластера и почели смо да се сусрећемо са различитим изазовима због обима саобраћаја, величине кластера и ДНС-а. Решили смо занимљиве изазове да мигрирамо 200 услуга и покренемо Кубернетес кластер у скали од укупно 1.000 чворова, 15.000 махуна и 48.000 контејнера.

како

Од јануара 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 уносом табеле руте, 1 уносом АРП табеле (на фланнел.1 сучељу) и 1 уносом базе података прослеђивања (ФДБ). Они се додају када се први чвор покреће или када се открије сваки нови чвор.

Поред тога, комуникација чвор-до-под (или под-до-под) комуникација на крају тече преко етх0 интерфејса (приказаног на Фланнеловом дијаграму горе). То ће резултирати додатним уносом у АРП табели за сваки одговарајући извор чвора и одредишта чвора.

У нашем окружењу је ова врста комуникације веома честа. За наше Кубернетес сервисне објекте креира се ЕЛБ и Кубернетес региструје сваки чвор са ЕЛБ. ЕЛБ није свјестан да одабрани чвор можда није крајње одредиште пакета. То је зато што кад чвор прими пакет од ЕЛБ-а, он процењује своја правила иптаблес за услугу и насумично бира под на другом чвору.

У тренутку прекида рада, у кластеру је било 605 укупних чворова. Из горе наведених разлога, ово је било довољно за помрачење задате вредности гц_тхресх3. Када се то догоди, не само да се пакети одбацују, већ и цео Фланнел / 24с виртуалног адресног простора недостаје из АРП табеле. Комуникација чвора до под и ДНС претраге нису успјели. (ДНС је домаћин унутар кластера, као што ће бити детаљније објашњено у овом чланку.)

Да би се решили, вредности гц_тхресх1, гц_тхресх2 и гц_тхресх3 су повишене и Фланнел се мора поново покренути да би се поново регистровала мрежа која недостаје.

Неочекивано покреће ДНС на скали

Да бисмо се прилагодили нашој миграцији, снажно смо користили ДНС да бисмо олакшали обликовање саобраћаја и инкрементални пресек од заостављених до Кубернетеса за наше услуге. Постављали смо релативно ниске вредности ТТЛ-а на придружени Роуте53 РецордСетс. Кад смо покренули своју наслијеђену инфраструктуру на ЕЦ2 примјерима, наша конфигурација резолуције указала је на Амазонов ДНС. То смо схватили здраво за готово и трошкови релативно ниског ТТЛ-а за наше услуге и Амазонове услуге (нпр. ДинамоДБ) остали су углавном незапажени.

Како смо се укрцали на све више и више услуга Кубернетесу, нашли смо се да покрећемо ДНС услугу која је одговарала на 250.000 захтева у секунди. Наилазили смо на повремене и импресивне истекне ДНС претраживања унутар наших апликација. До тога је дошло упркос напорном подешавању и преласку ДНС провајдера на ЦореДНС имплементацију која је у једном тренутку достигла 1.000 махуна конзумирајући 120 језгара.

Док смо истраживали друге могуће узроке и решења, пронашли смо чланак који описује стање трке који утиче на Линук филтрирање оквира пакета нетфилтер. Времена за приказ ДНС-а који смо видели, заједно са повећаним бројачем инсерт_фаилед на Фланнел интерфејсу, усклађен с налазима чланка.

До овог проблема долази током превођења адресе изворне и одредишне мреже (СНАТ и ДНАТ) и накнадног уметања у табелу за враћање. Једно решење о коме се интерно разговарало и које је заједница предложила је премештање ДНС-а на раднички чвор. У овом случају:

  • СНАТ није потребан, јер саобраћај остаје локално на чвору. Не мора да се преноси преко етх0 интерфејса.
  • ДНАТ није потребан јер је одредишни ИП локални чвор, а није насумично одабран под за правила иптаблес.

Одлучили смо да напредујемо овим приступом. ЦореДНС је распоређен као ДаемонСет у Кубернетесу и убризгали смо локални ДНС послужитељ чвора у сваки под Ресол.цонф под конфигурацијом конфигурације кубелет - цлустер-днс. Решавање је било ефикасно за ДНС-ове истекле.

Међутим, и даље видимо одбачене пакете и прираст бројача бројача инсерт_фаилед интерфејса. Ово ће се наставити и након горе наведеног напретка, јер смо само избегли СНАТ и / или ДНАТ за ДНС саобраћај. Стање трке ће и даље постојати за друге врсте саобраћаја. Срећом, већина наших пакета је ТЦП и када се стање догоди, пакети ће се успешно поново послати. Дугорочно исправљање свих врста саобраћаја је нешто о чему још увек расправљамо.

Коришћење изасланика за постизање бољег уравнотежења оптерећења

Док смо мигрантске услуге пребацили на Кубернетес, почели смо да патимо од неуравнотеженог оптерећења преко махуна. Открили смо да се захваљујући ХТТП Кеепаливе, ЕЛБ везе задржале на првим спремним махунама сваке имплементације, тако да је већина саобраћаја текла кроз мали проценат доступних махуна. Једно од првих ублажавања које смо покушали било је коришћење 100% МакСургеа на новим размештањима за најгоре прекршитеље. Ово је било незнатно ефикасно и дугорочно одрживо уз неке од већих примена.

Друго ублажавање које смо користили било је да вештачки повећамо захтеве за ресурсима на критичним услугама како би обојене махуне имале више простора поред осталих тешких махуна. Ово такође неће дугорочно бити исплативо због расипања ресурса, а наше Ноде апликације су једноструке и на тај начин су ефективно ограничене на 1 језгро. Једино јасно решење било је коришћење бољег балансирања оптерећења.

Интерно смо желели да проценимо изасланика. То нам је пружило шансу да је уведемо на врло ограничен начин и да добијемо непосредне користи. Изасланик је отворени извор, високо-перформансни проки Лаиер 7 дизајниран за велике сервисно оријентисане архитектуре. У стању је да примењује напредне технике балансирања оптерећења, укључујући аутоматска покушаја, прекид кола и ограничење глобалне брзине.

Конфигурација коју смо смислили била је да има бочни аутомобил Енвои-а уз сваки под који је имао једну руту и ​​грозд да би погодио локални прикључак за контејнере. Да бисмо умањили потенцијал каскадне и задржали мали радијус експлозије, користили смо флоту предњих проки-ова Енвои-ових махуна, једно размештање у свакој зони доступности (АЗ) за сваку услугу. Ови су погодили мали механизам за откривање сервиса који је један од наших инжењера саставио, а који су једноставно вратили листу махуна у сваком АЗ-у за одређену услугу.

Предњи сервисни изасланици су затим користили овај механизам за откривање услуге једним кластером и смером узводно. Конфигурисали смо разумне временске прекиде, појачали сва подешавања прекидача, а затим унели минималну конфигурацију за покушај да помогнемо при пролазним кваровима и неометаним размештањима. Сваку од ових услуга предстојећих изасланика смо успоставили са ТЦП ЕЛБ-ом. Чак и ако се маепаливе из нашег главног предњег проки слоја закачио на одређене махуне Енвои-а, они су много боље могли да подносе оптерећење и били су конфигурисани да уравнотежују путем најмање_ Захтева до повратног рачуна.

За примене смо користили преСтоп куку и на апликацији и на бочној носачу. Ова кука названа бочна контрола здравственог прегледа возила не ради, уз мало спавања, како би се мало времена омогућило да се везе за лет заврше и испразне.

Један од разлога зашто смо се успели тако брзо кретати био је због богатих метрика које смо били у стању лако интегрисати са нашим уобичајеним Прометејевим подешавањем. То нам је омогућило да тачно видимо шта се догађа док смо понављали поставке конфигурације и смањили промет.

Резултати су били непосредни и очигледни. Почели смо с најнебалансиранијим сервисима и у овом тренутку смо га покренули испред дванаест најважнијих сервиса у нашем кластеру. Ове године планирамо да пређемо на мрежу са потпуном услугом, са напреднијим откривањем сервиса, прекидом кола, детекцијом вањске слике, ограничавањем брзине и праћењем.

Слика 3–1 конвергенција ЦПУ-а једне услуге током резања посланика

Крајњи резултат

Кроз ова учења и додатна истраживања развили смо снажан интерни инфраструктурни тим са великим познавањем начина дизајнирања, распоређивања и управљања великим кластерима Кубернетес-а. Цела инжењерска организација компаније Тиндер сада има знање и искуство у вези са контејнерисањем и распоређивањем њихових апликација на Кубернетес.

На нашој заостављеној инфраструктури, када је била потребна додатна скала, често смо патили од неколико минута чекања да се нови ЕЦ2 примери појаве на мрежи. Контејнери сада планирају и служе саобраћају у року од неколико секунди, за разлику од минута. Заказивање више спремника на једној ЕЦ2 инстанци такође омогућава побољшану хоризонталну густину. Као резултат, пројицирамо знатне уштеде трошкова на ЕЦ2 у 2019. у односу на претходну годину.

Прошле су готово две године, али смо миграцију довршили у марту 2019. Тиндер платформа ради искључиво на Кубернетес кластеру који се састоји од 200 сервиса, 1.000 чворова, 15.000 махуна и 48.000 контејнера. Инфраструктура више није задатак резервиран за наше оперативне тимове. Уместо тога, инжењери у целој организацији деле ову одговорност и имају контролу над начином на који су њихове апликације изграђене и распоређене са свиме као кодом.