Not. werger.: Karkerên karûbarê navdar ê cîhanê Tinder vê dawiyê hin hûrguliyên teknîkî yên koçkirina binesaziya xwe bo Kubernetes parve kirin. Pêvajo nêzî du salan dom kir û di encamê de platformek pir mezin li ser K8-an hate destpêkirin, ku ji 200 servîsên ku li ser 48 hezar konteyniran hatine çêkirin pêk tê. Endezyarên Tinder bi çi zehmetiyên balkêş re rû bi rû man û gihîştin çi encamê? Vê wergerê bixwînin.
Çima?
Nêzîkî du sal berê, Tinder biryar da ku platforma xwe bar bike Kubernetes. Kubernetes dê bihêle ku tîmê Tinder bi navgîniya bicîhkirina neguhêrbar ve bi hewildanek hindiktirîn ber bi hilberînê ve bibe konteyneran. (bikaranîna neguhêrbar). Di vê rewşê de, kombûna serîlêdanan, bicihkirina wan, û binesaziya xwe dê bi kodê yekta were destnîşankirin.
Em jî li çareseriyekê digeriyan ji bo pirsgirêka mezinbûn û aramiyê. Dema ku pîvandin krîtîk bû, me gelek caran neçar ma ku çend deqeyan li bendê bimînin da ku mînakên nû yên EC2 bizivirin. Fikra destpêkirina konteyneran û destpêkirina xizmetkirina trafîkê di nav çend hûrdeman de ji me re pir balkêş bû.
Pêvajo bi zehmet derket holê. Di dema koça me ya di destpêka 2019-an de, koma Kubernetes gihîşt girseyek krîtîk û me ji ber qebareya trafîkê, mezinahiya komê û DNS-ê dest bi pirsgirêkên cihêreng kir. Di rê de, me gelek pirsgirêkên balkêş ên têkildarî koçberkirina 200 karûbar û domandina komek Kubernetes ku ji 1000 nod, 15000 pods û 48000 konteynerên xebitandinê pêk tê çareser kirin.
Çawa?
Ji Çileya 2018’an ve em di gelek qonaxên koçberiyê re derbas bûne. Me bi konteynirkirina hemî karûbarên xwe dest pê kir û wan li hawîrdorên ewrê ceribandina Kubernetes bicîh kir. Ji meha cotmehê dest pê kir, me bi metodek dest bi koçkirina hemî karûbarên heyî bo Kubernetes kir. Heya Adara sala paşîn, me koçberî qedand û naha platforma Tinder bi taybetî li ser Kubernetes dimeşe.
Avakirina wêneyan ji bo Kubernetes
Zêdetirî 30 depoyên koda çavkaniyê ji bo mîkroxizmetên ku li ser komek Kubernetes dixebitin hene. Koda di van depoyan de bi zimanên cihêreng (mînak, Node.js, Java, Scala, Go) bi gelek hawîrdorên dema xebitandinê ji bo heman zimanî têne nivîsandin.
Pergala avakirinê hatî sêwirandin ku ji bo her mîkroxizmetê "çarçoveyek avakirinê" bi tevahî xwerû peyda bike. Ew bi gelemperî ji Dockerfile û navnîşek fermanên şêlê pêk tê. Naveroka wan bi tevahî xwerû ye, û di heman demê de, hemî van çarçoveyên çêkirinê li gorî rengek standard têne nivîsandin. Standardîzekirina çarçoweya çêkirinê dihêle ku yek pergalek avahîsaziyê hemî mîkroxizmetan bi rê ve bibe.
jimar 1-1. Pêvajoya avakirina standardkirî bi navgîniya konteynerê Builder
Ji bo ku di navbera dema xebitandinê de hevrêziya herî zêde bigihîjin (dorhêlên dema xebatê) heman pêvajoya avakirinê di dema pêşkeftin û ceribandinê de tê bikar anîn. Em bi dijwariyek pir balkêş re rû bi rû man: diviyabû ku me rêyek pêş bixe da ku li seranserê platformê lihevhatina hawîrdora çêkirinê misoger bike. Ji bo gihîştina vê yekê, hemî pêvajoyên kombûnê di hundurê konteynirek taybetî de têne kirin. Avaker.
Pêkanîna konteynerê wî teknîkên pêşkeftî yên Docker hewce dike. Builder nasnameya bikarhênerê herêmî û nehênî (wek mifteya SSH, pêbaweriyên AWS, hwd.) ku ji bo gihîştina depoyên Tinder-ê yên taybet hewce dike mîras digire. Ew pelrêçên herêmî yên ku jêderkan vedihewîne datîne ku bi xwezayî hunerên çêkirinê hilîne. Ev nêzîkatî performansê baştir dike ji ber ku ew hewcedariya kopîkirina hunerên çêkirinê di navbera konteynera Builder û mêvandar de ji holê radike. Berhemên çêkirî yên hilanîn dikarin bêyî veavakirina zêde ji nû ve werin bikar anîn.
Ji bo hin karûbaran, me neçar ma ku konteynirek din biafirînin da ku hawîrdora berhevokê li hawîrdora dema xebitandinê nexşe bikin (mînak, pirtûkxaneya Node.js bcrypt di dema sazkirinê de hunerên binary-taybet ên platformê çêdike). Di dema pêvajoya berhevkirinê de, dibe ku pêdivî di navbera karûbaran de cûda bibin, û Dockerfile ya paşîn di firînê de tê berhev kirin.
Kubernetes mîmarî û koçberiyê kom dike
Rêvebiriya mezinahiya komê
Me biryar da ku bikar bînin kube-aws ji bo bicîhkirina komê ya otomatîkî ya li ser mînakên Amazon EC2. Di destpêkê de, her tişt di yek hewzek hevbeş a girêkan de xebitî. Me zû pê hesiya ku hewce ye ku bargiraniyên xebatê li gorî mezinahî û celeb nimûne ji hev veqetînin da ku çavkaniyan bikêrtir bikar bînin. Mantiq ev bû ku destpêkirina çend pêlên pir-mijabarkirî yên barkirî di warê performansê de ji hevjiyana wan bi hejmareke mezin a potanên yek-têl re pêşbîntir bû.
Di dawiyê de em li ser:
- m5.4xmezin - ji bo çavdêriyê (Prometheus);
- c5.4xmezin - ji bo barkêşiya Node.js (karê yek-têkilî);
- c5.2xmezin - ji bo Java û Go (barkêşiya pir-têkilî);
- c5.4xmezin - ji bo panela kontrolê (3 nod).
Koçberî
Yek ji gavên amadekar ên ji bo koçkirina ji binesaziya kevn a Kubernetes ev bû ku pêwendiya rasterast a heyî ya di navbera karûbaran de berbi hevsengên barkirinê yên nû (Elastic Load Balancers (ELB) ve bike. Ew li ser subnetek taybetî ya ewrek taybet a virtual (VPC) hatin afirandin. Ev subnet bi Kubernetes VPC ve girêdayî bû. Vê yekê hişt ku em gav bi gav modulan koç bikin, bêyî ku em rêzika taybetî ya girêdayîbûna karûbarê bihesibînin.
Van xalên dawîn bi karanîna komên girankirî yên tomarên DNS-ê yên ku CNAME-yên xwedan her ELB-ya nû destnîşan dikin hatin afirandin. Ji bo veguheztinê, me têketinek nû lê zêde kir ku nîşanî karûbarê Kubernetes-a nû ELB bi giraniya 0 ye. Dûv re me Demjimêra Jiyanê (TTL) ya têketinê kir 0. Piştî vê yekê, giraniya kevin û nû hêdî hêdî hatin sererast kirin. , û di dawiyê de 100% barkirinê ji serverek nû re hate şandin. Piştî ku guheztin qediya, nirxa TTL vegeriya astek têrtir.
Modulên Java yên ku me hebûn dikaribûn bi TTL DNS-ya kêm re mijûl bibin, lê serîlêdanên Node nekarîn. Yek ji endezyaran beşek ji koda hewza pêwendiyê ji nû ve nivîsand û ew di nav rêveberek ku her 60 saniyeyan carekê hewzên nûjen dike pêça. Nêzîkatiya bijartî pir baş û bêyî xirabûna performansê ya berbiçav xebitî.
Dersan
Sînorên Fabric Tora
Di sibeha zû ya 8ê Rêbendana 2019an de, platforma Tinder bi awayekî neçaverêkirî ket. Di bersivê de zêdebûnek negirêdayî di derengiya platformê ya serê sibê de, di komê de hejmara pod û girêkan zêde bû. Vê yekê bû sedem ku cache ARP li ser hemî girêkên me biqede.
Sê vebijarkên Linux hene ku bi cache ARP ve girêdayî ne:
()
gc_thresh3 - ev sînorek dijwar e. Di têketinê de xuyangkirina navnîşên "derbasbûna tabloya cîranan" tê vê wateyê ku tewra piştî berhevkirina çopê ya hevdem (GC), di cache ARP de cîhek têr tune ku têketina cîran hilîne. Di vê rewşê de, kernel bi tenê pakêtê bi tevahî avêtin.
Em bikar tînin wekî tevnek torê li Kubernetes. Paket li ser VXLAN têne şandin. VXLAN tunelek L2 ye ku li ser torgilokek L3 hatî rakirin. Teknolojî encapsulasyona MAC-in-UDP (MAC Address-in-User Datagram Protocol) bikar tîne û destûrê dide berfirehkirina beşên torê yên Layer 2. Protokola veguhastinê ya li ser tora navenda daneya laşî IP plus UDP ye.
Wêne 2-1. Diyagrama flannel ()
Wêne 2-2. Pakêta VXLAN ()
Her girêka xebatkarê Kubernetes cîhek navnîşana virtual bi maskek /24 ji blokek /9 mezintir veqetîne. Ji bo her nodek ev e yek têketin di tabloya rêvekirinê de, yek têketinek di tabloya ARP de (li ser pêveka flannel.1), û yek têketin di tabloya veguheztinê (FDB). Ew cara yekem ku girêkek karker dest pê dike an jî her carê ku girêkek nû tê vedîtin têne zêde kirin.
Wekî din, pêwendiya node-pod (an pod-pod) di dawiyê de bi navgîniyê re derbas dibe eth0 (wekî ku di diyagrama Flannel li jor de tê xuyang kirin). Ev yek di tabloya ARP-ê de ji bo her çavkaniyek têkildar û mêvandarê armancê encam dide.
Di hawîrdora me de, ev celeb danûstandin pir gelemperî ye. Ji bo tiştên karûbarê li Kubernetes, ELB tê afirandin û Kubernetes her girêk bi ELB re tomar dike. ELB di derbarê pods de tiştek nizane û dibe ku girêka hilbijartî ne cîhê paşîn a pakêtê be. Mesele ev e ku gava girêk pakêtek ji ELB distîne, ew li gorî rêzikan dihesibîne. iptables ji bo karûbarek taybetî û bi korfelaqî li ser girêkek din podek hildibijêre.
Di dema têkçûnê de, di komê de 605 girêk hebûn. Ji ber sedemên ku li jor hatine destnîşan kirin, ev ji bo derbaskirina girîngiyê bes bû gc_thresh3, ku standard e. Dema ku ev diqewime, ne tenê pakêt dest bi avêtinê dikin, lê tevahiya cîhê navnîşana virtual ya Flannel bi maskek /24 ji tabloya ARP winda dibe. Têkiliya node-pod û pirsên DNS-ê têne qut kirin (DNS di komekê de tê mêvandar kirin; ji bo hûrguliyan paşê di vê gotarê de bixwînin).
Ji bo çareserkirina vê pirsgirêkê, hûn hewce ne ku nirxan zêde bikin gc_thresh1, gc_thresh2 и gc_thresh3 û Flannel ji nû ve bidin destpêkirin da ku torên winda ji nû ve tomar bikin.
Pîvana DNS ya nediyar
Di pêvajoya koçberiyê de, me DNS bi awayekî çalak bikar anî da ku seyrûseferê birêve bibe û hêdî hêdî karûbaran ji binesaziya kevn veguhezîne Kubernetes. Me ji bo RecordSets têkildar di Route53 de nirxên TTL-ê yên kêm kêm danîn. Dema ku binesaziya kevn li ser mînakên EC2 dimeşiya, veavakirina çareserkerê me Amazon DNS destnîşan kir. Me ev ji xwe re qebûl kir û bandora TTL ya kêm a li ser karûbar û karûbarên me yên Amazon (wek DynamoDB) bi giranî nedît.
Gava ku me karûbar koçî Kubernetes kir, me dît ku DNS di çirkeyê de 250 hezar daxwazan dike. Wekî encamek, serîlêdan ji bo pirsên DNS-ê dest bi ceribandina demên domdar û giran kirin. Ev pêk hat tevî hewildanên bêhempa ji bo xweşbînkirin û veguheztina pêşkêşkarê DNS-ê li CoreDNS (ku di barkirina lûtkeyê de gihîştiye 1000 pods ku li ser 120 core dixebitin).
Di dema lêkolîna sedem û çareseriyên mimkun ên din de, me kifş kir , danasîna şert û mercên nijadê ku bandorê li çarçoweya parzûna pakêtê dike Parzûna torê li Linux. Demjimêrên ku me temaşe kirin, digel hejmareke zêde insert_failed di navbeyna Flannel de bi dîtinên gotarê re hevaheng bûn.
Pirsgirêk di qonaxa Wergerandina Navnîşana Tora Çavkanî û Destpêkî (SNAT û DNAT) de û paşê têketina tabloyê de çêdibe. contrack. Yek ji rêgezên ku di hundurê de hate nîqaş kirin û ji hêla civatê ve hatî pêşniyar kirin ev bû ku DNS-ê biguhezîne girêka karker bixwe. Di vê rewşê de:
- SNAT ne hewce ye ji ber ku seyrûsefer di hundurê nodê de dimîne. Ne hewce ye ku ew bi navgîniyê ve were rêve kirin eth0.
- DNAT ne hewce ye ji ber ku IP-ya meqsedê ji girêkê re herêmî ye, û ne li gorî qaîdeyan podek bi tesadufî bijartî ye. iptables.
Me biryar da ku em bi vê rêbazê re bisekinin. CoreDNS wekî DaemonSet li Kubernetes hate bicîh kirin û me serverek DNS-ya girêka herêmî di nav de bicîh kir. biryar.conf her pod bi danîna ala --cluster-dns ferman dike kubelet . Ev çareserî ji bo demên DNS-ê bandorker derket.
Lêbelê, me hîn jî windabûna pakêtê û zêdebûnek di kontra de dît insert_failed di navbeyna Flannel de. Ev berdewam kir piştî ku çareserî hate bicîh kirin ji ber ku me karîbû SNAT û / an DNAT tenê ji bo seyrûsefera DNS-ê ji holê rakin. Şertên pêşbaziyê ji bo celebên din ên trafîkê hatin parastin. Xweşbextane, piraniya pakêtên me TCP ne, û heke pirsgirêkek çêbibe ew bi tenê ji nû ve têne şandin. Em hîn jî hewl didin ku ji bo her cûre trafîkê çareseriyek guncaw bibînin.
Bikaranîna Envoy ji bo Balansa Barkirina Baştir
Gava ku me karûbarên paşerojê koçî Kubernetes kir, me dest pê kir ku em ji bargiraniya bêhevseng a di navbera pods de diêşin. Me dît ku HTTP Keepalive bû sedem ku girêdanên ELB-ê li ser pêlên amade yên yekem ên her vesazkirinê veqetînin. Bi vî rengî, piraniya seyrûseferê di nav rêjeyek piçûk a podên berdest re derbas bû. Çareseriya yekem a ku me ceriband ev bû ku MaxSurge ji bo senaryoyên rewşa herî xirab li ser bicîhkirinên nû 100% danîn. Di warê bicihkirina mezintir de bandorek ne girîng û bêhêvî derket.
Çareseriyek din a ku me bikar anî ev bû ku bi sûnî daxwazên çavkaniyê ji bo karûbarên krîtîk zêde bikin. Di vê rewşê de, pêlên ku li nêzê têne danîn dê li gorî pêlên din ên giran bêtir cîhê manevrayê hebe. Ew ê di demek dirêj de jî nexebite ji ber ku ew ê windakirina çavkaniyan be. Digel vê yekê, serîlêdanên me yên Node yek-têl bûn û, li gorî vê yekê, tenê dikaribûn yek bingehek bikar bînin. Tenê çareseriya rastîn ev bû ku meriv hevsengiya barkirinê çêtir bikar bîne.
Me demek dirêj dixwest ku em bi tevahî binirxînin . Rewşa heyî hişt ku em bi awayekî pir bisînor bi cih bikin û yekser encamên xwe bi dest bixin. Envoy proxyek performansa bilind, çavkaniya vekirî, qat-7 e ku ji bo serîlêdanên mezin ên SOA hatî çêkirin. Ew dikare teknîkên hevsengiya barkirinê ya pêşkeftî bicîh bîne, di nav de dubarekirina otomatîkî, şkestinên dorhêl, û sînorkirina rêjeya gerdûnî. (Not. werger.: Hûn dikarin li ser vê yekê bêtir bixwînin di derbarê Istio de, ku li ser Qasidê ye.)
Me konfigurasyona jêrîn pêk anî: ji bo her pod û rêyek yekane rêgezek Envoy hebe, û komê bi navgîniya portê ve bi konteynerê ve girêdin. Ji bo kêmkirina kavilbûna potansiyel û domandina tîrêjek lêdanek piçûk, me ji bo her karûbarek fîloyek ji podên pêş-navdêr ên Envoy bikar anî, yek ji Herêmên Berdestbûnê (AZ). Wan pişta xwe da motorek keşfkirina karûbarê hêsan a ku ji hêla yek ji endezyarên me ve hatî nivîsandin ku bi tenê navnîşek potan li her AZ-ê ji bo karûbarê diyarkirî vegerandiye.
Karûbarê pêş-Envoys wê hingê vê mekanîzmaya vedîtina karûbarê bi yek kom û rêgezek jorîn bikar anîn. Me demên guncav danî, hemî mîhengên şkestê yên çerxerê zêde kir, û mîhengên ji nû ve ceribandina hindiktirîn lê zêde kirin da ku ji têkçûnên yekane re bibin alîkar û bicîhkirina bêkêmasî misoger bikin. Me TCP ELB li ber her yek ji van eniya karûbarê şandî danîn. Tewra ku keepalive ji qata meya sereke ya wekîlê li ser hin podên Envoy asê mabû jî, wan dîsa jî dikaribû barkirinê pir çêtir bi rê ve bibe û ji bo ku di nav paşerojê de bi minimum_request hevseng bikin hatine mîheng kirin.
Ji bo bicîhkirinê, me çengelê preStop hem li ser pêlên serîlêdanê û hem jî li ser pêlên kêlekê bikar anî. The hook di kontrolkirina statûya xala paşîn a rêveberiyê de ku li ser konteynerê kêlekê ye de xeletiyek derxist û ji bo ku rê bide girêdanên çalak biqede ji bo demekê raza.
Yek ji sedemên ku me karîbû ewqas zû tevbigerin ji ber metrîkên hûrgulî ye ku me karîbû bi hêsanî di sazkirinek Prometheus a tîpîk de yek bikin. Vê yekê hişt ku em bi rastî bibînin ka çi diqewime dema ku me pîvanên vesazkirinê rast kir û seyrûsefer ji nû ve belav kir.
Encam yekser û eşkere bûn. Me bi karûbarên herî bêhevseng dest pê kir, û di vê gavê de ew li ber 12 karûbarên herî girîng ên komê dixebite. Vê salê em plan dikin ku veguheztinek tevnek karûbarê tam bi vedîtina karûbarê pêşkeftî, şikandina çerxê, vedîtina derveyî, sînorkirina rêje û şopandinê.
Wêne 3-1. Di dema veguheztina Envoy de yek karûbarek CPU-ê lihevhatî
Encama dawî
Di nav vê ezmûnê û lêkolîna zêde de, me tîmek binesaziya bihêz a ku di sêwirandin, bicihkirin û xebitandina komên mezin ên Kubernetes de jêhatîbûnek xurt ava kiriye. Hemî endezyarên Tinder naha xwedan zanîn û ezmûn in ku konteyneran pak bikin û sepanan li Kubernetes bicîh bikin.
Dema ku hewcedariya kapasîteya zêde li ser binesaziya kevn derket, em neçar bûn ku çend hûrdeman li benda destpêkirina mînakên nû yên EC2 bin. Naha konteynir dest bi xebitandinê dikin û li şûna çend hûrdeman di nav çend hûrdeman de dest bi pêvajoyê dikin. Plansazkirina gelek konteyneran li ser yek mînakek EC2 di heman demê de baldariya horîzontal jî çêtir peyda dike. Wekî encamek, em li gorî sala borî kêmbûnek girîng di lêçûnên EC2019 de di sala 2-an de texmîn dikin.
Koçberî hema du sal kişand, lê me ew di Adara 2019 de qedand. Platforma Tinder naha tenê li ser komek Kubernetes ku ji 200 karûbar, 1000 nod, 15 pods, û 000 konteynerên xebitandinê pêk tê, dimeşe. Binesaziyê êdî ne tenê qada tîmên operasyonê ye. Hemî endezyarên me vê berpirsiyariyê parve dikin û pêvajoya avakirin û bicîhkirina serîlêdanên xwe tenê bi karanîna kodê kontrol dikin.
PS ji wergêr
Her weha çend gotarên li ser bloga me bixwînin:
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
Source: www.habr.com