Flutningur Tinder til Kubernetes

Skrifað af: Chris O'Brien, verkfræðistjóri | Chris Thomas, verkfræðistjóri | Jinyong Lee, yfirmaður hugbúnaðarverkfræðings | Klippt af: Cooper Jackson, hugbúnaðarverkfræðingi

Af hverju

Fyrir tæpum tveimur árum ákvað Tinder að flytja vettvang sinn til Kubernetes. Kubernetes gaf okkur tækifæri til að keyra Tinder Engineering í átt að gámagerð og aðgerð með litla snertingu með óbreytanlegri dreifingu. Uppbygging forrits, dreifing og innviði væri skilgreindur sem kóða.

Við vorum líka að leita að því að takast á við stærðargráðu og stöðugleika. Þegar stigstærð varð mikilvæg urðum við oft í nokkrar mínútur að bíða eftir því að ný EC2 tilvik komu á netinu. Hugmyndin um að gáma tímaáætlun og þjóna umferð innan sekúndna öfugt við nokkrar mínútur var aðlaðandi fyrir okkur.

Það var ekki auðvelt. Við fólksflutninga snemma árs 2019, náðum við mikilvægum massa innan Kubernetes þyrpingarinnar okkar og fórum að lenda í ýmsum áskorunum vegna umferðarmagns, stærðar klasans og DNS. Við leystum áhugaverðar áskoranir um að flytja 200 þjónustu og reka Kubernetes þyrpingu á kvarðanum samanlagt 1.000 hnúta, 15.000 fræbelgjum og 48.000 hlaupagáma.

Hvernig

Frá og með janúar 2018 unnum við okkur í gegnum ýmis stig flóttamannaátaksins. Við byrjuðum á því að gáma alla þjónustu okkar og dreifa þeim í röð Kubernetes farfuglaheimili fyrir leiksvið. Í byrjun október fórum við með aðferðaflutningi að flytja alla arfleifðar þjónustu okkar til Kubernetes. Í mars árið eftir kláruðum við búferlaflutninga okkar og Tinder pallurinn keyrir nú eingöngu á Kubernetes.

Að byggja myndir fyrir Kubernetes

Það eru meira en 30 frumkóða geymslur fyrir smásöluþjónusturnar sem eru í gangi í Kubernetes þyrpingunni. Kóðinn í þessum geymslum er skrifaður á mismunandi tungumálum (td Node.js, Java, Scala, Go) með mörg afturkreppsumhverfi fyrir sama tungumál.

Byggingarkerfið er hannað til að starfa á fullkomlega sérhannaða „byggja samhengi“ fyrir hverja smásöluþjónustu, sem venjulega samanstendur af Dockerfile og röð skelin skipana. Þó að innihald þeirra sé aðlagað að fullu eru þessi byggingarsamhengi öll samin með stöðluðu sniði. Stöðlun byggingarsamhengisins gerir eitt byggingarkerfi kleift að meðhöndla allar smásjárþjónustu.

Mynd 1–1 Staðlað byggingarferli í gegnum byggingagáminn

Til að ná hámarks samræmi milli afturkreppsumhverfis er sama smíðaferli notað á þróunar- og prófunarstiginu. Þetta lagði sérstaka áskorun þegar við þurftum að móta leið til að tryggja stöðugt byggingarumhverfi yfir pallinn. Fyrir vikið eru allir byggingarferlar framkvæmdir í sérstökum „Builder“ gám.

Innleiðing Builder gámsins krafðist fjölda háþróaðra Docker tækni. Þessi byggingarílát erfir staðbundið notandakenni og leyndarmál (td SSH lykil, AWS persónuskilríki osfrv.) Eins og krafist er til að fá aðgang að einkareknum geymslum Tinder. Það er sett saman staðbundin möppur sem innihalda frumkóðann til að hafa náttúrulega leið til að geyma smíðar úr smíðum. Þessi aðferð bætir frammistöðu, vegna þess að hún kemur í veg fyrir að afrita innbyggða gripi milli byggingarílátsins og vélarinnar. Geymdir smíðir eru endurnýttir næst án frekari uppsetningar.

