Создайте и управляйте постоянными томами с помощью Файлы Azure в Azure Kubernetes Service (AKS)

Если нескольким модулям pod требуется одновременный доступ к одному тому хранилища, можно использовать Файлы Azure для подключения с помощью протокола Server Message Block (SMB) или NFS. В этой статье показано, как динамически и статически создать общую папку Azure для использования несколькими pod в кластере Azure Kubernetes Service (AKS).

Предпосылки

• Azure CLI версии 2.0.59 или более поздней, установлен и настроен. Найдите версию с помощью az --version команды. Сведения об установке или обновлении см. в разделе Install Azure CLI.
• Драйвер Файлы Azure CSI включен в кластере AKS.
• Учетная запись хранилища Azure .
• При выборе файловых ресурсов на основе SSD (Premium) и HDD (Standard) важно понимать модель развертывания и требования ожидаемого характера использования, который планируется на Файлы Azure. Файлы Azure имеет три модели выставления счетов: предоставленный версии 2 (рекомендуется), оплата по мере использования и устаревшая предоставленная v1. Дополнительные сведения см. в разделе Выбор уровня производительности Файлы Azure на основе шаблонов использования.

Используйте встроенные классы хранилища для создания динамических PV с Файлы Azure

Классы хранилища определяют, как единица хранилища динамически создается в виде постоянного тома. Учетная запись хранения автоматически создается в группе ресурсов node для использования с классом хранилища и содержанием файловой доли Файлы Azure. При использовании драйверов CSI в AKS имеются два дополнительных встроенных StorageClasses, которые используют драйверы хранилища CSI Файлы Azure (остальные классы хранилища CSI создаются вместе с кластером и включают встроенные классы хранилища по умолчанию):

• azurefile-csi: создает общую папку Azure в хранилище HDD.
• azurefile-csi-premium: создает общую папку Azure в хранилище SSD.

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

Вы можете выбрать один из следующих вариантов SKU избыточности хранилища Azure для параметра skuname в классе определения хранилища:

• PremiumV2_LRS (рекомендуется): версия 2 SSD, локально-избыточное хранилище
• PremiumV2_ZRS (рекомендуется): подготовленный SSD v2, зонально-избыточное хранилище
• Premium_LRS: предоставленная SSD версия 1 (устаревший), локально избыточное хранилище
• Premium_ZRS: SSD подготовленный первой версии (устаревшая версия), зонально-избыточное хранилище
• StandardV2_LRS: подготовленное v2 HDD, локально избыточное хранилище
• StandardV2_ZRS: HDD выделено v2, зонально-резервируемое хранилище
• StandardV2_GRS: выделенный HDD v2, геоизбыточное хранилище
• StandardV2_GZRS: выделенное HDD v2, гео-зонально-избыточное хранилище
• Standard_LRS: HDD с оплатой по мере использования, локально избыточное хранилище
• Standard_GRS: HDD с оплатой по факту использования, геоизбыточное хранилище
• Standard_ZRS: HDD с оплатой по мере использования, зонально-избыточное хранилище

Создайте настраиваемые классы хранилища для динамических PV с использованием Файлы Azure

Классы хранилища по умолчанию подходят для большинства сценариев. В некоторых случаях может потребоваться настроить собственный класс хранилища с собственными параметрами. Например, может потребоваться настроить mountOptions общую папку.

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

   kind: StorageClass
   apiVersion: storage.k8s.io/v1
   metadata:
     name: my-azurefile
   provisioner: file.csi.azure.com
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   allowVolumeExpansion: true
   mountOptions:
     # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
     # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
     - dir_mode=0755
     - file_mode=0755
     - uid=1000
     - gid=1000
     - mfsymlinks
     - cache=strict
     - actimeo=30
     - nosharesock
   parameters:
     skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2), Standard_LRS (HDD pay-as-you-go)
   

2. Создайте класс хранилища с помощью kubectl apply команды:

   kubectl apply -f azure-file-sc.yaml
   

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

   storageclass.storage.k8s.io/my-azurefile created
   

Параметры класса хранилища для динамических PV с Файлы Azure

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

az storage account update \
    --name mystorageaccount \
    --resource-group MC_myResourceGroup_myAKSCluster_eastus \
    --set tags.abc=ABC123

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-private-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, StandardV2_LRS, Standard_LRS
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - 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

