🥇Pakia kusawazisha na kuongeza miunganisho ya muda mrefu katika Kubernetes

Makala haya yatakusaidia kuelewa jinsi usawazishaji wa upakiaji unavyofanya kazi katika Kubernetes, kinachotokea wakati wa kuongeza miunganisho ya muda mrefu, na kwa nini unapaswa kuzingatia kusawazisha upande wa mteja ikiwa unatumia HTTP/2, gRPC, RSockets, AMQP, au itifaki zingine za muda mrefu. .

Kidogo kuhusu jinsi trafiki inavyosambazwa tena katika Kubernetes

Kubernetes hutoa vifupisho viwili vinavyofaa kwa kupeleka programu: Huduma na Usambazaji.

Utumaji hufafanua jinsi na nakala ngapi za programu yako zinapaswa kuendeshwa wakati wowote. Kila programu inatumwa kama Pod na imepewa anwani ya IP.

Huduma ni sawa katika utendaji kazi na mizani ya mzigo. Zimeundwa ili kusambaza trafiki kwenye maganda mengi.

Hebu tuone jinsi inavyoonekana.

Katika mchoro hapa chini unaweza kuona matukio matatu ya programu sawa na mizani ya mzigo:
Kisawazisha cha mzigo kinaitwa Huduma na kimepewa anwani ya IP. Ombi lolote linaloingia linaelekezwa kwa mojawapo ya maganda:
Hali ya utumaji huamua idadi ya matukio ya programu. Karibu hautalazimika kupanua moja kwa moja chini ya:
Kila ganda limepewa anwani yake ya IP:

Ni muhimu kufikiria huduma kama mkusanyiko wa anwani za IP. Kila wakati unapofikia huduma, mojawapo ya anwani za IP huchaguliwa kutoka kwenye orodha na kutumika kama anwani lengwa.

Inaonekana hivi.

Ombi la curl 10.96.45.152 limepokelewa kwa huduma:
Huduma huchagua mojawapo ya anwani tatu za ganda kama lengwa:
Trafiki inaelekezwa kwenye ganda maalum:

Ikiwa maombi yako yana sehemu ya mbele na ya nyuma, basi utakuwa na huduma na upelekaji kwa kila moja.

Wakati sehemu ya mbele inatuma ombi kwa upande wa nyuma, haihitaji kujua ni maganda ngapi ya sehemu ya nyuma hutumikia: kunaweza kuwa na moja, kumi, au mia.

Pia, sehemu ya mbele haijui chochote kuhusu anwani za maganda yanayohudumia sehemu ya nyuma.

Wakati sehemu ya mbele inafanya ombi kwa nyuma, hutumia anwani ya IP ya huduma ya nyuma, ambayo haibadilika.

Hivi ndivyo inavyoonekana.

Chini ya 1 huomba sehemu ya nyuma ya ndani. Badala ya kuchagua moja maalum kwa nyuma, hufanya ombi kwa huduma:
Huduma huchagua moja ya ganda la nyuma kama anwani lengwa:
Trafiki huenda kutoka Pod 1 hadi Pod 5, iliyochaguliwa na huduma:
Chini ya 1 hajui ni ganda ngapi kama chini ya 5 zimefichwa nyuma ya huduma:

Lakini ni jinsi gani huduma inasambaza maombi? Inaonekana kama kusawazisha kwa robin-pande zote hutumiwa? Hebu tufikirie.

Kusawazisha katika huduma za Kubernetes

Huduma za Kubernetes hazipo. Hakuna mchakato wa huduma ambayo imepewa anwani ya IP na bandari.

Unaweza kuthibitisha hili kwa kuingia kwenye nodi yoyote kwenye nguzo na kuendesha netstat -ntlp amri.

Hutaweza hata kupata anwani ya IP iliyotengewa huduma.

