Тиндердің Кубернетке көшуі

Авторы: Крис О'Брайен, Инженерлік Менеджер | Крис Томас, Инженерлік Менеджер | Джинён Ли, бағдарламалық қамтамасыздандырудың аға инженері | Авторы: Купер Джексон, бағдарламалық жасақтама инженері

Неге

Шамамен екі жыл бұрын, Tinder платформасын Кубернетке ауыстыруға шешім қабылдады. Кубернетес бізге Tinder инжинирингін контейнеризация мен төмен жанасу арқылы өзгермейтін орналастыру арқылы басқаруға мүмкіндік берді. Бағдарламаны құру, орналастыру және инфрақұрылым код ретінде анықталуы мүмкін.

Біз сондай-ақ масштаб пен тұрақтылық мәселелерін шешуге ұмтылдық. Масштабтау маңызды болған кезде бізде EC2 жаңа интернеттің пайда болуын күтуге бірнеше минут уақыт кетті. Контейнерлерді бірнеше минут ішінде емес, бірнеше секунд ішінде жоспарлау және қызмет көрсету идеясы бізді қызықтырды.

Бұл оңай болған жоқ. Көші-қон кезінде 2019 жылдың басында біз Кубернетес кластеріміздегі сыни массаға жеттік және трафик көлеміне, кластердің мөлшеріне және DNS-ке байланысты түрлі қиындықтарға тап бола бастадық. Біз 200 қызметтерді көшіру бойынша қызықты міндеттерді шештік және Кубернетес кластерін 1000 масштабтағы түйіндер, 15000 дана және 48000 жұмыс істейтін контейнерлерден өткіздік.

Қалай

2018 жылдың қаңтар айынан бастап біз көші-қон әрекетінің әртүрлі кезеңдерінен өттік. Біз барлық қызметтерімізді таратып, оларды Кубернеттегі бірнеше қойылым ортасына орналастырудан бастадық. Қазан айынан бастап біз барлық мұра қызметімізді Кубернетке жібере бастадық. Келесі жылдың наурыз айында біз көшуді аяқтадық және Tinder платформасы тек Кубернетте жұмыс істейді.

Кубернетке суреттер салу

Кубернетес кластерінде жұмыс істейтін микро сервистерге арналған 30-дан астам бастапқы код репозиторийлері бар. Бұл репозиторийлердегі код әр тілде жазылған (мысалы, Node.js, Java, Scala, Go), сол тіл үшін бірнеше жұмыс уақыты бар.

Құру жүйесі әдетте Dockerfile және раковиналық командалардан тұратын әрбір микросервис үшін толықтай теңшелетін «құрастыру контексінде» жұмыс істеуге арналған. Мазмұны толығымен реттелетін болғанымен, бұл мәтінмәндер стандартталған форматқа сәйкес жазылады. Құрылымдық мәтінмәндерді стандарттау бірыңғай құрастыру жүйесіне барлық микросервистерді өңдеуге мүмкіндік береді.

Сурет 1-1. Builder контейнері арқылы стандартталған құрылыс процесі

Жұмыс уақыты ортасы арасындағы максималды сәйкестікке қол жеткізу үшін әзірлеу және сынау кезеңінде бірдей құрастыру процесі қолданылады. Біз платформада тұрақты ортаны құруға кепілдік беретін жолды құру қажет болған кезде бұл бірегей қиындықтар туғызды. Нәтижесінде барлық құрылыс процестері арнайы «Құрушы» контейнерінде орындалады.

Builder контейнерін іске қосу бірқатар жетілдірілген Docker әдістерін қажет етті. Бұл Builder контейнері жергілікті пайдаланушы идентификаторы мен құпияларды (мысалы, SSH кілті, AWS тіркелгі деректері және т.б.) Tinder жеке репозиторийлеріне кіру үшін талап етеді. Ол құрылыс артефактілерін сақтаудың табиғи тәсілі болу үшін бастапқы кодты қамтитын жергілікті каталогтарды жинақтайды. Бұл тәсіл өнімділікті жақсартады, өйткені ол Builder контейнері мен хост машинасы арасында салынған артефактілерді көшіруді болдырмайды. Сақталған артефактілер келесі жолы қайта конфигурацияланбай қайта пайдаланылады.

