Тиндердин Кубернетке көчүшү

Автору: Крис О'Брайен, Инженердик Менеджер | Крис Томас, Инженердик Менеджер | Jinyong Lee, Программанын улук инженери | Түзөтүүчү: Купер Джексон, программалык камсыздоо инженери

Неге

Эки жыл мурун, Тиндер платформасын Кубернетке көчүрүүнү чечкен. Кубернетес бизге Tinder Engineering компаниясын контейнеризацияга жана аз тийүү менен иштөөгө багытталган өзгөрүлбөгөн жайгаштыруу аркылуу жетүүгө мүмкүнчүлүк берди. Колдонмо куруу, жайылтуу жана инфраструктура код катары аныкталат.

Ошондой эле биз масштабдуу жана туруктуулук көйгөйлөрүн чечүүгө аракет кылдык. Масштаб түзүү кризиске учураганда, биз EC2 инстанцияларынын онлайнга келишин күтүп, бир нече мүнөт кыйналдык. Контейнерлерди тактоо жана трафикти бир нече мүнөт ичинде эмес, бир нече мүнөт ичинде тейлөө идеясы бизди кызыктырды.

Оңой болгон жок. 2019-жылдын башында миграция учурунда биз Кубернетстеги кластердеги чоң масштабга жетип, трафиктин көлөмүнө, кластердин көлөмүнө жана DNSке байланыштуу ар кандай кыйынчылыктарга туш болдук. Биз 200 кызматты көчүрүү жана Кубернетес кластерин иштетүү боюнча кызыктуу маселелерди чечтик, масштабда 1000 түйүн, 15000 кесек жана 48,000 иштеп жаткан контейнерлер.

кантип

2018-жылдын январынан баштап, биз миграциялык аракеттердин ар кандай баскычтарын баштадык. Кызматтарыбыздын бардыгын контейнерлерге жөнөтүп, Кубернетес шаарында өткөрүлгөн ар кандай шарттарда жайгаштыруудан баштадык. Октябрь айынан баштап, мурунку кызматтарыбыздын бардыгын Кубернетке өткөрүп бердик. Кийинки жылдын март айында биз миграцияны аяктадык жана Tinder платформасы азыр гана Кубернетте жайгашкан.

Кубернетес үчүн сүрөттөрдү куруу

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

Система ар бир микросервис үчүн толук ыңгайлаштырылган "куруу контекстинде" иштөөгө ылайыкташтырылган, ал адатта Dockerfile жана ракеталык командалардан турат. Мазмуну толугу менен өзгөчөлөштүрүлө турган болсо да, бул контексттер бардыгы стандартташтырылган форматка ылайык жазылат. Курулуш контексттерин стандартташтыруу, бирдиктүү тутумга бардык микросервисттерди иштетүүгө мүмкүндүк берет.

Сүрөт 1–1 Builder контейнери аркылуу стандартташтырылган куруу процесси

Иштөө убактысынын чөйрөлөрү ортосундагы максималдуу шайкештикке жетишүү үчүн, иштеп чыгуу жана сыноо баскычында ушул эле курулуш процесси колдонулат. Платформада айлана-чөйрөнү ырааттуу курууга кепилдик берүүчү жолду ойлоп табышыбыз керек болгондо, бул өзгөчө кырдаал жаралды. Натыйжада, бардык куруу процесстери атайын "Куруучу" контейнеринде жүргүзүлөт.

Builder контейнерин ишке ашыруу бир катар алдыңкы Docker техникаларын талап кылды. Бул Builder контейнери жергиликтүү колдонуучунун ID жана купуя сырларын (мисалы, SSH ачкычы, AWS аныктоо белгилери ж.б.) Tinder жеке репозиторийлерине кирүү үчүн талап кылынат. Ал курулган артефакттарды сактоонун табигый жолу бар жергиликтүү коддорду орнотот. Бул ыкма өндүрүмдүүлүктү өркүндөтөт, анткени ал Builder контейнери менен башкы компьютердин ортосунда орнотулган артефакттарды көчүрүүнү жок кылат. Сакталган артефакттар кийинки жолу кийинки конфигурациясыз колдонулат.

Айрым кызматтар үчүн, куруучу убакыттын чөйрөсүн иштөө убактысынын чөйрөсүнө дал келүү үчүн, Builderдин ичинде дагы бир контейнер жаратышыбыз керек болчу (мисалы, Node.js bcrypt китепканасын орнотуу, платформага тиешелүү экилик артефакттарды жаратат). Компиляция убактысынын талаптары кызматтардын ортосунда айырмаланышы мүмкүн жана акыркы Dockerfile чымынга түзүлөт.

Кубернетес кластердик архитектурасы жана миграция

Кластердик өлчөм

