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

Создавайте и управляйте постоянными томами (PV) с использованием дисков Azure в службе Azure Kubernetes Service (AKS).

В этой статье показано, как динамически и статически создавать постоянные тома (PVs) с использованием дисков Azure Disks для одного pod в кластере службы Azure Kubernetes Service (AKS).

Предпосылки

  • Azure CLI версии 2.0.59 или более поздней версии, установленной и настроенной. Найдите версию с помощью az --version команды. Чтобы выполнить установку или обновление, см. сведения в статье Установка Azure CLI.

  • Драйвер CSI дисков Azure включен в вашем кластере AKS.

  • Драйвер CSI дисков Azure имеет ограничение на объемы для каждого узла. Количество томов изменяется на основе размера узла или пула узлов. Вы можете определить количество томов, которые можно выделить на каждый узел с помощью kubectl get команды. Рассмотрим пример.

    kubectl get CSINode <node-name> -o yaml

    Если ограничение объема на узел является проблемой для вашей рабочей нагрузки, рассмотрите возможность использования Azure Container Storage для постоянных хранилищ вместо драйверов CSI.

Встроенные классы хранилища для динамических PV с дисками Azure

Классы хранилища определяют, как единица хранилища динамически создается в виде постоянного тома.

Каждый кластер AKS включает четыре встроенных класса хранилища с двумя из них, настроенными для работы с дисками Azure:

  • Класс хранилища по умолчанию подготавливает диск Azure SSD уровня "Стандартный".
    • Стандартные SSD поддерживают стандартное хранилище и обеспечивают экономичное хранение при надежной производительности.
  • Класс хранения managed-csi-premium предоставляет диск Azure премиум-класса.
    • Высокопроизводительные SSD-диски с низкой задержкой поддерживают накопители премиум-класса. Они идеально подходят для виртуальных машин, выполняющих производственные нагрузки. При использовании драйвера Azure Disk CSI на AKS вы также можете использовать managed-csi класс хранилища, который поддерживается локально избыточным хранилищем Standard SSD (LRS).
  • Эффективно, начиная с Kubernetes версии 1.29: При развертывании кластеров AKS в нескольких зонах доступности, AKS теперь использует зонально-избыточное хранилище (ZRS) для создания управляемых дисков в рамках встроенных классов хранилища.
    • ZRS обеспечивает синхронную репликацию управляемых дисков Azure в нескольких зонах доступности Azure в выбранном регионе. Эта стратегия избыточности повышает устойчивость приложений и защищает данные от сбоев центра обработки данных.
      • Однако важно отметить, что ZRS имеет более высокую стоимость по сравнению с локальным избыточным хранилищем (LRS). Если оптимизация затрат является приоритетом, можно создать новый класс хранения с параметром имени SKU LRS и использовать его в ПВХ.

Уменьшение размера ПВХ не поддерживается из-за риска потери данных. Можно изменить существующий класс хранилища с помощью kubectl edit sc команды или создать собственный пользовательский класс хранилища.

Замечание

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

Просмотрите предварительно созданные классы хранилища с помощью kubectl get sc команды. В следующем примере показаны готовые классы хранилища, доступные в кластере AKS:

kubectl get sc

Выходные данные должны выглядеть примерно следующим образом, включая классы хранилища default и managed-csi, которые предварительно созданы для дисков Azure.

NAME                PROVISIONER                AGE
default (default)   disk.csi.azure.com         1h
managed-csi         disk.csi.azure.com         1h

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

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

Вы можете использовать volumeBindingMode: Immediate класс, гарантирующий, что он возникает сразу после создания ПВХ. Если пулы узлов ограничены топологией, например при использовании зон доступности, PVs будет привязан или подготовлен без знаний о требованиях к планированию pod.

Для решения этого сценария можно использовать volumeBindingMode: WaitForFirstConsumer, что задерживает привязку и подготовку PV до создания модуля pod, использующего ПВХ. Таким образом, PV соответствует ограничениям планирования пода и подготавливается в зоне доступности (или другой топологии), указанной этими ограничениями. Классы хранилища по умолчанию используют volumeBindingMode: WaitForFirstConsumer класс.

  1. Создайте файл с именем sc-azuredisk-csi-waitforfirstconsumer.yaml и вставьте его в следующий манифест YAML. Класс хранилища совпадает с managed-csi классом хранилища, но с другим volumeBindingMode классом.

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

  2. Создайте класс хранилища с помощью kubectl apply команды и укажите sc-azuredisk-csi-waitforfirstconsumer.yaml файл:

    kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml

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

    storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created

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

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

