🥇 Cydbwyso llwyth a graddio cysylltiadau hirhoedlog yn Kubernetes

Bydd yr erthygl hon yn eich helpu i ddeall sut mae cydbwyso llwyth yn gweithio yn Kubernetes, beth sy'n digwydd wrth raddio cysylltiadau hirhoedlog, a pham y dylech ystyried cydbwyso ochr y cleient os ydych chi'n defnyddio HTTP/2, gRPC, RSockets, AMQP, neu brotocolau hirhoedlog eraill .

Ychydig am sut mae traffig yn cael ei ailddosbarthu yn Kubernetes

Mae Kubernetes yn darparu dau dyniad cyfleus ar gyfer defnyddio cymwysiadau: Gwasanaethau a Defnydd.

Mae gosodiadau yn disgrifio sut a faint o gopïau o'ch cais ddylai fod yn rhedeg ar unrhyw adeg benodol. Mae pob cais yn cael ei ddefnyddio fel Pod a rhoddir cyfeiriad IP iddo.

Mae gwasanaethau yn debyg o ran swyddogaeth i gydbwysedd llwyth. Maent wedi'u cynllunio i ddosbarthu traffig ar draws codennau lluosog.

Gawn ni weld sut olwg sydd arno.

Yn y diagram isod gallwch weld tri achos o'r un cymhwysiad a chydbwysedd llwyth:
Gelwir y balans llwyth yn Wasanaeth a rhoddir cyfeiriad IP iddo. Mae unrhyw gais sy'n dod i mewn yn cael ei ailgyfeirio i un o'r codennau:
Mae'r senario defnyddio yn pennu nifer yr achosion o'r cais. Bydd bron byth yn rhaid i chi ehangu'n uniongyrchol o dan:
Rhoddir ei gyfeiriad IP ei hun i bob pod:

Mae'n ddefnyddiol meddwl am wasanaethau fel casgliad o gyfeiriadau IP. Bob tro y byddwch chi'n cyrchu'r gwasanaeth, mae un o'r cyfeiriadau IP yn cael ei ddewis o'r rhestr a'i ddefnyddio fel y cyfeiriad cyrchfan.

Mae'n edrych fel hyn.

Mae cais curl 10.96.45.152 yn cael ei dderbyn i'r gwasanaeth:
Mae'r gwasanaeth yn dewis un o dri chyfeiriad pod fel cyrchfan:
Mae traffig yn cael ei ailgyfeirio i god penodol:

Os yw eich cais yn cynnwys blaen ac ôl-wyneb, yna bydd gennych wasanaeth a lleoliad ar gyfer pob un.

Pan fydd y blaen yn gwneud cais i'r pen ôl, nid oes angen iddo wybod yn union sawl cod y mae'r pen ôl yn ei wasanaethu: gallai fod un, deg, neu gant.

Hefyd, nid yw'r blaen yn gwybod dim am gyfeiriadau'r codennau sy'n gwasanaethu'r pen ôl.

Pan fydd y frontend yn gwneud cais i'r backend, mae'n defnyddio cyfeiriad IP y gwasanaeth backend, nad yw'n newid.

Dyma sut mae'n edrych.

Mae o dan 1 yn gofyn am y gydran fewnol gefn. Yn hytrach na dewis un penodol ar gyfer y backend, mae'n gwneud cais i'r gwasanaeth:
Mae'r gwasanaeth yn dewis un o'r codau backend fel y cyfeiriad cyrchfan:
Mae traffig yn mynd o Pod 1 i Pod 5, wedi'i ddewis gan y gwasanaeth:
Nid yw Dan 1 yn gwybod yn union faint o godennau fel dan 5 sydd wedi'u cuddio y tu ôl i'r gwasanaeth:

Ond sut yn union mae'r gwasanaeth yn dosbarthu ceisiadau? Mae'n ymddangos fel rownd-cydbwyso robin yn cael ei ddefnyddio? Gadewch i ni chyfrif i maes.

Cydbwyso gwasanaethau Kubernetes

Nid yw gwasanaethau Kubernetes yn bodoli. Nid oes unrhyw broses ar gyfer y gwasanaeth sy'n cael cyfeiriad IP a phorthladd.

Gallwch wirio hyn trwy fewngofnodi i unrhyw nod yn y clwstwr a rhedeg y gorchymyn netstat -ntlp.

Ni fyddwch hyd yn oed yn gallu dod o hyd i'r cyfeiriad IP a neilltuwyd i'r gwasanaeth.

