Statusbeheer in Kubernetes begrijpen
Wanneer u het over toepassingen in het algemeen hebt, hoort u mogelijk vaak over de toepassingsstatus. In deze les bekijken we de definitie van de status en de verschillende typen statussen, zodat u uw toepassing beter kunt voorbereiden voor de verwerking ervan.
Staat
De status van de toepassing is alles wat in het geheugen wordt opgeslagen op het moment dat de toepassing wordt uitgevoerd. De status kan betrekking hebben op verschillende dingen, maar we richten ons voornamelijk op de gebruikersgegevens.
Als u een voorbeeld van de toepassingsstatus wilt geven, stelt u zich voor dat u een muziekspeler hebt geopend. Deze toepassing heeft een status. Het weet wie je bent, wat je graag hoort en welke muziek je hebt gedownload. Al deze informatie maakt deel uit van de toepassingsstatus.
De in-memory status is de informatie die de toepassing nergens anders hoeft te zoeken. De schijfstatus bevat de informatie die de toepassing niet bij de hand heeft, dus moet deze worden opgehaald uit een andere gegevensbron.
Typen staten
Er zijn twee typen toepassingsstatussen. Het eerste type is de tijdelijke status, die niet permanent is en verdwijnt zodra de toepassing is gesloten.
Containers hebben een tijdelijke status. Alle gegevens die erin zijn opgeslagen, gaan direct verloren wanneer de container wordt verwijderd. Sommige toepassingen kunnen daar alleen mee werken, omdat ze de status van andere bronnen opnieuw kunnen genereren en de status niet lokaal hoeven op te slaan. Deze toepassingen worden stateless toepassingengenoemd.
Alle resterende statussen die niet kortstondig zijn, worden permanente statusgenoemd. De persistente toestand blijft bestaan na de levenscyclus van een container. De meeste containertechnologieën die we gebruiken, hebben het concept van volume, een in-schijflocatie waar de status zich bevindt. Zelfs als u de container verwijdert en weer inschakelt, blijft de status opgeslagen op een veilige locatie en kan deze opnieuw worden gebruikt.
Toepassingen die afhankelijk zijn van een externe status die moeten worden opgehaald, worden stateful toepassingengenoemd.
Toestanden en Kubernetes
Kubernetes kan zowel stateless als stateful toepassingen verwerken. Staatloze apps zijn eenvoudiger omdat we ons alleen kunnen richten op de toepassing zelf en niet op de status ervan (omdat deze niet bestaat).
Voor de meeste stateless toepassingen is een eenvoudige implementatieworkload met een pod voldoende om een volledig functionerend systeem te hebben en om optimaal gebruik te maken van uw cluster.
Het werken met stateful toepassingen is precies het tegenovergestelde. In deze gevallen moet u rekening houden met de toepassing en de bijbehorende status, waar de status is opgeslagen en hoe u de status veilig en betrouwbaar kunt opslaan.
Daarom heeft Kubernetes ook het concept van PersistentVolumes (PV's) en PersistentVolumeClaims (PVC's).
Fooi
In deze module worden geen opslagconcepten verder besproken, maar u kunt de Azure Kubernetes Service-resources in de samenvatting raadplegen voor meer informatie.
PersistentVolumes zijn schijven die zijn toegewezen in knooppunten om statussen op te slaan uit de container van een pod. Omdat Kubernetes het beste is voor gedistribueerde apps, bevinden alle gemaakte volumes zich in een pool met beschikbare volumes. Containers claimen die ruimte vervolgens zelf. U kunt PersistentVolumeClaims gebruiken om een PersistentVolume met een pod te binden en de ruimte te gebruiken om de benodigde gegevens op te slaan.
Alle databaseproviders zijn toepassingen met toestand. Als u een databaseprovider in uw cluster implementeert, hebt u een PV en PVC nodig om de databasegegevens op een veilige plek op te slaan en de provider toe te staan die gegevens op te halen, zelfs als de containers zijn verwijderd.
Beste praktijken voor statusverwerking
De status is aanwezig in de meeste toepassingen. Een best practice voor het afhandelen van toestand is echter om er helemaal niet mee om te gaan.
U ontwerpt elke efficiënte toepassing met als doel deze maximaal beschikbaar en schaalbaar te maken. De staat gaat in tegengestelde richting. Ondanks de opties van opslagproviders en het gemak van implementatie en gebruik, kan de status niet eenvoudig worden geschaald. Het is ook niet erg beschikbaar.
Maximaal beschikbare status
Als u maximaal beschikbaar wilt zijn, moet een toepassing altijd online zijn. Dit wordt gedaan via zone- en regioreplicatie. Kubernetes is zonebewust in de meeste workloads. Dit betekent dat u verschillende exemplaren kunt hebben van een toepassing die in verschillende zones is geïmplementeerd. Schijven zijn echter niet zonebewust.
Wanneer u een nieuw PersistentVolume-object in Kubernetes implementeert, is dit gebonden aan een schijf op een knooppunt. Deze schijf is ook gebonden aan een bepaalde zone in een bepaalde regio. Het gebruik van zone- of regioreplicatie met CSV's is complex en vereist veel onderhoud, zowel om gegevens te repliceren als te synchroniseren.
Zeer schaalbare status
Om zeer schaalbaar te zijn, moet een toepassing de doorvoer vergroten, samen met het aantal gebruikers dat ermee is verbonden. Dit is ingewikkeld in statusbeheer, omdat een externe status in feite een schijf is en een schijf een beperkte invoer- en uitvoersnelheid heeft. Doorvoerbeheer helpt dit probleem op te lossen.
Databaseoplossingen kwamen met het idee van ReplicaSets, waarmee de hele database in meerdere exemplaren wordt gerepliceerd. De replicatie verhoogt het aantal schijven en en de I/O voor de staat.
Bij elke databasewijziging moet de status worden gesynchroniseerd, zodat alle schijven dezelfde gegevens bevatten. Deze synchronisatie is ook complex.
De status externaliseren
Azure heeft PaaS-oplossingen (Platform as a Service), zoals Azure Cosmos DB, die maximaal beschikbaar en schaalbaar zijn en de meeste statusbeheerproblemen voor u oplossen.
Door de status extern op te slaan en de noodzaak voor onderhoud te verwijderen, kunt u zich richten op de toepassing en de overhead voor het omgaan met gegevensintegriteit in uw infrastructuur verminderen.