Zarządzanie magazynem zasobników w klastrach Kubernetes
Mimo że większość aplikacji, które zamierzasz wdrożyć w usłudze AKS w usłudze Azure Stack HCI, są bezstanowe, deweloperzy firmy Contoso zidentyfikowali kilka stanowych obciążeń, które planują konteneryzować. Aby spełnić to wymaganie, należy zapoznać się z obsługą zachowania stanu uruchomionych zasobników, opierając się na woluminach trwałych platformy Kubernetes.
Implementowanie woluminów trwałych dla usługi AKS w usłudze Azure Stack HCI
Domyślnie poszczególne zasobniki działają jako zasoby bezstanowe. Jeśli z jakiegoś powodu zasobnik, który jest częścią wdrożenia, harmonogram kubernetes automatycznie tworzy nowy, który zapewnia pasujące funkcje, zapewniając, że konteneryzowana aplikacja pozostaje dostępna. Jednak bez dodatkowych przepisów dotyczących zachowania stanu wszelkie dane, nad którymi mógł działać nieudany zasobnik, zostaną utracone.
Istnieją scenariusze, w których zasobniki muszą być w stanie utrwalać i udostępniać swoje dane i stan. W tych scenariuszach można użyć woluminów trwałych, które są zasobami klastra, które umożliwiają przechowywanie danych konteneryzowanych obciążeń poza cykl życia poszczególnych zasobników.
Aby zaimplementować wolumin w klastrze Kubernetes, należy zdefiniować trwałe oświadczenie woluminu dla określonej klasy magazynu. Klasa magazynu reprezentuje cechy magazynu bazowego, takie jak wydajność lub obsługa dostępu współdzielonego. Trwałe oświadczenie woluminu zawiera informacje o wymaganym trybie dostępu i rozmiarze woluminu. Serwer interfejsu API Kubernetes używa trwałej definicji oświadczenia woluminu, aby dynamicznie aprowizować odpowiedni wolumin magazynu zawsze, gdy jest to wymagane przez wdrożone zasobniki.
Uwaga
Usługa AKS w usłudze Azure Stack HCI oferuje domyślną klasę magazynu, która implementuje dyski oparte na dysku VHDX.
Zdefiniuj wymagania dotyczące magazynu wdrożonych zasobników, uwzględniając trwałe specyfikacje woluminów w odpowiednich plikach manifestu. Oprócz wyzwalania dynamicznej aprowizacji powoduje to również automatyczne zainstalowanie woluminu w zasobnikach.
Na przykład poniższy manifest definiuje trwałe oświadczenie woluminu dla dysku innego niż udostępniony o rozmiarze 100 GB, który używa domyślnej klasy magazynu.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-akshci
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
Aby zaimplementować to trwałe oświadczenie woluminu, można zapisać ten manifest jako plik YAML i uruchomić narzędzie wiersza polecenia kubectl, aby utworzyć odpowiedni zasób (gdzie pvc_definition.yaml reprezentuje plik YAML):
kubectl create -f pvc_definition.yaml
Aby zdefiniować odpowiedni wolumin trwały dla zasobnika, można użyć następującego manifestu:
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
Aby zaimplementować ten wolumin trwały, można również przechowywać manifest zasobnika jako plik YAML i uruchomić narzędzie wiersza polecenia kubectl, aby aprowizować wolumin i zainstalować go (gdzie pv_definition.yaml reprezentuje plik YAML):
kubectl create -f pv_definition.yaml
Wynikowy zasobnik będzie miał wolumin o rozmiarze 100 GB zainstalowanym w ścieżce systemu plików wyznaczonej przez wartość mountPath elementu.
Aby usunąć trwałe oświadczenie woluminu, należy najpierw usunąć wszystkie zasobniki i wdrożenia, które są obecnie z niego używane. W tym momencie, aby ukończyć zadanie, możesz użyć kubectl delete PersistentVolumeClaim polecenia , a następnie nazwy trwałego oświadczenia woluminu.