Udostępnij za pośrednictwem

Używanie sterownika interfejsu CSI (Azure Disk Container Storage Interface) w usłudze Azure Kubernetes Service (AKS)

  • Artykuł

Sterownik interfejsu CSI (Container Storage Interface) usługi Azure Disks to sterownik zgodny ze specyfikacją CSI używany przez usługę Azure Kubernetes Service (AKS) do zarządzania cyklem życia usługi Azure Disk.

CSI to standard dotyczący uwidaczniania dowolnych systemów magazynowania bloków i plików w konteneryzowanych obciążeniach na platformie Kubernetes. Dzięki wdrożeniu i użyciu interfejsu CSI usługa AKS może teraz zapisywać, wdrażać i iterować wtyczki, aby uwidocznić nowe lub ulepszać istniejące systemy magazynowania na platformie Kubernetes. Korzystanie ze sterowników CSI w usłudze AKS pozwala uniknąć konieczności dotykania podstawowego kodu Kubernetes i oczekiwania na cykle wydania.

Aby utworzyć klaster AKS z obsługą sterowników CSI, zobacz Włączanie sterownika CSI w usłudze AKS. W tym artykule opisano sposób używania sterownika AZURE Disk CSI w wersji 1.

Uwaga

Sterownik AZURE Disk CSI w wersji 2 (wersja zapoznawcza) zwiększa skalowalność i zmniejsza opóźnienie pracy w trybie failover zasobnika. Używa dysków udostępnionych do aprowizowania replik załączników w wielu węzłach klastra i integruje się z harmonogramem zasobników, aby upewnić się, że węzeł z repliką załącznika jest wybierany w trybie failover zasobnika. Sterownik AZURE Disk CSI w wersji 2 (wersja zapoznawcza) zapewnia również możliwość dostosowania wydajności. Jeśli interesuje Cię uczestnictwo w wersji zapoznawczej, prześlij żądanie: https://aka.ms/DiskCSIv2Preview. Ta wersja zapoznawcza jest udostępniana bez umowy dotyczącej poziomu usług i od czasu do czasu można oczekiwać zmian powodujących niezgodność w wersji zapoznawczej. Wersja zapoznawcza nie jest zalecana w przypadku obciążeń produkcyjnych. Aby uzyskać więcej informacji, zobacz Uzupełniające warunki korzystania z wersji zapoznawczych platformy Microsoft Azure.

Uwaga

Sterowniki w drzewie odnoszą się do bieżących sterowników magazynu, które są częścią podstawowego kodu Kubernetes w porównaniu z nowymi sterownikami CSI, które są wtyczkami.

Funkcje sterownika CSI dysku platformy Azure

Oprócz funkcji sterowników w drzewie sterownik azure Disk CSI obsługuje następujące funkcje:

  • Ulepszenia wydajności podczas dołączania i odłączania dysków współbieżnych
    • Sterowniki w drzewie dołączają lub odłączają dyski szeregowe, podczas gdy sterowniki CSI dołączają lub odłączają dyski w partii. W przypadku dołączania wielu dysków do jednego węzła występuje znaczna poprawa.
  • Obsługiwane są dyski SSD w warstwie Premium w wersji 1 i 2.
    • PremiumV2_LRS obsługuje None tylko tryb buforowania
  • Obsługa dysków magazynu strefowo nadmiarowego (ZRS)
    • Premium_ZRSobsługiwane StandardSSD_ZRS są typy dysków. Dysk ZRS można zaplanować w strefie lub w węźle bez strefy, bez ograniczenia, że wolumin dysku powinien znajdować się w tej samej strefie co dany węzeł. Aby uzyskać więcej informacji, w tym obsługiwanych regionów, zobacz Magazyn strefowo nadmiarowy dla dysków zarządzanych.
  • Migawka
  • Klonowanie woluminu
  • Zmienianie rozmiaru dysku PV bez przestoju

Uwaga

