etcd komanda 8. jūlijā izlaida versiju 3.7.0 — pirmo lielo laidienu kopš 3.6. Galvenais jaunums ir RangeStream: jauns RPC, kas lielus nolasīšanas rezultātus atdod pa daļām, nevis vispirms sabāž visu atbildi atmiņā.
etcd ir izkliedētā atslēgu–vērtību datubāze, kurā Kubernetes tur visu klastera stāvokli. Tā ir CNCF projekts un noklusējuma glabātuve gandrīz katrā Kubernetes klasterī, tāpēc etcd veiktspēja tieši nosaka, cik lielu klasteri vispār var vadīt. Līdz šim, nolasot tūkstošiem objektu vienā vaicājumā, etcd savāca pilnu rezultātu atmiņā un tikai tad sāka to sūtīt. Uz lieliem klasteriem tas deva neparedzamu aizturi un atmiņas lēcienus abās pusēs — gan serverī, gan klientā.
Problēma izpaužas tieši lielos klasteros. Kubernetes API serveris regulāri prasa etcd atdot veselu objektu kolekciju — visus podus namespace, visus secrets, visus notikumus. Jo vairāk objektu, jo lielāks vienreizējais atmiņas piķis. Sliktākais scenārijs ir tā sauktā relist vētra: pēc tīkla pārrāvuma desmitiem watch klientu vienlaikus prasa pilnu sarakstu no jauna, un etcd tos visus mēģina buferēt reizē. Tieši šādos brīžos mezgls var aizrīties ar atmiņu un novilkt lejā visu klasteri.
Ko maina RangeStream
RangeStream sadala atbildi gabalos un straumē tos klientam pakāpeniski. Serverim vairs nav jātur viss rezultāts atmiņā vienlaikus, tāpēc atmiņas patēriņš kļūst prognozējams, un pirmie dati klientu sasniedz ātrāk. Funkcija nāk no Kubernetes uzlabojuma priekšlikuma KEP-5966, ko izstrādāja SIG etcd darba grupa.
Pašā etcd RangeStream ir pieejams uzreiz caur gRPC un etcdctl. Kubernetes pusē tas ieslēdzas atsevišķi: gaidāmajā versijā 1.37 to iedarbina ar EtcdRangeStream funkcijas vārtiem. Ieguvumu tātad vispirms sajutīs tie, kas jaunina abus komponentus saskaņoti.
Jaunais RPC neko nelauž. Vecie klienti turpina lietot parasto Range vaicājumu un strādā kā līdz šim, bet straumēto ceļu izmanto tikai tie, kas to tieši pieprasa. Tāpēc uz etcd 3.7.0 var pāriet, neko nemainot lietojumos, un straumēšanu ieslēgt vēlāk.
Keys-only vaicājumi lasa tikai no atmiņas
Otrs praktisks uzlabojums skar vaicājumus, kuriem vajag tikai atslēgu nosaukumus, ne vērtības. etcd tos tagad apkalpo tieši no atmiņā glabātā indeksa un vairs neiet uz bbolt disku aizmugurē. Tas mazina lieku disku lasīšanu un atmiņas patēriņu darbam ar lielu atslēgu sarakstu. Tādi vaicājumi Kubernetes vidē nav reti — piemēram, kad kontrolieris pārbauda, kuras atslēgas ar konkrētu prefiksu vispār pastāv. Izņēmums paliek viens: ja rezultātu kārto pēc vērtības, dati joprojām jāielādē no bbolt.
Ātrākas nomas, mazāk CPU
etcd 3.7.0 pārstrādā arī nomu (lease) apstrādi. Nomas Kubernetes vidē notur mezglu sirdspukstus un objektu TTL, tāpēc to ātrums ietekmē, cik raiti klasteris pamana mirušu mezglu. FastLeaseKeepAlive paātrina nomas atjaunošanu, izlaižot gaidīšanu uz applied index, bet pārslodzes brīžos priekšroka tiek dota LeaseRevoke, lai nomas laikus izbeidzas. Klāt nāk ātrāka find() operācija, kas uzlabo vairāku vienlaicīgu watch pieprasījumu veiktspēju.
Kubernetes lietotājiem vajadzētu novērot jūtami zemāku etcd mezglu CPU patēriņu salīdzinājumā ar 3.6.
Precīzus skaitļus laidiena piezīmes nedod, tāpēc reālais ieguvums būs jāmēra katram klasterim atsevišķi. Virziens tomēr ir skaidrs: mazāk lieka darba uz katru vaicājumu.
Vecā v2 glabātuve izmesta
v2store bija etcd sākotnējais datu modelis vēl no 2.x laikiem. Kad ieradās v3 ar mvcc glabātuvi, v2 daļa palika tikai dažām mantotām funkcijām, galvenokārt sāknēšanas discovery. etcd 3.7.0 to slēdz ciet: serveris tagad pilnībā sāknējas no v3 glabātuves. No koda izņemts v2 discovery, v2 sāknēšanas kods, v2 pieprasījumu apstrāde un v2 klienta bibliotēka, kā arī vairāki novecojuši eksperimentālie karogi. Paralēli pabeigta novecojušo protobuf bibliotēku nomaiņa uz uzturētām versijām. Atkarībās atjaunināti divi etcd stūrakmeņi — bbolt 1.5.0 un raft 3.7.0.
Laidiens nenāca pēkšņi. Beta versija parādījās 20. maijā, tai sekoja release candidate testēšanai, un galīgā 3.7.0 iznāca 8. jūlijā. Kas grib pārbaudīt savu slodzi pirms produkcijas, var sākt ar publicētajām binārajām versijām GitHubā.
Ko ņemt vērā, jauninot
Versija 3.4 sasniedza dzīves cikla beigas 15. maijā, un 3.5 saņems labojumus vēl gadu pēc 3.7.0 galīgā laidiena. etcd uzturēšanā tur tikai divas jaunākās minor versijas, tāpēc, paliekot uz 3.5, atbalsta logs ir ierobežots. Kas gatavojas pāriet uz 3.7, tam vispirms jāpārbauda, vai konfigurācija neizmanto kādu no izmestajiem v2 karogiem vai discovery mehānismu — tie klusi nepazudīs, un serveris ar tiem vairs nestartēs.
Kubernetes administratoriem svarīgākais solis paliek RangeStream ieslēgšana. Bez EtcdRangeStream vārtiem 1.37 klasteris strādās kā agrāk, tikai ar zemāku bāzes CPU slodzi no pašas etcd 3.7.0.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.