Белгілі бір қызметтер үшін біз құрастырушы уақыт ортасын жұмыс уақыты ортасымен сәйкестендіру үшін басқа контейнер жасауымыз керек болды (мысалы, Node.js bcrypt кітапханасын орнату платформаға тән екілік артефактілерді жасайды). Компиляция уақытына қойылатын талаптар қызметтер арасында әр түрлі болуы мүмкін және соңғы Dockerfile шұғыл түрде жасалады.

Kubernetes кластерлік сәулет және көші-қон

Кластердің өлшемі

Біз Amazon EC2 даналарында автоматтандырылған кластерді қамтамасыз ету үшін куб-тарды қолдануға шешім қабылдадық. Ертерек біз бәрін бір торап бассейнінде жүргізетінбіз. Ресурстарды тиімді пайдалану үшін жұмыс көлемін әртүрлі мөлшерде және даналардың түрлеріне бөлу қажеттілігін тез анықтадық. Мұның себебі аз салмақты бұрандалы шыбықтардың бір-бірімен жұмыс істеуі, олардың көп тізбектелген тіректермен қатар өмір сүруіне мүмкіндік бергеннен гөрі, біз үшін болжамды нәтижелер берді.

Біз шештік:

  • Мониторинг үшін m5.4 өлшемі (Prometheus)
  • N5.js жұмыс жүктемесін ұлғайту (бір ретті жұмыс жүктемесі)
  • Java және Go үшін c5.2x үлкейту (көп ағынды жұмыс)
  • басқару ұшағына арналған үлкейту (3 түйін)

Көші-қон

Бұрынғы инфрақұрылымымыздан Кубернетке көшуге дайындық кезеңдерінің бірі қолданыстағы қызметтік байланысты нақты Virtual Private Cloud (VPC) ішкі желісінде құрылған жаңа серпімді жүктеме тепе-теңдіктеріне (ELBs) ауыстыру болды. Бұл ішкі желі Kubernetes VPC-ге арналған. Бұл бізге модульдерді қызметтерге тәуелділіктерге нақты тапсырыс беруді ескерместен ауыстыруға мүмкіндік берді.

Бұл соңғы нүктелер әр жаңа ELB-ге бағыттайтын CNAME бар өлшенген DNS жазбалар жиынтығының көмегімен жасалды. Кесу үшін біз Кубернетес жаңа ELB қызметін көрсетіп, салмағы 0 болатын жаңа жазбаны қостық. Содан кейін біз тіркеудің уақытын (TTL) 0-ге орнаттық. Содан кейін ескі және жаңа салмақтар баяу реттелді. сайып келгенде, жаңа серверде 100% аяқталады. Кесу аяқталғаннан кейін, TTL әлдеқайда ақылға қонымды болды.

Біздің Java модульдеріміз төмен DNS TTL құрметіне ие болды, бірақ біздің Node қосымшалары олай алмады. Біздің инженерлеріміздің бірі бассейн кодының бір бөлігін бассейнді әр 60 ж сайын жаңартып отыратын менеджерге орап жазды. Бұл біз үшін өте жақсы жұмыс жасады.

Оқыту

Желілік маталар шегі

2019 жылғы 8 қаңтардың таңертеңгі сағаттарында Тиндер платформасы тұрақты тоқтап қалды. Платформаның кідіріс уақытының байланысты емес ұлғаюына жауап ретінде ертерек, кластерде түйіндер мен түйіндердің саны есептелді. Бұл барлық түйіндерде ARP кэшінің сарқылуына әкелді.

ARP кэшіне қатысты үш Linux мәні бар:

Несие

gc_thresh3 - қатты қақпақ. Егер сіз «көршілер кестесінің толып кетуі» журналының жазбаларын алсаңыз, бұл ARP кэшінің синхронды қоқыс жинауынан (GC) кейін, көршінің жазбасын сақтауға орын жетіспейтінін көрсетеді. Бұл жағдайда ядро ​​пакетті толығымен тастайды.

Біз Фланелді Кубернеттегі желілік мата ретінде қолданамыз. Пакеттер VXLAN арқылы жіберіледі. VXLAN - бұл Layer 3 желісіндегі Layer 2 қабаттастыру схемасы. Layer 2 желісінің сегменттерін кеңейтуге мүмкіндік беретін MAC-адресаттағы дерекқор протоколы (MAC-in-UDP) инкапсуляциясын қолданады. Физикалық деректер орталығы желісі бойынша тасымалдау протоколы - IP плюс UDP.

