Balancing beban sareng skala sambungan umur panjang di Kubernetes

Artikel ieu bakal nulungan anjeun ngartos kumaha load balancing jalan di Kubernetes, naon anu lumangsung nalika skala sambungan lila-hirup, sarta naha anjeun kudu mertimbangkeun kasaimbangan klien-sisi lamun make HTTP/2, gRPC, RSockets, AMQP, atawa protokol lila-hirup lianna. . 

Sakedik ngeunaan kumaha lalu lintas disebarkeun deui di Kubernetes 

Kubernetes nyadiakeun dua abstraksi merenah pikeun deploying aplikasi: Services jeung Deployments.

Deployments ngajelaskeun kumaha jeung sabaraha salinan aplikasi Anjeun kudu ngajalankeun iraha wae. Unggal aplikasi disebarkeun salaku Pod sareng ditugaskeun alamat IP.

Jasa anu fungsina sami sareng pangimbang beban. Éta dirancang pikeun ngadistribusikaeun lalu lintas kana sababaraha pod.

Hayu urang tingali kumaha éta.

1. Dina diagram di handap anjeun tiasa ningali tilu conto aplikasi anu sami sareng pangimbang beban:

   

2. The load balancer disebut Service sarta ditugaskeun alamat IP. Sakur pamundut anu asup dialihkeun ka salah sahiji pods:

   

3. Skenario panyebaran nangtukeun jumlah instansi aplikasi. Anjeun ampir henteu kedah ngalegaan langsung dina:

   

4. Unggal pod ditugaskeun alamat IP sorangan:

   

Mangpaat pikeun mikirkeun jasa salaku kumpulan alamat IP. Unggal waktos anjeun ngaksés jasa éta, salah sahiji alamat IP dipilih tina daptar sareng dianggo salaku alamat tujuan.

Sigana mah kieu.

1. Paménta curl 10.96.45.152 ditampi pikeun jasa:

   

2. Ladenan milih salah sahiji tina tilu alamat pod salaku tujuan:

   

3. Lalu lintas dialihkeun ka pod khusus:

   

Upami aplikasi anjeun diwangun ku frontend sareng backend, maka anjeun bakal gaduh jasa sareng panyebaran masing-masing.

Nalika frontend ngadamel pamundut ka backend, éta henteu kedah terang persis sabaraha pods anu dilayanan: tiasa aya hiji, sapuluh, atanapi saratus.

Ogé, frontend nu teu nyaho nanaon tentang alamat pods porsi backend nu.

Nalika frontend ngajadikeun pamundut ka backend nu, ngagunakeun alamat IP sahiji layanan backend, nu teu robah.

Ieu kumaha rupana.

1. Dina 1 requests komponén backend internal. Gantina milih anu khusus pikeun backend, éta ngadamel pamundut ka jasa:

   

2. Ladenan milih salah sahiji pod backend salaku alamat tujuan:

   

3. Lalu lintas angkat ti Pod 1 ka Pod 5, dipilih ku jasa:

   

4. Dina 1 teu terang persis sabaraha pods sapertos handapeun 5 anu disumputkeun tukangeun jasa:

   

Tapi kumaha persisna jasa ngadistribusikaeun pamundut? Sigana kawas round-robin balancing dipaké? Hayu urang angka eta kaluar. 

Balancing dina jasa Kubernetes

jasa Kubernetes teu aya. Henteu aya prosés pikeun jasa anu ditugaskeun alamat IP sareng port.

Anjeun tiasa pariksa ku cara asup kana titik mana waé dina kluster sareng ngajalankeun paréntah netstat -ntlp.

Anjeun malah moal tiasa mendakan alamat IP anu dialokasikeun pikeun jasa éta.

Alamat IP jasa aya dina lapisan kontrol, dina controller, sareng kacatet dina pangkalan data - jsb. Alamat anu sami dianggo ku komponén sanés - kube-proxy.
Kube-proxy nampi daptar alamat IP pikeun sadaya jasa sareng ngahasilkeun sakumpulan aturan iptables dina unggal titik dina kluster.

