Phenquestions
Låt oss börja med en naiv definition av "statslöshet" och sedan långsamt gå vidare till en mer rigorös och verklig syn.
En statslös applikation är en som är beroende av ingen beständig lagring. Det enda som ditt kluster ansvarar för är koden och annat statiskt innehåll som är värd för den. Det är det, inga databaser som ändras, inga skrivningar och inga kvarvarande filer när poden raderas.
En statlig applikation har å andra sidan flera andra parametrar som den ska ta hand om i klustret. Det finns dynamiska databaser som, även när appen är offline eller raderad, finns kvar på disken. På ett distribuerat system, som Kubernetes, väcker detta flera problem. Vi kommer att titta på dem i detalj, men låt oss först klargöra några missuppfattningar.
Statslösa tjänster är faktiskt inte 'statslösa'
Vad betyder det när vi säger tillståndet i ett system? Låt oss överväga följande enkla exempel på en automatisk dörr.
Dörren öppnas när sensorn upptäcker att någon närmar sig och den stängs när sensorn inte får någon relevant ingång.
I praktiken liknar din statslösa app den här mekanismen ovan. Det kan ha många fler tillstånd än bara stängt eller öppet, och många olika typer av ingångar gör det också mer komplext men i huvudsak detsamma.
Det kan lösa komplicerade problem genom att bara ta emot en inmatning och utföra åtgärder som beror på både ingången och "tillståndet" den är i. Antalet möjliga tillstånd är fördefinierade.
Så statslöshet är en felaktig benämning.
Statslösa applikationer kan i praktiken också fuska lite genom att spara information om, till exempel, klientsessionerna på klienten själv (HTTP-kakor är ett bra exempel) och ändå ha en fin statslöshet som skulle få dem att köra felfritt på klustret.
Till exempel kan en klients sessionsinformation som vilka produkter som sparades i kundvagnen och inte checkas ut alla lagras på klienten och nästa gång en session börjar kommer dessa relevanta detaljer också att återkallas.
På ett Kubernetes-kluster har en statslös applikation ingen ihållande lagring eller volym associerad med den. Ur ett verksamhetsperspektiv är det bra nyheter. Olika pods över hela klustret kan fungera oberoende med flera förfrågningar som kommer till dem samtidigt. Om något går fel kan du bara starta om programmet så går det tillbaka till det ursprungliga tillståndet med lite stillestånd.
Stateful-tjänster och CAP-satsen
De statliga tjänsterna kommer å andra sidan att behöva oroa sig för massor av kantärenden och konstiga problem. En pod åtföljs av åtminstone en volym och om data i den volymen är skadad fortsätter det även om hela klustret startas om.
Om du till exempel kör en databas i ett Kubernetes-kluster, måste alla pods ha en lokal volym för att lagra databasen. All data måste vara perfekt synkroniserad.
Så om någon ändrar en post till databasen, och det gjordes på pod A, och en läsförfrågan kommer på pod B för att se de modifierade data, måste pod B visa de senaste uppgifterna eller ge dig ett felmeddelande. Detta kallas konsistens.
Konsistens, i samband med ett Kubernetes-kluster, betyder varje läsning får det senaste skriv- eller felmeddelandet.
Men detta skär mot tillgänglighet, en av de viktigaste anledningarna till att ha ett distribuerat system. Tillgänglighet innebär att din applikation fungerar så nära perfekt som möjligt dygnet runt, med så lite fel som möjligt.
Man kan argumentera för att du kan undvika allt detta om du bara har en central databas som är ansvarig för att hantera alla bestående lagringsbehov. Nu är vi tillbaka till en enda misslyckande punkt, vilket är ytterligare ett problem som en Kubernetes-kluster ska lösa i första hand.
Du måste ha ett decentraliserat sätt att lagra ihållande data i ett kluster. Vanligtvis kallad nätverkspartitionering. Dessutom måste ditt kluster kunna överleva misslyckandet med noder som kör den stateful-applikationen. Detta kallas partitionstolerans.
Alla stateful-tjänster (eller applikationer), som körs på ett Kubernetes-kluster, måste ha en balans mellan dessa tre parametrar. I branschen är det känt som CAP-teorem där avvägningar mellan konsekvens och tillgänglighet betraktas i närvaro av nätverkspartitionering.
Ytterligare referenser
För ytterligare insikt i CAP-satsen kan du se detta utmärkta föredrag av Bryan Cantrill, som tittar mycket närmare på att köra distribuerade system i produktion.
