Phenquestions
Laten we beginnen met een naïeve definitie van 'staatloosheid' en dan langzaam overgaan naar een meer rigoureuze en realistische kijk.
Een stateless applicatie is er een die afhankelijk is van geen permanente opslag. Het enige waar uw cluster verantwoordelijk voor is, is de code en andere statische inhoud die erop wordt gehost. Dat is alles, geen databases wijzigen, schrijven en geen overgebleven bestanden wanneer de pod wordt verwijderd.
Aan de andere kant heeft een stateful-applicatie verschillende andere parameters waar het in het cluster voor moet zorgen. Er zijn dynamische databases die, zelfs wanneer de app offline is of verwijderd is, op de schijf blijven staan. Op een gedistribueerd systeem, zoals Kubernetes, roept dit verschillende problemen op. We zullen ze in detail bekijken, maar laten we eerst enkele misvattingen ophelderen.
Staatloze diensten zijn eigenlijk niet 'staatloos'
Wat betekent het als we de toestand van een systeem zeggen?? Laten we eens kijken naar het volgende eenvoudige voorbeeld van een automatische deur:.
De deur gaat open wanneer de sensor iemand detecteert die nadert, en sluit zodra de sensor geen relevante input krijgt.
In de praktijk is uw staatloze app vergelijkbaar met dit mechanisme hierboven. Het kan veel meer toestanden hebben dan alleen gesloten of open, en ook veel verschillende soorten invoer, waardoor het complexer maar in wezen hetzelfde wordt.
Het kan gecompliceerde problemen oplossen door alleen een invoer te ontvangen en acties uit te voeren die afhankelijk zijn van zowel de invoer als de 'status' waarin deze zich bevindt. Het aantal mogelijke toestanden is vooraf gedefinieerd.
Dus staatloosheid is een verkeerde benaming.
Stateless-toepassingen kunnen in de praktijk ook een beetje vals spelen door details over bijvoorbeeld de clientsessies op de client zelf op te slaan (HTTP-cookies zijn een goed voorbeeld) en hebben nog steeds een mooie staatloosheid waardoor ze foutloos op het cluster zouden werken.
De sessiegegevens van een klant, zoals welke producten in de winkelwagen zijn opgeslagen en niet zijn uitgecheckt, kunnen bijvoorbeeld allemaal op de klant worden opgeslagen en de volgende keer dat een sessie begint, worden deze relevante details ook onthouden.
Op een Kubernetes-cluster heeft een stateless applicatie geen persistente opslag of gekoppeld volume. Vanuit operationeel oogpunt is dit geweldig nieuws. Verschillende pods in het hele cluster kunnen onafhankelijk werken met meerdere verzoeken die tegelijkertijd naar hen toekomen. Als er iets misgaat, kun je de applicatie gewoon opnieuw opstarten en zal het teruggaan naar de oorspronkelijke staat met weinig downtime.
Stateful services en de CAP-stelling
De stateful services zullen zich daarentegen zorgen moeten maken over heel veel edge-cases en rare problemen. Een pod gaat gepaard met ten minste één volume en als de gegevens in dat volume beschadigd zijn, blijft dat bestaan, zelfs als het hele cluster opnieuw wordt opgestart.
Als u bijvoorbeeld een database uitvoert op een Kubernetes-cluster, moeten alle pods een lokaal volume hebben voor het opslaan van de database. Alle gegevens moeten perfect gesynchroniseerd zijn.
Dus als iemand een invoer in de database wijzigt, en dat is gedaan op pod A, en er komt een leesverzoek op pod B om die gewijzigde gegevens te zien, dan moet pod B die laatste gegevens tonen of u een foutmelding geven. Dit staat bekend als consistentie.
Consistentie, in de context van een Kubernetes-cluster betekent: elke lezing ontvangt de meest recente schrijf- of foutmelding.
Maar dit snijdt tegen beschikbaarheid, een van de belangrijkste redenen om een gedistribueerd systeem te hebben. Beschikbaarheid houdt in dat uw applicatie zo perfect mogelijk functioneert, de klok rond, met zo min mogelijk fouten.
Je zou kunnen stellen dat je dit allemaal kunt vermijden als je slechts één gecentraliseerde database hebt die verantwoordelijk is voor het afhandelen van alle permanente opslagbehoeften. Nu hebben we weer een single point of failure, wat nog een ander probleem is dat een Kubernetes-cluster in de eerste plaats zou moeten oplossen.
U moet een gedecentraliseerde manier hebben om persistente gegevens in een cluster op te slaan. Gewoonlijk netwerkpartitionering genoemd. Bovendien moet uw cluster het uitvallen van knooppunten die de stateful-toepassing uitvoeren, kunnen overleven. Dit staat bekend als partitie tolerantie:.
Elke stateful service (of applicatie), die wordt uitgevoerd op een Kubernetes-cluster, moet een balans hebben tussen deze drie parameters. In de industrie staat het bekend als de CAP-stelling waarbij de afwegingen tussen consistentie en beschikbaarheid worden overwogen in aanwezigheid van netwerkpartitionering.
Verdere referenties
Voor meer inzicht in de CAP-stelling wil je misschien deze uitstekende lezing bekijken van Bryan Cantrill, die veel nauwkeuriger kijkt naar het draaien van gedistribueerde systemen in productie.