Имя. Значение Доступные значения Обязательно Значение по умолчанию
skuName Тип учетной записи хранения дисков Azure (псевдоним: storageAccountType). PremiumV2_LRS и UltraSSD_LRS поддерживают мгновенный доступ для инкрементальных восстановлений моментальных снимков. Standard_LRS, Premium_LRS, StandardSSD_LRSPremiumV2_LRSUltraSSD_LRSPremium_ZRSStandardSSD_ZRS нет StandardSSD_LRS
fsType Тип файловой системы ext4, , , ext3ext2xfsbtrfs для Linux
ntfs для Windows		 нет ext4 для Linux
ntfs для Windows
cachingMode Параметр кэша дисков данных Azure (PremiumV2_LRS и UltraSSD_LRS поддерживают None только режим кэширования) None, ReadOnly, ReadWrite нет ReadOnly
resourceGroup Укажите группу ресурсов для дисков Azure Имя существующей группы ресурсов нет Если это пусто, драйвер использует то же имя группы ресурсов, что и текущий кластер AKS.
DiskIOPSReadWrite Способность поддерживать IOPS (минимум: 2 IOPS/ГиБ) для Ultra Disk или Premium SSD v2 100~160000 нет 500
DiskMBpsReadWrite Производительность дисков Ultra Disk или Premium SSD v2 (минимум: 0,032/ГиБ) 1~2000 нет 100
LogicalSectorSize Размер логического сектора в байтах для диска "Ультра". 512, 4096 нет 4096
tags Теги диска Azure Формат тега: key1=val1,key2=val2 нет ""
diskEncryptionSetID Идентификатор ресурса набора шифрования дисков, используемый для включения шифрования неактивных данных формат: /subscriptions/{subs-id}/resourceGroups/{rg-name}/providers/Microsoft.Compute/diskEncryptionSets/{diskEncryptionSet-name} нет ""
diskEncryptionType Тип шифрования набора шифрования диска. EncryptionAtRestWithCustomerKey (по умолчанию) EncryptionAtRestWithPlatformAndCustomerKeys нет ""
writeAcceleratorEnabled Ускоритель записи на дисках Azure true, false нет ""
networkAccessPolicy NetworkAccessPolicy свойство для предотвращения создания URI SAS для диска или моментального снимка. AllowAll, DenyAll, AllowPrivate нет AllowAll
diskAccessID Идентификатор ресурса DiskAccess в Azure для использования частных конечных точек дисков нет ``
enableBursting Включите ускорение по запросу за пределами подготовленного целевого объекта производительности диска. Ускорение по запросу должно применяться только к диску категории "Премиум" и размеру > диска 512 ГБ. Диски Ultra и Shared не поддерживаются. Burst-режим отключен по умолчанию. true, false нет false
useragent Агент пользователя, используемый для отслеживания потребления услуг клиентами нет Созданный формат агента пользователя: driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Укажите идентификатор подписки Azure, в которой создаются диски Azure. Идентификатор подписки Azure нет Если значение не пустое, необходимо указать resourceGroup.
--- Следующие параметры доступны только для версии 2. --- --- ---
maxShares Общее количество точек монтирования общего диска, разрешённых для этого диска. Установка значения 2 или более включает реплики вложений. Поддерживаемые значения зависят от размера диска. Сведения о поддерживаемых значениях см. в статье "Общий доступ к управляемому диску Azure ". нет 1
maxMountReplicaCount Количество привязок реплик для поддержания. Это значение должно находиться в диапазоне [0..(maxShares - 1)] нет Если accessMode имеет значение ReadWriteMany, значение по умолчанию равно 0. В противном случае значение по умолчанию maxShares - 1

Создание ПВХ с дисками Azure

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

  1. Создайте файл с именем azure-pvc.yaml и вставьте его в следующий манифест. Запрос требует диск с именем azure-managed-disk, размером 5 ГБ и доступом 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

  3. Убедитесь, что PV готов к использованию pod с помощью kubectl describe pvc команды:

    kubectl describe pvc azure-managed-disk

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

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

Создайте pod, использующий PVC с дисками Azure

  1. Создайте файл с именем azure-pvc-disk.yaml и вставьте его в следующий манифест. Этот манифест создает базовый POD NGINX, который использует запрос на постоянный том с именем 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

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

    kubectl apply -f azure-pvc-disk.yaml

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

    pod/mypod created

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

    kubectl describe pod mypod

    Выходные данные должны выглядеть примерно так, как показано, что том именованный том использует ПВХ с именем azure-managed-disk:

    [...]
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-12345678-9
Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-12345678-9  MountVolume.SetUp succeeded for volume "default-token-smm2n"
Normal  SuccessfulMountVolume  1m    kubelet, aks-nodepool1-12345678-9  MountVolume.SetUp succeeded for volume "pvc-abc0d123-4e5f-67g8-901h-ijk23l45m678"
[...]