Aturan ieu nyarios: "Upami urang ningali alamat IP tina jasa, urang kedah ngarobih alamat tujuan pamundut sareng kirimkeun ka salah sahiji pods."

Alamat IP jasa ngan ukur dianggo salaku titik éntri sareng henteu dilayanan ku prosés naon waé anu ngadangukeun alamat IP sareng palabuhan éta.

Hayu urang nempo ieu. 

1. Mertimbangkeun gugusan tilu titik. Unggal titik boga pods:

   

2. Polong dihijikeun dicét beige mangrupikeun bagian tina jasa. Kusabab jasa éta henteu aya salaku prosés, éta ditingalikeun dina warna abu:

   

3. Pod munggaran nyuhunkeun jasa sareng kedah angkat ka salah sahiji pod anu aya hubunganana:

   

4. Tapi jasa henteu aya, prosésna henteu aya. Kumaha jalanna?

   

5. Sateuacan pamundut ninggalkeun titik, éta ngaliwatan aturan iptables:

   

6. Aturan iptables terang yén jasa éta henteu aya sareng ngagentos alamat IP na ku salah sahiji alamat IP tina pods anu aya hubunganana sareng jasa éta:

   

7. Paménta nampi alamat IP anu sah salaku alamat tujuan sareng diolah sacara normal:

   

8. Gumantung kana topologi jaringan, pamundut ahirna ngahontal pod:

   

Naha iptables tiasa ngamuat kasaimbangan?

Henteu, iptables dianggo pikeun nyaring sareng henteu dirancang pikeun kasaimbangan.

Sanajan kitu, kasebut nyaéta dimungkinkeun pikeun nulis susunan aturan anu dianggo kawas pseudo-balancer.

Sareng ieu persis anu dilaksanakeun di Kubernetes.

Upami anjeun gaduh tilu pods, kube-proxy bakal nyerat aturan ieu:

1. Pilih sub munggaran kalayan probabilitas 33%, upami henteu, angkat ka aturan salajengna.
2. Pilih anu kadua kalayan kamungkinan 50%, upami henteu, angkat ka aturan salajengna.
3. Pilih katilu di handap.

Sistem ieu nyababkeun unggal pod dipilih kalayan kamungkinan 33%.

Sareng teu aya jaminan yén Pod 2 bakal dipilih saatos Pod 1.

nyarios: iptables ngagunakeun modul statistik kalawan sebaran acak. Ku kituna, algoritma balancing dumasar kana pilihan acak.

Ayeuna anjeun ngartos kumaha jasa dianggo, hayu urang tingali skenario jasa anu langkung narik.

Koneksi lila-lila dina Kubernetes henteu skala sacara standar

Unggal pamundut HTTP ti frontend ka backend dilayanan ku sambungan TCP misah, nu dibuka jeung ditutup.

Lamun frontend ngirimkeun 100 requests per detik ka backend, lajeng 100 sambungan TCP béda dibuka jeung ditutup.

Anjeun tiasa ngirangan waktos ngolah pamundut sareng beban ku muka hiji sambungan TCP sareng nganggo éta pikeun sadaya pamundut HTTP anu salajengna.

Protokol HTTP ngagaduhan fitur anu disebut HTTP tetep-hirup, atanapi nganggo deui sambungan. Dina hal ieu, sambungan TCP tunggal digunakeun pikeun ngirim sareng nampa sababaraha pamundut sareng réspon HTTP:

Fitur ieu henteu diaktipkeun sacara standar: server sareng klien kedah dikonpigurasi sasuai.

Setélan éta saderhana sareng tiasa diaksés pikeun kalolobaan basa program sareng lingkungan.

Ieu sababaraha tumbu ka conto dina basa anu béda:

