Hantera poddlagring i Kubernetes-kluster
Även om de flesta program som du tänker distribuera till AKS på Azure Stack HCI är tillståndslösa, identifierade Contoso-utvecklare några tillståndskänsliga arbetsbelastningar som de planerar att containerisera. För att tillgodose det här kravet måste du utforska stödet för att bevara tillståndet för att köra poddar genom att förlita dig på Kubernetes beständiga volymer.
Implementera beständiga volymer för AKS på Azure Stack HCI
Som standard fungerar enskilda poddar som tillståndslösa resurser. Om en podd som ingår i en distribution misslyckas av någon anledning skapar Kubernetes Scheduler automatiskt en ny som tillhandahåller matchande funktioner, vilket säkerställer att det containerbaserade programmet förblir tillgängligt. Men utan ytterligare bestämmelser för att bevara tillståndet går alla data som den misslyckade podden har arbetat med förlorade.
Det finns scenarier där poddar måste kunna bevara och dela sina data och tillstånd. I dessa scenarier kan du använda beständiga volymer, som är klusterresurser som gör det möjligt att lagra data för containerbaserade arbetsbelastningar utöver livslängden för enskilda poddar.
För att implementera en volym i ett Kubernetes-kluster måste du definiera ett beständiga volymanspråk för en specifik lagringsklass. En lagringsklass representerar egenskaperna för den underliggande lagringen, till exempel prestanda eller stöd för delad åtkomst. Beständiga volymanspråk innehåller information om det nödvändiga åtkomstläget och volymstorleken. Kubernetes API-server använder definitionen för beständiga volymanspråk för att dynamiskt etablera en lämplig lagringsvolym när det krävs av distribuerade poddar.
Kommentar
AKS på Azure Stack HCI erbjuder standardlagringsklassen, som implementerar VHDX-baserade diskar.
Definiera lagringskrav för distribuerade poddar genom att inkludera beständiga volymspecifikationer i motsvarande manifestfiler. Förutom att utlösa dynamisk etablering monterar detta även automatiskt volymen i poddarna.
Följande manifest definierar till exempel ett beständigt volymanspråk för en icke-delad disk på 100 GB som använder standardlagringsklassen.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-akshci
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
Om du vill implementera det här beständiga volymanspråket kan du lagra manifestet som en YAML-fil och köra kommandoradsverktyget kubectl för att skapa motsvarande resurs (där pvc_definition.yaml representerar YAML-filen):
kubectl create -f pvc_definition.yaml
Om du vill definiera en motsvarande beständig volym för en podd kan du använda följande manifest:
kind: Pod
apiVersion: v1
metadata:
name: win-appserver
spec:
containers:
- name: win-appserver
image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
volumeMounts:
- name: akshciscsi
mountPath: "/mnt/akshciscsi"
volumes:
- name: akshciscsi
persistentVolumeClaim:
claimName: pvc-akshci
nodeSelector:
kubernetes.io/os: windows
Om du vill implementera den här beständiga volymen kan du också lagra poddmanifestet som en YAML-fil och köra kubectl-kommandoradsverktyget för att etablera volymen och montera den (där pv_definition.yaml representerar YAML-filen):
kubectl create -f pv_definition.yaml
Den resulterande podden har en volym på 100 GB i storlek monterad i filsystemsökvägen som anges av elementets mountPath värde.
Om du vill ta bort det beständiga volymanspråket måste du först ta bort alla poddar och distributioner som för närvarande använder det. För att slutföra uppgiften kan du då använda kubectl delete PersistentVolumeClaim kommandot följt av namnet på det beständiga volymanspråket.