🥇 Load balancing lan scaling sambungan umur dawa ing Kubernetes

Artikel iki bakal mbantu sampeyan ngerti carane ngimbangi beban ing Kubernetes, apa sing kedadeyan nalika nggedhekake sambungan sing umure suwe, lan kenapa sampeyan kudu nimbang keseimbangan sisih klien yen sampeyan nggunakake HTTP/2, gRPC, RSockets, AMQP, utawa protokol umur dawa liyane. .

A sethitik babagan carane lalu lintas disebarake ing Kubernetes

Kubernetes nyedhiyakake rong abstraksi sing trep kanggo nyebarake aplikasi: Layanan lan Penyebaran.

Deployments njlèntrèhaké carane lan pira salinan aplikasi sampeyan kudu mlaku ing sembarang wektu tartamtu. Saben aplikasi disebarake minangka Pod lan diwenehi alamat IP.

Layanan padha ing fungsi kanggo load balancer. Dheweke dirancang kanggo nyebarake lalu lintas ing pirang-pirang pod.

Ayo ndeleng kaya apa.

Ing diagram ing ngisor iki sampeyan bisa ndeleng telung conto aplikasi sing padha lan imbangan beban:
Penyeimbang beban diarani Layanan lan diwenehi alamat IP. Sembarang panjaluk sing mlebu dialihake menyang salah sawijining pod:
Skenario penyebaran nemtokake jumlah kedadean saka aplikasi. Sampeyan meh ora kudu nggedhekake langsung ing:
Saben pod diwenehi alamat IP dhewe:

Iku migunani kanggo mikir layanan minangka kumpulan alamat IP. Saben sampeyan ngakses layanan kasebut, salah sawijining alamat IP dipilih saka dhaptar lan digunakake minangka alamat tujuan.

Iku katon kaya iki.

Panjaluk curl 10.96.45.152 ditampa menyang layanan:
Layanan milih salah siji saka telung alamat pod minangka tujuan:
Lalu lintas dialihake menyang pod tartamtu:

Yen aplikasi sampeyan kalebu frontend lan backend, sampeyan bakal duwe layanan lan penyebaran kanggo saben.

Nalika frontend nggawe panjalukan menyang backend, ora perlu ngerti persis jumlah pod sing dilayani: bisa uga ana siji, sepuluh, utawa satus.

Uga, frontend ora ngerti apa-apa babagan alamat pods sing nyedhiyakake backend.

Nalika frontend nggawe panjalukan menyang backend, nggunakake alamat IP layanan backend, sing ora owah.

Iki rupane.

Ing 1 njaluk komponen backend internal. Tinimbang milih sing spesifik kanggo backend, nggawe panjalukan kanggo layanan kasebut:
Layanan milih salah siji saka polong mburi minangka alamat tujuan:
Lalu lintas dadi saka Pod 1 nganti Pod 5, dipilih dening layanan:
Ing 1 ora ngerti persis pira pod kaya ing ngisor 5 sing didhelikake ing mburi layanan:

Nanging kepiye carane layanan nyebarake panjaluk? Iku misale jek kaya round-robin balancing digunakake? Ayo dadi tokoh metu.

Balancing ing layanan Kubernetes

Layanan Kubernetes ora ana. Ora ana proses kanggo layanan sing diwenehi alamat IP lan port.

Sampeyan bisa verifikasi iki kanthi mlebu menyang simpul apa wae ing kluster lan nglakokake perintah netstat -ntlp.

Sampeyan ora bakal bisa nemokake alamat IP sing diwenehake kanggo layanan kasebut.

Alamat IP layanan dumunung ing lapisan kontrol, ing controller, lan direkam ing database - etcd. Alamat sing padha digunakake dening komponen liyane - kube-proxy.
Kube-proxy nampa dhaptar alamat IP kanggo kabeh layanan lan ngasilake set aturan iptables ing saben simpul ing kluster.

Aturan kasebut ujar: "Yen kita ndeleng alamat IP layanan kasebut, kita kudu ngowahi alamat tujuan panjaluk kasebut lan ngirim menyang salah sawijining pods."

Alamat IP layanan mung digunakake minangka titik entri lan ora dilayani dening proses apa wae sing ngrungokake alamat IP lan port kasebut.

Ayo ndeleng iki.

