🥇Kubernetes-en iraupen luzeko konexioak orekatzea eta eskalatzea ProHoster

Artikulu honek karga-orekatzeak Kubernetes-en nola funtzionatzen duen ulertzen lagunduko dizu, zer gertatzen den iraupen luzeko konexioak eskalatzean eta zergatik kontuan hartu behar duzun bezeroaren aldeko orekatzea HTTP/2, gRPC, RSockets, AMQP edo iraupen luzeko beste protokolo batzuk erabiltzen badituzu. .

Kubernetes-en trafikoa nola banatzen den apur bat

Kubernetes-ek bi abstrakzio eroso eskaintzen ditu aplikazioak zabaltzeko: Zerbitzuak eta Inplementazioak.

Inplementazioek deskribatzen dute nola eta zenbat kopia exekutatu behar diren une bakoitzean. Aplikazio bakoitza Pod gisa zabaltzen da eta IP helbide bat esleitzen zaio.

Zerbitzuak karga-orekatzaile baten funtzioan antzekoak dira. Trafikoa hainbat podetan banatzeko diseinatuta daude.

Ea nolakoa den.

Beheko diagraman aplikazio beraren hiru instantzia eta karga-orekatzaile bat ikus ditzakezu:
Karga-orekatzaileari Zerbitzua deitzen zaio eta IP helbide bat esleitzen zaio. Jasotzen den edozein eskaera ontzietako batera birbideratzen da:
Inplementazio eszenatokiak aplikazioaren instantzia kopurua zehazten du. Ia inoiz ez duzu zuzenean zabaldu beharko:
Pod bakoitzari bere IP helbidea esleitzen zaio:

Baliagarria da zerbitzuak IP helbideen bilduma gisa pentsatzea. Zerbitzura sartzen zaren bakoitzean, zerrendatik IP helbideetako bat hautatzen da eta helmuga helbide gisa erabiltzen da.

Honela dirudi.

Curl 10.96.45.152 eskaera jasotzen da zerbitzura:
Zerbitzuak hiru pod helbide hauetako bat hautatzen du helmuga gisa:
Trafikoa pod zehatz batera birbideratzen da:

Zure aplikazioa frontend eta backend batez osatuta badago, orduan zerbitzu bat eta inplementazio bat izango dituzu bakoitzarentzat.

Frontend-ak backend-ari eskaera bat egiten dionean, ez du jakin behar zehatz-mehatz zenbat pod zerbitzatzen dituen backend-ak: bat, hamar edo ehun egon daitezke.

Gainera, frontend-ak ez daki ezer backend-a zerbitzatzen duten poden helbideei buruz.

Frontendak backend-ari eskaera bat egiten dionean, backend zerbitzuaren IP helbidea erabiltzen du, eta hori ez da aldatzen.

Hona hemen nola itxura.

1-ek barne backend osagaia eskatzen du. Backend-erako berariazko bat hautatu beharrean, eskaera bat egiten dio zerbitzuari:
Zerbitzuak helmuga-helbide gisa backend podetako bat hautatzen du:
Trafikoa 1etik 5era doa, zerbitzuak hautatuta:
1etik beherakoek ez daki zehatz-mehatz 5 urtetik beherakoek zenbat ontzi ezkutatzen diren zerbitzuaren atzean:

Baina nola banatzen ditu zehazki zerbitzuak eskaerak? Badirudi round-robin oreka erabiltzen dela? Asma dezagun.

Kubernetes zerbitzuetan orekatzea

Kubernetes zerbitzuak ez dira existitzen. IP helbidea eta ataka bat esleitzen zaion zerbitzurako ez dago prozesurik.

Hau egiazta dezakezu klusterreko edozein nodotan saioa hasi eta netstat -ntlp komandoa exekutatuz.

Ezingo duzu zerbitzuari esleitutako IP helbidea aurkitu ere egin.

Zerbitzuaren IP helbidea kontrol-geruzan dago, kontrolagailuan, eta datu-basean erregistratuta dago - etcd. Helbide bera beste osagai batek erabiltzen du: kube-proxy.
Kube-proxy-k zerbitzu guztien IP helbideen zerrenda jasotzen du eta iptables arau multzo bat sortzen du klusterreko nodo bakoitzean.

Arau hauek esaten dute: "Zerbitzuaren IP helbidea ikusten badugu, eskaeraren helmuga helbidea aldatu eta podetako batera bidali behar dugu".

Zerbitzuaren IP helbidea sarrera-puntu gisa soilik erabiltzen da eta ez du IP helbide eta ataka hori entzuten duen prozesu batek zerbitzatzen.

Ikus dezagun hau.