Создать PVC с Файлы Azure

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

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
   

3. Просмотрите состояние ПВХ с помощью kubectl get команды:

   kubectl get pvc my-azurefile
   

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

   NAME           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
   my-azurefile   Bound     pvc-aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb   100Gi       RWX            my-azurefile      5m
   

Использование ПВХ с Файлы Azure в модуле pod

Пример манифеста 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
   

3. Просмотрите состояние pod с помощью kubectl describe команды:

   kubectl describe pod mypod
   

   Выходные данные должны выглядеть примерно так, как показано, что модуль pod запущен и том подключен по правильному пути:

   Containers:
     mypod:
       Container ID:   docker://BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
       Image:          mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
       Image ID:       docker-pullable://nginx@sha256:AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
       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
   [...]
   

Параметры монтирования для Файлы Azure

Расположение для настройки параметров монтирования (mountOptions) зависит от того, подготавливаете ли вы динамические или статические постоянные тома:

• Если вы динамически подготавливаете том с классом хранилища, укажите параметры подключения для объекта класса хранилища (тип: StorageClass).
• Если вы статически подготавливаете том, укажите параметры монтирования для объекта PV (тип: PersistentVolume).
• Если вы подключаете общую папку в виде встроенного тома, укажите параметры подключения в объекте Pod (тип: Pod).

Дополнительные сведения см. в разделе "Параметры подключения".

Значение по умолчанию для fileMode и dirMode в Kubernetes версии 1.13.0 и более поздней — 0777. В следующем примере задано значение 0777:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com
allowVolumeExpansion: true
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - 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: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2), Standard_LRS (HDD pay-as-you-go)

Рекомендуемые параметры монтирования для долей SMB

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
    skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, StandardV2_LRS, Standard_LRS, Standard_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
    # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
    # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
    - dir_mode=0755
    - file_mode=0755
    - uid=1000
    - gid=1000
    - 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, а рабочая нагрузка тяжела, зарегистрируйтесь, чтобы использовать функцию кэширования метаданных для повышения производительности.

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

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

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
parameters:
    protocol: nfs
    skuName: PremiumV2_LRS     # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_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. В настоящее время в реализации nconnect для Файлы Azure нет никаких улучшений, превышающих четыре канала.

Создание моментального снимка тома из ПВХ с Файлы Azure

Драйвер CSI Файлы Azure поддерживает создание снапшотов постоянных томов, а также связанных с ними файловых томов.

1. Создайте класс снимка томаkubectl apply с помощью команды:

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

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

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

2. Создайте моментальный снимок тома из динамического PVC, созданного ранее в этом руководстве, с помощью команды kubectl apply.

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

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

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

3. Просмотрите состояние моментального снимка тома с помощью kubectl describe команды:

   kubectl describe volumesnapshot azurefile-volume-snapshot
   

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

   Name:         azurefile-volume-snapshot
   Namespace:    default
   Labels:       <none>
   Annotations:  API Version:  snapshot.storage.k8s.io/v1beta1
   Kind:         VolumeSnapshot
   Metadata:
     Creation Timestamp:  2020-08-27T22:37:41Z
     Finalizers:
       snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
       snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
     Generation:        1
     Resource Version:  955091
     Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-volume-snapshot
     UID:               00aa00aa-bb11-cc22-dd33-44ee44ee44ee
   Spec:
     Source:
       Persistent Volume Claim Name:  pvc-azurefile
     Volume Snapshot Class Name:      csi-azurefile-vsc
   Status:
     Bound Volume Snapshot Content Name:  snapcontent-00aa00aa-bb11-cc22-dd33-44ee44ee44ee
     Ready To Use:                        false
   Events:                                <none>
   

Изменение размера постоянного тома с помощью Файлы Azure

Вы можете запросить больший объем для ПВХ, изменив объект ПВХ, чтобы указать больший размер. Это изменение активирует расширение базового тома, которое производит резервное копирование постоянного тома. Новый постоянный том (Persistent Volume, PV) никогда не будет создан для удовлетворения запроса. Вместо этого изменяется размер существующего тома.

В AKS встроенный managed-csi класс хранилища уже поддерживает расширение, поэтому вы можете использовать динамический PVC, который был создан ранее в этом руководстве. PVC запросил область хранения на 100 ГиБ.

1. Проверьте текущий размер ПВХ и файловой системы внутри модуля pod с помощью kubectl exec команды для выполнения df -h команды внутри модуля pod:

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

   Выходные данные должны выглядеть примерно так, как показано, что файловая система имеет размер 100 ГБ:

   Filesystem                                                                                      Size  Used Avail Use% Mounted on
   //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee  100G  128K  100G   1% /mnt/azurefile
   

2. Расширьте PVC, увеличив поле spec.resources.requests.storage с помощью команды kubectl patch. В этом примере мы увеличим общую папку до 200 ГиБ:

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

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

   persistentvolumeclaim/pvc-azurefile patched
   

3. Убедитесь, что размер ПВХ был успешно изменен, и новый размер отражается в модуле pod с помощью kubectl get pvc команды и df -h команды внутри модуля pod:

   kubectl get pvc pvc-azurefile
   

   Выходные данные должны выглядеть примерно так, как показано, что ПВХ по-прежнему находится в Bound состоянии, и емкость была обновлена до 200 ГиБ:

   NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
   pvc-azurefile   Bound    pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee   200Gi      RWX            azurefile-csi   64m
   

4. Проверьте новый размер файловой системы в контейнере с помощью команды kubectl exec, чтобы выполнить команду df -h внутри контейнера:

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

   Выходные данные должны выглядеть примерно так, как показано, что размер файловой системы составляет 200 ГБ:

   Filesystem                                                                                Size  Used Avail Use% Mounted on
   //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-bbbbbbbb-1111-2222-3333-cccccccccccc  200G  128K  200G   1% /mnt/azurefile
   

Использование постоянного тома с частным хранилищем Файлы Azure (частная конечная точка)

Если ресурсы Файлы Azure защищены с помощью частной конечной точки, необходимо создать собственный класс хранилища. Убедитесь, что вы настроили параметры DNS для разрешения IP-адреса частной конечной точки в полное доменное имя FQDN строка подключения. При создании класса хранилища с помощью драйвера CSI Файлы Azure необходимо указать параметр networkEndpointType со значением privateEndpoint и указать следующие параметры:

• resourceGroup: группа ресурсов, в которой развернута учетная запись хранения.
• storageAccount: имя учетной записи хранения.
• server: полное доменное имя частной конечной точки учетной записи хранения.

1. Создайте файл с именем private-azure-file-sc.yaml и вставьте следующий манифест. Убедитесь, что вы заменили заполнители <resourceGroup> и <storageAccountName>.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azurefile-csi-private-custom
   provisioner: file.csi.azure.com
   allowVolumeExpansion: true
   parameters:
     skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, StandardV2_LRS
     resourceGroup: <resourceGroup>
     storageAccount: <storageAccountName>
     server: <storageAccountName>.file.core.windows.net
     networkEndpointType: privateEndpoint
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   mountOptions:
     # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
     # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
     - dir_mode=0755
     - file_mode=0755
     - uid=1000
     - gid=1000
     - 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
   

2. Создайте класс хранилища с помощью kubectl apply команды:

   kubectl apply -f private-azure-file-sc.yaml
   

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

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

3. Создайте файл с именем private-pvc.yaml и вставьте его в следующий манифест. Убедитесь, что storageClassName соответствует имени существующего класса хранилища.

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

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

   kubectl apply -f private-pvc.yaml
   

Использование Файлы Azure с контейнерами Windows

Драйвер CSI Файлы Azure также поддерживает Windows узлы и контейнеры. Чтобы использовать контейнеры Windows, следуйте инструкции по быстрому запуску Windows контейнеров, чтобы добавить пул узлов Windows. После настроек Windows-пула узлов можно использовать встроенные классы хранилища, такие как azurefile-csi, или создать пользовательский. Пример набора с отслеживанием состояния Windows в этом разделе каждую секунду сохраняет метки времени в файл data.txt, который подключен к общей папке Azure с помощью Файлы Azure CSI-драйвера.

1. Создайте StatefulSet с помощью команды kubectl apply.

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

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

   statefulset.apps/busybox-azurefile created
   

2. Убедитесь, что метки времени записываются в общую папку с помощью следующих kubectl exec команд для выполнения cat команды внутри pod:

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

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

   2020-08-27 22:11:01Z
   2020-08-27 22:11:02Z
   2020-08-27 22:11:04Z
   (...)
   