W zależności od używanej jednostki SKU maszyny wirtualnej sterownik CSI dysku platformy Azure może mieć limit woluminu na węzeł. W przypadku niektórych zaawansowanych maszyn wirtualnych (na przykład 16 rdzeni) limit wynosi 64 woluminy na węzeł. Aby zidentyfikować limit dla jednostki SKU maszyny wirtualnej, zapoznaj się z kolumną Maksymalna liczba dysków danych dla każdej oferowanej jednostki SKU maszyny wirtualnej. Aby uzyskać listę oferowanych jednostek SKU maszyn wirtualnych i ich odpowiednie szczegółowe limity pojemności, zobacz Rozmiary maszyn wirtualnych ogólnego przeznaczenia.

Używanie woluminów trwałych CSI z dyskami platformy Azure

Wolumin trwały (PV) reprezentuje część magazynu, która jest aprowizowana do użycia z zasobnikami Kubernetes. Pv może być używany przez jeden lub wiele zasobników i może być dynamicznie lub statycznie aprowizowany. W tym artykule pokazano, jak dynamicznie tworzyć woluminy wirtualne z dyskiem platformy Azure do użycia przez pojedynczy zasobnik w klastrze usługi AKS. Aby uzyskać statyczną aprowizację, zobacz Tworzenie woluminu statycznego za pomocą usługi Azure Disks.

Aby uzyskać więcej informacji na temat woluminów Kubernetes, zobacz Opcje magazynu dla aplikacji w usłudze AKS.

Dynamiczne tworzenie wirtualnych dysków platformy Azure przy użyciu wbudowanych klas magazynu

Klasa magazynu służy do definiowania sposobu dynamicznego tworzenia jednostki magazynu przy użyciu woluminu trwałego. Aby uzyskać więcej informacji na temat klas magazynu Kubernetes, zobacz Klasy magazynu Kubernetes.

Jeśli używasz sterownika AZURE Disk CSI w usłudze AKS, istnieją jeszcze dwa wbudowane StorageClasses , które używają sterownika magazynu Azure Disk CSI. Inne klasy magazynu CSI są tworzone z klastrem wraz z domyślnymi klasami magazynu w drzewie.

  • managed-csi: używa magazynu lokalnie nadmiarowego SSD w warstwie Standardowa (LRS) platformy Azure do utworzenia dysku zarządzanego. Począwszy od platformy Kubernetes w wersji 1.29, w klastrach usługi Azure Kubernetes Service (AKS) wdrożonych w wielu strefach dostępności ta klasa magazynu korzysta z magazynu strefowo nadmiarowego (ZRS) ssd w warstwie Standardowa w celu utworzenia dysków zarządzanych.
  • managed-csi-premium: używa magazynu LRS w warstwie Premium platformy Azure do utworzenia dysku zarządzanego. Począwszy od platformy Kubernetes w wersji 1.29, w klastrach usługi Azure Kubernetes Service (AKS) wdrożonych w wielu strefach dostępności ta klasa magazynu korzysta z magazynu strefowo nadmiarowego platformy Azure (ZRS) do tworzenia dysków zarządzanych.

Zasady odzyskiwania w obu klasach magazynu zapewniają, że bazowe dyski platformy Azure zostaną usunięte po usunięciu odpowiedniego pv. Klasy magazynu konfigurują również woluminy PV, aby można je było rozszerzać. Wystarczy edytować trwałe oświadczenie woluminu (PVC) przy użyciu nowego rozmiaru.

Aby użyć tych klas magazynowania, utwórz pvc i odpowiedni zasobnik, który odwołuje się do nich i używa ich. Element PVC służy do automatycznego aprowizowania magazynu na podstawie klasy magazynu. W celu utworzenia dysku zarządzanego platformy Azure dla żądanej jednostki SKU i rozmiaru można użyć jednej ze wstępnie utworzonych klas magazynu lub klasy magazynu zdefiniowanej przez użytkownika. Podczas tworzenia definicji zasobnika zostanie określony element PVC w celu zażądania żądanego magazynu.

Utwórz przykładowy zasobnik i odpowiedni element PVC, uruchamiając polecenie kubectl apply :

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/pvc-azuredisk-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/nginx-pod-azuredisk.yaml

