Cathetan. nerjemahake.: Karyawan layanan Tinder sing misuwur ing donya bubar nuduhake sawetara rincian teknis babagan migrasi infrastruktur menyang Kubernetes. Proses kasebut meh rong taun lan nyebabake peluncuran platform skala gedhe banget ing K8s, kalebu 200 layanan sing dianakake ing 48 ewu kontainer. Apa kangelan menarik sing ditemoni para insinyur Tinder lan apa asile? Waca terjemahan iki.
Kenapa?
Meh rong taun kepungkur, Tinder mutusake kanggo mindhah platform menyang Kubernetes. Kubernetes bakal ngidini tim Tinder nggawe wadhah lan pindhah menyang produksi kanthi usaha minimal liwat panyebaran sing ora bisa diganti. (penyebaran ora owah). Ing kasus iki, perakitan aplikasi, panyebaran, lan infrastruktur dhewe bakal ditetepake kanthi kode kanthi unik.
Kita uga nggoleki solusi kanggo masalah skalabilitas lan stabilitas. Nalika skala dadi kritis, kita kerep kudu ngenteni sawetara menit kanggo kedadean EC2 anyar kanggo muter munggah. Gagasan ngluncurake kontaner lan miwiti ngladeni lalu lintas sajrone sawetara detik tinimbang menit dadi menarik banget kanggo kita.
Proses kasebut dadi angel. Sajrone migrasi ing awal 2019, kluster Kubernetes tekan massa kritis lan kita wiwit nemoni macem-macem masalah amarga volume lalu lintas, ukuran kluster, lan DNS. Sadawane dalan, kita ngrampungake akeh masalah menarik sing ana gandhengane karo migrasi 200 layanan lan njaga kluster Kubernetes sing dumadi saka 1000 simpul, 15000 pod lan 48000 kontaner sing mlaku.
Carane?
Wiwit Januari 2018, kita wis ngliwati macem-macem tahapan migrasi. Kita miwiti kanthi ngemot kabeh layanan lan nyebarake menyang lingkungan maya uji Kubernetes. Wiwit wulan Oktober, kita wiwit migrasi kabeh layanan sing ana menyang Kubernetes kanthi cara. Ing wulan Maret taun sabanjuré, kita wis rampung migrasi lan saiki platform Tinder mlaku sacara eksklusif ing Kubernetes.
Nggawe gambar kanggo Kubernetes
Kita duwe luwih saka 30 repositori kode sumber kanggo layanan mikro sing mlaku ing kluster Kubernetes. Kode ing repositori kasebut ditulis ing macem-macem basa (contone, Node.js, Java, Scala, Go) kanthi macem-macem lingkungan runtime kanggo basa sing padha.
Sistem mbangun dirancang kanggo nyedhiyakake "konteks mbangun" sing bisa disesuaikan kanggo saben layanan mikro. Biasane kasusun saka Dockerfile lan dhaptar perintah cangkang. Isine bisa disesuaikan, lan ing wektu sing padha, kabeh konteks mbangun iki ditulis miturut format standar. Konteks mbangun standar ngidini siji sistem mbangun kanggo nangani kabeh layanan mikro.
Gambar 1-1. Proses mbangun standar liwat wadhah Builder
Kanggo entuk konsistensi maksimum antarane runtimes (lingkungan runtime) proses mbangun padha digunakake sak pembangunan lan testing. Kita ngadhepi tantangan sing menarik banget: kita kudu nggawe cara kanggo njamin konsistensi lingkungan mbangun ing kabeh platform. Kanggo nindakake iki, kabeh proses perakitan ditindakake ing wadhah khusus. Gedung.
Implementasi wadhah kasebut mbutuhake teknik Docker majeng. Pembangun marisi ID pangguna lan rahasia lokal (kayata kunci SSH, kredensial AWS, lan sapiturute) sing dibutuhake kanggo ngakses repositori Tinder pribadi. Iki masang direktori lokal sing ngemot sumber kanggo nyimpen artefak bangunan kanthi alami. Pendekatan iki nambah kinerja amarga ngilangake perlu kanggo nyalin artefak mbangun antarane wadhah Builder lan host. Artefak mbangun sing disimpen bisa digunakake maneh tanpa konfigurasi tambahan.
Kanggo sawetara layanan, kita kudu nggawe wadhah liyane kanggo peta lingkungan kompilasi menyang lingkungan runtime (contone, perpustakaan bcrypt Node.js ngasilake artefak binar khusus platform nalika instalasi). Sajrone proses kompilasi, syarat bisa beda-beda ing antarane layanan, lan Dockerfile pungkasan dikompilasi kanthi cepet.
arsitektur kluster Kubernetes lan migrasi
Manajemen ukuran cluster
Kita mutusake kanggo nggunakake kube-aws kanggo panyebaran cluster otomatis ing Amazon EC2 kedadean. Ing wiwitan, kabeh bisa digunakake ing siji simpul umum. Kita cepet nyadari kabutuhan kanggo misahake beban kerja miturut ukuran lan jinis conto kanggo nggunakake sumber daya sing luwih efisien. Logika kasebut yaiku ngluncurake sawetara pod multi-Utas sing dimuat dadi luwih bisa diprediksi babagan kinerja tinimbang urip bebarengan karo pods siji-threaded sing akeh.
Ing pungkasan kita mutusake:
- m5.4x gedhe - kanggo ngawasi (Prometheus);
- c5.4x gedhe - kanggo beban kerja Node.js (beban kerja benang tunggal);
- c5.2x gedhe - kanggo Java lan Go (beban karya multithreaded);
- c5.4x gedhe - kanggo panel kontrol (3 simpul).
Migrasi
Salah sawijining langkah persiapan kanggo migrasi saka infrastruktur lawas menyang Kubernetes yaiku ngarahake komunikasi langsung antarane layanan menyang penyeimbang beban anyar (Elastic Load Balancers (ELB). Padha digawe ing subnet tartamtu saka maya pribadi virtual (VPC). Subnet iki disambungake menyang VPC Kubernetes. Iki ngidini kita migrasi modul kanthi bertahap, tanpa nimbang urutan tartamtu saka dependensi layanan.
Titik pungkasan iki digawe nggunakake set bobot saka cathetan DNS sing duwe CNAMEs nuding saben ELB anyar. Kanggo ngalih, kita nambahake entri anyar sing nuding menyang ELB anyar saka layanan Kubernetes kanthi bobot 0. Kita banjur nyetel Time To Live (TTL) saka entri disetel dadi 0. Sawise iki, bobot lawas lan anyar padha. alon diatur, lan pungkasanipun 100% saka mbukak dikirim menyang server anyar. Sawise ngoper rampung, nilai TTL bali menyang tingkat sing luwih nyukupi.
Modul Java sing kita duwe bisa ngatasi DNS TTL sing kurang, nanging aplikasi Node ora bisa. Salah engineers rewrote bagean kode blumbang sambungan lan kebungkus ing manager sing nganyari pools saben 60 detik. Pendekatan sing dipilih makarya kanthi apik lan tanpa ana degradasi kinerja sing katon.
Pawulangan
Watesan Kain Jaringan
Ing wayah esuk tanggal 8 Januari 2019, platform Tinder tiba-tiba ambruk. Nanggepi kenaikan sing ora ana hubungane ing latensi platform ing esuk kasebut, jumlah polong lan simpul ing kluster saya tambah. Iki nyebabake cache ARP kesel ing kabeh simpul kita.
Ana telung opsi Linux sing ana gandhengane karo cache ARP:
()
gc_thresh3 - iki watesan hard. Munculé entri "tabungan kebanjiran" ing log temenan sing malah sawise koleksi sampah sinkron (GC), ana ora cukup papan ing cache ARP kanggo nyimpen entri tetanggan. Ing kasus iki, kernel mung mbuwang paket kasebut kanthi lengkap.
Kita nggunakake minangka kain jaringan ing Kubernetes. Paket dikirim liwat VXLAN. VXLAN minangka trowongan L2 sing diangkat ing ndhuwur jaringan L3. Teknologi kasebut nggunakake enkapsulasi MAC-in-UDP (MAC Address-in-User Datagram Protocol) lan ngidini ekspansi segmen jaringan Layer 2. Protokol transportasi ing jaringan pusat data fisik yaiku IP plus UDP.
Gambar 2–1. diagram flanel ()
Gambar 2-2. Paket VXLAN ()
Saben simpul buruh Kubernetes nyedhiyakake ruang alamat virtual kanthi topeng /24 saka blok /9 sing luwih gedhe. Kanggo saben simpul iki siji entri ing tabel nuntun, siji entri ing tabel ARP (ing antarmuka flannel.1), lan siji entri ing tabel ngoper (FDB). Iki ditambahake nalika pisanan simpul buruh diwiwiti utawa saben simpul anyar ditemokake.
Kajaba iku, komunikasi node-pod (utawa pod-pod) pungkasane liwat antarmuka eth0 (kaya sing ditampilake ing diagram Flanel ing ndhuwur). Iki nyebabake entri tambahan ing tabel ARP kanggo saben sumber lan host tujuan sing cocog.
Ing lingkungan kita, jinis komunikasi iki umum banget. Kanggo obyek layanan ing Kubernetes, ELB digawe lan Kubernetes ndhaptar saben simpul nganggo ELB. ELB ora ngerti apa-apa babagan polong lan simpul sing dipilih bisa uga ora dadi tujuan akhir paket kasebut. Intine yaiku nalika simpul nampa paket saka ELB, dheweke nganggep aturan kasebut iptables kanggo layanan tartamtu lan kanthi acak milih pod ing simpul liyane.
Ing wektu gagal, ana 605 simpul ing kluster. Kanggo alasan sing kasebut ing ndhuwur, iki cukup kanggo ngatasi pentinge gc_thresh3, kang minangka standar. Nalika iki kedaden, ora mung paket wiwit dropped, nanging kabeh papan alamat virtual Flannel karo topeng / 24 ilang saka meja ARP. Komunikasi node-pod lan pitakon DNS diganggu (DNS di-host ing kluster; waca mengko ing artikel iki kanggo rincian).
Kanggo ngatasi masalah iki, sampeyan kudu nambah nilai gc_thresh1, gc_thresh2 и gc_thresh3 lan miwiti maneh Flanel kanggo ndhaptar maneh jaringan sing ilang.
Skala DNS sing ora dikarepke
Sajrone proses migrasi, kita aktif nggunakake DNS kanggo ngatur lalu lintas lan mindhah layanan kanthi bertahap saka infrastruktur lawas menyang Kubernetes. Kita nyetel nilai TTL sing relatif kurang kanggo RecordSets sing ana gandhengane ing Route53. Nalika infrastruktur lawas mlaku ing conto EC2, konfigurasi solver kita nuding Amazon DNS. Kita njupuk iki kanggo diwenehake lan impact saka TTL kurang ing layanan kita lan layanan Amazon (kayata DynamoDB) dadi umumé unnoticed.
Nalika kita migrasi layanan menyang Kubernetes, kita nemokake yen DNS ngolah 250 ewu panjalukan saben detik. Akibaté, aplikasi wiwit ngalami wektu entek konstan lan serius kanggo pitakon DNS. Iki kedadeyan sanajan ana upaya sing luar biasa kanggo ngoptimalake lan ngalih panyedhiya DNS menyang CoreDNS (sing kanthi beban puncak tekan 1000 pod sing mlaku ing 120 intine).
Nalika nliti panyebab lan solusi liyane, kita nemokake , njlentrehke kahanan lomba sing mengaruhi framework nyaring paket saringan net ing Linux. Wektu entek sing diamati, ditambah karo counter sing nambah insert_failed ing antarmuka Flanel padha konsisten karo temonan saka artikel.
Masalah kasebut dumadi ing tataran Terjemahan Alamat Jaringan Sumber lan Tujuan (SNAT lan DNAT) lan entri sabanjure menyang tabel conntrack. Salah sawijining solusi sing dibahas sacara internal lan disaranake dening komunitas yaiku mindhah DNS menyang simpul pekerja dhewe. Ing kasus iki:
- SNAT ora dibutuhake amarga lalu lintas tetep ana ing simpul. Iku ora perlu kanggo routed liwat antarmuka eth0.
- DNAT ora dibutuhake amarga IP tujuan lokal menyang simpul, lan dudu polong sing dipilih kanthi acak miturut aturan iptables.
Kita mutusake kanggo tetep nganggo pendekatan iki. CoreDNS disebarake minangka DaemonSet ing Kubernetes lan kita ngetrapake server DNS simpul lokal ing mutusake masalah.conf saben pod kanthi nyetel gendera --cluster-dns printah kubelet . Solusi iki dadi efektif kanggo wektu entek DNS.
Nanging, kita isih weruh mundhut paket lan nambah ing counter insert_failed ing antarmuka Flanel. Iki terus sawise workaround dileksanakake amarga kita bisa ngilangi SNAT lan/utawa DNAT mung kanggo lalu lintas DNS. Kondisi balapan dijaga kanggo jinis lalu lintas liyane. Untunge, sebagian besar paket kita yaiku TCP, lan yen ana masalah, mung dikirim maneh. Kita isih nyoba golek solusi sing cocog kanggo kabeh jinis lalu lintas.
Nggunakake Utusan kanggo Load Balancing Luwih
Nalika migrasi layanan backend menyang Kubernetes, kita wiwit nandhang beban sing ora seimbang ing antarane polong. Kita nemokake manawa HTTP Keepalive nyebabake sambungan ELB digantung ing polong siap pisanan saben penyebaran sing diluncurake. Mangkono, akeh lalu lintas ngliwati persentase cilik saka polong sing kasedhiya. Solusi pisanan sing dites yaiku nyetel MaxSurge dadi 100% ing panyebaran anyar kanggo skenario paling ala. Efek kasebut dadi ora pati penting lan ora janji babagan penyebaran sing luwih gedhe.
Solusi liyane sing digunakake yaiku nambahake panjalukan sumber daya kanggo layanan kritis kanthi artifisial. Ing kasus iki, polong sing diselehake ing cedhak bakal duwe ruang luwih akeh kanggo maneuver dibandhingake polong abot liyane. Ora bakal bisa digunakake ing wektu sing suwe amarga bakal mbuwang sumber daya. Kajaba iku, aplikasi Node kita padha siji-Utas lan, miturut, mung bisa nggunakake siji inti. Siji-sijine solusi nyata yaiku nggunakake keseimbangan beban sing luwih apik.
Kita wis dawa wanted kanggo kebak appreciate . Kahanan saiki ngidini kita nyebarake kanthi cara sing winates lan entuk asil langsung. Utusan minangka proksi lapisan-XNUMX kanthi kinerja dhuwur, open-source, dirancang kanggo aplikasi SOA gedhe. Bisa ngleksanakake teknik imbangan beban sing luwih maju, kalebu nyoba maneh otomatis, pemutus sirkuit, lan watesan tarif global. (Cathetan. nerjemahake.: Sampeyan bisa maca liyane babagan iki ing babagan Istio, sing adhedhasar Utusan.)
We teka munggah karo konfigurasi ing ngisor iki: duwe sidecar Utusan kanggo saben pod lan rute siji, lan nyambung kluster kanggo wadhah lokal liwat port. Kanggo nyilikake cascading potensial lan njaga radius hit cilik, kita digunakake armada pods ngarep-proxy Envoy, siji saben kasedhiya Zone (AZ) kanggo saben layanan. Dheweke ngandelake mesin panemuan layanan sing prasaja sing ditulis dening salah sawijining insinyur sing mung ngasilake dhaptar pod ing saben AZ kanggo layanan sing diwenehake.
Utusan ngarep layanan banjur nggunakake mekanisme panemuan layanan iki kanthi siji kluster lan rute hulu. Kita nyetel wektu entek nyukupi, nambah kabeh setelan mbobol sirkuit, lan nambah konfigurasi nyoba maneh minimal kanggo bantuan karo gagal siji lan mesthekake penyebaran Gamelan. We diselehake TCP ELB ing ngarepe saben layanan iki front-Envoys. Sanajan keepalive saka lapisan proxy utama kita macet ing sawetara pods Envoy, dheweke isih bisa nangani beban sing luwih apik lan dikonfigurasi kanggo imbangan liwat least_request ing backend.
Kanggo penyebaran, kita nggunakake pancing preStop ing pod aplikasi lan pod sidecar. Pancing kasebut nyebabake kesalahan nalika mriksa status endpoint admin sing ana ing wadhah sidecar lan turu sedhela kanggo ngidini sambungan aktif mandheg.
Salah sawijining alasan sing bisa ditindakake kanthi cepet yaiku amarga metrik rinci sing bisa gampang digabungake menyang instalasi Prometheus sing khas. Iki ngidini kita ndeleng persis apa sing kedadeyan nalika nyetel paramèter konfigurasi lan mbagekake lalu lintas.
Asil padha langsung lan ketok. Kita miwiti karo layanan paling ora imbang, lan ing wayahe makaryakke ing ngarepe 12 layanan paling penting ing kluster. Taun iki kita ngrancang transisi menyang bolong layanan lengkap kanthi panemuan layanan sing luwih maju, pemutus sirkuit, deteksi outlier, watesan tarif lan pelacakan.
Gambar 3–1. Konvergensi CPU siji layanan sajrone transisi menyang Utusan
Asil pungkasan
Liwat pengalaman iki lan riset tambahan, kita wis mbangun tim infrastruktur sing kuwat kanthi katrampilan sing kuat kanggo ngrancang, nyebarake, lan ngoperasikake kluster Kubernetes sing gedhe. Kabeh insinyur Tinder saiki duwe kawruh lan pengalaman kanggo ngemas kontaner lan nyebarake aplikasi menyang Kubernetes.
Nalika mbutuhake kapasitas tambahan ing infrastruktur lawas, kita kudu ngenteni sawetara menit kanggo miwiti EC2 anyar. Saiki kontaner wiwit mlaku lan miwiti ngolah lalu lintas sajrone sawetara detik tinimbang menit. Njadwalake pirang-pirang kontaner ing siji conto EC2 uga nyedhiyakake konsentrasi horisontal sing luwih apik. Akibaté, kita ngira pangurangan signifikan ing biaya EC2019 ing 2 dibandhingake taun kepungkur.
Migrasi meh rong taun, nanging rampung ing Maret 2019. Saiki, platform Tinder mlaku sacara eksklusif ing kluster Kubernetes sing dumadi saka 200 layanan, 1000 simpul, 15 pod lan 000 kontaner sing mlaku. Infrastruktur ora dadi siji-sijine domain tim operasi. Kabeh insinyur kita nuduhake tanggung jawab iki lan ngontrol proses mbangun lan nyebarake aplikasi mung nggunakake kode.
PS saka penerjemah
Waca uga seri artikel ing blog kita:
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
Source: www.habr.com