Параметры класса моментальных снимков тома для дисков Azure

Драйвер CSI дисков Azure поддерживает создание моментальных снимков постоянных томов. В рамках этой возможности драйвер может выполнять полные или инкрементные снимки в зависимости от значения, заданного в параметре incremental.

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

Имя. Значение Доступные значения Обязательно Значение по умолчанию
resourceGroup Группа ресурсов для хранения снимков. СУЩЕСТВУЮЩАЯ ГРУППА РЕСУРСОВ нет Если это не указано, моментальный снимок будет храниться в той же группе ресурсов, что и исходные диски Azure.
incremental Создайте полный или инкрементный моментальный снимок true, false нет true
tags Теги дисков Azure Формат тега: "key1=val1,key2=val2" нет ""
userAgent Агент пользователя, используемый для отслеживания потребления услуг клиентами нет Созданный useragent в формате driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Укажите идентификатор подписки Azure, в которой будут созданы диски Azure Идентификатор подписки Azure нет Если значение не пустое, resourceGroup необходимо указать, incremental должно быть установлено как false.

Создание моментального снимка тома из PVC на дисках Azure

Замечание

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

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

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

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

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

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

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

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

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

  3. Убедитесь, что моментальный снимок тома был успешно создан с помощью kubectl describe команды:

    kubectl describe volumesnapshot azuredisk-volume-snapshot

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

    Name:         azuredisk-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T05:27:58Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  714582
  Self Link:         /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
  UID:               00aa00aa-bb11-cc22-dd33-44ee44ee44ee
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azuredisk
  Volume Snapshot Class Name:      csi-azuredisk-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-00aa00aa-bb11-cc22-dd33-44ee44ee44ee
  Creation Time:                       2020-08-31T05:27:59Z
  Ready To Use:                        true
  Restore Size:                        10Gi
Events:                                <none>

Создание нового PVC на основе моментального снимка тома с помощью дисков Azure

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

  1. Создайте ПВХ и pod с помощью следующих kubectl apply команд:

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

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

    persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created

  2. Проверьте, что это тот же ПВХ, созданный до этого, проверив содержимое тома с помощью kubectl exec команды для выполнения ls команды в модуле pod:

    kubectl exec nginx-restored -- ls /mnt/azuredisk

    Ваши выходные данные должны напоминать следующий пример, который показывает тот же контент, что и в оригинальном PVC, включая файл test.txt, созданный в этом оригинальном PVC.

    lost+found
outfile
test.txt

Клонирование дисковых томов с использованием Azure Disks

Клонированный том определяется как дубликат существующего тома Kubernetes. Дополнительные сведения о клонировании томов в Kubernetes см. в концептуальной документации по клонированию томов.

Драйвер CSI для дисков Azure поддерживает клонирование томов. Чтобы продемонстрировать, создайте клонированный том динамического ПВХ, созданного ранее в этом руководстве, и новый pod для его использования.

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

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

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

    persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created

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

    kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk

    Выходные данные должны выглядеть примерно так же, как исходный ПВХ, в том числе test.txt файл, созданный в исходном ПВХ:

    lost+found
outfile
test.txt

Изменение размера постоянного тома без простоя с помощью дисков Azure

Замечание

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

The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

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

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

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

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

    Выходные данные должны выглядеть примерно так: текущий размер тома составляет 10 Ги.

    Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk

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

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

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

    persistentvolumeclaim/pvc-azuredisk patched

  3. Проверьте pv, чтобы убедиться, что новый размер отражается в PV с помощью kubectl get pv команды:

    kubectl get pv

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

    NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
pvc-a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
(...)

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

    kubectl get pvc pvc-azuredisk

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

    NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pvc-a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1   15Gi       RWO            managed-csi    2d2h

  5. Убедитесь, что размер диска в pod обновлен до нового размера, выполнив команду kubectl exec, чтобы выполнить команду df -h в pod.

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

    Ваши выходные данные должны выглядеть примерно так, как показано, размер тома был обновлен до 15 ГиБ:

    Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         15G   46M   15G   1% /mnt/azuredisk

Динамическое масштабирование для Premium SSD в Azure Disks

