Sterownik CSI usługi Azure Storage i aprowizowanie woluminów

Ta sekcja zawiera wskazówki dla administratorów klastra, którzy chcą aprowizować co najmniej jeden wolumin trwały, który zawiera szczegóły magazynu obiektów blob do użycia przez obciążenie. Żądanie utworzenia trwałego wolumenu (PVC) używa obiektu klasy pamięci do dynamicznego przydzielania kontenera usługi Azure Blob Storage.

Aby aprowizować wolumin trwały przy użyciu usługi Azure Blob Storage z podaną klasą magazynu, wykonaj następujące kroki:

1. StorageClass Utwórz manifest, zapisując następujący kod YAML w pliku o nazwie blob-fuse-sc.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: blob-fuse
   provisioner: blob.csi.azure.com
   parameters:
     skuName: Premium_LRS  # available values: Standard_LRS, Premium_LRS, Standard_GRS, Standard_RAGRS, Standard_ZRS, Premium_ZRS
     protocol: fuse2
     networkEndpointType: privateEndpoint
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   allowVolumeExpansion: true
   mountOptions:
     - -o allow_other
     - --file-cache-timeout-in-seconds=120
     - --use-attr-cache=true
     - --cancel-list-on-mount-seconds=10  # prevent billing charges on mounting
     - -o attr_timeout=120
     - -o entry_timeout=120
     - -o negative_timeout=120
     - --log-level=LOG_WARNING  # LOG_WARNING, LOG_INFO, LOG_DEBUG
     - --cache-size-mb=1000  # Default will be 80% of available memory, eviction will happen beyond specified value.
   

2. Aby utworzyć klasę pamięci masowej w klastrze, zastosuj StorageClass, uruchamiając następujące polecenie:

   kubectl apply -f blob-fuse-sc.yaml
   

Utwórz PVC przy użyciu wbudowanej klasy przechowywania

Klasa magazynu służy do definiowania sposobu tworzenia kontenera usługi Azure Blob Storage. Konto magazynu jest tworzone automatycznie w grupie zasobów węzła do użycia z klasą magazynu do przechowywania kontenera usługi Azure Blob Storage. Wybierz jedną z następujących jednostek SKU nadmiarowości pamięci masowej Azure dla skuName:

• Standard_LRS: Standardowa lokalna nadmiarowość przechowywania
• Premium_LRS: magazyn lokalnie nadmiarowy w warstwie Premium
• Standard_ZRS: magazyn strefowo nadmiarowy w warstwie Standardowa
• Premium_ZRS: magazyn strefowo nadmiarowy w warstwie Premium
• Standard_GRS: Standardowa pamięć geograficznie z nadmiarową dostępnością
• Standard_RAGRS: magazyn geograficznie nadmiarowy z dostępem do odczytu w warstwie Standardowa

Kiedy używasz sterowników CSI magazynu w usłudze AKS, dostępne są dwa inne wbudowane sterowniki StorageClasses, które korzystają z magazynu Azure Blob CSI.

Zasady odzyskiwania w obu klasach pamięci masowej zapewniają, że podstawowy magazyn obiektów Blob w Azure zostanie usunięty, gdy odpowiedni PV zostanie usunięty. Klasy pamięci masowej konfigurują również kontener, aby można go było rozszerzać domyślnie, ponieważ set allowVolumeExpansion parametr ma wartość true.

Użyj polecenia kubectl get sc , aby wyświetlić klasy magazynu. W przedstawionym przykładzie pokazano dostępne klasy pamięci azureblob-fuse-premium i azureblob-nfs-premium w klastrze AKS.

NAME                     PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
azureblob-fuse-premium   blob.csi.azure.com   Delete          Immediate           true                   23h
azureblob-nfs-premium    blob.csi.azure.com   Delete          Immediate           true                   23h

Aby użyć tych klas magazynowania, utwórz PVC i odpowiedni pod, który do nich odwołuje i je wykorzystuje. PVC służy do automatycznego przydzielania zasobów dyskowych na podstawie klasy pamięci masowej. PVC można utworzyć przy użyciu jednej z wbudowanych klas pamięci masowej lub niestandardowej klasy pamięci masowej. Ten PVC tworzy kontener w usłudze Azure Blob Storage z określoną jednostką SKU, rozmiarem oraz protokołem. Podczas tworzenia definicji zasobnika określa się PVC w celu zażądania żądanej przestrzeni dyskowej.

Element PVC używa obiektu klasy magazynu do dynamicznego aprowizowania kontenera usługi Azure Blob Storage. Poniższy kod YAML może służyć do utworzenia 5 GB PVC z dostępem ReadWriteMany przy użyciu wbudowanej klasy przechowywania. Aby uzyskać więcej informacji na temat trybów dostępu, zobacz dokumentację dotyczącą trwałego woluminu Kubernetes .

1. Utwórz plik o nazwie blob-nfs-pvc.yaml i skopiuj następujący kod YAML:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azure-blob-storage
   spec:
     accessModes:
     - ReadWriteMany
     storageClassName: azureblob-nfs-premium
     resources:
       requests:
         storage: 5Gi
   

2. Utwórz element PVC za pomocą polecenia kubectl create :

   kubectl create -f blob-nfs-pvc.yaml
   

Po zakończeniu zostanie utworzony kontener usługi Blob Storage. Możesz użyć polecenia kubectl get , aby wyświetlić stan PVC:

kubectl get pvc azure-blob-storage

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

NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                AGE
azure-blob-storage   Bound    pvc-b88e36c5-c518-4d38-a5ee-337a7dda0a68   5Gi        RWX            azureblob-nfs-premium       92m

Zamontuj PCV

Poniższy kod YAML tworzy zasobnik, który używa magazynu azure-blob-storage PVC do zainstalowania usługi Azure Blob Storage w ścieżce /mnt/blob .