Dane wyjściowe polecenia przypominają następujący przykład:

persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created

Po uruchomieniu zasobnika uruchom następujące polecenie, aby utworzyć nowy plik o nazwie test.txt.

kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt

Aby sprawdzić poprawność instalacji dysku, uruchom następujące polecenie i sprawdź, test.txt czy plik jest widoczny w danych wyjściowych:

kubectl exec nginx-azuredisk -- ls /mnt/azuredisk

lost+found
outfile
test.txt

Tworzenie niestandardowej klasy magazynu

Domyślne klasy magazynu są odpowiednie dla najbardziej typowych scenariuszy. W niektórych przypadkach możesz chcieć dostosować własną klasę magazynu z własnymi parametrami. Na przykład możesz zmienić klasę volumeBindingMode .

Można użyć volumeBindingMode: Immediate klasy, która gwarantuje, że następuje natychmiast po utworzeniu PVC. Jeśli pule węzłów są ograniczone topologią, na przykład w przypadku korzystania ze stref dostępności, woluminy PV będą powiązane lub aprowidowane bez znajomości wymagań dotyczących planowania zasobnika.

Aby rozwiązać ten scenariusz, można użyć polecenia volumeBindingMode: WaitForFirstConsumer, który opóźni powiązanie i aprowizację pv do momentu utworzenia zasobnika korzystającego z PVC. W ten sposób pv jest zgodna i aprowizowana w strefie dostępności (lub innej topologii), która jest określona przez ograniczenia planowania zasobnika. Domyślne klasy magazynu używają volumeBindingMode: WaitForFirstConsumer klasy.

Utwórz plik o nazwie sc-azuredisk-csi-waitforfirstconsumer.yaml, a następnie wklej następujący manifest. Klasa magazynu jest taka sama jak nasza managed-csi klasa magazynu, ale z inną volumeBindingMode klasą.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Utwórz klasę magazynu, uruchamiając polecenie kubectl apply i określ sc-azuredisk-csi-waitforfirstconsumer.yaml plik:

kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml

Dane wyjściowe polecenia przypominają następujący przykład:

storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created

Migawki woluminów

Sterownik CSI dysku platformy Azure obsługuje tworzenie migawek woluminów trwałych. W ramach tej możliwości sterownik może wykonywać pełne lub przyrostowe migawki w zależności od wartości ustawionej w parametrze incremental (domyślnie jest to prawda).

Poniższa tabela zawiera szczegółowe informacje dotyczące wszystkich parametrów.

Nazwisko Znaczenie Dostępna wartość Obowiązkowy Domyślna wartość
resourceGroup Grupa zasobów do przechowywania zdjęć migawek ISTNIEJĄCA GRUPA ZASOBÓW Nie. Jeśli nie zostanie określony, migawka będzie przechowywana w tej samej grupie zasobów co źródłowe dyski platformy Azure
Przyrostowe Tworzenie pełnej lub przyrostowej migawki true, false Nie. true
tags Tagi usługi Azure Disks Format tagu: "key1=val1,key2=val2" Nie. ""
userAgent Agent użytkownika używany do przypisywania użycia przez klienta Nie. Wygenerowany agent useragent sformatowany driverName/driverVersion compiler/version (OS-ARCH)
identyfikator subskrypcji Określanie identyfikatora subskrypcji platformy Azure, w którym zostaną utworzone dyski platformy Azure Identyfikator subskrypcji Azure Nie. Jeśli nie jest puste, resourceGroup należy podać wartość , incremental należy ustawić jako false

Tworzenie migawki woluminu

Uwaga

Przed kontynuowaniem upewnij się, że aplikacja nie zapisuje danych na dysku źródłowym.

Aby uzyskać przykład tej możliwości, utwórz klasę migawki woluminu za pomocą polecenia kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/storageclass-azuredisk-snapshot.yaml

Dane wyjściowe polecenia przypominają następujący przykład:

volumesnapshotclass.snapshot.storage.k8s.io/csi-azuredisk-vsc created

