🥇Pagbalanse sa load ug pag-scale sa dugay nang mga koneksyon sa Kubernetes

Kini nga artikulo makatabang kanimo nga masabtan kung giunsa paglihok ang pagbalanse sa load sa Kubernetes, kung unsa ang mahitabo kung mag-scale sa mga dugay na nga koneksyon, ug kung ngano nga kinahanglan nimo nga ikonsiderar ang pagbalanse sa kilid sa kliyente kung mogamit ka sa HTTP/2, gRPC, RSockets, AMQP, o uban pang dugay na nga mga protocol. .

Usa ka gamay bahin sa kung giunsa ang pag-apod-apod sa trapiko sa Kubernetes

Naghatag ang Kubernetes og duha ka sayon nga abstraction alang sa pag-deploy sa mga aplikasyon: Mga Serbisyo ug Mga Deployment.

Gihulagway sa mga deployment kung giunsa ug pila ka kopya sa imong aplikasyon ang kinahanglan nga magamit sa bisan unsang oras. Ang matag aplikasyon gipakatap isip Pod ug gihatagan ug IP address.

Ang mga serbisyo susama sa function sa usa ka load balancer. Gidisenyo sila sa pag-apod-apod sa trapiko sa daghang mga pod.

Tan-awon nato kon unsay hitsura niini.

Sa diagram sa ubos makita nimo ang tulo ka mga higayon sa parehas nga aplikasyon ug usa ka balanse sa pagkarga:
Ang load balancer gitawag og Serbisyo ug gihatagan og IP address. Ang bisan unsang umaabot nga hangyo gi-redirect sa usa sa mga pod:
Ang senaryo sa pag-deploy nagtino sa gidaghanon sa mga higayon sa aplikasyon. Halos dili na nimo kinahanglan nga mopalapad direkta ubos sa:
Ang matag pod gihatagan ug kaugalingong IP address:

Mapuslanon ang paghunahuna sa mga serbisyo ingon usa ka koleksyon sa mga adres sa IP. Sa matag higayon nga imong ma-access ang serbisyo, usa sa mga IP address ang gipili gikan sa lista ug gigamit ingon nga destinasyon nga adres.

Murag mao ni.

Usa ka curl 10.96.45.152 nga hangyo ang nadawat sa serbisyo:
Gipili sa serbisyo ang usa sa tulo ka adres sa pod ingon nga destinasyon:
Ang trapiko gi-redirect sa usa ka piho nga pod:

Kung ang imong aplikasyon naglangkob sa usa ka frontend ug usa ka backend, nan ikaw adunay usa ka serbisyo ug usa ka deployment alang sa matag usa.

Kung ang frontend mohangyo sa backend, dili kinahanglan nga mahibal-an kung pila ka pod ang gisilbi sa backend: mahimong adunay usa, napulo, o usa ka gatos.

Usab, ang frontend walay nahibal-an bahin sa mga adres sa mga pod nga nagsilbi sa backend.

Kung ang frontend naghangyo sa backend, gigamit niini ang IP address sa serbisyo sa backend, nga dili mausab.

Mao kini ang hitsura niini.

Ubos sa 1 naghangyo sa internal nga bahin sa backend. Imbis nga magpili usa ka piho alang sa backend, naghimo kini usa ka hangyo sa serbisyo:
Gipili sa serbisyo ang usa sa mga backend pod ingon nga adres sa destinasyon:
Ang trapiko gikan sa Pod 1 hangtod sa Pod 5, gipili sa serbisyo:
Ubos sa 1 wala mahibal-an kung pila ka mga pod sama sa ubos sa 5 ang gitago sa luyo sa serbisyo:

Apan sa unsang paagi nga ang serbisyo nag-apod-apod sa mga hangyo? Morag round-robin balancing ang gigamit? Atong hisgotan kini.

Pagbalanse sa mga serbisyo sa Kubernetes

Ang mga serbisyo sa Kubernetes wala maglungtad. Wala’y proseso alang sa serbisyo nga gihatagan usa ka IP address ug pantalan.

Mahimo nimong pamatud-an kini pinaagi sa pag-log in sa bisan unsang node sa cluster ug pagpadagan sa netstat -ntlp command.

Dili gani nimo makit-an ang IP address nga gigahin sa serbisyo.