Биз Amazon EC2 инстанцияларында автоматташтырылган кластерди камсыз кылуу үчүн куб-тарды колдонууну чечтик. Эрте менен, биз бардыгын бир баскычтагы бассейнде иштетип жаттык. Ресурстарды натыйжалуу пайдалануу үчүн жумуш жүктөрүн ар кандай көлөмдөгү жана инстанциялар түрлөрүнө бөлүү зарылдыгын тез арада аныктадык. Эң негизгиси, аз жик ийилген чептерди биргелешип иштетүү биз үчүн бир кыйла көп жипчелер менен бирге жашоого мүмкүндүк бергенден көрө, иштин натыйжалуулугун кыйла натыйжалуулугун көрсөттү.

Төмөнкү жерге отурукташтык:

  • Мониторинг үчүн m5.4x чоңойтуу (Prometheus)
  • Node.js жүгү үчүн c5.4xlarge (бир жиптүү жумуш жүгү)
  • Java жана Go үчүн c5.2xlarge (көп тиштүү жумуш жүгү)
  • башкаруу учагы үчүн c5.4x чоңойуу (3 түйүн)

көчүрүү

Биздин эски инфраструктурабыздан Кубернетке көчүп барууга даярдык көрүүчү кадамдардын бири учурдагы тейлөө кызматын байланышты өзгөртүү болуп, белгилүү бир Виртуалдык Жеке Булутта (VPC) түзүлгөн жаңы Elastic Жүктөө Балансерлерине (ELBs) өтүү болду. Бул ички тармак Кубернетес VPC менен иштелип чыккан. Бул бизге модульдарды тейлөөгө көз карандылыкка атайын буйрутма бербестен көчүрүп салууга мүмкүндүк берди.

Бул акыркы чекиттер ар бир жаңы ELBди көрсөтүп турган CNAME бар салмактанып алынган DNS рекорддорун колдонуу менен түзүлгөн. Кесүү үчүн, биз Кубернетес жаңы ELB кызматын көрсөтүп, салмагы 0 болгон жаңы рекордду коштук. Андан кийин биз рекорддун убактысын (TTL) 0 деп койдук. Андан кийин эски жана жаңы салмактар ​​акырындык менен туураланды. акыры 100% жаңы серверде бүтөт. Кыскартуу аяктагандан кийин, TTL бир топ акылга сыярлык нерсеге даярдалды.

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

үйрөнүү

Тармак кездемелеринин чектери

2019-жылдын 8-январындагы таң эрте, Тиндердин платформасы үзгүлтүккө учурады. Эртеси эрте менен платформанын кечигүү менен байланышкан көбөйүшүнө жооп кылып, кластерде штанга жана түйүн санактары аныкталды. Натыйжада, биздин бардык түйүндөрдө ARP кэши түгөндү.

ARP кэшине тиешелүү үч Linux мааниси бар:

Кредит

gc_thresh3 - катуу капкак. Эгерде сиз "коңшуларга үстөлдүн толуп кетиши" журналына кирсеңиз, бул ARP кэшинин синхрондуу таштандыларын чогултуудан кийин, кошунанын жазууларын сактоо үчүн орун жетишсиз экендигин көрсөтүп турат. Бул учурда, данек пакетти толугу менен таштайт.

Фланнелди Кубернеттеги тармактык кездеме катары колдонобуз. Пакеттер 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) кирүүгө алып келет. Алар жумушчу түйүнү биринчи жолу ишке киргенде же ар бир жаңы түйүн ачылганда кошулат.

Мындан тышкары, "тырмактан" ("pod-to-pod") байланыш акыры eth0 интерфейсинин үстүнөн агып өтөт (жогорудагы Фланнел диаграммасында). Натыйжада, ар бир тиешелүү түйүн булагы жана түйүн көздөгөн жери үчүн ARP таблицасына кошумча жазуу киргизилет.

Биздин чөйрөдө байланыштын бул түрү өтө кеңири таралган. Биздин Kubernetes тейлөө объектилеринде ELB түзүлөт жана Кубернетес бардык түйүндөрдү ELB менен каттайт. ELB эч нерсени билбейт жана тандалган түйүн пакеттин акыркы багыты болбошу мүмкүн. Себеби, түйүн пакетти ELBден алгандан кийин, тейлөө үчүн анын иптабл эрежелерин баалайт жана кокусунан башка түйүндүн ичинде сойлокту тандап алат.

Электр жарыгы өчүп калган учурда, кластерде 605 жалпы түйүн бар болчу. Жогоруда айтылган себептерден улам, демейки gc_thresh3 маанисин туташтыруу үчүн жетиштүү болду. Бул ишке ашкандан кийин, пакеттер гана түшүп калбастан, ARP таблицасында Flannel / виртуалдык дарек мейкиндигинин бардык 24 боштугу жок. Туташуу түйүнү жана DNS издөө иштери ишке ашкан жок. (DNS кластердин ичинде жайгаштырылган, бул макалада кийинчерээк кеңири түшүндүрүлөт.)

