Драйвер CSI и подготовка томов службы хранилища Azure

В этом разделе содержатся рекомендации для администраторов кластера, которые хотят подготовить один или несколько постоянных томов, включающих сведения о Blob Storage для использования работой. Запрос на создание постоянного тома (PVC) использует объект класса хранилища для динамического выделения контейнера Blob-хранилища Azure.

Чтобы подготовить постоянный том с использованием Azure Blob Storage и заданного класса хранилища, выполните следующие действия.

1. StorageClass Создайте манифест, сохранив следующий YAML в файл с именем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. Чтобы создать класс хранилища в кластере, выполните StorageClass следующую команду:

   kubectl apply -f blob-fuse-sc.yaml
   

Создание ПВХ с помощью встроенного класса хранилища

Класс хранения используется для определения способа создания контейнера хранилища BLOB-объектов Azure. Для хранения контейнера хранилища BLOB-объектов Azure учетная запись хранения создается автоматически в группе ресурсов узла для использования с классом хранения. Выберите одно из следующих SKU избыточности хранилища Azure для skuName:

• Standard_LRS — стандартное локально избыточное хранилище.
• Premium_LRS — локально избыточное хранилище класса Premium.
• Standard_ZRS: стандартное хранилище с зональной избыточностью
• Premium_ZRS: избыточное хранилище зоны "Премиум"
• Standard_GRS — стандартное геоизбыточное хранилище
• Standard_RAGRS — стандартное геоизбыточное хранилище с доступом только для чтения;

При использовании драйверов CSI хранилища в AKS имеются два других встроенных драйвера для объектов BLOB Azure.

Политика освобождения емкости в обоих классах хранения гарантирует, что базовое хранилище Azure Blob будет удалено при удалении соответствующего постоянного тома. Классы хранения также конфигурируют расширяемость контейнера по умолчанию, поскольку для параметра set allowVolumeExpansion задано значение true.

Используйте команду kubectl get sc, чтобы просмотреть классы хранения. В следующем примере демонстрируются классы хранения azureblob-fuse-premium и azureblob-nfs-premium, доступные для кластера 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

Чтобы использовать эти классы хранения, создайте PVC и соответствующий модуль, который ссылается на них и использует их. ПВХ используется для автоматического выделения хранилища на основе класса хранения. Вы можете создать ПВХ с помощью одного из встроенных классов хранилища или пользовательского класса хранения. Этот ПВХ создает контейнер хранилища BLOB-объектов Azure с указанным номером SKU, размером и протоколом. При создании определения pod указывается PVC для запроса требуемого объема хранилища.

Запрос постоянного тома (PVC) использует объект класса хранилища для динамического выделения контейнера для BLOB-объектов Azure. Следующий YAML можно использовать для создания 5 ГиБ PVC с доступом ReadWriteMany с помощью встроенного класса хранилища. Дополнительные сведения о режимах доступа см. в документации по постоянным томам Kubernetes.

1. Создайте файл с именем blob-nfs-pvc.yaml и скопируйте следующий YAML:

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

2. Создайте ПВХ с помощью команды создания kubectl :

   kubectl create -f blob-nfs-pvc.yaml
   

После его завершения создается контейнер хранилища BLOB-объектов. Команду kubectl get можно использовать для просмотра состояния ПВХ:

kubectl get pvc azure-blob-storage

Выходные данные команды будут выглядеть примерно так:

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

Установите ПВХ

В следующем YAML создается pod, использующий ПВХ azure-blob-storage для монтажа хранилища Azure Blob по пути /mnt/blob.

1. Создайте файл с именем blob-nfs-pvи скопируйте следующий YAML. Убедитесь, что имя утверждения соответствует ПВХ, созданному на предыдущем шаге.

   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. Создайте pod командой kubectl apply

   kubectl apply -f blob-nfs-pv.yaml
   

3. После того как модуль pod находится в состоянии выполнения, выполните следующую команду, чтобы создать новый файл test.txt.

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

4. Чтобы проверить правильность подключения диска, выполните следующую команду и убедитесь, что в выходных данных отображается файл test.txt.

   kubectl exec mypod -- ls /mnt/blob
   

   Выходные данные команды будут выглядеть примерно так:

   test.txt
   

В этом разделе содержатся рекомендации для администраторов кластера, которые хотят создать один или несколько PV, включающих сведения о хранилище блобов для использования рабочей нагрузкой.

