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

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

Для нескольких модулей pod, возможно, потребуется:

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

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

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

• Тома
• перенос постоянных томов;
• классы хранилищ;
• утверждения постоянного тома.

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

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

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

Примечание.

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

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

Диск Azure

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

• Диски категории "Ультра"
• диски SSD ценовой категории "Премиум";
• Диски SSD ценовой категории "Стандартный"
• диски HDD ценовой категории "Стандартный".

Совет

Для большинства рабочих нагрузок, связанных с производством и разработкой, следует использовать SSD (цен. категория "Премиум").

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

Файлы Azure

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

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

Azure NetApp Files

• Хранилище ценовой категории "Ультра"
• Хранилище класса Premium
• Стандартное хранилище

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

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

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

Типы томов

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

Распространенные дополнительные типы томов в Kubernetes включают в себя следующее:

emptyDir

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

secret

Том secret (секрет) используется для внедрения в pod конфиденциальных данных, например паролей.

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

configMap

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

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

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

перенос постоянных томов;

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

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

• Диск Azure
• Файлы Azure
• Контейнер Azure служба хранилища (предварительная версия).

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

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

Внимание

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

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

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

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

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

Storage class	Description
managed-csi	Использует локально избыточное хранилище на базе SSD ценовой категории "Стандартная" для создания управляемого диска. Политика восстановления гарантирует, что базовый диск Azure удаляется при удалении постоянного тома, который использовал его. Для класса хранения также настраивается расширяемость постоянных томов, поэтому для изменения размера достаточно лишь указать новый размер в утверждении постоянного тома.
managed-csi-premium	Использует локально избыточное хранилище ценовой категории "Премиум" для создания управляемого диска. Политика восстановления снова гарантирует, что базовый диск Azure удаляется при удалении постоянного тома, который использовал его. Аналогичным образом, этот класс хранения позволяет расширять постоянные тома.
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 удаляется при удалении постоянного тома, который использовал его.

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

Внимание

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

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

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

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 согласовывает классы хранения по умолчанию и перезаписывает любые изменения, внесенные в эти классы хранения.

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

утверждения постоянного тома.

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

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

Том PersistentVolume привязывается к утверждению PersistentVolumeClaim после назначения элементу pod запрашиваемого доступного ресурса хранилища. Постоянные тома сопоставляются с утверждениями один к одному.

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

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

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

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

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

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 служба хранилища Рекомендации.

Чтобы узнать, как использовать драйверы CSI, ознакомьтесь со следующими руководствами:

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

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

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