Statlige vs statsløse applikasjoner på Kubernetes
La oss starte med en naiv definisjon av 'statløshet' og deretter sakte gå videre til et strengere og virkelighetssyn.
En statsløs applikasjon er en som avhenger av ingen vedvarende lagring. Det eneste klyngen din er ansvarlig for er koden, og annet statisk innhold, som blir vert på den. Det er det, ingen skiftende databaser, ingen skriver og ingen overliv filer når poden blir slettet.
En statlig applikasjon har derimot flere andre parametere den er ment å passe på i klyngen. Det er dynamiske databaser som, selv når appen er frakoblet eller slettet, vedvarer på disken. På et distribuert system, som Kubernetes, reiser dette flere problemer. Vi vil se på dem i detalj, men la oss først avklare noen misoppfatninger.
Statsløse tjenester er faktisk ikke "statsløse"
Hva betyr det når vi sier tilstanden til et system? Vel, la oss vurdere følgende enkle eksempel på en automatisk dør.
Døren åpnes når sensoren oppdager noen som nærmer seg, og den lukkes når sensoren ikke får noen relevant inngang.
I praksis er den statsløse appen din lik denne mekanismen ovenfor. Det kan ha mange flere stater enn bare lukket eller åpent, og mange forskjellige typer innspill i tillegg til å gjøre det mer sammensatt, men egentlig det samme.
Det kan løse kompliserte problemer ved bare. Antall mulige stater er forhåndsdefinert.
Så statsløshet er en feilnummer.
Stateløse applikasjoner, i praksis, kan også jukse litt ved å lagre detaljer om, for eksempel, klientøktene på klienten selv (HTTP -informasjonskapsler er et flott eksempel) og har fortsatt en fin statløshet som vil få dem til å kjøre feilfritt på klyngen.
For eksempel kan en klients sesjonsdetaljer som hvilke produkter som ble lagret i handlekurven og ikke sjekkes ut, alle lagres på klienten, og neste gang en økt begynner disse relevante detaljene blir også husket.
På en Kubernetes -klynge har en statsløs applikasjon ingen vedvarende lagring eller volum tilknyttet den. Fra et operasjonsperspektiv er dette gode nyheter. Ulike belg over hele klyngen kan jobbe uavhengig med flere forespørsler som kommer til dem samtidig. Hvis noe går galt, kan du bare starte applikasjonen på nytt, og det vil gå tilbake til starttilstanden med lite driftsstans.
Stateful Services og CAP -teorem
De statlige tjenestene, derimot, må bekymre seg for mye og masse kant-tilfeller og rare problemer. En pod er ledsaget av minst ett volum, og hvis dataene i det volumet er ødelagt, vedvarer som vedvarer selv om hele klyngen blir startet på nytt.
Hvis du for eksempel kjører en database i en Kubernetes -klynge, må alle pods ha et lokalt volum for lagring av databasen. Alle dataene må være i perfekt synkronisering.
Så hvis noen endrer en oppføring i databasen, og det ble gjort på pod a, og en leseforespørsel kommer på pod b for å se at modifiserte data, så må pod b vise at nyeste data eller gi deg en feilmelding. Dette er kjent som konsistens.
Konsistens, I sammenheng med en Kubernetes -klynge, betyr Hver lesing mottar den siste skrivingen eller en feilmelding.
Men dette kutter mot tilgjengelighet, En av de viktigste grunnene til å ha et distribuert system. Tilgjengeligheten innebærer at applikasjonen din fungerer så nær perfeksjon som mulig, døgnet rundt, med så lite feil som mulig.
Man kan hevde at du kan unngå alt dette hvis du bare har en sentralisert database som er ansvarlig for å håndtere alle vedvarende lagringsbehov. Nå er vi tilbake til å ha et enkelt feilpunkt, noe som er nok et problem som en Kubernetes -klynger skal løse i utgangspunktet.
Du må ha en desentralisert måte å lagre vedvarende data i en klynge på. Ofte referert til som nettverkspartisjonering. Dessuten må klyngen din kunne overleve svikt i noder som kjører den statlige applikasjonen. Dette er kjent som Partisjonstoleranse.
Enhver statlig tjeneste (eller applikasjon), som blir kjørt på en Kubernetes -klynge, må ha en balanse mellom disse tre parametrene. I bransjen er det kjent som CAP -teoremet der avveiningene mellom konsistens og tilgjengelighet vurderes i nærvær av nettverkspartisjonering.
Ytterligere referanser
For ytterligere innsikt i CAP -teoremet kan det være lurt å se denne utmerkede foredraget gitt av Bryan Cantrill, som tar mye nærmere titt på å kjøre distribuerte systemer i produksjon.