Stateful workloads in Kubernetes: wat hosting écht lastig maakt

Kubernetes is ontworpen voor stateless applicaties. Om een binnenkomend verzoek te verwerken, start en draait een pod die daarna weer verdwijnt. Valt de pod uit, dan start het platform gewoon een verse kopie die het verzoek alsnog afhandelt. Dat werkt uitstekend voor workloads die geen bewaarde gegevens nodig hebben. Maar wat als dat wel het geval is? Kubernetes kan met stateful workloads werken, maar dat brengt wel uitdagingen met zich mee. Ontdek hier waar die complexiteit vandaan komt en welke hostingkeuzes beheer makkelijker maken.

Wat is het verschil tussen stateless en stateful workloads?

Een taak (of set van taken) die een systeem uitvoert, ook wel bekend als een workload, kan stateless of stateful zijn. Stateless workloads bewaren geen data tussen requests. Met dit soort workloads levert een webserver HTML-pagina’s aan, verwerkt een API binnenkomende verzoeken en valideert een authenticatieservice tokens. Als Kubernetes stateless workloads uitvoert, maakt het niet uit welke pod ze afhandelt. Het systeem kan dit soort workloads vrij starten, stoppen en verplaatsen.

Een stateful workload maakt gebruik van bewaarde gegevens. Stateful workloads gebruik je onder meer om bestellingen in een winkelwagen te bewaren, een ingelogde gebruiker te volgen of zoekresultaten te indexeren. Om de state bij te houden heb je schrijf- en leestoegang nodig naar opslag; ook als je met pods werkt die herstart of verplaatst worden. Een pod met een stateful workload is niet zo uitwisselbaar als een pod met stateless workload omdat de onderliggende data gebonden zijn aan die specifieke workload.

Dit ogenschijnlijk kleine verschil heeft grote gevolgen voor hoe je opslag, back-ups en herstel binnen Kubernetes inricht.

Kan Kubernetes werken met stateful workloads?

Dat Kubernetes ontworpen is voor stateless workloads betekent niet dat het geen stateful workloads aankan. Het vereist wel wat extra werk. Bij stateful workloads is opslag de kern in plaats van een bijzaak. Kubernetes slaat data op via Persistent Volumes (PV's) en Persistent Volume Claims (PVC's). Een pod verzoekt om een bepaalde hoeveelheid opslag via een PVC. Kubernetes koppelt dat verzoek aan een PV. Hiermee reserveert het een stuk opslag dat losstaat van de levenscyclus van de pod.

Wat is er complex aan stateful opslag voor pods?

Om opslag te reserveren die losstaat van de levenscyclus van een pod moet je drie dingen juist configureren: netwerkopslag, storage class en actief opslagbeheer. Netwerkopslag houdt de data beschikbaar als Kubernetes een pod verplaatst of herstart. De juiste storage class zorgt dat een PVC niet blijft wachten en de pod daarom niet start. Actief opslagbeheer voorkomt dat ongebruikte opslag van pods blijft rondslingeren.

Netwerkopslag

Als Kubernetes een stateful pod naar een andere node wil verplaatsen is er een probleem. De PVC van een pod is in de meeste omgevingen gebonden aan één node. Bij verplaatsing zou de pod daarom zijn state verliezen. Om dit te voorkomen moet Kubernetes netwerkopslag gebruiken. De pod kan na verplaatsing dan via de netwerkopslag zijn PVC benaderen.

Storage Class

Het benaderen van de netwerkopslag gaat mis als de storage class niet goed gedefinieerd is. Heeft de PVC geen storage class, of een storage class die in jouw hostingomgeving niet beschikbaar is, dan weet Kubernetes niet welke opslag hij moet inzetten. De PVC blijft dan op pending staan en de pod start niet. Sluit de storage class niet aan bij de workload, spreek je bijvoorbeeld trage netwerkopslag aan voor een database die snelle schijftoegang nodig heeft, dan start de pod wel, maar zijn de prestaties onacceptabel.

Actief opslagbeheer

Bij stateful workloads heeft iedere pod bewust een eigen PVC. Je wilt namelijk niet dat de data van pod-0 ook gekoppeld zijn aan pod-1 (om maar een voorbeeld te noemen). Kubernetes beheert de koppeling tussen PVC’s en pods, maar verwijdert de PVC niet automatisch als de stateful workload is afgehandeld. Dat voorkomt dataverlies, maar vraagt om actief opslagbeheer. Regel je dit niet, dan vult jouw opslagruimte zich met ongebruikte PVC’s.

StatefulSets

Kubernetes brengt netwerkopslag, storage class en actief opslagbeheer samen tot een StatefulSet. Dit is een Kubernetes-object dat de uitrol en het beheer van stateful workloads beschrijft. Het geeft elke pod een stabiele, voorspelbare naam, een eigen PVC en legt vast in welke volgorde het pods start en stopt. Zo weet Kubernetes altijd welke opslag bij welke pod hoort en voorkomt het dat data van de ene pod worden gekoppeld aan een andere.

Werken met StatefulSets

Via StatefulSets voert Kubernetes applicaties met stateful workloads uit. Omdat pods hier niet onderling uitwisselbaar zijn (zoals bij een Deployment van stateless workloads), krijgt iedere pod een stabiele, voorspelbare naam (pod-0, pod-1, pod-2) en een eigen PVC. Daarmee blijft ook bij herstarts en herplanningen de identiteit behouden.

Pods in een vaste volgorde starten en stoppen

StatefulSets starten en stoppen pods in een vaste volgorde. Dat is belangrijk voor applicaties zoals databases die een primary-replica-relatie onderhouden. In dat soort cases is pod-0 de primary en zijn pod-1 en pod-2 replica's die pas starten nadat de vorige pod gereed is. Kubernetes garandeert dat de primary beschikbaar is voordat de replica's verbinding maken en houdt zo de replicatie consistent.