Создайте контейнер для хранилища BLOB

При создании ресурса хранилища BLOB-объектов Azure для использования с AKS можно создать ресурс в группе ресурсов узла. Такой подход позволяет кластеру AKS получать доступ к ресурсу Blob-хранилища и управлять им.

В этой статье создайте контейнер в группе ресурсов узла. Сначала с помощью команды az aks show получите имя группы ресурсов и добавьте параметр --query nodeResourceGroup запроса. В следующем примере определяется группа ресурсов для узлов для кластера AKS с именем myAKSCluster в группе ресурсов с именем myResourceGroup:

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

Выходные данные команды будут выглядеть примерно так:

MC_myResourceGroup_myAKSCluster_eastus

Затем создайте контейнер для хранения BLOB-объектов, выполнив действия, описанные в разделе Управление хранилищем BLOB-объектов, чтобы авторизовать доступ и создать контейнер.

В этом примере следующий манифест настраивает монтирование контейнера объектного хранилища Blob с помощью протокола NFS. Используйте его для добавления tags параметра.

1. Создайте файл с именем blob-nfs-sc.yaml и вставьте в него следующий пример манифеста.

   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. Создайте класс хранилища с помощью команды kubectl apply :

   kubectl apply -f blob-nfs-sc.yaml
   

   Выходные данные команды будут выглядеть примерно так:

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

В этом примере следующий манифест настраивает использование BlobFuse и монтирует контейнер блоб-объектов. Используйте его для обновления параметра skuName .

1. Создайте файл с именем blobfuse-sc.yaml и вставьте следующий пример манифеста:

   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. Создайте класс хранилища с помощью команды kubectl apply :

   kubectl apply -f blobfuse-sc.yaml
   

   Выходные данные команды будут выглядеть примерно так:

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

Подключение хранилища Blob с помощью протокола NFS версии 3 не поддерживает аутентификацию с использованием ключа учетной записи. Кластер AKS должен находиться в той же или одноранговой виртуальной сети, что и узел агента. Единственным способом защиты данных в учетной записи хранения является использование виртуальной сети и других параметров безопасности сети. Для получения дополнительной информации о настройке доступа к учетной записи хранения через NFS см. статью «Монтирование Blob-хранилища с использованием протокола Network File System (NFS) 3.0».

В следующем примере показано, как подключить контейнер хранилища Blob как постоянный том с помощью протокола NFS.

1. Создайте файл pv-blob-nfs.yaml и скопируйте в него следующий код YAML. В объекте storageClass измените resourceGroup, storageAccount и containerName.

   Замечание

   Значение volumeHandle в вашем YAML должно быть уникальным идентификатором тома для каждого аналогичного контейнера объектов BLOB-хранилища в кластере.

   Символы # и / зарезервированы для внутреннего использования и не могут быть использованы.

   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
   

   Замечание

   Хотя атрибут емкостиAPI Kubernetes является обязательным, это значение не используется драйвером CSI хранилища BLOB-объектов Azure, так как вы можете гибко записывать данные, пока не достигнете предела емкости учетной записи хранения. Значение атрибута capacity используется только для сопоставления размера между PVs и PVCs. Рекомендуется использовать вымышленное высокое значение. Модуль pod видит подключенный том с вымышленным размером 5 Петабайт.

2. Выполните следующую команду, чтобы создать постоянный том с помощью команды kubectl create , ссылающейся на файл YAML, созданный ранее:

   kubectl create -f pv-blob-nfs.yaml
   

3. pvc-blob-nfs.yaml Создайте файл с помощью PersistentVolumeClaim. Рассмотрим пример.

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

4. Выполните следующую команду, чтобы создать запрос на постоянный том с помощью команды kubectl create ссылающейся на файл YAML, созданный ранее.

   kubectl create -f pvc-blob-nfs.yaml
   

Kubernetes требует учетных данных для доступа к контейнеру хранилища объектов BLOB, созданному ранее, как ключ доступа Azure, так и маркеры SAS. Эти учетные данные хранятся в секрете Kubernetes, на который ссылается при создании модуля Pod Kubernetes.

1. Используйте kubectl create secret command, чтобы создать секрет. Вы можете пройти проверку подлинности с помощью секрета Kubernetes или токенов общего доступа (SAS). Необходимо также указать имя и ключ учетной записи из существующей учетной записи хранения Azure.

   • Секрет Kubernetes
   • Маркеры SAS

   В следующем примере создается объект Secret с именем azure-secret и заполняется параметрами azurestorageaccountname и azurestorageaccountkey.

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

