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

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

  • Статья

В этой статье сравниваются возможности хранилища Amazon Elastic Kubernetes Service (Amazon 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 (PV) можно использовать для хранения данных независимо от модулей, что позволяет сохранять данные дольше времени существования данного модуля. Amazon EKS поддерживает различные типы хранилищ для PV, включая Amazon EBS, Amazon EFS, Amazon FSx для Lustreи Amazon FSx для NetApp ONTAP.

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

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

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

Пользователи Amazon EKS могут использовать такие средства, как оптимизатор вычислений AWS и Velero для оптимизации конфигураций хранилища и управления резервными копиями и моментальными снимками.

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

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

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

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

Типы томов

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

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

EmptyDirs

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

Секреты

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

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

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

ConfigMaps

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

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

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

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

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

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

схема постоянных томов в кластере Служб Azure Kubernetes (AKS).

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

Важный

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

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

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

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

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

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

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

Класс хранилища Описание
managed-csi Использует локально избыточное хранилище Azure Standard SSD (LRS) для создания управляемого диска. Политика восстановления гарантирует, что базовый диск Azure удаляется при удалении постоянного тома, используемого им. Класс хранилища также настраивает персистентные тома таким образом, чтобы их можно было расширять. Можно изменить заявку на постоянный том, чтобы указать новый размер. Эффективно начиная с версии Kubernetes 1.29 в кластерах службы Azure Kubernetes (AKS), развернутых в нескольких зонах доступности, этот класс хранилища использует зоне-избыточное хранилище Azure Standard SSD (ZRS) для создания управляемых дисков.
managed-csi-premium Использует локально избыточное хранилище Azure Premium (LRS) для создания управляемого диска. Политика восстановления снова гарантирует, что базовый диск Azure удаляется при удалении постоянного тома, который использовался. Аналогичным образом этот класс хранилища позволяет расширить постоянные тома. Начиная с версии Kubernetes 1.29, в кластерах Службы Azure Kubernetes (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. Политика возврата предусматривает, что контейнер Azure Blob Storage удаляется при удалении постоянного используемого тома.
azureblob-fuse-premium Использует хранилище Azure Premium для создания контейнера в хранилище Blob Azure и подключения через BlobFuse. Политика возврата предусматривает, что контейнер Azure Blob Storage удаляется при удалении постоянного используемого тома.

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

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

Класс default будет совпадать с managed-csi.

Начиная с версии 1.29 Kubernetes, при развертывании кластеров Azure Kubernetes Service (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.

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

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

В следующем примере манифеста 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 обычно рассматривает поды как временные, одноразовые ресурсы. Приложения имеют различные подходы к использованию и сохранению данных. Том представляет способ хранения, извлечения и сохранения данных в модулях pod и жизненном цикле приложения.

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

Примечание.

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

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

Диск Azure

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

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

Эти классы хранения используют управляемые диски Azure с локальным избыточным хранилищем (LRS). LRS означает, что данные имеют три синхронных копии в одном физическом расположении в основном регионе Azure. LRS является наименее дорогостоящим вариантом репликации, но не обеспечивает защиту от сбоя центра обработки данных. Можно определить пользовательские классы хранилища, использующие управляемые диски с отказоустойчивостью на уровне зон (ZRS). Хранилище, избыточное между зонами (ZRS), синхронно реплицирует управляемый диск Azure в трех зонах доступности Azure в выбранном регионе. Каждая зона доступности — это отдельное физическое расположение с независимым питанием, охлаждением и сетью. Диски ZRS обеспечивают по крайней мере 99,99999999999% (12 9) устойчивости в течение заданного года. Управляемый диск ZRS может быть подключен к виртуальной машине в другой зоне доступности. Диски ZRS в настоящее время недоступны для всех регионов Azure. Дополнительные сведения о дисках ZRS см. в разделе "Зонально избыточное хранилище (ZRS) для дисков Azure для обеспечения высокой доступности". Кроме того, чтобы снизить риск потери данных, можно выполнять регулярные резервные копии или моментальные снимки данных хранилища дисков с помощью azure Kubernetes Service Backup или сторонних решений, таких как Velero или Azure Backup, которые могут использовать встроенные технологии моментальных снимков.

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

Совет

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

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

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

Диски SSD уровня "Премиум" версии 2 предлагают рабочие нагрузки , интенсивные операции ввода-вывода в секунду, согласованную задержку на диске подмиллисекунда, а также высокую пропускную способность и пропускную способность. Производительность (емкость, пропускная способность и количество операций ввода-вывода в секунду) дисков SSD (цен. категории "Премиум") версии 2 можно настроить независимо в любое время, что упрощает выполнение большего количества сценариев с точки зрения экономической эффективности при соблюдении требований к производительности. Дополнительные сведения о настройке нового или существующего кластера AKS для использования дисков SSD azure premium версии 2 см. в разделе "Использование дисков SSD уровня "Премиум" azure уровня "Премиум" версии 2 на Служба Azure Kubernetes.

Хранилище дисков (цен. категория "Ультра")

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

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

Если выбрать хранилище дисков категории "Ультра", помните об ограничениях и убедитесь, что размер совместимой виртуальной машины выбран. Хранилище дисков категории "Ультра" доступно с локально избыточной репликацией хранилища (LRS).

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

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

Файлы Azure

Дисковое хранилище не может обеспечить одновременный доступ к дисковому тому, но вы можете использовать Azure Files для подключения общей папки Server Message Block (SMB) версии 3.1.1 или общей папки сетевой файловой системы (NFS) версии 4.1, поддерживаемой Azure Storage. Этот процесс предоставляет подключенное к сети хранилище, аналогичное Amazon EFS. Как и в случае с хранилищем дисков, существует два варианта:

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

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

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

Azure NetApp Files

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 для службы Azure Kubernetes.

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

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

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

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

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

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

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

Azure HPC Cache

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

Сервер NFS

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

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

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

Использование собственных ключей (BYOK - Bring Your Own Key) с дисками Azure

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

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

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

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

  • Диски Azure: детальный контроль номеров SKU и конфигураций хранилища. Они подходят для баз данных уровня 1 и общего назначения.
  • Временные диски: использует локальные ресурсы хранилища на узлах AKS (NVMe или temp SSD). Лучше всего подходит для приложений без необходимости обеспечения устойчивости данных или встроенной поддержки репликации данных. AKS обнаруживает доступное эфемерное хранилище на узлах AKS и получает их для развертывания томов.
  • Azure Elastic SAN: подготовка полностью управляемого ресурса по запросу. Подходит для баз данных общего назначения, служб потоковой передачи и обмена сообщениями, сред CD/CI и других рабочих нагрузок уровня 1/2. Несколько кластеров могут одновременно получить доступ к одной сети SAN, однако постоянные тома могут быть подключены только одним потребителем одновременно.

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

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

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

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

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

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

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

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

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

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

Сторонние решения

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

  • Новичок превращает распределенные системы хранения в автономные службы хранения, автоматив задачи администратора хранилища. Новичок предоставляет свои службы через оператор Kubernetes для каждого поставщика хранилища.
  • GlusterFS — это бесплатная масштабируемая сетевая файловая система с открытым исходным кодом, которая использует общее аппаратное обеспечение вне полки для создания больших распределенных решений хранилища для задач с большим объемом данных и пропускной способности.
  • Ceph предоставляет надежную и масштабируемую унифицированную службу хранилища с объектами, блоками и файловыми интерфейсами из одного кластера, созданного из сырьевых аппаратных компонентов.
  • Хранилище объектов MinIO multicloud позволяет предприятиям создавать инфраструктуру данных, совместимую с AWS S3, в любом облаке, обеспечивая согласованный, переносимый интерфейс для данных и приложений.
  • Portworx — это комплексное решение для хранения и управления данными для проектов Kubernetes и инициатив на основе контейнеров. Portworx предлагает детальное хранилище контейнеров, аварийное восстановление, безопасность данных и многооблачные миграции.
  • Quobyte предоставляет высокопроизводительное хранилище файлов и объектов, которые можно развернуть на любом сервере или облаке для масштабирования производительности, управления большими объемами данных и упрощения администрирования.
  • Ondat обеспечивает согласованный уровень хранения на любой платформе. Базу данных или любую постоянную рабочую нагрузку можно запустить в среде Kubernetes без необходимости управлять уровнем хранения.

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

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

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

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

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

Service ReadWriteOnce ReadOnlyMany ReadWriteMany
Диски Azure X
Файлы Azure X X X
Azure NetApp Files X X X
Сервер NFS X X X
Azure HPC Cache X X X

Динамическая и статическая подготовка

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

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

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

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

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

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

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

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