Nodyn. traws.: Yn ddiweddar, rhannodd gweithwyr y gwasanaeth Tinder byd enwog rai manylion technegol am fudo eu seilwaith i Kubernetes. Cymerodd y broses bron i ddwy flynedd ac arweiniodd at lansio llwyfan ar raddfa fawr iawn ar K8s, yn cynnwys 200 o wasanaethau wedi'u cynnal ar 48 mil o gynwysyddion. Pa anawsterau diddorol y daeth peirianwyr Tinder ar eu traws a pha ganlyniadau y daethant iddynt? Darllenwch y cyfieithiad hwn.
Pam?
Bron i ddwy flynedd yn ôl, penderfynodd Tinder symud ei lwyfan i Kubernetes. Byddai Kubernetes yn caniatáu i dîm Tinder gynhwysiant a symud i gynhyrchu heb fawr o ymdrech trwy ddefnydd na ellir ei gyfnewid (defnydd digyfnewid). Yn yr achos hwn, byddai cydosod ceisiadau, eu defnydd, a'r seilwaith ei hun yn cael eu diffinio'n unigryw gan god.
Roeddem hefyd yn chwilio am ateb i'r broblem o scalability a sefydlogrwydd. Pan ddaeth graddio'n dyngedfennol, yn aml roedd yn rhaid i ni aros sawl munud i achosion EC2 newydd ddeillio. Daeth y syniad o lansio cynwysyddion a dechrau gwasanaethu traffig mewn eiliadau yn lle munudau yn ddeniadol iawn i ni.
Trodd y broses allan i fod yn anodd. Yn ystod ein mudo yn gynnar yn 2019, cyrhaeddodd clwstwr Kubernetes màs critigol a dechreuom ddod ar draws problemau amrywiol oherwydd maint y traffig, maint y clwstwr, a DNS. Ar hyd y ffordd, gwnaethom ddatrys llawer o broblemau diddorol yn ymwneud â mudo 200 o wasanaethau a chynnal clwstwr Kubernetes sy'n cynnwys 1000 o nodau, 15000 o godennau a 48000 o gynwysyddion rhedeg.
Как?
Ers mis Ionawr 2018, rydym wedi mynd trwy gamau mudo amrywiol. Dechreuon ni trwy roi ein holl wasanaethau mewn cynhwysydd a'u defnyddio i amgylcheddau cwmwl prawf Kubernetes. Gan ddechrau ym mis Hydref, gwnaethom ddechrau symud yr holl wasanaethau presennol i Kubernetes yn drefnus. Erbyn mis Mawrth y flwyddyn ganlynol, gwnaethom gwblhau'r mudo a nawr mae platfform Tinder yn rhedeg ar Kubernetes yn unig.
Adeiladu delweddau ar gyfer Kubernetes
Mae gennym dros 30 o storfeydd cod ffynhonnell ar gyfer microwasanaethau sy'n rhedeg ar glwstwr Kubernetes. Mae'r cod yn y storfeydd hyn wedi'i ysgrifennu mewn gwahanol ieithoedd (er enghraifft, Node.js, Java, Scala, Go) gydag amgylcheddau amser rhedeg lluosog ar gyfer yr un iaith.
Mae'r system adeiladu wedi'i chynllunio i ddarparu “cyd-destun adeiladu” cwbl addasadwy ar gyfer pob microwasanaeth. Fel arfer mae'n cynnwys Dockerfile a rhestr o orchmynion cregyn. Mae eu cynnwys yn gwbl addasadwy, ac ar yr un pryd, mae'r holl gyd-destunau adeiladu hyn wedi'u hysgrifennu yn ôl fformat safonol. Mae safoni cyd-destunau adeiladu yn caniatáu i un system adeiladu ymdrin â'r holl ficrowasanaethau.
Ffigur 1-1. Proses adeiladu safonol trwy gynhwysydd Builder
Er mwyn sicrhau'r cysondeb mwyaf rhwng amseroedd rhedeg (amgylcheddau amser rhedeg) defnyddir yr un broses adeiladu wrth ddatblygu a phrofi. Roedd her ddiddorol iawn yn ein hwynebu: roedd yn rhaid i ni ddatblygu ffordd o sicrhau cysondeb yn yr amgylchedd adeiladu ar draws y platfform cyfan. Er mwyn cyflawni hyn, cynhelir yr holl brosesau cydosod y tu mewn i gynhwysydd arbennig. Builder.
Roedd ei weithrediad cynhwysydd yn gofyn am dechnegau Docker uwch. Mae Builder yn etifeddu'r ID defnyddiwr lleol a'r cyfrinachau (fel allwedd SSH, tystlythyrau AWS, ac ati) sy'n ofynnol i gael mynediad i ystorfeydd Tinder preifat. Mae'n gosod cyfeiriaduron lleol sy'n cynnwys ffynonellau i storio arteffactau adeiladu yn naturiol. Mae'r dull hwn yn gwella perfformiad oherwydd ei fod yn dileu'r angen i gopïo arteffactau adeiladu rhwng y cynhwysydd Builder a'r gwesteiwr. Gellir ailddefnyddio arteffactau adeiladu wedi'u storio heb gyfluniad ychwanegol.
Ar gyfer rhai gwasanaethau, roedd yn rhaid i ni greu cynhwysydd arall i fapio'r amgylchedd casglu i'r amgylchedd amser rhedeg (er enghraifft, mae llyfrgell bcrypt Node.js yn cynhyrchu arteffactau deuaidd platfform-benodol yn ystod y gosodiad). Yn ystod y broses grynhoi, gall gofynion amrywio rhwng gwasanaethau, a chaiff y Dockerfile terfynol ei lunio ar y hedfan.
Pensaernïaeth clwstwr Kubernetes a mudo
Rheoli maint clwstwr
Fe benderfynon ni ddefnyddio ciwb-aws ar gyfer lleoli clwstwr awtomataidd ar achosion Amazon EC2. Ar y cychwyn cyntaf, roedd popeth yn gweithio mewn un pwll cyffredin o nodau. Sylweddolwyd yn gyflym fod angen gwahanu llwythi gwaith yn ôl maint a math o enghraifft i wneud defnydd mwy effeithlon o adnoddau. Y rhesymeg oedd bod rhedeg sawl codyn aml-edau llwythog wedi troi allan i fod yn fwy rhagweladwy o ran perfformiad na'u cydfodolaeth â nifer fawr o godennau un edau.
Yn y diwedd fe wnaethom setlo ar:
- m5.4xlarge — ar gyfer monitro (Prometheus);
- c5.4xlarge - ar gyfer llwyth gwaith Node.js (llwyth gwaith un edau);
- c5.2xlarge - ar gyfer Java a Go (llwyth gwaith aml-ddarllen);
- c5.4xlarge - ar gyfer y panel rheoli (3 nod).
Yr ymfudo
Un o'r camau paratoadol ar gyfer mudo o'r hen seilwaith i Kubernetes oedd ailgyfeirio'r cyfathrebu uniongyrchol presennol rhwng gwasanaethau i'r balanswyr llwyth newydd (Cydbwysyddion Llwyth Elastig (ELB). Cawsant eu creu ar is-rwydwaith penodol o gwmwl preifat rhithwir (VPC). Roedd yr is-rwydwaith hwn wedi'i gysylltu â VPC Kubernetes. Caniataodd hyn i ni symud modiwlau yn raddol, heb ystyried trefn benodol dibyniaethau gwasanaeth.
Crëwyd y pwyntiau terfyn hyn gan ddefnyddio setiau pwysol o gofnodion DNS a oedd â CNAMEs yn pwyntio at bob ELB newydd. I newid drosodd, fe wnaethom ychwanegu cofnod newydd yn pwyntio at ELB newydd y gwasanaeth Kubernetes gyda phwysau o 0. Yna fe wnaethom osod Amser i Fyw (TTL) y set cofnod i 0. Ar ôl hyn, y pwysau hen a newydd oedd wedi'i addasu'n araf, ac yn y pen draw anfonwyd 100% o'r llwyth i weinydd newydd. Ar ôl cwblhau'r newid, dychwelodd y gwerth TTL i lefel fwy digonol.
Gallai'r modiwlau Java a gawsom ymdopi â TTL DNS isel, ond ni allai'r cymwysiadau Node. Ailysgrifennodd un o'r peirianwyr ran o'r cod pwll cysylltiad a'i lapio mewn rheolwr a oedd yn diweddaru'r pyllau bob 60 eiliad. Gweithiodd y dull a ddewiswyd yn dda iawn a heb unrhyw ddirywiad amlwg mewn perfformiad.
Y gwersi
Terfynau'r Ffabrig Rhwydwaith
Yn gynnar yn y bore ar Ionawr 8, 2019, cwympodd platfform Tinder yn annisgwyl. Mewn ymateb i gynnydd digyswllt mewn hwyrni platfform yn gynharach y bore hwnnw, cynyddodd nifer y codennau a nodau yn y clwstwr. Achosodd hyn i'r storfa ARP gael ei disbyddu ar bob un o'n nodau.
Mae yna dri opsiwn Linux yn ymwneud â storfa ARP:
()
gc_tresh3 - mae hwn yn derfyn caled. Roedd ymddangosiad cofnodion “gorlif bwrdd cymdogion” yn y log yn golygu, hyd yn oed ar ôl casglu sbwriel cydamserol (GC), nad oedd digon o le yn y storfa ARP i storio'r cofnod cyfagos. Yn yr achos hwn, roedd y cnewyllyn yn taflu'r pecyn yn gyfan gwbl.
Rydym yn defnyddio fel ffabrig rhwydwaith yn Kubernetes. Trosglwyddir pecynnau dros VXLAN. Mae VXLAN yn dwnnel L2 a godwyd ar ben rhwydwaith L3. Mae'r dechnoleg yn defnyddio amgáu MAC-in-UDP (MAC Cyfeiriad-mewn-Defnyddiwr Datagram Protocol) ac yn caniatáu ehangu segmentau rhwydwaith Haen 2. Y protocol trafnidiaeth ar rwydwaith y ganolfan ddata ffisegol yw IP a CDU.
Ffigur 2–1. Diagram gwlanen ()
Ffigur 2-2. pecyn VXLAN ()
Mae pob nod gweithiwr Kubernetes yn dyrannu gofod cyfeiriad rhithwir gyda mwgwd /24 o floc /9 mwy. Ar gyfer pob nod mae hyn un cofnod yn y tabl llwybro, un cofnod yn y tabl ARP (ar y rhyngwyneb gwlanen.1), ac un cofnod yn y tabl newid (FDB). Cânt eu hychwanegu y tro cyntaf y bydd nod gweithiwr yn cael ei gychwyn neu bob tro y darganfyddir nod newydd.
Yn ogystal, mae cyfathrebu nod-pod (neu pod-pod) yn y pen draw yn mynd trwy'r rhyngwyneb eth0 (fel y dangosir yn y diagram gwlanen uchod). Mae hyn yn arwain at gofnod ychwanegol yn y tabl ARP ar gyfer pob ffynhonnell gyfatebol a gwesteiwr cyrchfan.
Yn ein hamgylchedd, mae'r math hwn o gyfathrebu yn gyffredin iawn. Ar gyfer gwrthrychau gwasanaeth yn Kubernetes, crëir ELB ac mae Kubernetes yn cofrestru pob nod gyda'r ELB. Nid yw'r ELB yn gwybod dim am godennau ac mae'n bosibl nad y nod a ddewiswyd fydd cyrchfan olaf y pecyn. Y pwynt yw, pan fydd nod yn derbyn pecyn gan yr ELB, ei fod yn ei ystyried gan ystyried y rheolau iptables ar gyfer gwasanaeth penodol ac yn dewis pod ar nod arall ar hap.
Ar adeg y methiant, roedd 605 o nodau yn y clwstwr. Am y rhesymau a nodir uchod, roedd hyn yn ddigon i oresgyn yr arwyddocâd gc_tresh3, sef y rhagosodiad. Pan fydd hyn yn digwydd, nid yn unig y mae pecynnau'n dechrau cael eu gollwng, ond mae'r gofod cyfeiriad rhithwir cyfan Wlanen gyda mwgwd /24 yn diflannu o'r tabl ARP. Amharir ar gyfathrebu pod nodau ac ymholiadau DNS (mae DNS yn cael ei gynnal mewn clwstwr; darllenwch yn ddiweddarach yn yr erthygl hon am fanylion).
I ddatrys y broblem hon, mae angen i chi gynyddu'r gwerthoedd gc_tresh1, gc_tresh2 и gc_tresh3 ac ailgychwyn Wlanen i ailgofrestru'r rhwydweithiau coll.
Graddio DNS annisgwyl
Yn ystod y broses fudo, fe wnaethom ddefnyddio DNS yn weithredol i reoli traffig a throsglwyddo gwasanaethau'n raddol o'r hen seilwaith i Kubernetes. Rydym yn gosod gwerthoedd TTL cymharol isel ar gyfer RecordSets cysylltiedig yn Route53. Pan oedd yr hen seilwaith yn rhedeg ar achosion EC2, cyfeiriodd ein cyfluniad datryswr at Amazon DNS. Cymerasom hyn yn ganiataol ac ni sylweddolwyd effaith y TTL isel ar ein gwasanaethau a gwasanaethau Amazon (fel DynamoDB).
Wrth inni fudo gwasanaethau i Kubernetes, canfuom fod DNS yn prosesu 250 mil o geisiadau yr eiliad. O ganlyniad, dechreuodd ceisiadau brofi cyfnodau cyson a difrifol ar gyfer ymholiadau DNS. Digwyddodd hyn er gwaethaf ymdrechion anhygoel i optimeiddio a newid y darparwr DNS i CoreDNS (a gyrhaeddodd y llwyth brig 1000 cod yn rhedeg ar greiddiau 120).
Wrth ymchwilio i achosion ac atebion posibl eraill, fe wnaethom ddarganfod , yn disgrifio amodau hil sy'n effeithio ar y fframwaith hidlo pecynnau netfilter yn Linux. Y seibiannau a welsom, ynghyd â rhifydd cynyddol insert_failed yn y rhyngwyneb Wlanen yn gyson â chanfyddiadau'r erthygl.
Mae'r broblem yn digwydd ar y cam o Gyfieithu Cyfeiriad Rhwydwaith Ffynhonnell a Chyrchfan (SNAT a DNAT) a mynediad dilynol i'r tabl contrack. Un o'r atebion a drafodwyd yn fewnol ac a awgrymwyd gan y gymuned oedd symud y DAC i'r nod gweithiwr ei hun. Yn yr achos hwn:
- Nid oes angen SNAT oherwydd bod y traffig yn aros y tu mewn i'r nod. Nid oes angen ei gyfeirio drwy'r rhyngwyneb eth0.
- Nid oes angen DNAT gan fod IP y cyrchfan yn lleol i'r nod, ac nid pod a ddewiswyd ar hap yn ôl y rheolau iptables.
Fe benderfynon ni gadw at y dull hwn. Defnyddiwyd CoreDNS fel DaemonSet yn Kubernetes a gwnaethom weithredu gweinydd DNS nod lleol yn datrys.conf pob pod trwy osod baner --clwstwr-dns gorchmynion cubelet . Daeth yr ateb hwn i fod yn effeithiol ar gyfer cyfnodau DNS.
Fodd bynnag, gwelsom golli pecynnau o hyd a chynnydd yn y cownter insert_failed yn y rhyngwyneb Wlanen. Parhaodd hyn ar ôl i'r ateb gael ei roi ar waith oherwydd roeddem yn gallu dileu SNAT a/neu DNAT ar gyfer traffig DNS yn unig. Cadwyd amodau rasio ar gyfer mathau eraill o draffig. Yn ffodus, mae'r rhan fwyaf o'n pecynnau yn TCP, ac os bydd problem yn codi cânt eu hail-drosglwyddo. Rydym yn dal i geisio dod o hyd i ateb addas ar gyfer pob math o draffig.
Defnyddio Cennad ar gyfer Cydbwyso Llwyth Gwell
Wrth i ni symud gwasanaethau ôl-gefn i Kubernetes, fe ddechreuon ni ddioddef o lwyth anghytbwys rhwng codennau. Canfuom fod HTTP Keepalive wedi achosi i gysylltiadau ELB hongian ar godennau parod cyntaf pob gosodiad a gyflwynwyd. Felly, aeth y rhan fwyaf o'r traffig trwy ganran fechan o'r codennau oedd ar gael. Yr ateb cyntaf a brofwyd gennym oedd gosod MaxSurge i 100% ar leoliadau newydd ar gyfer y senarios gwaethaf. Trodd yr effaith allan yn ddi-nod ac yn anaddawol o ran lleoli mwy.
Ateb arall a ddefnyddiwyd gennym oedd cynyddu ceisiadau am adnoddau ar gyfer gwasanaethau hanfodol yn artiffisial. Yn yr achos hwn, byddai gan godennau a osodir gerllaw fwy o le i symud o gymharu â chodennau trwm eraill. Ni fyddai'n gweithio yn y tymor hir chwaith oherwydd byddai'n wastraff adnoddau. Yn ogystal, roedd ein cymwysiadau Node yn un edau ac, yn unol â hynny, dim ond un craidd y gallent ei ddefnyddio. Yr unig ateb go iawn oedd defnyddio gwell cydbwyso llwyth.
Rydym wedi bod eisiau gwerthfawrogi'n llawn ers amser maith . Roedd y sefyllfa bresennol yn caniatáu i ni ei ddefnyddio mewn ffordd gyfyngedig iawn a chael canlyniadau ar unwaith. Mae Envoy yn ddirprwy perfformiad uchel, ffynhonnell agored, haen-XNUMX a ddyluniwyd ar gyfer cymwysiadau SOA mawr. Gall weithredu technegau cydbwyso llwyth uwch, gan gynnwys ailgynigion awtomatig, torwyr cylchedau, a chyfyngu ar gyfraddau byd-eang. (Nodyn. traws.: Gallwch ddarllen mwy am hyn yn am Istio, sy'n seiliedig ar Envoy.)
Fe wnaethon ni lunio'r ffurfweddiad canlynol: cael car ochr Cennad ar gyfer pob pod ac un llwybr, a chysylltu'r clwstwr â'r cynhwysydd yn lleol trwy'r porthladd. Er mwyn lleihau rhaeadru posibl a chynnal radiws taro bach, defnyddiwyd fflyd o godennau dirprwy blaen y Cenhadwr, un fesul Parth Argaeledd (AZ) ar gyfer pob gwasanaeth. Roeddent yn dibynnu ar beiriant darganfod gwasanaeth syml a ysgrifennwyd gan un o'n peirianwyr a oedd yn dychwelyd rhestr o godennau ym mhob AZ ar gyfer gwasanaeth penodol.
Yna defnyddiodd Llysgenhadon blaen y gwasanaeth y mecanwaith darganfod gwasanaeth hwn gydag un clwstwr a llwybr i fyny'r afon. Fe wnaethom osod terfynau amser digonol, cynyddu'r holl osodiadau torrwr cylched, ac ychwanegu'r cyfluniad ailgynnig lleiaf posibl i helpu gyda methiannau sengl a sicrhau gosodiadau llyfn. Fe wnaethom osod TCP ELB o flaen pob un o'r Llysgenhadon blaen gwasanaeth hyn. Hyd yn oed pe bai'r cadw'n fyw o'n prif haen ddirprwy yn sownd ar rai codennau Envoy, roeddent yn dal i allu trin y llwyth yn llawer gwell ac wedi'u ffurfweddu i gydbwyso trwy least_request yn y pen ôl.
I'w ddefnyddio, fe wnaethom ddefnyddio'r bachyn preStop ar god y cais a'r codennau car ochr. Sbardunodd y bachyn wall wrth wirio statws y pwynt terfyn gweinyddol sydd wedi'i leoli ar gynhwysydd y car ochr ac aeth i gysgu am ychydig i ganiatáu i gysylltiadau gweithredol ddod i ben.
Un o'r rhesymau pam ein bod wedi gallu symud mor gyflym yw'r metrigau manwl y bu modd i ni eu hintegreiddio'n hawdd i osodiad Prometheus nodweddiadol. Roedd hyn yn ein galluogi i weld yn union beth oedd yn digwydd wrth i ni addasu paramedrau cyfluniad ac ailddosbarthu traffig.
Roedd y canlyniadau yn syth ac yn amlwg. Dechreuasom gyda’r gwasanaethau mwyaf anghytbwys, ac ar hyn o bryd mae’n gweithredu o flaen y 12 gwasanaeth pwysicaf yn y clwstwr. Eleni rydym yn cynllunio trawsnewid i rwyll gwasanaeth llawn gyda mwy o ddarganfod gwasanaeth datblygedig, torri cylchedau, canfod allgleifion, cyfyngu ar gyfraddau ac olrhain.
Ffigur 3–1. Cydgyfeirio CPU un gwasanaeth yn ystod y trawsnewid i Gennad
Canlyniad terfynol
Trwy'r profiad hwn ac ymchwil ychwanegol, rydym wedi adeiladu tîm seilwaith cryf gyda sgiliau cryf mewn dylunio, lleoli a gweithredu clystyrau Kubernetes mawr. Bellach mae gan bob peiriannydd Tinder y wybodaeth a'r profiad i becynnu cynwysyddion a defnyddio cymwysiadau i Kubernetes.
Pan gododd yr angen am gapasiti ychwanegol ar yr hen seilwaith, bu’n rhaid inni aros am rai munudau cyn lansio achosion EC2 newydd. Nawr mae cynwysyddion yn dechrau rhedeg ac yn dechrau prosesu traffig o fewn eiliadau yn lle munudau. Mae amserlennu cynwysyddion lluosog ar un enghraifft EC2 hefyd yn darparu crynodiad llorweddol gwell. O ganlyniad, rydym yn rhagweld gostyngiad sylweddol mewn costau EC2019 yn 2 o gymharu â’r llynedd.
Cymerodd y mudo bron i ddwy flynedd, ond fe wnaethom ei gwblhau ym mis Mawrth 2019. Ar hyn o bryd, mae platfform Tinder yn rhedeg yn gyfan gwbl ar glwstwr Kubernetes sy'n cynnwys 200 o wasanaethau, 1000 o nodau, 15 o godennau a 000 o gynwysyddion rhedeg. Nid seilwaith yw unig faes timau gweithrediadau mwyach. Mae pob un o'n peirianwyr yn rhannu'r cyfrifoldeb hwn ac yn rheoli'r broses o adeiladu a defnyddio eu cymwysiadau gan ddefnyddio cod yn unig.
PS gan y cyfieithydd
Darllenwch hefyd gyfres o erthyglau ar ein blog:
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
- «'.
Ffynhonnell: hab.com