2. Создайте файл pv-blobfuse.yaml . В разделе volumeAttributes, обновите containerName. В разделе nodeStateSecretRef обновите name с именем ранее созданного объекта Secret. Рассмотрим пример.

   Замечание

   Значение volumeHandle в вашем YAML должно быть уникальным идентификатором тома для каждого аналогичного контейнера объектов BLOB-хранилища в кластере.

   Символы # и / зарезервированы для внутреннего использования и не могут быть использованы.

   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. Выполните следующую команду, чтобы создать PV с помощью команды kubectl create, ссылающейся на файл YAML, созданный ранее:

   kubectl create -f pv-blobfuse.yaml
   

4. pvc-blobfuse.yaml Создайте файл с помощью PV. Рассмотрим пример.

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

5. Выполните следующую команду, чтобы создать ПВХ с помощью команды kubectl create , ссылающейся на файл YAML, созданный ранее:

   kubectl create -f pvc-blobfuse.yaml
   

1. Создайте файл azure-blob-nfs-ss.yaml и скопируйте в него следующий код 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. Создайте StatefulSet с kubectl create помощью команды:

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

1. Создайте файл azure-blobfuse-ss.yaml и скопируйте в него следующий код 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. Создайте StatefulSet с kubectl create помощью команды:

   kubectl create -f azure-blobfuse-ss.yaml
   

¹ Если учетная запись хранения создается драйвером, необходимо указать networkEndpointType: privateEndpoint только параметр в классе хранилища. Драйвер CSI создает частную конечную точку и частную зону DNS (именованную privatelink.blob.core.windows.net) вместе с учетной записью. Если у вас есть собственная учетная запись хранения, необходимо создать частную конечную точку для аккаунта хранения. Если вы используете хранилище BLOB-объектов Azure в изолированном сетевом кластере, необходимо создать пользовательский класс хранилища с помощью networkEndpointType: privateEndpoint.

Вы можете использовать проверку подлинности управляемого удостоверения или имени субъекта-службы (SPN) с blobFuse. Дополнительные сведения см. в разделе Управляемая идентификация и Имя основного пользователя службы.

Вы можете использовать следующие параметры, чтобы настроить BlobFuse для чтения ключа учетной записи или маркера SAS непосредственно из Azure Key Vault.

ПВХ автоматически подготавливает хранилище на основе класса хранения. В этом случае ПВХ может использовать один из предварительно созданных классов хранилища для создания управляемого диска Azure уровня "Стандартный" или "Премиум".

1. Создайте файл azure-pvc.yaml и скопируйте в него следующий манифест. Запрос на диск с именем azure-managed-disk, размером 5 GB и доступом ReadWriteOnce. managed-csi указан как класс хранения.

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

   Подсказка

   Чтобы создать диск, который использует хранилище уровня "Премиум", используйте класс storageClassName: managed-csi-premium вместо managed-csi.

2. Создайте утверждение постоянного тома с помощью kubectl apply команды и укажите файл azure-pvc.yaml .

   kubectl apply -f azure-pvc.yaml
   

   Выходные данные команды будут выглядеть примерно так:

   persistentvolumeclaim/azure-managed-disk created
   

Применение PVC к модулю pod

После создания утверждения постоянного тома необходимо проверить состояние Pending. Состояние Pending указывает, что оно готово к использованию модулем pod.

1. Проверьте состояние ПВХ с помощью kubectl describe pvc команды.

   kubectl describe pvc azure-managed-disk
   

   Выходные данные команды похожи на следующий сжатый пример:

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

2. Создайте файл azure-pvc-disk.yaml и скопируйте в него следующий манифест. Этот манифест создает базовый модуль NGINX pod, который использует запрос постоянного тома с именем azure-managed-disk для монтирования диска Azure в путь /mnt/azure. Для контейнеров Windows Server укажите mountPath соглашение о пути Windows, например "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. Создайте pod с помощью команды kubectl apply.

   kubectl apply -f azure-pvc-disk.yaml
   

   Выходные данные команды будут выглядеть примерно так:

   pod/mypod created
   

4. Теперь у вас есть работающий pod с диском Azure, подключенным к каталогу /mnt/azure. Проверьте конфигурацию pod с помощью kubectl describe команды.

   kubectl describe pod mypod
   

   Выходные данные команды будут выглядеть примерно так:

   [...]
   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"
   [...]
   