Mae cyfeiriad IP y gwasanaeth wedi'i leoli yn yr haen reoli, yn y rheolydd, ac wedi'i gofnodi yn y gronfa ddata - ac ati. Defnyddir yr un cyfeiriad gan gydran arall - kube-proxy.
Mae Kube-proxy yn derbyn rhestr o gyfeiriadau IP ar gyfer pob gwasanaeth ac yn cynhyrchu set o reolau iptables ar bob nod yn y clwstwr.

Dywed y rheolau hyn: “Os gwelwn gyfeiriad IP y gwasanaeth, mae angen i ni addasu cyfeiriad cyrchfan y cais a’i anfon i un o’r codennau.”

Dim ond fel pwynt mynediad y defnyddir y cyfeiriad IP gwasanaeth ac nid yw'n cael ei wasanaethu gan unrhyw broses sy'n gwrando ar y cyfeiriad IP a'r porthladd hwnnw.

Gadewch i ni edrych ar hyn.

Ystyriwch glwstwr o dri nod. Mae codennau ym mhob nod:
Mae codennau clwm wedi'u paentio'n llwydfelyn yn rhan o'r gwasanaeth. Oherwydd nad yw'r gwasanaeth yn bodoli fel proses, fe'i dangosir mewn llwyd:
Mae'r pod cyntaf yn gofyn am wasanaeth a rhaid iddo fynd i un o'r codennau cysylltiedig:
Ond nid yw'r gwasanaeth yn bodoli, nid yw'r broses yn bodoli. Sut mae'n gweithio?
Cyn i'r cais adael y nod, mae'n mynd trwy reolau iptables:
Mae rheolau iptables yn gwybod nad yw'r gwasanaeth yn bodoli ac yn disodli ei gyfeiriad IP ag un o gyfeiriadau IP y codennau sy'n gysylltiedig â'r gwasanaeth hwnnw:
Mae'r cais yn derbyn cyfeiriad IP dilys fel y cyfeiriad cyrchfan ac yn cael ei brosesu fel arfer:
Yn dibynnu ar dopoleg y rhwydwaith, mae'r cais yn cyrraedd y pod yn y pen draw:

A all iptables lwytho cydbwysedd?

Na, defnyddir iptables ar gyfer hidlo ac ni chawsant eu cynllunio ar gyfer cydbwyso.

Fodd bynnag, mae'n bosibl ysgrifennu set o reolau sy'n gweithio fel ffug-gydbwyswr.

A dyma'n union beth sy'n cael ei weithredu yn Kubernetes.

Os oes gennych dri chod, bydd kube-proxy yn ysgrifennu'r rheolau canlynol:

Dewiswch yr is-adran gyntaf gyda thebygolrwydd o 33%, fel arall ewch i'r rheol nesaf.
Dewiswch yr ail un gyda thebygolrwydd o 50%, fel arall ewch i'r rheol nesaf.
Dewiswch y trydydd o dan.

Mae'r system hon yn arwain at ddewis pob pod gyda thebygolrwydd o 33%.

Ac nid oes unrhyw sicrwydd y bydd Pod 2 yn cael ei ddewis nesaf ar ôl Pod 1.

Nodyn: mae iptables yn defnyddio modiwl ystadegol gyda dosbarthiad ar hap. Felly, mae'r algorithm cydbwyso yn seiliedig ar ddewis ar hap.

Nawr eich bod yn deall sut mae gwasanaethau'n gweithio, gadewch i ni edrych ar senarios gwasanaeth mwy diddorol.

Nid yw cysylltiadau hirhoedlog yn Kubernetes yn graddio'n ddiofyn

Mae pob cais HTTP o'r blaen i'r pen ôl yn cael ei wasanaethu gan gysylltiad TCP ar wahân, sy'n cael ei agor a'i gau.

Os yw'r blaen yn anfon 100 cais yr eiliad i'r pen ôl, yna mae 100 o gysylltiadau TCP gwahanol yn cael eu hagor a'u cau.

Gallwch leihau amser prosesu ceisiadau a llwyth trwy agor un cysylltiad TCP a'i ddefnyddio ar gyfer pob cais HTTP dilynol.

Mae gan y protocol HTTP nodwedd o'r enw HTTP cadw'n fyw, neu ailddefnyddio cysylltiad. Yn yr achos hwn, defnyddir un cysylltiad TCP i anfon a derbyn nifer o geisiadau ac ymatebion HTTP:

Nid yw'r nodwedd hon wedi'i galluogi yn ddiofyn: rhaid ffurfweddu'r gweinydd a'r cleient yn unol â hynny.