Сурет 2–1 Фланельдік диаграмма (несие)

Сурет 2-2 VXLAN пакеті (несие)

Kubernetes жұмысшыларының әрбір түйіні өзінің / 24 виртуалды мекенжай кеңістігін үлкен / 9 блоктан бөледі. Әрбір түйін үшін бұл 1 маршрут кестесіне, 1 ARP кестесіне (flannel.1 интерфейсінде) және 1 дерекқорға (FDB) жазба енгізуге әкеледі. Олар жұмысшы түйіні алғаш іске қосылғанда немесе әрбір жаңа түйін ашылған кезде қосылады.

Сонымен қатар, «тораптан» (немесе «поддоннан») байланыс, сайып келгенде, эт0 интерфейсі арқылы өтеді (жоғарыда Фланель диаграммасында көрсетілген). Бұл әрбір сәйкес түйін көзі мен түйін тағайындау үшін ARP кестесіне қосымша енгізуге әкеледі.

Біздің ортада коммуникацияның бұл түрі өте жиі кездеседі. Біздің Kubernetes қызмет көрсету нысандары үшін ELB жасалады және Кубернетес әрбір түйінді ELB-мен тіркейді. ELB хабардар емес және таңдалған түйін пакеттің соңғы бағыты болмауы мүмкін. Бұл түйін ELB-ден пакетті алған кезде, оның қызмет ету ережелерін бағалайды және басқа түйінде кездейсоқ таңдайды.

Өшіру кезінде кластерде жалпы 605 түйін болған. Жоғарыда келтірілген себептерге байланысты, бұл әдепкі gc_thresh3 мәнін тұтқындауға жеткілікті болды. Бұл орын алғанда, ARP кестесінде тек пакеттер ғана емес, Flannel / виртуалды мекен-жайдың барлық кеңістігі жоқ. Подключение байланысы және DNS іздеулер сәтсіз аяқталды. (DNS кластерде орналастырылған, осы мақалада кейінірек толығырақ түсіндірілетін болады.)

Шешу үшін gc_thresh1, gc_thresh2 және gc_thresh3 мәндері көтеріліп, жоқ желілерді қайта тіркеу үшін Flannel қайта іске қосылуы керек.

Күтпеген түрде масштабта DNS іске қосылуда

Көші-қонды қамтамасыз ету үшін біз DNS-ті трафикті қалыптастыруға және біздің қызметтерімізден ескі Кубернетке дейінгі өсуді жеңілдету үшін қолдандық. Біз Route53 RecordSets жиынтығына TTL салыстырмалы түрде төмен мәндерін орнаттық. Ескірген инфрақұрылымды EC2 даналарында іске қосқан кезде, шешуші конфигурация Amazon DNS-ге нұсқады. Біз мұны қажет деп таптық және біздің қызметтеріміз бен Amazon қызметтері (мысалы, DynamoDB) үшін салыстырмалы түрдегі TTL құны айтарлықтай елеусіз қалды.

Кубернетке көбірек қызмет көрсете отырып, біз секундына 250 000 сұраныстарға жауап беретін DNS қызметін басқаратын болдық. Біздің қосымшаларымызда DNS іздеу уақытының үзілістерімен және әсерлі күту уақытымен бетпе-бет келдік. Бұл DST провайдерінің CoreDNS орналастыруына ауысқанына қарамастан, бір уақытта 120 өзекті тұтынатын 1000 данаға жеткенде орын алды.

Басқа ықтимал себептер мен шешімдерді зерттеу барысында Linux пакетін сүзгілеу нетфильтріне әсер ететін жарыс жағдайын сипаттайтын мақаланы таптық. Біз көрген DNS күту уақыты және Flannel интерфейсіндегі insert_fail есептегішінің өсуі мақаланың нәтижелеріне сәйкес келді.

Мәселе бастапқы және тағайындау желісінің мекен-жайын аудару (SNAT және DNAT) және одан кейін байланыс кестесіне енгізу кезінде пайда болады. Ішкі талқыланған және қауымдастық ұсынған бір шешім - DNS-ті жұмысшы түйініне бағыттау. Бұл жағдайда:

  • SNAT қажет емес, өйткені трафик түйінде жергілікті болады. Оны Eth0 интерфейсі арқылы жіберудің қажеті жоқ.
  • DNAT қажет емес, өйткені тағайындалған IP түйінге локальды болып табылады және әр ипотекалық ережелер үшін кездейсоқ таңдалған подшипник емес.