При создании диска Azure для использования с AKS можно создать ресурс диска в группе ресурсов узла. Такой подход позволит кластеру AKS получить доступ к ресурсу диска и управлять им. Если вместо этого вы создадите диск в отдельной группе ресурсов, необходимо предоставить настроенному для кластера управляемому удостоверению Службы Azure Kubernetes (AKS) роль Contributor в группе ресурсов с этим диском.

1. Определите имя группы ресурсов с помощью az aks show команды и добавьте --query nodeResourceGroup этот параметр.

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

   Выходные данные команды будут выглядеть примерно так:

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Создайте диск с помощью az disk create команды. Укажите имя группы ресурсов узла и имя ресурса диска, например myAKSDisk. В следующем примере создается диск 20 ГиБ и выводится идентификатор диска после создания. Если вы намерены использовать этот диск с контейнерами Windows Server, добавьте параметр --os-type windows для правильного форматирования диска.

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

   Замечание

   Плата за диски Azure взимается на основе номера SKU для определенного размера. Эти номера SKU варьируются от 32 ГиБ для дисков S4 или P4 и до 32 ТиБ для дисков S80 или P80 (в предварительной версии). Число операций ввода-вывода в секунду и пропускная способность управляемого диска (цен. категория "Премиум") зависят как от номера SKU, так и от размера экземпляров узлов в кластере AKS. Дополнительные сведения см. на странице Цены на управляемые диски.

   Идентификатор ресурса диска отображается после успешного завершения команды, как показано в следующем примере выходных данных. Идентификатор диска используется для подключения диска в следующем разделе.

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

Подключите диск как том

1. Создайте файл pv-azuredisk.yaml с помощью PV. Обновите volumeHandle с использованием идентификатора ресурса диска из предыдущего шага. Для контейнеров Windows Server укажите NTFS для параметра 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
   

Если диск для volumeHandle был создан в отдельной группе ресурсов, необходимо предоставить управляемой идентичности кластера AKS роль Contributor к группе ресурсов диска.

1. Создайте файл pvc-azuredisk.yaml с PVC, который использует PV.

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

2. Создайте PV и PVC с помощью команды kubectl apply и сошлитесь на два созданных вами файла YAML.

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

3. Убедитесь, что ваш ПВХ создан и привязан к PV с помощью kubectl get pvc команды:

   kubectl get pvc pvc-azuredisk
   

   Выходные данные команды будут выглядеть примерно так:

   NAME            STATUS   VOLUME         CAPACITY    ACCESS MODES   STORAGECLASS   AGE
   pvc-azuredisk   Bound    pv-azuredisk   20Gi        RWO                           5s
   

4. Создайте файл azure-disk-pod.yaml, чтобы ссылаться на файл PersistentVolumeClaim. Для контейнеров Windows Server укажите mountPath с использованием формата пути Windows, например "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. Примените конфигурацию и подключите том с помощью kubectl apply команды.

   kubectl apply -f azure-disk-pod.yaml
   

Следующие параметры предназначены только для версии 2.

Класс хранения используется для определения того, как создается файловое хранилище Azure. Хранилищная учетная запись автоматически создается в группе ресурсов узлов для использования с классом хранилища для хранения общего ресурса файлов Azure. Выберите один из следующих вариантов избыточности хранилища Azure для skuName:

• Standard_LRS — стандартное локально избыточное хранилище.
• Standard_GRS — стандартное геоизбыточное хранилище
• Standard_ZRS: стандартное зонально-избыточное хранилище
• Standard_RAGRS — стандартное геоизбыточное хранилище с доступом только для чтения;
• Standard_RAGZRS: стандартное хранилище с геозонной избыточностью для чтения
• Premium_LRS — локально избыточное хранилище класса Premium.
• Premium_ZRS: избыточное зональное хранилище уровня "премиум"

Дополнительные сведения о классах хранения Kubernetes для файлов Azure см. в разделе о классах хранения Kubernetes.

1. Создайте файл под названием azure-file-sc.yaml и скопируйте в него следующий пример манифеста. Дополнительные сведения см mountOptions. в разделе "Параметры подключения ".

   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. Создайте класс хранилища с помощью kubectl apply команды.

   kubectl apply -f azure-file-sc.yaml
   

Создание ПВХ