Использование протокола NFS с Файлы Azure

Файлы Azure поддерживает протокол NFS версии 4.1. Поддержка NFS версии 4.1 для Файлы Azure предоставляет полностью управляемую файловую систему NFS как услугу, построенную на платформе распределенного хранилища с высокой доступностью и надежностью.

Этот параметр оптимизирован для рабочих нагрузок произвольного доступа с обновлениями данных на месте и обеспечивает полную поддержку файловой системы POSIX. В этом разделе показано, как использовать ресурсы NFS с помощью драйвера Azure File CSI в кластере AKS.

Предварительные требования для использования общих папок NFS с Файлы Azure

• Для NFS требуются общие папки SSD (например PremiumV2_LRS, PremiumV2_ZRS, Premium_LRSили Premium_ZRS) и учетная запись хранения с поддержкой виртуальной сети.
• Идентификатор плоскости управления вашего кластера AKS (то есть, имя вашего кластера AKS) добавляется к роли Contributor в виртуальной сети и NetworkSecurityGroup.
• Для кластеров AKS, служебный принципал или управляемое удостоверение службы (MSI) должны быть добавлены в роль Участника к аккаунту хранилища.

Оптимизация параметров размера чтения и записи

В этом разделе содержатся сведения о подходе к настройке производительности NFS с драйвером CSI Файлы Azure cSI с параметрами 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, которые поддерживают эффективную передачу пакетов и не уменьшают пропускную способность и не увеличивают задержку.

Следующий пример манифеста настраивает раздел mountOptions в классе хранилища с максимальным значением rsize и wsize, равным 256 КиБ.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30
  - rsize=262144
  - wsize=262144

Для списка поддерживаемых mountOptions см. параметры подключения NFS.

Создание класса хранения общей папки NFS

1. Создайте файл с именем nfs-sc.yaml и вставьте его в следующий манифест. Обязательно укажите protocol: nfs в разделе параметров и настройте необходимые mountOptions параметры для рабочей нагрузки.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azurefile-csi-premiumv2-custom
   provisioner: file.csi.azure.com
   allowVolumeExpansion: true
   parameters:
     protocol: nfs
     skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
   mountOptions:
     - nconnect=4
     - noresvport
     - actimeo=30
   

2. После редактирования и сохранения файла создайте класс хранилища с помощью kubectl apply команды.

   kubectl apply -f nfs-sc.yaml
   

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

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

Создание набора с отслеживанием состояния с помощью общей папки с поддержкой NFS

1. Создайте файл с именем nfs-ss.yaml и вставьте его в следующий манифест. Эта конфигурация сохраняет метки времени в файл data.txt.

   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-premiumv2-custom
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 100Gi
   

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

   kubectl apply -f nfs-ss.yaml
   

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

   statefulset.apps/statefulset-azurefile created
   

3. Проверьте содержимое тома с помощью следующей kubectl exec команды, чтобы выполнить df -h команду внутри pod:

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

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

   Filesystem      Size  Used Avail Use% Mounted on
   ...
   /dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
   accountname.file.core.windows.net:/accountname/pvc-cccccccc-2222-3333-4444-dddddddddddd  100G     0  100G   0% /mnt/azurefile
   ...
   

   Так как общая папка NFS находится в учетной записи хранения класса Premium, минимальный размер общей папки составляет 100 ГиБ. Если вы создаете PVC с небольшим размером хранилища, вы можете столкнуться с примерно такой ошибкой: Не удалось создать общую папку ... размер (5)....

Шифрование при передаче (EiT) для общих папок NFS (предварительная версия)

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

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
  encryptInTransit: "true"
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

Использование управляемого удостоверения для доступа к хранилищу Файлы Azure (предварительная версия)

Файлы Azure теперь поддерживает проверку подлинности на основе управляемых удостоверений для доступа SMB. Это позволяет приложениям безопасно получать доступ к Файлы Azure без хранения учетных данных или управления ими.

Предварительные требования для использования управляемого удостоверения для доступа к хранилищу Файлы Azure

• Убедитесь, что удостоверение Kubelet, назначаемое пользователем , имеет Storage File Data SMB MI Admin роль в учетной записи хранения.
  • Если вы используете собственную учетную запись хранения, необходимо назначить Storage File Data SMB MI Admin роль назначенному пользователем удостоверению Kubelet в этой учетной записи хранения.
  • Если учетная запись хранения создается драйвером CSI, предоставьте Storage File Data SMB MI Admin роль группе ресурсов, в которой находится учетная запись хранения.

