Dësen Artikel hëlleft Iech ze verstoen wéi d'Laaschtbalancéierung a Kubernetes funktionnéiert, wat geschitt wann Dir laanglieweg Verbindungen skaléieren, a firwat Dir sollt Client-Säit Balance berücksichtegen wann Dir HTTP/2, gRPC, RSockets, AMQP oder aner laanglieweg Protokoller benotzt .
E bëssen iwwer wéi de Verkéier a Kubernetes ëmverdeelt gëtt
Kubernetes bitt zwee praktesch Abstraktioune fir Uwendungen z'installéieren: Services an Deployments.
Deployments beschreiwen wéi a wéivill Kopie vun Ärer Applikatioun zu all Moment lafen sollen. All Applikatioun gëtt als Pod ofgesat a gëtt eng IP Adress zougewisen.
D'Servicer sinn ähnlech a Funktioun wéi e Lastbalancer. Si sinn entwéckelt fir de Traffic iwwer verschidde Pods ze verdeelen.
Loosst eis kucken wéi et ausgesäit.
- Am Diagramm hei drënner kënnt Dir dräi Instanzen vun der selwechter Applikatioun an engem Lastbalancer gesinn:
- De Lastbalancer gëtt e Service genannt a gëtt eng IP Adress zougewisen. All erakommen Ufro gëtt op ee vun de Pods ëmgeleet:
- Den Deployment Szenario bestëmmt d'Zuel vun Instanzen vun der Applikatioun. Dir musst bal ni direkt ënner:
- All Pod gëtt seng eege IP Adress zougewisen:
Et ass nëtzlech fir Servicer als eng Sammlung vun IP Adressen ze denken. All Kéier wann Dir op de Service kënnt, gëtt eng vun den IP Adressen aus der Lëscht ausgewielt an als Destinatiounsadress benotzt.
Et gesäit esou aus.
- Eng Curl 10.96.45.152 Ufro gëtt un de Service kritt:
- De Service wielt eng vun dräi Podadressen als Destinatioun:
- Traffic gëtt op e spezifesche Pod ëmgeleet:
Wann Är Applikatioun aus engem Frontend an engem Backend besteet, da wäert Dir souwuel e Service wéi och eng Deployment fir all hunn.
Wann de Frontend eng Ufro un de Backend mécht, brauch et net genau ze wëssen wéivill Pods de Backend servéiert: et kéint een, zéng oder honnert sinn.
Och de Frontend weess näischt iwwer d'Adresse vun de Pods déi de Backend servéieren.
Wann de Frontend eng Ufro un de Backend mécht, benotzt se d'IP Adress vum Backend Service, deen net ännert.
Esou gesäit et aus.
- Ënner 1 freet den internen Backend Komponent. Amplaz e spezifesche fir de Backend ze wielen, mécht et eng Ufro un de Service:
- De Service wielt ee vun de Backend Pods als Destinatiounsadress:
- Den Traffic geet vum Pod 1 op Pod 5, ausgewielt vum Service:
- Ënner 1 weess net genau wéi vill Pods wéi ënner 5 hannert dem Service verstoppt sinn:
Awer wéi genee verdeelt de Service Ufroen? Et schéngt wéi Ronn-Robin Equiliber benotzt gëtt? Loosst eis et erausfannen.
Gläichgewiicht an Kubernetes Servicer
Kubernetes Servicer existéieren net. Et gëtt kee Prozess fir de Service deen eng IP Adress a Port zougewisen gëtt.
Dir kënnt dëst verifizéieren andeems Dir Iech an all Node am Cluster loggt an de Kommando netstat -ntlp ausféiert.
Dir wäert net emol d'IP Adress fannen, déi dem Service zougewisen ass.
D'IP Adress vum Service ass an der Kontrollschicht, am Controller, an an der Datebank opgeholl - etcd. Déi selwecht Adress gëtt vun engem anere Komponent benotzt - kube-Proxy.
Kube-Proxy kritt eng Lëscht vun IP Adressen fir all Servicer a generéiert eng Rei vun iptables Regelen op all Node am Cluster.
Dës Regele soen: "Wa mir d'IP Adress vum Service gesinn, musse mir d'Destinatiounsadress vun der Ufro änneren an et un ee vun de Pods schécken."
D'IP Adress vum Service gëtt nëmmen als Entrée benotzt a gëtt net vun engem Prozess zerwéiert deen op dës IP Adress an den Hafen lauschtert.
Loosst eis dëst kucken.
- Betruecht e Stärekoup vun dräi Wirbelen. All Node huet Pods:
- Gebonne Pods beige gemoolt sinn Deel vum Service. Well de Service net als Prozess existéiert, gëtt et a gro gewisen:
- Den éischte Pod freet e Service a muss op ee vun den assoziéierten Pods goen:
- Mä de Service existéiert net, de Prozess existéiert net. Wéi funktionéiert et?
- Ier d'Ufro den Node verléisst, geet et duerch d'iptables Regelen:
- D'iptables Regele wëssen datt de Service net existéiert an ersetzt seng IP Adress mat enger vun den IP Adressen vun de Pods, déi mat deem Service verbonne sinn:
- D'Ufro kritt eng gëlteg IP Adress als Destinatiounsadress a gëtt normalerweis veraarbecht:
- Ofhängeg vun der Netzwierktopologie, erreecht d'Ufro schliisslech de Pod:
Kann iptables Laaschtbalance?
Nee, iptables gi benotzt fir ze filteren a waren net fir ze balancéieren entworf.
Wéi och ëmmer, et ass méiglech eng Rei vu Regelen ze schreiwen déi funktionnéieren .
A genee dat ass an Kubernetes ëmgesat.
Wann Dir dräi Pods hutt, schreift kube-Proxy déi folgend Regelen:
- Wielt déi éischt Ënner mat enger Wahrscheinlechkeet vun 33%, soss gitt op déi nächst Regel.
- Wielt déi zweet mat enger Wahrscheinlechkeet vu 50%, soss gitt op déi nächst Regel.
- Wielt déi drëtt ënner.
Dëse System resultéiert datt all Pod mat enger Wahrscheinlechkeet vun 33% ausgewielt gëtt.
An et gëtt keng Garantie datt de Pod 2 nächst nom Pod 1 gewielt gëtt.
Remarque: iptables benotzt engem statistesche Modul mat zoufälleg Verdeelung. Also baséiert de Balancealgorithmus op zoufälleger Auswiel.
Elo datt Dir verstitt wéi Servicer funktionnéieren, loosst eis méi interessant Service Szenarie kucken.
Laanglieweg Verbindungen a Kubernetes skaléieren net par défaut
All HTTP-Ufro vum Frontend op de Backend gëtt vun enger separater TCP-Verbindung zerwéiert, déi opgemaach an zou ass.
Wann de Frontend 100 Ufroe pro Sekonn un de Backend schéckt, da ginn 100 verschidde TCP Verbindungen opgemaach an zougemaach.
Dir kënnt d'Ufroveraarbechtungszäit reduzéieren an d'Laascht reduzéieren andeems Dir eng TCP Verbindung opmaacht an se fir all spéider HTTP-Ufroe benotzt.
Den HTTP-Protokoll huet eng Feature genannt HTTP Keep-alive, oder Verbindungswiederbenotzen. An dësem Fall gëtt eng eenzeg TCP Verbindung benotzt fir verschidde HTTP Ufroen an Äntwerten ze schécken an ze kréien:
Dës Fonktioun ass net als Standard aktivéiert: souwuel de Server wéi och de Client mussen deementspriechend konfiguréiert sinn.
De Setup selwer ass einfach an zougänglech fir déi meescht Programméierungssproochen an Ëmfeld.
Hei sinn e puer Linken op Beispiller a verschiddene Sproochen:
Wat geschitt wa mir Keep-alive an engem Kubernetes Service benotzen?
Loosst eis unhuelen datt souwuel de Frontend wéi och de Backend Keep-alive ënnerstëtzen.
Mir hunn eng Kopie vum Frontend an dräi Exemplare vum Backend. De Frontend mécht déi éischt Ufro an mécht eng TCP Verbindung zum Backend op. D'Ufro erreecht de Service, ee vun de Backend Pods gëtt als Destinatiounsadress ausgewielt. De Backend schéckt eng Äntwert, an de Frontend kritt et.
Am Géigesaz zu der üblecher Situatioun, wou d'TCP-Verbindung zougemaach gëtt nodeems se eng Äntwert kritt huet, gëtt se elo op fir weider HTTP-Ufroe gehal.
Wat geschitt wann de Frontend méi Ufroe un de Backend schéckt?
Fir dës Ufroe weiderzebréngen, gëtt eng oppe TCP Verbindung benotzt, all Ufroe ginn op dee selwechte Backend wou déi éischt Ufro goung.
Sollen iptables net de Verkéier ëmverdeelen?
Net an dësem Fall.
Wann eng TCP Verbindung erstallt gëtt, geet et duerch iptables Regelen, déi e spezifesche Backend auswielen, wou de Verkéier geet.
Well all spéider Ufroe op enger scho oppener TCP Verbindung sinn, ginn d'iptables Regelen net méi genannt.
Loosst eis kucken wéi et ausgesäit.
- Den éischte Pod schéckt eng Ufro un de Service:
- Dir wësst schonns wat duerno geschitt. De Service existéiert net, awer et gi iptables Regelen déi d'Ufro veraarbecht:
- Ee vun de Backend Pods gëtt als Destinatiounsadress ausgewielt:
- D'Demande erreecht de Pod. Zu dësem Zäitpunkt gëtt eng persistent TCP Verbindung tëscht den zwee Pods etabléiert:
- All spéider Ufro vum éischte Pod geet duerch déi scho etabléiert Verbindung:
D'Resultat ass méi séier Äntwertzäit a méi héijen Duerchgang, awer Dir verléiert d'Fäegkeet fir de Backend ze skaléieren.
Och wann Dir zwee Pods am Backend hutt, mat enger konstanter Verbindung, wäert de Traffic ëmmer op ee vun hinnen goen.
Kann dëst fixéiert ginn?
Well Kubernetes net weess wéi persistent Verbindunge balancéiert ginn, fällt dës Aufgab op Iech.
Servicer sinn eng Sammlung vun IP Adressen a Ports genannt Endpoints.
Är Applikatioun kann eng Lëscht vun Endpunkte vum Service kréien an entscheeden wéi d'Ufroen tëscht hinnen verdeelen. Dir kënnt eng persistent Verbindung op all Pod opmaachen an Ufroen tëscht dëse Verbindunge balancéieren mat Round-Robin.
Oder gëlle méi .
De Client-Säit Code dee verantwortlech ass fir d'Balancen soll dës Logik verfollegen:
- Kritt eng Lëscht vun Endpunkte vum Service.
- Öffnen eng persistent Verbindung fir all Endpunkt.
- Wann eng Ufro muss gemaach ginn, benotzt eng vun den oppene Verbindungen.
- Update regelméisseg d'Lëscht vun den Endpunkten, erstellt nei oder schléisst al persistent Verbindungen wann d'Lëscht ännert.
Dëst ass wéi et wäert ausgesinn.
- Amplaz datt den éischte Pod d'Ufro un de Service schéckt, kënnt Dir Ufroen op der Client Säit balanséieren:
- Dir musst Code schreiwen dee freet wéi eng Pods Deel vum Service sinn:
- Wann Dir d'Lëscht hutt, späichert se op der Client Säit a benotzt se fir mat de Pods ze verbannen:
- Dir sidd verantwortlech fir de Belaaschtungsalgorithmus:
Elo stellt sech d'Fro: gëllt dëse Problem nëmme fir HTTP Keep-alive?
Client-Säit Last Balance
HTTP ass net deen eenzege Protokoll deen persistent TCP Verbindunge ka benotzen.
Wann Är Applikatioun eng Datebank benotzt, da gëtt eng TCP Verbindung net all Kéier opgemaach wann Dir eng Ufro maache musst oder en Dokument aus der Datebank zréckzéien.
Amplaz gëtt eng persistent TCP Verbindung mat der Datebank opgemaach a benotzt.
Wann Är Datebank op Kubernetes agesat gëtt an den Zougang als Service gëtt, da wäert Dir déiselwecht Probleemer begéinen, déi an der viregter Sektioun beschriwwe ginn.
Eng Datebank Replika gëtt méi gelueden wéi déi aner. Kube-Proxy a Kubernetes hëllefen d'Verbindungen net ze balanséieren. Dir musst oppassen fir d'Ufroen op Är Datebank ze balanséieren.
Ofhängeg wéi eng Bibliothéik Dir benotzt fir mat der Datebank ze verbannen, kënnt Dir verschidde Méiglechkeeten hunn fir dëse Problem ze léisen.
Drënner ass e Beispill fir Zougang zu engem MySQL Datebankcluster vum 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 databaseEt gi vill aner Protokoller déi persistent TCP Verbindunge benotzen:
- WebSockets a geséchert WebSockets
- HTTP- / 2
- gRPC
- RSockets
- AMQP
Dir sollt scho mat de meeschte vun dëse Protokoller vertraut sinn.
Awer wann dës Protokoller sou populär sinn, firwat gëtt et keng standardiséiert Balanceléisung? Firwat muss d'Clientlogik änneren? Gëtt et eng gebierteg Kubernetes Léisung?
Kube-Proxy an iptables sinn entwéckelt fir déi meescht üblech Benotzungsfäll ze decken beim Ofbau op Kubernetes. Dëst ass fir d'Bequemlechkeet.
Wann Dir e Webservice benotzt deen e REST API aussetzt, hutt Dir Gléck - an dësem Fall ginn persistent TCP Verbindunge net benotzt, Dir kënnt all Kubernetes Service benotzen.
Awer wann Dir ufänkt persistent TCP Verbindungen ze benotzen, musst Dir erausfannen wéi Dir d'Laascht gläichméisseg iwwer d'Backends verdeelt. Kubernetes enthält keng fäerdeg Léisunge fir dëse Fall.
Wéi och ëmmer, et gi sécherlech Optiounen déi hëllefe kënnen.
Balancéiert laanglieweg Verbindungen zu Kubernetes
Et gi véier Zorte vu Servicer zu Kubernetes:
- ClusterIP
- NodePort
- LoadBalancer
- Kapplos
Déi éischt dräi Servicer funktionnéieren op Basis vun enger virtueller IP Adress, déi vu kube-Proxy benotzt gëtt fir iptables Regelen ze bauen. Awer d'fundamental Basis vun all Servicer ass e Kapplosen Service.
De Kapplosen Service huet keng IP Adress mat him assoziéiert a bitt nëmmen e Mechanismus fir eng Lëscht vun IP Adressen an Ports vun de Pods (Endpoints) déi mat him verbonne sinn.
All Servicer baséieren op de Kapplosen Service.
De ClusterIP Service ass e Kapplosen Service mat e puer Ergänzunge:
- D'Verwaltungsschicht gëtt et eng IP Adress.
- Kube-Proxy generéiert déi néideg iptables Regelen.
Op dës Manéier kënnt Dir Kube-Proxy ignoréieren an direkt d'Lëscht vun den Endpunkte benotzen, déi vum Headless Service kritt goufen, fir Är Uwendung ze laden.
Awer wéi kënne mir ähnlech Logik fir all Uwendungen addéieren, déi am Cluster ofgebaut ginn?
Wann Är Applikatioun scho ofgesat ass, kann dës Aufgab onméiglech schéngen. Wéi och ëmmer, et gëtt eng alternativ Optioun.
Service Mesh wäert Iech hëllefen
Dir hutt wahrscheinlech scho gemierkt datt d'Client-Säit Load Balancing Strategie zimlech Standard ass.
Wann d'Applikatioun ufänkt, ass et:
- Kritt eng Lëscht vun IP Adressen vum Service.
- Öffnet an ënnerhält e Verbindungspool.
- Periodesch aktualiséiert de Pool andeems Dir Endpunkte bäigefüügt oder ewechhuelt.
Wann d'Applikatioun eng Ufro wëllt maachen, ass et:
- Wielt eng verfügbar Verbindung mat enger Logik (zB Round-Robin).
- Féiert d'Ufro aus.
Dës Schrëtt funktionnéieren fir béid WebSockets, gRPC, an AMQP Verbindungen.
Dir kënnt dës Logik an eng separat Bibliothéik trennen an se an Ären Uwendungen benotzen.
Wéi och ëmmer, Dir kënnt Service Meshes wéi Istio oder Linkerd benotzen amplaz.
Service Mesh erweidert Är Uwendung mat engem Prozess deen:
- Sicht automatesch no Service IP Adressen.
- Testt Verbindungen wéi WebSockets a gRPC.
- Balancéiert Ufroe mam richtege Protokoll.
Service Mesh hëlleft den Traffic am Cluster ze managen, awer et ass zimmlech Ressourceintensiv. Aner Optiounen benotze Drëtt-Partei-Bibliothéike wéi Netflix Ribbon oder programméierbar Proxyen wéi Envoy.
Wat geschitt wann Dir Balanceproblemer ignoréiert?
Dir kënnt wielen d'Laaschtbalancéierung net ze benotzen an nach ëmmer keng Ännerunge bemierken. Loosst eis e puer Aarbechtsszenarie kucken.
Wann Dir méi Clienten wéi Serveren hutt, ass dëst net sou e grousse Problem.
Loosst eis soen datt et fënnef Clienten sinn déi mat zwee Servere verbannen. Och wann et kee Balance gëtt, gi béid Servere benotzt:
D'Verbindunge kënnen net gläichméisseg verdeelt ginn: vläicht véier Clienten déi mam selwechte Server verbonne sinn, awer et ass eng gutt Chance datt béid Servere benotzt ginn.
Wat méi problematesch ass ass de Géigendeel Szenario.
Wann Dir manner Clienten a méi Serveren hutt, kënnen Är Ressourcen ënnerbenotzt ginn an e potenzielle Flaschenhals erschéngt.
Loosst eis soen datt et zwee Clienten a fënnef Server sinn. Am beschte Fall ginn et zwee permanent Verbindungen op zwee Server vu fënnef.
Déi verbleiwen Server wäerten idle sinn:
Wann dës zwee Serveren net Client Ufroen handhaben kënnen, hëlleft horizontal Skaléieren net.
Konklusioun
Kubernetes Servicer sinn entwéckelt fir an de meeschte Standard Webapplikatiounsszenarien ze schaffen.
Wéi och ëmmer, wann Dir ufänkt mat Applikatiounsprotokollen ze schaffen, déi persistent TCP Verbindunge benotzen, wéi Datenbanken, gRPC oder WebSockets, Servicer sinn net méi gëeegent. Kubernetes bitt keng intern Mechanismen fir persistent TCP Verbindungen ze balancéieren.
Dëst bedeit datt Dir Uwendungen schreiwen muss mat Client-Säit Balance am Kapp.
Iwwersetzung virbereet vum Team .
Wat soss iwwer dëst Thema ze liesen:
- .
- .
- .
Source: will.com