etcd 3.7.0 sāka sūtīt lielus vaicājumu rezultātus pa gabaliem. Līdz šim datubāze sabuferēja visu atbildi pilnībā, pirms to nosūtīja klientam. Jauno RangeStream izsaukumu izlaida 8. jūlijā kopā ar visu 3.7.0 laidienu.
etcd ir sadalīta atslēgu un vērtību datubāze, uz kuras balstās katrs Kubernetes klasteris. Tur glabājas viss klastera stāvoklis: podi, servisi, konfigurācija un noslēpumi. Kad Kubernetes API serveris vaicā pēc visiem podiem, tas vaicājums aiziet uz etcd. Lielā klasterī viena tāda atbilde var būt desmitiem tūkstošu ierakstu.
Kāpēc buferēšana bija problēma
Vecajā shēmā etcd visu atbildi sagatavoja atmiņā, pirms sāka to sūtīt. Lielam vaicājumam tas nozīmēja divas nepatikšanas. Klients gaidīja, kamēr serveris savāc pilnu kopu, tāpēc aizture lēca augšup neparedzami. Serveris tikmēr turēja visu kopu atmiņā, tāpēc atmiņas patēriņš auga līdz ar rezultāta izmēru.
RangeStream šo maina. Lietotne saņem rezultātu pa daļām, tāpēc tā var sākt apstrādi jau pirms pienākusi visa atbilde. Aizture kļūst mazāka. Serverim vairs nav jātur visa kopa atmiņā vienlaikus.
Šī problēma parādās skaidri pēc API servera pārstartēšanas. Tad tam vajag no jauna izlasīt visu attiecīgo objektu sarakstu, lai atjaunotu savu iekšējo kešatmiņu. Lielā klasterī tāds sākotnējais lasījums var pieprasīt megabaitiem lielu atbildi vienā gabalā. Ar RangeStream tas pats lasījums plūst pa daļām, tāpēc gan API serveris, gan etcd tiek galā ar mazāku atmiņas maksimumu.
Kubernetes to saņems ar 1.37
Pati etcd funkcija ir klāt jau tagad, bet Kubernetes to neizmantos uzreiz. Funkcija būs pieejama nākamajā Kubernetes versijā 1.37. To ieslēgs ar funkciju iezīmi EtcdRangeStream. Līdz tam lielo vaicājumu uzvedība paliks tāda pati kā līdz šim.
Ieguvumu vispirms sajutīs tie klasteri, kur objektu skaits ir liels: simtiem mezglu, tūkstošiem podu vai daudz pielāgotu resursu. Mazam klasterim ar dažiem desmitiem objektu starpība būs grūti pamanāma. Lielam klasterim tieši šie masveida lasījumi bieži ir slodzes virsotnes brīži.
Atslēgu vaicājumi lasa tikai no atmiņas
Otrs uzlabojums skar vaicājumus, kuriem vajag tikai atslēgu nosaukumus. Komanda etcdctl get --keys-only tagad lasa tikai no atmiņā glabātā indeksa. Iepriekš etcd šādā gadījumā tik un tā ielādēja serializētās vērtības no bbolt diskā, kaut vērtības neviens neprasīja.
Izmaiņa (labojums numur 21791) samazina liekus lasījumus un atmiņas patēriņu tām slodzēm, kurām vajag tikai atslēgas. Viens izņēmums paliek. Ja atslēgu vaicājumu kārto pēc vērtības, etcd joprojām ielādē vērtības no bbolt, jo citādi kārtot nav pēc kā.
Vecā v2 krātuve beidzot prom
etcd 3.7.0 startē pilnībā no v3 krātuves. Tas ir pirmais laidiens, kas simtprocentīgi atteicies no vecās v2 krātuves. Prom ir v2 atklāšana, sāknēšana, v2 pieprasījumi un v2 klients.
Vecā krātuve etcd kodā vilkās gadiem, jo daži sāknēšanas ceļi to vēl izmantoja. Tagad tā ir aizvākta pilnībā. Vienas krātuves kods ir vieglāk uzturams. Divu paralēlu ceļu vietā etcd tagad iet pa vienu, tāpēc paliek mazāk vietu, kur ieviesties kļūdai vai neatbilstībai starp stāvokļiem. Līdztekus komanda pabeidza protobuf pārstrādi un nomainīja novecojušās protobuf bibliotēkas pret uzturētām. Vecās bibliotēkas augšupējie uzturētāji vairs neatbalstīja, tāpēc to nomaiņa noņem drošības un savietojamības risku ilgtermiņā. Laidiens atjaunina arī divas etcd pamatatkarības: bbolt uz versiju 1.5.0 un raft uz 3.7.0.
Abas atkarības ir etcd pamatā. bbolt ir iegultā atslēgu un vērtību glabātuve, kas raksta datus diskā. raft ir vienprātības algoritms, kas nodrošina, lai visi klastera mezgli vienojas par vienu un to pašu datu secību. To atjaunināšana nozīmē, ka etcd saņem jaunākos šo divu komponentu labojumus tieši laidiena sastāvā.
Laidiens nenāca pēkšņi. Komanda vispirms izlaida beta versiju maijā, pēc tam izlaišanas kandidātu, tad stabilo 3.7.0. Katrā solī tika pārbaudīts, vai v2 krātuves aizvākšana nesabojā sāknēšanu esošajām instalācijām.
Kubernetes lietotājiem pēc pārejas uz 3.7.0 vajadzētu redzēt jūtami mazāku etcd mezglu procesora slodzi salīdzinājumā ar 3.6.
Ātrāka nomas apstrāde un ko darīt tālāk
Nomas (lease) apstrāde kļuva ātrāka un drošāka. Labojums numur 20492 dod priekšroku nomas atsaukšanas pieprasījumiem, lai tie paspētu izbeigties arī pārslodzes brīdī. Tas ir svarīgi tāpēc, ka Kubernetes izmanto nomas objektu dzīves cikla un mezglu veselības uzskaitei. Ja noma neizbeidzas laikā, klasteris var uzskatīt mirušu mezglu par dzīvu.
Pirms jaunināšanas ir vērts izveidot etcd momentuzņēmumu ar etcdctl snapshot save. Administratoriem, kas uztur pašu etcd, galvenais ieguvums ir procesora slodzes kritums. Tiem, kas etcd redz tikai caur pārvaldītu Kubernetes, izmaiņas atnāks pakāpeniski, sākot ar 1.37 versiju un tās RangeStream iezīmi. Jauninot ir vērts pārbaudīt, vai neviens pašrocīgs rīks vēl neizmanto v2 API, jo pēc 3.7.0 tas vairs neatbildēs. Pilnu izmaiņu sarakstu komanda publicēja laidiena piezīmēs, tāpēc pirms jaunināšanas produkcijā tās ir vērts izlasīt no sākuma līdz beigām.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.