Возможности хранения данных в Службе 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 класса Premium.

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

Файлы Azure

Используйте Файлы Azure для подключения общей папки МБ 3.1.1 или сетевой файловой системы (NFS) версии 4.1. Файлы 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.

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

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

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

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

Внимание

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

В следующем примере манифеста YAML показано утверждение постоянного тома, которое использует класс хранилища управляемого класса 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-файла манифеста показано, как предыдущее утверждение постоянного тома может использоваться для подключения тома в 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