1. Utwórz plik o nazwie blob-nfs-pvi skopiuj następujący kod YAML. Upewnij się, że claimName jest zgodny z PVC utworzonym w poprzednim kroku.

   kind: Pod
   apiVersion: v1
   metadata:
     name: mypod
   spec:
     containers:
     - name: mypod
       image: mcr.microsoft.com/oss/nginx/nginx:1.17.3-alpine
       resources:
         requests:
           cpu: 100m
           memory: 128Mi
         limits:
           cpu: 250m
           memory: 256Mi
       volumeMounts:
       - mountPath: "/mnt/blob"
         name: volume
         readOnly: false
     volumes:
       - name: volume
         persistentVolumeClaim:
           claimName: azure-blob-storage
   

2. Utwórz pod za pomocą polecenia kubectl apply

   kubectl apply -f blob-nfs-pv.yaml
   

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

   kubectl exec mypod -- touch /mnt/blob/test.txt
   

4. Aby sprawdzić, czy dysk jest poprawnie zainstalowany, uruchom następujące polecenie i sprawdź, czy plik jest widoczny test.txt w danych wyjściowych:

   kubectl exec mypod -- ls /mnt/blob
   

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

   test.txt
   

Ta sekcja zawiera wskazówki dla administratorów klastra, którzy chcą utworzyć jeden lub więcej zasobów PV zawierających szczegóły dotyczące magazynu obiektów blob do wykorzystania przez obciążenie.

Utwórz kontener przechowywania Blob

Podczas tworzenia zasobu usługi Azure Blob Storage do użycia z usługą AKS można utworzyć zasób w grupie zasobów węzła. Takie podejście umożliwia klastrowi usługi AKS uzyskiwanie dostępu do zasobu magazynu obiektów Blob i zarządzanie tym zasobem.

W tym artykule utwórz kontener w grupie zasobów węzła. Najpierw pobierz nazwę grupy zasobów za pomocą polecenia az aks show i dodaj parametr zapytania --query nodeResourceGroup. Poniższy przykład pobiera grupę zasobów węzłów dla klastra AKS o nazwie myAKSCluster w grupie zasobów o nazwie myResourceGroup:

az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv

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

MC_myResourceGroup_myAKSCluster_eastus

Następnie utwórz kontener do przechowywania obiektów blob, wykonując kroki opisane w temacie Zarządzanie magazynem obiektów blob w celu autoryzowania dostępu, a następnie utwórz kontener.

W tym przykładzie poniższy manifest konfiguruje instalowanie kontenera usługi Blob Storage przy użyciu protokołu NFS. Użyj go, aby dodać tags parametr .

1. Utwórz plik o nazwie blob-nfs-sc.yamli wklej następujący przykładowy manifest:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azureblob-nfs-premium
   provisioner: blob.csi.azure.com
   parameters:
     protocol: nfs
     tags: environment=Development
   volumeBindingMode: Immediate
   allowVolumeExpansion: true
   mountOptions:
     - nconnect=4
   

2. Utwórz klasę pamięci za pomocą polecenia kubectl apply

   kubectl apply -f blob-nfs-sc.yaml
   

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

   storageclass.storage.k8s.io/blob-nfs-premium created
   

W tym przykładzie poniższy manifest konfiguruje się przy użyciu narzędzia BlobFuse i instaluje kontener usługi Blob Storage. Służy do aktualizowania parametru skuName .

1. Utwórz plik o nazwie blobfuse-sc.yaml i wklej następujący przykładowy manifest:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azureblob-fuse-premium
   provisioner: blob.csi.azure.com
   parameters:
     skuName: Standard_GRS  # available values: Standard_LRS, Premium_LRS, Standard_GRS, Standard_RAGRS
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    allowVolumeExpansion: true
    mountOptions:
     - -o allow_other
     - --file-cache-timeout-in-seconds=120
     - --use-attr-cache=true
     - --cancel-list-on-mount-seconds=10  # prevent billing charges on mounting
     - -o attr_timeout=120
     - -o entry_timeout=120
     - -o negative_timeout=120
     - --log-level=LOG_WARNING  # LOG_WARNING, LOG_INFO, LOG_DEBUG
     - --cache-size-mb=1000  # Default will be 80% of available memory, eviction will happen beyond that.
   

2. Utwórz klasę pamięci masowej za pomocą polecenia kubectl apply

   kubectl apply -f blobfuse-sc.yaml
   

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

   storageclass.storage.k8s.io/blob-fuse-premium created
   

Instalowanie magazynu obiektów blob przy użyciu protokołu NFS w wersji 3 nie jest uwierzytelniane przy użyciu klucza konta. Klaster AKS musi znajdować się w tej samej lub równorzędnej sieci wirtualnej co węzeł agenta. Jedynym sposobem zabezpieczenia danych na koncie przechowywania jest użycie sieci wirtualnej i innych ustawień zabezpieczeń sieci. Aby uzyskać więcej informacji na temat konfigurowania dostępu systemu plików NFS do konta magazynu, zobacz Instalowanie usługi Blob Storage przy użyciu protokołu sieciowego systemu plików (NFS) 3.0.

W poniższym przykładzie pokazano, jak zainstalować kontener usługi Blob Storage jako wolumin trwały przy użyciu protokołu NFS.

1. Utwórz plik o nazwie pv-blob-nfs.yaml i skopiuj go w następującym języku YAML. W obszarze storageClass, zaktualizuj resourceGroup, storageAccount, i containerName.

   Uwaga / Notatka

   Wartość volumeHandle w pliku YAML powinna być unikatowym identyfikatorem woluminu dla każdego kontenera obiektów blob, który jest identyczny w klastrze.

   Znaki # i / są zastrzeżone do użytku wewnętrznego i nie można ich używać.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: blob.csi.azure.com
     name: pv-blob
   spec:
     capacity:
       storage: 1Pi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain  # If set as "Delete" container would be removed after pvc deletion
     storageClassName: azureblob-nfs-premium
     mountOptions:
       - nconnect=4
     csi:
       driver: blob.csi.azure.com
       # make sure volumeid is unique for every identical storage blob container in the cluster
       # character `#` and `/` are reserved for internal use and cannot be used in volumehandle
       volumeHandle: account-name_container-name
       volumeAttributes:
         resourceGroup: resourceGroupName
         storageAccount: storageAccountName
         containerName: containerName
         protocol: nfs
   

   Uwaga / Notatka

   Chociaż atrybut pojemnościinterfejsu API platformy Kubernetes jest obowiązkowy, ta wartość nie jest używana przez sterownik CSI usługi Azure Blob Storage, ponieważ można elastycznie zapisywać dane do momentu osiągnięcia limitu pojemności konta magazynu. Wartość atrybutu capacity jest używana tylko do dopasowywania rozmiaru między PVs i PVCs. Zalecamy użycie fikcyjnej wysokiej wartości. Pod widzi zamontowany wolumin o fikcyjnym rozmiarze 5 Petabajtów.