• Tetep-hirup di Node.js
• Tetep-hirup dina boot Spring
• Tetep-hirup di Python
• Tetep-hirup di .NET

Naon anu lumangsung lamun urang ngagunakeun keep-alive dina layanan Kubernetes?
Hayu urang nganggap yén frontend sareng backend ngadukung tetep-hirup.

Kami gaduh hiji salinan frontend sareng tilu salinan backend. Frontend ngajadikeun pamundut munggaran tur muka sambungan TCP ka backend nu. Paménta ngahontal jasa, salah sahiji pod backend dipilih salaku alamat tujuan. backend nu ngirimkeun respon, sarta frontend narima eta.

Beda sareng kaayaan biasa dimana sambungan TCP ditutup saatos nampi réspon, ayeuna tetep dibuka pikeun pamundut HTTP salajengna.

Naon kajadian lamun frontend nu ngirimkeun deui requests ka backend nu?

Pikeun neraskeun pamundut ieu, sambungan TCP anu kabuka bakal dianggo, sadaya pamundut bakal angkat ka tukang anu sami dimana pamundut anu munggaran angkat.

Naha iptables henteu kedah ngadistribusikaeun lalu lintas?

Henteu dina hal ieu.

Nalika sambungan TCP dijieun, éta ngaliwatan aturan iptables, nu milih backend husus dimana lalulintas bakal balik.

Kusabab sakabeh requests salajengna aya dina sambungan TCP geus kabuka, aturan iptables teu disebut deui.

Hayu urang tingali kumaha éta.

1. Pod kahiji ngirimkeun pamundut ka jasa:

   

2. Anjeun geus nyaho naon nu bakal kajadian salajengna. Ladenan éta henteu aya, tapi aya aturan iptables anu bakal ngolah pamundut:

   

3. Salah sahiji pod backend bakal dipilih salaku alamat tujuan:

   

4. Paménta ngahontal pod. Dina titik ieu, sambungan TCP pengkuh antara dua pods bakal diadegkeun:

   

5. Sakur pamundut saterusna ti pod kahiji bakal ngaliwatan sambungan nu geus ngadegkeun:

   

Hasilna nyaéta waktos réspon anu langkung gancang sareng throughput anu langkung luhur, tapi anjeun kaleungitan kamampuan pikeun skala backend.

Malah lamun boga dua pods di backend nu, kalawan sambungan konstan, lalulintas bakal salawasna buka salah sahijina.

Naha ieu tiasa dilereskeun?

Kusabab Kubernetes henteu terang kumaha carana nyaimbangkeun sambungan anu terus-terusan, tugas ieu tumiba ka anjeun.

Jasa mangrupikeun kumpulan alamat IP sareng palabuhan anu disebut titik tungtung.

Aplikasi anjeun tiasa nampi daptar titik tungtung tina jasa sareng mutuskeun kumaha ngadistribusikaeun pamundut diantara aranjeunna. Anjeun tiasa muka sambungan pengkuh pikeun tiap pod na kasaimbangan requests antara sambungan ieu ngagunakeun round-robin.

Atawa nerapkeun leuwih algoritma balancing kompléks.

Kodeu sisi klien anu tanggung jawab pikeun kasaimbangan kedah nuturkeun logika ieu:

1. Meunang daptar titik tungtung tina jasa.
2. Buka sambungan pengkuh pikeun tiap titik tungtung.
3. Nalika pamundut kedah dilakukeun, paké salah sahiji sambungan anu kabuka.
4. Ngapdet daptar titik tungtung sacara rutin, jieun anu anyar atanapi tutup sambungan permanén anu lami upami daptarna robih.

Ieu naon eta bakal kasampak kawas.

1. Gantina pod munggaran ngirim pamundut ka layanan, anjeun tiasa saimbang requests di sisi klien:

   

2. Anjeun kedah nyerat kode anu naroskeun polong anu bagian tina jasa:

   