Fyrir ákveðna þjónustu þurftum við að búa til annan gám innan Byggingaraðila til að passa saman tímaumhverfið við keyrslutímumhverfið (td með því að setja upp Node.js bcrypt bókasafn býr til pallur-sérstakur tvöfaldur gripur). Kröfur um samantekt geta verið mismunandi milli þjónustu og endanleg Dockerfile er samin á flugu.

Kubernetes þyrping arkitektúr og fólksflutninga

Þyrping stærð

Við ákváðum að nota kube-aws fyrir sjálfvirkt klasaútveg í Amazon EC2 tilvikum. Snemma vorum við að keyra allt í einni almennri hnútapotti. Við fundum fljótt þörfina á að aðgreina vinnuálag í mismunandi stærðir og gerðir af tilvikum til að nýta auðlindirnar betur. Rökstuðningurinn var sá að með því að keyra færri þráðþráð belga saman skilaði fyrirsjáanlegri árangur árangri fyrir okkur en að láta þá lifa saman við stærri fjölda einþráða belg.

Við settumst að:

  • m5.4xlstækkun fyrir eftirlit (Prometheus)
  • c5.4xlarge fyrir Node.js vinnuálag (eins þráður vinnuálag)
  • c5.2xlarge fyrir Java og Go (fjölþráður vinnuálag)
  • c5.4xlstærð fyrir stjórnplanið (3 hnútar)

Búferlaflutningar

Eitt af undirbúningsskrefunum fyrir flutninginn frá eldri grunnvirkjum okkar til Kubernetes var að breyta núverandi samskiptum milli þjónustu og þjónustu til að vísa til nýrra teygjanlegra hleðslujafnvægis (ELB) sem voru búin til í sérstöku Virtual Private Cloud (VPC) undirneti. Þetta undirnet var kíkt á VPC Kubernetes. Þetta gerði okkur kleift að flytja mát með nákvæmni án tillits til sérstakrar pöntunar eftir þjónustufíkn.

Þessir endapunktar voru búnir til með því að nota vegið DNS-upptökusett sem hafði CNAME sem vísaði á hvert nýtt ELB. Til að bæta við bættum við nýju meti og bentum á nýja Kubernetes þjónustuna ELB, með þyngd 0. Við stilltum síðan Time To Live (TTL) á plötusettinu á 0. Gamla og nýja lóðin var síðan stillt hægt endar að lokum með 100% á nýja netþjóninum. Eftir að niðurskurði var lokið var TTL stillt á eitthvað sanngjarnt.

Java-einingarnar okkar heiðruðu lágt DNS TTL, en hnútforritin okkar ekki. Einn verkfræðingurinn okkar skrifaði um hluta af kóða tengingarlaugarinnar til að vefja hann í stjórnanda sem endurnærði sundlaugarnar á sjötugsaldri. Þetta virkaði mjög vel fyrir okkur án merkjanlegs árangurshöggs.

Nám

Net dúkmarka

Snemma á morgnana 8. janúar 2019 varð Tinder's Platform fyrir þrálátum afleiðingum. Til að bregðast við ótengdri aukningu á seinkun pallsins fyrr um morguninn voru talningar á fræbelgum og hnút minnkaðir á þyrpingunni. Þetta leiddi til örmögnun ARP skyndiminni á öllum hnútunum okkar.

Það eru þrjú Linux gildi sem tengjast ARP skyndiminni:

Trúnaður

gc_thresh3 er hörð húfa. Ef þú ert að fá „nágrannatafla yfirfall“ skráarfærslur bendir þetta til þess að jafnvel eftir samstillt sorpsöfnun (GC) í ARP skyndiminni var ekki nóg pláss til að geyma nágrannainnganginn. Í þessu tilfelli sleppir kjarninn pakkanum bara að öllu leyti.