В заявке на постоянный том используется объект класса хранилища для динамического предоставления общего файла Azure. Чтобы создать PVC размером 100 ГБ с доступом ReadWriteMany, используйте следующий YAML. Дополнительные сведения о режимах доступа см. в разделе "Постоянный том Kubernetes".

1. Создайте файл azure-file-pvc.yaml и скопируйте в него следующий код YAML. Убедитесь, storageClassName что соответствует классу хранилища, созданному на предыдущем шаге.

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

   Замечание

   Если используется Premium_LRS номер SKU для класса хранилища, минимальное значение storage должно быть 100Gi.

2. Создайте ПВХ с помощью kubectl apply команды.

   kubectl apply -f azure-file-pvc.yaml
   

   После завершения будет создан общий файловый ресурс. Также будет создан секрет Kubernetes, содержащий сведения о подключении и учетные данные. Вы можете использовать kubectl get команду для просмотра состояния ПВХ:

   kubectl get pvc my-azurefile
   

   Выходные данные команды будут выглядеть примерно так:

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

Установите ПВХ

В следующем YAML создается модуль pod, использующий файл PVC my-azurefile для подключения общей папки файлов Azure по пути /mnt/azure . Для контейнеров Windows Server укажите mountPath с использованием формата пути Windows, например "D:".

1. Создайте файл azure-pvc-files.yaml и скопируйте в него следующий код YAML. Убедитесь в том, что claimName соответствует PVC, созданной на предыдущем шаге.

   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. Создайте pod с помощью команды kubectl apply.

   kubectl apply -f azure-pvc-files.yaml
   

   Теперь у вас есть запущенный модуль pod с общим файлом Azure Files, подключенным в каталоге /mnt/azure . Эту конфигурацию можно увидеть, когда вы проверяете pod с помощью команды kubectl describe. В следующем сжатом примере выходных данных показан том, подключенный к контейнеру.

   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
   [...]
   

Параметры подключения

Для версий Kubernetes 1.13.0 и более поздних значения по умолчанию для fileMode и dirMode установлены как 0777. При динамической подготовке PV с помощью класса хранилища можно определить параметры подключения непосредственно в манифесте класса хранилища. Дополнительные сведения см. в разделе "Параметры подключения". В следующем примере показано, как задать эти разрешения 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

В этом разделе содержатся рекомендации для администраторов кластера, которые хотят создать один или несколько PV, включающих сведения о существующей общей папке Службы файлов Azure для использования с рабочей нагрузкой.

Создание общей папки Файлов Azure

Прежде чем использовать файловое хранилище Azure Files в качестве тома Kubernetes, необходимо создать учетную запись хранилища Azure и файловое хранилище.

1. Получите имя группы ресурсов с помощью az aks show команды с параметром --query nodeResourceGroup .

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

   Выходные данные команды будут выглядеть примерно так:

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Создайте учетную запись хранения с помощью az storage account create команды с параметром --sku . Следующая команда создает учетную запись хранения с помощью Standard_LRS SKU. Обязательно замените следующие заполнители:

   • myAKSStorageAccount с именем учетной записи хранения
   • nodeResourceGroupName с именем группы ресурсов, в которую размещаются узлы кластера AKS.
   • location с именем региона для создания ресурса. Это должен быть тот же регион, что и узлы кластера AKS.

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

3. Экспортируйте строка подключения в качестве переменной среды с помощью следующей команды, которая используется для создания общей папки.

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

   Строки подключения должны быть защищены с помощью смены ключей или хранилища в Azure Key Vault. Дополнительные сведения о строках подключения см. в разделе "Настройка строк подключения службы хранилища Azure " и "Управление ключами доступа к учетной записи хранения".

   Для рабочих сред корпорация Майкрософт рекомендует использовать проверку подлинности идентификатора Microsoft Entra. Дополнительные сведения см. в статье Авторизация доступа к данным в службе хранилища Azure.

4. Создайте общую папку az storage share create с помощью команды. Обязательно замените shareName своим именем для общего доступа.

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

5. Экспорт ключа учетной записи хранилища в качестве переменной среды с помощью следующей команды.

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

6. Выведите имя и ключ учетной записи хранения с помощью следующей команды. Скопируйте эти сведения, так как вам нужны эти значения при создании тома Kubernetes.

   echo Storage account key: $STORAGE_KEY
   

Создайте секрет Kubernetes

Kubernetes требуются учетные данные для доступа к файловому ресурсу, который был создан на предыдущем шаге. Эти учетные данные хранятся в секрете Kubernetes, на который ссылается при создании модуля Pod Kubernetes.