Mae'r setup ei hun yn syml ac yn hygyrch ar gyfer y rhan fwyaf o ieithoedd rhaglennu ac amgylcheddau.

Dyma rai dolenni i enghreifftiau mewn gwahanol ieithoedd:

Beth sy'n digwydd os ydym yn defnyddio cadw'n fyw mewn gwasanaeth Kubernetes?
Gadewch i ni dybio bod y blaen a'r cefn yn cadw'n fyw.

Mae gennym un copi o'r blaen a thri chopi o'r pen ôl. Mae'r frontend yn gwneud y cais cyntaf ac yn agor cysylltiad TCP i'r pen ôl. Mae'r cais yn cyrraedd y gwasanaeth, dewisir un o'r codau backend fel y cyfeiriad cyrchfan. Mae'r backend yn anfon ymateb, ac mae'r blaen yn ei dderbyn.

Yn wahanol i'r sefyllfa arferol lle mae'r cysylltiad TCP ar gau ar ôl derbyn ymateb, mae bellach yn cael ei gadw ar agor ar gyfer ceisiadau HTTP pellach.

Beth sy'n digwydd os bydd y blaen yn anfon mwy o geisiadau i'r pen ôl?

I anfon y ceisiadau hyn ymlaen, bydd cysylltiad TCP agored yn cael ei ddefnyddio, bydd pob cais yn mynd i'r un ôl-wyneb lle aeth y cais cyntaf.

Oni ddylai iptables ailddosbarthu'r traffig?

Nid yn yr achos hwn.

Pan fydd cysylltiad TCP yn cael ei greu, mae'n mynd trwy reolau iptables, sy'n dewis pen ôl penodol lle bydd y traffig yn mynd.

Gan fod pob cais dilynol ar gysylltiad TCP sydd eisoes ar agor, nid yw rheolau iptables bellach yn cael eu galw.

Gawn ni weld sut olwg sydd arno.

Mae'r pod cyntaf yn anfon cais i'r gwasanaeth:
Rydych chi eisoes yn gwybod beth fydd yn digwydd nesaf. Nid yw'r gwasanaeth yn bodoli, ond mae rheolau iptables a fydd yn prosesu'r cais:
Bydd un o'r codennau ôl yn cael ei ddewis fel y cyfeiriad cyrchfan:
Mae'r cais yn cyrraedd y pod. Ar y pwynt hwn, sefydlir cysylltiad TCP parhaus rhwng y ddau god:
Bydd unrhyw gais dilynol o'r pod cyntaf yn mynd trwy'r cysylltiad sydd eisoes wedi'i sefydlu:

Y canlyniad yw amser ymateb cyflymach a mewnbwn uwch, ond rydych chi'n colli'r gallu i raddfa'r ôl-ben.

Hyd yn oed os oes gennych ddau god yn y pen ôl, gyda chysylltiad cyson, bydd traffig bob amser yn mynd i un ohonynt.

A ellir gosod hyn yn sefydlog?

Gan nad yw Kubernetes yn gwybod sut i gydbwyso cysylltiadau parhaus, chi sy'n gyfrifol am y dasg hon.

Casgliad o gyfeiriadau IP a phorthladdoedd o'r enw endpoints yw gwasanaethau.

Gall eich cais gael rhestr o bwyntiau terfyn gan y gwasanaeth a phenderfynu sut i ddosbarthu ceisiadau rhyngddynt. Gallwch agor cysylltiad parhaus i bob pod a chydbwyso ceisiadau rhwng y cysylltiadau hyn gan ddefnyddio rownd-robin.

Neu gwnewch gais mwy algorithmau cydbwyso cymhleth.

Dylai'r cod ochr cleient sy'n gyfrifol am gydbwyso ddilyn y rhesymeg hon:

Mynnwch restr o bwyntiau terfyn o'r gwasanaeth.
Agorwch gysylltiad parhaus ar gyfer pob pwynt terfyn.
Pan fydd angen gwneud cais, defnyddiwch un o'r cysylltiadau agored.
Diweddarwch y rhestr o bwyntiau terfyn yn rheolaidd, creu rhai newydd neu gau hen gysylltiadau parhaus os bydd y rhestr yn newid.

Dyma sut olwg fydd arno.

Yn lle bod y pod cyntaf yn anfon y cais i'r gwasanaeth, gallwch chi gydbwyso ceisiadau ar ochr y cleient:
Mae angen i chi ysgrifennu cod sy'n gofyn pa godennau sy'n rhan o'r gwasanaeth:
Ar ôl i chi gael y rhestr, arbedwch hi ar ochr y cleient a'i defnyddio i gysylltu â'r codennau:
Chi sy'n gyfrifol am yr algorithm cydbwyso llwyth:

