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

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

В этой статье сравниваются возможности хранилища Службы Amazon Elastic Kubernetes (EKS) и Службы Azure Kubernetes (AKS). В нем также описываются параметры хранения данных рабочей нагрузки в AKS.

Примечание.

Эта статья является частью серии статей, которые помогают специалистам, знакомым с Amazon EKS, понять Службу Azure Kubernetes (AKS).

Параметры хранения Amazon EKS

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

Временные тома

Для приложений, требующих временных локальных томов, но не требуется сохранять данные после перезапуска, используйте временные тома. Kubernetes поддерживает различные типы временных томов, таких как emptyDir, ConfigMap, downwardAPI, Secret и hostPath. Чтобы обеспечить экономическую эффективность и производительность, выберите наиболее подходящий том размещения. В Amazon EKS можно использовать gp3 в качестве корневого тома узла, который обходится дешевле, чем тома gp2.

Вы также можете использовать хранилища экземпляров Amazon EC2, которые предоставляют временное хранилище на уровне блоков для экземпляров EC2. Эти тома физически присоединены к узлам хоста и существуют только в течение времени существования экземпляра. Чтобы использовать тома локального хранилища в Kubernetes, необходимо секционировать, настроить и отформатировать диски с помощью пользовательских данных Amazon EC2.

Персистентные тома

Обычно для запуска приложений без отслеживания состояния используется Kubernetes, но иногда требуется постоянное хранилище данных. Постоянные тома Kubernetes можно использовать для хранения данных независимо от подов, чтобы данные могли сохраняться и после завершения времени существования данного пода. Amazon EKS поддерживает различные типы вариантов хранения постоянных томов, включая Amazon EBS, Amazon Elastic File System (EFS), AmazonFSx для Lustre и Amazon FSx для NetApp ONTAP.

Используйте тома Amazon EBS для хранения на уровне блоков и для баз данных и приложений с высокой пропускной способностью. Пользователи Amazon EKS могут использовать последнее поколение хранилища блоков gp3 для баланса между ценами и производительностью. Для приложений с более высокими требованиями к производительности вы можете использовать тома io2 Block Express.

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

Amazon FSx для Lustre обеспечивает высокопроизводительный параллельный файловый хранилище. Используйте этот тип хранилища для сценариев, требующих операций с высокой пропускной способностью и низкой задержкой. Вы можете связать это хранилище файлов с репозиторием данных Amazon S3 для хранения больших наборов данных. Amazon FSx для NetApp ONTAP — это полностью управляемое решение для хранения данных, созданное на основе файловой системы ONTAP NetApp.

Чтобы оптимизировать конфигурации хранилища и управлять резервными копиями и моментальными снимками, используйте такие инструменты, как AWS Compute Optimizer и Velero.

Параметры хранения AKS

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

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

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

Типы томов

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

Распространенные типы томов в Kubernetes включают emptyDirs, секреты и ConfigMaps.

EmptyDirs

Для модуля pod, который определяет пустой томDir, том создается при назначении модуля pod узлу. Как следует из названия, объём emptyDir изначально пуст. Все контейнеры в pod могут читать и записывать одни и те же файлы в томе emptyDir, при этом этот том может быть примонтирован по одному и тому же или разным путям в каждом контейнере. Когда модуль pod удаляется из узла по какой-либо причине, данные в пустомdir удаляются окончательно.

Секреты

Секрет — это объект, содержащий небольшой объем конфиденциальных данных, например пароль, маркер или ключ. Если вы не используете секрет, эти сведения включаются в спецификацию pod или образ контейнера. Секрет предотвращает необходимость внедрения конфиденциальных данных непосредственно в код приложения. Вы можете создавать секреты независимо от модулей, которые их используют. Эта практика снижает риск предоставления секрета и его данных при создании, просмотре и изменении модулей pod. Kubernetes и приложения, которые выполняются в кластере, могут принимать дополнительные меры предосторожности с секретами, например, предотвращая запись конфиденциальных данных в неналатильное хранилище. Секреты похожи на ConfigMaps, но специально предназначены для хранения конфиденциальных данных.

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

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

ConfigMaps

ConfigMap — это объект Kubernetes, используемый для хранения неконфиденциальных данных в парах "ключ-значение". Поды могут использовать ConfigMaps в качестве переменных среды, аргументов командной строки или в виде файлов конфигурации в томе . С помощью ConfigMap можно разделить конфигурации, относящиеся к среде, из образов контейнеров, что упрощает перенос приложений.

