PiezÄ«me. tulk.: pasaulslavenÄ pakalpojuma Tinder darbinieki nesen dalÄ«jÄs ar dažÄm tehniskÄm detaļÄm par savas infrastruktÅ«ras migrÄÅ”anu uz Kubernetes. Process ilga gandrÄ«z divus gadus, un tÄ rezultÄtÄ K8s tika uzsÄkta ļoti liela mÄroga platforma, kas sastÄv no 200 pakalpojumiem, kas izvietoti 48 tÅ«kstoÅ”os konteineru. Ar kÄdÄm interesantÄm grÅ«tÄ«bÄm saskÄrÄs Tinder inženieri un pie kÄdiem rezultÄtiem viÅi nonÄca?Izlasi Å”o tulkojumu.
KÄpÄc?
GandrÄ«z pirms diviem gadiem Tinder nolÄma pÄrvietot savu platformu uz Kubernetes. Kubernetes ļautu Tinder komandai ievietot konteinerus un pÄriet uz ražoÅ”anu ar minimÄlu piepÅ«li, izmantojot nemainÄ«gu izvietoÅ”anu (nemainÄ«ga izvietoÅ”ana). Å ajÄ gadÄ«jumÄ lietojumprogrammu komplektu, to izvietoÅ”anu un paÅ”u infrastruktÅ«ru unikÄli definÄtu kods.
MÄs arÄ« meklÄjÄm risinÄjumu mÄrogojamÄ«bas un stabilitÄtes problÄmai. Kad mÄrogoÅ”ana kļuva kritiska, mums bieži bija jÄgaida vairÄkas minÅ«tes, lÄ«dz parÄdÄ«jÄs jauni EC2 gadÄ«jumi. Ideja palaist konteinerus un sÄkt apkalpot satiksmi sekundÄs, nevis minÅ«tÄs, mums kļuva ļoti pievilcÄ«ga.
Process izrÄdÄ«jÄs grÅ«ts. MÅ«su migrÄcijas laikÄ 2019. gada sÄkumÄ Kubernetes klasteris sasniedza kritisko masu, un mÄs sÄkÄm saskarties ar dažÄdÄm problÄmÄm trafika apjoma, klastera lieluma un DNS dÄļ. Pa ceļam mÄs atrisinÄjÄm daudzas interesantas problÄmas, kas saistÄ«tas ar 200 pakalpojumu migrÄÅ”anu un Kubernetes klastera uzturÄÅ”anu, kas sastÄv no 1000 mezgliem, 15000 48000 podiem un XNUMX XNUMX strÄdÄjoÅ”iem konteineriem.
KÄ?
KopÅ” 2018. gada janvÄra esam izgÄjuÅ”i cauri dažÄdiem migrÄcijas posmiem. MÄs sÄkÄm, ievietojot visus savus pakalpojumus konteineros un izvietojot tos Kubernetes testa mÄkoÅa vidÄs. SÄkot ar oktobri, mÄs sÄkÄm metodisku visu esoÅ”o pakalpojumu migrÄÅ”anu uz Kubernetes. LÄ«dz nÄkamÄ gada martam mÄs pabeidzÄm migrÄÅ”anu, un tagad Tinder platforma darbojas tikai Kubernetes.
Kubernetes attÄlu veidoÅ”ana
Mums ir vairÄk nekÄ 30 pirmkoda krÄtuves mikropakalpojumiem, kas darbojas Kubernetes klasterÄ«. Kods Å”ajÄs krÄtuvÄs ir rakstÄ«ts dažÄdÄs valodÄs (piemÄram, Node.js, Java, Scala, Go) ar vairÄkÄm izpildlaika vidÄm vienai valodai.
BÅ«vsistÄma ir izstrÄdÄta, lai nodroÅ”inÄtu pilnÄ«bÄ pielÄgojamu ābÅ«vÄjuma kontekstuā katram mikropakalpojumam. Tas parasti sastÄv no Dockerfile un Äaulas komandu saraksta. To saturs ir pilnÄ«bÄ pielÄgojams, un tajÄ paÅ”Ä laikÄ visi Å”ie bÅ«vÄÅ”anas konteksti ir rakstÄ«ti saskaÅÄ ar standartizÄtu formÄtu. BÅ«vÄÅ”anas kontekstu standartizÄÅ”ana ļauj vienai bÅ«vÄÅ”anas sistÄmai apstrÄdÄt visus mikropakalpojumus.
AttÄls 1-1. StandartizÄts veidoÅ”anas process, izmantojot Builder konteineru
Lai sasniegtu maksimÄlu konsekvenci starp izpildlaikiem (izpildlaika vides) tas pats veidoÅ”anas process tiek izmantots izstrÄdes un testÄÅ”anas laikÄ. MÄs saskÄrÄmies ar ļoti interesantu izaicinÄjumu: mums bija jÄizstrÄdÄ veids, kÄ nodroÅ”inÄt bÅ«vniecÄ«bas vides konsekvenci visÄ platformÄ. Lai to panÄktu, visi montÄžas procesi tiek veikti Ä«paÅ”Ä konteinerÄ. Celtnieks.
ViÅa konteinera ievieÅ”anai bija nepiecieÅ”amas uzlabotas Docker metodes. Builder manto vietÄjo lietotÄja ID un noslÄpumus (piemÄram, SSH atslÄgu, AWS akreditÄcijas datus utt.), kas nepiecieÅ”ami, lai piekļūtu privÄtajÄm Tinder krÄtuvÄm. Tas pievieno lokÄlos direktorijus, kuros ir avoti, lai dabiski uzglabÄtu bÅ«vÄÅ”anas artefaktus. Å Ä« pieeja uzlabo veiktspÄju, jo novÄrÅ” nepiecieÅ”amÄ«bu kopÄt bÅ«vÄjuma artefaktus starp Builder konteineru un resursdatoru. SaglabÄtos bÅ«vÄjuma artefaktus var izmantot atkÄrtoti bez papildu konfigurÄcijas.
Dažiem pakalpojumiem mums bija jÄizveido cits konteiners, lai kartÄtu kompilÄcijas vidi ar izpildlaika vidi (piemÄram, Node.js bcrypt bibliotÄka instalÄÅ”anas laikÄ Ä£enerÄ platformai raksturÄ«gus binÄros artefaktus). KompilÄcijas procesa laikÄ prasÄ«bas dažÄdiem pakalpojumiem var atŔķirties, un galÄ«gais Dockerfile tiek apkopots lidojuma laikÄ.
Kubernetes klasteru arhitektÅ«ra un migrÄcija
Klasteru lieluma pÄrvaldÄ«ba
MÄs nolÄmÄm izmantot kube-aws automatizÄtai klasteru izvietoÅ”anai Amazon EC2 gadÄ«jumos. PaÅ”Ä sÄkumÄ viss darbojÄs vienÄ kopÄjÄ mezglu baseinÄ. MÄs Ätri sapratÄm, ka darba slodzes ir jÄnodala pÄc lieluma un gadÄ«jumu veida, lai efektÄ«vÄk izmantotu resursus. LoÄ£ika bija tÄda, ka vairÄku ielÄdÄtu vairÄku vÄ«tÅu apvidu palaiÅ”ana veiktspÄjas ziÅÄ izrÄdÄ«jÄs paredzamÄka nekÄ to lÄ«dzÄspastÄvÄÅ”ana ar lielu skaitu viena vÄ«tnes apvidu.
BeigÄs vienojÄmies:
- m5.4xliels ā monitoringam (Prometejs);
- c5.4xliels - Node.js darba slodzei (vienpavedienu darba slodze);
- c5.2xliels - Java un Go (daudzpavedienu darba slodze);
- c5.4xliels ā vadÄ«bas panelim (3 mezgli).
MigrÄcija
Viens no sagatavoÅ”anÄs posmiem, lai pÄrietu no vecÄs infrastruktÅ«ras uz Kubernetes, bija esoÅ”Äs tieÅ”Äs komunikÄcijas novirzÄ«Å”ana starp pakalpojumiem uz jaunajiem slodzes balansÄtÄjiem (ElastÄ«gie slodzes balansÄtÄji (ELB). Tie tika izveidoti noteiktÄ virtuÄlÄ privÄtÄ mÄkoÅa (VPC) apakÅ”tÄ«klÄ. Å is apakÅ”tÄ«kls tika savienots ar Kubernetes VPC. Tas ļÄva mums pakÄpeniski migrÄt moduļus, neÅemot vÄrÄ Ä«paÅ”o pakalpojumu atkarÄ«bu secÄ«bu.
Å ie galapunkti tika izveidoti, izmantojot svÄrtÄs DNS ierakstu kopas, kurÄs CNAME norÄdÄ«ja uz katru jauno ELB. Lai pÄrslÄgtos, mÄs pievienojÄm jaunu ierakstu, kas norÄda uz jauno Kubernetes pakalpojuma ELB ar svaru 0. PÄc tam ieraksta kopas Time To Live (TTL) iestatÄ«jÄm uz 0. PÄc tam tika iestatÄ«ts vecais un jaunais svars. lÄnÄm pielÄgots, un galu galÄ 100% slodzes tika nosÅ«tÄ«ta uz jaunu serveri. PÄc pÄrslÄgÅ”anas TTL vÄrtÄ«ba atgriezÄs atbilstoÅ”ÄkÄ lÄ«menÄ«.
MÅ«su rÄ«cÄ«bÄ esoÅ”ie Java moduļi varÄja tikt galÄ ar zemu TTL DNS, bet Node lietojumprogrammas to nevarÄja. Viens no inženieriem pÄrrakstÄ«ja daļu savienojuma pÅ«la koda un iesaiÅoja to pÄrvaldniekÄ, kas atjauninÄja kopas ik pÄc 60 sekundÄm. IzvÄlÄtÄ pieeja darbojÄs ļoti labi un bez manÄmas veiktspÄjas pasliktinÄÅ”anÄs.
Nodarbības
Tīkla auduma ierobežojumi
8. gada 2019. janvÄra agrÄ rÄ«tÄ Tinder platforma negaidÄ«ti avarÄja. ReaÄ£Äjot uz nesaistÄ«tu platformas latentuma palielinÄÅ”anos agrÄk tajÄ paÅ”Ä rÄ«tÄ, klastera pÄkstu un mezglu skaits palielinÄjÄs. Tas izraisÄ«ja ARP keÅ”atmiÅas izsmelÅ”anu visos mÅ«su mezglos.
Ir trÄ«s Linux opcijas, kas saistÄ«tas ar ARP keÅ”atmiÅu:
()
gc_thresh3 - tas ir stingrs ierobežojums. Ierakstu ākaimiÅu tabulas pÄrpildeā parÄdÄ«Å”anÄs žurnÄlÄ nozÄ«mÄja, ka pat pÄc sinhronÄs atkritumu savÄkÅ”anas (GC) ARP keÅ”atmiÅÄ nebija pietiekami daudz vietas, lai saglabÄtu blakus esoÅ”o ierakstu. Å ajÄ gadÄ«jumÄ kodols vienkÄrÅ”i pilnÄ«bÄ izmeta paketi.
MÄs izmantojam kÄ tÄ«kla audums Kubernetes. Paketes tiek pÄrsÅ«tÄ«tas, izmantojot VXLAN. VXLAN ir L2 tunelis, kas izveidots virs L3 tÄ«kla. TehnoloÄ£ija izmanto MAC-in-UDP (MAC Address-in-User Datagram Protocol) iekapsulÄciju un ļauj paplaÅ”inÄt 2. slÄÅa tÄ«kla segmentus. Transporta protokols fiziskÄ datu centra tÄ«klÄ ir IP plus UDP.
AttÄls 2-1. Flaneļa diagramma ()
AttÄls 2-2. VXLAN pakotne ()
Katrs Kubernetes darbinieka mezgls pieŔķir virtuÄlo adreÅ”u telpu ar /24 masku no lielÄka /9 bloka. Katram mezglam tas ir viens ieraksts marÅ”rutÄÅ”anas tabulÄ, viens ieraksts ARP tabulÄ (interfeisÄ flanel.1) un viens ieraksts komutÄcijas tabulÄ (FDB). Tie tiek pievienoti, pirmo reizi startÄjot darbinieka mezglu vai katru reizi, kad tiek atklÄts jauns mezgls.
TurklÄt mezgla-pod (vai pod-pod) komunikÄcija galu galÄ notiek caur saskarni eth0 (kÄ parÄdÄ«ts iepriekÅ” redzamajÄ flaneļa diagrammÄ). TÄ rezultÄtÄ ARP tabulÄ tiek parÄdÄ«ts papildu ieraksts katram atbilstoÅ”ajam avota un mÄrÄ·a resursdatoram.
MÅ«su vidÄ Å”Äda veida komunikÄcija ir ļoti izplatÄ«ta. Kubernetes pakalpojumu objektiem tiek izveidots ELB, un Kubernetes reÄ£istrÄ katru mezglu ar ELB. ELB neko nezina par podiem, un atlasÄ«tais mezgls var nebÅ«t paketes galamÄrÄ·is. Lieta ir tÄda, ka tad, kad mezgls saÅem paketi no ELB, tas to uzskata, Åemot vÄrÄ noteikumus iptables konkrÄtam pakalpojumam un nejauÅ”i izvÄlas podziÅu citÄ mezglÄ.
Kļūmes brÄ«dÄ« klasterÄ« bija 605 mezgli. IepriekÅ” minÄto iemeslu dÄļ ar to pietika, lai pÄrvarÄtu nozÄ«mi gc_thresh3, kas ir noklusÄjuma vÄrtÄ«ba. Kad tas notiek, ne tikai sÄk izmest paketes, bet arÄ« visa Flanel virtuÄlÄ adreÅ”u telpa ar /24 masku pazÅ«d no ARP tabulas. Node-pod komunikÄcija un DNS vaicÄjumi ir pÄrtraukti (DNS tiek mitinÄts klasterÄ«; sÄ«kÄku informÄciju lasiet vÄlÄk Å”ajÄ rakstÄ).
Lai atrisinÄtu Å”o problÄmu, jums ir jÄpalielina vÄrtÄ«bas gc_thresh1, gc_thresh2 Šø gc_thresh3 un restartÄjiet Flanel, lai atkÄrtoti reÄ£istrÄtu trÅ«kstoÅ”os tÄ«klus.
NegaidÄ«ta DNS mÄrogoÅ”ana
MigrÄcijas procesÄ mÄs aktÄ«vi izmantojÄm DNS, lai pÄrvaldÄ«tu trafiku un pakÄpeniski pÄrsÅ«tÄ«tu pakalpojumus no vecÄs infrastruktÅ«ras uz Kubernetes. MÄs iestatÄ«jÄm salÄ«dzinoÅ”i zemas TTL vÄrtÄ«bas saistÄ«tajiem ierakstu komplektiem marÅ”rutÄ53. Kad vecÄ infrastruktÅ«ra darbojÄs EC2 gadÄ«jumos, mÅ«su atrisinÄtÄja konfigurÄcija norÄdÄ«ja uz Amazon DNS. MÄs to uztvÄrÄm kÄ paÅ”saprotamu, un zemÄ TTL ietekme uz mÅ«su pakalpojumiem un Amazon pakalpojumiem (piemÄram, DynamoDB) lielÄkoties palika nepamanÄ«ta.
MigrÄjot pakalpojumus uz Kubernetes, mÄs atklÄjÄm, ka DNS apstrÄdÄ 250 tÅ«kstoÅ”us pieprasÄ«jumu sekundÄ. TÄ rezultÄtÄ lietojumprogrammÄm sÄka rasties pastÄvÄ«gas un nopietnas DNS vaicÄjumu noildzes. Tas notika, neskatoties uz neticamajiem centieniem optimizÄt un pÄrslÄgt DNS nodroÅ”inÄtÄju uz CoreDNS (kas maksimÄlÄs slodzes laikÄ sasniedza 1000 podi, kas darbojas ar 120 kodoliem).
PÄtot citus iespÄjamos cÄloÅus un risinÄjumus, mÄs atklÄjÄm , aprakstot sacensÄ«bu apstÄkļus, kas ietekmÄ pakeÅ”u filtrÄÅ”anas sistÄmu netfilter operÄtÄjsistÄmÄ Linux. NovÄrotÄs noildzes kopÄ ar pieaugoÅ”u skaitÄ«tÄju ievietot_neizdevÄs flanela saskarnÄ bija saskaÅÄ ar raksta atklÄjumiem.
ProblÄma rodas avota un galamÄrÄ·a tÄ«kla adreÅ”u tulkoÅ”anas (SNAT un DNAT) posmÄ un pÄc tam ievadÄ«Å”anas tabulÄ. saplÅ«st. Viens no iekÅ”Äji apspriestajiem un kopienas ieteiktajiem risinÄjumiem bija DNS pÄrvietoÅ”ana uz paÅ”u darbinieku mezglu. Å ajÄ gadÄ«jumÄ:
- SNAT nav nepiecieÅ”ams, jo satiksme paliek mezglÄ. Tas nav jÄmarÅ”rutÄ caur interfeisu eth0.
- DNAT nav nepiecieÅ”ams, jo galamÄrÄ·a IP ir lokÄls mezglam, nevis nejauÅ”i izvÄlÄts pods saskaÅÄ ar noteikumiem iptables.
MÄs nolÄmÄm pieturÄties pie Ŕīs pieejas. CoreDNS tika izvietots kÄ DaemonSet pakalpojumÄ Kubernetes, un mÄs ieviesÄm vietÄjÄ mezgla DNS serveri solve.conf katrs pods, uzstÄdot karogu --cluster-dns komandÄm kubeletā. Å is risinÄjums izrÄdÄ«jÄs efektÄ«vs DNS taimauta gadÄ«jumÄ.
TomÄr mÄs joprojÄm redzÄjÄm pakeÅ”u zudumu un skaitÄ«tÄja pieaugumu ievietot_neizdevÄs flaneļa saskarnÄ. Tas turpinÄjÄs pÄc tam, kad tika ieviests risinÄjums, jo mÄs varÄjÄm likvidÄt SNAT un/vai DNAT tikai DNS trafikam. SacensÄ«bu apstÄkļi tika saglabÄti cita veida satiksmei. Par laimi, lielÄkÄ daļa mÅ«su pakeÅ”u ir TCP, un, ja rodas problÄma, tÄs vienkÄrÅ”i tiek pÄrsÅ«tÄ«tas. MÄs joprojÄm cenÅ”amies atrast piemÄrotu risinÄjumu visiem satiksmes veidiem.
SÅ«tÅa izmantoÅ”ana labÄkai slodzes lÄ«dzsvaroÅ”anai
MigrÄjot aizmugursistÄmas pakalpojumus uz Kubernetes, mÄs sÄkÄm ciest no nesabalansÄtas slodzes starp podiem. MÄs atklÄjÄm, ka HTTP Keepalive izraisÄ«ja ELB savienojumu pÄrtraukÅ”anu katras ieviestÄs izvietoÅ”anas pirmajos gatavajos apvidos. TÄdÄjÄdi lielÄkÄ daļa datplÅ«smas tika veikta caur nelielu procentuÄlo daļu no pieejamajiem podiem. Pirmais mÅ«su pÄrbaudÄ«tais risinÄjums bija MaxSurge iestatÄ«Å”ana uz 100% jauniem izvietojumiem sliktÄkajiem scenÄrijiem. Efekts izrÄdÄ«jÄs nenozÄ«mÄ«gs un neperspektÄ«vs lielÄkas izvietoÅ”anas ziÅÄ.
Cits risinÄjums, ko izmantojÄm, bija mÄkslÄ«gi palielinÄt resursu pieprasÄ«jumus kritiskiem pakalpojumiem. Å ajÄ gadÄ«jumÄ tuvumÄ novietotÄm pÄkstÄ«m bÅ«tu lielÄka manevrÄÅ”anas iespÄja salÄ«dzinÄjumÄ ar citÄm smagajÄm pÄkstÄ«m. Tas nedarbotos arÄ« ilgtermiÅÄ, jo tÄ bÅ«tu resursu izniekoÅ”ana. TurklÄt mÅ«su Node lietojumprogrammas bija viena pavediena un attiecÄ«gi varÄja izmantot tikai vienu kodolu. VienÄ«gais reÄlais risinÄjums bija izmantot labÄku slodzes lÄ«dzsvaroÅ”anu.
MÄs jau sen vÄlÄjÄmies pilnÄ«bÄ novÄrtÄt . PaÅ”reizÄjÄ situÄcija ļÄva mums to izmantot ļoti ierobežotÄ veidÄ un iegÅ«t tÅ«lÄ«tÄjus rezultÄtus. Envoy ir augstas veiktspÄjas atvÄrtÄ koda XNUMX. slÄÅa starpniekserveris, kas paredzÄts lielÄm SOA lietojumprogrammÄm. Tas var ieviest uzlabotas slodzes lÄ«dzsvaroÅ”anas metodes, tostarp automÄtiskus atkÄrtotus mÄÄ£inÄjumus, automÄtiskie slÄdži un globÄlÄ Ätruma ierobežoÅ”ana. (PiezÄ«me. tulk.: VairÄk par to varat lasÄ«t Å”eit par Istio, kura pamatÄ ir Envoy.)
MÄs nonÄcÄm pie Å”Ädas konfigurÄcijas: katram blokam jÄbÅ«t Envoy blakusvÄÄ£im un vienam marÅ”rutam, un savienojiet kopu ar konteineru lokÄli, izmantojot portu. Lai samazinÄtu iespÄjamo kaskÄdi un saglabÄtu nelielu trÄpÄ«juma rÄdiusu, mÄs izmantojÄm sÅ«tÅa priekÅ”Äjo starpniekservera bloku parku ā vienu katrÄ pieejamÄ«bas zonÄ (AZ) katram pakalpojumam. ViÅi paļÄvÄs uz vienkÄrÅ”u pakalpojumu atklÄÅ”anas dzinÄju, ko bija uzrakstÄ«jis viens no mÅ«su inženieriem, kas vienkÄrÅ”i atgrieza sarakstu ar aplikÄcijÄm katrÄ AZ konkrÄtajam pakalpojumam.
PÄc tam pakalpojumu frontes sÅ«tÅi izmantoja Å”o pakalpojumu atklÄÅ”anas mehÄnismu ar vienu augÅ”upÄjo kopu un marÅ”rutu. MÄs iestatÄ«jÄm atbilstoÅ”us taimautus, palielinÄjÄm visus Ä·Ädes pÄrtraucÄju iestatÄ«jumus un pievienojÄm minimÄlu atkÄrtotÄ mÄÄ£inÄjuma konfigurÄciju, lai palÄ«dzÄtu novÄrst atseviŔķas kļūmes un nodroÅ”inÄtu vienmÄrÄ«gu izvietoÅ”anu. Katram no Å”iem dienesta priekÅ”Äjiem sÅ«tÅiem mÄs novietojÄm TCP ELB. Pat ja mÅ«su galvenÄ starpniekservera slÄÅa Keepalive bija iestrÄdzis dažiem Envoy podiem, tie joprojÄm varÄja daudz labÄk apstrÄdÄt slodzi un tika konfigurÄti tÄ, lai aizmugursistÄmÄ balansÄtu, izmantojot vismaz_pieprasÄ«jumu.
IzvietoÅ”anai mÄs izmantojÄm preStop ÄÄ·i gan uzlikÅ”anas blokiem, gan blakusvÄÄ£a kÄrbÄm. ÄÄ·is izraisÄ«ja kļūdu, pÄrbaudot administratora galapunkta statusu, kas atrodas blakusvÄÄ£a konteinerÄ, un kÄdu laiku aizmiga, lai ļautu pÄrtraukt aktÄ«vo savienojumu darbÄ«bu.
Viens no iemesliem, kÄpÄc mÄs varÄjÄm pÄrvietoties tik Ätri, ir detalizÄtie rÄdÄ«tÄji, kurus varÄjÄm viegli integrÄt tipiskÄ Prometheus instalÄcijÄ. Tas ļÄva mums precÄ«zi redzÄt, kas notiek, kamÄr mÄs pielÄgojÄm konfigurÄcijas parametrus un pÄrdalÄm trafiku.
RezultÄti bija tÅ«lÄ«tÄji un acÄ«mredzami. MÄs sÄkÄm ar nesabalansÄtÄkajiem pakalpojumiem, un Å”obrÄ«d tas darbojas klastera 12 svarÄ«gÄko pakalpojumu priekÅ”Ä. Å ogad mÄs plÄnojam pÄreju uz pilna servisa tÄ«klu ar modernÄku pakalpojumu atklÄÅ”anu, Ä·Ädes pÄrtraukumiem, noviržu noteikÅ”anu, Ätruma ierobežoÅ”anu un izsekoÅ”anu.
AttÄls 3-1. Viena pakalpojuma CPU konverÄ£ence pÄrejas laikÄ uz Envoy
Gala rezultÄts
Izmantojot Å”o pieredzi un papildu pÄtÄ«jumus, esam izveidojuÅ”i spÄcÄ«gu infrastruktÅ«ras komandu ar spÄcÄ«gÄm prasmÄm lielu Kubernetes klasteru projektÄÅ”anÄ, izvietoÅ”anÄ un darbÄ«bÄ. Visiem Tinder inženieriem tagad ir zinÄÅ”anas un pieredze konteineru iepakoÅ”anai un lietojumprogrammu izvietoÅ”anai Kubernetes.
Kad vecajÄ infrastruktÅ«rÄ radÄs nepiecieÅ”amÄ«ba pÄc papildu jaudas, mums bija jÄgaida vairÄkas minÅ«tes, lÄ«dz tiks palaists jauns EC2 gadÄ«jums. Tagad konteineri sÄk darboties un sÄk apstrÄdÄt trafiku dažu sekunžu, nevis minÅ«Å”u laikÄ. VairÄku konteineru plÄnoÅ”ana vienÄ EC2 eksemplÄrÄ nodroÅ”ina arÄ« uzlabotu horizontÄlo koncentrÄciju. RezultÄtÄ mÄs prognozÄjam bÅ«tisku EC2019 izmaksu samazinÄjumu 2. gadÄ salÄ«dzinÄjumÄ ar pagÄjuÅ”o gadu.
MigrÄcija ilga gandrÄ«z divus gadus, bet mÄs to pabeidzÄm 2019. gada martÄ. PaÅ”laik Tinder platforma darbojas tikai Kubernetes klasterÄ«, kas sastÄv no 200 pakalpojumiem, 1000 mezgliem, 15 000 podiem un 48 000 darbojoÅ”iem konteineriem. InfrastruktÅ«ra vairs nav vienÄ«gÄ operÄciju komandu joma. Visi mÅ«su inženieri dala Å”o atbildÄ«bu un kontrolÄ savu lietojumprogrammu izveides un izvietoÅ”anas procesu, izmantojot tikai kodu.
PS no tulka
Lasiet arÄ« rakstu sÄriju mÅ«su emuÄrÄ:
- Ā«'.
- Ā«'.
- Ā«'.
- Ā«'.
- Ā«'.
- Ā«'.
- Ā«'.
- Ā«'.
- Ā«'.
- Ā«'.
Avots: www.habr.com