1. Создайте секрет с помощью kubectl create secret команды. В следующем примере создается секрет с именем azure-secret и заполняется параметрами azurestorageaccountname и azurestorageaccountkey на предыдущем шаге. Чтобы использовать существующую учетную запись Azure, укажите имя и ключ учетной записи.

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

Подключение файлового хранилища в виде PV

1. Создайте новый файл с именем azurefiles-pv.yaml и вставьте в него следующее содержимое. В объекте csi измените resourceGroup, volumeHandle и shareName. Для параметров подключения значение по умолчанию для fileMode и dirMode равно 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. Создайте PV, используя команду kubectl create.

   kubectl create -f azurefiles-pv.yaml
   

3. Создайте файл с именем azurefiles-mount-options-pvc.yaml и скопируйте следующее содержимое.

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

4. Создайте ПВХ с помощью kubectl apply команды.

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

5. Убедитесь, что ваш ПВХ создан и привязан к PV с помощью kubectl get команды.

   kubectl get pvc azurefile
   

   Выходные данные команды будут выглядеть примерно так:

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

6. Обновите спецификацию контейнера, чтобы ссылаться на ПВХ и pod в YAML-файле. Рассмотрим пример.

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

7. Спецификация pod не может быть обновлена на месте, поэтому удалите модуль pod с помощью kubectl delete команды и повторно создайте его с помощью kubectl apply команды.

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

Подключение общей папки в виде встроенного тома

Чтобы подключить общую папку Файлы Azure в модуль pod, настройте том в спецификации контейнера.

1. Создайте новый файл с именем azure-files-pod.yaml и вставьте в него следующее содержимое. Если имя общей папки или секретного имени изменено, обновите shareName и secretName. Вы также можете обновить mountPathпуть, по которому общая папка "Файлы" подключена в модуле pod. Для контейнеров Windows Server укажите mountPath в формате пути Windows, например 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. Создайте pod с помощью команды kubectl apply.

   kubectl apply -f azure-files-pod.yaml
   

   Теперь у вас есть запущенный модуль pod с общей папкой файлов Azure, подключенной в /mnt/azure. Вы можете убедиться, что общая папка успешно подключена, используя команду kubectl describe.

   kubectl describe pod mypod
   

В следующей таблице приведены параметры, которые можно использовать для определения пользовательского класса хранения для ПВХ.

¹ Если учетная запись хранения создается драйвером, необходимо указать networkEndpointType: privateEndpoint только параметр в классе хранилища. Драйвер CSI создает частную конечную точку и частную зону DNS (именованную privatelink.file.core.windows.net) вместе с учетной записью. Если у вас есть собственная учетная запись хранения, необходимо создать частную конечную точку для аккаунта хранения. Если вы используете хранилище файлов Azure в изолированном сетевом кластере, необходимо создать пользовательский класс хранилища с помощью networkEndpointType: privateEndpoint. Вы можете следовать этому примеру для справки:

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

Следующие параметры предназначены только для протокола SMB.

Следующие параметры предназначены только для протокола NFS.

Следующие параметры предназначены только для параметра виртуальной сети, например NFS и частной конечной точки.

В следующей таблице приведены параметры, которые можно использовать для определения pv.

Следующие параметры предназначены только для протокола SMB.

Следующие параметры предназначены только для протокола NFS.

Чтобы включить управляемую идентификацию для динамически создаваемых томов, выполните следующие действия.

1. Создайте класс хранилища с активированным управляемым удостоверением с помощью YAML-файла, например, azurefile-csi-managed-identity.yaml с таким содержанием. Установите mountWithManagedIdentity: "true" в разделе 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. Примените этот класс хранилища, выполнив следующую команду:

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

3. Разверните StatefulSet или рабочую нагрузку, используя новый класс хранилища, который ссылается на этот том запроса на постоянный том (PVC), чтобы обеспечить подготовку тома с использованием аутентификации управляемой идентичности. В манифесте ПВХ установите storageClassName: azurefile-csi-managed-identity. Рассмотрим пример.

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

Чтобы включить управляемую идентичность для статически выделенных томов, выполните следующие действия.

