Podopslag beheren op Kubernetes-clusters
Hoewel de meeste toepassingen die u wilt implementeren in AKS in Azure Stack HCI staatloos zijn, hebben Contoso-ontwikkelaars enkele stateful workloads geïdentificeerd die ze in containers willen plaatsen. Om aan deze vereiste te voldoen, moet u de ondersteuning voor het behouden van de status van actieve pods verkennen door te vertrouwen op permanente Kubernetes-volumes.
Permanente volumes implementeren voor AKS in Azure Stack HCI
Afzonderlijke pods werken standaard als staatloze resources. Als een pod die deel uitmaakt van een implementatie om een of andere reden mislukt, maakt Kubernetes Scheduler automatisch een nieuwe die de overeenkomende functionaliteit biedt, zodat de containertoepassing beschikbaar blijft. Zonder aanvullende bepalingen voor het behouden van de status gaan alle gegevens waaraan de mislukte pod werkt echter verloren.
Er zijn scenario's waarin pods hun gegevens en status moeten kunnen behouden en delen. In deze scenario's kunt u permanente volumes gebruiken. Dit zijn clusterbronnen waarmee gegevens van containerworkloads kunnen worden opgeslagen na de levensduur van afzonderlijke pods.
Als u een volume in een Kubernetes-cluster wilt implementeren, moet u een permanente volumeclaim definiëren voor een specifieke opslagklasse. Een opslagklasse vertegenwoordigt de kenmerken van de onderliggende opslag, zoals prestaties of ondersteuning voor gedeelde toegang. Permanente volumeclaim bevat informatie over de vereiste toegangsmodus en volumegrootte. Kubernetes API-server maakt gebruik van de definitie van de permanente volumeclaim om dynamisch een geschikt opslagvolume in te richten wanneer dit nodig is voor geïmplementeerde pods.
Notitie
AKS op Azure Stack HCI biedt de standaardopslagklasse, waarmee VHDX-schijven worden geïmplementeerd.
Definieer opslagvereisten voor geïmplementeerde pods door permanente volumespecificaties op te slaan in de bijbehorende manifestbestanden. Naast het activeren van dynamische inrichting, wordt hiermee ook automatisch het volume in de pods gekoppeld.
Het volgende manifest definieert bijvoorbeeld een permanente volumeclaim voor een niet-gedeelde schijf van 100 GB die gebruikmaakt van de standaardopslagklasse.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-akshci
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
Als u deze permanente volumeclaim wilt implementeren, kunt u dit manifest opslaan als een YAML-bestand en het opdrachtregelprogramma kubectl uitvoeren om de bijbehorende resource te maken (waarbij het pvc_definition.yaml YAML-bestand wordt vertegenwoordigd):
kubectl create -f pvc_definition.yaml
Als u een bijbehorend permanent volume voor een pod wilt definiëren, kunt u het volgende manifest gebruiken:
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
Als u dit permanente volume ook wilt implementeren, kunt u het podmanifest opslaan als een YAML-bestand en het opdrachtregelprogramma kubectl uitvoeren om het volume in te richten en te koppelen (waarbij het pv_definition.yaml YAML-bestand wordt vertegenwoordigd):
kubectl create -f pv_definition.yaml
De resulterende pod heeft een volume van 100 GB in grootte dat is gekoppeld aan het bestandssysteempad dat is aangewezen door de waarde van het mountPath element.
Als u de permanente volumeclaim wilt verwijderen, moet u eerst pods en implementaties verwijderen die deze momenteel gebruiken. Als u de taak wilt voltooien, kunt u de kubectl delete PersistentVolumeClaim opdracht gebruiken, gevolgd door de naam van de permanente volumeclaim.