Używanie sterownika interfejsu CSI (Container Storage Interface) usługi Azure Files w usłudze Azure Kubernetes Service (AKS)
Sterownik interfejsu CSI (Container Storage Interface) usługi Azure Files to sterownik zgodny ze specyfikacją CSI używany przez usługę Azure Kubernetes Service (AKS) do zarządzania cyklem życia udziałów plików platformy Azure. 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 usługi AKS z obsługą sterowników CSI, zobacz Włączanie sterowników CSI w usłudze AKS.
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.
Oprócz oryginalnych funkcji sterowników w drzewie sterownik CSI usługi Azure Files obsługuje następujące nowe funkcje:
- System plików sieciowych (NFS) w wersji 4.1
- Prywatny punkt końcowy
- Równoległe tworzenie dużej instalacji udziałów plików.
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. Jeśli wiele zasobników wymaga współbieżnego dostępu do tego samego woluminu magazynu, możesz użyć usługi Azure Files do nawiązania połączenia przy użyciu protokołu SMB (Server Message Block) lub NFS. W tym artykule pokazano, jak dynamicznie utworzyć udział usługi Azure Files do użycia przez wiele zasobników w klastrze usługi AKS. Aby uzyskać statyczną aprowizację, zobacz Ręczne tworzenie woluminu i używanie go z udziałem usługi Azure Files.
Uwaga
Należy pamiętać, że sterownik CSI usługi Azure File zezwala tylko na instalowanie udziałów plików SMB przy użyciu uwierzytelniania opartego na kluczach (NTLM v2), dlatego nie obsługuje maksymalnego profilu zabezpieczeń ustawień udziału plików platformy Azure. Z drugiej strony instalowanie udziałów plików NFS nie wymaga uwierzytelniania opartego na kluczach.
W przypadku udziałów usługi Azure Files nie ma limitu liczby zainstalowanych w węźle.
Aby uzyskać więcej informacji na temat woluminów Kubernetes, zobacz Opcje magazynu dla aplikacji w usłudze AKS.
Klasa magazynu służy do definiowania sposobu tworzenia udziału plików platformy Azure. Konto magazynu jest tworzone automatycznie w grupie zasobów węzła do użycia z klasą magazynu do przechowywania udziału plików platformy Azure. Wybierz jedną z następujących jednostek SKU nadmiarowości usługi Azure Storage dla skuName:
- Standard_LRS: magazyn lokalnie nadmiarowy w warstwie Standardowa
- Standard_GRS: magazyn geograficznie nadmiarowy w warstwie Standardowa
- Standard_ZRS: magazyn strefowo nadmiarowy w warstwie Standardowa
- Standard_RAGRS: magazyn geograficznie nadmiarowy z dostępem do odczytu w warstwie Standardowa
- Standard_RAGZRS: magazyn geograficznie nadmiarowy z dostępem do odczytu w warstwie Standardowa
- Premium_LRS: magazyn lokalnie nadmiarowy w warstwie Premium
- Premium_ZRS: magazyn strefowo nadmiarowy w warstwie Premium
Uwaga
Usługa Azure Files obsługuje udziały plików Azure Premium. Minimalna pojemność udziału plików to 100 GiB. Zalecamy używanie udziałów plików Azure Premium zamiast udziałów plików w warstwie Standardowa, ponieważ udziały plików w warstwie Premium oferują większą wydajność i obsługę dysków o małych opóźnieniach dla obciążeń intensywnie korzystających z operacji we/wy.
W przypadku używania sterowników CSI magazynu w usłudze AKS istnieją jeszcze dwa wbudowane StorageClasses
sterowniki magazynu usługi Azure Files CSI. Inne klasy magazynu CSI są tworzone z klastrem wraz z domyślnymi klasami magazynu w drzewie.
azurefile-csi
: używa usługi Azure Standard Storage do utworzenia udziału plików platformy Azure.azurefile-csi-premium
: używa usługi Azure Premium Storage do utworzenia udziału plików platformy Azure.
Zasady odzyskiwania w obu klasach magazynu zapewniają, że podstawowy udział plików platformy Azure zostanie usunięty po usunięciu odpowiedniego pv. Klasy magazynu konfigurują również udziały plików, 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. Element PVC służy do automatycznego aprowizowania magazynu na podstawie klasy magazynu. Element PVC może użyć jednej ze wstępnie utworzonych klas magazynu lub klasy magazynu zdefiniowanej przez użytkownika, aby utworzyć udział plików platformy Azure dla żądanej jednostki SKU i rozmiaru. Podczas tworzenia definicji zasobnika zostanie określony element PVC w celu zażądania żądanego magazynu.
Utwórz przykładowy element PVC i zasobnik, który wyświetla bieżącą datę do elementu outfile
, uruchamiając polecenia kubectl apply :
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/pvc-azurefile-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/nginx-pod-azurefile.yaml
Dane wyjściowe polecenia przypominają następujący przykład:
persistentvolumeclaim/pvc-azurefile created
pod/nginx-azurefile created
Po uruchomieniu zasobnika można sprawdzić, czy udział plików jest poprawnie zainstalowany, uruchamiając następujące polecenie i sprawdzając, czy dane wyjściowe zawierają element outfile
:
kubectl exec nginx-azurefile -- ls -l /mnt/azurefile
Dane wyjściowe polecenia przypominają następujący przykład:
total 29
-rwxrwxrwx 1 root root 29348 Aug 31 21:59 outfile
Domyślne klasy magazynu odpowiadają najbardziej typowym scenariuszom, ale nie wszystkim. W niektórych przypadkach możesz chcieć dostosować własną klasę magazynu z własnymi parametrami. Na przykład użyj następującego manifestu, aby skonfigurować mountOptions
udział plików.
Wartość domyślna dla funkcji fileMode i dirMode to 0777 dla zainstalowanych udziałów plików platformy Kubernetes. Można określić różne opcje instalacji w obiekcie klasy magazynu.
Utwórz plik o nazwie azure-file-sc.yaml
i wklej następujący przykładowy manifest:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: my-azurefile
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
- dir_mode=0640
- file_mode=0640
- uid=0
- gid=0
- mfsymlinks
- cache=strict # https://linux.die.net/man/8/mount.cifs
- nosharesock
parameters:
skuName: Standard_LRS
Utwórz klasę magazynu, uruchamiając polecenie kubectl apply :
kubectl apply -f azure-file-sc.yaml
Dane wyjściowe polecenia przypominają następujący przykład:
storageclass.storage.k8s.io/my-azurefile created
Sterownik CSI usługi Azure Files obsługuje tworzenie migawek woluminów trwałych i podstawowych udziałów plików.
Utwórz klasę migawki woluminu za pomocą polecenia kubectl apply:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshotclass-azurefile.yaml
Dane wyjściowe polecenia przypominają następujący przykład:
volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created
Utwórz migawkę woluminu na podstawie pliku PVC, który został utworzony dynamicznie na początku tego samouczka. pvc-azurefile
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshot-azurefile.yaml
Dane wyjściowe polecenia przypominają następujący przykład:
volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created
Sprawdź, czy migawka została utworzona poprawnie, uruchamiając następujące polecenie:
kubectl describe volumesnapshot azurefile-volume-snapshot
Dane wyjściowe polecenia przypominają następujący przykład:
Name: azurefile-volume-snapshot
Namespace: default
Labels: <none>
Annotations: API Version: snapshot.storage.k8s.io/v1beta1
Kind: VolumeSnapshot
Metadata:
Creation Timestamp: 2020-08-27T22:37:41Z
Finalizers:
snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
Generation: 1
Resource Version: 955091
Self Link: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-volume-snapshot
UID: c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Spec:
Source:
Persistent Volume Claim Name: pvc-azurefile
Volume Snapshot Class Name: csi-azurefile-vsc
Status:
Bound Volume Snapshot Content Name: snapcontent-c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Ready To Use: false
Events: <none>
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.
Zmniejszanie woluminów trwałych nie jest obecnie obsługiwane.
W usłudze AKS wbudowana azurefile-csi
klasa magazynu obsługuje już rozszerzenie, więc użyj pvc utworzonego wcześniej z tą klasą magazynu. PCV zażądał udziału plików 100 GiB. Możemy to potwierdzić, uruchamiając polecenie:
kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Dane wyjściowe polecenia przypominają następujący przykład:
Filesystem Size Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770 100G 128K 100G 1% /mnt/azurefile
Rozwiń pvc, zwiększając spec.resources.requests.storage
pole:
kubectl patch pvc pvc-azurefile --type merge --patch '{"spec": {"resources": {"requests": {"storage": "200Gi"}}}}'
Dane wyjściowe polecenia przypominają następujący przykład:
persistentvolumeclaim/pvc-azurefile patched
Sprawdź, czy zarówno PCW, jak i system plików w zasobniku mają nowy rozmiar:
kubectl get pvc pvc-azurefile
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-azurefile Bound pvc-5e5d9980-da38-492b-8581-17e3cad01770 200Gi RWX azurefile-csi 64m
kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Filesystem Size Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770 200G 128K 200G 1% /mnt/azurefile
Jeśli zasoby usługi Azure Files są chronione za pomocą prywatnego punktu końcowego, musisz utworzyć własną klasę magazynu. Upewnij się, że skonfigurowano ustawienia DNS w celu rozpoznania prywatnego adresu IP punktu końcowego na nazwę FQDN parametry połączenia. Dostosuj następujące parametry:
resourceGroup
: grupa zasobów, w której jest wdrażane konto magazynu.storageAccount
: nazwa konta magazynu.server
: nazwa FQDN prywatnego punktu końcowego konta magazynu.
Utwórz plik o nazwie private-azure-file-sc.yaml
, a następnie wklej następujący przykładowy manifest w pliku. Zastąp wartości dla <resourceGroup>
i <storageAccountName>
.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: private-azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
resourceGroup: <resourceGroup>
storageAccount: <storageAccountName>
server: <storageAccountName>.file.core.windows.net
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=0
- gid=0
- mfsymlinks
- cache=strict # https://linux.die.net/man/8/mount.cifs
- nosharesock # reduce probability of reconnect race
- actimeo=30 # reduce latency for metadata-heavy workload
Utwórz klasę magazynu przy użyciu kubectl apply
polecenia :
kubectl apply -f private-azure-file-sc.yaml
Dane wyjściowe polecenia przypominają następujący przykład:
storageclass.storage.k8s.io/private-azurefile-csi created
Utwórz plik o nazwie private-pvc.yaml
, a następnie wklej następujący przykładowy manifest w pliku:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: private-azurefile-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: private-azurefile-csi
resources:
requests:
storage: 100Gi
Utwórz element PVC przy użyciu polecenia kubectl apply :
kubectl apply -f private-pvc.yaml
Usługa Azure Files obsługuje protokół NFS w wersji 4.1. Obsługa systemu plików NFS w wersji 4.1 dla usługi Azure Files zapewnia w pełni zarządzany system plików NFS jako usługę utworzoną na platformie magazynu o wysokiej dostępności i wysoce odpornej na awarie.
Ta opcja jest zoptymalizowana pod kątem obciążeń dostępu losowego z aktualizacjami danych w miejscu i zapewnia pełną obsługę systemu plików POSIX. W tej sekcji pokazano, jak używać udziałów NFS ze sterownikiem AZURE File CSI w klastrze usługi AKS.
- Tożsamość płaszczyzny sterowania klastrem usługi AKS (czyli nazwa klastra usługi AKS) jest dodawana do roli Współautor w sieci wirtualnej i networkSecurityGroup.
- Jednostka usługi lub tożsamość usługi zarządzanej (MSI) klastra usługi AKS musi zostać dodana do roli Współautor na koncie magazynu.
Uwaga
Możesz użyć prywatnego punktu końcowego zamiast zezwalać na dostęp do wybranej sieci wirtualnej.
Ta sekcja zawiera informacje na temat sposobu podejścia dostrajania wydajności systemu plików NFS za pomocą sterownika CSI usługi Azure Files z opcjami rozmiaru i rozmiaru. Opcje rsize i wsize ustawiają maksymalny rozmiar transferu operacji NFS. Jeśli rozmiar rsize lub wsize nie są określone podczas instalacji, klient i serwer negocjują największy rozmiar obsługiwany przez te dwa. Obecnie zarówno usługa Azure NetApp Files, jak i nowoczesne dystrybucje systemu Linux obsługują rozmiary odczytu i zapisu nawet 1 048 576 bajtów (1 MiB).
Optymalna wydajność jest oparta na wydajnej komunikacji między klientem a serwerem. Zwiększenie lub zmniejszenie wartości rozmiaru opcji odczytu i zapisu instalacji może poprawić wydajność systemu plików NFS. Domyślny rozmiar pakietów odczytu/zapisu przesyłanych między klientem a serwerem to 8 KB dla systemu plików NFS w wersji 2 i 32 KB dla systemu plików NFS w wersji 3 i 4. Te wartości domyślne mogą być zbyt duże lub za małe. Zmniejszenie rozmiaru rsize i wsize może poprawić wydajność systemu plików NFS w zatłoczonej sieci, wysyłając mniejsze pakiety dla każdej odpowiedzi NFS-read i żądania zapisu. Może to jednak zwiększyć liczbę pakietów potrzebnych do wysyłania danych w sieci, zwiększając całkowity ruch sieciowy i wykorzystanie procesora CPU na kliencie i serwerze.
Ważne jest, aby przeprowadzić testy w celu znalezienia rozmiaru i rozmiaru, który podtrzymuje wydajność transferu pakietów, gdzie nie zmniejsza przepływności i zwiększa opóźnienie.
Aby uzyskać więcej informacji na temat optymalizowania rozmiaru rsize i rozmiaru, zobacz Linux NFS mount options best practices for Azure NetApp Files (Najlepsze rozwiązania dotyczące instalacji systemu plików NFS w systemie Linux dla usługi Azure NetApp Files).
Aby na przykład skonfigurować maksymalny rozmiar rsize i rozmiar 256-KiB, skonfiguruj klasę mountOptions
magazynu w następujący sposób:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
protocol: nfs
mountOptions:
- nconnect=4
- noresvport
- actimeo=30
- rsize=262144
- wsize=262144
Utwórz plik o nazwie nfs-sc.yaml
i skopiuj manifest poniżej. Aby uzyskać listę obsługiwanych mountOptions
plików , zobacz Opcje instalacji systemu plików NFS.
Uwaga
vers
, minorversion
sec
są konfigurowane przez sterownik CSI usługi Azure File. Określanie wartości w manifeście dla tych właściwości nie jest obsługiwane.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
protocol: nfs
mountOptions:
- nconnect=4
- noresvport
- actimeo=30
Po edycji i zapisaniu pliku utwórz klasę magazynu za pomocą polecenia kubectl apply :
kubectl apply -f nfs-sc.yaml
Dane wyjściowe polecenia przypominają następujący przykład:
storageclass.storage.k8s.io/azurefile-csi-nfs created
Możesz wdrożyć przykładowy zestaw stanowy, który zapisuje znaczniki czasu w pliku data.txt
za pomocą polecenia kubectl apply :
kubectl apply -f
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: statefulset-azurefile
labels:
app: nginx
spec:
podManagementPolicy: Parallel # default is OrderedReady
serviceName: statefulset-azurefile
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
nodeSelector:
"kubernetes.io/os": linux
containers:
- name: statefulset-azurefile
image: mcr.microsoft.com/oss/nginx/nginx:1.19.5
command:
- "/bin/bash"
- "-c"
- set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done
volumeMounts:
- name: persistent-storage
mountPath: /mnt/azurefile
updateStrategy:
type: RollingUpdate
selector:
matchLabels:
app: nginx
volumeClaimTemplates:
- metadata:
name: persistent-storage
spec:
storageClassName: azurefile-csi-nfs
accessModes: ["ReadWriteMany"]
resources:
requests:
storage: 100Gi
Dane wyjściowe polecenia przypominają następujący przykład:
statefulset.apps/statefulset-azurefile created
Zweryfikuj zawartość woluminu, uruchamiając następujące polecenie:
kubectl exec -it statefulset-azurefile-0 -- df -h
Dane wyjściowe polecenia przypominają następujący przykład:
Filesystem Size Used Avail Use% Mounted on
...
/dev/sda1 29G 11G 19G 37% /etc/hosts
accountname.file.core.windows.net:/accountname/pvc-fa72ec43-ae64-42e4-a8a2-556606f5da38 100G 0 100G 0% /mnt/azurefile
...
Uwaga
Należy pamiętać, że ponieważ udział plików NFS znajduje się na koncie Premium, minimalny rozmiar udziału plików to 100 GiB. Jeśli tworzysz pvc o małym rozmiarze magazynu, może wystąpić błąd podobny do następującego: nie można utworzyć udziału plików ... rozmiar (5)....
Sterownik CSI usługi Azure Files obsługuje również węzły i kontenery systemu Windows. Aby użyć 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 użyj wbudowanych klas magazynu, takich jak azurefile-csi
lub utwórz niestandardowe. Możesz wdrożyć przykładowy zestaw stanowy oparty na systemie Windows, który zapisuje znaczniki czasu w pliku data.txt
, uruchamiając polecenie kubectl apply :
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/windows/statefulset.yaml
Dane wyjściowe polecenia przypominają następujący przykład:
statefulset.apps/busybox-azurefile created
Zweryfikuj zawartość woluminu, uruchamiając następujące polecenie narzędzia kubectl exec :
kubectl exec -it busybox-azurefile-0 -- cat c:\\mnt\\azurefile\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azurefile-0 -- cat c:\mnt\azurefile\data.txt # on Windows Powershell/CMD
Dane wyjściowe poleceń przypominają następujący przykład:
2020-08-27 22:11:01Z
2020-08-27 22:11:02Z
2020-08-27 22:11:04Z
(...)
- Aby dowiedzieć się, jak używać sterownika CSI dla dysków platformy Azure, zobacz Używanie dysków platformy Azure ze sterownikiem CSI.
- Aby dowiedzieć się, jak używać sterownika CSI dla usługi Azure Blob Storage, zobacz Używanie usługi Azure Blob Storage ze sterownikiem CSI.
- Aby uzyskać więcej informacji na temat najlepszych rozwiązań dotyczących magazynu, zobacz Best practices for storage and backups in Azure Kubernetes Service (Najlepsze rozwiązania dotyczące magazynu i tworzenia kopii zapasowych w usłudze Azure Kubernetes Service).
Opinia o produkcie Azure Kubernetes Service
Azure Kubernetes Service to projekt typu open source. Wybierz link, aby przekazać opinię: