Варианты хранения для приложений в AKS, включенных Azure Arc

  • Статья

Область применения: AKS в Azure Stack HCI 22H2, AKS в Windows Server

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

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

Образ хранилища архитектуры, показывающий master и узел кластера.

В этой статье описываются основные понятия, обеспечивающие хранение приложений в AKS Arc, в том числе:

  • Тома
  • Постоянные тома
  • Классы хранения
  • Утверждения постоянного тома (PVC)

Тома

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

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

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

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

  • configMap — этот тип тома используется для внедрения в элементы pod пар свойств "ключ-значение", например сведений о конфигурации приложения. Вместо определения сведений о конфигурации приложения в образе контейнера их можно определить как ресурс Kubernetes, который можно легко обновлять и применять к новым экземплярам модулей pod по мере их развертывания. Как и при использовании секрета, сначала создается ConfigMap с помощью API Kubernetes. Затем этот объект ConfigMap можно запросить при определении модуля pod или развертывания. Файлы ConfigMap хранятся в заданном пространстве имен и могут быть доступны только модулям pod в том же пространстве имен.

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

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

Вы можете использовать тома дисков AKS, поддерживаемые VHDX, которые подключены как ReadWriteOnce и доступны для одного узла одновременно. Вы также можете использовать файловые тома AKS на базе общих папок SMB или NFS. Они подключены как ReadWriteMany и доступны для нескольких узлов одновременно.

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

Классы хранения

Чтобы определить различные уровни (и расположение) хранилища, можно создать Класс хранения. StorageClass также определяет reclaimPolicy. Это свойство reclaimPolicy управляет поведением базового ресурса хранилища при удалении модуля pod, а постоянный том может больше не требоваться. Базовый ресурс хранилища можно удалить или сохранить для использования с будущим модулем pod.

В AKS Arc автоматически создается класс хранения по умолчанию , который использует CSV для создания томов с поддержкой VHDX. Политика освобождения гарантирует, что базовый VHDX-файл будет удален при удалении постоянного тома, который его использовал. Класс хранения также настраивает постоянные тома для расширения, поэтому необходимо просто изменить утверждение постоянного тома, указав новый размер.

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

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

PersistentVolumeClaim запрашивает хранилище ReadWriteOnce или ReadWriteMany определенного класса StorageClass и размера. Сервер API Kubernetes может динамически подготавливать базовый ресурс хранилища в AKS Arc, если нет ресурса для выполнения утверждения на основе определенного класса StorageClass. Определение pod включает в себя подключение тома после его присоединения к pod.

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

В следующем примере манифеста YAML показано утверждение постоянного тома, которое использует класс StorageClass по умолчанию и запрашивает диск 5Gi:

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: aks-hci-vhdx 
spec: 
  accessModes: 
  - ReadWriteOnce 
  storageClassName: default 
  resources: 
    requests: 
      storage: 5Gi

При создании определения pod указывается утверждение постоянного тома для запроса требуемого хранилища. Затем вы также укажете volumeMount для приложений чтение и запись данных. В следующем примере манифеста YAML показано, как можно использовать предыдущее утверждение постоянного тома для подключения тома в /mnt/aks-hci:

kind: Pod 
apiVersion: v1 
metadata: 
  name: nginx 
spec: 
  containers: 
    - name: myfrontend 
      image: k8s.gcr.io/nginx 
      volumeMounts: 
      - mountPath: "/mnt/aks-hci" 
        name: volume
  nodeSelector:
      kubernetes.io/os: linux
  volumes: 
    - name: volume 
      persistentVolumeClaim: 
        claimName: aks-hci-vhdx

В следующем примере показано, как подключить том в контейнере Windows и указать букву диска и путь:

volumeMounts: 
        - mountPath: "d:" 
          name: volume 
        - mountPath: "c:\k" 
          name: k-dir

Дальнейшие действия