Coba klompok telung simpul. Saben simpul duwe polong:
Pods diikat dicet beige minangka bagean saka layanan kasebut. Amarga layanan kasebut ora ana minangka proses, ditampilake kanthi warna abu-abu:
Pod pisanan njaluk layanan lan kudu pindhah menyang salah siji pod sing gegandhengan:
Nanging layanan ora ana, proses ora ana. Piye cara kerjane?
Sadurunge panyuwunan ninggalake simpul kasebut, bakal ngliwati aturan iptables:
Aturan iptables ngerti manawa layanan kasebut ora ana lan ngganti alamat IP karo salah sawijining alamat IP pods sing ana gandhengane karo layanan kasebut:
Panyuwunan nampa alamat IP sing bener minangka alamat tujuan lan diproses kanthi normal:
Gumantung ing topologi jaringan, panjalukan pungkasane tekan pod:

Apa iptables bisa mbukak imbangan?

Ora, iptables digunakake kanggo nyaring lan ora dirancang kanggo imbangan.

Nanging, iku bisa kanggo nulis pesawat saka aturan sing bisa kaya pseudo-balancer.

Lan iki persis sing ditindakake ing Kubernetes.

Yen sampeyan duwe telung pods, kube-proxy bakal nulis aturan ing ngisor iki:

Pilih sub pisanan kanthi kemungkinan 33%, yen ora, pindhah menyang aturan sabanjure.
Pilih sing kapindho kanthi kemungkinan 50%, yen ora, pindhah menyang aturan sabanjure.
Pilih katelu ing ngisor.

Sistem iki nyebabake saben pod dipilih kanthi kemungkinan 33%.

Lan ora ana jaminan yen Pod 2 bakal dipilih sabanjure sawise Pod 1.

komentar: iptables nggunakake modul statistik karo distribusi acak. Mangkono, algoritma balancing adhedhasar pilihan acak.

Saiki sampeyan ngerti cara kerja layanan, ayo ndeleng skenario layanan sing luwih menarik.

Sambungan dawa ing Kubernetes ora ukuran standar

Saben panjalukan HTTP saka frontend menyang backend diwenehake dening sambungan TCP sing kapisah, sing dibukak lan ditutup.

Yen frontend ngirim 100 panjalukan saben detik menyang backend, banjur 100 sambungan TCP beda dibukak lan ditutup.

Sampeyan bisa nyuda wektu pangolahan panjalukan lan mbukak kanthi mbukak siji sambungan TCP lan nggunakake kanggo kabeh panjalukan HTTP sakteruse.

Protokol HTTP nduweni fitur sing diarani HTTP keep-alive, utawa sambungan maneh. Ing kasus iki, sambungan TCP siji digunakake kanggo ngirim lan nampa sawetara panjalukan lan respon HTTP:

Fitur iki ora diaktifake kanthi gawan: server lan klien kudu dikonfigurasi.

Persiyapan kasebut prasaja lan bisa diakses kanggo umume basa lan lingkungan pemrograman.

Ing ngisor iki sawetara pranala menyang conto ing macem-macem basa:

Apa sing kedadeyan yen kita nggunakake keep-alive ing layanan Kubernetes?
Ayo nganggep manawa frontend lan backend ndhukung tetep urip.

Kita duwe siji salinan frontend lan telung salinan backend. Frontend nggawe panjalukan pisanan lan mbukak sambungan TCP menyang backend. Panjaluk kasebut tekan layanan kasebut, salah sawijining polong mburi dipilih minangka alamat tujuan. Backend ngirim respon, lan frontend nampa.

Ora kaya kahanan biasa sing sambungan TCP ditutup sawise nampa respon, saiki tetep mbukak kanggo panjalukan HTTP luwih lanjut.

Apa sing kedadeyan yen frontend ngirim panjalukan liyane menyang backend?

Kanggo nerusake panjalukan kasebut, sambungan TCP sing mbukak bakal digunakake, kabeh panjalukan bakal pindhah menyang backend sing padha ing ngendi panjalukan pisanan.

Apa ora iptables ngirimake lalu lintas?

Ora ing kasus iki.

Nalika sambungan TCP digawe, iku liwat aturan iptables, kang milih backend tartamtu ngendi lalu lintas bakal pindhah.

Wiwit kabeh panjalukan sakteruse ana ing sambungan TCP sing wis mbukak, aturan iptables ora diarani maneh.

Ayo ndeleng kaya apa.

Pod pisanan ngirim panjalukan menyang layanan:
Sampeyan wis ngerti apa sing bakal kelakon sabanjure. Layanan kasebut ora ana, nanging ana aturan iptables sing bakal ngolah panjaluk kasebut:
Salah siji polong mburi bakal dipilih minangka alamat tujuan:
Panyuwunan tekan polong. Ing titik iki, sambungan TCP sing terus-terusan ing antarane rong pod bakal diadegake:
Sembarang panjalukan sakteruse saka pod pisanan bakal liwat sambungan sing wis ditetepake:

Asil wektu nanggepi luwih cepet lan throughput sing luwih dhuwur, nanging sampeyan bakal kelangan kemampuan kanggo skala backend.

Malah yen sampeyan duwe rong pods ing backend, karo sambungan pancet, lalu lintas bakal tansah pindhah menyang salah siji saka.

Apa iki bisa diatasi?

Amarga Kubernetes ora ngerti carane ngimbangi sambungan sing terus-terusan, tugas iki dadi sampeyan.

Layanan minangka kumpulan alamat IP lan port sing disebut titik pungkasan.

Aplikasi sampeyan bisa entuk dhaptar titik pungkasan saka layanan kasebut lan mutusake cara nyebarake panjalukan ing antarane. Sampeyan bisa mbukak sambungan terus-terusan kanggo saben pod lan panjalukan imbangan antarane sambungan iki nggunakake round-robin.

Utawa aplikasi liyane algoritma imbangan Komplek.

Kode sisih klien sing tanggung jawab kanggo imbangan kudu ngetutake logika iki:

Entuk dhaptar titik pungkasan saka layanan kasebut.
Bukak sambungan sing terus-terusan kanggo saben titik pungkasan.
Yen panjaluk kudu digawe, gunakake salah sawijining sambungan sing mbukak.
Nganyari dhaptar endpoint kanthi rutin, gawe anyar utawa nutup sambungan terus-terusan lawas yen dhaptar ganti.

Iki bakal katon kaya.

Tinimbang pod pisanan ngirim panjalukan menyang layanan, sampeyan bisa ngimbangi panjalukan ing sisih klien:
Sampeyan kudu nulis kode sing takon polong sing dadi bagean saka layanan:
Sawise sampeyan duwe dhaptar, simpen ing sisih klien lan gunakake kanggo nyambung menyang pods:
Sampeyan tanggung jawab kanggo algoritma imbangan beban:

Saiki pitakonan muncul: apa masalah iki mung ditrapake kanggo HTTP tetep-urip?

Load balancing sisih klien

HTTP ora mung protokol sing bisa nggunakake sambungan TCP persisten.

Yen aplikasi sampeyan nggunakake database, sambungan TCP ora dibukak saben sampeyan kudu njaluk utawa njupuk dokumen saka database.

Nanging, sambungan TCP sing terus-terusan menyang database dibukak lan digunakake.

Yen database sampeyan disebarake ing Kubernetes lan akses diwenehake minangka layanan, sampeyan bakal nemoni masalah sing padha sing diterangake ing bagean sadurunge.

Siji replika database bakal luwih dimuat tinimbang liyane. Kube-proxy lan Kubernetes ora bakal mbantu ngimbangi sambungan. Sampeyan kudu ati-ati kanggo ngimbangi pitakon menyang database sampeyan.

Gumantung ing perpustakaan sing sampeyan gunakake kanggo nyambung menyang database, sampeyan bisa uga duwe opsi beda kanggo ngatasi masalah iki.

Ing ngisor iki conto ngakses kluster database MySQL saka Node.js:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

Ana akeh protokol liyane sing nggunakake sambungan TCP persisten:

WebSockets lan WebSockets aman
HTTP / 2
gRPC
RSockets
AMQP

Sampeyan kudune wis kenal karo sebagian besar protokol kasebut.

Nanging yen protokol iki populer banget, kenapa ora ana solusi keseimbangan standar? Napa logika klien kudu diganti? Apa ana solusi Kubernetes asli?

Kube-proxy lan iptables dirancang kanggo nutupi kasus panggunaan sing paling umum nalika nyebarake menyang Kubernetes. Iki kanggo penak.

Yen sampeyan nggunakake layanan web sing mbukak API REST, sampeyan bakal begja - ing kasus iki, sambungan TCP sing terus-terusan ora digunakake, sampeyan bisa nggunakake layanan Kubernetes.

Nanging yen sampeyan miwiti nggunakake sambungan TCP sing terus-terusan, sampeyan kudu ngerti carane nyebarake beban kanthi rata ing sisih mburi. Kubernetes ora ngemot solusi sing wis siap kanggo kasus iki.

Nanging, mesthi ana pilihan sing bisa mbantu.

Ngimbangi sambungan dawa ing Kubernetes

Ana papat jinis layanan ing Kubernetes:

KlusterIP
NodePort
LoadBalancer
Sira Kepala