Ang IP address sa serbisyo nahimutang sa control layer, sa controller, ug girekord sa database - etcd. Ang parehas nga adres gigamit sa lain nga sangkap - kube-proxy.
Ang Kube-proxy nakadawat og lista sa mga IP address para sa tanang serbisyo ug nagmugna og set sa mga iptable nga lagda sa matag node sa cluster.

Kini nga mga lagda nag-ingon: "Kung makita namon ang IP address sa serbisyo, kinahanglan namon nga usbon ang destinasyon nga adres sa hangyo ug ipadala kini sa usa sa mga pod."

Ang serbisyo IP address gigamit lamang isip usa ka entry point ug wala giserbisyuhan sa bisan unsang proseso sa pagpaminaw sa IP address ug port.

Atong tan-awon kini.

Tagda ang usa ka pungpong sa tulo ka node. Ang matag node adunay mga pod:
Ang gihigot nga mga pod nga gipintalan nga beige kabahin sa serbisyo. Tungod kay ang serbisyo wala maglungtad ingon usa ka proseso, kini gipakita sa gray:
Ang unang pod nangayo ug serbisyo ug kinahanglang moadto sa usa sa mga kaubang pod:
Apan wala ang serbisyo, wala ang proseso. Giunsa kini pagtrabaho?
Sa wala pa ang hangyo mobiya sa node, moagi kini sa mga lagda sa iptables:
Ang mga lagda sa iptables nahibal-an nga ang serbisyo wala maglungtad ug gipulihan ang IP address niini sa usa sa mga IP address sa mga pod nga nakig-uban sa kana nga serbisyo:
Ang hangyo makadawat og balido nga IP address isip destinasyon nga adres ug giproseso nga normal:
Depende sa topology sa network, ang hangyo sa katapusan makaabot sa pod:

Maka-load ba ang iptables sa balanse?

Dili, ang mga iptable gigamit alang sa pagsala ug wala gidisenyo alang sa pagbalanse.

Bisan pa, posible nga magsulat usa ka hugpong sa mga lagda nga molihok sama pseudo-balancer.

Ug mao gyud kini ang gipatuman sa Kubernetes.

Kung ikaw adunay tulo ka pod, ang kube-proxy mosulat sa mosunod nga mga lagda:

Pilia ang una nga sub nga adunay posibilidad nga 33%, kung dili moadto sa sunod nga lagda.
Pilia ang ikaduha nga adunay posibilidad nga 50%, kung dili moadto sa sunod nga lagda.
Pilia ang ikatulo sa ubos.

Kini nga sistema nagresulta sa matag pod nga gipili nga adunay posibilidad nga 33%.

Ug walay garantiya nga ang Pod 2 mapili sunod human sa Pod 1.

Примечание: Ang iptables naggamit ug statistical module nga adunay random distribution. Busa, ang pagbalanse nga algorithm gibase sa random nga pagpili.

Karon nga nasabtan na nimo kung giunsa paglihok ang mga serbisyo, tan-awon naton ang mas makapaikag nga mga senaryo sa serbisyo.

Ang dugay na nga mga koneksyon sa Kubernetes dili sukdon pinaagi sa default

Ang matag hangyo sa HTTP gikan sa frontend hangtod sa backend gisilbihan sa usa ka bulag nga koneksyon sa TCP, nga giablihan ug gisirhan.

Kung ang frontend magpadala ug 100 ka hangyo kada segundo sa backend, unya 100 ka lain-laing koneksyon sa TCP ang maablihan ug sirado.

Mahimo nimong pakunhuran ang oras sa pagproseso sa hangyo ug pagkarga pinaagi sa pag-abli sa usa ka koneksyon sa TCP ug paggamit niini alang sa tanan nga nagsunod nga mga hangyo sa HTTP.

Ang HTTP protocol adunay feature nga gitawag HTTP keep-alive, o connection reuse. Sa kini nga kaso, usa ka koneksyon sa TCP ang gigamit aron magpadala ug makadawat daghang mga hangyo ug tubag sa HTTP:

Kini nga bahin dili mahimo pinaagi sa default: ang server ug kliyente kinahanglan nga ma-configure sumala niana.

Ang setup mismo yano ug ma-access alang sa kadaghanan sa mga programming language ug environment.

Ania ang pipila ka mga link sa mga pananglitan sa lain-laing mga pinulongan:

Unsa ang mahitabo kung gamiton nato ang keep-alive sa usa ka serbisyo sa Kubernetes?
Atong isipon nga ang frontend ug backend nagsuporta nga padayon nga buhi.

Kami adunay usa ka kopya sa frontend ug tulo ka kopya sa backend. Ang frontend naghimo sa unang hangyo ug nagbukas sa koneksyon sa TCP sa backend. Ang hangyo nakaabot sa serbisyo, usa sa mga backend pod ang gipili isip destinasyon nga adres. Ang backend nagpadala ug tubag, ug ang frontend makadawat niini.

Dili sama sa naandan nga sitwasyon diin ang koneksyon sa TCP sirado human makadawat og tubag, kini karon gipadayon nga bukas alang sa dugang nga HTTP nga mga hangyo.

Unsa ang mahitabo kung ang frontend magpadala ug daghang mga hangyo sa backend?

Aron ipasa kini nga mga hangyo, usa ka bukas nga koneksyon sa TCP ang gamiton, ang tanan nga mga hangyo moadto sa parehas nga backend diin ang una nga hangyo miadto.

Dili ba ang mga iptables kinahanglan nga mag-apod-apod usab sa trapiko?

Dili sa niini nga kaso.

Kung ang usa ka koneksyon sa TCP gihimo, kini moagi sa mga lagda sa iptables, nga nagpili usa ka piho nga backend kung diin moadto ang trapiko.

Tungod kay ang tanan nga nagsunod nga mga hangyo anaa na sa bukas nga koneksyon sa TCP, ang mga lagda sa iptables wala na tawgon.

Tan-awon nato kon unsay hitsura niini.

Ang unang pod nagpadala ug hangyo sa serbisyo:
Nahibal-an na nimo kung unsa ang sunod nga mahitabo. Wala ang serbisyo, apan adunay mga lagda sa iptables nga magproseso sa hangyo:
Usa sa mga backend pod ang pilion isip destinasyon nga adres:
Naabot pod ang hangyo. Niini nga punto, ang usa ka makanunayon nga koneksyon sa TCP tali sa duha nga mga pod matukod:
Ang bisan unsang sunod nga hangyo gikan sa una nga pod moagi sa natukod na nga koneksyon:

Ang resulta mao ang mas paspas nga oras sa pagtubag ug mas taas nga throughput, apan nawad-an ka sa abilidad sa pag-scale sa backend.

Bisan kung adunay ka duha ka pod sa backend, nga adunay kanunay nga koneksyon, ang trapiko kanunay nga moadto sa usa niini.

Mahimo ba kini ayohon?

Tungod kay ang Kubernetes dili mahibal-an kung unsaon pagbalanse ang padayon nga mga koneksyon, kini nga buluhaton nahulog kanimo.

Ang mga serbisyo usa ka koleksyon sa mga IP address ug mga pantalan nga gitawag og mga endpoint.

Makakuha ang imong aplikasyon og lista sa mga endpoint gikan sa serbisyo ug makahukom unsaon pag-apod-apod sa mga hangyo tali kanila. Mahimo nimong ablihan ang usa ka padayon nga koneksyon sa matag pod ug balanse nga mga hangyo tali niini nga mga koneksyon gamit ang round-robin.

O mag-apply ug dugang komplikado nga mga algorithm sa pagbalanse.

Ang code sa kilid sa kliyente nga responsable sa pagbalanse kinahanglang mosunod niini nga lohika:

Pagkuha og lista sa mga endpoint gikan sa serbisyo.
Ablihi ang usa ka padayon nga koneksyon alang sa matag endpoint.
Kung gikinahanglan ang paghangyo, gamita ang usa sa mga bukas nga koneksyon.
Kanunay nga i-update ang lista sa mga endpoint, paghimo og mga bag-o o isira ang daan nga padayon nga koneksyon kung ang lista mausab.

Ingon niini ang hitsura niini.

Imbis sa una nga pod ipadala ang hangyo sa serbisyo, mahimo nimong balansehon ang mga hangyo sa bahin sa kliyente:
Kinahanglan nimong isulat ang code nga mangutana kung unsang mga pod ang bahin sa serbisyo:
Kung naa na nimo ang lista, i-save kini sa kilid sa kliyente ug gamita kini aron makonektar sa mga pod:
Ikaw ang responsable sa load balancing algorithm:

Karon ang pangutana mitungha: kini ba nga problema magamit lamang sa HTTP keep-alive?

Pagbalanse sa load sa kilid sa kliyente

Ang HTTP dili lamang ang protocol nga makagamit sa padayon nga koneksyon sa TCP.

Kung ang imong aplikasyon naggamit usa ka database, nan ang koneksyon sa TCP dili maablihan sa matag higayon nga kinahanglan nimo nga mohangyo o magkuha usa ka dokumento gikan sa database.

Hinuon, ang usa ka padayon nga koneksyon sa TCP sa database giablihan ug gigamit.

Kung ang imong database gi-deploy sa Kubernetes ug ang pag-access gihatag ingon usa ka serbisyo, nan makasugat ka sa parehas nga mga problema nga gihulagway sa miaging seksyon.

Ang usa ka replika sa database mas makarga kay sa uban. Ang Kube-proxy ug Kubernetes dili makatabang sa pagbalanse sa mga koneksyon. Kinahanglan nimong ampingan ang pagbalanse sa mga pangutana sa imong database.

Depende kung asa nga librarya ang imong gigamit sa pagkonektar sa database, mahimo kang adunay lain-laing mga kapilian sa pagsulbad niini nga problema.

Sa ubos usa ka pananglitan sa pag-access sa MySQL database cluster gikan sa 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

Adunay daghang uban pang mga protocol nga naggamit kanunay nga koneksyon sa TCP:

WebSockets ug secured WebSockets
HTTP / 2
gRPC
Mga RSocket
AMQP

Kinahanglan nga pamilyar ka sa kadaghanan niini nga mga protocol.

Apan kung kini nga mga protocol popular kaayo, nganong wala'y usa ka standardized nga solusyon sa pagbalanse? Ngano nga kinahanglan nga usbon ang lohika sa kliyente? Aduna bay lumad nga solusyon sa Kubernetes?

Ang Kube-proxy ug mga iptable kay gilaraw aron matabonan ang kasagarang mga kaso sa paggamit kung mag-deploy sa Kubernetes. Kini alang sa kasayon.

Kung naggamit ka usa ka serbisyo sa web nga nagpadayag sa usa ka REST API, swerte ka - sa kini nga kaso, wala gigamit ang kanunay nga koneksyon sa TCP, mahimo nimong gamiton ang bisan unsang serbisyo sa Kubernetes.

Apan sa higayon nga magsugod ka sa paggamit sa makanunayon nga mga koneksyon sa TCP, kinahanglan nimo nga mahibal-an kung giunsa ang parehas nga pag-apod-apod sa load sa mga backend. Ang Kubernetes wala maglangkob sa mga andam nga solusyon alang niini nga kaso.

Bisan pa, adunay mga kapilian nga makatabang.

Pagbalanse sa dugay na nga mga koneksyon sa Kubernetes

Adunay upat ka matang sa mga serbisyo sa Kubernetes:

ClusterIP
NodePort
LoadBalancer
Wala’y ulo

Ang unang tulo ka mga serbisyo naglihok base sa usa ka virtual IP address, nga gigamit sa kube-proxy sa pagtukod iptables mga lagda. Apan ang sukaranan nga sukaranan sa tanan nga mga serbisyo usa ka serbisyo nga wala’y ulo.

Ang walay ulo nga serbisyo walay bisan unsang IP address nga nalangkit niini ug naghatag lamang ug mekanismo sa pagkuha sa listahan sa mga IP address ug mga pantalan sa mga pods (endpoints) nga nalangkit niini.

Ang tanan nga mga serbisyo gibase sa walay ulo nga serbisyo.

Ang serbisyo sa ClusterIP usa ka serbisyo nga wala’y ulo nga adunay pipila nga mga pagdugang:

Ang management layer naghatag niini og IP address.
Ang Kube-proxy nagmugna sa gikinahanglan nga mga lagda sa iptables.

Niining paagiha mahimo nimong ibaliwala ang kube-proxy ug direkta nga gamiton ang lista sa mga endpoint nga nakuha gikan sa serbisyo nga wala’y ulo aron ma-load ang balanse sa imong aplikasyon.

Apan unsaon nato pagdugang ang susama nga lohika sa tanan nga mga aplikasyon nga gipakatap sa cluster?