Demagun hiru nodoko multzo bat. Nodo bakoitzak lekak ditu:
Beis margotutako lekak lotuta daude zerbitzuaren parte. Zerbitzua prozesu gisa existitzen ez denez, grisez agertzen da:
Lehenengo podak zerbitzu bat eskatzen du eta erlazionatutako podetako batera joan behar du:
Baina zerbitzua ez da existitzen, prozesua ez da existitzen. Nola dabil?
Eskaerak nodotik irten baino lehen, iptables arauak betetzen ditu:
iptables arauek badakite zerbitzua ez dela existitzen eta bere IP helbidea ordezkatzen du zerbitzu horrekin lotutako poden IP helbideetako batekin:
Eskaerak baliozko IP helbide bat jasotzen du helburu gisa eta normalean prozesatzen da:
Sarearen topologiaren arabera, eskaera azkenean podra iristen da:

iptables-ek balantzea karga dezake?

Ez, iptables iragazteko erabiltzen dira eta ez ziren orekatzeko diseinatu.

Hala ere, posible da funtzionatzen duten arau multzo bat idaztea sasi-orekatzailea.

Eta horixe da Kubernetesen inplementatzen dena.

Hiru pod badituzu, kube-proxy-k arau hauek idatziko ditu:

Hautatu lehen azpikoa % 33ko probabilitatearekin, bestela joan hurrengo araura.
Aukeratu bigarrena %50eko probabilitatearekin, bestela hurrengo araura joan.
Hautatu hirugarren azpian.

Sistema honek leka bakoitza % 33ko probabilitatearekin hautatzen du.

Eta ez dago bermatzen Pod 2 hurrengo Pod 1 ondoren aukeratuko denik.

Kontuan izan: iptables-ek ausazko banaketa duen modulu estatistiko bat erabiltzen du. Beraz, orekatzeko algoritmoa ausazko hautapenean oinarritzen da.

Zerbitzuek nola funtzionatzen duten ulertzen duzunean, ikus ditzagun zerbitzuen eszenatoki interesgarriagoak.

Kubernetes-en iraupen luzeko konexioak ez dira eskalatzen lehenespenez

Frontendetik backenderako HTTP eskaera bakoitza TCP konexio bereizi batek zerbitzatzen du, ireki eta itxi egiten dena.

Frontendak segundoko 100 eskaera bidaltzen baditu backend-era, orduan 100 TCP konexio ezberdin ireki eta itxiko dira.

Eskaerak prozesatzeko denbora eta karga murriztu ditzakezu TCP konexio bat irekiz eta hurrengo HTTP eskaera guztietan erabiliz.

HTTP protokoloak HTTP keep-alive edo konexioaren berrerabilpena izeneko funtzio bat du. Kasu honetan, TCP konexio bakarra erabiltzen da HTTP eskaera eta erantzun anitz bidaltzeko eta jasotzeko:

Ezaugarri hau ez dago lehenespenez gaituta: zerbitzaria zein bezeroa horren arabera konfiguratu behar dira.

Konfigurazioa bera erraza eta eskuragarria da programazio-lengoaia eta ingurune gehienetarako.

Hona hemen hainbat hizkuntzatako adibideetarako esteka:

Zer gertatzen da Keep-alive erabiltzen badugu Kubernetes zerbitzu batean?
Demagun frontend eta backend-ek bizirik mantentzen dutela onartzen dutela.

Frontendaren kopia bat eta backendaren hiru kopia ditugu. Frontendak lehenengo eskaera egiten du eta TCP konexio bat irekitzen du backend-era. Eskaera zerbitzura iristen da, helmuga-helbide gisa backend podetako bat hautatzen da. Backend-ak erantzun bat bidaltzen du eta frontend-ak jasotzen du.

Erantzun bat jaso ondoren TCP konexioa ixten den ohiko egoera ez bezala, orain irekita mantentzen da HTTP eskaera gehiago egiteko.

Zer gertatzen da frontend-ak eskaera gehiago bidaltzen baditu backend-era?

Eskaera hauek birbidaltzeko, TCP konexio ireki bat erabiliko da, eskaera guztiak lehen eskaera joan den backend berera joango dira.

iptablesek ez al luke trafikoa birbanatu behar?

Kasu honetan ez.

TCP konexio bat sortzen denean, iptables-en arauetatik igarotzen da, zeinak trafikoa joango den backend zehatz bat hautatzen baitu.

Ondorengo eskaera guztiak dagoeneko irekita dagoen TCP konexio batean daudenez, iptables arauak ez dira deitzen.

Ea nolakoa den.

Lehenengo podak eskaera bat bidaltzen dio zerbitzura:
Dagoeneko badakizu zer gertatuko den. Zerbitzua ez da existitzen, baina eskaera prozesatuko duten iptables arauak daude:
Atzeko gailuetako bat hautatuko da helmuga helbide gisa:
Eskaera lekura iristen da. Une honetan, bi poden arteko TCP konexio iraunkor bat ezarriko da:
Lehenengo podaren ondorengo eskaerak lehendik ezarritako konexiotik pasatuko dira:

Emaitza erantzun-denbora azkarragoa eta errendimendu handiagoa da, baina backend-a eskalatzeko gaitasuna galtzen duzu.

Backend-ean bi pod badituzu ere, etengabeko konexioarekin, trafikoa horietako batera joango da beti.

Konpondu al daiteke?

Kubernetes-ek konexio iraunkorrak nola orekatzen ez dakienez, zeregin hau zure esku dago.

Zerbitzuak amaierako puntuak izeneko IP helbide eta ataken bilduma bat dira.

Zure aplikazioak zerbitzuaren amaierako puntuen zerrenda lor dezake eta haien artean eskaerak nola banatu erabaki dezake. Konexio iraunkor bat ireki dezakezu pod bakoitzerako eta konexio horien arteko eskaerak orekatu round-robin erabiliz.

Edo gehiago aplikatu orekatzeko algoritmo konplexuak.

Orekatzeaz arduratzen den bezeroaren alboko kodeak logika hau jarraitu beharko luke:

Lortu zerbitzuaren amaierako puntuen zerrenda.
Ireki konexio iraunkor bat amaiera-puntu bakoitzeko.
Eskaera bat egin behar denean, erabili irekitako konexioetako bat.
Eguneratu amaierako puntuen zerrenda aldian-aldian, sortu berriak edo itxi konexio iraunkor zaharrak zerrenda aldatzen bada.

Honela izango da itxura.

Lehenengo podak eskaera zerbitzura bidali beharrean, eskaerak orekatu ditzakezu bezeroaren aldetik:
Zerbitzuaren parte diren podak zeintzuk diren galdetzen duen kodea idatzi behar duzu:
Zerrenda duzunean, gorde bezeroaren aldean eta erabili podsetara konektatzeko:
Karga orekatzeko algoritmoaren arduraduna zara:

Orain galdera sortzen da: arazo hau HTTP mantendu-biziari soilik aplikatzen al da?

Bezeroaren aldetik karga orekatzea

HTTP ez da TCP konexio iraunkorrak erabil ditzakeen protokolo bakarra.

Zure aplikazioak datu-base bat erabiltzen badu, ez da TCP konexiorik irekiko eskaera bat egin edo datu-basetik dokumentu bat berreskuratu behar duzun bakoitzean.

Horren ordez, datu-baserako TCP konexio iraunkor bat ireki eta erabiltzen da.

Zure datu-basea Kubernetes-en zabaltzen bada eta sarbidea zerbitzu gisa ematen bada, aurreko atalean azaldutako arazo berberak izango dituzu.

Datu-basearen erreplika bat besteak baino kargatuago egongo da. Kube-proxy eta Kubernetes-ek ez dute konexioak orekatzen lagunduko. Kontu egin behar duzu zure datu-baserako kontsultak orekatzeko.

Datu-basera konektatzeko erabiltzen duzun liburutegiaren arabera, arazo hau konpontzeko aukera desberdinak izan ditzakezu.

Jarraian, Node.js-etik MySQL datu-base-kluster batera sartzeko adibide bat dago:

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

TCP konexio iraunkorrak erabiltzen dituzten beste protokolo asko daude:

WebSockets eta WebSocket seguruak
HTTP / 2
gRPC
RSockets
AMQP

Dagoeneko ezagutu beharko zenuke protokolo horietako gehienak.

Baina protokolo hauek hain ezagunak badira, zergatik ez dago orekatzeko irtenbide estandarizaturik? Zergatik aldatu behar da bezeroaren logika? Ba al dago Kubernetes soluzio natiborik?

Kube-proxy eta iptables Kubernetes-en zabaltzen direnean erabilera-kasu ohikoenak estaltzeko diseinatuta daude. Hau erosotasunagatik da.

REST API bat erakusten duen web-zerbitzu bat erabiltzen ari bazara, zorte ona duzu; kasu honetan, TCP konexio iraunkorrak ez dira erabiltzen, edozein Kubernetes zerbitzu erabil dezakezu.

Baina TCP konexio iraunkorrak erabiltzen hasten zarenean, karga backendetan modu uniformean banatzen den asmatu beharko duzu. Kubernetes-ek ez du kasu honetarako prestatutako soluziorik.

Hala ere, zalantzarik gabe, lagungarri izan daitezkeen aukerak daude.

Kubernetesen iraupen luzeko konexioak orekatzea

Kubernetesen lau zerbitzu mota daude:

KlusterIP
NodePorta
LoadBalancer
bururik gabeko

Lehenengo hiru zerbitzuek IP helbide birtualean oinarrituta funtzionatzen dute, kube-proxy-k iptables arauak eraikitzeko erabiltzen duena. Baina zerbitzu guztien oinarrizko oinarria bururik gabeko zerbitzua da.