2. Uruchom następujące polecenie, aby utworzyć wolumin trwały przy użyciu polecenia kubectl create odwołującego się do utworzonego wcześniej pliku YAML:

   kubectl create -f pv-blob-nfs.yaml
   

3. pvc-blob-nfs.yaml Utwórz plik za pomocą elementu PersistentVolumeClaim. Przykład:

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: pvc-blob
   spec:
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 10Gi
     volumeName: pv-blob
     storageClassName: azureblob-nfs-premium
   

4. Uruchom następujące polecenie, aby utworzyć żądanie trwałego woluminu używając polecenia kubectl create, odwołując się do wcześniej utworzonego pliku YAML.

   kubectl create -f pvc-blob-nfs.yaml
   

Platforma Kubernetes potrzebuje poświadczeń w celu uzyskania dostępu do utworzonego wcześniej kontenera usługi Blob Storage, który jest kluczem dostępu platformy Azure lub tokenami SAS. Te poświadczenia są przechowywane w sekrecie Kubernetes, do którego odwołuje się podczas tworzenia podu Kubernetes.

1. Użyj kubectl create secret command do utworzenia sekretu. Możesz uwierzytelnić się przy użyciu sekretu Kubernetes lub [Sygnatury Dostępu Współdzielonego][tokeny sas] (SAS). Musisz również podać nazwę konta i klucz z istniejącego konta usługi Azure Storage.

   • Wpis tajny platformy Kubernetes
   • Tokeny interfejsu SAS

   Poniższy przykład tworzy obiekt Secret o nazwie azure-secret i wypełnia parametry azurestorageaccountname i azurestorageaccountkey .

   kubectl create secret generic azure-secret --from-literal azurestorageaccountname=NAME --from-literal azurestorageaccountkey="KEY" --type=Opaque
   

2. Utwórz plik pv-blobfuse.yaml. W obszarze volumeAttributeszaktualizuj plik containerName. W nodeStateSecretRef zaktualizuj name nazwą wcześniej utworzonego obiektu Secret. Przykład:

   Uwaga / Notatka

   Wartość volumeHandle w pliku YAML powinna być unikatowym identyfikatorem woluminu dla każdego identycznego kontenera obiektów blob magazynu w klastrze.

   Znaki # i / są zastrzeżone do użytku wewnętrznego i nie można ich używać.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: blob.csi.azure.com
     name: pv-blob
   spec:
     capacity:
       storage: 10Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain  # If set as "Delete" container would be removed after pvc deletion
     storageClassName: azureblob-fuse-premium
     mountOptions:
       - -o allow_other
       - --file-cache-timeout-in-seconds=120
     csi:
       driver: blob.csi.azure.com
       # volumeid has to be unique for every identical storage blob container in the cluster
       # character `#`and `/` are reserved for internal use and cannot be used in volumehandle
       volumeHandle: account-name_container-name
       volumeAttributes:
         containerName: containerName
       nodeStageSecretRef:
         name: azure-secret
         namespace: default
   

3. Uruchom następujące polecenie, aby utworzyć pv przy użyciu polecenia kubectl create odwołującego się do utworzonego wcześniej pliku YAML:

   kubectl create -f pv-blobfuse.yaml
   

4. Utwórz plik z PV. Przykład:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-blob
   spec:
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 10Gi
     volumeName: pv-blob
     storageClassName: azureblob-fuse-premium
   

5. Uruchom następujące polecenie, aby utworzyć plik PVC przy użyciu polecenia kubectl create odwołującego się do utworzonego wcześniej pliku YAML:

   kubectl create -f pvc-blobfuse.yaml
   

1. Utwórz plik o nazwie azure-blob-nfs-ss.yaml i skopiuj go w następującym języku YAML.

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: statefulset-blob-nfs
     labels:
       app: nginx
   spec:
     serviceName: statefulset-blob-nfs
     replicas: 1
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:
           "kubernetes.io/os": linux
         containers:
           - name: statefulset-blob-nfs
             image: mcr.microsoft.com/azurelinux/base/nginx:1.25
             volumeMounts:
               - name: persistent-storage
                 mountPath: /mnt/blob
     updateStrategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: nginx
     volumeClaimTemplates:
       - metadata:
           name: persistent-storage
         spec:
           storageClassName: azureblob-nfs-premium
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 100Gi
   

2. Utwórz element StatefulSet za pomocą polecenia kubectl create.

   kubectl create -f azure-blob-nfs-ss.yaml
   

1. Utwórz plik o nazwie azure-blobfuse-ss.yaml i skopiuj go w następującym języku YAML.

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: statefulset-blob
     labels:
       app: nginx
   spec:
     serviceName: statefulset-blob
     replicas: 1
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:
           "kubernetes.io/os": linux
         containers:
           - name: statefulset-blob
             image: mcr.microsoft.com/azurelinux/base/nginx:1.25
             volumeMounts:
               - name: persistent-storage
                 mountPath: /mnt/blob
     updateStrategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: nginx
     volumeClaimTemplates:
       - metadata:
           name: persistent-storage
         spec:
           storageClassName: azureblob-fuse-premium
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 100Gi
   

2. Utwórz StatefulSet za pomocą polecenia kubectl create:

   kubectl create -f azure-blobfuse-ss.yaml
   