Telu layanan pisanan beroperasi adhedhasar alamat IP virtual, sing digunakake dening kube-proxy kanggo mbangun aturan iptables. Nanging dhasar dhasar kabeh layanan yaiku layanan tanpa kepala.

Layanan tanpa sirah ora duwe alamat IP sing ana gandhengane lan mung menehi mekanisme kanggo njupuk dhaptar alamat IP lan port pods (titik pungkasan) sing ana gandhengane.

Kabeh layanan adhedhasar layanan tanpa sirah.

Layanan ClusterIP minangka layanan tanpa kepala kanthi sawetara tambahan:

Lapisan manajemen menehi alamat IP.
Kube-proxy ngasilake aturan iptables sing dibutuhake.

Kanthi cara iki sampeyan bisa nglirwakake kube-proxy lan langsung nggunakake dhaptar titik pungkasan sing dipikolehi saka layanan tanpa sirah kanggo mbukak imbangan aplikasi sampeyan.

Nanging kepiye carane bisa nambah logika sing padha karo kabeh aplikasi sing dipasang ing kluster?

Yen aplikasi sampeyan wis disebarake, tugas iki bisa uga ora mungkin. Nanging, ana pilihan alternatif.

Service Mesh bakal mbantu sampeyan

Sampeyan bisa uga wis ngerteni manawa strategi keseimbangan beban sisih klien cukup standar.

Nalika aplikasi diwiwiti, iku:

Entuk dhaptar alamat IP saka layanan kasebut.
Mbukak lan njaga blumbang sambungan.
Nganyari blumbang kanthi periodik kanthi nambah utawa mbusak titik pungkasan.

Sawise aplikasi pengin nggawe panjalukan, iku:

Milih sambungan sing kasedhiya nggunakake sawetara logika (contone round-robin).
Nglakokaké panjalukan.

Langkah-langkah iki bisa digunakake kanggo sambungan WebSockets, gRPC, lan AMQP.

Sampeyan bisa misahake logika iki dadi perpustakaan sing kapisah lan digunakake ing aplikasi sampeyan.

Nanging, sampeyan bisa nggunakake jejaring layanan kaya Istio utawa Linkerd.

Service Mesh nambah aplikasi sampeyan kanthi proses sing:

Telusuri alamat IP layanan kanthi otomatis.
Tes sambungan kayata WebSockets lan gRPC.
Ngimbangi panjalukan nggunakake protokol sing bener.

Service Mesh mbantu ngatur lalu lintas ing kluster, nanging cukup intensif sumber daya. Pilihan liyane nggunakake perpustakaan pihak katelu kaya Netflix Ribbon utawa proksi sing bisa diprogram kaya Utusan.

Apa sing kedadeyan yen sampeyan nglirwakake masalah keseimbangan?

Sampeyan bisa milih ora nggunakake load balancing lan isih ora weruh owah-owahan. Ayo ndeleng sawetara skenario kerja.

Yen sampeyan duwe klien luwih akeh tinimbang server, iki ora dadi masalah gedhe.

Contone, ana limang klien sing nyambung menyang rong server. Sanajan ora ana imbangan, loro server bakal digunakake:

Sambungan bisa uga ora roto-roto mbagekke: mbok menawa papat klien disambungake menyang server padha, nanging ana kasempatan apik sing loro server bakal digunakake.

Sing luwih masalah yaiku skenario sing ngelawan.

Yen sampeyan duwe luwih sithik klien lan luwih akeh server, sumber daya sampeyan bisa uga ora dimanfaatake lan potensial bottleneck bakal katon.

Contone, ana loro klien lan limang server. Ing kasus sing paling apik, bakal ana rong sambungan permanen menyang rong server saka limang.

Server sing isih ana bakal nganggur:

Yen loro server iki ora bisa nangani panjalukan klien, skala horisontal ora bakal mbantu.

kesimpulan

Layanan Kubernetes dirancang kanggo bisa digunakake ing umume skenario aplikasi web standar.

Nanging, yen sampeyan miwiti nggarap protokol aplikasi sing nggunakake sambungan TCP persisten, kayata database, gRPC utawa WebSockets, layanan ora cocok maneh. Kubernetes ora nyedhiyakake mekanisme internal kanggo ngimbangi sambungan TCP sing terus-terusan.

Iki tegese sampeyan kudu nulis aplikasi kanthi ngimbangi sisih klien.

Terjemahan disiapake dening tim Kubernetes aaS saka Mail.ru.

Apa maneh kanggo maca babagan topik kasebut:

Source: www.habr.com

Load balancing lan scaling sambungan dawa ing Kubernetes