Við notum Flannel sem netefni okkar í Kubernetes. Pakkar eru sendir í gegnum VXLAN. VXLAN er Layer 2 yfirlagsskipulag yfir Layer 3 net. Það notar MAC Address-in-User Datagram Protocol (MAC-in-UDP) umbreytingu til að veita leið til að lengja lag 2 netkerfis. Samgöngur siðareglur yfir líkamlega gagnamiðstöðvarnetið er IP plús UDP.

Mynd 2–1 Flannel skýringarmynd (inneign)

Mynd 2–2 VXLAN pakki (inneign)

Hver Kubernetes starfsmaður hnútur úthlutar eigin / 24 af raunverulegu heimilisfangi út úr stærri / 9 reitnum. Fyrir hvern hnút leiðir þetta til 1 leiðatöflufærsla, 1 ARP töflufærsla (á flannel.1 viðmóti) og 1 framsendingar gagnagrunn (FDB) færslu. Þessu er bætt við þegar hnút starfsmannsins ræsir fyrst eða þegar hver nýr hnútur uppgötvast.

Að auki rennur samskipti hnút-til-fræbelg (eða pod-to-pod) að lokum yfir eth0 viðmótið (lýst í Flannel skýringarmyndinni hér að ofan). Þetta mun leiða til viðbótar færslu í ARP töfluna fyrir hvern samsvarandi hnút uppsprettu og ákvörðunarstað.

Í umhverfi okkar eru þessi tegund samskipta mjög algeng. Fyrir Kubernetes þjónustuhlutina okkar er ELB búinn til og Kubernetes skráir hvern hnút hjá ELB. ELB er ekki kunnugt um fræbelginn og hnúturinn sem valinn er kann að vera ekki lokaáfangastaður pakkans. Þetta er vegna þess að þegar hnúturinn tekur við pakkanum frá ELB, metur hann iptables-reglur sínar fyrir þjónustuna og velur handahófi á annan hnút.

Þegar hlé var gert voru 605 alls hnútar í þyrpingunni. Af þeim ástæðum sem lýst er hér að ofan var þetta nóg til að myrkvast sjálfgefið gc_thresh3 gildi. Þegar þetta gerist er ekki aðeins verið að láta pakka falla, heldur vantar allt Flannel / 24s af raunverulegu heimilisfangi í ARP töflunni. Hnút til að fræva samskipti og DNS leit mistakast. (DNS er hýst innan þyrpingarinnar, eins og nánar verður útskýrt síðar í þessari grein.)

Til að leysa það eru gc_thresh1, gc_thresh2 og gc_thresh3 gildi hækkuð og Flannel verður að endurræsa til að skrá sig vantar net.

Óvænt að keyra DNS á mælikvarða

Til að koma til móts við fólksflutninga nýttum við okkur DNS til að auðvelda mótun umferðar og stigvaxandi niðurskurð frá arfleifð til Kubernetes vegna þjónustu okkar. Við setjum tiltölulega lágt TTL gildi á tilheyrandi Route53 RecordSets. Þegar við stjórnuðum eldri innviði okkar í EC2 tilvikum, benti upplausn okkar á DNS Amazon. Við tókum þetta sem sjálfsögðum hlut og kostnaðurinn við tiltölulega lágt TTL fyrir þjónustu okkar og þjónustu Amazon (td DynamoDB) fór að mestu leyti fram.

Þegar við fórum um borð í sífellt fleiri þjónustu við Kubernetes fundum við okkur með DNS-þjónustu sem svaraði 250.000 beiðnum á sekúndu. Við fundum með tímabundnum og áhrifamiklum tíma í leit að DNS í umsóknum okkar. Þetta gerðist þrátt fyrir tæmandi stillingaráreynslu og DNS-veitandi skipti yfir í CoreDNS dreifingu sem náði í einu hámarki í 1.000 belgjum sem neyttu 120 kjarna.