¹ Jeśli konto magazynu jest tworzone przez sterownik, wystarczy określić networkEndpointType: privateEndpoint parametr w klasie magazynu. Sterownik CSI tworzy prywatny punkt końcowy i prywatną strefę DNS (o nazwie privatelink.blob.core.windows.net) wraz z kontem. Jeśli używasz własnego konta magazynu, musisz utworzyć prywatny punkt końcowy dla konta magazynu. Jeśli używasz usługi Azure Blob Storage w izolowanym klastrze sieciowym, musisz utworzyć niestandardową klasę magazynu za pomocą polecenia networkEndpointType: privateEndpoint.

Możesz użyć uwierzytelniania za pomocą tożsamości zarządzanej lub nazwy głównego użytkownika usługi (SPN) z BlobFuse. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie przy użyciu tożsamości zarządzanej i nazwy głównej usługi.

Aby włączyć usługę BlobFuse, możesz użyć następujących parametrów, aby odczytać klucz konta lub token SAS bezpośrednio z usługi Azure Key Vault.

PVC automatycznie przydziela pamięć masową na podstawie klasy pamięci masowej. W takim przypadku PVC może użyć jednej ze wstępnie utworzonych klas magazynu do utworzenia dysku zarządzanego platformy Azure w warstwie Standardowa lub Premium.

1. Utwórz plik o nazwie azure-pvc.yaml i skopiuj go w następującym manifeście. Oświadczenie żąda dysku o nazwie azure-managed-disk o rozmiarze 5 GB z dostępem ReadWriteOnce. Klasa przechowywania managed-csi jest określona jako klasa przechowywania.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
       name: azure-managed-disk
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: managed-csi
     resources:
       requests:
         storage: 5Gi
   

   Wskazówka

   Aby utworzyć dysk korzystający z magazynu w warstwie Premium, użyj storageClassName: managed-csi-premium zamiast managed-csi.

2. Utwórz żądanie trwałego woluminu za pomocą polecenia kubectl apply i określ plik azure-pvc.yaml.

   kubectl apply -f azure-pvc.yaml
   

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

   persistentvolumeclaim/azure-managed-disk created
   

Zastosowanie PVC do poda

Po utworzeniu żądania trwałego woluminu należy upewnić się, że ma on stan Pending. Stan Pending wskazuje, że jest gotowy do użycia przez zasobnik.

1. Zweryfikuj status PVC za pomocą polecenia kubectl describe pvc.

   kubectl describe pvc azure-managed-disk
   

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

   Name:            azure-managed-disk
   Namespace:       default
   StorageClass:    managed-csi
   Status:          Pending
   [...]
   

2. Utwórz plik o nazwie azure-pvc-disk.yaml i skopiuj go w następującym manifeście. Ten manifest tworzy podstawowy pod NGINX, który używa żądania trwałego woluminu o nazwie azure-managed-disk do zamontowania dysku Azure na ścieżce /mnt/azure. W przypadku kontenerów systemu Windows Server określ konwencję mountPath ścieżki systemu Windows, taką jak "D:".

   kind: Pod
   apiVersion: v1
   metadata:
     name: mypod
   spec:
     containers:
       - name: mypod
         image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - mountPath: "/mnt/azure"
             name: volume
             readOnly: false
     volumes:
       - name: volume
         persistentVolumeClaim:
           claimName: azure-managed-disk
   

3. Utwórz pod przy użyciu polecenia kubectl apply.

   kubectl apply -f azure-pvc-disk.yaml
   

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

   pod/mypod created
   

4. Masz teraz uruchomiony zasobnik z zamontowanym dyskiem /mnt/azure Azure w katalogu. Sprawdź konfigurację zasobnika za pomocą polecenia kubectl describe.

   kubectl describe pod mypod
   

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

   [...]
   Volumes:
     volume:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  azure-managed-disk
       ReadOnly:   false
      default-token-smm2n:
       Type:        Secret (a volume populated by a Secret)
       SecretName:  default-token-smm2n
       Optional:    false
   [...]
    Events:
     Type    Reason                 Age   From                               Message
     ----    ------                 ----  ----                               -------
     Normal  Scheduled              2m    default-scheduler                  Successfully assigned mypod to aks-nodepool1-79590246-0
     Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-79590246-0  MountVolume.SetUp succeeded for volume "default-token-smm2n"
     Normal  SuccessfulMountVolume  1m    kubelet, aks-nodepool1-79590246-0  MountVolume.SetUp succeeded for volume "pvc-faf0f176-8b8d-11e8-923b-deb28c58d242"
   [...]
   

Podczas tworzenia dysku platformy Azure do użycia z usługą AKS można utworzyć zasób dysku w grupie zasobów węzła. Takie podejście umożliwia klastrowi usługi AKS uzyskiwanie dostępu do zasobu dysku i zarządzanie nim. Jeśli zamiast tego utworzysz dysk w oddzielnej grupie zasobów, musisz przyznać tożsamości zarządzanej usługi Azure Kubernetes Service (AKS) dla klastra Contributor rolę do grupy zasobów dysku.

1. Zidentyfikuj nazwę grupy zasobów przy użyciu az aks show polecenia i dodaj --query nodeResourceGroup parametr .

   az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
   

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

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Utwórz dysk przy użyciu az disk create polecenia . Określ nazwę grupy zasobów węzła i nazwę zasobu dysku, na przykład myAKSDisk. Poniższy przykład tworzy dysk 20 GiB i generuje identyfikator dysku po utworzeniu. Jeśli musisz utworzyć dysk do użycia z kontenerami systemu Windows Server, dodaj --os-type windows parametr w celu poprawnego sformatowania dysku.

   az disk create \
     --resource-group MC_myResourceGroup_myAKSCluster_eastus \
     --name myAKSDisk \
     --size-gb 20 \
     --query id --output tsv
   

   Uwaga / Notatka

   Opłaty za dyski Azure są naliczane na podstawie SKU dla określonego rozmiaru. Te jednostki SKU wahają się od 32GiB dla dysków S4 lub P4 do 32TiB dla dysków S80 lub P80 (w wersji zapoznawczej). Wydajność przepływności i liczby operacji we/wy na sekundę dysku zarządzanego w warstwie Premium zależy zarówno od jednostki SKU, jak i rozmiaru wystąpienia węzłów w klastrze usługi AKS. Zobacz Cennik i wydajność Dyski zarządzane.

   Identyfikator zasobu dysku jest wyświetlany po pomyślnym zakończeniu polecenia, jak pokazano w poniższych przykładowych danych wyjściowych. Identyfikator dysku służy do instalowania dysku w następnej sekcji.

   /subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
   