3. Sakali anjeun gaduh daptar, simpen dina sisi klien sareng dianggo pikeun nyambung ka pods:

   

4. Anjeun tanggung jawab pikeun algoritma balancing beban:

   

Ayeuna timbul patarosan: naha masalah ieu ngan dilarapkeun ka HTTP tetep-hirup?

Balancing beban sisi klien

HTTP sanes hiji-hijina protokol anu tiasa nganggo sambungan TCP persisten.

Upami aplikasi anjeun nganggo pangkalan data, maka sambungan TCP henteu dibuka unggal waktos anjeun kedah naroskeun atanapi nyandak dokumen tina pangkalan data. 

Gantina, sambungan TCP pengkuh kana database dibuka tur dipaké.

Upami pangkalan data anjeun dipasang dina Kubernetes sareng aksés disayogikeun salaku jasa, anjeun bakal mendakan masalah anu sami anu dijelaskeun dina bagian sateuacana.

Hiji réplika pangkalan data bakal langkung dimuat tibatan anu sanés. Kube-proxy sareng Kubernetes moal ngabantosan kasaimbangan sambungan. Anjeun kedah ati-ati pikeun nyaimbangkeun patarosan ka pangkalan data anjeun.

Gumantung kana perpustakaan nu Anjeun pake pikeun nyambung ka database, Anjeun bisa jadi kudu pilihan béda pikeun ngajawab masalah ieu.

Di handap ieu conto ngakses klaster database MySQL ti 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

Aya seueur protokol sanés anu nganggo sambungan TCP persisten:

• WebSockets sareng WebSockets aman
• HTTP / 2
• gRPC
• RSockets
• AMQP

Anjeun kudu geus akrab jeung lolobana protokol ieu.

Tapi upami protokol ieu populer pisan, naha henteu aya solusi balancing standar? Naha logika klien kedah robih? Naha aya solusi Kubernetes asli?

Kube-proxy sareng iptables dirancang pikeun nutupan kasus pamakean anu paling umum nalika nyebarkeun ka Kubernetes. Ieu keur genah.

Upami anjeun nganggo jasa wéb anu ngalaan REST API, anjeun untung - dina hal ieu, sambungan TCP pengkuh henteu dianggo, anjeun tiasa nganggo jasa Kubernetes.

Tapi sakali anjeun mimiti ngagunakeun sambungan TCP pengkuh, anjeun bakal kudu angka kaluar kumaha merata ngadistribusikaeun beban sakuliah backends. Kubernetes henteu ngandung solusi anu siap-siap pikeun hal ieu.

Nanging, pasti aya pilihan anu tiasa ngabantosan.

Balancing sambungan lila-cicing di Kubernetes

Aya opat jinis jasa dina Kubernetes:

1. KlusterIP
2. NodePort
3. LoadBalancer
4. Henteu aya sirah

Tilu jasa munggaran beroperasi dumasar kana alamat IP virtual, anu dianggo ku kube-proxy pikeun ngawangun aturan iptables. Tapi dasar dasar sadaya jasa nyaéta jasa tanpa sirah.

Ladenan tanpa sirah teu ngagaduhan alamat IP anu aya hubunganana sareng ngan ukur nyayogikeun mékanisme pikeun nyandak daptar alamat IP sareng palabuhan pods (titik tungtung) anu aya hubunganana sareng éta.

Sadaya jasa dumasar kana jasa tanpa sirah.

Ladenan ClusterIP nyaéta layanan tanpa sirah kalayan sababaraha tambahan: 

1. Lapisan manajemén masihan éta alamat IP.
2. Kube-proxy ngahasilkeun aturan iptables anu diperlukeun.

Ku cara ieu anjeun tiasa malire kube-proxy sareng langsung nganggo daptar titik tungtung anu dicandak tina jasa tanpa sirah pikeun ngamuat kasaimbangan aplikasi anjeun.

Tapi kumaha urang tiasa nambihan logika anu sami pikeun sadaya aplikasi anu dipasang dina kluster?

