Phenquestions
Lad os starte med en naiv definition af 'statsløshed' og derefter langsomt udvikle os til et mere stringent og virkeligt verdensbillede.
En statsløs applikation er en, der afhænger af ingen vedvarende opbevaring. Det eneste, din klynge er ansvarlig for, er koden og andet statisk indhold, der hostes på den. Det er det, ingen skiftende databaser, ingen skrivning og ingen resterende filer, når pod'en slettes.
En stateful applikation har derimod flere andre parametre, som den skal passe på i klyngen. Der er dynamiske databaser, der, selv når appen er offline eller slettes, forbliver på disken. På et distribueret system, som Kubernetes, rejser dette flere problemer. Vi vil se nærmere på dem, men lad os først afklare nogle misforståelser.
Statsløse tjenester er faktisk ikke 'statsløse'
Hvad betyder det, når vi siger et systems tilstand? Lad os overveje følgende enkle eksempel på en automatisk dør.
Døren åbnes, når sensoren registrerer nogen, der nærmer sig, og den lukker, når sensoren ikke får noget relevant input.
I praksis ligner din statsløse app denne mekanisme ovenfor. Det kan have mange flere tilstande end bare lukket eller åben, og mange forskellige typer input gør det også mere komplekst, men stort set det samme.
Det kan løse komplicerede problemer ved blot at modtage et input og udføre handlinger, der afhænger af både input og 'tilstand', det er i. Antallet af mulige tilstande er foruddefineret.
Så statsløshed er en misvisende betegnelse.
Statsløse applikationer kan i praksis også snyde lidt ved at gemme detaljer om f.eks. Klientsessioner på selve klienten (HTTP-cookies er et godt eksempel) og stadig have en dejlig statsløshed, der får dem til at køre fejlfrit på klyngen.
For eksempel kan en klients sessionsoplysninger, som hvilke produkter der blev gemt i indkøbskurven og ikke tjekket ud, alle gemmes på klienten, og næste gang en session begynder, genkendes disse relevante detaljer også.
På en Kubernetes-klynge har en statsløs applikation ingen vedvarende lagring eller volumen forbundet med den. Fra et operationelt perspektiv er dette gode nyheder. Forskellige bælg overalt i klyngen kan arbejde uafhængigt med flere anmodninger, der kommer til dem samtidigt. Hvis noget går galt, kan du bare genstarte applikationen, og den vender tilbage til den oprindelige tilstand med lidt nedetid.
Statefulde tjenester og CAP-sætningen
De statefulde tjenester skal derimod bekymre sig om masser af kant-sager og underlige problemer. En pod ledsages af mindst en diskenhed, og hvis dataene i denne diskenhed er beskadiget, fortsætter den, selvom hele klyngen genstartes.
Hvis du f.eks. Kører en database på en Kubernetes-klynge, skal alle bælgene have en lokal lydstyrke til lagring af databasen. Alle data skal være i perfekt synkronisering.
Så hvis nogen ændrer en post i databasen, og det blev gjort på pod A, og der kommer en læseanmodning på pod B for at se de modificerede data, skal pod B vise de nyeste data eller give dig en fejlmeddelelse. Dette er kendt som konsistens.
Konsistens, i sammenhæng med en Kubernetes-klynge, betyder hver læsning modtager den seneste skrivning eller en fejlmeddelelse.
Men dette skærer imod tilgængelighed, en af de vigtigste grunde til at have et distribueret system. Tilgængelighed betyder, at din applikation fungerer så tæt på perfektion som muligt døgnet rundt med så lidt fejl som muligt.
Man kan argumentere for, at du kan undgå alt dette, hvis du kun har en central database, der er ansvarlig for at håndtere alle de vedvarende lagerbehov. Nu er vi tilbage til at have et enkelt fejlpunkt, hvilket er endnu et problem, som en Kubernetes-klynger skulle løse i første omgang.
Du skal have en decentral måde at lagre vedvarende data i en klynge på. Almindeligvis benævnt netværkspartitionering. Desuden skal din klynge være i stand til at overleve svigt af noder, der kører den statefulde applikation. Dette er kendt som partitionstolerance.
Enhver stateful service (eller applikation), der køres på en Kubernetes-klynge, skal have en balance mellem disse tre parametre. I branchen er det kendt som CAP-sætningen, hvor afvejninger mellem konsistens og tilgængelighed betragtes i nærvær af netværkspartitionering.
Yderligere referencer
For yderligere indsigt i CAP-sætningen vil du måske se denne fremragende tale holdt af Bryan Cantrill, der ser meget nærmere på at køre distribuerede systemer i produktionen.
