Catetan. narjamahkeun.: Karyawan ti layanan Tinder kawentar dunya nembe dibagikeun sababaraha rinci teknis migrasi infrastruktur maranéhna pikeun Kubernetes. Prosesna nyandak ampir dua taun sareng nyababkeun peluncuran platform skala ageung dina K8s, anu diwangun ku 200 jasa anu diayakeun dina 48 rébu peti. Kasusah anu pikaresepeun naon anu dipendakan ku insinyur Tinder sareng hasil naon anu aranjeunna sumping? Baca tarjamahan ieu.
Kunaon?
Ampir dua taun ka tukang, Tinder mutuskeun pikeun mindahkeun platformna ka Kubernetes. Kubernetes bakal ngidinan tim Tinder pikeun wadahna sarta pindah ka produksi kalawan usaha minimal ngaliwatan deployment immutable (penyebaran teu bisa dirobah). Dina hal ieu, rakitan aplikasi, panyebaranana, sareng infrastrukturna sorangan bakal didefinisikeun sacara unik ku kode.
Kami ogé milarian solusi pikeun masalah skalabilitas sareng stabilitas. Nalika skala janten kritis, urang sering kedah ngantosan sababaraha menit kanggo instansi EC2 anyar pikeun spin up. Gagasan pikeun ngaluncurkeun wadah sareng ngamimitian ngalayanan lalu lintas dina sababaraha detik tibatan menit janten pikaresepeun pisan pikeun kami.
Prosésna tétéla hésé. Salami migrasi urang di awal 2019, klaster Kubernetes ngahontal massa kritis sareng urang mimiti ngalaman sagala rupa masalah kusabab volume lalu lintas, ukuran klaster, sareng DNS. Sapanjang jalan, kami ngarengsekeun seueur masalah anu pikaresepeun anu aya hubunganana sareng migrasi 200 jasa sareng ngajaga kluster Kubernetes anu diwangun ku 1000 titik, 15000 pod sareng 48000 wadah jalan.
Kumaha?
Kusabab Januari 2018, urang parantos ngalangkungan sababaraha tahapan migrasi. Kami ngamimitian ku wadahna sadaya jasa kami sareng nyebarkeunana kana lingkungan uji awan Kubernetes. Dimimitian dina Oktober, urang mimiti methodically migrasi sadaya jasa aya ka Kubernetes. Ku Maret taun saterusna, urang réngsé migrasi tur ayeuna platform Tinder ngajalankeun éksklusif on Kubernetes.
Ngawangun gambar pikeun Kubernetes
Kami ngagaduhan langkung ti 30 repositori kode sumber pikeun layanan mikro anu dijalankeun dina klaster Kubernetes. Kodeu dina repositori ieu ditulis dina basa anu béda (contona, Node.js, Java, Scala, Go) sareng sababaraha lingkungan runtime pikeun basa anu sami.
Sistem ngawangun dirancang pikeun nyadiakeun "konteks ngawangun" pinuh customizable pikeun tiap microservice. Biasana diwangun ku Dockerfile sareng daptar paréntah cangkang. Eusina lengkep tiasa disaluyukeun, sareng dina waktos anu sami, sadaya kontéks ngawangun ieu ditulis dumasar kana format standar. Standarisasi kontéks ngawangun ngamungkinkeun hiji sistem ngawangun tunggal pikeun nanganan sadaya jasa mikro.
Gambar 1-1. Prosés ngawangun standar via wadahna Pangwangun
Pikeun ngahontal konsistensi maksimum antara runtimes (lingkungan runtime) prosés ngawangun sarua dipaké nalika ngembangkeun sarta nguji. Kami nyanghareupan tantangan anu pikaresepeun pisan: urang kedah ngembangkeun cara pikeun mastikeun konsistensi lingkungan ngawangun di sakumna platform. Pikeun ngahontal ieu, sadaya prosés perakitan dilaksanakeun di jero wadah khusus. nu ngawangun.
palaksanaan wadahna merlukeun téhnik Docker canggih. Pangwangun inherits ID pamaké lokal jeung Rahasia (saperti konci SSH, Kapercayaan AWS, jsb) diperlukeun pikeun ngakses repositories Tinder swasta. Éta dipasang diréktori lokal anu ngandung sumber pikeun nyimpen artefak ngawangun sacara alami. Pendekatan ieu ningkatkeun kinerja sabab ngaleungitkeun kabutuhan pikeun nyalin artefak ngawangun antara wadah Pangwangun sareng host. Artefak ngawangun disimpen tiasa dianggo deui tanpa konfigurasi tambahan.
Kanggo sababaraha jasa, urang kedah nyiptakeun wadah anu sanés pikeun peta lingkungan kompilasi kana lingkungan runtime (contona, perpustakaan bcrypt Node.js ngahasilkeun artefak binér khusus platform nalika instalasi). Salila prosés kompilasi, syarat bisa rupa-rupa antara jasa, sarta Dockerfile final disusun dina laleur nu.
Kubernetes arsitéktur klaster jeung migrasi
Manajemén ukuran klaster
Urang mutuskeun pikeun ngagunakeun kube-aws pikeun deployment klaster otomatis dina instansi Amazon EC2. Dina awalna, sagalana digawé di hiji kolam renang umum titik. Kami gancang sadar kabutuhan pikeun misahkeun beban kerja ku ukuran sareng jinis conto pikeun ngagunakeun sumber daya anu langkung éfisién. Logika éta ngajalankeun sababaraha pods multi-threaded dimuat tétéla leuwih bisa diprediksi dina hal kinerja ti coexistence maranéhanana jeung sajumlah badag pods single-threaded.
Tungtungna urang netepkeun:
- m5.4x badag - pikeun ngawaskeun (Prometheus);
- c5.4x badag - pikeun beban kerja Node.js (beban kerja benang tunggal);
- c5.2x badag - pikeun Java sareng Go (beban kerja multithreaded);
- c5.4x badag - pikeun panel kontrol (3 titik).
Migrasi
Salah sahiji léngkah préparasi pikeun migrasi ti infrastruktur heubeul ka Kubernetes nya éta alihan komunikasi langsung nu aya antara jasa ka balancers beban anyar (Elastic Load Balancers (ELB). Éta dijieun dina subnet husus tina awan pribadi virtual (VPC). Subnet ieu disambungkeun ka VPC Kubernetes. Hal ieu ngamungkinkeun urang migrasi modul laun, tanpa merhatikeun urutan husus tina dependensi jasa.
Titiktungtung ieu didamel nganggo sét catetan DNS anu ditimbang anu ngagaduhan CNAME nunjuk ka unggal ELB énggal. Pikeun ngalih, kami nambihan éntri énggal anu nunjuk ka ELB énggal tina jasa Kubernetes kalayan beurat 0. Urang teras nyetél Time To Live (TTL) tina éntri disetel ka 0. Saatos ieu, beurat anu lami sareng énggal janten lalaunan disaluyukeun, sarta ahirna 100% beban ieu dikirim ka server anyar. Saatos switching réngsé, nilai TTL balik ka tingkat nu leuwih nyukupan.
Modul Java anu kami kagungan tiasa ngatasi DNS TTL anu rendah, tapi aplikasi Node henteu tiasa. Salah sahiji insinyur rewrote bagian tina kode kolam renang sambungan na dibungkus dina manajer anu diropéa pools unggal 60 detik. Pendekatan anu dipilih damel saé pisan sareng tanpa degradasi kinerja anu nyata.
Éta palajaran
Watesan Kain Jaringan
Dina isuk awal 8 Januari 2019, platform Tinder teu disangka-sangka nabrak. Salaku tanggepan kana paningkatan anu teu aya hubunganana dina latensi platform tadi isuk-isuk, jumlah polong sareng titik dina kluster ningkat. Ieu nyababkeun cache ARP béak dina sadaya titik kami.
Aya tilu pilihan Linux anu aya hubunganana sareng cache ARP:
()
gc_thresh3 - ieu wates teuas. Penampilan éntri "tatangga ngabahekeun" dina log hartina sanajan sanggeus kempelan sampah sinkron (GC), aya teu cukup spasi dina cache ARP pikeun nyimpen entri tatangga. Dina hal ieu, kernel ngan saukur dipiceun pakét lengkep.
Kami nganggo salaku lawon jaringan di Kubernetes. Pakét dikirimkeun ngaliwatan VXLAN. VXLAN mangrupakeun torowongan L2 diangkat dina luhureun hiji jaringan L3. Téknologi ngagunakeun MAC-in-UDP (MAC Address-in-User Datagram Protocol) enkapsulasi sareng ngamungkinkeun ékspansi bagéan jaringan Lapisan 2. Protokol angkutan dina jaringan pusat data fisik nyaéta IP plus UDP.
Gambar 2–1. diagram flanel ()
Gambar 2-2. Paket VXLAN ()
Unggal titik worker Kubernetes allocates spasi alamat maya jeung /24 topeng tina blok /9 nu leuwih gede. Pikeun unggal titik ieu hiji éntri dina tabel routing, hiji éntri dina tabel ARP (dina panganteur flannel.1), sarta hiji éntri dina tabel switching (FDB). Éta ditambahkeun nalika mimiti titik worker dimimitian atawa unggal waktos titik anyar kapanggih.
Salaku tambahan, komunikasi node-pod (atanapi pod-pod) pamustunganana ngalangkungan antarmuka ét0 (sakumaha ditémbongkeun dina diagram Flannel luhur). Ieu ngakibatkeun entri tambahan dina tabel ARP pikeun tiap sumber saluyu jeung host tujuan.
Di lingkungan urang, jenis ieu komunikasi pisan umum. Pikeun objék layanan dina Kubernetes, ELB dijieun tur Kubernetes ngadaptar unggal titik jeung ELB. ELB henteu terang nanaon ngeunaan pods sareng titik anu dipilih tiasa janten tujuan akhir pakét. Intina nyaéta nalika titik hiji nampi pakét ti ELB, éta nganggap éta tumut kana aturan iptables pikeun layanan husus sarta acak milih pod on titik sejen.
Dina waktos gagalna, aya 605 titik dina kluster. Pikeun alesan anu didadarkeun di luhur, ieu cekap pikeun ngatasi pentingna gc_thresh3, nu mangrupakeun standar. Nalika ieu kajadian, teu ukur pakét ngawitan turun, tapi sakabeh spasi alamat maya Flannel kalawan / 24 mask ngaleungit tina tabel ARP. Komunikasi node-pod sareng patarosan DNS diganggu (DNS di-host dina kluster; baca engké dina tulisan ieu pikeun detil).
Pikeun ngajawab masalah ieu, anjeun kudu ningkatkeun nilai gc_thresh1, gc_thresh2 и gc_thresh3 sareng balikan deui Flannel pikeun ngadaptarkeun deui jaringan anu leungit.
Skala DNS anu teu kaduga
Salila prosés migrasi, kami aktip ngagunakeun DNS pikeun ngatur patalimarga jeung mindahkeun laun ladenan ti infrastruktur heubeul ka Kubernetes. Urang nyetel nilai TTL rélatif low pikeun RecordSets pakait dina Route53. Nalika infrastruktur heubeul dijalankeun dina instansi EC2, konfigurasi resolver kami nunjuk ka Amazon DNS. Kami nganggap hal ieu sareng dampak TTL anu rendah dina jasa kami sareng jasa Amazon (sapertos DynamoDB) henteu diémutan.
Nalika kami migrasi jasa ka Kubernetes, kami mendakan yén DNS ngolah 250 rébu pamundut per detik. Hasilna, aplikasi mimiti ngalaman timeout konstanta sarta serius pikeun queries DNS. Ieu kajantenan sanaos usaha anu luar biasa pikeun ngaoptimalkeun sareng ngalihkeun panyadia DNS ka CoreDNS (anu dina beban puncak ngahontal 1000 pods ngajalankeun on 120 cores).
Nalika nalungtik kamungkinan sabab sareng solusi anu sanés, kami mendakan , ngajéntrékeun kaayaan lomba mangaruhan kerangka panyaring pakét saringan net dina Linux. The timeouts kami observasi, gandeng ku counter ngaronjatna insert_gagal dina panganteur Flannel éta konsisten jeung papanggihan artikel.
Masalahna lumangsung dina tahap Tarjamahan Alamat Jaringan Sumber sareng Tujuan (SNAT sareng DNAT) sareng asupna salajengna kana tabél nyambungkeun. Salah sahiji workarounds anu dibahas sacara internal sareng disarankeun ku masarakat nyaéta pikeun mindahkeun DNS kana titik pagawé sorangan. Dina hal ieu:
- SNAT henteu diperlukeun sabab lalulintas tetep di jero titik. Teu perlu routed ngaliwatan interface nu ét0.
- DNAT henteu diperlukeun saprak IP tujuan lokal pikeun titik, sarta lain pod dipilih acak nurutkeun aturan iptables.
Urang mutuskeun pikeun lengket kalayan pendekatan ieu. CoreDNS dikaluarkeun salaku DaemonSet di Kubernetes sareng kami ngalaksanakeun server DNS titik lokal di ngabéréskeun.conf unggal pod ku netepkeun bandéra --cluster-dns paréntah cubelet . Solusi ieu tétéla mujarab pikeun timeouts DNS.
Tapi, urang masih ningali packet loss sareng paningkatan dina loket insert_gagal dina panganteur Flannel. Ieu dituluykeun sanggeus workaround ieu dilaksanakeun sabab kami bisa ngaleungitkeun SNAT jeung / atawa DNAT pikeun lalulintas DNS wungkul. Kaayaan balapan dilestarikan pikeun jinis lalu lintas anu sanés. Untungna, lolobana pakét urang téh TCP, sarta lamun masalah lumangsung aranjeunna saukur retransmitted. Kami masih nyobian milarian solusi anu cocog pikeun sadaya jinis lalu lintas.
Ngagunakeun Utusan pikeun Beban Balancing Leuwih alus
Nalika urang migrasi jasa backend ka Kubernetes, urang mimiti kakurangan tina beban anu henteu saimbang antara pods. Kami mendakan yén HTTP Keepalive nyababkeun sambungan ELB ngagantung dina polong siap munggaran unggal panyebaran anu digulung. Ku kituna, bulk lalulintas ngaliwatan perséntase leutik pods sadia. Solusi anu munggaran anu kami uji nyaéta netepkeun MaxSurge ka 100% dina panyebaran énggal pikeun skenario anu paling parah. Pangaruhna tétéla teu pati penting sareng henteu ngajangjikeun dina hal panyebaran anu langkung ageung.
Solusi anu sanésna kami dianggo nyaéta sacara artifisial ningkatkeun paménta sumberdaya pikeun jasa kritis. Dina hal ieu, pods disimpen caket dieu bakal boga leuwih rohangan pikeun maneuver dibandingkeun pods beurat lianna. Éta ogé moal tiasa dianggo dina jangka panjang sabab éta bakal janten runtah sumber. Sajaba ti éta, aplikasi Node urang éta single-threaded sarta, sasuai, ngan bisa ngagunakeun hiji inti. Hiji-hijina solusi nyata nyaéta ngagunakeun kasaimbangan beban anu langkung saé.
Kami geus lila hayang pinuh ngahargaan . Kaayaan ayeuna ngamungkinkeun urang nyebarkeun éta ku cara anu terbatas sareng kéngingkeun hasil anu langsung. Envoy nyaéta kinerja tinggi, open-source, lapisan-XNUMX proxy dirancang pikeun aplikasi SOA badag. Bisa nerapkeun téknik load balancing canggih, kaasup retries otomatis, breakers circuit, sarta watesan laju global. (Catetan. narjamahkeun.: Anjeun bisa maca leuwih lengkep tentang ieu dina ngeunaan Istio, anu dumasar kana Utusan.)
Urang datang nepi ka konfigurasi handap: boga sidecar Utusan pikeun tiap pod sarta jalur tunggal, tur sambungkeun klaster kana wadahna lokal via port. Pikeun ngaleutikan cascading poténsi sarta ngajaga radius hit leutik, kami dipaké hiji armada utusan hareup-proxy pods, hiji per Zona Kasadiaan (AZ) pikeun tiap jasa. Aranjeunna ngandelkeun mesin panemuan jasa anu sederhana anu ditulis ku salah sahiji insinyur kami anu ngan ukur ngabalikeun daptar pod di unggal AZ pikeun jasa anu dipasihkeun.
Service hareup-Envoys lajeng dipaké mékanisme kapanggihna jasa ieu kalawan hiji klaster hulu jeung jalur. Urang nyetel timeouts nyukupan, ngaronjat sadaya setelan circuit breaker, sarta ditambahkeun konfigurasi coba deui minimal pikeun pitulung kalayan gagal tunggal jeung mastikeun deployments lemes. Urang nempatkeun TCP ELB di hareup unggal jasa ieu hareup-Envoys. Sanaos keepalive tina lapisan proxy utama urang macét dina sababaraha pods Envoy, aranjeunna masih tiasa nahan beban anu langkung saé sareng dikonpigurasi pikeun saimbang ngaliwatan least_request di backend.
Pikeun panyebaran, kami nganggo hook preStop dina pod aplikasi sareng pods sidecar. Hook nu dipicu kasalahan dina mariksa status titik admin lokasina dina wadah sidecar sarta indit sare bari pikeun ngidinan sambungan aktip pikeun ngeureunkeun.
Salah sahiji alesan urang tiasa ngalih gancang-gancang nyaéta kusabab métrik anu lengkep anu urang tiasa gampang ngahijikeun kana pamasangan Prometheus anu khas. Ieu ngamungkinkeun urang pikeun ningali naon anu lumangsung nalika urang nyaluyukeun parameter konfigurasi sareng nyebarkeun lalu lintas.
Hasilna langsung sareng atra. Urang mimitian ku jasa paling henteu saimbang, sarta di momen eta ngoperasikeun di hareup 12 jasa pangpentingna dina kluster. Taun ieu kami ngarencanakeun transisi ka bolong layanan pinuh ku panemuan jasa anu langkung maju, putus sirkuit, deteksi outlier, ngawatesan laju sareng ngalacak.
Gambar 3–1. Konvergénsi CPU hiji layanan salila transisi ka Utusan
Hasil akhir
Ngaliwatan pangalaman ieu sareng panilitian tambahan, kami parantos ngawangun tim infrastruktur anu kuat sareng kaahlian anu kuat dina ngarancang, nyebarkeun, sareng ngoperasikeun klaster Kubernetes anu ageung. Sadaya insinyur Tinder ayeuna gaduh pangaweruh sareng pangalaman pikeun ngarangkep wadah sareng nyebarkeun aplikasi ka Kubernetes.
Nalika kabutuhan kapasitas tambahan timbul dina infrastruktur anu lami, urang kedah ngantosan sababaraha menit kanggo instansi EC2 anyar diluncurkeun. Ayeuna wadahna mimiti jalan sareng ngamimitian ngolah lalu lintas dina sababaraha detik tibatan menit. Ngajadwalkeun sababaraha wadah dina hiji conto EC2 ogé nyayogikeun konsentrasi horisontal anu ningkat. Hasilna, kami ngaramalkeun pangurangan anu signifikan dina biaya EC2019 dina 2 dibandingkeun taun ka tukang.
Migrasi nyandak ampir dua taun, tapi urang réngsé dina Maret 2019. Ayeuna, platform Tinder dijalankeun sacara éksklusif dina kluster Kubernetes anu diwangun ku 200 jasa, 1000 titik, 15 pod sareng 000 wadah jalan. Infrastruktur henteu deui hiji-hijina domain tim operasi. Sadaya insinyur urang ngabagi tanggung jawab ieu sareng ngontrol prosés ngawangun sareng nyebarkeun aplikasina nganggo kode wungkul.
PS ti penerjemah
Baca ogé runtuyan artikel dina blog urang:
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
sumber: www.habr.com