Bururik gabeko zerbitzuak ez du harekin lotutako IP helbiderik eta harekin lotutako IP helbideen eta ataken zerrenda bat berreskuratzeko mekanismoa baino ez du eskaintzen.

Zerbitzu guztiak bururik gabeko zerbitzuan oinarritzen dira.

ClusterIP zerbitzua bururik gabeko zerbitzua da, gehigarri batzuekin:

Kudeaketa geruzak IP helbide bat esleitzen dio.
Kube-proxy-k beharrezko iptables arauak sortzen ditu.

Horrela kube-proxy-a alde batera utzi eta bururik gabeko zerbitzutik lortutako puntuen zerrenda zuzenean erabil dezakezu zure aplikazioa karga orekatzeko.

Baina nola gehitu dezakegu antzeko logika klusterrean zabaldutako aplikazio guztiei?

Zure aplikazioa dagoeneko zabalduta badago, zeregin hau ezinezkoa dirudi. Hala ere, aukera alternatibo bat dago.

Service Mesh-ek lagunduko dizu

Seguruenik dagoeneko ohartu zara bezeroaren aldetik karga orekatzeko estrategia nahiko estandarra dela.

Aplikazioa hasten denean, hau da:

Zerbitzuaren IP helbideen zerrenda lortzen du.
Konexio-igerilekua ireki eta mantentzen du.
Aldian-aldian igerilekua eguneratzen du amaiera-puntuak gehituz edo kenduz.

Aplikazioak eskaera bat egin nahi duenean, hau:

Eskuragarri dagoen konexio bat hautatzen du logika batzuk erabiliz (adibidez, round-robin).
Eskaera exekutatzen du.

Urrats hauek WebSockets, gRPC eta AMQP konexioetarako funtzionatzen dute.

Logika hau beste liburutegi batean bereiz dezakezu eta zure aplikazioetan erabil dezakezu.

Hala ere, Istio edo Linkerd bezalako zerbitzu-sareak erabil ditzakezu horren ordez.

Service Mesh-ek zure aplikazioa areagotzen du prozesu batekin:

Zerbitzuaren IP helbideak automatikoki bilatzen ditu.
WebSockets eta gRPC bezalako konexioak probatzen ditu.
Eskaerak protokolo egokia erabiliz orekatzen ditu.

Service Mesh-ek klusterraren barruko trafikoa kudeatzen laguntzen du, baina nahiko baliabide ugari ditu. Beste aukera batzuk Netflix Ribbon bezalako hirugarrenen liburutegiak edo Envoy bezalako proxy programagarriak erabiltzen ari dira.

Zer gertatzen da oreka-arazoak alde batera uzten badituzu?

Karga-oreka ez erabiltzea eta oraindik aldaketarik ez nabaritzea aukera dezakezu. Ikus ditzagun lan-eszenatoki batzuk.

Zerbitzariak baino bezero gehiago badituzu, hau ez da hain arazo handia.

Demagun bi zerbitzarietara konektatzen diren bost bezero daudela. Orekarik ez badago ere, bi zerbitzariak erabiliko dira:

Baliteke konexioak ez egotea uniformeki banatuta: agian lau bezero zerbitzari berdinera konektatuta daude, baina aukera handia dago bi zerbitzariak erabiltzeko.

Problematsuagoa dena kontrako eszenatokia da.

Bezero gutxiago eta zerbitzari gehiago badituzu, baliteke zure baliabideak gutxi erabiltzea eta balizko botila-lepo bat agertuko da.

Demagun bi bezero eta bost zerbitzari daudela. Kasurik onenean, bi konexio iraunkor egongo dira bostetik bi zerbitzarirekin.

Gainerako zerbitzariak inaktibo egongo dira:

Bi zerbitzari hauek ezin badituzte bezeroen eskaerak kudeatu, eskalatze horizontalak ez du lagunduko.

Ondorioa

Kubernetes zerbitzuak web aplikazio estandar gehienetan funtzionatzeko diseinatuta daude.

Hala ere, TCP konexio iraunkorrak erabiltzen dituzten aplikazio-protokoloekin lanean hasten zarenean, hala nola datu-baseak, gRPC edo WebSockets, zerbitzuak jada ez dira egokiak. Kubernetes-ek ez du barne-mekanismorik eskaintzen TCP konexio iraunkorrak orekatzeko.

Horrek esan nahi du aplikazioak idatzi behar dituzula bezeroaren aldetik orekatzea kontuan izanda.

Taldeak prestatutako itzulpena Kubernetes aaS Mail.ru-tik.

Zer gehiago irakurri gaiari buruz:

Iturria: www.habr.com

Karga orekatzea eta iraupen luzeko konexioak eskalatzea Kubernetes-en