Чечүү үчүн, gc_thresh1, gc_thresh2 жана gc_thresh3 маанилери көтөрүлүп, жетишпеген тармактарды кайрадан каттоо үчүн Flannel кайра жүргүзүлүшү керек.

Күтүүсүздөн масштабда DNS иштетилүүдө

Биздин миграцияны камсыз кылуу үчүн, DNS трафикти күчөтүп, трафиктин калыптанышына жана биздин кызматтар үчүн эскиден Кубернетке чейин өсүп чыгууга жардам берди. Байланышкан Route53 RecordSetsке салыштырмалуу төмөн TTL маанилерин койдук. Эскиз инфраструктурасын EC2 нускаларында иштеткенибизде, биздин конфигурациялуу конфигурациябыз Amazon'дун DNSти көрсөтүп турат. Биз муну талапка ылайык деп таптык жана Amazon компаниясынын кызматтары (мисалы DynamoDB) үчүн салыштырмалуу төмөн TTLдин баасы байкалбай калды.

Кубернетеске барган сайын көбүрөөк кызматтарды кыдырып, секундасына 250,000 суроого жооп бере турган DNS кызматын иштетип чыктык. Колдонмолорубуздун ичинде үзгүлтүксүз жана таасирдүү DNS издөө убакыты болду. Бул толук жөндөө аракетине жана DNS провайдеринин CoreDNS жайгаштырылышына карабастан, бир учурда 120 өзөктү керектеген 1000 подиумга жеткен.

Башка мүмкүн болгон себептерди жана чечимдерди изилдөөдө, Linux пакетин чыпкалоо нетфильтерине таасир эткен жарыштын абалын сүрөттөгөн макаланы таптык. Биз көргөн DNS тайм-ауттары жана Flannel интерфейсиндеги insert_failed эсептегич макаланын жыйынтыктарына дал келген.

Маселе Source and Destination Network Даректи Которуунун (SNAT жана DNAT) которулушунда жана кийинчерээк кошумча шилтеме столуна киргизилгенде пайда болот. Коомчулук сунуш кылган жана иштелип чыккан көйгөйдүн бири - DNSти жумушчу түйүнүнө өткөрүп берүү. Бул учурда:

  • SNAT кереги жок, анткени трафик түйүндө жергиликтүү жерде турат. Аны Eth0 интерфейси аркылуу өткөрүүнүн кажети жок.
  • DNAT кереги жок, анткени көздөлүүчү IP түйүндүн ичинде жайгашкан жана iptables эрежелери үчүн кокусунан тандалган эмес.

Ушул ыкма менен алдыга жылууну чечтик. CoreDNS Кубернеттеги DaemonSet катары жайгаштырылган жана биз кубелеттин - cluster-dns буйрук желегин конфигурациялап, ар бир pod-rez.conf ичине түйүндүн жергиликтүү DNS серверин киргиздик. Бул көнүгүү DNS тыныгуусу үчүн натыйжалуу болду.

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

Жакшыраак жетишүү үчүн элчинин жардамы менен жүктөрдү баланстоо

Кубернетеске өткөрүп берүү кызматыбызды көчүргөндө, биз бактардагы тең салмаксыз жүктөрдөн жапа чегип баштадык. HTTP Keepalive улам, ELB туташуулары ар бир жылдыруунун биринчи даяр тилкелерине жабышып калгандыгын байкадык, ошондуктан трафиктин көпчүлүгү колдо болгон кукалардын аз гана пайызы аркылуу агып жатты. Эң биринчи жумшартуунун бири, эң начар кылмышкерлер үчүн 100% MaxSurge программасын колдонуу. Бул кээ бир ири жайгаштыруулар менен натыйжалуу жана туруктуу эмес узак мөөнөттүү.

Биз колдонгон дагы бир жумшартуу - бул кризистик кызматтарга ресурстардын суроо-талабын жасалма жол менен көбөйтүү, ошондо башка оор сойкулар менен катар колокустары дагы чоңураак болот. Ресурстардын ысырапкорлугунан улам, бул узак мөөнөттүү келечекте иштей албай калат жана биздин Түйүн колдонмолору бирдиктүү жип менен натыйжада 1 өзөктө жайгашкан. Жалгыз гана айкын чечим - жүктөрдү баланстоону жакшыртуу.

Ички элчинин ишин баалоо үчүн издедик. Бул бизге аны өтө чектелүү түрдө жайып, тез арада пайда алып келе турган мүмкүнчүлүк берди. Элчи бул ири кызмат көрсөтүүгө багытталган архитектуралар үчүн иштелип чыккан Layer 7 проектиси, ачык булак. Автоматтык түрдө кайталоону, электр тутумун бузууну жана дүйнөлүк ылдамдыкты чектөөнү камтыган жүктөрдү баланстоонун алдыңкы ыкмаларын колдонууга жөндөмдүү.