Біз осы тәсілмен алға жылжуды ұйғардық. CoreDNS Кубернетте DaemonSet ретінде орналастырылды және біз кубель - кластер-dns командалық жалаушаны конфигурациялау арқылы тораптың жергілікті DNS серверін әр подкасттың көрнекі.conf-ға енгіздік. Айналым DNS күту уақыты үшін тиімді болды.

Алайда, біз әлі де төмендеген пакеттерді және Flannel интерфейсінің insert_failed есептегішінің өсуін көреміз. Бұл жоғарыда қарастырылғаннан кейін де сақталады, өйткені біз DNS трафигі үшін SNAT және / немесе DNAT-тен аулақ болдық. Жарыстың шарты басқа қозғалыс түрлеріне қатысты болады. Бақытымызға орай, біздің пакеттеріміздің көпшілігі TCP болып табылады және жағдай туындаған кезде пакеттер сәтті қайта жіберіледі. Трафиктің барлық түрлеріне арналған ұзақ мерзімді түзету - біз әлі талқылаймыз.

Жақсы жүктеме тепе-теңдігіне қол жеткізу үшін елшіні пайдалану

Біздің серверлерді Кубернетке көшіру барысында біз бағандардағы теңгерімсіз жүктемелерден зардап шекті. Біз HTTP Keepalive арқасында ELB қосылымдары әр жылжымалы орналастырудың алғашқы дайын шыбықтарына жабысып қалғанын анықтадық, сондықтан трафиктің көп бөлігі қол жетімді тіректердің аз пайызынан өтті. Алғашқы жеңілдетудің бірі - ең нашар құқық бұзушылар үшін 100% MaxSurge-ді жаңа орналастыру кезінде қолдану. Бұл кейбір тиімді орналастырулармен тиімді және тұрақты емес ұзақ мерзімді болды.

Біз қолданған тағы бір жеңілдету - бұл күрделі қызметтер үшін ресурстар сұраныстарын жасанды түрде көбейту. Бұл ресурстардың қалдықтарына байланысты ұзақ мерзімді перспективада мүмкін болмады және біздің түйін қосымшаларымыз бір бұрандалы болып, 1 ядроға тиімді қосылды. Жалғыз нақты шешім - жүктемелерді теңдестіруді пайдалану.

Біз іштей Елшіні бағалауды қарастырдық. Бұл бізге өте шектеулі түрде қолдануға және бірден пайда көруге мүмкіндік берді. Тіркелу - бұл жоғары деңгейлі Layer 7 прокси-сервері, бұл үлкен қызметке бағытталған сәулет үшін жасалған. Ол жүктемелерді теңдестірудің алдыңғы қатарлы әдістерін, соның ішінде автоматты қайта қосуды, электр тізбегін бұзуды және жылдамдықты ғаламдық шектеуге мүмкіндік береді.

Біз ойластырған: әрбір контейнерде бір бағыт пен кластер бар жергілікті контейнер портына соққы беретін Эльвой тротуар болуы керек. Потенциалды каскадты азайту және жарылыс радиусын сақтау үшін біз әр қызмет үшін әр қол жетімділік аймағында (AZ) бір-бір орналастырылған алдыңғы қатарлы Envoy подкаларын пайдаландық. Бұл біздің инженерлеріміздің бірі қызметтердің ашылуының кішігірім механизміне әсер етті, олар берілген қызмет үшін әр AZ-дағы шыбықтардың тізімін қайтарды.

Алдын-ала қызмет көрсету қызметі осы қызметтің ашылу механизмін бір жоғары ағыс кластермен және маршрутпен қолданады. Біз ақылға қонымды үзілістерді орнаттық, барлық ажыратқыштардың параметрлерін жақсарттық, содан кейін өтпелі сәтсіздіктер мен жайылыстарға көмектесу үшін минималды қайталау конфигурациясын орнаттық. Біз осы алдыңғы қызметтердің әрқайсысын TCP ELB көмегімен алдық. Біздің басты прокси қабаттағы сақтағыш белгілі бір Envoy подкастарына салынса да, олар жүктемені басқара білді және ең аз_құрал арқылы теңгеруге теңшелді.