Við rannsóknir á öðrum mögulegum orsökum og lausnum fundum við grein sem lýsir keppnisástandi sem hefur áhrif á Linux pakkasíunarramma netfilter. DNS-tímamörkin sem við vorum að sjá, ásamt auknum insert_failed teljara í Flannel viðmótinu, í takt við niðurstöður greinarinnar.

Málið kemur upp meðan á þýðingu Heimilisfangfanga og ákvörðunarneta á neti (SNAT og DNAT) stendur og í kjölfarið sett í töfluna. Ein lausn sem rædd var innra með og samfélagið lagði til var að færa DNS yfir á starfsmannahnútinn sjálfan. Í þessu tilfelli:

  • SNAT er ekki nauðsynlegt vegna þess að umferðin dvelur á staðnum á hnútnum. Það þarf ekki að senda yfir eth0 viðmótið.
  • DNAT er ekki nauðsynlegt vegna þess að ákvörðunarstaður IP er staðbundinn við hnútinn og ekki valinn hylki af handahófi samkvæmt reglum um iptables.

Við ákváðum að halda áfram með þessa nálgun. CoreDNS var sent sem DaemonSet í Kubernetes og við sprautuðum staðbundnum DNS netþjóni hnútins í resolv.conf hvers fræbelgs með því að stilla kubelet - cluster-dns skipunarfána. Lausnin var árangursrík við tímamörk DNS.

Hins vegar sjáum við ennþá falla pakka og innsetningarfallsfléttu Flannel viðmótsins. Þetta mun halda áfram jafnvel eftir ofangreinda lausn vegna þess að við forðumst aðeins SNAT og / eða DNAT fyrir DNS-umferð. Hlaupið ástand mun enn eiga sér stað fyrir aðrar tegundir af umferð. Til allrar hamingju eru flestir pakkarnir okkar TCP og þegar ástandið kemur upp verða pakkar sendir með góðum árangri. Langtímaleiðrétting fyrir allar gerðir af umferð er eitthvað sem við erum enn að ræða.

Nota sendiboði til að ná betri hleðslujafnvægi

Þegar við fluttum stuðningsþjónustu okkar til Kubernetes, fórum við að þjást af ójafnvægi álagi yfir belg. Við uppgötvuðum að vegna HTTP Keepalive festust ELB-tengingar við fyrstu tilbúnu belgina í hverri veltivinnu, þannig að mest umferð streymdi um lítið hlutfall af tiltæku belgunum. Ein fyrsta mótvægið sem við reyndum var að nota 100% MaxSurge við nýjar sendingar fyrir verstu brotamennina. Þetta var lítil áhrif og ekki sjálfbær til langs tíma með sumum stærri dreifingum.

Önnur mótvægisaðgerðir sem við notuðum var að blása tilbúnar beiðnir í gagnrýna þjónustu þannig að bólusettir belgir fengju meira lofthæð ásamt öðrum þungum belg. Þetta ætlaði heldur ekki að verða endingargott til langs tíma litið vegna úrgangs í úrræðum og hnútaforritin okkar voru einþráður og því í raun lokaðir í 1 kjarna. Eina skýra lausnin var að nýta betri burðarjöfnun.

Við höfðum verið að leita að því að meta sendimanninn. Þetta gaf okkur tækifæri til að beita því á mjög takmarkaðan hátt og uppskera strax ávinning. Sendiráðið er opinn hugbúnaður, framúrskarandi Layer 7 umboð hannaður fyrir stóra þjónustu-stilla arkitektúr. Það er hægt að innleiða háþróaða álagsjöfnunartækni, þar með talið sjálfvirkar tilraunir, rofabrot og hraðatakmarkanir.