Upami aplikasi anjeun parantos dipasang, tugas ieu sigana teu mungkin. Sanajan kitu, aya hiji pilihan alternatif.

Service Mesh bakal ngabantosan anjeun

Anjeun panginten parantos terang yén strategi kasaimbangan beban sisi klien cukup standar.

Nalika aplikasi dimimitian, éta:

1. Meunang daptar alamat IP tina jasa.
2. Muka tur ngajaga kolam renang sambungan.
3. Périodik ngamutahirkeun kolam renang ku nambahkeun atawa miceun titik tungtung.

Sakali aplikasi hoyong ngadamel pamundut, éta:

1. Milih sambungan nu sadia ngagunakeun sababaraha logika (misalna round-robin).
2. Ngaéksekusi paménta.

Léngkah-léngkah ieu tiasa dianggo pikeun sambungan WebSockets, gRPC, sareng AMQP.

Anjeun tiasa misahkeun logika ieu kana perpustakaan anu misah sareng dianggo dina aplikasi anjeun.

Nanging, anjeun tiasa nganggo jaring jasa sapertos Istio atanapi Linkerd.

Service Mesh nambihan aplikasi anjeun ku prosés anu:

1. Otomatis milarian alamat IP jasa.
2. Nguji sambungan sapertos WebSockets sareng gRPC.
3. Balances requests ngagunakeun protokol bener.

Service Mesh ngabantosan ngatur lalu lintas dina kluster, tapi éta cukup sumber daya. Pilihan sanésna nganggo perpustakaan pihak katilu sapertos Netflix Ribbon atanapi proksi anu tiasa diprogram sapertos Envoy.

Naon anu bakal kajadian upami anjeun teu malire masalah kasaimbangan?

Anjeun tiasa milih henteu nganggo balancing beban sareng tetep teu aya perhatosan perobihan. Hayu urang nempo sababaraha skenario gawé.

Upami Anjeun gaduh leuwih klien ti server, ieu teu jadi masalah badag.

Hayu urang nyebutkeun aya lima klien nu nyambung ka dua server. Sanaos henteu aya kasaimbangan, duanana server bakal dianggo:

Sambungan bisa jadi teu merata disebarkeun: meureun opat klien disambungkeun ka server sarua, tapi aya kasempetan alus yén duanana server bakal dipaké.

Anu langkung masalah nyaéta skenario anu sabalikna.

Upami anjeun gaduh pangsaeutikna klien sareng langkung seueur server, sumber daya anjeun tiasa teu dianggo sareng poténsi bottleneck bakal muncul.

Sebutkeun aya dua klien sareng lima server. Dina kasus pangalusna, bakal aya dua sambungan permanén ka dua server kaluar lima.

Sésana server bakal dianggurkeun:

Upami dua server ieu henteu tiasa ngadamel pamundut klien, skala horisontal moal ngabantosan.

kacindekan

Ladenan Kubernetes dirancang pikeun dianggo dina kalolobaan skenario aplikasi wéb standar.

Tapi, pas anjeun ngamimitian damel sareng protokol aplikasi anu nganggo sambungan TCP persisten, sapertos database, gRPC atanapi WebSockets, jasa henteu cocog deui. Kubernetes teu nyadiakeun mékanisme internal pikeun nyaimbangkeun sambungan TCP pengkuh.

Ieu ngandung harti yén anjeun kedah nyerat aplikasi kalayan kasaimbangan sisi klien dina pikiran.

Tarjamahan disiapkeun ku tim Kubernetes aaS ti Mail.ru.

Naon deui maca dina topik:

1. Tilu tingkat autoscaling di Kubernetes sareng cara ngagunakeunana sacara efektif. 
2. Kubernetes dina sumanget piracy kalawan template pikeun palaksanaan.
3. Saluran Telegram kami ngeunaan transformasi digital.

sumber: www.habr.com