Ескерту. аударма: Жақында әлемге әйгілі Tinder қызметінің қызметкерлері инфрақұрылымын Kubernetes-ке көшірудің кейбір техникалық мәліметтерімен бөлісті. Процесс екі жылға жуық уақытқа созылды және нәтижесінде 8 мың контейнерде орналастырылған 200 қызметтен тұратын K48-де өте ауқымды платформа іске қосылды. Tinder инженерлері қандай қызықты қиындықтарға тап болды және олар қандай нәтижелерге жетті?Осы аударманы оқыңыз.
Неліктен?
Шамамен екі жыл бұрын Tinder өз платформасын Kubernetes-ке көшіруді шешті. Kubernetes Tinder командасына контейнерлерді жинауға және өзгермейтін орналастыру арқылы ең аз күшпен өндіріске көшуге мүмкіндік береді. (өзгермейтін орналастыру). Бұл жағдайда қолданбаларды құрастыру, оларды орналастыру және инфрақұрылымның өзі кодпен бірегей түрде анықталады.
Біз сондай-ақ ауқымдылық пен тұрақтылық мәселесінің шешімін іздедік. Масштабтау маңызды болған кезде, біз жиі жаңа EC2 даналарының айналуы үшін бірнеше минут күтуге тура келді. Контейнерлерді іске қосу және трафикті минуттардың орнына секундтарда бастау идеясы біз үшін өте тартымды болды.
Процесс қиын болып шықты. 2019 жылдың басындағы көші-қон кезінде Кубернетес кластері маңызды массаға жетті және біз трафик көлеміне, кластер өлшеміне және DNS-ке байланысты әртүрлі мәселелерге тап болдық. Жол бойында біз 200 қызметті көшіруге және 1000 түйіннен, 15000 48000 түйіннен және XNUMX XNUMX жұмыс істейтін контейнерден тұратын Kubernetes кластерін қолдауға қатысты көптеген қызықты мәселелерді шештік.
Қалай?
2018 жылдың қаңтар айынан бастап біз көші-қонның түрлі кезеңдерін бастан өткердік. Біз барлық қызметтерімізді контейнерлеуден және оларды Kubernetes сынақ бұлттық орталарына орналастырудан бастадық. Қазан айынан бастап біз барлық қолданыстағы қызметтерді Kubernetes-ке әдістемелік түрде көшіруді бастадық. Келесі жылдың наурыз айына дейін біз көшіруді аяқтадық және қазір Tinder платформасы тек Кубернетесте жұмыс істейді.
Kubernetes үшін кескіндерді құру
Бізде Kubernetes кластерінде жұмыс істейтін микросервистерге арналған 30-дан астам бастапқы код репозиторийлері бар. Бұл репозиторийлердегі код әртүрлі тілдерде (мысалы, Node.js, Java, Scala, Go) бір тілге арналған бірнеше орындалу орталарымен жазылған.
Құрастыру жүйесі әрбір микросервис үшін толығымен теңшелетін «құрастыру контекстін» қамтамасыз етуге арналған. Ол әдетте Dockerfile және қабық командаларының тізімінен тұрады. Олардың мазмұны толығымен теңшеуге болады және сонымен бірге барлық осы құрастыру контексттері стандартталған пішімге сәйкес жазылған. Құрастыру мәтінмәндерін стандарттау бір құрастыру жүйесіне барлық микросервистерді өңдеуге мүмкіндік береді.
1-1-сурет. Builder контейнері арқылы стандартталған құрастыру процесі
Орындау уақыттары арасындағы максималды үйлесімділікке қол жеткізу үшін (орындау орталары) әзірлеу және тестілеу кезінде бірдей құрастыру процесі қолданылады. Біз өте қызықты мәселеге тап болдық: бізге бүкіл платформада құрастыру ортасының үйлесімділігін қамтамасыз ету жолын әзірлеу керек болды. Бұған қол жеткізу үшін барлық құрастыру процестері арнайы контейнерде жүзеге асырылады. құрылысшы.
Оның контейнерді іске асыруы жетілдірілген Docker әдістерін қажет етті. Builder жеке Tinder репозиторийлеріне кіру үшін қажетті жергілікті пайдаланушы идентификаторын және құпияларды (SSH кілті, AWS тіркелгі деректері және т.б.) иеленеді. Ол құрастырылған артефактілерді табиғи түрде сақтау үшін көздері бар жергілікті каталогтарды орнатады. Бұл тәсіл өнімділікті жақсартады, себебі ол Builder контейнері мен хост арасында құрастыру артефактілерін көшіру қажеттілігін жояды. Сақталған құрастыру артефактілерін қосымша конфигурациясыз қайта пайдалануға болады.
Кейбір қызметтер үшін компиляция ортасын орындалу ортасына салыстыру үшін басқа контейнер жасауға тура келді (мысалы, Node.js bcrypt кітапханасы орнату кезінде платформаға тән екілік артефакттерді жасайды). Компиляция процесі кезінде талаптар қызметтер арасында әр түрлі болуы мүмкін және соңғы Dockerfile жылдам құрастырылады.
Kubernetes кластерінің архитектурасы және миграциясы
Кластер өлшемін басқару
пайдалануды шештік kube-aws Amazon EC2 даналарында автоматтандырылған кластерді орналастыру үшін. Ең басында бәрі түйіндердің бір ортақ пулында жұмыс істеді. Біз ресурстарды тиімдірек пайдалану үшін жұмыс жүктемелерін өлшемі мен дана түрі бойынша бөлу қажеттілігін тез түсіндік. Логика мынада болды: бірнеше жүктелген көп ағынды қосқыштарды іске қосу олардың бір ағынды қосқыштардың көп санымен бірге өмір сүруіне қарағанда өнімділік тұрғысынан болжамдырақ болып шықты.
Соңында біз шештік:
- m5.4x үлкен — бақылау үшін (Прометей);
- c5.4x үлкен - Node.js жұмыс жүктемесі үшін (бір ағынды жұмыс жүктемесі);
- c5.2x үлкен - Java және Go үшін (көп ағынды жұмыс жүктемесі);
- c5.4x үлкен — басқару панелі үшін (3 түйін).
Көші-қон
Ескі инфрақұрылымнан Кубернетеске көшуге дайындық қадамдарының бірі қызметтер арасындағы бар тікелей байланысты жаңа жүктеме теңестіргіштеріне (Elastic Load Balancers (ELB)) қайта бағыттау болды. Олар виртуалды жеке бұлттың (VPC) белгілі бір ішкі желісінде жасалған. Бұл ішкі желі Kubernetes VPC-ге қосылған. Бұл қызмет тәуелділіктерінің нақты тәртібін ескермей, модульдерді біртіндеп көшіруге мүмкіндік берді.
Бұл соңғы нүктелер әрбір жаңа ELB-ге нұсқайтын CNAME бар DNS жазбаларының салмақты жиынтықтары арқылы жасалған. Ауыстыру үшін біз салмағы 0 болатын Kubernetes қызметінің жаңа ELB нұсқасын көрсететін жаңа жазба қостық. Содан кейін жазбаның өмір сүру уақытын (TTL) 0-ге орнаттық. Осыдан кейін ескі және жаңа салмақтар орнатылды. баяу реттелді және ақырында жүктеменің 100% жаңа серверге жіберілді. Ауыстыру аяқталғаннан кейін TTL мәні барабар деңгейге оралды.
Бізде бар Java модульдері төмен TTL DNS деңгейіне төтеп бере алды, бірақ Node қолданбалары мүмкін емес. Инженерлердің бірі қосылым пулының кодының бір бөлігін қайта жазып, оны әр 60 секунд сайын бассейндерді жаңартып отыратын менеджерге ораған. Таңдалған тәсіл өте жақсы жұмыс істеді және өнімділіктің айтарлықтай төмендеуінсіз.
Сабақ
Желілік матаның шектері
8 жылдың 2019 қаңтарында таңертең Tinder платформасы күтпеген жерден апатқа ұшырады. Сол күні таңертең платформаның кешігуінің байланысты емес өсуіне жауап ретінде кластердегі түйіндер мен түйіндердің саны артты. Бұл барлық түйіндерімізде ARP кэшінің таусылуына әкелді.
ARP кэшіне қатысты үш Linux опциясы бар:
()
gc_thresh3 - бұл қатаң шектеу. Журналдағы «көрші кестенің толып кетуі» жазбаларының пайда болуы тіпті синхронды қоқыс жинаудан (GC) кейін де көрші жазбаны сақтау үшін ARP кэшінде орын жеткіліксіз екенін білдірді. Бұл жағдайда ядро жай ғана пакетті толығымен тастады.
Біз қолданамыз Кубернетестегі желілік мата ретінде. Пакеттер VXLAN арқылы беріледі. VXLAN — L2 желісінің үстіне көтерілген L3 туннелі. Технология MAC-in-UDP (MAC Address-in-User Datagram Protocol) инкапсуляциясын пайдаланады және 2-деңгей желі сегменттерін кеңейтуге мүмкіндік береді. Физикалық деректер орталығының желісіндегі тасымалдау протоколы IP плюс UDP болып табылады.
2–1-сурет. Фланель диаграммасы ()
2–2-сурет. VXLAN бумасы ()
Әрбір Kubernetes жұмысшы түйіні үлкенірек /24 блогынан /9 маскасы бар виртуалды мекенжай кеңістігін бөледі. Әрбір түйін үшін бұл маршруттау кестесінде бір жазба, ARP кестесінде бір жазба (фланель.1 интерфейсінде) және коммутация кестесінде (FDB) бір жазба. Олар жұмысшы түйін бірінші рет іске қосылғанда немесе жаңа түйін ашылған сайын қосылады.
Сонымен қатар, түйін-под (немесе pod-pod) байланысы ақыр соңында интерфейс арқылы өтеді eth0 (жоғарыдағы Фланель диаграммасында көрсетілгендей). Бұл әрбір сәйкес көз және тағайындалған хост үшін ARP кестесінде қосымша жазбаға әкеледі.
Біздің ортада қарым-қатынастың бұл түрі өте кең таралған. Kubernetes қызметіндегі нысандар үшін ELB жасалады және Kubernetes әрбір түйінді ELB арқылы тіркейді. ELB подкасттар туралы ештеңе білмейді және таңдалған түйін пакеттің соңғы мақсаты болмауы мүмкін. Мәселе мынада, түйін ELB пакетін алған кезде оны ережелерді ескере отырып қарастырады. iptables белгілі бір қызметке арналған және басқа түйіндегі подкастты кездейсоқ таңдайды.
Сәтсіздік кезінде кластерде 605 түйін болды. Жоғарыда айтылған себептерге байланысты бұл маңыздылықты жеңу үшін жеткілікті болды gc_thresh3, ол әдепкі болып табылады. Бұл орын алған кезде, пакеттер түсіріліп қана қоймайды, сонымен қатар /24 маскасы бар бүкіл Flannel виртуалды мекенжай кеңістігі ARP кестесінен жоғалады. Түйін байланысы және DNS сұраулары үзілді (DNS кластерде орналастырылған; толық ақпаратты осы мақаладан кейін оқыңыз).
Бұл мәселені шешу үшін мәндерді көбейту керек gc_thresh1, gc_thresh2 и gc_thresh3 және жетіспейтін желілерді қайта тіркеу үшін Flannel қолданбасын қайта іске қосыңыз.
Күтпеген DNS масштабтауы
Тасымалдау процесі кезінде біз трафикті басқару және қызметтерді ескі инфрақұрылымнан Кубернетеске біртіндеп тасымалдау үшін DNS-ті белсенді түрде қолдандық. Route53 ішіндегі байланысты жазбалар жиындары үшін салыстырмалы түрде төмен TTL мәндерін орнаттық. Ескі инфрақұрылым EC2 даналарында жұмыс істеп тұрған кезде, біздің шешуші конфигурациясы Amazon DNS-ке нұсқады. Біз мұны әдеттегідей қабылдадық және төмен TTL біздің қызметтерімізге және Amazon қызметтеріне (мысалы, DynamoDB) әсері айтарлықтай байқалмады.
Біз қызметтерді Kubernetes қызметіне көшірген кезде, DNS секундына 250 мың сұрауды өңдеп жатқанын анықтадық. Нәтижесінде қолданбалар DNS сұраулары үшін тұрақты және елеулі күту уақытын бастан кешіре бастады. Бұл DNS провайдерін CoreDNS жүйесіне оңтайландыру және ауыстыру бойынша керемет күш-жігерге қарамастан болды (ол ең жоғары жүктеме кезінде 1000 ядрода жұмыс істейтін 120 подрядқа жетті).
Басқа ықтимал себептер мен шешімдерді зерттей отырып, біз анықтадық , пакетті сүзу құрылымына әсер ететін жарыс шарттарын сипаттау netfilter Linux жүйесінде. Біз байқаған тайм-ауттар, өскелең санауышпен бірге кірістіру_сәтсіз Фланель интерфейсіндегі мәліметтер мақаланың нәтижелеріне сәйкес келді.
Мәселе бастапқы және тағайындалған желі мекенжайын аудару (SNAT және DNAT) және кестеге кейіннен енгізу сатысында орын алады. контракт. Ішкі талқыланған және қауымдастық ұсынған уақытша шешімдердің бірі DNS-ті жұмысшы түйінінің өзіне жылжыту болды. Бұл жағдайда:
- SNAT қажет емес, себебі трафик түйіннің ішінде қалады. Оны интерфейс арқылы бағыттаудың қажеті жоқ eth0.
- DNAT қажет емес, өйткені тағайындалған IP түйінге жергілікті болып табылады және ережелерге сәйкес кездейсоқ таңдалған подкаст емес. iptables.
Біз осы әдісті ұстануға шешім қабылдадық. CoreDNS Kubernetes жүйесінде DaemonSet ретінде орналастырылды және біз жергілікті түйіннің DNS серверін іске асырдық. ажыратымдылық жалаушаны орнату арқылы әрбір подкаст --cluster-dns командалар кубелет . Бұл шешім DNS күту уақытында тиімді болып шықты.
Дегенмен, біз әлі де пакеттердің жоғалуын және есептегіштің ұлғаюын көрдік кірістіру_сәтсіз Фланель интерфейсінде. Бұл уақытша шешім жүзеге асырылғаннан кейін жалғасты, себебі біз тек DNS трафигі үшін SNAT және/немесе DNAT жою мүмкіндігіне ие болдық. Көлік қозғалысының басқа түрлері үшін жарыс шарттары сақталды. Бақытымызға орай, біздің пакеттеріміздің көпшілігі TCP болып табылады және мәселе туындаса, олар жай ғана қайта жіберіледі. Біз әлі де трафиктің барлық түрлеріне қолайлы шешім табуға тырысамыз.
Жүктемені жақсырақ теңестіру үшін Envoy қолданбасын пайдалану
Біз бэкендтік қызметтерді Kubernetes-ке көшірген кезде, біз қосқыштар арасындағы теңгерімсіз жүктемеден зардап шеге бастадық. Біз HTTP Keepalive ELB қосылымдарының әрбір шығарылған орналастырудың алғашқы дайын подводтарына ілініп тұруына себеп болғанын анықтадық. Осылайша, трафиктің негізгі бөлігі қол жетімді подкасттардың шағын пайызы арқылы өтті. Біз сынаған бірінші шешім ең нашар жағдай сценарийлері үшін жаңа орналастыруларда MaxSurge-ді 100% орнату болды. Үлкенірек орналастырулар тұрғысынан әсер шамалы және перспективасыз болып шықты.
Біз пайдаланған тағы бір шешім маңызды қызметтерге ресурс сұраныстарын жасанды түрде арттыру болды. Бұл жағдайда жақын жерде орналастырылған бұршақтарда басқа ауыр бұршақтармен салыстырғанда маневр жасау үшін көбірек орын болады. Бұл ұзақ мерзімді перспективада да жұмыс істемейді, өйткені бұл ресурстарды ысырап етеді. Сонымен қатар, біздің Node қолданбалары бір ағынды болды және сәйкесінше тек бір ядроны пайдалана алады. Жалғыз нақты шешім жүктемені жақсырақ теңестіруді пайдалану болды.
Біз көптен бері толық бағалағымыз келді . Қазіргі жағдай оны өте шектеулі түрде орналастыруға және бірден нәтиже алуға мүмкіндік берді. Envoy — үлкен SOA қолданбаларына арналған жоғары өнімді, ашық бастапқы, деңгей-XNUMX прокси. Ол автоматты қайталауды, автоматты ажыратқыштарды және жаһандық жылдамдықты шектеуді қоса алғанда, жүктемені теңестірудің озық әдістерін енгізе алады. (Ескерту. аударма: Бұл туралы толығырақ мына жерден оқи аласыз Envoy негізіндегі Истио туралы.)
Біз келесі конфигурацияны ойлап таптық: әрбір подводқа және бір бағытқа арналған Envoy арбасына ие болыңыз және кластерді порт арқылы жергілікті контейнерге қосыңыз. Ықтимал каскадты азайту және шағын соққы радиусын сақтау үшін біз әр қызмет үшін бір қолжетімділік аймағына (AZ) бір Envoy алдыңғы прокси-серверлер паркін пайдаландық. Олар біздің инженерлеріміздің бірі жазған қарапайым қызметтерді табу механизміне сүйенді, ол берілген қызмет үшін әрбір AZ-да қосқыштар тізімін қайтарды.
Қызмет фронтының өкілдері содан кейін осы қызметті табу механизмін бір жоғарғы кластермен және маршрутпен пайдаланды. Біз сәйкес күту уақытын орнаттық, барлық автоматты ажыратқыш параметрлерін ұлғайттық және жалғыз сәтсіздіктерге көмектесу және біркелкі орналастыруды қамтамасыз ету үшін ең аз қайталау конфигурациясын қостық. Біз осы қызметтің алдыңғы өкілдерінің әрқайсысының алдына TCP ELB қойдық. Тіпті біздің негізгі прокси-қабатымыздың сақтау мүмкіндігі кейбір Envoy қосқыштарында тұрып қалса да, олар әлі де жүктемені әлдеқайда жақсы өңдей алды және сервердегі ең аз_сұрау арқылы теңестіруге теңшелген.
Орналастыру үшін біз preStop ілгегін қолданбалы бөліктерде де, қосалқы бөлімдерде де қолдандық. Ілмек бүйірлік контейнерде орналасқан әкімші соңғы нүктесінің күйін тексеру кезінде қатені тудырды және белсенді қосылымдарды тоқтатуға мүмкіндік беру үшін біраз уақытқа ұйқы режиміне өтті.
Біз тез қозғала алуымыздың себептерінің бірі қарапайым Prometheus қондырғысына оңай біріктіре алатын егжей-тегжейлі көрсеткіштерге байланысты. Бұл конфигурация параметрлерін реттеп, трафикті қайта таратқанда не болып жатқанын дәл көруге мүмкіндік берді.
Нәтижелері бірден және айқын болды. Біз ең теңгерімсіз қызметтерден бастадық, қазіргі уақытта ол кластердегі ең маңызды 12 қызметтің алдында жұмыс істейді. Осы жылы біз кеңейтілген қызметті ашу, электр тізбегін үзу, шектен шығуды анықтау, жылдамдықты шектеу және бақылау арқылы толық сервистік торға көшуді жоспарлап отырмыз.
Сурет 3–1. Envoy-ге көшу кезінде бір қызметтің CPU конвергенциясы
Қорытынды нәтиже
Осы тәжірибе және қосымша зерттеулер арқылы біз үлкен Kubernetes кластерлерін жобалау, орналастыру және пайдалануда күшті дағдылары бар күшті инфрақұрылымдық топ құрдық. Барлық Tinder инженерлерінде контейнерлерді буып-түю және Kubernetes-ке қосымшаларды орналастыру бойынша білімі мен тәжірибесі бар.
Ескі инфрақұрылымда қосымша қуат қажет болған кезде, жаңа EC2 даналарының іске қосылуын бірнеше минут күтуге тура келді. Енді контейнерлер іске қосылып, трафикті минуттардың орнына бірнеше секунд ішінде өңдей бастайды. Бір EC2 данасында бірнеше контейнерлерді жоспарлау да көлденең концентрацияны жақсартады. Нәтижесінде біз өткен жылмен салыстырғанда 2019 жылы EC2 шығындарының айтарлықтай төмендеуін болжаймыз.
Көшіру екі жылға жуық уақытты алды, бірақ біз оны 2019 жылдың наурыз айында аяқтадық. Қазіргі уақытта Tinder платформасы тек 200 қызметтен, 1000 15 түйіннен, 000 48 түйіннен және 000 XNUMX жұмыс істейтін контейнерлерден тұратын Kubernetes кластерінде жұмыс істейді. Инфрақұрылым енді операциялық топтардың жалғыз домені емес. Біздің барлық инженерлер осы жауапкершілікті бөліседі және тек кодты пайдалана отырып, өз қолданбаларын құру және орналастыру процесін бақылайды.
Аудармашыдан PS
Сондай-ақ біздің блогтағы мақалалар топтамасын оқыңыз:
- ««.
- ««.
- ««.
- ««.
- ««.
- ««.
- ««.
- ««.
- ««.
- ««.
Ақпарат көзі: www.habr.com