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.
Provincie
De status van de toepassing is alles wat wordt opgeslagen in het geheugen op het moment dat de toepassing wordt uitgevoerd. De status kan betrekking hebben op verschillende dingen, maar we richten ons voornamelijk op de gebruikersgegevens.
Laten we een voorbeeld geven van een toepassingsstatus; stel dat u uw muziekspeler hebt geopend. Deze toepassing heeft een status. De toepassing weet wie u bent, wat u graag hoort en welke muziek u hebt gedownload. Al deze informatie maakt deel uit van de toepassingsstatus.
De status in het geheugen is de informatie waar de toepassing niet op een andere locatie naar hoeft te zoeken. De schijfstatus bevat de informatie die de toepassing niet bij de hand heeft, deze informatie moet dus worden opgehaald uit een andere gegevensbron.
Typen statussen
Er zijn twee soorten 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 alleen daarmee werken, omdat ze de status van andere bronnen opnieuw kunnen genereren, zodat deze niet lokaal hoeft te worden opgeslagen. Deze toepassingen worden statelesstoepassingen genoemd.
Alle resterende statussen die niet kortstondig zijn, worden permanente status genoemd. De permanente status blijft bestaan na de levenscyclus van een container. De meeste containertechnologieën die we gebruiken, hebben het concept volume, een locatie op schijf 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 moet worden opgehaald, worden statefultoepassingen genoemd.
Statussen 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 verwerken van stateful toepassingen is 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).
Tip
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 voor het opslaan van statussen van de container van een pod. Omdat Kubernetes het beste is voor gedistribueerde apps, bevinden alle gemaakte volumes zich in een pool beschikbare volumes. Containers claimen die ruimte vervolgens zelf. U kunt PersistentVolumeClaims gebruiken om een PersistentVolume met een pod te verbinden en de beschikbare ruimte te gebruiken om de benodigde gegevens op te slaan.
Alle databaseproviders zijn stateful toepassingen. 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.
Best practices voor statusverwerking
De status is aanwezig in de meeste toepassingen. Een best practice voor het omgaan met een status is deze überhaupt niet aan te raken.
U ontwerpt een efficiënte toepassing met het doel om deze maximaal beschikbaar en schaalbaar te maken. In het geval van status is het andersom. Ondanks de opties van opslagproviders en het gemak van implementatie en gebruik, kan de status niet eenvoudig worden geschaald. Het is ook niet zeer beschikbaar.
Maximaal beschikbare status
Om zeer beschikbaar te zijn, moet een toepassing altijd online zijn. Dit wordt gedaan via zone- en regioreplicatie. Kubernetes is in de meeste werkbelastingen zonebewust. Dit betekent dat u meerdere exemplaren van een toepassing kunt hebben die in verschillende zones worden 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.
In hoge mate 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 elke externe status in feite een schijf is en een schijf een beperkte invoer- en uitvoerfrequentie heeft. Doorvoerbeheer helpt dit probleem op te lossen.
Databaseoplossingen kwamen met het idee om ReplicaSetsde hele database in meerdere exemplaren te repliceren. De replicatie verhoogt het aantal schijven en de I/O voor de status.
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 verwerken van gegevensintegriteit in uw infrastructuur verminderen.