Teraz utwórzmy migawkę woluminu na podstawie pcv, który dynamicznie utworzyliśmy na początku tego samouczka. pvc-azuredisk

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/azuredisk-volume-snapshot.yaml

Dane wyjściowe polecenia przypominają następujący przykład:

volumesnapshot.snapshot.storage.k8s.io/azuredisk-volume-snapshot created

Aby sprawdzić, czy migawka została utworzona poprawnie, uruchom następujące polecenie:

kubectl describe volumesnapshot azuredisk-volume-snapshot

Dane wyjściowe polecenia przypominają następujący przykład:

Name:         azuredisk-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T05:27:58Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  714582
  Self Link:         /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
  UID:               dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azuredisk
  Volume Snapshot Class Name:      csi-azuredisk-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
  Creation Time:                       2020-08-31T05:27:59Z
  Ready To Use:                        true
  Restore Size:                        10Gi
Events:                                <none>

Tworzenie nowego PVC na podstawie migawki woluminu

Możesz utworzyć nowy element PVC na podstawie migawki woluminu. Użyj migawki utworzonej w poprzednim kroku i utwórz nowy element PVC i nowy zasobnik , aby go wykorzystać.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/pvc-azuredisk-snapshot-restored.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/nginx-pod-restored-snapshot.yaml

Dane wyjściowe polecenia przypominają następujący przykład:

persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created

Na koniec upewnijmy się, że jest to ten sam element PVC utworzony przed sprawdzeniem zawartości, uruchamiając następujące polecenie:

kubectl exec nginx-restored -- ls /mnt/azuredisk

Dane wyjściowe polecenia przypominają następujący przykład:

lost+found
outfile
test.txt

Zgodnie z oczekiwaniami nadal możemy zobaczyć nasz wcześniej utworzony test.txt plik.

Klonowanie woluminów

Sklonowany wolumin jest definiowany jako duplikat istniejącego woluminu Kubernetes. Aby uzyskać więcej informacji na temat klonowania woluminów na platformie Kubernetes, zobacz dokumentację koncepcyjną dotyczącą klonowania woluminów.

Sterownik CSI dla usługi Azure Disks obsługuje klonowanie woluminów. Aby to zademonstrować, utwórz sklonowany wolumin utworzonego azuredisk-pvc wcześniej zasobnika i nowy zasobnik, aby go używać.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/pvc-azuredisk-cloning.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/nginx-pod-restored-cloning.yaml

Dane wyjściowe polecenia przypominają następujący przykład:

persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created

Zawartość sklonowanego woluminu można sprawdzić, uruchamiając następujące polecenie i potwierdzając utworzenie pliku test.txt :

kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk

Dane wyjściowe polecenia przypominają następujący przykład:

lost+found
outfile
test.txt

Zmienianie rozmiaru woluminu trwałego bez przestojów

Możesz zażądać większego woluminu dla obiektu PVC. Edytuj obiekt PVC i określ większy rozmiar. Ta zmiana wyzwala rozszerzenie woluminu bazowego, który wspiera PV.

Uwaga

Nowy pv nigdy nie jest tworzony w celu spełnienia roszczenia. Zamiast tego zmieniany jest rozmiar istniejącego woluminu.

W usłudze AKS wbudowana managed-csi klasa magazynu obsługuje już rozszerzenie, więc użyj pvc utworzonego wcześniej z tą klasą magazynu. PCV zażądał 10-Gi trwałej objętości. Możesz to potwierdzić, uruchamiając następujące polecenie:

kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

Dane wyjściowe polecenia przypominają następujący przykład:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk

Rozwiń pcv, zwiększając spec.resources.requests.storage pole, uruchamiając następujące polecenie:

kubectl patch pvc pvc-azuredisk --type merge --patch '{"spec": {"resources": {"requests": {"storage": "15Gi"}}}}'

Uwaga

Zmniejszanie woluminów trwałych nie jest obecnie obsługiwane. Próba zastosowania istniejącego pvc o mniejszym rozmiarze niż bieżący prowadzi do następującego komunikatu o błędzie: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

Dane wyjściowe polecenia przypominają następujący przykład:

persistentvolumeclaim/pvc-azuredisk patched

Uruchom następujące polecenie, aby potwierdzić zwiększenie rozmiaru woluminu:

kubectl get pv

Dane wyjściowe polecenia przypominają następujący przykład:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
(...)

A po kilku minutach uruchom następujące polecenia, aby potwierdzić rozmiar PCV:

kubectl get pvc pvc-azuredisk

Dane wyjściowe polecenia przypominają następujący przykład:

NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            managed-csi    2d2h

Uruchom następujące polecenie, aby potwierdzić rozmiar dysku wewnątrz zasobnika:

kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

Dane wyjściowe polecenia przypominają następujący przykład:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         15G   46M   15G   1% /mnt/azuredisk

Wzrost na żądanie

Model skalowania dysków na żądanie umożliwia wzrosty dysków, gdy jego potrzeby przekraczają bieżącą pojemność. Ten model generuje dodatkowe opłaty za każdym razem, gdy dysk się zwiększa. Skalowanie na żądanie jest dostępne tylko dla dysków SSD w warstwie Premium większych niż 512 GiB. Aby uzyskać więcej informacji na temat dysków SSD w warstwie Premium aprowizowanej liczby operacji we/wy na sekundę i przepływności na dysk, zobacz Rozmiar ssd w warstwie Premium. Alternatywnie, skalowanie oparte na środkach to miejsce, w którym dysk będzie pękać tylko wtedy, gdy w zasobniku kredytowym zgromadzono środki z serii. Skalowanie oparte na kredytach nie generuje dodatkowych opłat, gdy dysk pęka. Skalowanie oparte na kredytach jest dostępne tylko dla dysków SSD w warstwie Premium 512 GiB i mniejszych oraz dysków SSD w warstwie 1024 GiB i mniejszych. Aby uzyskać więcej informacji na temat wzrostów na żądanie, zobacz Wzrost na żądanie.

Ważne

Domyślna managed-csi-premium klasa magazynu ma wyłączone skalowanie na żądanie i używa skalowania opartego na kredytach. Każdy dysk SSD w warstwie Premium dynamicznie tworzony przez trwałe oświadczenie woluminu na podstawie domyślnej managed-csi-premium klasy magazynu ma również wyłączone skalowanie na żądanie.

Aby utworzyć trwały wolumin SSD w warstwie Premium z włączonym wzrostem na żądanie, możesz utworzyć nową klasę magazynu z parametrem enableBursting ustawionym na true wartość, jak pokazano w poniższym szablonie YAML. Aby uzyskać więcej informacji na temat włączania skalowania na żądanie, zobacz Temat Na żądanie— wzrost. Aby uzyskać więcej informacji na temat tworzenia własnej klasy magazynu z włączoną obsługą skalowania na żądanie, zobacz Tworzenie klasy magazynu w warstwie Premium CSI zarządzanej z możliwością zwiększenia wydajności.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Kontenery systemu Windows

Sterownik interfejsu CSI dysku platformy Azure obsługuje węzły i kontenery systemu Windows. Jeśli chcesz używać kontenerów systemu Windows, postępuj zgodnie z przewodnikiem Szybki start kontenerów systemu Windows, aby dodać pulę węzłów systemu Windows.

Po utworzeniu puli węzłów systemu Windows można teraz używać wbudowanych klas magazynu, takich jak managed-csi. Możesz wdrożyć przykładowy zestaw stanowy oparty na systemie Windows, który zapisuje znaczniki czasu w pliku data.txt , uruchamiając następujące polecenie kubectl apply :

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/windows/statefulset.yaml

Dane wyjściowe polecenia przypominają następujący przykład:

statefulset.apps/busybox-azuredisk created

Aby zweryfikować zawartość woluminu, uruchom następujące polecenie:

kubectl exec -it busybox-azuredisk-0 -- cat c:\\mnt\\azuredisk\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azuredisk-0 -- cat c:\mnt\azuredisk\data.txt # on Windows Powershell/CMD

Dane wyjściowe polecenia przypominają następujący przykład:

2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)

Następne kroki