Zamontuj dysk jako wolumin

1. Utwórz plik pv-azuredisk.yaml z PV. Zaktualizuj volumeHandle za pomocą identyfikatora zasobu dysku z poprzedniego kroku. W przypadku kontenerów systemu Windows Server określ ntfs dla parametru fsType.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: disk.csi.azure.com
     name: pv-azuredisk
   spec:
     capacity:
       storage: 20Gi
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     storageClassName: managed-csi
     csi:
       driver: disk.csi.azure.com
       volumeHandle: /subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
       volumeAttributes:
         fsType: ext4
   

Jeśli dysk dla volumeHandle został utworzony w oddzielnej grupie zasobów, musisz przyznać zarządzanej tożsamości klastra AKS rolę Contributor w grupie zasobów dla dysku.

1. Utwórz plik pvc-azuredisk.yaml z PVC, który używa PV.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-azuredisk
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 20Gi
     volumeName: pv-azuredisk
     storageClassName: managed-csi
   

2. Utwórz pv i PVC przy użyciu kubectl apply polecenia i odwołaj się do dwóch utworzonych plików YAML:

   kubectl apply -f pv-azuredisk.yaml
   kubectl apply -f pvc-azuredisk.yaml
   

3. Sprawdź, czy Twój PVC został utworzony i powiązany z PV za pomocą polecenia kubectl get pvc:

   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    pv-azuredisk   20Gi        RWO                           5s
   

4. Utwórz plik azure-disk-pod.yaml, aby odwołać się do pliku PersistentVolumeClaim. W przypadku kontenerów systemu Windows Server podaj ścieżkę używając konwencji ścieżki systemu Windows, na przykład "D:".

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
     - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
       name: mypod
       resources:
         requests:
           cpu: 100m
           memory: 128Mi
         limits:
           cpu: 250m
           memory: 256Mi
       volumeMounts:
         - name: azure
           mountPath: /mnt/azure
     volumes:
       - name: azure
         persistentVolumeClaim:
           claimName: pvc-azuredisk
   

5. Zastosuj konfigurację i zainstaluj wolumin przy kubectl apply użyciu polecenia .

   kubectl apply -f azure-disk-pod.yaml
   

Następujące parametry dotyczą tylko wersji 2.

Klasa przechowywania służy do definiowania sposobu tworzenia udziału plików w usłudze Azure. Konto magazynowe jest tworzone automatycznie w grupie zasobów węzła do wykorzystania z klasą magazynową do przechowywania zasobu plików Azure. Wybierz jedną z następujących opcji SKU dla redundancji Azure Storage dla skuName:

• Standard_LRS: Standardowa lokalna nadmiarowość przechowywania
• Standard_GRS: Standardowa pamięć geograficznie z nadmiarową dostępnością
• Standard_ZRS: magazyn strefowy redundantny Standard
• Standard_RAGRS: magazyn geograficznie nadmiarowy z dostępem do odczytu w warstwie Standardowa
• Standard_RAGZRS: standardowy geograficznie nadmiarowy magazyn z dostępem tylko do odczytu
• Premium_LRS: magazyn lokalnie nadmiarowy w warstwie Premium
• Premium_ZRS: strefowo nadmiarowa pamięć Premium

Aby uzyskać więcej informacji na temat klas magazynu kubernetes dla usługi Azure Files, zobacz Klasy magazynu Kubernetes.

1. Utwórz plik o nazwie azure-file-sc.yaml i skopiuj w poniższym przykładowym manifeście. Aby uzyskać więcej informacji na temat mountOptionsprogramu , zobacz sekcję Opcje instalacji .

   kind: StorageClass
   apiVersion: storage.k8s.io/v1
   metadata:
     name: my-azurefile
   provisioner: file.csi.azure.com # replace with "kubernetes.io/azure-file" if aks version is less than 1.21
   allowVolumeExpansion: true
   mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=0
    - gid=0
    - mfsymlinks
    - cache=strict
    - actimeo=30
    - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
   parameters:
     skuName: Premium_LRS
   

2. Utwórz klasę magazynu przy użyciu polecenia kubectl apply.

   kubectl apply -f azure-file-sc.yaml
   

Utwórz PVC

PVC używa obiektu klasy magazynu do dynamicznego aprowizowania udziału plików w usłudze Azure. Możesz użyć następującego kodu YAML, aby utworzyć PVC o rozmiarze 100 GB z dostępem ReadWriteMany. Aby uzyskać więcej informacji na temat trybów dostępu, zobacz Kubernetes trwały wolumin.

1. Utwórz plik o nazwie azure-file-pvc.yaml i skopiuj go w następującym języku YAML. Upewnij się, że storageClassName odpowiada klasie magazynu utworzonej w poprzednim kroku.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: my-azurefile
     resources:
       requests:
         storage: 100Gi
   

   Uwaga / Notatka

   Jeśli używasz Premium_LRS SKU dla klasy przechowywania, minimalną wartością storage powinna być 100Gi.

2. Utwórz PVC przy użyciu kubectl apply polecenia.

   kubectl apply -f azure-file-pvc.yaml
   

   Po zakończeniu zostanie utworzone udostępnianie plików. Zostanie również utworzony sekret Kubernetes, który zawiera informacje o połączeniu i poświadczenia. Możesz użyć kubectl get polecenia , aby wyświetlić stan PCV:

   kubectl get pvc my-azurefile
   

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

   NAME           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
   my-azurefile   Bound     pvc-8436e62e-a0d9-11e5-8521-5a8664dc0477   100Gi       RWX           my-azurefile      5m
   