Орналастыру үшін біз қосымшада да, бүйірлік подкаста да алдын-ала PreStop ілмегін қолдандық. Бүйірдегі денсаулық тексеруі деп аталатын бұл ілмек кішкене ұйқымен қатар, жарық қосылымдарының аяқталып, ағып кетуіне біраз уақыт беру үшін сәтсіздікке ұшырайды.

Біздің тез қозғалуымыздың бір себебі - қарапайым Prometheus қондырғысымен оңай біріктіре алатын бай метрикалық құралдар. Бұл бізге конфигурацияны баптаған кезде және трафикті азайту кезінде не болып жатқанын көруге мүмкіндік берді.

Нәтижелер бірден және айқын болды. Біз ең теңгерімсіз қызметтерден бастадық және осы сәтте ол біздің кластердегі ең маңызды қызметтердің он екіінің алдында жұмыс істейді. Осы жылы біз толыққанды қызмет көрсететін торға көшуді жоспарлап отырмыз, ол қызметтерді жетілдіруді, схеманы бұзуды, сатылымдарды анықтауды, жылдамдықты шектеу мен іздеуді жүзеге асырады.

Сурет 3–1 Бір қызметке жіберілген процессордың жіберілуі

Ақырғы нәтиже

Осы зерттеулер мен қосымша зерттеулердің арқасында біз Кубернеттің үлкен кластерлерін қалай жобалау, орналастыру және басқару тәсілдерін жақсы білетін мықты ішкі инфрақұрылым командасын құрдық. Тиндердің бүкіл инжинирингтік ұйымы қазір Кубернеттегі контейнерлерді қалай орналастыруға және орналастыруға қатысты білімі мен тәжірибесіне ие.

Бұрынғы инфрақұрылымымызда қосымша масштаб қажет болған кезде, біз жаңа EC2 даналарының Интернетте пайда болуын күте отырып бірнеше минутты бастан кешірдік. Қазір контейнерлер бірнеше минут ішінде емес, бірнеше секунд ішінде трафикті жоспарлайды және қызмет етеді. Бір контейнердің EC2 данасында жоспарлау сонымен қатар көлденең тығыздықты жақсартуға мүмкіндік береді. Нәтижесінде біз 2019 жылы алдыңғы жылға қарағанда EC2 шығындарын едәуір үнемдеуді жобалаймыз.

Екі жылға жуық уақыт кетті, бірақ біз 2019 жылдың наурыз айында көші-қонымызды аяқтадық. Tinder платформасы тек 200 қызмет, 1000 түйін, 15000 дана және 48000 контейнерден тұратын Кубернетес кластерінде жұмыс істейді. Инфрақұрылым енді біздің операциялық топтарымызға жүктелген міндет емес. Мұның орнына, бүкіл ұйымның инженерлері осы жауапкершілікті бөліседі және олардың қосымшалардың қалай құрастырылғанын және барлығын код түрінде қолданатындығын бақылауды алады.

Сондай-ақ қараңыз

Инстаграмда біреуді еске түсіруді қалай тоқтатасыз?Снейпчатта бір жігітті қызды қағып жатыр. Ол оны өшірмеді немесе оны менің өтінішім бойынша өшіруді сұрады, сондықтан мен оны Инстаграмға жеке хабарлама жіберіп, онымен барлық байланыстарды үзіп тастауды өтінемін. Қазір ол есімнен кетіп, мені жынды деп атайды. Кім дұрыс?Сіз өзіңіздің SnapChat сызықтарыңызға назар аудармайсыз ба? Неліктен оларды жалғастырғыңыз келеді?Интернеттегі BioLink-ті қалай ақша табуға болады?Неліктен инстаграмдағы оқиғаларды жариялай алмаймын?Дауыстық хабарламаларды WhatsApp-қа автоматты түрде жүктеуді өшірудің қандай да бір тәсілі бар ма? Егер бар болса, мұны жүзеге асыру үшін не істеу керек?Менің бұрынғы ізбасарым ретінде Инстаграмнан алып тастауым керек пе? Мен бұл мүмкін екенін білдім. Қысқаша әңгіме: бұл салқын болды және біз (шамамен 3 жыл) бері сөйлескен жоқпыз. Қайсысы одан гөрі ауырады: ол менің өмірімде жаңарып жатыр ма, әлде шеттетіле ме?Біреудің \ u2019s инстаграмдағы Android-дегі жазбаларын қалай өшіруге болады?