1. Создайте манифест PV, например azurefile-csi-static.yaml. Определите ПС, ссылающийся на существующий общий ресурс файлов Azure и обеспечивающий проверку подлинности управляемого удостоверения, установив mountWithManagedIdentity: "true" в разделе volumeAttributes.

   Пример манифеста 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. Разверните PV в pod приложения, выполнив следующую команду:

   kubectl apply -f azurefile-csi-static.yaml
   

В этом разделе содержатся сведения о подходе к настройке производительности NFS с файлообразующим драйвером CSI Azure с опциями rsize (размер чтения) и wsize (размер записи). Опции rsize и wsize устанавливают максимальный размер передачи для операций NFS. Если rsize или wsize не указано при подключении, клиент и сервер договариваются о наибольшем размере, поддерживаемом обоими. В настоящее время как файлы Azure, так и современные дистрибутивы Linux поддерживают размеры чтения и записи размером в 1 048 576 байт (1 МиБ).

Оптимальная производительность основана на эффективном обмене данными между клиентом и сервером. Увеличение или уменьшение значений размера опций чтения и записи может повысить производительность NFS. Размер пакетов чтения и записи, передаваемых между клиентом и сервером, по умолчанию — 8 КБ для NFS версии 2 и 32 КБ для NFS версии 3 и 4. Эти значения по умолчанию могут быть слишком большими или слишком маленькими. Уменьшение rsize и wsize может улучшить производительность NFS в перегруженной сети за счет отправки более мелких пакетов для каждого ответа на чтение NFS и запроса на запись. Однако это сокращение может увеличить количество пакетов, необходимых для отправки данных по сети, увеличив общее сетевое трафик и использование ЦП на клиенте и сервере.

Важно выполнить тестирование, чтобы найти rsize и wsize, которые поддерживают эффективную передачу пакетов, не снижая пропускную способность и не увеличивая задержку.

Например, чтобы настроить максимально rsize и wsize на 256-КиБ, настройте класс хранилища mountOptions следующим образом:

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. Создайте файл с именем nfs-sc.yaml и скопируйте пример манифеста. Для списка поддерживаемых mountOptions см. параметры подключения NFS.

   Замечание

   Драйвер CSI файлов Azure настраивает vers, minorversion и sec. Указание значения в манифесте для этих свойств не поддерживается .

   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. После редактирования и сохранения файла YAML примените класс хранилища с помощью команды kubectl apply:

   kubectl apply -f nfs-sc.yaml
   

   Выходные данные команды будут выглядеть примерно так:

   storageclass.storage.k8s.io/azurefile-csi-nfs created
   

1. Пример StatefulSet можно развернуть с использованием следующего манифеста, который записывает временные метки в файл с именем data.txt, выполнив команду 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
   

   Выходные данные команды будут выглядеть примерно так:

   statefulset.apps/statefulset-azurefile created
   

2. Проверьте содержимое тома с помощью следующей команды:

   kubectl exec -it statefulset-azurefile-0 -- df -h
   

   Выходные данные команды будут выглядеть примерно так:

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

Так как NFS находится в учетной записи хранения класса Premium, минимальный размер общей папки составляет 100 ГиБ. При создании ПВХ с небольшим размером хранилища может возникнуть ошибка, аналогичная следующим выходным данным:

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

При использовании AKS версии 1.33 функция шифрования в транзитной версии (EiT)Preview гарантирует, что все операции чтения и записи в общие папки NFS в виртуальной сети шифруются, обеспечивая другой уровень безопасности.

Задав encryptInTransit: "true" параметры класса хранилища, вы можете включить шифрование данных в транзитном режиме для общих папок Azure NFS. Рассмотрим пример.

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

Рекомендуемые варианты подключения для общих папок SMB приведены в следующем примере класса хранилища:

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

При использовании общих папок ценовой категории "Премиум" (SSD) и рабочей нагрузки рабочая нагрузка является тяжелой, зарегистрируйтесь, чтобы использовать функцию кэширования метаданных для повышения производительности.

Дополнительные сведения см. в статье "Повышение производительности для общих папок SMB Azure".

Рекомендуемые варианты подключения для общих папок NFS приведены в следующем примере класса хранилища:

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

Вы можете повысить пропускную способность чтения, увеличив размер предварительного чтения.

Хотя служба "Файлы Azure" поддерживает установку nconnect до максимального значения 16, рекомендуется настроить параметры подключения с оптимальным значением nconnect=4. В настоящее время для реализации Azure Files нет увеличения числа каналов сверх четырех.

Дополнительные сведения см. в статье "Повышение производительности для общих папок Azure NFS".