Kung ang imong aplikasyon na-deploy na, kini nga buluhaton ingon og imposible. Bisan pa, adunay usa ka alternatibo nga kapilian.

Ang Service Mesh makatabang kanimo

Tingali namatikdan na nimo nga ang estratehiya sa pagbalanse sa load sa kilid sa kliyente medyo sukaranan.

Sa diha nga ang aplikasyon magsugod, kini:

Nakakuha ug lista sa mga IP address gikan sa serbisyo.
Nagbukas ug nagmintinar sa koneksyon nga pool.
Kanunay nga gi-update ang pool pinaagi sa pagdugang o pagtangtang sa mga endpoint.

Kung ang aplikasyon gusto nga mohimo usa ka hangyo, kini:

Nagpili ug magamit nga koneksyon gamit ang pipila ka lohika (eg round-robin).
Nagpatuman sa hangyo.

Kini nga mga lakang magamit alang sa mga koneksyon sa WebSockets, gRPC, ug AMQP.

Mahimo nimong ibulag kini nga lohika sa usa ka lahi nga librarya ug gamiton kini sa imong mga aplikasyon.

Bisan pa, mahimo nimong gamiton ang mga meshes sa serbisyo sama sa Istio o Linkerd.

Ang Service Mesh nagdugang sa imong aplikasyon sa usa ka proseso nga:

Awtomatikong nangita alang sa mga adres sa serbisyo sa IP.
Gisulayan ang mga koneksyon sama sa WebSockets ug gRPC.
Balanse ang mga hangyo gamit ang husto nga protocol.

Ang Service Mesh nagtabang sa pagdumala sa trapiko sa sulod sa cluster, apan kini labi ka kusog sa kapanguhaan. Ang ubang mga kapilian naggamit sa mga librarya sa ikatulo nga partido sama sa Netflix Ribbon o mga programmable nga proxy sama sa Envoy.

Unsa ang mahitabo kung imong ibaliwala ang mga isyu sa pagbalanse?

Mahimo nimong pilion nga dili mogamit sa pagbalanse sa load ug dili gihapon makamatikod sa bisan unsang mga pagbag-o. Atong tan-awon ang pipila ka mga sitwasyon sa trabaho.

Kung adunay ka daghang mga kliyente kaysa mga server, dili kini usa ka dako nga problema.

Ingnon ta nga adunay lima ka mga kliyente nga nagkonektar sa duha ka mga server. Bisan kung walay pagbalanse, ang duha ka mga server gamiton:

Ang mga koneksyon mahimong dili parehas nga iapod-apod: tingali upat ka mga kliyente nga konektado sa parehas nga server, apan adunay usa ka maayong higayon nga ang duha nga mga server magamit.

Ang mas problema mao ang kaatbang nga senaryo.

Kung ikaw adunay gamay nga mga kliyente ug daghang mga server, ang imong mga kapanguhaan mahimong dili magamit ug usa ka potensyal nga bottleneck ang makita.

Ingnon ta nga adunay duha ka kliyente ug lima ka server. Sa labing maayo nga kaso, adunay duha ka permanente nga koneksyon sa duha ka mga server gikan sa lima.

Ang nahabilin nga mga server mahimong idle:

Kung kining duha ka mga server dili makadumala sa mga hangyo sa kliyente, ang horizontal scaling dili makatabang.

konklusyon

Ang mga serbisyo sa Kubernetes gidesinyo aron magtrabaho sa kadaghanan nga mga senaryo sa aplikasyon sa web.

Bisan pa, sa higayon nga magsugod ka sa pagtrabaho sa mga protocol sa aplikasyon nga naggamit kanunay nga koneksyon sa TCP, sama sa mga database, gRPC o WebSockets, ang mga serbisyo dili na angay. Ang Kubernetes wala maghatag ug internal nga mekanismo para sa pagbalanse sa padayon nga koneksyon sa TCP.

Nagpasabut kini nga kinahanglan nimo nga isulat ang mga aplikasyon nga naa sa hunahuna ang pagbalanse sa kilid sa kliyente.

Paghubad nga giandam sa team Kubernetes aaS gikan sa Mail.ru.

Unsa pa ang basahon sa hilisgutan:

Source: www.habr.com

Pagbalanse sa load ug pag-scale sa dugay nang mga koneksyon sa Kubernetes