Хранилище контейнеров Windows с помощью службы Azure Kubernetes
В предыдущем уроке мы узнали, как Kubernetes управляет приложениями на основе контейнеров и их связанными компонентами хранения. Мы также узнали об архитектуре кластера Kubernetes, состоящей из уровня управления для основных служб и узлов для ресурсов приложений.
Служба Azure Kubernetes (AKS) упрощает развертывание управляемого кластера Kubernetes в Azure путем разгрузки операционных расходов в Azure. Как хостинговая служба Kubernetes, Azure выполняет критически важные задачи, такие как мониторинг работоспособности и обслуживание.
При создании кластера AKS , плоскость управленияавтоматически создается и настраивается. Эта плоскость управления предоставляется без затрат как управляемый ресурс Azure, абстрагированный от пользователя. Вы оплачиваете только узлы, подключенные к кластеру AKS, и управляете ими.
На следующей схеме показано, как AKS управляет плоскостью управления, которая предоставляет основные службы Kubernetes и оркестрацию рабочих нагрузок приложений, в то время как вы управляете узлами, содержащими рабочие нагрузки приложения.
Кластер AKS
При развертывании кластера AKS укажите количество и размер узлов, а AKS развертывает и настраивает плоскость управления и узлы Kubernetes.
На следующей схеме показана архитектура кластера AKS.
Узлы AKS выполняются на виртуальных машинах Azure. По умолчанию Azure автоматически реплицирует диск операционной системы (диск ОС) для виртуальной машины (виртуальной машины) в хранилище Azure, чтобы избежать потери данных при перемещении виртуальной машины на другой узел. Однако, как мы узнали ранее, контейнеры не предназначены для постоянного сохранения локального состояния. Таким образом, это поведение обладает ограниченной полезностью, а также такими недостатками, как медленная подготовка узлов и более высокая задержка чтения и записи.
AKS, напротив, использует временные диски ОС . Эти диски хранятся только на хост-компьютере, как временный диск. Благодаря этой конфигурации вы получаете более низкую задержку чтения и записи вместе с более быстрым масштабированием узлов и обновлениями кластера.
Хранение томов в AKS
В AKS традиционные тома создаются как ресурсы Kubernetes, поддерживаемые службой хранилища Azure. Вы можете вручную создавать тома данных для назначения их непосредственно Kubernetes-подам или позволить Kubernetes автоматически создавать их. Чтобы связать эти тома со службой хранилища Azure, AKS использует CSI (интерфейс хранилища контейнеров).
CSI — это стандарт для предоставления различных блочных и файловых систем хранения контейнеризированным рабочим нагрузкам в Kubernetes.
При использовании CSI служба Azure Kubernetes (AKS) может разрабатывать, развертывать и итерировать подключаемые модули для внедрения новых или совершенствования существующих систем хранения в Kubernetes без необходимости изменять основной код Kubernetes и ждать его циклов выпуска.
Поддержка драйвера хранилища CSI в AKS позволяет использовать его нативно:
- Azure Disks можно использовать для создания ресурса Kubernetes DataDisk. Диски могут использовать хранилище Azure уровня "Премиум", поддерживаемое высокопроизводительными ssd или хранилищем Azure уровня "Стандартный", поддерживаемым обычными жесткими дисками (жесткими дисками) или стандартными SSD. Для большинства рабочих нагрузок и рабочих нагрузок разработки используйте хранилище класса Premium. Диски Azure подключены как ReadWriteOnce и доступны только одному узлу в AKS. Для томов хранилища, доступ к которым можно получить одновременно несколькими узлами, используйте файлы Azure.
- Файлы Azure можно использовать для подключения общего ресурса SMB (блок сообщений сервера) 3.0/3.1, поддерживаемого учетной записью хранения Azure, к модулям pod. С помощью Azure Files можно совместно использовать данные между несколькими узлами и подами. Файлы Azure могут использовать стандартное хранилище Azure, поддерживаемое обычными жесткими дисками (HDD), или премиум-хранилище Azure, поддерживаемое высокопроизводительными твердотельными накопителями (SSD).
- Хранилище BLOB Azure можно использовать для монтирования хранилища BLOB (или объектного хранилища) в виде файловой системы в контейнер или pod. Использование хранилища BLOB-объектов позволяет кластеру поддерживать приложения, работающие с большими неструктурированными наборами данных, такими как данные файла журнала, изображения или документы, HPC и другие. Кроме того, при приеме данных в хранилище Azure Data Lake можно напрямую подключить и использовать его в AKS без настройки другой промежуточной файловой системы.
Начиная с Kubernetes версии 1.21 AKS использует только драйверы CSI по умолчанию, а миграция CSI включена. Хотя существующие постоянные тома в дереве продолжают функционировать, начиная с версии 1.26 AKS больше не будет поддерживать тома, созданные с помощью драйвера в дереве и хранилища, подготовленного для файлов и дисков.
Постоянные тома
Постоянный том (PV) — это ресурс хранилища, созданный и управляемый API Kubernetes, который может существовать за пределами времени существования отдельного модуля pod. В AKS можно использовать диск Azure или файлы Azure для предоставления PersistentVolume. Выбор дисков или файлов для тома часто определяется необходимостью параллельного доступа к данным или требуемому уровню производительности.
Администратор кластера может статически создать PersistentVolume, или же том создается динамически сервером API Kubernetes. Если pod запланирован и запрашивает недоступное хранилище, Kubernetes может создать диск или файловое хранилище Azure и подключить его к pod. Динамическая подготовка использует StorageClass для определения того, какой тип хранилища Azure нужно создать.
Классы хранения в Azure Kubernetes Service
Чтобы определить различные уровни хранилища, такие как "Премиум" и "Стандартный", можно создать класс storageClass. StorageClass также определяет reclaimPolicy. При удалении постоянного тома reclaimPolicy управляет поведением базового ресурса службы хранилища Azure. Базовый ресурс хранилища можно удалить или сохранить для использования с будущим модулем pod.
Для кластеров, использующих драйверы CSI, AKS создал следующие дополнительные StorageClasses:
| Разрешение | Причина |
|---|---|
| managed-csi | Использует локально избыточное хранилище Azure StandardSSD (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. Политика восстановления гарантирует, что контейнер хранилища Azure Blob удаляется при удалении постоянного тома, который его использовал. |
| azureblob-fuse-Premium | Используется Azure Premium Storage для создания контейнера Blob-хранилища Azure и подключения с помощью BlobFuse. Политика восстановления ресурсов обеспечивает удаление базового контейнера хранилища BLOB-объектов Azure при удалении связанного с ним постоянного тома. |
Если для постоянного тома не указан класс StorageClass, используется класс storageClass по умолчанию. Необходимо убедиться, что тома используют соответствующее хранилище, необходимое при запросе постоянных томов. Класс по умолчанию будет совпадать с managed-csi.
Запросы на постоянные тома
PersistentVolumeClaim запрашивает хранилище определенного StorageClass, режима доступа и размера. Сервер API Kubernetes может динамически подготавливать базовый ресурс хранилища Azure, если существующий ресурс не может выполнить утверждение на основе определенного StorageClass.
Определение pod включает подключение тома после того, как он был подключен к pod.
На следующей схеме показано, как работает ПВХ в кластере AKS:
