Phenquestions
Začnimo z naivno definicijo "apatridnosti" in nato počasi napredujemo do bolj strogega in resničnega pogleda.
Aplikacija brez državljanstva je tista, ki ni odvisna od trajnega shranjevanja. Edina stvar, za katero je odgovorna vaša grozd, je koda in druga statična vsebina, ki jo gosti. To je to, brez spreminjanja baz podatkov, brez pisanja in brez preostalih datotek, ko je pod izbrisan.
Aplikacija s stanjem pa ima več drugih parametrov, za katere naj bi skrbela v gruči. Obstajajo dinamične zbirke podatkov, ki tudi na disku ostanejo nespremenjene ali izbrisane. V porazdeljenem sistemu, kot je Kubernetes, to odpira več vprašanj. Podrobno si jih bomo ogledali, najprej pa razjasnimo nekaj napačnih predstav.
Storitve brez državljanstva pravzaprav niso „osebe brez državljanstva“
Kaj pomeni, ko rečemo stanje sistema? No, razmislimo o naslednjem preprostem primeru samodejnih vrat.
Vrata se odprejo, ko senzor zazna nekoga, ki se približuje, in se zapre, ko senzor ne dobi ustreznega vhoda.
V praksi je aplikacija brez državljanstva podobna zgornjemu mehanizmu. Lahko ima veliko več stanj kot samo zaprto ali odprto in veliko različnih vrst vhodnih podatkov, zaradi česar je bolj zapleten, a v bistvu enak.
Zapletene težave lahko reši tako, da samo prejme vhod in izvede dejanja, ki so odvisna tako od vnosa kot od stanja, v katerem je. Število možnih stanj je vnaprej določeno.
Državljanstvo je torej napačno poimenovanje.
Aplikacije brez državljanstva lahko v praksi tudi malo varajo, tako da na samem odjemalcu shranijo podrobnosti o recimo odjemalčevih sejah (odličen primer so piškotki HTTP) in imajo kljub temu lepo brez državljanstva, zaradi česar bi lahko brezhibno delovale na gruči.
Na primer, podrobnosti odjemalske seje, na primer izdelki, ki so bili shranjeni v košarici in niso odjavljeni, se lahko vse shranijo v odjemalcu in naslednjič, ko se seja začne, se tudi spomnijo teh pomembnih podrobnosti.
V gruči Kubernetes aplikacija brez državljanstva ni povezana s trajnim pomnilnikom ali nosilcem. Z operativnega vidika je to odlična novica. Različni stroki v celotni gruči lahko delujejo neodvisno, hkrati pa jim prihaja več zahtev. Če gre kaj narobe, lahko preprosto znova zaženete aplikacijo in se bo vrnila v začetno stanje z majhnimi zastoji.
Storitve s stanjem in izrek CAP
Po drugi strani pa bodo državne službe morale skrbeti za veliko in veliko izjemnih primerov in čudnih vprašanj. Pod je priložen vsaj en zvezek in če so podatki v tem nosilcu poškodovani, to traja, tudi če se celotna grozd znova zažene.
Če na primer izvajate bazo podatkov v gruči Kubernetes, morajo imeti vsi stroji lokalni nosilec za shranjevanje baze podatkov. Vsi podatki se morajo popolnoma sinhronizirati.
Torej, če nekdo spremeni vnos v bazo podatkov, in to je bilo storjeno na pod A, in na pod B pride zahteva za branje, da vidi te spremenjene podatke, potem mora pod B prikazati te najnovejše podatke ali vam poslati sporočilo o napaki. To je znano kot doslednost.
Doslednost, v okviru grozda Kubernetes pomeni vsako branje prejme zadnji zapis ali sporočilo o napaki.
Toda to zmanjšuje razpoložljivost, eden najpomembnejših razlogov za porazdeljen sistem. Razpoložljivost pomeni, da vaša aplikacija deluje čim bližje popolnosti, in sicer neprekinjeno, neprekinjeno, s čim manj napak.
Lahko se trdi, da se lahko vsemu temu izognete, če imate samo eno centralizirano bazo podatkov, ki je odgovorna za obravnavo vseh stalnih potreb po pomnilniku. Zdaj smo spet na eni točki okvare, kar je še ena težava, ki naj bi jo najprej rešili grozdi Kubernetes.
Imeti morate decentraliziran način shranjevanja trajnih podatkov v gruči. Običajno se imenuje omrežna particija. Poleg tega mora biti vaša grozda sposobna preživeti neuspeh vozlišč, ki izvajajo aplikacijo s stanjem. To je znano kot toleranca particije.
Vsaka storitev (ali aplikacija) s stanjem, ki se izvaja v gruči Kubernetes, mora imeti ravnovesje med temi tremi parametri. V industriji je znan kot izrek CAP, kjer se upoštevajo kompromisi med skladnostjo in razpoložljivostjo ob prisotnosti mrežnega razdeljevanja.
Nadaljnje reference
Za nadaljnji vpogled v izrek CAP si boste morda želeli ogledati ta odličen pogovor Bryana Cantrilla, ki veliko podrobneje preuči delovanje porazdeljenih sistemov v proizvodnji.
