Sveiki, esmu Sergejs Elancevs, es attīstos
Vispirms ieviesīsim dažus terminus:
- VIP (Virtual IP) - balansÄtÄja IP adrese
- Serveris, aizmugursistÄma, instance ā virtuÄla maŔīna, kurÄ darbojas lietojumprogramma
- RIP (Real IP) - servera IP adrese
- Healthcheck - servera gatavÄ«bas pÄrbaude
- PieejamÄ«bas zona, AZ - izolÄta infrastruktÅ«ra datu centrÄ
- ReÄ£ions - dažÄdu AZ savienÄ«ba
Slodzes balansÄtÄji atrisina trÄ«s galvenos uzdevumus: veic paÅ”u balansÄÅ”anu, uzlabo pakalpojuma kļūdu toleranci un vienkÄrÅ”o tÄ mÄrogoÅ”anu. Kļūdu tolerance tiek nodroÅ”inÄta, izmantojot automÄtisku trafika pÄrvaldÄ«bu: balansÄtÄjs uzrauga lietojumprogrammas stÄvokli un izslÄdz no balansÄÅ”anas gadÄ«jumiem, kas neiztur dzÄ«vÄ«guma pÄrbaudi. MÄrogoÅ”ana tiek nodroÅ”inÄta, vienmÄrÄ«gi sadalot slodzi starp gadÄ«jumiem, kÄ arÄ« lidojuma laikÄ atjauninot gadÄ«jumu sarakstu. Ja balansÄÅ”ana nav pietiekami viendabÄ«ga, dažas instances saÅems slodzi, kas pÄrsniedz to jaudas ierobežojumu, un pakalpojums kļūs mazÄk uzticams.
Slodzes balansÄtÄjs bieži tiek klasificÄts pÄc protokola slÄÅa no OSI modeļa, kurÄ tas darbojas. Cloud Balancer darbojas TCP lÄ«menÄ«, kas atbilst ceturtajam slÄnim L4.
PÄriesim pie mÄkoÅa balansÄtÄja arhitektÅ«ras pÄrskata. MÄs pakÄpeniski palielinÄsim detalizÄcijas lÄ«meni. MÄs sadalÄm balansÄtÄja sastÄvdaļas trÄ«s klasÄs. KonfigurÄcijas plaknes klase ir atbildÄ«ga par lietotÄja mijiedarbÄ«bu un saglabÄ sistÄmas mÄrÄ·a stÄvokli. VadÄ«bas plakne saglabÄ paÅ”reizÄjo sistÄmas stÄvokli un pÄrvalda sistÄmas no datu plaknes klases, kas ir tieÅ”i atbildÄ«gas par trafika piegÄdi no klientiem uz jÅ«su gadÄ«jumiem.
Datu plakne
Satiksme nonÄk dÄrgÄs ierÄ«cÄs, ko sauc par robežmarÅ”rutÄtÄjiem. Lai palielinÄtu kļūdu toleranci, vienÄ datu centrÄ vienlaikus darbojas vairÄkas Å”Ädas ierÄ«ces. PÄc tam trafiks tiek novirzÄ«ts uz balansÄtÄjiem, kas visiem AZ paziÅo jebkuras apraides IP adreses, izmantojot BGP klientiem.
Satiksme tiek pÄrraidÄ«ta pa ECMP - Ŕī ir marÅ”rutÄÅ”anas stratÄÄ£ija, saskaÅÄ ar kuru var bÅ«t vairÄki vienlÄ«dz labi marÅ”ruti uz mÄrÄ·i (mÅ«su gadÄ«jumÄ mÄrÄ·is bÅ«s galamÄrÄ·a IP adrese) un paketes var nosÅ«tÄ«t pa jebkuru no tiem. MÄs arÄ« atbalstÄm darbu vairÄkÄs pieejamÄ«bas zonÄs pÄc Å”Ädas shÄmas: katrÄ zonÄ reklamÄjam adresi, satiksme iet uz tuvÄko un nepÄrsniedz tÄs robežas. VÄlÄk ierakstÄ sÄ«kÄk aplÅ«kosim, kas notiek ar satiksmi.
KonfigurÄcijas plakne
KonfigurÄcijas plaknes galvenÄ sastÄvdaļa ir API, caur kuru tiek veiktas pamata darbÄ«bas ar balansÄtÄjiem: gadÄ«jumu izveidoÅ”ana, dzÄÅ”ana, sastÄva maiÅa, veselÄ«bas pÄrbaužu rezultÄtu iegÅ«Å”ana utt. No vienas puses, tÄ ir REST API, un, no otras puses, otrs, mÄs mÄkonÄ« ļoti bieži izmantojam ietvaru gRPC, tÄpÄc mÄs ātulkojamā REST uz gRPC un pÄc tam izmantojam tikai gRPC. JebkurÅ” pieprasÄ«jums noved pie asinhronu idempotentu uzdevumu sÄrijas izveidoÅ”anas, kas tiek izpildÄ«ti kopÄjÄ Yandex.Cloud darbinieku pÅ«lÄ. Uzdevumi ir uzrakstÄ«ti tÄ, lai tos jebkurÄ laikÄ varÄtu apturÄt un pÄc tam restartÄt. Tas nodroÅ”ina darbÄ«bu mÄrogojamÄ«bu, atkÄrtojamÄ«bu un reÄ£istrÄÅ”anu.
RezultÄtÄ uzdevums no API iesniegs pieprasÄ«jumu balansÄtÄja servisa kontrolierim, kas ir rakstÄ«ts Go. Tas var pievienot un noÅemt balansÄtÄjus, mainÄ«t aizmugurprogrammu sastÄvu un iestatÄ«jumus.
Pakalpojums saglabÄ savu stÄvokli Yandex datu bÄzÄ, izplatÄ«tÄ pÄrvaldÄ«tÄ datu bÄzÄ, kuru drÄ«z varÄsit izmantot. VietnÄ Yandex.Cloud, kÄ jau mÄs
AtgriezÄ«simies pie balansiera kontroliera. TÄs uzdevums ir saglabÄt informÄciju par balansÄtÄju un nosÅ«tÄ«t uz Healthcheck kontrolleri uzdevumu pÄrbaudÄ«t virtuÄlÄs maŔīnas gatavÄ«bu.
Healthcheck kontrolieris
Tas saÅem pieprasÄ«jumus mainÄ«t pÄrbaudes noteikumus, saglabÄ tos YDB, sadala uzdevumus starp Healtcheck mezgliem un apkopo rezultÄtus, kas pÄc tam tiek saglabÄti datu bÄzÄ un nosÅ«tÄ«ti slodzes lÄ«dzsvara kontrolierim. Tas savukÄrt nosÅ«ta pieprasÄ«jumu mainÄ«t klastera sastÄvu datu plaknÄ uz loadbalancer-node, par ko es runÄÅ”u tÄlÄk.
ParunÄsim vairÄk par veselÄ«bas pÄrbaudÄm. Tos var iedalÄ«t vairÄkÄs klasÄs. RevÄ«zijÄm ir dažÄdi panÄkumu kritÄriji. TCP pÄrbaudÄm ir nepiecieÅ”ams veiksmÄ«gi izveidot savienojumu noteiktÄ laika periodÄ. HTTP pÄrbaudÄm ir nepiecieÅ”ams gan veiksmÄ«gs savienojums, gan atbilde ar statusa kodu 200.
ArÄ« Äeki atŔķiras pÄc darbÄ«bas klases ā tie ir aktÄ«vi un pasÄ«vi. PasÄ«vÄs pÄrbaudes vienkÄrÅ”i pÄrrauga, kas notiek ar satiksmi, neveicot nekÄdas Ä«paÅ”as darbÄ«bas. Tas nedarbojas ļoti labi L4, jo tas ir atkarÄ«gs no augstÄka lÄ«meÅa protokolu loÄ£ikas: L4 nav informÄcijas par to, cik ilgi darbÄ«ba prasÄ«ja un vai savienojuma pabeigÅ”ana bija laba vai slikta. Lai veiktu aktÄ«vas pÄrbaudes, lÄ«dzsvarotÄjam ir jÄnosÅ«ta pieprasÄ«jumi katrai servera instancei.
LielÄkÄ daļa slodzes balansÄtÄju paÅ”i veic dzÄ«vÄ«bas pÄrbaudes. UzÅÄmumÄ Cloud mÄs nolÄmÄm atdalÄ«t Ŕīs sistÄmas daļas, lai palielinÄtu mÄrogojamÄ«bu. Å Ä« pieeja ļaus mums palielinÄt lÄ«dzsvarotÄju skaitu, vienlaikus saglabÄjot pakalpojumam iesniegto veselÄ«bas pÄrbaudes pieprasÄ«jumu skaitu. PÄrbaudes veic atseviŔķi veselÄ«bas pÄrbaudes mezgli, kuros pÄrbaudes mÄrÄ·i tiek sadalÄ«ti un replicÄti. JÅ«s nevarat veikt pÄrbaudes no viena saimniekdatora, jo tas var neizdoties. Tad mÄs nesaÅemsim viÅa pÄrbaudÄ«to gadÄ«jumu stÄvokli. MÄs veicam pÄrbaudes jebkurÄ no gadÄ«jumiem no vismaz trim veselÄ«bas pÄrbaudes mezgliem. MÄs sadalÄm pÄrbaužu mÄrÄ·us starp mezgliem, izmantojot konsekventus jaukÅ”anas algoritmus.
LÄ«dzsvaroÅ”anas un veselÄ«bas pÄrbaudes atdalÄ«Å”ana var radÄ«t problÄmas. Ja veselÄ«bas pÄrbaudes mezgls veic pieprasÄ«jumus instancei, apejot balansÄtÄju (kas Å”obrÄ«d neapkalpo trafiku), tad rodas dÄ«vaina situÄcija: resurss it kÄ ir dzÄ«vs, bet satiksme to nesasniegs. MÄs Å”o problÄmu atrisinÄm Å”Ädi: mÄs garantÄjam, ka mÄs uzsÄksim veselÄ«bas pÄrbaudes satiksmi, izmantojot balansierus. Citiem vÄrdiem sakot, shÄma pakeÅ”u pÄrvietoÅ”anai ar trafiku no klientiem un no veselÄ«bas pÄrbaudÄm atŔķiras minimÄli: abos gadÄ«jumos paketes nonÄks lÄ«dzstrÄdniekiem, kas nogÄdÄs tÄs mÄrÄ·a resursos.
AtŔķirÄ«ba ir tÄda, ka klienti iesniedz pieprasÄ«jumus VIP, bet veselÄ«bas pÄrbaudes veic pieprasÄ«jumus katram atseviŔķam RIP. Å eit rodas interesanta problÄma: mÄs saviem lietotÄjiem dodam iespÄju izveidot resursus pelÄkajos IP tÄ«klos. IedomÄsimies, ka ir divi dažÄdi mÄkoÅu Ä«paÅ”nieki, kuri savus pakalpojumus ir slÄpuÅ”i aiz balansÄtÄjiem. Katram no tiem ir resursi apakÅ”tÄ«klÄ 10.0.0.1/24 ar vienÄdÄm adresÄm. Jums ir jÄspÄj tos kaut kÄ atŔķirt, un Å”eit jums ir jÄiedziļinÄs Yandex.Cloud virtuÄlÄ tÄ«kla struktÅ«rÄ. LabÄk ir uzzinÄt sÄ«kÄku informÄciju
Healthcheck mezgli sazinÄs ar balansÄtÄjiem, izmantojot tÄ sauktÄs kvazi-IPv6 adreses. Kvaziadrese ir IPv6 adrese ar tajÄ iegultu IPv4 adresi un lietotÄja apakÅ”tÄ«kla ID. Trafiks sasniedz balansÄtÄju, kas no tÄ iegÅ«st IPv4 resursa adresi, aizstÄj IPv6 ar IPv4 un nosÅ«ta paketi uz lietotÄja tÄ«klu.
ApgrieztÄ trafika notiek tÄpat: balansÄtÄjs redz, ka galamÄrÄ·is ir pelÄks tÄ«kls no veselÄ«bas pÄrbaudÄ«tÄjiem, un pÄrvÄrÅ” IPv4 par IPv6.
VPP ā datu plaknes sirds
BalansÄtÄjs ir ieviests, izmantojot vektora pakeÅ”u apstrÄdes (VPP) tehnoloÄ£iju, Cisco sistÄmu tÄ«kla trafika pakeÅ”apstrÄdei. MÅ«su gadÄ«jumÄ ietvars darbojas papildus lietotÄja telpas tÄ«kla ierÄ«Äu pÄrvaldÄ«bas bibliotÄkai - Data Plane Development Kit (DPDK). Tas nodroÅ”ina augstu pakeÅ”u apstrÄdes veiktspÄju: kodolÄ notiek daudz mazÄk pÄrtraukumu un nav konteksta pÄrslÄgÅ”anÄs starp kodola vietu un lietotÄja vietu.
VPP iet vÄl tÄlÄk un izspiež no sistÄmas vÄl lielÄku veiktspÄju, apvienojot paketes partijÄs. VeiktspÄjas pieaugumu nodroÅ”ina agresÄ«va keÅ”atmiÅas izmantoÅ”ana mÅ«sdienu procesoros. Tiek izmantotas gan datu keÅ”atmiÅas (paketes tiek apstrÄdÄtas āvektorosā, dati atrodas tuvu viens otram), gan instrukciju keÅ”atmiÅas: VPP pakeÅ”u apstrÄde notiek pÄc grafika, kuras mezglos ir funkcijas, kas veic vienu un to paÅ”u uzdevumu.
PiemÄram, IP pakeÅ”u apstrÄde VPP notiek Å”ÄdÄ secÄ«bÄ: vispirms parsÄÅ”anas mezglÄ tiek parsÄtas pakeÅ”u galvenes, un pÄc tam tÄs tiek nosÅ«tÄ«tas uz mezglu, kas tÄlÄk pÄrsÅ«ta paketes atbilstoÅ”i marÅ”rutÄÅ”anas tabulÄm.
Mazliet hardcore. VPP autori nepieļauj kompromisus procesora keÅ”atmiÅu izmantoÅ”anÄ, tÄpÄc tipisks pakeÅ”u vektora apstrÄdes kods satur manuÄlu vektorizÄciju: ir apstrÄdes cilpa, kurÄ tiek apstrÄdÄta tÄda situÄcija kÄ āmums ir Äetras paketes rindÄā, tad tas pats diviem, tad - vienam. IepriekÅ”Äjas ielÄdes instrukcijas bieži tiek izmantotas, lai ielÄdÄtu datus keÅ”atmiÅÄ, lai paÄtrinÄtu piekļuvi tiem turpmÄkajÄs iterÄcijÄs.
n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// ...
while (n_left_from >= 4 && n_left_to_next >= 2)
{
// processing multiple packets at once
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
// ...
/* Prefetch next iteration. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
// actually process data
/* verify speculative enqueues, maybe switch current next frame */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
while (n_left_from > 0 && n_left_to_next > 0)
{
// processing packets by one
}
// processed batch
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}
TÄtad Healthchecks, izmantojot IPv6, sarunÄjas ar VPP, kas tos pÄrvÄrÅ” par IPv4. To veic grafa mezgls, ko mÄs saucam par algoritmisko NAT. Reversajai trafikai (un pÄrveidoÅ”anai no IPv6 uz IPv4) ir tas pats algoritmiskais NAT mezgls.
TieÅ”Ä trafika no balansÄtÄja klientiem iet caur grafika mezgliem, kas paÅ”i veic balansÄÅ”anu.
Pirmais mezgls ir lipÄ«gÄs sesijas. Tas saglabÄ jaucÄjkodu
5 korpusu jaukÅ”ana palÄ«dz mums veikt mazÄk aprÄÄ·inu nÄkamajÄ konsekventajÄ jaukÅ”anas mezglÄ, kÄ arÄ« labÄk apstrÄdÄt resursu saraksta izmaiÅas aiz balansÄtÄja. Kad pakete, kurai nav sesijas, nonÄk balansÄtÄjÄ, tÄ tiek nosÅ«tÄ«ta uz konsekvento jaukÅ”anas mezglu. Å eit notiek lÄ«dzsvaroÅ”ana, izmantojot konsekventu jaukÅ”anu: mÄs atlasÄm resursu no pieejamo ādzÄ«voā resursu saraksta. TÄlÄk paketes tiek nosÅ«tÄ«tas uz NAT mezglu, kas faktiski aizstÄj galamÄrÄ·a adresi un pÄrrÄÄ·ina kontrolsummas. KÄ redzams, mÄs ievÄrojam VPP noteikumus - patÄ«k patÄ«k, grupÄjot lÄ«dzÄ«gus aprÄÄ·inus, lai palielinÄtu procesora keÅ”atmiÅu efektivitÄti.
Konsekventa jaukŔana
KÄpÄc mÄs to izvÄlÄjÄmies un kas tas vispÄr ir? Vispirms apskatÄ«sim iepriekÅ”Äjo uzdevumu - resursa atlasi no saraksta.
Nekonsekventas jaukÅ”anas gadÄ«jumÄ tiek aprÄÄ·inÄta ienÄkoÅ”Äs paketes jaucÄjvÄrtÄ«ba un resurss tiek atlasÄ«ts no saraksta ar atlikumu, dalot Å”o jaucÄjfunkciju ar resursu skaitu. KamÄr saraksts paliek nemainÄ«gs, Ŕī shÄma darbojas labi: mÄs vienmÄr nosÅ«tÄm paketes ar vienu un to paÅ”u 5 korpusu uz vienu un to paÅ”u gadÄ«jumu. Ja, piemÄram, kÄds resurss pÄrstÄja reaÄ£Ät uz veselÄ«bas pÄrbaudÄm, tad lielai daļai jaucÄju izvÄle mainÄ«sies. Klienta TCP savienojumi tiks pÄrtraukti: pakete, kas iepriekÅ” sasniegusi gadÄ«jumu A, var sÄkt sasniegt gadÄ«jumu B, kas nav pazÄ«stama ar Ŕīs paketes sesiju.
Konsekventa jaukÅ”ana atrisina aprakstÄ«to problÄmu. VienkÄrÅ”Äkais veids, kÄ izskaidrot Å”o jÄdzienu, ir Å”Äds: iedomÄjieties, ka jums ir gredzens, uz kuru jÅ«s sadalÄt resursus, izmantojot hash (piemÄram, pÄc IP:porta). Resursa izvÄle ir riteÅa pagrieÅ”ana par leÅÄ·i, ko nosaka paketes hash.
Tas samazina trafika pÄrdali, kad mainÄs resursu sastÄvs. Resursa dzÄÅ”ana ietekmÄs tikai to konsekventÄ jaukÅ”anas gredzena daļu, kurÄ atradÄs resurss. Resursa pievienoÅ”ana maina arÄ« izplatÄ«Å”anu, taÄu mums ir lipÄ«go sesiju mezgls, kas ļauj nepÄrslÄgt jau izveidotÄs sesijas uz jauniem resursiem.
MÄs apskatÄ«jÄm, kas notiek, lai novirzÄ«tu trafiku starp balansÄtÄju un resursiem. Tagad apskatÄ«sim atpakaļgaitas satiksmi. Tas atbilst tÄdai paÅ”ai shÄmai, kÄ pÄrbaudÄ«t trafiku ā izmantojot algoritmisko NAT, tas ir, izmantojot reverso NAT 44 klientu trafikam un caur NAT 46 veselÄ«bas pÄrbaužu trafikam. MÄs ievÄrojam savu shÄmu: mÄs apvienojam veselÄ«bas pÄrbaužu trafiku un reÄlo lietotÄju trafiku.
Loadbalancer-mezgls un samontÄtie komponenti
Par balansÄtÄju un resursu sastÄvu VPP ziÅo vietÄjais dienests - loadbalancer-node. Tas abonÄ notikumu straumi no slodzes lÄ«dzsvara kontroliera un spÄj attÄlot atŔķirÄ«bu starp paÅ”reizÄjo VPP stÄvokli un mÄrÄ·a stÄvokli, kas saÅemts no kontrollera. MÄs iegÅ«stam slÄgtu sistÄmu: notikumi no API nonÄk lÄ«dzsvara kontrolierim, kas veselÄ«bas pÄrbaudes kontrolierim pieŔķir uzdevumus, lai pÄrbaudÄ«tu resursu ādzÄ«vuā. Tas savukÄrt pieŔķir uzdevumus veselÄ«bas pÄrbaudes mezglam un apkopo rezultÄtus, pÄc tam tos nosÅ«ta atpakaļ balansÄtÄja kontrollerim. Loadbalancer-node abonÄ kontroliera notikumus un maina VPP stÄvokli. Å ÄdÄ sistÄmÄ katrs dienests par blakus pakalpojumiem zina tikai nepiecieÅ”amo. Savienojumu skaits ir ierobežots, un mums ir iespÄja neatkarÄ«gi darboties un mÄrogot dažÄdus segmentus.
No kÄdÄm problÄmÄm izdevÄs izvairÄ«ties?
Visi mÅ«su pakalpojumi vadÄ«bas plaknÄ ir rakstÄ«ti Go, un tiem ir labas mÄrogoÅ”anas un uzticamÄ«bas Ä«paŔības. Go ir daudzas atvÄrtÄ pirmkoda bibliotÄkas sadalÄ«to sistÄmu veidoÅ”anai. MÄs aktÄ«vi izmantojam GRPC, visos komponentos ir atvÄrtÄ pirmkoda pakalpojumu atklÄÅ”anas ievieÅ”ana - mÅ«su pakalpojumi uzrauga viens otra veiktspÄju, var dinamiski mainÄ«t sastÄvu, un mÄs to saistÄ«jÄm ar GRPC balansÄÅ”anu. Metrikas noteikÅ”anai mÄs izmantojam arÄ« atvÄrtÄ pirmkoda risinÄjumu. Datu plaknÄ mÄs saÅÄmÄm pienÄcÄ«gu veiktspÄju un lielu resursu rezervi: izrÄdÄ«jÄs ļoti grÅ«ti salikt stendu, uz kura varÄtu paļauties uz VPP, nevis dzelzs tÄ«kla kartes veiktspÄju.
ProblÄmas un risinÄjumi
Kas tik labi nedarbojÄs? Go ir automÄtiska atmiÅas pÄrvaldÄ«ba, taÄu joprojÄm notiek atmiÅas noplÅ«des. VienkÄrÅ”Äkais veids, kÄ ar tiem tikt galÄ, ir palaist gorutÄ«nas un atcerÄties tÄs pÄrtraukt. LÄ«dzÅemÅ”anai: skatieties savu Go programmu atmiÅas patÄriÅu. Bieži vien labs rÄdÄ«tÄjs ir gorutÄ«nu skaits. Å im stÄstam ir pluss: programmÄ Go ir viegli iegÅ«t izpildlaika datus - atmiÅas patÄriÅu, palaistoÅ”o gorutÄ«nu skaitu un daudzus citus parametrus.
TurklÄt Go var nebÅ«t labÄkÄ izvÄle funkcionÄlajiem testiem. Tie ir diezgan runÄ«gi, un standarta pieeja āpalaist visu CI pa partijÄmā viÅiem nav Ä«paÅ”i piemÄrota. Fakts ir tÄds, ka funkcionÄlie testi prasa vairÄk resursu un rada reÄlus taimautu. Å Ä« iemesla dÄļ testi var neizdoties, jo CPU ir aizÅemts ar vienÄ«bu testiem. SecinÄjums: ja iespÄjams, veiciet āsmagosā testus atseviŔķi no vienÄ«bas testiem.
Mikropakalpojumu notikumu arhitektÅ«ra ir sarežģītÄka nekÄ monolÄ«ts: vÄkt žurnÄlus desmitiem dažÄdu iekÄrtu nav Ä«paÅ”i Ärti. SecinÄjums: ja veicat mikropakalpojumus, nekavÄjoties padomÄjiet par izsekoÅ”anu.
MÅ«su plÄni
MÄs izlaidÄ«sim iekÅ”Äjo balansÄtÄju, IPv6 balansÄtÄju, pievienosim atbalstu Kubernetes skriptiem, turpinÄsim sadalÄ«t savus pakalpojumus (Å”obrÄ«d ir sadalÄ«ti tikai Healthcheck-node un Healthcheck-ctrl), pievienosim jaunas veselÄ«bas pÄrbaudes, kÄ arÄ« ieviesÄ«sim viedo pÄrbaužu apkopoÅ”anu. Apsveram iespÄju padarÄ«t savus pakalpojumus vÄl neatkarÄ«gÄkus - lai tie sazinÄtos nevis tieÅ”i savÄ starpÄ, bet izmantojot ziÅojumu rindu. MÄkonÄ« nesen parÄdÄ«jÄs ar SQS saderÄ«gs pakalpojums
Nesen notika Yandex Load Balancer publiska izlaiÅ”ana. IzpÄtÄ«t
Avots: www.habr.com