ConfigMaps не предоставляют секретность или шифрование. Если вы хотите хранить конфиденциальные данные, используйте секрет , а не ConfigMap или используйте другие партнерские средства для сохранения конфиденциальности данных.

С помощью ConfigMap можно задать данные конфигурации отдельно от кода приложения. Например, вы можете разработать приложение для запуска на компьютере для разработки и запуска в облаке для обработки реального трафика. Вы можете написать код для поиска в переменной среды с именем DATABASE_HOST. Локально задайте для этой переменной localhostзначение . В облаке задайте для него ссылку на службу Kubernetes, которая предоставляет компонент базы данных кластеру. Этот подход позволяет получить образ контейнера, который выполняется в облаке, и при необходимости отлаживать тот же код локально.

Персистентные тома

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

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

Схема постоянных томов в кластере AKS.

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

Важный

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

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

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

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

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

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

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

Класс хранилища Описание
managed-csi Использует ssd Azure уровня "Стандартный" с локальным избыточным хранилищем (LRS) для создания управляемого диска. Политика возврата гарантирует, что базовый диск Azure удаляется одновременно с удалением связанного с ним постоянного тома. Класс хранилища также настраивает персистентные тома таким образом, чтобы их можно было расширять. Можно изменить заявку на постоянный том, чтобы указать новый размер.

Для Kubernetes версии 1.29 и более поздних версий этот класс хранилища использует SSD уровня Стандартный с зонально избыточным хранилищем (ZRS) для создания управляемых дисков для кластеров AKS, развернутых в нескольких зонах высокой доступности.
managed-csi-premium Использует ssd Azure Premium с LRS для создания управляемого диска. Политика возврата гарантирует, что базовый диск Azure удаляется одновременно с удалением связанного с ним постоянного тома. Этот класс хранилища позволяет развертывать постоянные тома.

Для Kubernetes версии 1.29 и более поздних версий этот класс хранения использует SSD класса Premium с ZRS для создания управляемых дисков для кластеров AKS, развернутых в нескольких зонах доступности.
azurefile-csi Использует хранилище SSD уровня "Стандартный" для создания общей папки Azure. Политика восстановления гарантирует, что базовый файловый ресурс Azure удаляется при удалении постоянного тома, используемого им.
azurefile-csi-premium Использует хранилище SSD класса Premium для создания общей папки Azure. Политика восстановления гарантирует, что базовый файловый ресурс Azure удаляется при удалении постоянного тома, используемого им.
azureblob-nfs-premium Использует хранилище SSD класса Premium для создания контейнера хранилища BLOB-объектов и подключения через протокол NFS версии 3. Политика восстановления гарантирует, что базовый контейнер хранилища BLOB-объектов удаляется при удалении постоянного тома, используемого им.
azureblob-fuse-premium Использует хранилище SSD класса Premium для создания контейнера хранилища BLOB-объектов и подключения через BLOBFuse. Политика восстановления гарантирует, что базовый контейнер хранилища BLOB-объектов удаляется при удалении постоянного тома, используемого им.

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

Важный

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

Класс default совпадает с классом managed-csi .

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

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

Класс хранилища для других потребностей можно создать с помощью 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.

Диаграмма запросов на постоянный том в кластере AKS.

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

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

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

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

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

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

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

Требования к размеру и рекомендации см. в разделе "Временные диски ОС" для виртуальных машин Azure. Рассмотрим следующие рекомендации по размеру:

  • Если вы используете размер виртуальной машины AKS по умолчанию Standard_DS2_v2 SKU с размером диска ОС по умолчанию 100 ГиБ, размер виртуальной машины по умолчанию поддерживает временные диски ОС, но имеет только размер кэша 86 ГиБ. Эта конфигурация по умолчанию использует управляемые диски, если ее не указать. Если вы запрашиваете временный диск ОС, вы получите ошибку проверки.

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

  • Если выбрать номер SKU Standard_D8s_v3 с диском ОС размером 100 ГБ, этот размер виртуальной машины поддерживает временные диски ОС и имеет размер кэша 200 ГиБ. Если тип диска ОС не указан, пул узлов по умолчанию получает временные диски ОС.

Последнее поколение серии виртуальных машин не имеет выделенного кэша и имеет только временное хранилище.

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

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

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

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

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

Объемы

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

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

Примечание.

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

Сведения о выборе между файлами Azure и Azure NetApp Files см. в статье "Файлы Azure" и сравнение Azure NetApp Files.

Хранилище дисков Azure