Nawr mae'r cwestiwn yn codi: a yw'r broblem hon yn berthnasol i HTTP cadw'n fyw yn unig?

Cydbwyso llwyth ochr y cleient

Nid HTTP yw'r unig brotocol a all ddefnyddio cysylltiadau TCP parhaus.

Os yw'ch cais yn defnyddio cronfa ddata, yna nid yw cysylltiad TCP yn cael ei agor bob tro y bydd angen i chi wneud cais neu adfer dogfen o'r gronfa ddata.

Yn lle hynny, mae cysylltiad TCP parhaus â'r gronfa ddata yn cael ei agor a'i ddefnyddio.

Os yw'ch cronfa ddata yn cael ei defnyddio ar Kubernetes a bod mynediad yn cael ei ddarparu fel gwasanaeth, yna byddwch yn dod ar draws yr un problemau a ddisgrifiwyd yn yr adran flaenorol.

Bydd un copi cronfa ddata yn cael ei lwytho'n fwy na'r lleill. Ni fydd Kube-proxy a Kubernetes yn helpu i gydbwyso cysylltiadau. Rhaid i chi fod yn ofalus i gydbwyso'r ymholiadau i'ch cronfa ddata.

Yn dibynnu ar ba lyfrgell rydych chi'n ei defnyddio i gysylltu â'r gronfa ddata, efallai y bydd gennych chi opsiynau gwahanol ar gyfer datrys y broblem hon.

Isod mae enghraifft o gyrchu clwstwr cronfa ddata MySQL o 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

Mae yna lawer o brotocolau eraill sy'n defnyddio cysylltiadau TCP parhaus:

WebSockets a WebSockets diogel
HTTP / 2
gRPC
RSocedi
AMQP

Dylech fod yn gyfarwydd â'r rhan fwyaf o'r protocolau hyn eisoes.

Ond os yw'r protocolau hyn mor boblogaidd, pam nad oes ateb cydbwyso safonol? Pam mae angen newid rhesymeg y cleient? A oes datrysiad Kubernetes brodorol?

Mae Kube-proxy ac iptables wedi'u cynllunio i gwmpasu'r achosion defnydd mwyaf cyffredin wrth anfon i Kubernetes. Mae hyn er hwylustod.

Os ydych chi'n defnyddio gwasanaeth gwe sy'n datgelu API REST, rydych chi mewn lwc - yn yr achos hwn, ni ddefnyddir cysylltiadau TCP parhaus, gallwch ddefnyddio unrhyw wasanaeth Kubernetes.

Ond ar ôl i chi ddechrau defnyddio cysylltiadau TCP parhaus, bydd yn rhaid i chi ddarganfod sut i ddosbarthu'r llwyth yn gyfartal ar draws y backends. Nid yw Kubernetes yn cynnwys atebion parod ar gyfer yr achos hwn.

Fodd bynnag, yn sicr mae yna opsiynau a all helpu.

Cydbwyso cysylltiadau hirhoedlog yn Kubernetes

Mae pedwar math o wasanaeth yn Kubernetes:

ClwstwrIP
NodePort
Llwyth Cydbwysydd
Heb ben

Mae'r tri gwasanaeth cyntaf yn gweithredu yn seiliedig ar gyfeiriad IP rhithwir, a ddefnyddir gan kube-proxy i adeiladu rheolau iptables. Ond sylfaen sylfaenol pob gwasanaeth yw gwasanaeth di-ben.

Nid oes gan y gwasanaeth di-ben unrhyw gyfeiriad IP sy'n gysylltiedig ag ef ac mae'n darparu mecanwaith yn unig ar gyfer adalw rhestr o gyfeiriadau IP a phorthladdoedd y codennau (pwyntiau terfyn) sy'n gysylltiedig ag ef.

Mae pob gwasanaeth yn seiliedig ar y gwasanaeth heb ben.

Mae gwasanaeth ClusterIP yn wasanaeth heb ben gyda rhai ychwanegiadau:

Mae'r haen reoli yn rhoi cyfeiriad IP iddo.
Mae Kube-proxy yn cynhyrchu'r rheolau iptables angenrheidiol.

Fel hyn, gallwch anwybyddu kube-proxy a defnyddio'r rhestr o bwyntiau terfyn a gafwyd o'r gwasanaeth di-ben yn uniongyrchol i lwytho cydbwysedd eich cais.

