Возможности хранения данных в Службе Azure Kubernetes (AKS)

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

Может потребоваться несколько модулей pod:

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

Также может потребоваться собирать конфиденциальные данные или сведения о конфигурации приложения в pod.

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

• Тома
• постоянные тома
• классы хранилищ;
• запросы на постоянные тома

Определение размера диска ОС по умолчанию

Временные диски ОС

Если вы выберете SKU виртуальной машины, поддерживающий эфемерные диски ОС, но не укажете размер диска ОС, AKS по умолчанию подготавливает эфемерный диск ОС с размером, который масштабируется в зависимости от общего объема временного хранилища, при условии, что это хранилище составляет как минимум 128 ГиБ. Например, Standard_D8ds_v5 SKU с временным диском размером 300 ГиБ по умолчанию получает Эфемерный системный диск размером 300 ГиБ, если параметры диска не указаны.

Если вы хотите использовать временное хранилище SKU виртуальной машины, необходимо указать размер диска ОС во время развертывания, в противном случае он используется по умолчанию.

Внимание

Размер диска операционной системы по умолчанию используется только в новых кластерах или пулах узлов, где поддерживаются временные диски ОС и размер диска ОС по умолчанию не указан. Размер диска ОС по умолчанию может повлиять на производительность или стоимость кластера. Невозможно изменить размер диска ОС после создания кластера или пула узлов. Это изменение размера по умолчанию «Ephemeral» влияет на кластеры или пулы узлов, созданные в марте 2025 года или позже.

Управляемые диски ОС

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

Ядра SKU виртуальной машины (виртуальные ЦП)	Уровень диска ОС по умолчанию	Резервируемые IOPS	Подготовленная пропускная способность (Мбит/с)
1–7	P10/128G	500	100
8–15	P15/256G	1 100	125
16–63	P20/512G	2300	сто пятьдесят
64+	P30/1024G	5 000	200

Внимание

Размер диска управляемой ОС по умолчанию используется только в новых кластерах или пулах узлов, если диски Эфемерной ОС не поддерживаются, а размер диска ОС по умолчанию не указан. Размер диска ОС по умолчанию может повлиять на производительность или стоимость кластера. Невозможно изменить размер диска ОС после создания кластера или пула узлов. Рекомендуется использовать минимальный размер диска размером 512 Г, если не удается использовать временные диски ОС. Это управляемое изменение размера по умолчанию влияет на кластеры или пулы узлов, созданные в июле 2022 г. или более поздней версии.

Временный диск ОС

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

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

Примечание.

Если вы явно не запрашиваете управляемые диски Azure для ОС, AKS по умолчанию использует эфемерную ОС, если это возможно для заданной конфигурации пула узлов.

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

В последнем поколении серии виртуальных машин нет выделенного кэша, а только временного хранилища. Например, если выбран размер виртуальной машины Standard_E2bds_v5 с размером диска ОС по умолчанию 100 ГиБ, он поддерживает временные диски ОС, но имеет только 75 ГБ временного хранилища. Эта конфигурация по умолчанию использует управляемые диски ОС, если ее явно не указать. Если вы запрашиваете временный диск ОС, вы получите ошибку проверки.

• Если вы запрашиваете тот же размер виртуальной машины Standard_E2bds_v5 с диском ОС 60 ГиБ, эта конфигурация по умолчанию используется для временных дисков ОС. Запрошенный размер 60 ГиБ меньше максимального временного хранилища 75 ГиБ.
• Если выбрать номер SKU Standard_E4bds_v5 с диском ОС 100 ГиБ, этот размер виртуальной машины поддерживает эфемерную ОС и имеет 150 ГиБ временного хранилища. Если вы не указываете тип диска ОС, Azure подготавливает временный диск ОС к пулу узлов по умолчанию.

Виртуальные машины предыдущего поколения и снятые с производства размеры имеют выделенное пространство кэша в дополнение к временному дисковому пространству. Однако при оценке эфемерного размещения используется дисковое пространство кэша, а не временного хранилища.

Ключи, управляемые клиентом

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

Временные диски данных NVMe

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

Временные диски данных NVMe изначально были доступны только на виртуальных машинах Виртуальной машины Azure серии L, серии E и GPU. Благодаря внедрению поколений виртуальных машин Azure версии 6 и 7 поддержка временных дисков данных NVMe расширилась до более широкого диапазона размеров виртуальных машин, включая серии D, серии F, серии H и многое другое. Диски NVMe обеспечивают более высокие IOPS и пропускную способность по сравнению с традиционными вариантами HDD или SSD. Однако данные, хранящиеся на этих дисках, являются временными и будут потеряны, если виртуальная машина деаллоцирована или переразвернута.

Чтобы упростить управление и подготовку временных дисков данных NVMe в AKS, используйте хранилище контейнеров Azure. Хранилище контейнеров Azure может автоматически обнаруживать и оркестрировать диски данных NVMe, позволяя создавать постоянные тома для рабочих нагрузок Kubernetes и управлять ими с минимальной конфигурацией. Этот подход рекомендуется для сценариев, когда требуется высокопроизводительное временное хранилище, например:

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