По умолчанию кластер AKS поставляется с предварительно созданными managed-csi классами и managed-csi-premium классами хранилища, используюющими хранилище дисков Azure. Как и в Amazon EBS, эти классы создают управляемый диск или блочное устройство, подключенное к узлу для доступа к pod.

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

Эти классы хранилища используют управляемые диски Azure с LRS. Данные в LRS имеют три синхронные копии в одном физическом расположении в основном регионе Azure. LRS является наименее дорогим вариантом репликации, но не обеспечивает защиту от сбоя центра обработки данных. Можно определить пользовательские классы хранилища, использующие управляемые диски ZRS.

ZRS синхронно реплицирует управляемый диск Azure в трех зонах доступности Azure в вашем регионе. Каждая зона доступности — это отдельное физическое расположение с независимым питанием, охлаждением и сетью. Диски ZRS обеспечивают по крайней мере 99,9999999999999% надежности в течение заданного года. Управляемый диск ZRS может быть подключен виртуальной машиной в другой зоне доступности. Диски ZRS недоступны во всех регионах Azure. Дополнительные сведения см. в разделе "Параметры ZRS" для дисков Azure для повышения доступности.

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

Хранилище дисков Azure можно использовать для создания ресурса DataDisk Kubernetes. Можно использовать следующие типы дисков:

Совет

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

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

Диски SSD уровня "Премиум" версии 2

Диски Premium SSD v2 предназначены для интенсивных операций ввода-вывода в корпоративных рабочих нагрузках. Они обеспечивают согласованную задержку диска подмиллисекунда, высокую пропускную способность операций ввода-вывода в секунду (IOPS) и высокую пропускную способность. Вы можете независимо настроить производительность (емкость, операции ввода-вывода в секунду и пропускную способность) дисков SSD уровня Premium версии 2 в любое время. Таким образом, вы легко повышаете эффективность затрат при удовлетворении потребностей в производительности. Дополнительные сведения о настройке нового или существующего кластера AKS для использования дисков SSD уровня "Премиум" версии 2 см. в статье "Использование дисков SSD уровня "Премиум" версии 2 в AKS.

Ультра дисковое хранилище

Хранилище дисков ценовой категории "Ультра" — это управляемый диск Azure, обеспечивающий высокую пропускную способность, высокий объем операций ввода-вывода в секунду и согласованное хранилище дисков с низкой задержкой для виртуальных машин Azure. Используйте хранилище дисков ценовой категории "Ультра" для рабочих нагрузок с большим объемом данных и транзакций. Как и другие единицы SKU дискового хранилища и Amazon EBS, хранилище Ultra Disk Storage подключает один pod одновременно и не обеспечивает совместный доступ.

Чтобы включить хранилище дисков ценовой категории "Ультра" в кластере AKS, используйте флаг --enable-ultra-ssd.

Помните об ограничениях хранилища дисков ценовой категории "Ультра" и выберите совместимый размер виртуальной машины. Дисковое хранилище Ultra имеет репликацию LRS.

Предоставьте собственные ключи (BYOK)

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

Файлы Azure

Дисковое хранилище не может предоставить одновременный доступ к томам, но вы можете использовать Azure Files для монтирования совместного ресурса SMB версии 3.1.1 или NFS версии 4.1, которые поддерживаются службой хранилища Azure. Этот процесс предоставляет подключенное к сети хранилище, аналогичное Amazon EFS. Служба "Файлы Azure" имеет два варианта хранения:

  • Хранилище Azure Files Standard обеспечивает поддержку файлового ресурса с помощью обычных жестких дисков (HDD).

  • Хранилище Azure Files Premium поддерживает общую папку с высокопроизводительными твердотельными дисками (SSD). Минимальный размер общей папки для Premium составляет 100 ГБ.

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

Чтобы оптимизировать затраты на Azure Files, приобретите резервирование емкости для Azure Files.

Файлы Azure NetApp

Azure NetApp Files — это корпоративная, высокопроизводительная служба хранилища файлов, которая работает в Azure и поддерживает тома с помощью томов NFS (NFSv3 или NFSv4.1), SMB и двойного протокола (NFSv3 и SMB или NFSv4.1 и SMB). Пользователи Kubernetes имеют два варианта использования томов Azure NetApp Files для рабочих нагрузок Kubernetes:

  • Статически создавайте тома Azure NetApp Files. Создайте тома за пределами AKS с помощью Azure CLI или портала Azure. После создания эти тома подключаются к Kubernetes путем создания PersistentVolume. Статически созданные тома Azure NetApp Files имеют множество ограничений. Например, их нельзя расширить, и их необходимо избыточно резервировать. Мы не рекомендуем статически созданные тома для большинства вариантов использования.

  • Динамически создавайте тома Azure NetApp Files с помощью Kubernetes. Это предпочтительный метод для создания нескольких томов непосредственно через Kubernetes с помощью Astra Trident. Astra Trident — это совместимый с CSI оркестратор динамического хранилища, который помогает изначально подготавливать тома через Kubernetes.