Включение управляемого удостоверения для динамических PV с помощью Файлы Azure

Чтобы включить управляемое удостоверение для динамически подготовленных томов, необходимо создать новый класс хранилища с параметрами: mountWithManagedIdentity, "true" и развернуть StatefulSet, используя этот класс хранилища.

В следующем примере манифеста настраивается класс хранилища для использования управляемого удостоверения для доступа к Файлы Azure:

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:
   # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
   # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
   - dir_mode=0755
   - file_mode=0755
   - uid=1000
   - gid=1000
   - 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

Включение управляемого удостоверения для статических PV с помощью Файлы Azure

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

1. Включите SMBOauth в учетной записи хранения, выполнив следующую команду:

   az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
   

2. Создайте PV с помощью mountWithManagedIdentity: "true" и подключите PV к модулю pod приложения.

В следующем примере манифеста настраивается ПС для использования управляемого удостоверения для доступа к Файлы Azure:

apiVersion: v1
kind: PersistentVolume
metadata:
   name: pv-azurefile
spec:
   capacity:
   storage: 100Gi
   accessModes:
   - ReadWriteMany
   persistentVolumeReclaimPolicy: Retain
   storageClassName: azurefile-csi
   mountOptions:
   # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
   # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
   - dir_mode=0755
   - file_mode=0755
   - uid=1000
   - gid=1000
   - 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"

Использование удостоверения рабочей нагрузки для доступа к хранилищу Файлы Azure (предварительная версия)

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

Предварительные условия для использования идентификации рабочей нагрузки для доступа к хранилищу Файлы Azure

Прежде чем использовать идентификацию рабочей нагрузки для доступа к Файлы Azure из AKS, выполните следующие предварительные условия.

1. Создайте кластер с включенным издателем oidc и получите учетные данные кластера AKS

Создайте новый кластер AKS с активированным эмитентом OIDC или убедитесь, что он уже активирован. Следуйте официальной документации по созданию кластера AKS с --enable-oidc-issuer параметром и получите учетные данные кластера. И задайте следующие переменные среды:

export RESOURCE_GROUP=<your resource group name>
export CLUSTER_NAME=<your cluster name>
export REGION=<your region>

2. Подготовка учетной записи хранения

Создайте новую учетную запись хранения и общую папку или используйте существующую. Подробные инструкции см. в Файлы Azure документации. Задайте следующие переменные среды:

export STORAGE_RESOURCE_GROUP=<your storage account resource group>
export ACCOUNT=<your storage account name>
export SHARE=<your fileshare name> # optional

Создайте или повторно используйте управляемую учетную запись и предоставьте необходимые разрешения

Создайте управляемое удостоверение, назначаемое пользователем, или повторно используйте существующее (например, управляемое удостоверение , связанное с группой ресурсов узла AKS). А также получите необходимые сведения об удостоверениях и ресурсах:

export UAMI=<your managed identity name>
az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show -g $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)
export ACCOUNT_SCOPE=$(az storage account show --name $ACCOUNT --query id -o tsv)

Предоставьте Storage File Data SMB MI Admin роль управляемому удостоверению. Эта роль позволяет монтировать Файлы Azure только с использованием идентификационных токенов рабочих процессов, без использования ключей аккаунта хранения.

az role assignment create --role "Storage File Data SMB MI Admin" --assignee $USER_ASSIGNED_CLIENT_ID --scope $ACCOUNT_SCOPE

4. Создание Kubernetes ServiceAccount

Создайте Службу Kubernetes ServiceAccount, которую будет использовать рабочая нагрузка.

export SERVICE_ACCOUNT_NAME=<your sa name>
export SERVICE_ACCOUNT_NAMESPACE=<your sa namespace>

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

5. Создайте федеративное удостоверение личности

Создайте учетные данные федеративного удостоверения между управляемым удостоверением, издателем учетной записи службы и субъектом az identity federated-credential create с помощью команды.

export FEDERATED_IDENTITY_NAME=<your federated identity name>
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"

az identity federated-credential create --name $FEDERATED_IDENTITY_NAME \
--identity-name $UAMI \
--resource-group $RESOURCE_GROUP \
--issuer $AKS_OIDC_ISSUER \
--subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