Биз иштеп чыккан конфигурацияга бир каттамы жана кластери болгон ар бир тирегичтин жанында Элчи өкүлдүн тротуарынын жергиликтүү контейнер портуна жетиши керек болчу. Потенциалдык каскадды минималдаштыруу жана жарылуу радиусунун кичинекей болушун камсыз кылуу үчүн, ар бир кызмат үчүн ар бир жеткиликтүүлүк зонасында (AZ) жайгаштырылган Envoy алдыңкы прокси тутумдарынын паркын колдондук. Булар биздин инженерлерибиздин биринин кызматын ачуу чакан механизмин бузуп, ар бир AZ кызматына берилген ар бир Яздагы шыбактын тизмесин кайтарып берди.

Тейлөө кызматынын алдыңкы элчилери бул кызматты ачуу механизмин бир агымдагы кластер жана каттамдар менен колдонушту. Акылга сыярлык үзгүлтүккө учурадык, электр өткөргүчтүн бардык жөндөөлөрүн күчөттүк, андан кийин убактылуу иштебей калган жана оңой жайылтууга жардам берүү үчүн минималдык аракет конфигурациясын киргиздик. Бул ар бир алдыңкы өкүлдүн кызматын TCP ELB менен алдыңыз. Биздин алдыңкы прокси катмардын сактоочусу белгилүү бир Envoy подкастарына кадалган күндө дагы, алар жүктү көтөрө алышкан жана эң аз_request аркылуу арткыга чейин тең салмакташкан.

Бөлүштүрүү үчүн, колдонмонун жана капталдын капталындагы PreStop илгичин колдондук. Бул капталдагы салмакты текшерүү деп аталган илгич администратордун акыркы чекитин, кичинекей уйку менен кошо, жарык берүү туташууларын толуктап, суусуз калтырууга бир аз убакыт берет.

Биз ушунчалык тез кыймылдай алганыбыздын бир себеби, кадимки Prometheus орнотуусу менен оңой эле айкалыштыра алган бай көрсөткүчтөрдөн улам болду. Бул конфигурацияны жөндөп, трафикти кыскарткандыктан, эмне болуп жатканын так көрүүгө мүмкүнчүлүк берди.

Натыйжалар дароо эле айкын болду. Биз эң салмаксыз кызматтардан баштадык жана ушул тапта ал биздин кластердеги он эки эң маанилүү кызматтардын алдында иштеп жатат. Быйыл биз толук кандуу тейлөөчү торго өтүүнү пландап жатабыз, ал кызматтарды өркүндөтүп, райондук үзгүлтүккө учурап, сырткы абалды аныктоо, ылдамдыкты чектөө жана көзөмөлдөө.

Сүрөт 3–1 CPU элчини бөлүштүрүү учурунда бир кызматтын конвергенциясы

Жыйынтык

Ушул изилдөөлөрдүн жана кошумча изилдөөлөрдүн натыйжасында биз Кубернеттеги ири кластерлерди кантип долбоорлоону, жайгаштырууну жана иштетүүнү жакшы билген күчтүү ички инфраструктура тобун түздүк. Тиндердин бүт инженердик уюму азыр Кубернеттеги контейнерлерди кантип жайылтуу жана кантип жайгаштыруу боюнча билимге жана тажрыйбага ээ.

Мурдагы эски инфраструктурабызда, кошумча масштаб талап кылынганда, биз онлайн режиминде EC2 жаңы инстанцияларынын чыгышын күтүп бир нече мүнөттөр бою кыйналдык. Контейнерлер азыр трафикти бир нече мүнөттөргө салыштырмалуу бир нече секунда ичинде тейлешет. Бир контейнерди бир EC2 үлгүсүнө жайгаштыруу, горизонталдуу тыгыздыкты жакшыртат. Натыйжада, биз EC2де 2019-жылы өткөн жылга салыштырмалуу олуттуу чыгымдарды үнөмдөп жатабыз.

Эки жылга жакын убакыт өттү, бирок биз 2019-жылдын март айында миграцияны аяктадык. Tinder платформасы 200 кызматтан, 1000 түйүндөн, 15000 кесектен жана 48000 контейнерден турган Кубернетес кластеринде иштейт. Инфраструктура мындан ары биздин операциялык топторго жүктөлгөн милдет эмес. Андан көрө, уюмдун бардык инженерлери бул жоопкерчиликти бөлүшүшөт жана алардын колдонмолорунун кандайча код менен иштелип чыккандыгын жана көзөмөлдөп турушат.