Дополнительные сведения см. в статье "Настройка Azure NetApp Files для AKS".

Хранилище блобов

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

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

При подключении хранилища BLOB-объектов в качестве файловой системы в контейнер или pod его можно использовать с приложениями, обрабатывающими большие объемы неструктурированных данных, например:

  • Данные файла журнала.
  • Изображения, документы и потоковая передача видео или аудио.
  • Данные аварийного восстановления.

Приложения могут получить доступ к данным в хранилище объектов через BLOBFuse или протокол NFS 3.0. Перед введением драйвера CSI хранилища BLOB-объектов единственным вариантом было вручную установить неподдерживаемый драйвер для доступа к хранилищу BLOB-объектов из приложения, работающего в AKS. Драйвер CSI хранилища BLOB-объектов, включенный в AKS, имеет два встроенных класса хранилища: azureblob-fuse-premium и azureblob-nfs-premium.

Чтобы создать кластер AKS с поддержкой драйверов CSI, ознакомьтесь с драйверами CSI в AKS. Для получения дополнительной информации см. Сравнение доступа к файлам Azure, хранилищу BLOB-объектов и Azure NetApp Files с NFS.

Azure HPC Cache

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

Сервер NFS

Для общего доступа к NFS следует использовать файлы Azure или Azure NetApp Files. Вы также можете создать сервер NFS на виртуальной машине Azure , которая экспортирует тома.

Этот параметр поддерживает только статическую подготовку. Необходимо вручную подготовить ресурсы NFS на сервере. Вы не можете автоматически создать общие папки NFS в AKS.

Это решение основано на инфраструктуре как услуга (IaaS), а не на платформе как услуга (PaaS). Вы управляете сервером NFS, включая обновления ОС, высокий уровень доступности, резервные копии, аварийное восстановление и масштабируемость.

Хранилище контейнеров Azure

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

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

  • Диски Azure: Обеспечивают подробный контроль SKU и конфигураций хранилища. Диски Azure подходят для баз данных уровня 1 и общего назначения.

  • Временные диски: Используйте локальные ресурсы хранилища на узлах AKS (NVMe или temp SSD). Временные диски подходят для приложений, которые не имеют требований к устойчивости данных или имеют встроенную поддержку репликации данных. AKS обнаруживает доступное эфемерное хранилище на узлах AKS и аккумулирует его для развертывания томов.

  • Эластичная SAN: Предоставление полностью управляемых ресурсов по запросу. Elastic SAN подходит для баз данных общего назначения, служб потоковой передачи и обмена сообщениями, непрерывной интеграции и непрерывной доставки, а также других рабочих нагрузок уровня 1 или уровня 2. Несколько кластеров могут одновременно получить доступ к одной сети хранения (SAN). Однако постоянные тома могут быть подключены только одним клиентом одновременно.

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

Хранилище контейнеров Azure является производным от OpenEBS, решения с открытым исходным кодом, которое предоставляет возможности хранения контейнеров для Kubernetes. Сервис Azure Container Storage предоставляет управляющую оркестрацию томов данных с помощью контроллеров хранилища на основе микрослужб в среде Kubernetes. Эта функция обеспечивает истинное хранилище на основе контейнера.

Хранилище контейнеров Azure подходит для следующих сценариев:

  • Ускорьте инициативы по переходу от виртуальных машин к контейнерам: Хранилище контейнеров Azure открывает полный спектр возможностей блочного хранилища Azure, которые ранее были доступны только для виртуальных машин, и теперь делает их доступными для контейнеров. Это хранилище включает в себя эфемерное хранилище дисков, которое обеспечивает крайне низкую задержку для рабочих нагрузок, таких как Cassandra. Она также включает в себя эластичную SAN, которая предоставляет собственные целевые объекты iSCSI и общие подготовленные целевые объекты.

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

  • Уменьшите общую стоимость владения: Чтобы повысить эффективность затрат, увеличьте масштаб постоянных томов, поддерживаемых для каждого модуля pod или узла. Чтобы уменьшить потребность в ресурсах хранилища, необходимых для выделения, динамически распределяйте ресурсы хранилища. Поддержка масштабирования для самого пула хранения не включена.

