Использование драйвера Container Storage Interface (CSI) для Файлов Azure в Службе Azure Kubernetes (AKS)

Статья
08/07/2024

Драйвер Файлы Azure интерфейса хранилища контейнеров (CSI) — это драйвер, соответствующий спецификации CSI, используемый Служба Azure Kubernetes (AKS) для управления жизненным циклом общих папок Azure. CSI является стандартом для предоставления произвольных блоков и систем хранения файлов контейнерным рабочим нагрузкам на Kubernetes.

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

Сведения о создании кластера AKS с поддержкой драйверов CSI см. в статье Включение драйверов CSI в AKS.

Примечание.

Драйверы в дереве относятся к текущим драйверам хранилища, которые являются частью основного кода Kubernetes, а также новым драйверами CSI, которые являются подключаемыми модулями.

Новые возможности драйвера CSI Файлов Azure

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

NFS версии 4.1.
Частная конечная точка
Параллельное создание большого подключения общих папок.

Использование постоянного тома с Файлами Azure

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

Примечание.

Обратите внимание, что драйвер CSI файлов Azure разрешает только подключение общих папок SMB с помощью проверки подлинности на основе ключей (NTLM версии 2) и поэтому не поддерживает максимальный профиль безопасности параметров общей папки Azure. С другой стороны, подключение общих папок NFS не требует проверки подлинности на основе ключей.

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

Дополнительные сведения о томах Kubernetes см. в статье, посвященной возможностям хранения данных приложений в AKS.

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

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

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

Примечание.

Файлы Azure поддерживает общие папки Azure Premium. Минимальная емкость общей папки составляет 100 ГиБ. Мы рекомендуем использовать общие папки Azure Premium вместо общих папок уровня "Стандартный", так как общие папки класса Premium обеспечивают более высокую производительность, поддержку дисков с низкой задержкой для рабочих нагрузок с интенсивным вводом-выводом.

При использовании драйверов CSI хранилища в AKS используется еще два встроенных StorageClasses драйвера хранилища Файлы Azure CSI. Дополнительные классы хранения CSI создаются вместе с кластером наряду с классами хранения по умолчанию в дереве.

azurefile-csi: использует службу хранилища Azure уровня "Стандартный" для создания общей папки Azure.
azurefile-csi-premium: использует Azure хранилище класса Premium для создания общей папки Azure.

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

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

Создайте пример PVC и pod для вывода текущей даты в outfile с помощью команды kubectl apply.

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

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

persistentvolumeclaim/pvc-azurefile created
pod/nginx-azurefile created

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

kubectl exec nginx-azurefile -- ls -l /mnt/azurefile

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

total 29
-rwxrwxrwx 1 root root 29348 Aug 31 21:59 outfile

Создание пользовательского класса хранения

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

В подключенных общих папках Kubernetes для параметров fileMode и dirMode используется значение по умолчанию 0777. Для объекта класса хранения можно указать различные параметры подключения.

Создайте файл с именем 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:
  - dir_mode=0640
  - file_mode=0640
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict # https://linux.die.net/man/8/mount.cifs
  - nosharesock
parameters:
  skuName: Standard_LRS

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

kubectl apply -f azure-file-sc.yaml

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

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

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

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

Создайте моментальный снимок тома из заявки PVC, которое мы динамически создали в начале этого учебника, pvc-azurefile.

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

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

kubectl describe volumesnapshot azurefile-volume-snapshot

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

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

Изменение размера постоянного тома

Для PVC можно запросить больший объем. Измените объект заявки на постоянный том и укажите больший размер. Это изменение активирует расширение базового тома, которое производит резервное копирование постоянного тома.

Примечание.

Новый постоянный том никогда не будет создан для удовлетворения заявки. Вместо этого изменяется размер существующего тома.

Сжатие постоянных томов сейчас не поддерживается.

В AKS встроенный класс хранения azurefile-csi уже поддерживает расширение, поэтому используйте заявку PVC, созданную ранее с этим классом хранения. ПВХ попросил 100 ХиБ-файловую папку. Это можно проверить, запустив:

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

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

Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  100G  128K  100G   1% /mnt/azurefile