Внимание

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

Дополнительные сведения об использовании хранилища контейнеров Azure с временными дисками данных NVMe см. в статье "Использование хранилища контейнеров Azure с AKS".

Объемы

Kubernetes обычно рассматривает отдельные модули pod как временные, освобождаемые ресурсы. Для использования и сохранения данных внутри приложений предусмотрены различные подходы. Том представляет способ хранения, извлечения и сохранения данных подов в течение жизненного цикла приложения.

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

Примечание.

В зависимости от SKU используемой виртуальной машины, драйвер CSI диска Azure может иметь ограничение на количество томов на узел. Для некоторых высокопроизводительных виртуальных машин (например, 16 ядер) ограничение составляет 64 тома на узел. Чтобы определить ограничение на номер SKU виртуальной машины, просмотрите столбец "Максимальное количество дисков данных" для каждого предлагаемого номера SKU виртуальной машины. Список предлагаемых номеров SKU виртуальных машин и их соответствующих подробных ограничений емкости см. в разделе "Размеры виртуальных машин общего назначения".

Чтобы определить, что лучше подходит для вашей рабочей нагрузки — Azure Files или Azure NetApp Files, ознакомьтесь с информацией в статье Сравнение Azure Files и Azure NetApp Files.

Диск Azure

Используйте Azure Disk для создания ресурса DataDisk Kubernetes. Типы дисков включают:

• SSD уровня "Премиум" (рекомендуется для большинства рабочих нагрузок)
• Диски категории "Ультра"
• Стандартные SSD-диски
• стандартные жесткие диски

Совет

Для большинства рабочих нагрузок и рабочих нагрузок разработки используйте диски SSD класса Premium.

Так как диск Azure подключен как ReadWriteOnce, он доступен только одному узлу. Для томов хранилища, которые доступны подами на нескольких узлах одновременно, используйте Azure Files.

Файлы Azure

Используйте Файлы Azure для монтирования общей папки на базе Server Message Block (SMB) версии 3.1.1 или сетевой файловой системы (NFS) версии 4.1. Файлы Azure позволяют совместно использовать данные между несколькими узлами и модулями pod, а также использовать:

• Хранилище Azure категории "Премиум", использующее твердотельные накопители (SSD) высокой производительности
• Хранилище Azure категории Standard, использующее обычные жесткие диски

Файлы Azure NetApp

• Хранилище Ультра
• Хранилище класса Premium
• Стандартное хранилище

Хранилище BLOB-объектов Azure

Хранилище BLOB-объектов Azure позволяет создать контейнер хранилища BLOB-объектов и подключить его с помощью протокола NFS версии 3.0 или BlobFuse.

• Блочные блоб-объекты

Типы томов

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

Распространенные типы томов в Kubernetes включают:

пустая директория

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

секрет

Вы можете использовать секретные тома для внедрения конфиденциальных данных в поды, например пароли.

1. Создайте секрет с помощью API Kubernetes.
2. Определите под или развертывание и запросите определённый секрет.
   • Секреты предоставляются только узлам, на которых запланирован под, который их требует.
   • Секрет хранится в tmpfs, а не записывается на диск.
3. При удалении последнего модуля pod на узле, требующего секрета, секрет удаляется из tmpfs узла.
   • Секреты хранятся в заданном пространстве имен и доступны только для podов в том же пространстве имен.

configMap

Вы можете использовать configMap для внедрения свойств в pod'ы, таких как сведения о конфигурации приложения. Определите информацию о конфигурации приложения в качестве ресурса Kubernetes, чтобы в этом формате ее было легко обновлять и применять к новым экземплярам pod по мере развертывания.

Как и в случае использования секрета:

1. Создайте ConfigMap с помощью API Kubernetes.
2. Запрашивайте ConfigMap при определении pod или при развертывании.
   • ConfigMaps хранятся в заданном пространстве имён и доступны только подам в том же пространстве имён.

Постоянные тома

Тома определяются и создаются в ходе жизненного цикла pod. Они существуют только до удаления pod. Нередко pod-ы ожидают, что их хранилище сохранится при переносе на другой хост во время события обслуживания, особенно в StatefulSets. Постоянный том — это ресурс хранилища, для создания и управления которым используется API Kubernetes. Этот том может существовать после истечения времени существования отдельного pod.

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

• Диск Azure
• Файлы Azure
• Хранилище контейнеров Azure

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

Администратор кластера может статически создать постоянный том, или том можно создавать динамически с помощью сервера API Kubernetes. Если модуль pod запланирован и запрашивает хранилище, которое сейчас недоступно, Kubernetes может создать базовое хранилище дисков Azure или файлов и подключить его к pod. Динамическая подготовка использует класс хранилища для определения типа ресурса, который необходимо создать.

Внимание

Постоянные тома не могут использоваться совместно подами Windows и Linux из-за различий в поддержке файловых систем между двумя операционными системами.