Anwani ya IP ya huduma iko kwenye safu ya udhibiti, kwenye kidhibiti, na imeandikwa kwenye hifadhidata - nk. Anwani hiyo hiyo inatumiwa na sehemu nyingine - kube-proksi.
Wakala wa Kube hupokea orodha ya anwani za IP kwa huduma zote na hutoa seti ya sheria za iptables kwenye kila nodi kwenye nguzo.

Sheria hizi zinasema: "Ikiwa tutaona anwani ya IP ya huduma, tunahitaji kurekebisha anwani ya ombi na kuituma kwa moja ya maganda."

Anwani ya IP ya huduma inatumika tu kama mahali pa kuingilia na haitumikiwi na mchakato wowote wa kusikiliza anwani hiyo ya IP na mlango.

Hebu tuangalie hili.

Fikiria nguzo ya nodi tatu. Kila nodi ina maganda:
Maganda yaliyofungwa ya rangi ya beige ni sehemu ya huduma. Kwa sababu huduma haipo kama mchakato, inaonyeshwa kwa kijivu:
Poda ya kwanza inaomba huduma na lazima iende kwa mojawapo ya maganda husika:
Lakini huduma haipo, mchakato haupo. Inafanyaje kazi?
Kabla ya ombi kuondoka kwenye nodi, hupitia sheria za iptables:
Sheria za iptables zinajua kuwa huduma haipo na hubadilisha anwani yake ya IP na anwani moja ya IP ya maganda yanayohusiana na huduma hiyo:
Ombi hupokea anwani halali ya IP kama anwani lengwa na huchakatwa kama kawaida:
Kulingana na topolojia ya mtandao, ombi hatimaye hufikia ganda:

Je, iptables zinaweza kupakia usawa?

Hapana, iptables hutumiwa kuchuja na hazikuundwa kwa kusawazisha.

Hata hivyo, inawezekana kuandika seti ya sheria zinazofanya kazi kama pseudo-balancer.

Na hii ndio hasa inatekelezwa katika Kubernetes.

Ikiwa una maganda matatu, kube-proksi itaandika sheria zifuatazo:

Chagua ndogo ya kwanza yenye uwezekano wa 33%, vinginevyo nenda kwa sheria inayofuata.
Chagua ya pili na uwezekano wa 50%, vinginevyo nenda kwa sheria inayofuata.
Chagua ya tatu chini.

Mfumo huu husababisha kila ganda kuchaguliwa kwa uwezekano wa 33%.

Na hakuna hakikisho kwamba Pod 2 itachaguliwa baada ya Pod 1.

Kumbuka: iptables hutumia moduli ya takwimu na usambazaji nasibu. Kwa hivyo, algorithm ya kusawazisha inategemea uteuzi wa nasibu.

Sasa kwa kuwa unaelewa jinsi huduma zinavyofanya kazi, hebu tuangalie matukio ya huduma ya kuvutia zaidi.

Viunganisho vya muda mrefu katika Kubernetes haviongezi kwa chaguo-msingi

Kila ombi la HTTP kutoka upande wa mbele hadi nyuma huhudumiwa na muunganisho tofauti wa TCP, ambao hufunguliwa na kufungwa.

Ikiwa sehemu ya mbele itatuma maombi 100 kwa sekunde kwa upande wa nyuma, basi miunganisho 100 tofauti ya TCP itafunguliwa na kufungwa.

Unaweza kupunguza muda wa kuchakata ombi na kupakia kwa kufungua muunganisho mmoja wa TCP na kuutumia kwa maombi yote yanayofuata ya HTTP.

Itifaki ya HTTP ina kipengele kinachoitwa HTTP keep-ave, au utumiaji tena wa muunganisho. Katika hali hii, muunganisho mmoja wa TCP hutumiwa kutuma na kupokea maombi na majibu mengi ya HTTP:

Kipengele hiki hakijawezeshwa kwa chaguo-msingi: seva na mteja lazima visanidiwe ipasavyo.

Usanidi yenyewe ni rahisi na unapatikana kwa lugha nyingi za programu na mazingira.