Модель динамического увеличения производительности дисков позволяет выполнять всплески производительности всякий раз, когда потребности диска превышают его текущую емкость. Эта модель создает дополнительные расходы в любой момент, когда диск рвется. Возможность увеличения производительности по запросу доступна только для SSD Premium объёмом более 512 ГиБ. Дополнительные сведения о выделенной производительности IOPS и пропускной способности на дисках SSD уровня "Премиум" см. в разделе Размер SSD уровня "Премиум". Кроме того, кредитный взрыв на основе кредитов заключается в том, где диск будет рваться только в том случае, если он накопил кредиты, накопленные в своем кредитном контейнере. Ускорение на основе кредитов не приводит к дополнительным затратам при всплеске диска. Ускорение на основе кредитов доступно только для твердотельных накопителей премиум-класса объемом 512 ГиБ или меньше, а также стандартных твердотельных накопителей объемом 1024 ГиБ или меньше. Дополнительные сведения о всплеске по запросу см. в статье о всплеске по запросу.

Это важно

Класс хранилища по умолчанию managed-csi-premium имеет отключённый режим всплесковой нагрузки по требованию и использует всплесковую нагрузку на основе кредитов. Любой SSD уровня "Премиум", динамически создаваемый запросом на постоянный том на основе класса хранилища по умолчанию managed-csi-premium, также имеет отключенное ускорение по запросу.

Чтобы создать постоянный том SSD уровня "Премиум" с включенным автоматическим увеличением скорости по запросу, можно создать новый класс хранилища с параметром enableBursting, true установленным на значение, как показано в следующем шаблоне YAML. Дополнительные сведения о включении всплеска по запросу см. в разделе Всплеск по запросу. Дополнительные сведения о создании собственного класса хранилища с включенным ускорением по запросу см. в статье Создание класса хранилища CSI Premium с возможностью ускорения.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

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

Драйвер CSI диска Azure поддерживает узлы и контейнеры Windows. Если вы хотите использовать контейнеры Windows, следуйте краткому руководству по добавлению пула узлов Windows. После того как у вас есть пул узлов Windows, можно использовать встроенные классы хранилища, такие как managed-csi.

  1. Разверните пример stateful набора на базе Windows, который сохраняет временные метки в файл data.txt с помощью следующей kubectl apply команды:

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

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

    statefulset.apps/busybox-azuredisk created

  2. Проверьте содержимое файла data.txt в pod, используя команду kubectl exec, чтобы выполнить команду type в pod.

    kubectl exec -it statefulset-azuredisk-win-0 -- powershell -c "type c:/mnt/azuredisk/data.txt"

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

    2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)

Создание статического PV с дисками Azure

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

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

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

Имя. Значение Доступные значения Обязательно Значение по умолчанию
volumeHandle URI диска Azure /subscriptions/{sub-id}/resourcegroups/{group-name}/providers/microsoft.compute/disks/{disk-id} Да N/A
volumeAttributes.fsType Тип файловой системы ext4, , , ext3ext2xfsbtrfs для Linux
ntfs для Windows		 нет ext4 для Linux
ntfs для Windows
volumeAttributes.partition Номер секции существующего диска (поддерживается только в Linux) 1, 2, 3 нет Пустой (без секции) Убедитесь, что формат секции: -part1
volumeAttributes.cachingMode Параметр кэша узла диска None, ReadOnly, ReadWrite нет ReadOnly

Создание диска Azure

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

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

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

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

    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 (в предварительной версии). Производительность по пропускной способности и числу операций ввода-вывода (IOPS) управляемого диска категории Premium зависит как от SKU, так и от размера узлов в кластере AKS. См. Цены и производительность управляемых дисков.

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

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

Создание ПВ и ПВХ, ссылающихся на диск Azure

  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

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

  2. Создайте файл 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

  3. Создайте PV и PVC с помощью следующих kubectl apply команд:

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

  4. Убедитесь, что ваш ПВХ был успешно создан и привязан к ПВ, используя команду kubectl get pvc.

    kubectl get pvc pvc-azuredisk

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

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

Создайте pod, который использует PVC с дисками Azure

  1. Создайте файл azure-disk-pod.yaml , чтобы ссылаться на ПВХ, используя следующий пример манифеста. (Для контейнеров 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

  2. Примените конфигурацию и подключите том с помощью команды kubectl apply.

    kubectl apply -f azure-disk-pod.yaml

Очистите ресурсы

  • Удалите ресурсы, созданные в этом руководстве, с помощью следующих команд [kubectl delete][kubectl-delete]

    # Remove the pod
kubectl delete -f azure-pvc-disk.yaml

# Remove the persistent volume claim
kubectl delete -f azure-pvc.yaml

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

  • Last updated on