Хранилище контейнеров Azure обеспечивает следующие ключевые преимущества:

  • Быстрое масштабирование pod'ов (контейнерных модулей) с сохранением состояния: Хранилище контейнеров Azure подключает постоянные тома с помощью протоколов сетевого блочного хранения, таких как NVMe-oF или iSCSI. Эта возможность обеспечивает быстрое подключение и отсоединение персистентных томов. Можно начать с малого и развертывать ресурсы по мере необходимости, чтобы гарантировать, что ваши приложения не испытывают нехватки ресурсов и сбоев во время инициализации или на этапе эксплуатации. При повторном запуске pod в кластере связанный постоянный том должен быть быстро перенесён в новый pod для обеспечения устойчивости приложения. Используя протоколы удаленной сети, хранилище контейнеров Azure тесно связывается со жизненным циклом pod для поддержки высоконадежных высокомасштабных приложений с отслеживанием состояния в AKS.

  • Улучшение производительности для рабочих нагрузок, требующих отслеживания состояния: Хранилище контейнеров Azure обеспечивает превосходную производительность чтения и предоставляет производительность записи, близкую к уровню дискового хранилища, с помощью NVMe-oF по протоколу RDMA. Эта возможность позволяет эффективно удовлетворять требования к производительности для различных контейнерных рабочих нагрузок, включая нагрузки уровня 1 с интенсивными операциями ввода-вывода, общего назначения, чувствительные к пропускной способности и рабочие нагрузки для разработки и тестирования. Ускорьте время подключения и отключения постоянных томов и сведите к минимуму время переключения подсистем.

  • Оркестрация томов, совместимых с Kubernetes: Создание пулов хранения и постоянных томов, сохранение моментальных снимков и управление всем жизненным циклом томов с помощью kubectl команд без перехода между инструментами для выполнения различных операций управления.

Решения партнеров

Как и система Amazon EKS, AKS — это реализация Kubernetes, и вы можете интегрировать партнерские решения для хранения данных в Kubernetes. Ниже приведены некоторые примеры решений для хранилища партнеров для Kubernetes:

  • Rook превращает распределенные системы хранения в самоуправляемые службы хранения, автоматизируя задачи администратора хранилища Azure. Rook предоставляет свои услуги через оператор Kubernetes для каждого поставщика хранилища.

  • GlusterFS — это бесплатная масштабируемая сетевая файловая система с открытым исходным кодом, которая использует общее аппаратное обеспечение вне полки для создания больших распределенных решений хранилища для задач с большим объемом данных и пропускной способности.

  • Ceph предоставляет надежную и масштабируемую унифицированную службу хранения, которая содержит объекты, блоки и файловые интерфейсы из одного кластера, созданного из сырьевых аппаратных компонентов.

  • Хранилище объектов MinIO multicloud позволяет предприятиям создавать инфраструктуру данных, совместимую с AWS S3, в любом облаке. Он предоставляет согласованный, переносимый интерфейс для данных и приложений.

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

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

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

Рекомендации по хранилищу Kubernetes

При выборе решения для хранения для Amazon EKS или AKS следует учитывать следующие факторы.

Режимы доступа класса хранилища

В версии 1.21 и более поздних версиях Kubernetes, классы хранилища AKS и Amazon EKS по умолчанию используют только драйверы CSI.

Различные службы поддерживают классы хранилища с различными режимами доступа.

Сервис ReadWriteOnce Режим только для чтения (ReadOnlyMany) ReadWriteMany
Хранилище дисков Azure X
Файлы Azure X X X
Файлы Azure NetApp X X X
Сервер NFS X X X
HPC Cache X X X

Динамическое vs. статическое распределение

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

Резервное копирование

Выберите средство для резервного копирования постоянных данных. Средство должно соответствовать типу хранилища, такому как моментальные снимки, Azure Backup, Velero или Kasten.

Оптимизация затрат

Чтобы оптимизировать затраты на службу хранилища Azure, используйте резервирования Azure, если служба поддерживает их. Дополнительные сведения см. в разделе "Управление затратами" для кластера Kubernetes.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

Другие участники:

  • Чад Киттель | Главный инженер по программному обеспечению — шаблоны и методики Azure
  • Эд Прайс | Старший диспетчер программ содержимого
  • Теано Питерсен | Технический писатель

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

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