Zamontuj PCV

Poniższy kod YAML tworzy zasobnik, który używa pliku my-azurefile PVC do zainstalowania udziału plików usługi Azure Files w ścieżce /mnt/azure . W przypadku kontenerów systemu Windows Server podaj ścieżkę używając konwencji ścieżki systemu Windows, na przykład "D:".

1. Utwórz plik o nazwie azure-pvc-files.yamli skopiuj go w następującym pliku YAML. Upewnij się, że element claimName odpowiada elementowi PVC utworzonemu w poprzednim kroku.

   kind: Pod
   apiVersion: v1
   metadata:
     name: mypod
   spec:
     containers:
       - name: mypod
         image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - mountPath: /mnt/azure
             name: volume
             readOnly: false
     volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: my-azurefile
   

2. Utwórz pod przy użyciu polecenia kubectl apply.

   kubectl apply -f azure-pvc-files.yaml
   

   Masz teraz uruchomiony zasobnik z udziałem plików usługi Azure Files zainstalowanym w katalogu /mnt/azure . Tę konfigurację można zobaczyć podczas inspekcji zasobnika przy użyciu polecenia kubectl describe. Następujące skrócone przykładowe dane wyjściowe pokazują wolumin zainstalowany w kontenerze.

   Containers:
     mypod:
       Container ID:   docker://053bc9c0df72232d755aa040bfba8b533fa696b123876108dec400e364d2523e
       Image:          mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
       Image ID:       docker-pullable://nginx@sha256:d85914d547a6c92faa39ce7058bd7529baacab7e0cd4255442b04577c4d1f424
       State:          Running
         Started:      Fri, 01 Mar 2019 23:56:16 +0000
       Ready:          True
       Mounts:
         /mnt/azure from volume (rw)
         /var/run/secrets/kubernetes.io/serviceaccount from default-token-8rv4z (ro)
   [...]
   Volumes:
     volume:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  my-azurefile
       ReadOnly:   false
   [...]
   

Opcje montowania

W przypadku platformy Kubernetes w wersji 1.13.0 lub nowszej wartości domyślne dla fileMode i dirMode to 0777. Podczas dynamicznego przydzielania trwałych woluminów przy użyciu klasy magazynu można zdefiniować opcje montowania bezpośrednio w manifeście klasy magazynu. Aby uzyskać szczegółowe informacje, zobacz Opcje instalacji. W poniższym przykładzie pokazano ustawienie tych uprawnień na :0777

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com # replace with "kubernetes.io/azure-file" if aks version is less than 1.21
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
parameters:
  skuName: Premium_LRS

Ta sekcja zawiera wskazówki dla administratorów klastra, którzy chcą utworzyć jeden lub więcej PV (Persistent Volume) zawierających szczegóły istniejącego udziału Azure Files do używania z obciążeniami.

Tworzenie udziału usługi Azure Files

Aby można było użyć udziału plików usługi Azure Files jako woluminu Kubernetes, musisz utworzyć konto usługi Azure Storage i udział plików.

1. Pobierz nazwę grupy zasobów przy użyciu polecenia az aks show z parametrem --query nodeResourceGroup.

   az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
   

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

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Utwórz konto magazynu za pomocą polecenia az storage account create z parametrem --sku. Następujące polecenie tworzy konto magazynowe przy użyciu Standard_LRS klasy SKU. Upewnij się, że zastąpisz następujące elementy zastępcze:

   • myAKSStorageAccount z nazwą konta magazynowego
   • nodeResourceGroupName z nazwą grupy zasobów, w której znajdują się węzły klastra usługi AKS
   • location z nazwą regionu, w którym ma zostać utworzony zasób. Powinien on być tym samym regionem co węzły klastra usługi AKS.

   az storage account create -n myAKSStorageAccount -g nodeResourceGroupName -l location --sku Standard_LRS
   

3. Wyeksportuj łańcuch połączenia jako zmienną środowiskową przy użyciu następującego polecenia, jakiego użyjesz do utworzenia udziału plików.

   export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string -n storageAccountName -g resourceGroupName -o tsv)
   

   Parametry połączenia muszą być chronione przy użyciu rotacji kluczy lub magazynu w usłudze Azure Key Vault. Aby uzyskać więcej informacji na temat parametrów połączenia, zobacz Konfigurowanie parametrów połączenia usługi Azure Storage i Zarządzanie kluczami dostępu do konta magazynu.

   W przypadku środowisk produkcyjnych firma Microsoft zaleca korzystanie z uwierzytelniania identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu do danych w usłudze Azure Storage.

4. Utwórz udział plików za pomocą polecenia az storage share create. Pamiętaj, aby zastąpić shareName nazwą udziału.

   az storage share create -n shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
   

5. Wyeksportuj klucz konta magazynu jako zmienną środowiskową przy użyciu następującego polecenia.

   STORAGE_KEY=$(az storage account keys list --resource-group nodeResourceGroupName --account-name myAKSStorageAccount --query "[0].value" -o tsv)
   

6. Wyświetl nazwę i klucz konta przechowywania przy użyciu następującego polecenia. Skopiuj te informacje, ponieważ te wartości są potrzebne podczas tworzenia woluminu Kubernetes.

   echo Storage account key: $STORAGE_KEY
   

Utwórz sekret Kubernetes

Kubernetes potrzebuje poświadczeń, aby uzyskać dostęp do zasobu plikowego utworzonego w poprzednim kroku. Te poświadczenia są przechowywane w wpisie tajnym kubernetes, do którego odwołuje się podczas tworzenia zasobnika Kubernetes.