Samskipanin sem við komumst upp með var að hafa sendibifreið sendibifreiðar við hlið hverrar fræbelgs sem hafði eina leið og þyrpingu til að lemja gámaheimilið á staðnum. Til að lágmarka hugsanlegan þrengingu og til að halda litlum sprengivirkni notuðum við flota af framsenda proxy sendimiðlum, ein dreifing í hverju tiltækisvæði (AZ) fyrir hverja þjónustu. Þessir lentu í litlum þjónustuuppgötvunartækjum sem einn verkfræðinganna okkar setti saman sem skilaði einfaldlega lista yfir belg í hverju AZ fyrir tiltekna þjónustu.

Þjónustufyrirtækin sem notuðu framhliðina nýttu síðan þennan þjónustu uppgötvunarbúnað með einni andstreymisþyrping og leið. Við stilltum hæfilegan tímahlé, efldum allar stillingar fyrir aflrofar og settum síðan í lágmarks að prófa aftur til að hjálpa við tímabundna bilun og slétta dreifingu. Við framhlið hverri þessari framsenda þjónustu með TCP ELB. Jafnvel þó að viðhaldslokið frá aðalframboðssætinu okkar að framan hafi verið fest á ákveðin sendiboða, þá voru þeir miklu betur færir um að takast á við byrðarnar og voru búnar til að koma jafnvægi í gegnum amk beiðni um stuðninginn.

Við dreifingu notuðum við preStop krók bæði á forritið og hliðarvagninn. Þessi krókur sem kallast heilsueftirlit hliðarvagnsins mistakast endapunkt adminar ásamt litlum svefni til að gefa smá tíma til að leyfa inflight tengingum að ljúka og tæma.

Ein ástæðan fyrir því að við gátum hreyft okkur svo hratt var vegna ríku mæligildanna sem við gátum auðveldlega samlagast venjulegu Prometheus skipulaginu. Þetta gerði okkur kleift að sjá nákvæmlega hvað var að gerast þegar við gerðum endurtekningar á stillingum og skera úr umferð.

Niðurstöðurnar voru strax og augljósar. Við byrjuðum á mestu jafnvægisþjónustunum og á þessum tímapunkti er hún í gangi fyrir framan tólf mikilvægustu þjónusturnar í þyrpingunni okkar. Í ár stefnum við að því að fara yfir í netþjónustu í fullri þjónustu, með fullkomnari þjónustuuppgötvun, brautarbrotum, uppgötvun útfara, hraðatakmörkun og rekja.

Mynd 3–1 CPU samleitni einnar þjónustu meðan á yfirvinnu stendur til sendimanns

Lokaniðurstaðan

Með þessum lærdómi og viðbótarrannsóknum höfum við þróað sterkt innviði teymi með mikla þekkingu á því hvernig hanna, dreifa og reka stóra Kubernetes þyrpingu. Öll verkfræðistofnun Tinder hefur nú þekkingu og reynslu um hvernig hægt er að gáma og dreifa forritum sínum á Kubernetes.

Í grunngerð okkar, þegar þörf var á viðbótarstærð, urðum við oft í nokkrar mínútur að bíða eftir að nýjar EC2 tilvik komist á netið. Ílát skipuleggja og þjóna umferð innan sekúndna öfugt við nokkrar mínútur. Að skipuleggja marga gáma á einu EC2 dæmi gefur einnig betri láréttan þéttleika. Fyrir vikið áætlum við mikinn kostnaðarsparnað á EC2 árið 2019 miðað við árið á undan.

Það tók næstum tvö ár, en við lukum flutningi okkar í mars 2019. Tinder pallurinn keyrir eingöngu á Kubernetes þyrpingu sem samanstendur af 200 þjónustu, 1.000 hnútum, 15.000 fræbelgjum og 48.000 gámum í gangi. Innviðir eru ekki lengur verkefni sem er frátekið fyrir rekstrarteymi okkar. Þess í stað deila verkfræðingar um allt skipulagið í þessari ábyrgð og hafa stjórn á því hvernig forritin eru byggð og notuð með allt sem kóða.