Если вы хотите полностью управляемое решение для доступа на уровне блоков к данным, рассмотрите возможность использования хранилища контейнеров Azure вместо драйверов CSI. Хранилище контейнеров Azure интегрируется с Kubernetes, обеспечивая динамическую и автоматическую подготовку постоянных томов. Хранилище контейнеров Azure поддерживает диски Azure, временные диски и Azure Elastic SAN (предварительная версия) в качестве резервного хранилища, предлагая гибкость и масштабируемость для приложений с отслеживанием состояния, работающих в кластерах Kubernetes.

Классы хранилищ

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

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

Для кластеров, использующих хранилище контейнеров Azure, вы увидите дополнительный класс acstor-<storage-pool-name>хранилища. Также создается внутренний класс хранилища.

Для кластеров с помощью драйверов интерфейса хранилища контейнеров (CSI) создаются следующие дополнительные классы хранилища:

Класс хранения	Описание
managed-csi	Использует локально избыточное хранилище Azure Standard SSD (LRS) для создания управляемого диска. Политика восстановления гарантирует, что базовый диск Azure удаляется при удалении использующего его постоянного тома. Класс хранилища также настраивает постоянные тома так, чтобы их можно было расширять. Можно изменить запрос на постоянный том, чтобы указать новый размер. Начиная с версии 1.29 Kubernetes, в кластерах Azure Kubernetes Service (AKS), развернутых в нескольких зонах доступности, этот класс хранилища использует зонально-избыточное хранилище Azure Standard SSD (ZRS) для создания управляемых дисков.
managed-csi-premium	Использует локально избыточное хранилище Azure Premium (LRS) для создания управляемого диска. Политика восстановления снова гарантирует, что базовый диск Azure удаляется при удалении постоянного тома, который его использовал. Аналогичным образом, этот класс хранения позволяет расширять постоянные тома. Начиная с версии Kubernetes 1.29, в кластерах службы Azure Kubernetes Service (AKS), развернутых в нескольких зонах доступности, этот класс хранилища использует зонально избыточное хранилище Azure Premium (ZRS) для создания управляемых дисков.
azurefile-csi	Использует хранилище Azure уровня "Стандартный" для создания общей папки Azure. Политика восстановления гарантирует, что базовый файловый ресурс Azure удаляется при удалении постоянного тома, который использовал его.
azurefile-csi-premium	Использует хранилище Azure Premium для создания общей папки Azure. Политика восстановления гарантирует, что базовый файловый ресурс Azure удаляется при удалении постоянного тома, который использовал его.
azureblob-nfs-premium	Использует хранилище Azure класса Premium для создания контейнера хранилища BLOB-объектов Azure и подключения с помощью протокола NFS версии 3. Политика восстановления гарантирует, что базовый контейнер хранилища BLOB-объектов Azure удаляется при удалении постоянного тома, который его использовал.
azureblob-fuse-premium	Использует хранилище Azure класса Premium для создания контейнера хранилища BLOB-объектов Azure и подключения с помощью BlobFuse. Политика восстановления гарантирует, что базовый контейнер хранилища BLOB-объектов Azure удаляется при удалении постоянного тома, который его использовал.

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

Внимание

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

Класс default будет таким же, как класс managed-csi.

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

Однако важно отметить, что хранилище с избыточностью между зонами (ZRS) обходится дороже, чем локальное избыточное хранилище (LRS). Если оптимизация затрат является приоритетом, можно создать класс хранилища с параметром, заданным skuname для LRS. Затем можно использовать новый класс хранилища в запросе на выделение постоянного тома (PVC).

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Примечание.

AKS согласовывает классы хранения по умолчанию и перезаписывает любые изменения, внесенные в эти классы хранения.

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

запросы на постоянный том.

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

Определение pod включает в себя подключение тома после его присоединения к pod.

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

В следующем примере манифеста YAML показан запрос на выделение постоянного тома, который использует класс хранилища managed-premium и запрашивает диск Azure размером 5 GiB.

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

При создании определения Pod также следует указать:

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

В следующем примере YAML-манифеста показано, как предыдущий запрос на постоянный том может использоваться для подключения тома по пути /mnt/azure.

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Для монтажа тома в контейнере Windows укажите букву диска и путь. Например:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

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

Советы по лучшим практикам см. в разделах Лучшие практики хранения и резервного копирования в AKS и Соображения по хранению в AKS.

Дополнительные сведения о хранилище контейнеров Azure см. в следующих статьях:

• Что такое хранилище контейнеров Azure?
• Использование хранилища контейнеров Azure с AKS

Дополнительные сведения об использовании драйверов CSI см. в следующих статьях:

• Драйверы Container Storage Interface (CSI) для Azure дисков, Azure файлов и хранилища Blob-объектов Azure в службе Azure Kubernetes
• Использование драйвера Azure Disk CSI в Службе Azure Kubernetes
• Драйвер Azure Files CSI в Службе Kubernetes Azure
• Использование драйвера CSI хранилища Blob Azure в службе Azure Kubernetes
• Настройка Azure NetApp Files с помощью Службы Azure Kubernetes

Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:

• Кластеры и рабочие нагрузки Kubernetes и AKS
• Идентификация в Kubernetes и AKS
• Безопасность Kubernetes и AKS
• Виртуальные сети Kubernetes и AKS
• Масштабирование Kubernetes и AKS