1. Utwórz tajemnicę za pomocą polecenia kubectl create secret. Poniższy przykład tworzy wpis tajny o nazwie azure-secret i wypełnia parametry azurestorageaccountname i azurestorageaccountkey z poprzedniego kroku. Aby użyć istniejącego konta usługi Azure Storage, podaj nazwę konta i klucz.

   kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=myAKSStorageAccount --from-literal=azurestorageaccountkey=$STORAGE_KEY
   

Instalowanie udziału plików jako pv

1. Utwórz nowy plik o nazwie azurefiles-pv.yaml i skopiuj do poniższej zawartości. W obszarze csi, zaktualizuj resourceGroup, volumeHandle, i shareName. W przypadku opcji instalacji domyślną wartością fileMode i dirMode jest 0777.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: file.csi.azure.com
     name: azurefile
   spec:
     capacity:
       storage: 5Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     storageClassName: azurefile-csi
     csi:
       driver: file.csi.azure.com
       volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"  # make sure this volumeid is unique for every identical share in the cluster
       volumeAttributes:
         shareName: aksshare
       nodeStageSecretRef:
         name: azure-secret
         namespace: default
     mountOptions:
       - dir_mode=0777
       - file_mode=0777
       - uid=0
       - gid=0
       - mfsymlinks
       - cache=strict
       - nosharesock
       - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
   

2. Utwórz PV za pomocą polecenia kubectl create.

   kubectl create -f azurefiles-pv.yaml
   

3. Utwórz nowy plik o nazwie azurefiles-mount-options-pvc.yaml i skopiuj następującą zawartość.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: azurefile-csi
     volumeName: azurefile
     resources:
       requests:
         storage: 5Gi
   

4. Utwórz PVC za pomocą polecenia kubectl apply.

   kubectl apply -f azurefiles-mount-options-pvc.yaml
   

5. Sprawdź, czy PVC został utworzony i powiązany z PV przy użyciu polecenia kubectl get.

   kubectl get pvc azurefile
   

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

   NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
   

6. Zaktualizuj specyfikację kontenera, aby odwołać się do Twojego PVC i poda w pliku YAML. Przykład:

   ...
     volumes:
     - name: azure
       persistentVolumeClaim:
         claimName: azurefile
   

7. Nie można zaktualizować specyfikacji zasobnika, dlatego usuń zasobnik, używając polecenia kubectl delete, i utwórz go ponownie, korzystając z polecenia kubectl apply.

   kubectl delete pod mypod
   
   kubectl apply -f azure-files-pod.yaml
   

Zamontuj udział plików jako wbudowany wolumin

Aby zainstalować udział plików usługi Azure Files w zasobniku, należy skonfigurować wolumin w specyfikacji kontenera.

1. Utwórz nowy plik o nazwie azure-files-pod.yaml i skopiuj do poniższej zawartości. Jeśli zmieniono nazwę udziału plików lub nazwę wpisu tajnego, zaktualizuj elementy shareName i secretName. Można również zaktualizować element mountPath, czyli ścieżkę, w której znajduje się dysk współdzielony Files zamontowany w podzie. W przypadku kontenerów systemu Windows Server określ konwencję mountPath ścieżki systemu Windows, taką jak D:/.

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
       - image: 'mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine'
         name: mypod
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - name: azure
             mountPath: /mnt/azure
             readOnly: false
     volumes:
       - name: azure
         csi:
           driver: file.csi.azure.com
           volumeAttributes:
             secretName: azure-secret  # required
             shareName: aksshare  # required
             mountOptions: 'dir_mode=0777,file_mode=0777,cache=strict,actimeo=30,nosharesock,nobrl'  # optional
   

2. Utwórz pod przy użyciu polecenia kubectl apply.

   kubectl apply -f azure-files-pod.yaml
   

   Masz teraz uruchomiony zasobnik z udziałem plików usługi Azure Files zainstalowanym w folderze /mnt/azure. Możesz zweryfikować, czy udział został pomyślnie zainstalowany, przy użyciu polecenia kubectl describe.

   kubectl describe pod mypod
   

Poniższa tabela zawiera parametry, których można użyć do zdefiniowania niestandardowej klasy przechowywania dla twojego PVC.

¹ Jeśli konto magazynu jest tworzone przez sterownik, wystarczy określić networkEndpointType: privateEndpoint parametr w klasie magazynu. Sterownik CSI tworzy prywatny punkt końcowy i prywatną strefę DNS (o nazwie privatelink.file.core.windows.net) wraz z kontem. Jeśli używasz własnego konta magazynu, musisz utworzyć prywatny punkt końcowy dla konta magazynu. Jeśli używasz usługi Azure Files w izolowanym klastrze sieciowym, musisz utworzyć niestandardową klasę magazynu z parametrem "networkEndpointType: privateEndpoint". Możesz skorzystać z tego przykładu w celu uzyskania informacji referencyjnych:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - 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
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Następujące parametry dotyczą tylko protokołu SMB.

Następujące parametry dotyczą tylko protokołu NFS.

Następujące parametry dotyczą tylko ustawień sieci wirtualnej, takich jak NFS i prywatny punkt końcowy.

Poniższa tabela zawiera parametry, których można użyć do zdefiniowania pv.

Następujące parametry dotyczą tylko protokołu SMB.

Następujące parametry dotyczą tylko protokołu NFS.

Aby włączyć tożsamość zarządzaną dla dynamicznie aprowizowanych woluminów, wykonaj następujące kroki:

1. Utwórz klasę magazynu z włączoną tożsamością zarządzaną przy użyciu pliku YAML, azurefile-csi-managed-identity.yaml z następującą zawartością przykładową. Ustaw mountWithManagedIdentity: "true" w obszarze parameters:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: azurefile-csi
    provisioner: file.csi.azure.com
    parameters:
      resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
      storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
      mountWithManagedIdentity: "true"
      # optional, clientID of the managed identity, kubelet identity would be used by default if it's not provided
      clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    allowVolumeExpansion: true
    mountOptions:
     - dir_mode=0777  # modify this permission if you want to enhance the security
     - 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
     - nobrl  # disable sending byte range lock requests to the server
   

