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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к размеру и рекомендации для временных дисков ОС доступны в документации по виртуальным машинам 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. Вы можете вручную создавать тома данных для назначения подам напрямую или позволить Kubernetes автоматически создавать их. Тома данных могут использовать: Azure Disk, Azure Files, Azure NetApp Files или Azure Blobs.

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

Диск Azure

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

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

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

Файлы Azure

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

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

Файлы Azure NetApp

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

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

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

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

Типы томов

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

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

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

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

секрет

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

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

configMap

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако важно отметить, что хранилище с избыточностью между зонами (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

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

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

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

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

После назначения доступного ресурса хранилища пакету 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
...

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

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

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

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

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

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

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

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