Hapa kuna viungo kadhaa vya mifano katika lugha tofauti:

Je, nini kitatokea ikiwa tunatumia Keep-hai katika huduma ya Kubernetes?
Wacha tuchukue kwamba sehemu ya mbele na ya nyuma inasaidia kuweka-hai.

Tuna nakala moja ya sehemu ya mbele na nakala tatu za mandharinyuma. Sehemu ya mbele hufanya ombi la kwanza na kufungua muunganisho wa TCP kwa upande wa nyuma. Ombi hufikia huduma, mojawapo ya maganda ya nyuma huchaguliwa kama anwani lengwa. Nyuma hutuma jibu, na sehemu ya mbele huipokea.

Tofauti na hali ya kawaida ambapo muunganisho wa TCP umefungwa baada ya kupokea jibu, sasa huwekwa wazi kwa maombi zaidi ya HTTP.

Je, nini kitatokea ikiwa sehemu ya mbele itatuma maombi zaidi kwa mandhari ya nyuma?

Ili kusambaza maombi haya, muunganisho wazi wa TCP utatumika, maombi yote yataenda kwenye mazingira yale yale ambapo ombi la kwanza lilienda.

Je, iptables hazipaswi kusambaza tena trafiki?

Sio katika kesi hii.

Wakati uunganisho wa TCP umeundwa, hupitia sheria za iptables, ambazo huchagua backend maalum ambapo trafiki itaenda.

Kwa kuwa maombi yote yanayofuata yako kwenye muunganisho tayari wa TCP, sheria za iptables hazijaitwa tena.

Hebu tuone jinsi inavyoonekana.

Poda ya kwanza hutuma ombi kwa huduma:
Tayari unajua nini kitatokea baadaye. Huduma haipo, lakini kuna sheria za iptables ambazo zitashughulikia ombi:
Moja ya ganda la nyuma litachaguliwa kama anwani lengwa:
Ombi linafikia ganda. Katika hatua hii, muunganisho unaoendelea wa TCP kati ya maganda mawili utaanzishwa:
Ombi lolote linalofuata kutoka kwa ganda la kwanza litapitia muunganisho uliowekwa tayari:

Matokeo yake ni kasi ya muda wa kujibu na matokeo ya juu zaidi, lakini unapoteza uwezo wa kuongeza matokeo.

Hata ikiwa una maganda mawili nyuma, na unganisho la mara kwa mara, trafiki itaenda kwa mmoja wao kila wakati.

Je! Hii inaweza kurekebishwa?

Kwa kuwa Kubernetes hajui jinsi ya kusawazisha miunganisho inayoendelea, jukumu hili ni lako.

Huduma ni mkusanyiko wa anwani za IP na bandari zinazoitwa endpoints.

Programu yako inaweza kupata orodha ya vidokezo kutoka kwa huduma na kuamua jinsi ya kusambaza maombi kati yao. Unaweza kufungua muunganisho unaoendelea kwa kila ganda na maombi ya kusawazisha kati ya miunganisho hii kwa kutumia duru-robin.

Au tuma maombi zaidi algorithms changamano ya kusawazisha.

Nambari ya upande wa mteja ambayo ina jukumu la kusawazisha inapaswa kufuata mantiki hii:

Pata orodha ya vidokezo kutoka kwa huduma.
Fungua muunganisho unaoendelea kwa kila ncha.
Wakati ombi linahitajika kufanywa, tumia moja ya viunganisho vilivyo wazi.
Sasisha mara kwa mara orodha ya vituo, unda vipya au funga miunganisho ya zamani ikiwa orodha itabadilika.

Hivi ndivyo itakavyokuwa.

Badala ya ganda la kwanza kutuma ombi kwa huduma, unaweza kusawazisha maombi kwa upande wa mteja:
Unahitaji kuandika msimbo unaouliza ni maganda gani ni sehemu ya huduma:
Mara tu unapokuwa na orodha, ihifadhi kwa upande wa mteja na uitumie kuunganisha kwenye maganda:
Unawajibika kwa algorithm ya kusawazisha mzigo:

Sasa swali linatokea: je, tatizo hili linatumika tu kwa HTTP kuweka-hai?

Usawazishaji wa upakiaji wa upande wa mteja

HTTP sio itifaki pekee inayoweza kutumia miunganisho endelevu ya TCP.

Ikiwa programu yako hutumia hifadhidata, basi muunganisho wa TCP haufunguliwe kila wakati unahitaji kufanya ombi au kupata hati kutoka kwa hifadhidata.

Badala yake, muunganisho unaoendelea wa TCP kwenye hifadhidata unafunguliwa na kutumika.

Ikiwa hifadhidata yako itatumwa kwenye Kubernetes na ufikiaji hutolewa kama huduma, basi utakumbana na shida sawa zilizoelezewa katika sehemu iliyotangulia.

Nakala moja ya hifadhidata itapakiwa zaidi kuliko zingine. Kube-proxy na Kubernetes hazitasaidia kusawazisha miunganisho. Lazima uangalie kusawazisha maswali kwenye hifadhidata yako.

Kulingana na maktaba gani unayotumia kuunganisha kwenye hifadhidata, unaweza kuwa na chaguo tofauti za kutatua tatizo hili.

Ifuatayo ni mfano wa kupata nguzo ya hifadhidata ya MySQL kutoka 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

Kuna itifaki zingine nyingi zinazotumia miunganisho ya TCP inayoendelea:

WebSockets na WebSockets zilizolindwa
HTTP / 2
gRPC
RSoketi
AMQP

Unapaswa kuwa tayari kufahamu nyingi ya itifaki hizi.

Lakini ikiwa itifaki hizi ni maarufu sana, kwa nini hakuna suluhisho sanifu la kusawazisha? Kwa nini mantiki ya mteja inahitaji kubadilika? Kuna suluhisho la asili la Kubernetes?

Proksi ya Kube na iptables zimeundwa kushughulikia hali nyingi za utumiaji wakati zinatumwa kwa Kubernetes. Hii ni kwa urahisi.

Ikiwa unatumia huduma ya wavuti inayofichua API ya REST, una bahati - katika kesi hii, miunganisho ya TCP inayoendelea haitumiki, unaweza kutumia huduma yoyote ya Kubernetes.

Lakini mara tu unapoanza kutumia miunganisho ya TCP inayoendelea, itabidi ujue jinsi ya kusambaza sawasawa mzigo kwenye sehemu za nyuma. Kubernetes haina suluhu zilizotengenezwa tayari kwa kesi hii.

Walakini, kuna chaguzi ambazo zinaweza kusaidia.

Kusawazisha miunganisho ya muda mrefu huko Kubernetes

Kuna aina nne za huduma katika Kubernetes:

ClusterIP
NodePort
LoadBalancer
Haina kichwa

Huduma tatu za kwanza hufanya kazi kulingana na anwani pepe ya IP, ambayo hutumiwa na kube-proksi kuunda sheria za iptables. Lakini msingi wa huduma zote ni huduma isiyo na kichwa.

Huduma isiyo na kichwa haina anwani yoyote ya IP inayohusishwa nayo na hutoa tu utaratibu wa kurejesha orodha ya anwani za IP na bandari za maganda (vituo vya mwisho) vinavyohusishwa nayo.

Huduma zote zinatokana na huduma isiyo na kichwa.

Huduma ya ClusterIP ni huduma isiyo na kichwa na nyongeza kadhaa:

Safu ya usimamizi inaipa anwani ya IP.
Kube-proksi hutoa sheria muhimu za iptables.

Kwa njia hii unaweza kupuuza kube-proksi na kutumia moja kwa moja orodha ya vituo vilivyopatikana kutoka kwa huduma isiyo na kichwa ili kupakia salio la programu yako.

Lakini tunawezaje kuongeza mantiki sawa kwa programu zote zilizowekwa kwenye nguzo?

Ikiwa programu yako tayari imetumwa, kazi hii inaweza kuonekana kuwa haiwezekani. Hata hivyo, kuna chaguo mbadala.

Service Mesh itakusaidia

Labda tayari umegundua kuwa mkakati wa kusawazisha mzigo wa upande wa mteja ni wa kawaida kabisa.

Wakati maombi yanapoanza, ni:

Hupata orodha ya anwani za IP kutoka kwa huduma.
Hufungua na kudumisha dimbwi la muunganisho.
Husasisha bwawa mara kwa mara kwa kuongeza au kuondoa sehemu za mwisho.

Mara tu ombi linapotaka kufanya ombi, ni:

Huchagua muunganisho unaopatikana kwa kutumia mantiki fulani (km. round-robin).
Hutekeleza ombi.

Hatua hizi hufanya kazi kwa miunganisho ya WebSockets, gRPC, na AMQP.

Unaweza kutenganisha mantiki hii katika maktaba tofauti na kuitumia katika programu zako.

Walakini, unaweza kutumia matundu ya huduma kama Istio au Linkerd badala yake.

Service Mesh huongeza maombi yako kwa mchakato ambao:

Hutafuta anwani za IP za huduma kiotomatiki.
Hujaribu miunganisho kama vile WebSockets na gRPC.
Husawazisha maombi kwa kutumia itifaki sahihi.

Huduma ya Mesh husaidia kudhibiti trafiki ndani ya nguzo, lakini inahitaji rasilimali nyingi. Chaguzi zingine ni kutumia maktaba za watu wengine kama Netflix Ribbon au proksi zinazoweza kupangwa kama Mjumbe.

Nini kinatokea ikiwa unapuuza masuala ya kusawazisha?

Unaweza kuchagua kutotumia kusawazisha upakiaji na bado usione mabadiliko yoyote. Hebu tuangalie matukio machache ya kazi.

Ikiwa una wateja wengi kuliko seva, hii sio shida kubwa.

Wacha tuseme kuna wateja watano ambao huunganisha kwa seva mbili. Hata kama hakuna kusawazisha, seva zote mbili zitatumika:

Viunganisho vinaweza kutosambazwa sawasawa: labda wateja wanne wameunganishwa kwenye seva moja, lakini kuna nafasi nzuri kwamba seva zote mbili zitatumika.

Kinachosumbua zaidi ni hali iliyo kinyume.

Iwapo una wateja wachache na seva nyingi zaidi, huenda rasilimali zako zisitumike na tatizo linalowezekana litatokea.

Wacha tuseme kuna wateja wawili na seva tano. Katika hali nzuri, kutakuwa na viunganisho viwili vya kudumu kwa seva mbili kati ya tano.

Seva zilizobaki zitakuwa bila kazi:

Ikiwa seva hizi mbili haziwezi kushughulikia maombi ya mteja, kuongeza mlalo hakutasaidia.

Hitimisho

Huduma za Kubernetes zimeundwa kufanya kazi katika hali nyingi za kawaida za utumaji wa wavuti.

Hata hivyo, pindi tu unapoanza kufanya kazi na itifaki za programu zinazotumia miunganisho endelevu ya TCP, kama vile hifadhidata, gRPC au WebSockets, huduma hazifai tena. Kubernetes haitoi mbinu za ndani za kusawazisha miunganisho ya TCP inayoendelea.

Hii inamaanisha ni lazima uandike programu kwa kuzingatia kusawazisha upande wa mteja.

Tafsiri iliyotayarishwa na timu Kubernetes aaS kutoka Mail.ru.

Nini kingine cha kusoma kwenye mada:

Chanzo: mapenzi.com

Kusawazisha mizigo na kuongeza miunganisho ya muda mrefu huko Kubernetes