2. Zastosuj tę klasę magazynu, uruchamiając następujące polecenie:

   kubectl apply -f azurefile-csi-managed-identity.yaml
   

3. Wdróż StatefulSet lub obciążenie przy użyciu nowej klasy pamięci, która odwołuje się do tego PVC, aby upewnić się, że wolumin jest aprowizowany przy użyciu uwierzytelniania tożsamości zarządzanej. W manifeście PVC ustaw wartość storageClassName: azurefile-csi-managed-identity. Przykład:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile-managed-identity-pvc
   spec:
     accessModes:
      - ReadWriteMany
     storageClassName: azurefile-csi-managed-identity
     resources:
      requests:
       storage: 100Gi
   

Aby włączyć tożsamość zarządzaną dla woluminów aprowizowanych statycznie, wykonaj następujące kroki:

1. Utwórz manifest PV, na przykład azurefile-csi-static.yaml. Zdefiniuj wolumin trwały (PV), który odwołuje się do istniejącego udziału usługi Azure Files i włącz uwierzytelnianie za pomocą zarządzanej tożsamości poprzez ustawienie w obszarze mountWithManagedIdentity: "true"volumeAttributes.

   Przykładowy manifest PV:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-azurefile
   spec:
     capacity:
       storage: 100Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     storageClassName: azurefile-csi
     mountOptions:
       - dir_mode=0777  # modify this permission if you want to enhance the security
       - 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
       - nobrl  # disable sending byte range lock requests to the server
     csi:
       driver: file.csi.azure.com
       # make sure volumeHandle is unique for every identical share in the cluster
       volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
       volumeAttributes:
         resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
         storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
         shareName: EXISTING_FILE_SHARE_NAME
         mountWithManagedIdentity: "true"
         # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
         clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
   

2. Aby wdrożyć PV w podzie aplikacji, uruchom następujące polecenie:

   kubectl apply -f azurefile-csi-static.yaml
   

Ta sekcja zawiera informacje na temat podejścia do dostrajania wydajności NFS za pomocą sterownika CSI usługi Azure Files z opcjami rsize (rozmiar odczytu) i wsize (rozmiar zapisu). Opcje rsize i wsize ustawiają maksymalny rozmiar transferu operacji NFS. Jeśli rsize ani wsize nie są określone podczas montowania, klient i serwer negocjują największy rozmiar obsługiwany przez oba. Obecnie zarówno usługa Azure Files, jak i nowoczesne dystrybucje systemu Linux obsługują rozmiary odczytu i zapisu tak duże, jak 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 rsize i wsize może poprawić wydajność NFS w zatłoczonej sieci poprzez wysyłanie mniejszych pakietów dla każdej odpowiedzi na odczyt i żądania zapisu w systemie NFS. Jednak zmniejszenie to może 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, aby znaleźć element rsize i wsize który utrzymuje wydajny transfer pakietów, gdzie nie zmniejsza przepływności i zwiększa opóźnienie.

Na przykład, aby skonfigurować maksymalną rsize i wsize 256-KiB, skonfiguruj klasę pamięci masowej mountOptions 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

1. Utwórz plik o nazwie nfs-sc.yaml i skopiuj przykładowy manifest. Aby uzyskać listę obsługiwanych mountOptionsplików , zobacz Opcje instalacji systemu plików NFS.

   Uwaga / Notatka

   Sterownik CSI usługi Azure File konfiguruje vers, minorversion, i sec. 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
   

2. Po edytowaniu i zapisaniu pliku YAML zastosuj klasę przechowywania 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
   

1. Przykładowy zestaw StatefulSet można wdrożyć przy użyciu następującego manifestu, który zapisuje znaczniki czasu w pliku o nazwie data.txt , uruchamiając polecenie 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
   

2. 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
   ...
   

Ponieważ system plików NFS znajduje się na koncie magazynu w warstwie Premium, minimalny rozmiar udziału plikowego to 100 GiB. W przypadku utworzenia PVC o małej pamięci masowej, może wystąpić błąd podobny do poniższego wyjścia:

*failed to create file share ... size (5)...*.

Dzięki usłudze AKS w wersji 1.33 funkcja szyfrowania w trakcie przesyłania (EiT)Preview zapewnia, że wszystkie operacje odczytu i zapisu w udostępnieniach plików NFS w obrębie sieci wirtualnej są szyfrowane, dostarczając dodatkową warstwę zabezpieczeń.

Ustawiając encryptInTransit: "true" w parametrach klasy magazynu, można włączyć szyfrowanie danych podczas przesyłania dla udziałów plików Azure NFS. Przykład:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  encryptInTransit: "true"
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

Zalecane opcje montowania udziałów SMB są podane w poniższym przykładzie klasy pamięci masowej.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777 # modify this permission if you want to enhance the security
  - mfsymlinks    # support symbolic links
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduces probability of reconnect race
  - actimeo=30  # reduces latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Jeśli korzystasz z udziałów plików w warstwie Premium (SSD), a obciążenie jest duże, zarejestruj się, aby użyć funkcji buforowania metadanych w celu zwiększenia wydajności.

Aby uzyskać więcej informacji, zobacz Poprawa wydajności udziałów plików SMB na platformie Azure.

Zalecane opcje montowania udziałów NFS są przedstawione w następującym przykładzie klasy magazynu.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
  protocol: nfs
  skuName: Premium_LRS     # available values: Premium_LRS, Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - nconnect=4  # improves performance by enabling multiple connections to share
  - noresvport  # improves availability
  - actimeo=30  # reduces latency for metadata-heavy workloads

Przepływność odczytu można zwiększyć, zwiększając rozmiar odczytu z wyprzedzeniem.

Chociaż Azure Files obsługują ustawienie nconnect do maksymalnej wartości 16, zalecamy skonfigurowanie opcji montowania z użyciem wartości optymalnej nconnect=4. Obecnie nie ma żadnych korzyści poza czterema kanałami implementacji usługi Azure Files.nconnect

Aby uzyskać więcej informacji, zobacz Poprawa wydajności udostępniania plików platformy Azure NFS.