Opslag afstemmen op ketenafhankelijkheid

De vaste opstartvolgorde creëert een ketenafhankelijkheid. Start pod-0 niet (omdat er geen opslag beschikbaar is), dan starten pod-1 en pod-2 ook niet. De opslaglaag moet daarom aan drie voorwaarden voldoen.

Beschikbaar zijn: De netwerkopslag moet beschikbaar zijn op het moment dat Kubernetes een pod inplant. Is de opslaglaag tijdelijk niet bereikbaar, dan blijft de pod in een pending-staat wachten en blokkeert hij de keten.
Snel zijn: Kubernetes bewaakt de gezondheid van pods via health checks. Als een pod te lang over initialisatie doet, beschouwt Kubernetes hem als ongezond en herstart hij hem. Ligt de fout bij trage opslag, dan herhaalt dit probleem zich wat leidt tot een crashloop. De volgende pod zal net zo traag zijn en ook herstart worden en ga zo maar door.
Consistent blijven: Als een pod herstart, moet hij zijn vorige staat kunnen hervatten via zijn PVC. Is die PVC beschadigd of inconsistent, dan start de pod wel, maar crasht hij direct. Als de opslag de data niet consistent weet te houden, ontstaat er een crashloop.

Met een snelle en betrouwbare opslaglaag voorkom je dat pods blijven hangen in een pending of crashloop-staat en zorg je voor een soepele afhandeling van je StatefulSets.

Waarom back-ups en herstel complexer zijn bij StatefulSets

Stateful workloads gebruiken gegevens die niet verloren mogen gaan. Bij stateless applicaties is dit niet aan de orde. Gaat er bij een Deployment iets goed mis, dan herstel je de omgeving met een back-up van de configuratie. Bij StatefulSets moet je ook de data zelf beschermen. Dat is lastiger dan het lijkt.

Consistente back-ups zijn geen vanzelfsprekendheid

Een back-up van een draaiende database is alleen bruikbaar als alle data op het moment van de snapshot consistent zijn. Dat is zelden het geval als je een bestandskopie van een actieve databaseschijf maakt. Voor een betrouwbare snapshot heb je applicatiebewuste back-upmechanismen nodig. Die brengen de database eerst in een consistente staat en maken dan een snapshot.

De juiste tooling voor database back-ups kies je zelf

Kubernetes biedt geen generieke oplossing die database back-ups voor je regelt. Elke database heeft zijn eigen aanpak. PostgreSQL heeft pg_dump of pgBackRest, MySQL heeft xtrabackup en ook Kafka en Elasticsearch hebben een eigen back-upstrategie. Afhankelijk van de database die je gebruikt, kies je zelf de juiste tooling en ben je verantwoordelijk voor de configuratie en het onderhoud daarvan.

Een back-up zonder herstel is geen back-up

Een back-up is pas een back-up als je ook het herstel getest hebt. Bij stateful workloads in Kubernetes betekent herstel: een nieuwe PVC aanmaken, data terugzetten, de pod opnieuw starten en controleren of de applicatie de herstelde data correct oppakt. Dat proces is omgeving- en applicatiespecifiek. Zorg dat je het vooraf test, anders ontdek je de tekortkomingen op het slechtst mogelijke moment: als het te laat is om een nieuwe back-up te maken.

Waar hosting het verschil maakt

Hoe soepel stateful workloads in Kubernetes draaien, is een goede test van de kwaliteit van jouw host.  De onderliggende infrastructuur moet helemaal op orde zijn.  Opslag, back-ups en monitoring stellen hoge eisen aan de hostingomgeving.

Snelle opslag is geen luxe

Databases en message brokers zijn latencygevoelig. Trage opslag vertaalt zich direct in slechte prestaties of crashloops door falende health checks. NVMe-gebaseerde block storage is geen luxe, maar een basisvereiste voor stateful workloads. De lage latency voorkomt dat de opslaglaag een bottleneck vormt of tot problemen leidt.

Back-upinfrastructuur hoort bij de omgeving

Back-ups zijn geen optionele extra, maar een noodzakelijk onderdeel van de infrastructuur. Object storage is uitermate geschikt voor back-updoeleinden: de data groeien mee met het datavolume, zijn via een API te benaderen en staan los van de Kubernetes-omgeving zelf. Back-ups zijn altijd beschikbaar, ook als de omgeving zelf problemen heeft.

Monitor niet alleen op gebruik, maar ook op contention

Monitoren op contention is minstens zo belangrijk als het gebruik in de gaten houden. Contention ontstaat als meerdere pods tegelijk aanspraak maken op dezelfde opslagcapaciteit. Dat is niet altijd zichtbaar als een harde fout. Daar komt bij dat stateful workloads minder duidelijke signalen geven dan stateless applicaties. Als je ook op PVC-gebruik, IOPS en opslaglatency monitort, zie je problemen ontstaan voordat ze tot instabiliteit leiden.

Wil jij stateful workloads draaien in Kubernetes?

Stateful workloads in Kubernetes zijn niet onmogelijk. Ze vragen meer van jouw Kubernetes-omgeving dan stateless applicaties. Opslag, back-ups en herstel vereisen een doordachte aanpak en een infrastructuur die daarbij aansluit. De juiste hostingkeuze maakt het verschil tussen een omgeving die je vertrouwt en één die je 's nachts wakker houdt.

Wil jij lekker slapen terwijl jouw clusters en nodes voor je werken? Kijk hier naar de mogelijkheden die onze Managed Kubernetes-omgeving jou biedt. Heb je vragen over de mogelijkheden? Neem contact op! Wij denken graag met je mee.