После выполнения этих действий рабочие нагрузки, работающие с указанным ServiceAccount, могут проходить проверку подлинности в Файлы Azure с помощью удостоверения рабочей нагрузки Microsoft Entra без использования ключей учетной записи хранения или управляемых удостоверений на уровне узла.

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

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

1. Предоставление разрешений для идентификации плоскости управления драйвера CSI

   • Назначьте роль для удостоверения, используемого контрольной плоскостью драйвера CSI, для целевой учетной записи хранения.
   • Если учетная запись хранения создается динамически драйвером CSI, предоставьте Storage Account Contributor роль группе ресурсов узла.
   • По умолчанию, идентификатор плоскости управления кластера AKS уже присваивается роли Storage Account Contributor в группе ресурсов узлов для создания учетной записи хранения.

2. Создайте новый класс хранилища с помощью mountWithWorkloadIdentityToken: "true" и разверните statefulset, используя этот класс хранилища.

Следующий пример манифеста настраивает класс хранилища для использования удостоверения рабочей нагрузки для доступа к Файлы Azure:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-wi
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
  mountWithWorkloadIdentityToken: "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
  - 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

Включение идентификации нагрузки для статических PV с помощью Файлы Azure

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

1. Включите SMBOauth в учетной записи хранения, выполнив следующую команду:

   az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
   

2. Создайте PV с указанными mountWithWorkloadIdentityToken"true" и подключите PV к поду приложения.

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

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
    mountWithWorkloadIdentityToken: "true"
    # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
    clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

Создание статического PV с помощью Файлы Azure

В следующих разделах приведены инструкции по созданию статического ПВ с Файлы Azure. Статический ПВ — это постоянный том, который администратор создает вручную. Этот PV доступен для использования модулями pod в кластере. Чтобы использовать статический PV, создайте ПВХ, который ссылается на PV, а затем создадите модуль pod, который ссылается на ПВХ.

Параметры класса хранилища для статических PV с Файлы Azure

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

Создание общего файлового хранилища Azure

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

1. Получите имя группы ресурсов узла кластера AKS с помощью 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 --name myAKSStorageAccount --resource-group nodeResourceGroupName --location location --sku Standard_LRS
   

3. Экспортируйте строка подключения в виде переменной среды, которая используется для создания общей папки, с помощью команды [az storage account show-connection-string][az-storage-account-show-connection-string]. Обязательно замените storageAccountName на имя учетной записи хранения и resourceGroupName на имя группы ресурсов.

   export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string --name storageAccountName --resource-group resourceGroupName -o tsv)
   

   Замечание

   Строки подключения должны быть защищены путем ротации ключей или хранения в безопасной среде Azure Key Vault. Дополнительные сведения о строках подключения см. в разделе Настройка строк подключения служба хранилища Azure и Управление ключами доступа к учетной записи хранилища. В рабочих средах Майкрософт рекомендуется использовать проверку подлинности Microsoft Entra ID. Дополнительные сведения можно найти в разделе Authorize access to data in служба хранилища Azure.

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

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

5. Экспортируйте ключ учетной записи хранилища как переменную среды, используя команду [az storage account keys list][az-storage-account-keys-list]. Обязательно замените storageAccountName на имя учетной записи хранения и resourceGroupName на имя группы ресурсов.

   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.

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

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

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

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:
       # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
       # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
       - dir_mode=0755
       - file_mode=0755
       - uid=1000
       - gid=1000
       - mfsymlinks
       - cache=strict
       - nosharesock
       - actimeo=30
       - 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 и вставьте в следующее содержимое. Убедитесь, что storageClassName совпадает с именем существующего класса хранилища, и volumeName совпадает с именем PV, созданного на предыдущем шаге.

   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
   

   Выходные данные должны иметь следующий вид: ПВХ находится в Bound состоянии, и он привязан к ПВ с именем 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=0755,file_mode=0755,uid=1000,gid=1000,cache=strict,actimeo=30,nosharesock,nobrl'  # optional
   

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

   kubectl apply -f azure-files-pod.yaml
   

3. Просмотрите состояние pod с помощью kubectl describe команды:

   kubectl describe pod mypod
   

Связанный контент

• Использовать теги Azure в Azure Kubernetes Service (AKS)