Ond sut allwn ni ychwanegu rhesymeg debyg at bob cymhwysiad a ddefnyddir yn y clwstwr?

Os yw'ch cais eisoes wedi'i ddefnyddio, gall y dasg hon ymddangos yn amhosibl. Fodd bynnag, mae opsiwn arall.

Bydd Rhwyll Gwasanaeth yn eich helpu chi

Mae'n debyg eich bod eisoes wedi sylwi bod y strategaeth cydbwyso llwyth ochr y cleient yn eithaf safonol.

Pan fydd y cais yn dechrau, mae'n:

Yn cael rhestr o gyfeiriadau IP o'r gwasanaeth.
Yn agor ac yn cynnal pwll cysylltu.
Yn diweddaru'r pwll o bryd i'w gilydd trwy ychwanegu neu ddileu pwyntiau terfyn.

Unwaith y bydd y cais am wneud cais, mae'n:

Yn dewis cysylltiad sydd ar gael gan ddefnyddio rhywfaint o resymeg (ee rownd-robin).
Yn gweithredu'r cais.

Mae'r camau hyn yn gweithio ar gyfer cysylltiadau WebSockets, gRPC, ac AMQP.

Gallwch wahanu'r rhesymeg hon i lyfrgell ar wahân a'i defnyddio yn eich cymwysiadau.

Fodd bynnag, gallwch ddefnyddio rhwyllau gwasanaeth fel Istio neu Linkerd yn lle hynny.

Mae Gwasanaeth Rhwyll yn ychwanegu at eich cais gyda phroses sy'n:

Chwilio am gyfeiriadau IP gwasanaeth yn awtomatig.
Yn profi cysylltiadau fel WebSockets a gRPC.
Yn cydbwyso ceisiadau gan ddefnyddio'r protocol cywir.

Mae Gwasanaeth Rhwyll yn helpu i reoli traffig o fewn y clwstwr, ond mae'n defnyddio llawer o adnoddau. Mae opsiynau eraill yn cynnwys defnyddio llyfrgelloedd trydydd parti fel Netflix Ribbon neu ddirprwyon rhaglenadwy fel Envoy.

Beth fydd yn digwydd os byddwch yn anwybyddu materion cydbwyso?

Gallwch ddewis peidio â defnyddio cydbwyso llwyth a dal heb sylwi ar unrhyw newidiadau. Edrychwn ar ychydig o senarios gwaith.

Os oes gennych chi fwy o gleientiaid na gweinyddwyr, nid yw hyn yn broblem mor fawr.

Gadewch i ni ddweud bod yna bum cleient sy'n cysylltu â dau weinydd. Hyd yn oed os nad oes mantoli, bydd y ddau weinydd yn cael eu defnyddio:

Efallai na fydd cysylltiadau wedi'u dosbarthu'n gyfartal: efallai pedwar cleient wedi'u cysylltu â'r un gweinydd, ond mae siawns dda y bydd y ddau weinydd yn cael eu defnyddio.

Yr hyn sy'n fwy problematig yw'r senario i'r gwrthwyneb.

Os oes gennych lai o gleientiaid a mwy o weinyddion, efallai na fydd digon o ddefnydd o'ch adnoddau a bydd tagfa bosibl yn ymddangos.

Gadewch i ni ddweud bod dau gleient a phum gweinydd. Yn yr achos gorau, bydd dau gysylltiad parhaol â dau weinydd allan o bump.

Bydd gweddill y gweinyddion yn segur:

Os na all y ddau weinyddwr hyn drin ceisiadau cleient, ni fydd graddio llorweddol yn helpu.

Casgliad

Mae gwasanaethau Kubernetes wedi'u cynllunio i weithio yn y rhan fwyaf o senarios cymhwysiad gwe safonol.

Fodd bynnag, ar ôl i chi ddechrau gweithio gyda phrotocolau cymwysiadau sy'n defnyddio cysylltiadau TCP parhaus, megis cronfeydd data, gRPC neu WebSockets, nid yw gwasanaethau bellach yn addas. Nid yw Kubernetes yn darparu mecanweithiau mewnol ar gyfer cydbwyso cysylltiadau TCP parhaus.

Mae hyn yn golygu bod yn rhaid i chi ysgrifennu ceisiadau gan gadw cydbwysedd ochr y cleient mewn golwg.

Cyfieithiad wedi'i baratoi gan y tîm Kubernetes aaS o Mail.ru.

Beth arall i'w ddarllen ar y pwnc:

Ffynhonnell: hab.com

Cydbwyso llwyth a graddio cysylltiadau hirhoedlog yn Kubernetes