Nota. transl.: Ang mga empleyado sa bantog nga serbisyo sa Tinder sa kalibotan bag-o lang mipaambit sa pipila ka teknikal nga mga detalye sa paglalin sa ilang imprastraktura ngadto sa Kubernetes. Ang proseso milungtad hapit duha ka tuig ug miresulta sa paglansad sa usa ka dako kaayo nga plataporma sa K8s, nga naglangkob sa 200 nga mga serbisyo nga gi-host sa 48 ka libo nga mga sudlanan. Unsang makapainteres nga mga kalisdanan ang nasugatan sa mga inhenyero sa Tinder ug unsa ang mga resulta nga ilang nahimo? Basaha kini nga hubad.
Ngano?
Hapit duha ka tuig ang milabay, nakahukom ang Tinder nga ibalhin ang plataporma niini sa Kubernetes. Gitugotan sa Kubernetes ang Tinder team nga mag-container ug mobalhin sa produksiyon nga adunay gamay nga paningkamot pinaagi sa dili mausab nga pag-deploy (dili mausab nga pagdeploy). Sa kini nga kaso, ang asembliya sa mga aplikasyon, ang ilang pag-deploy, ug ang imprastraktura mismo ang talagsaon nga gihubit pinaagi sa code.
Nangita usab kami og solusyon sa problema sa scalability ug stability. Kung nahimong kritikal ang pag-scale, kanunay namong maghulat og pipila ka minuto para sa bag-ong mga instance sa EC2 nga mosulbong. Ang ideya sa paglansad sa mga sudlanan ug pagsugod sa pagserbisyo sa trapiko sa mga segundo imbis nga mga minuto nahimo’g madanihon kaayo kanamo.
Ang proseso nahimong lisud. Atol sa among paglalin sa sayong bahin sa 2019, ang Kubernetes cluster nakaabot sa kritikal nga masa ug nagsugod kami sa pagsugat sa lainlaing mga problema tungod sa gidaghanon sa trapiko, gidak-on sa cluster, ug DNS. Sa kadugayan, nasulbad namo ang daghang makapaikag nga mga problema nga may kalabutan sa pagbalhin sa 200 ka serbisyo ug pagmintinar sa usa ka Kubernetes cluster nga gilangkuban sa 1000 ka node, 15000 ka pod ug 48000 ka running container.
Sa unsang paagi?
Sukad sa Enero 2018, naagian na nato ang lain-laing ang-ang sa paglalin. Nagsugod kami pinaagi sa pag-container sa tanan namong mga serbisyo ug pag-deploy niini sa Kubernetes test cloud environment. Sugod niadtong Oktubre, gisugdan namo ang paagi sa pagbalhin sa tanang kasamtangang serbisyo ngadto sa Kubernetes. Pagka Marso sa misunod nga tuig, nahuman namo ang paglalin ug karon ang plataporma sa Tinder kay ekslusibong midagan sa Kubernetes.
Paghimo og mga hulagway para sa Kubernetes
Kami adunay kapin sa 30 ka source code repository alang sa mga microservice nga nagdagan sa usa ka Kubernetes cluster. Ang code niini nga mga repository kay gisulat sa lain-laing lengguwahe (pananglitan, Node.js, Java, Scala, Go) nga adunay daghang runtime environment para sa samang pinulongan.
Ang sistema sa pagtukod gilaraw aron maghatag usa ka hingpit nga napasadya nga "konteksto sa pagtukod" alang sa matag microservice. Kasagaran kini naglangkob sa usa ka Dockerfile ug usa ka lista sa mga shell command. Ang ilang sulud hingpit nga napasadya, ug sa samang higayon, kining tanan nga mga konteksto sa pagtukod gisulat sumala sa usa ka standardized format. Ang pag-standardize sa mga konteksto sa pagtukod nagtugot sa usa ka sistema sa pagtukod sa pagdumala sa tanan nga mga microservice.
Hulagway 1-1. Standardized nga proseso sa pagtukod pinaagi sa Builder container
Aron makab-ot ang labing taas nga pagkamakanunayon tali sa mga runtime (runtime nga palibot) ang parehas nga proseso sa pagtukod gigamit sa panahon sa pag-uswag ug pagsulay. Nag-atubang kami sa usa ka makapaikag nga hagit: kinahanglan namon nga maghimo usa ka paagi aron masiguro ang pagkamakanunayon sa pagtukod sa palibot sa tibuuk nga plataporma. Aron makab-ot kini, ang tanan nga mga proseso sa asembliya gidala sa sulod sa usa ka espesyal nga sudlanan. magtutukod.
Ang pagpatuman sa iyang sudlanan nanginahanglan mga advanced nga teknik sa Docker. Gipanunod sa Builder ang lokal nga user ID ug mga sekreto (sama sa SSH key, mga kredensyal sa AWS, ug uban pa) nga gikinahanglan aron maka-access sa mga pribadong Tinder repository. Nag-mount kini sa mga lokal nga direktoryo nga adunay sulud nga natural nga pagtipig sa mga artifact sa pagtukod. Kini nga pamaagi nagpauswag sa pasundayag tungod kay kini nagwagtang sa panginahanglan sa pagkopya sa pagtukod sa mga artifact tali sa Builder container ug sa host. Ang gitipigan nga mga artifact sa pagtukod mahimong magamit pag-usab nga wala’y dugang nga pag-configure.
Alang sa pipila ka mga serbisyo, kinahanglan namong maghimo ug laing sudlanan aron mapa ang compilation environment ngadto sa runtime environment (pananglitan, ang Node.js bcrypt library nagmugna ug platform-specific binary artifacts atol sa instalasyon). Atol sa proseso sa pag-compile, ang mga kinahanglanon mahimong magkalainlain tali sa mga serbisyo, ug ang katapusan nga Dockerfile giipon dayon.
Kubernetes cluster architecture ug migration
Pagdumala sa gidak-on sa cluster
Nakahukom mi nga gamiton kube-aws alang sa automated cluster deployment sa Amazon EC2 instances. Sa sinugdanan, ang tanan nagtrabaho sa usa ka komon nga pundok sa mga node. Naamgohan dayon namo ang panginahanglan sa pagbulag sa mga workloads pinaagi sa gidak-on ug matang sa instance aron mas episyente ang paggamit sa mga kahinguhaan. Ang lohika mao nga ang pagpadagan sa daghang loaded multi-threaded pods nahimong mas predictable sa performance kay sa ilang coexistence sa daghang single-threaded pods.
Sa katapusan, kami miuyon sa:
- m5.4x dako - alang sa pagmonitor (Prometheus);
- c5.4x dako - para sa Node.js workload (single-threaded workload);
- c5.2x dako - para sa Java ug Go (multithreaded workload);
- c5.4x dako - alang sa control panel (3 nodes).
Pagbalhin
Usa sa mga lakang sa pagpangandam sa paglalin gikan sa karaang imprastraktura ngadto sa Kubernetes mao ang pag-redirect sa kasamtangang direktang komunikasyon tali sa mga serbisyo ngadto sa bag-ong load balancers (Elastic Load Balancers (ELB). Gibuhat sila sa usa ka piho nga subnet sa usa ka virtual private cloud (VPC). Kini nga subnet konektado sa usa ka Kubernetes VPC. Kini nagtugot kanamo sa paglalin sa mga module sa hinay-hinay, nga wala gikonsiderar ang piho nga han-ay sa mga dependency sa serbisyo.
Kini nga mga endpoint gihimo gamit ang gibug-aton nga set sa DNS record nga adunay mga CNAME nga nagpunting sa matag bag-ong ELB. Aron mabalhin, midugang kami og bag-ong entry nga nagpunting sa bag-ong ELB sa serbisyo sa Kubernetes nga adunay gibug-aton nga 0. Dayon among gibutang ang Time To Live (TTL) sa entry nga gibutang sa 0. Human niini, ang daan ug bag-ong mga gibug-aton kay hinay-hinay nga gi-adjust, ug sa katapusan 100% sa load gipadala ngadto sa usa ka bag-ong server. Human makompleto ang switching, ang TTL value mibalik sa mas igo nga lebel.
Ang Java modules nga among nabatonan makasagubang sa ubos nga TTL DNS, apan ang mga aplikasyon sa Node dili makahimo. Usa sa mga inhenyero misulat pag-usab sa bahin sa koneksyon pool code ug giputos kini sa usa ka manedyer nga nag-update sa mga pool matag 60 segundos. Ang gipili nga pamaagi nagtrabaho pag-ayo ug wala’y bisan unsang mamatikdan nga pagkadaot sa pasundayag.
Ang mga leksyon
Ang mga Limitasyon sa Panapton sa Network
Sa sayong buntag sa Enero 8, 2019, ang plataporma sa Tinder wala damha nga nahagsa. Agig tubag sa usa ka wala'y kalabutan nga pagtaas sa latency sa plataporma sa sayo pa nianang buntaga, ang gidaghanon sa mga pod ug mga node sa cluster misaka. Kini ang hinungdan nga ang cache sa ARP nahurot sa tanan namong mga node.
Adunay tulo ka mga opsyon sa Linux nga may kalabutan sa ARP cache:
()
gc_thresh3 - kini usa ka lisud nga limitasyon. Ang dagway sa mga entries nga "nag-awas sa lamesa sa silingan" sa log nagpasabot nga bisan human sa dungan nga pagkolekta sa basura (GC), wala'y igong luna sa cache sa ARP aron tipigan ang silingang entry. Sa kini nga kaso, ang kernel yano nga gilabay ang pakete sa hingpit.
Gigamit namon isip usa ka tela sa network sa Kubernetes. Ang mga pakete gipasa sa VXLAN. Ang VXLAN usa ka L2 tunnel nga gipataas sa ibabaw sa usa ka L3 network. Ang teknolohiya naggamit sa MAC-in-UDP (MAC Address-in-User Datagram Protocol) nga encapsulation ug nagtugot sa pagpalapad sa Layer 2 nga mga bahin sa network. Ang transport protocol sa pisikal nga data center network mao ang IP plus UDP.
Hulagway 2–1. Flannel diagram ()
Hulagway 2–2. VXLAN nga pakete ()
Ang matag Kubernetes worker node naggahin ug virtual address space nga adunay /24 mask gikan sa mas dako nga /9 block. Alang sa matag node mao kini usa ka entry sa routing table, usa ka entry sa ARP table (sa flannel.1 interface), ug usa ka entry sa switching table (FDB). Gidugang kini sa unang higayon nga magsugod ang worker node o matag higayon nga madiskubre ang bag-ong node.
Dugang pa, ang komunikasyon sa node-pod (o pod-pod) sa katapusan moagi sa interface eth0 (ingon sa gipakita sa Flannel diagram sa ibabaw). Kini moresulta sa usa ka dugang nga entry sa ARP table alang sa matag katugbang nga tinubdan ug destinasyon host.
Sa atong palibot, kini nga matang sa komunikasyon komon kaayo. Alang sa mga butang nga serbisyo sa Kubernetes, usa ka ELB ang gihimo ug girehistro sa Kubernetes ang matag node sa ELB. Ang ELB walay nahibal-an bahin sa mga pod ug ang gipili nga node mahimong dili ang katapusan nga destinasyon sa pakete. Ang punto mao nga kung ang usa ka node makadawat usa ka pakete gikan sa ELB, gikonsiderar kini nga gikonsiderar ang mga lagda iptables alang sa usa ka piho nga serbisyo ug random nga nagpili usa ka pod sa laing node.
Sa panahon sa kapakyasan, adunay 605 nga mga node sa cluster. Alang sa mga hinungdan nga gipahayag sa ibabaw, kini igo na aron mabuntog ang kamahinungdanon gc_thresh3, nga mao ang default. Kung kini mahitabo, dili lamang ang mga pakete magsugod sa paghulog, apan ang tibuok Flannel virtual address space nga adunay /24 mask mawala gikan sa ARP table. Ang komunikasyon sa node-pod ug mga pangutana sa DNS nabalda (Ang DNS gi-host sa usa ka cluster; basaha sa ulahi niini nga artikulo alang sa mga detalye).
Aron masulbad kini nga problema, kinahanglan nimo nga dugangan ang mga kantidad gc_thresh1, gc_thresh2 и gc_thresh3 ug i-restart ang Flannel aron marehistro pag-usab ang nawala nga mga network.
Wala damha nga DNS scaling
Atol sa proseso sa paglalin, aktibo namong gigamit ang DNS sa pagdumala sa trapiko ug hinayhinay nga pagbalhin sa mga serbisyo gikan sa karaang imprastraktura ngadto sa Kubernetes. Nagbutang kami og medyo ubos nga mga kantidad sa TTL alang sa mga kauban nga RecordSets sa Route53. Sa diha nga ang daan nga imprastraktura nagdagan sa EC2 nga mga higayon, ang among pagsulbad sa pagsulbad nagpunting sa Amazon DNS. Gidawat namo kini ug ang epekto sa ubos nga TTL sa among mga serbisyo ug serbisyo sa Amazon (sama sa DynamoDB) wala kaayo mamatikdi.
Sa among pagbalhin sa mga serbisyo sa Kubernetes, among nakita nga ang DNS nagproseso sa 250 ka libo nga mga hangyo matag segundo. Ingon nga resulta, ang mga aplikasyon nagsugod sa pagsinati sa makanunayon ug seryoso nga mga timeout alang sa DNS nga mga pangutana. Nahitabo kini bisan pa sa talagsaon nga mga paningkamot sa pag-optimize ug pagbalhin sa DNS provider ngadto sa CoreDNS (nga sa peak load nakaabot sa 1000 pods nga nagdagan sa 120 cores).
Samtang nagsiksik sa ubang posibleng hinungdan ug solusyon, among nadiskobrehan , nga naghulagway sa kahimtang sa lumba nga nakaapekto sa packet filtering framework netfilter sa Linux. Ang mga timeout nga among naobserbahan, inubanan sa nagkadaghang counter insert_failed sa Flannel interface nahiuyon sa mga nahibal-an sa artikulo.
Ang problema mahitabo sa yugto sa Source ug Destination Network Address Translation (SNAT ug DNAT) ug sa sunod nga pagsulod sa lamesa conntrack. Usa sa mga workaround nga gihisgutan sa sulod ug gisugyot sa komunidad mao ang pagbalhin sa DNS ngadto sa worker node mismo. Niini nga kaso:
- Dili kinahanglan ang SNAT tungod kay ang trapiko nagpabilin sa sulod sa node. Dili kinahanglan nga madala pinaagi sa interface eth0.
- Dili kinahanglan ang DNAT tungod kay ang destinasyon nga IP lokal sa node, ug dili usa ka random nga gipili nga pod sumala sa mga lagda iptables.
Nakahukom kami nga magpadayon sa kini nga pamaagi. Gi-deploy ang CoreDNS isip DaemonSet sa Kubernetes ug gipatuman namo ang lokal nga node DNS server sa pagsulbad.conf matag pod pinaagi sa pagbutang og bandila --cluster-dns mga mando kubelet . Kini nga solusyon nahimong epektibo alang sa DNS timeouts.
Bisan pa, nakita gihapon namon ang pagkawala sa packet ug pagtaas sa counter insert_failed sa Flannel interface. Nagpadayon kini human gipatuman ang workaround tungod kay natangtang namo ang SNAT ug/o DNAT para sa trapiko sa DNS lamang. Ang mga kondisyon sa lumba gipreserbar alang sa ubang mga matang sa trapiko. Maayo na lang, kadaghanan sa among mga pakete kay TCP, ug kung adunay problema nga mahitabo kini gi-retransmit lang. Kami naningkamot gihapon sa pagpangita og angay nga solusyon alang sa tanang matang sa trapiko.
Paggamit sa Envoy alang sa Mas Maayo nga Pagbalanse sa Load
Sa among pagbalhin sa mga serbisyo sa backend sa Kubernetes, nagsugod kami sa pag-antos sa dili balanse nga pagkarga tali sa mga pod. Among nakaplagan nga ang HTTP Keepalive maoy hinungdan sa mga koneksyon sa ELB nga magbitay sa unang andam nga mga pod sa matag deployment nga gilukot. Sa ingon, ang kadaghanan sa trapiko miagi sa gamay nga porsyento sa magamit nga mga pod. Ang una nga solusyon nga among gisulayan mao ang pagbutang sa MaxSurge sa 100% sa mga bag-ong deployment alang sa labing grabe nga mga sitwasyon sa kaso. Ang epekto nahimo nga wala’y hinungdan ug wala’y saad sa mga termino sa daghang mga pag-deploy.
Laing solusyon nga among gigamit mao ang artipisyal nga pagdugang sa mga hangyo sa kahinguhaan alang sa mga kritikal nga serbisyo. Sa kini nga kaso, ang mga pod nga gibutang sa duol adunay daghang lugar sa pagmaniobra kon itandi sa ubang mga bug-at nga pod. Dili usab kini molihok sa kadugayan tungod kay kini usa ka pag-usik sa mga kahinguhaan. Dugang pa, ang among mga aplikasyon sa Node mga single-threaded ug, sumala niana, makagamit lang og usa ka core. Ang bugtong tinuod nga solusyon mao ang paggamit sa mas maayo nga pagbalanse sa load.
Dugay na namong gusto nga hingpit nga mapasalamatan . Ang kasamtangan nga sitwasyon nagtugot kanamo sa pag-deploy niini sa limitado nga paagi ug makakuha dayon nga mga resulta. Ang Envoy usa ka high-performance, open-source, layer-XNUMX proxy nga gidisenyo alang sa dagkong mga aplikasyon sa SOA. Makapatuman kini og mga advanced load balancing techniques, lakip ang automatic retries, circuit breakers, ug global rate limiting. (Nota. transl.: Mahimo nimong mabasa ang dugang bahin niini sa mahitungod sa Istio, nga gibase sa Envoy.)
Gibuhat namo ang mosunod nga configuration: adunay Envoy sidecar alang sa matag pod ug usa ka rota, ug ikonektar ang cluster ngadto sa sudlanan sa lokal pinaagi sa pantalan. Aron mamenosan ang potensyal nga pag-cascade ug mamentinar ang gamay nga hit radius, migamit kami og armada sa Envoy front-proxy pod, usa kada Availability Zone (AZ) para sa matag serbisyo. Nagsalig sila sa usa ka yano nga makina sa pagdiskobre sa serbisyo nga gisulat sa usa sa among mga inhenyero nga nagbalik ra usa ka lista sa mga pod sa matag AZ alang sa usa ka gihatag nga serbisyo.
Gigamit dayon sa mga Envoy sa atubangan sa serbisyo kini nga mekanismo sa pagdiskubre sa serbisyo nga adunay usa ka upstream cluster ug ruta. Nagtakda kami og igong mga timeout, gipadaghan ang tanang setting sa circuit breaker, ug gidugang ang gamay nga pag-configure sa pagsulay aron makatabang sa usa ka kapakyasan ug masiguro ang hapsay nga pag-deploy. Nagbutang kami og TCP ELB atubangan sa matag usa niining mga service front-Envoys. Bisan kung ang keepalive gikan sa among nag-unang proxy nga layer natanggong sa pipila ka Envoy pods, nakahimo gihapon sila sa pagdumala sa load nga mas maayo ug gi-configure aron mabalanse pinaagi sa least_request sa backend.
Para sa deployment, gigamit namo ang preStop hook sa mga application pod ug sidecar pod. Ang kaw-it nagpahinabog kasaypanan sa pagsusi sa kahimtang sa admin endpoint nga nahimutang sa sidecar nga sudlanan ug natulog sa makadiyot aron tugotan ang mga aktibong koneksyon nga mahunong.
Usa sa mga hinungdan nga dali ra kaming nakalihok tungod sa mga detalyado nga sukatan nga dali ra namon na-integrate sa usa ka tipikal nga pag-install sa Prometheus. Kini nagtugot kanamo nga makita kung unsa gyud ang nahitabo samtang among gi-adjust ang mga parameter sa pag-configure ug gi-apod-apod usab ang trapiko.
Ang mga resulta diha-diha dayon ug dayag. Nagsugod kami sa labing dili balanse nga mga serbisyo, ug sa pagkakaron naglihok kini atubangan sa 12 nga labing hinungdanon nga serbisyo sa cluster. Karong tuiga nagplano kami og transisyon ngadto sa full service mesh nga adunay mas abante nga service discovery, circuit breaking, outlier detection, rate limiting ug tracing.
Hulagway 3–1. CPU convergence sa usa ka serbisyo sa panahon sa transisyon ngadto sa Envoy
Katapusan nga sangputanan
Pinaagi sa kini nga kasinatian ug dugang nga panukiduki, nakatukod kami usa ka lig-on nga team sa imprastraktura nga adunay lig-on nga kahanas sa pagdesinyo, pag-deploy, ug pag-operate sa dagkong mga cluster sa Kubernetes. Ang tanan nga mga inhenyero sa Tinder karon adunay kahibalo ug kasinatian sa pagputos sa mga sudlanan ug pag-deploy sa mga aplikasyon sa Kubernetes.
Kung ang panginahanglan alang sa dugang nga kapasidad mitungha sa daan nga imprastraktura, kinahanglan kaming maghulat pipila ka minuto alang sa bag-ong mga instance sa EC2 nga ilunsad. Karon ang mga sudlanan nagsugod sa pagdagan ug nagsugod sa pagproseso sa trapiko sulod sa mga segundo imbes sa mga minuto. Ang pag-iskedyul sa daghang mga sudlanan sa usa ka pananglitan sa EC2 naghatag usab ug gipaayo nga pinahigda nga konsentrasyon. Ingon usa ka sangputanan, gitagna namon ang usa ka hinungdanon nga pagkunhod sa mga gasto sa EC2019 sa 2 kumpara sa miaging tuig.
Ang paglalin milungtad og halos duha ka tuig, apan nahuman namo kini niadtong Marso 2019. Sa pagkakaron, ang plataporma sa Tinder eksklusibong nagdagan sa usa ka Kubernetes cluster nga gilangkuban sa 200 ka serbisyo, 1000 ka node, 15 ka pod ug 000 ka running container. Ang imprastraktura dili na ang bugtong domain sa mga operations team. Ang tanan sa among mga inhenyero nag-ambit niini nga responsibilidad ug nagkontrol sa proseso sa pagtukod ug pag-deploy sa ilang mga aplikasyon gamit lamang ang code.
PS gikan sa tighubad
Basaha usab ang serye sa mga artikulo sa among blog:
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
Source: www.habr.com