Разверните заявку на постоянный том, увеличив поле spec.resources.requests.storage:

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

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

persistentvolumeclaim/pvc-azurefile patched

Убедитесь, что в PVC и файловой системе в модуле Pod отображается новый размер:

kubectl get pvc pvc-azurefile
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
pvc-azurefile   Bound    pvc-5e5d9980-da38-492b-8581-17e3cad01770   200Gi      RWX            azurefile-csi   64m

kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  200G  128K  200G   1% /mnt/azurefile

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

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

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

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: private-azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  resourceGroup: <resourceGroup>
  storageAccount: <storageAccountName>
  server: <storageAccountName>.file.core.windows.net
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload

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

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

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

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

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

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

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

kubectl apply -f private-pvc.yaml

Общие файловые ресурсы NFS

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

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

Необходимые компоненты

Удостоверение уровня управления кластером AKS (то есть имя кластера AKS) добавляется в роль участника в виртуальной сети и NetworkSecurityGroup.
Субъект-служба кластера AKS или управляемое удостоверение службы (MSI) необходимо добавить в роль участника в учетную запись хранения.

Примечание.

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

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

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

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

Важно выполнить тестирование, чтобы найти rsize и wsize, поддерживающий передачу пакетов efficent, где она не уменьшает пропускную способность и увеличивает задержку.

Дополнительные сведения об оптимизации rsize и wsize см . в рекомендациях по настройке подключения Linux NFS для Azure NetApp Files.

Например, чтобы настроить максимальный размер rsize и wsize 256-KiB, настройте 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

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

Примечание.

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

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

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

kubectl apply -f nfs-sc.yaml

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

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

Вы можете развернуть пример набора с отслеживанием состояния, который сохраняет метки времени в файл 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

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

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 ГиБ. Если вы создаете PVC с небольшим размером хранилища, вы можете столкнуться с примерно такой ошибкой: Не удалось создать общую папку ... размер (5)....

Контейнеры Windows

Драйвер CSI Файлов Azure также поддерживает узлы и контейнеры Windows. Чтобы использовать контейнеры Windows, см. статью Краткое руководство по контейнерам Windows, чтобы добавить пул узлов Windows.

После создания пула узлов Windows используйте встроенные классы хранения, например azurefile-csi, или создайте настраиваемый. Вы можете развернуть пример набора с отслеживанием состояния на основе Windows, который сохранит метки времени в файле data.txt, выполнив команду 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

Проверьте содержимое тома, выполнив команду kubectl exec.

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

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

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

Следующие шаги

Сведения об использовании драйвера CSI для Дисков Azure см. в статье Использование Дисков Azure с драйвером CSI.
Сведения об использовании драйвера CSI для хранилища BLOB-объектов Azure см. в разделе Использование хранилища BLOB-объектов Azure с драйверами CSI.
Дополнительные сведения и рекомендации по хранению см. в разделе Рекомендации по хранению и резервному копированию в Службе Azure Kubernetes.

Поделиться через

Использование драйвера Container Storage Interface (CSI) для Файлов Azure в Службе Azure Kubernetes (AKS)

Новые возможности драйвера CSI Файлов Azure

Использование постоянного тома с Файлами Azure

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

Создание пользовательского класса хранения

Изменение размера постоянного тома

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

Общие файловые ресурсы NFS

Необходимые компоненты

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

Контейнеры Windows

Следующие шаги

Дополнительные ресурсы

Поделиться через

Использование драйвера Container Storage Interface (CSI) для Файлов Azure в Службе Azure Kubernetes (AKS)

Новые возможности драйвера CSI Файлов Azure

Использование постоянного тома с Файлами Azure

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

Создание пользовательского класса хранения

Изменение размера постоянного тома

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

Общие файловые ресурсы NFS

Необходимые компоненты

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

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

Создание развертывания с общей папкой на базе NFS

Контейнеры Windows

Следующие шаги

Дополнительные ресурсы