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.

Interfejs CSI jest standardem umożliwiającym uwidacznianie dowolnych systemów magazynowania bloków i plików do konteneryzowanych obciążeń 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 w usłudze Kubernetes. Używanie sterowników CSI w usłudze AKS pozwala uniknąć konieczności dotykania podstawowego kodu Kubernetes i oczekiwania na cykle wydania.

Aby utworzyć klaster usługi 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 CSI dysku platformy Azure w wersji 1.

Uwaga

Sterownik CSI dysku platformy Azure w wersji 2 (wersja zapoznawcza) zwiększa skalowalność i zmniejsza opóźnienie trybu 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 zasobnika, aby upewnić się, że węzeł z repliką załącznika jest wybierany w trybie failover zasobnika. Sterownik CSI dysku platformy Azure 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 csI dysku platformy Azure obsługuje następujące funkcje:

  • Ulepszenia wydajności podczas dołączania i odłączania dysku współbieżnego
    • Sterowniki w drzewie dołączają lub odłączają dyski szeregowe, a sterowniki CSI dołączają lub odłączają dyski wsadowe. Istnieje znaczna poprawa, gdy istnieje wiele dysków dołączanych do jednego węzła.
  • 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 magazynu 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
  • Zmiana 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 zapoznać się z listą oferowanych jednostek SKU maszyn wirtualnych i odpowiadającymi im szczegółowymi limitami pojemności, zobacz Ogólnego przeznaczenia rozmiary maszyn wirtualnych.

Używanie woluminów trwałych CSI z usługą Azure Disks

Wolumin trwały (PV) reprezentuje część magazynu, która jest aprowizowana do użytku 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ć telewizory 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 CSI dysku platformy Azure w usłudze AKS, istnieją jeszcze dwie wbudowane StorageClasses funkcje, które korzystają ze sterownika magazynu Azure Disk CSI. Inne klasy magazynu CSI są tworzone z klastrem wraz z domyślnymi klasami magazynu w drzewie.

  • managed-csi: do utworzenia dysku zarządzanego używa lokalnego magazynu ssd w warstwie Standardowa (LRS).
  • managed-csi-premium: używa usługi Azure Premium LRS do utworzenia dysku zarządzanego.

Zasady odzyskiwania w obu klasach magazynu zapewniają, że bazowe dyski platformy Azure są usuwane po usunięciu odpowiedniego pv. Klasy magazynu konfigurują również telewizory, aby można je było rozszerzać. Wystarczy edytować trwałe oświadczenie woluminu (PVC) o nowym rozmiarze.

Aby użyć tych klas magazynowania, utwórz pvc i odpowiedni zasobnik, który odwołuje się do nich i używa ich. Pvc służy do automatycznego aprowizowania magazynu na podstawie klasy magazynu. Pvc może używać jednej ze wstępnie utworzonych klas magazynu lub klasy magazynu zdefiniowanej przez użytkownika, aby utworzyć dysk zarządzany przez platformę Azure dla żądanej jednostki SKU i rozmiaru. Podczas tworzenia definicji zasobnika zostanie określony element PVC, aby zażądać żądanego miejsca do magazynowania.

Utwórz przykładowy zasobnik i odpowiedni 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 mieć własną klasę magazynu dostosowaną 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. W przypadku ograniczenia topologii pul węzłów, na przykład w przypadku korzystania ze stref dostępności, telewizory będą powiązane lub aprowizowane bez znajomości wymagań dotyczących planowania zasobnika.

Aby rozwiązać ten scenariusz, można użyć volumeBindingMode: WaitForFirstConsumermetody , która opóźnia powiązanie i aprowizowanie pv do momentu utworzenia zasobnika korzystającego z PVC. W ten sposób pv jest zgodna i jest 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.

Nazwa Znaczenie Dostępna wartość Obowiązkowy Wartość domyślna
resourceGroup Grupa zasobów do przechowywania zdjęć migawek ISTNIEJĄCA GRUPA ZASOBÓW Nie Jeśli nie zostanie określona, migawka będzie przechowywana w tej samej grupie zasobów co źródłowe dyski platformy Azure
Przyrostowe Wykonywanie 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 klienta Nie Wygenerowany parametr Useragent sformatowany driverName/driverVersion compiler/version (OS-ARCH)
Subscriptionid Określanie identyfikatora subskrypcji platformy Azure, w którym zostaną utworzone dyski platformy Azure Identyfikator subskrypcji platformy Azure Nie Jeśli nie jest pusty, resourceGroup należy podać parametr , incremental należy ustawić jako false

Tworzenie migawki woluminu

Uwaga

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

Na 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 pliku PVC, który został utworzony dynamicznie 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 PCV na podstawie migawki woluminu

Nowy element PVC można utworzyć 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 woluminutworzonego wcześniejazuredisk-pvc i nowy zasobnik, aby go użyć.

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

Możesz sprawdzić zawartość sklonowanego woluminu, 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 przestoju

Można zażądać większego woluminu dla PCV. 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 rozmiar istniejącego woluminu jest zmieniany.

W usłudze AKS wbudowana managed-csi klasa magazynu obsługuje już rozszerzenie, więc użyj elementu PVC utworzonego wcześniej z tą klasą magazynu. PCW zażądał 10-Gi trwałego woluminu. 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ń element PVC, 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 elementu PVC o mniejszym rozmiarze niż bieżąca 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
(...)

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

Skalowanie na żądanie

Model skalowania dysków na żądanie umożliwia zwiększanie szybkości dysków, gdy jego potrzeby przekraczają bieżącą pojemność. Ten model generuje dodatkowe opłaty za każdym razem, gdy dysk wybuchnie. 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 jest miejscem, w którym dysk będzie pęknięcie tylko wtedy, gdy w zasobniku środków zostanie skumulowany wzrost środków. Skalowanie oparte na środkach nie generuje dodatkowych opłat po pęknięciu dysku. Skalowanie oparte na środkach 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 skalowania 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 środkach. Każdy dysk SSD w warstwie Premium dynamicznie tworzony przez oświadczenie trwałego 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 zwiększaniem wydajności 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 Zwiększenie wydajności na żądanie. Aby uzyskać więcej informacji na temat tworzenia własnej klasy magazynu z włączonym skalowaniem na żądanie, zobacz Create a Burstable Managed CSI Premium Storage Class (Tworzenie zarządzanej klasy CSI 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żesz teraz używać wbudowanych klas magazynu, takich jak managed-csi. Możesz wdrożyć przykładowy zestaw stanowy oparty na systemie Windows , który pozwala zaoszczędzić 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 sprawdzić poprawność zawartości 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