Рекомендации по организации хранения для Службы Azure Kubernetes (AKS)

  • Статья

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

Kubernetes может выполнять рабочие нагрузки без отслеживания состояния и состояния. Рабочие нагрузки с отслеживанием состояния часто требуют решения хранилища для хранения состояния. AKS поддерживает несколько интегрированных вариантов для собственного хранилища, включая управляемые базы данных, диски (или блоки), а также файлы и хранилище BLOB-объектов (или объектов). Каждый из этих вариантов предлагает различные номера SKU, размеры и характеристики производительности. Выбор подходящего варианта требует тщательного рассмотрения.

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

Выберите нужную службу хранилища

Выбор правильных номеров SKU и размеров для начальных развертываний требует некоторых вычислений и, возможно, проверки концепции или тестовой среды. Ниже приведены общие рекомендации, которые помогут вам приступить к работе с хранилищем для AKS:

  • Структурированные данные. Для структурированных данных, которые приложение может хранить в управляемой базе данных, доступной на платформе (например, SQL Azure), рекомендуется использовать управляемую базу данных.

  • Неструктурированные данные. Для неструктурированных данных, таких как фотографии, видео и текстовые документы, используйте хранилище BLOB-объектов. Это можно сделать с помощью больших двоичных объектов, подключенных в виде файлов через сетевую файловую систему (NFS) или доступ к ней в качестве виртуальной файловой системы с помощью BLOBFuse. Кроме того, приложение может напрямую считывать и записывать данные в хранилище BLOB-объектов.

  • Общие данные приложения. Для общих данных приложения, требующих высокой производительности, используйте Azure NetApp Files или уровень "Премиум" Файлы Azure. Для общих данных конфигурации, требующих только ограниченной производительности, используйте стандартный уровень Файлы Azure.

  • Пропускная способность для запросов к приложению и хранилищу. Убедитесь, что узлы имеют достаточную пропускную способность сети для обработки запросов приложений и запросов к хранилищу. служба хранилища трафик передается по сетевому стеку, является ли протокол для передачи блоком сообщений сервера (S МБ) или NFS.

  • Низкая задержка, высокий объем операций ввода-вывода в секунду. Используйте диски для хранилища, если приложению требуется постоянная низкая задержка для приложений обмена сообщениями и операций ввода-вывода в секунду и высокая пропускная способность для запуска собственных баз данных в Kubernetes. Для обеспечения оптимальной производительности рекомендуется использовать SSD Azure premium, SSD Azure уровня "Премиум" версии 2 или служба хранилища диска Azure ценовой категории "Ультра".

Рекомендации по проектированию

Ниже приведены рекомендации по проектированию хранилища для AKS. Рассмотрим, где требуется хранилище в среде AKS, и определите оптимальное решение для каждого требования.

Диски операционной системы (ОС)

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

  • Временные диски для ОС. Для каждой виртуальной машины в Azure требуется диск для своей ОС. Так как узлы Kubernetes являются временными, AKS по умолчанию использует временные диски ОС на поддерживаемых размерах виртуальных машин. Дополнительные сведения о временных дисках ОС см. в разделе "Эфемеральная ОС".

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

  • Изменение размера управляемых дисков. Если выбрать управляемый диск в качестве диска ОС, убедитесь, что он соответствует требованиям операционной системы, системе Kubernetes и рабочей нагрузке. Дополнительные сведения о параметрах и различиях см. в разделе "Типы управляемых дисков Azure".

Данные приложения

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

решения служба хранилища в AKS

Если управляемая база данных не соответствует потребностям приложения, попробуйте использовать другой вариант хранилища, доступный AKS для хранения согласованных данных. К ним относятся решения на основе дисков, временные диски, решения на основе файлов, хранилище BLOB-объектов и другие варианты, которые не рассматриваются в этой статье.

Решения на основе дисков

Диски или блочное хранилище идеально подходят для хранения данных непосредственно на необработанном блокируемом устройстве. Хранилище на основе дисков идеально подходит для хранения данных для баз данных, на которые размещаются кластеры Kubernetes. В Azure управляемые диски — это решение для получения блочного хранилища.

  • Статическое или динамически созданное хранилище дисков. Рассмотрим, следует ли использовать статический диск, созданный за пределами AKS, или если требуется динамически создать хранилище дисков в качестве модуля pod или pod. служба хранилища, создаваемые динамически, также можно удалить динамически. Дополнительные сведения см. в разделе:

  • Избыточность и производительность. Рассмотрим избыточность хранилища и производительность, необходимые рабочей нагрузке. Дополнительные сведения см. в разделе:

  • Общий диск. Определите, нужен ли общий диск. Дополнительные сведения о параметрах см. в статье "Общий доступ к управляемому диску Azure".

  • Размер узла для дисков и пропускной способности. Рассмотрим размер узла Kubernetes. Оно должно быть достаточно большим, чтобы поддерживать как количество дисков, так и агрегатные требования к пропускной способности. Сведения о размерах и характеристиках см. в разделе "Размеры" для виртуальных машин в Azure.

  • Размер диска и требуемая производительность. Рассмотрите, соответствует ли размер управляемого диска требованиям к производительности рабочей нагрузки. Производительность увеличивается по мере увеличения размера диска для ssd уровня "Стандартный", "Стандартный" и SSD уровня "Премиум" версии 1. Дополнительные сведения об управляемых дисках см. в разделе "Типы управляемых дисков Azure".

Эфемерные решения для дисков

Рассмотрите, требуется ли ваше приложение непрекращающееся, временное хранилище или где требуется использовать высокопроизводительные диски на виртуальных машинах, оптимизированных для хранения. Чтобы подключиться к эфемерном тому, можно использовать параметр emptyDir в Kubernetes или драйвер для эфемерного локального тома CSI. Мы рекомендуем emptyDir для временных данных, таких как пространство с нуля. Для хранения в серии виртуальных машин, оптимизированных для хранения, рекомендуется использовать CSI с временным локальным томом. Дополнительные сведения о драйверах CSI см. в статьях о драйверах служба хранилища интерфейса контейнера (CSI) на Служба Azure Kubernetes (AKS).

Решения на основе файлов

Рассмотрите необходимость совместного использования файловой системы модуля pod. Общая файловая система идеально подходит для данных приложения и конфигурации, которые считываются и используются несколькими модулями pod в кластере Kubernetes. Хранилище файлов предоставляет общую файловую систему с помощью NFS или S МБ/Common Internet File System (CIFS). Azure имеет два решения для файлового хранилища: Файлы Azure и Azure NetApp Files.

Файлы Azure

Для Файлы Azure рассмотрим следующие варианты:

  • Статический или динамически созданный файловый ресурс. Рассмотрим, следует ли использовать статическую общую папку, созданную за пределами AKS, или если вы хотите, чтобы AKS динамически создавал общую папку от вашего имени. Дополнительные сведения см. в разделе:

  • Производительность уровня "Стандартный" или "Премиум". Оцените, достаточна ли стандартная производительность или требуется ли производительность уровня "Премиум" из Файлы Azure.

  • S МБ/CIFS или NFS. Чтобы получить доступ к Файлы Azure, оцените, должна ли рабочая нагрузка использовать API для протокола по умолчанию, S МБ/CIFS или если для рабочей нагрузки требуется поддержка NFS.

  • Сетевая модель для доступа. Рассмотрим сетевую модель, которую вы хотите использовать для доступа к Файлы Azure: доступ через прямой общедоступный IP-адрес, конечную точку службы или приватный канал.

Azure NetApp Files

Для Azure NetApp Files рассмотрим следующие варианты:

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

Рассмотрим объем неструктурированных данных, которые нужно хранить приложению. Хранилище BLOB-объектов Azure доступно через HTTP-API или с помощью пакетов SDK. Подключение хранилища BLOB-объектов в виде файловой системы в контейнер или pod идеально подходит для рабочих нагрузок приложений, имеющих большие объемы неструктурированных данных, таких как файлы журнала, изображения, документы, потоковая передача мультимедиа и данные аварийного восстановления.

  • Избыточность данных. Рассмотрим, какой избыточность данных соответствует приложению. Дополнительные сведения см. в статье Репликация службы хранилища Azure. Избыточность данных выбирается на уровне учетной записи хранения.

  • Уровень производительности. Рассмотрим, какой уровень производительности хранилища BLOB-объектов требуется приложению. Дополнительные сведения см. в разделе "Горячий", "холодный" и "архивный" уровней доступа для данных BLOB-объектов.

  • Метод проверки подлинности для доступа. Рассмотрите метод проверки подлинности, который приложение должно использовать для доступа к хранилищу BLOB-объектов: ключ хранилища, SAS или идентификатор Microsoft Entra. Дополнительные сведения см. в статье Авторизация доступа к данным в службе хранилища Azure.

  • API для абстрактного хранилища BLOB-объектов. Рассмотрим, какой API следует использовать. Как правило, приложения, обращаюющиеся к хранилищу BLOB-объектов, используют API в приложении через один из пакетов SDK, которые абстрагируют взаимодействие с хранилищем BLOB-объектов из кластера Kubernetes. Дополнительные сведения о библиотеках для различных языков программирования см. в статье "Введение в хранилище BLOB-объектов Azure".

  • Статическое или динамическое создание хранилища BLOB-объектов. Рассмотрим, следует ли использовать контейнер хранилища статических BLOB-объектов, созданный за пределами AKS, или если вы хотите, чтобы AKS динамически создавал контейнер хранилища BLOB-объектов от вашего имени. Дополнительные сведения см. в разделе:

  • Драйвер для доступа к хранилищу. Рассмотрим, как приложение должно получить доступ к хранилищу BLOB-объектов. Для доступа к нему в качестве файловой системы можно использовать драйвер CSI BLOB-объектов в Kubernetes. Этот драйвер позволяет получить доступ к хранилищу BLOB-объектов через протокол NFSv3 или драйвер fuse.

Другие решения для хранения

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

  • Кэш Azure HPC. HPC Cache ускоряет доступ к данным для задач высокопроизводительных вычислений (HPC). Azure HPC Cache обеспечивает масштабируемость облачных вычислений для имеющегося рабочего процесса благодаря кэшированию файлов в Azure. Дополнительные сведения см. в статье Интеграция Azure HPC Cache с Служба Azure Kubernetes.

  • Azure Data Lake Storage 2 поколения. Data Lake Storage 2-го поколения — это особый тип хранилища BLOB-объектов, оптимизированного для рабочих нагрузок больших данных, таких как Hadoop и Spark. Общие сведения об Azure Data Lake Storage 2-го поколения см. в этой статье.

Рекомендации по проектированию

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

  • Используйте Приватный канал Azure. Для обеспечения безопасности рекомендуется использовать Приватный канал Azure для всех решений хранилища, поддерживающих его. Приватный канал Azure обеспечивает доступ к службам Azure, таким как служба хранилища Azure и База данных SQL, а также размещенные в Azure службы через частную конечную точку в виртуальной сети. Дополнительные сведения см. в статье Что такое Приватный канал Azure.

  • Используйте временные диски для ОС. Для дисков ОС рекомендуется использовать временные диски. Чтобы воспользоваться этой функцией, выберите размер виртуальной машины с соответствующим размером временного диска. Дополнительные сведения см. в разделе "Временные диски ОС" для виртуальных машин Azure.

  • Используйте управляемые базы данных. Для данных приложения рекомендуется использовать управляемые базы данных. Список параметров базы данных см. в разделе "Типы баз данных" в Azure.

В следующих разделах описаны дополнительные рекомендации по дискам Azure, Файлы Azure и хранилищу BLOB-объектов.

Диски Azure

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

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

  • Размер узла для дисков и пропускной способности. Рекомендуется убедиться, что размер узла Kubernetes достаточно велик, чтобы поддерживать количество дисков и объем статистической пропускной способности. Сведения о размерах и характеристиках см. в разделе "Размеры" для виртуальных машин в Azure.

  • Создание моментальных снимков постоянных томов. Рекомендуется создавать моментальные снимки постоянных томов либо для подготовки новых томов, которые предварительно заполнены данными моментального снимка, либо для восстановления существующего тома до предыдущего состояния с помощью возможности моментального снимка драйвера CSI дисков Azure. Дополнительные сведения см. в разделе "Моментальные снимки томов".

  • Избегайте чередование дисков между дисками. Рекомендуется избегать чередовок между несколькими дисками в Kubernetes.

  • Используйте PV/PVC. Мы рекомендуем использовать PV и PVC в Kubernetes для динамического создания дисков, где это необходимо. Дополнительные сведения о постоянном хранилище см. в разделе служба хранилища варианты приложений в Служба Azure Kubernetes (AKS).

Файлы Azure

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

  • Выберите "Премиум". Если производительность важна, рекомендуется использовать уровень "Премиум".

  • Создание выделенных учетных записей хранения. Рекомендуется предоставлять выделенные учетные записи хранения для общих папок.

  • Выберите статические или динамически созданные общие папки. Рекомендуется тщательно рассмотреть вопрос о том, хотите ли AKS создавать общие папки или создавать их статически за пределами Kubernetes. служба хранилища, создаваемые динамически, также можно удалить динамически. Дополнительные сведения о динамическом создании общих папок AKS см. в статье "Динамическое создание и использование постоянного тома с Файлы Azure".

Azure NetApp Files

Для Azure NetApp Files рекомендуется использовать следующие варианты проектирования:

  • Выберите уровень производительности в зависимости от требований приложения. Azure NetApp Files предлагает 3 уровня производительности, которые предлагают различные классы производительности. Дополнительные сведения см. в статье Рекомендации по повышению производительности для Azure NetApp Files.

  • Создайте пулы емкости в том же регионе Azure, что и кластер AKS. Дополнительные сведения см. в статье "Создание пула емкости для Azure NetApp Files".

  • Для пулов емкости используйте тип автосбора качества обслуживания.

  • Планирование сети. Для проектирования сети существуют два варианта:

    1. Если вы используете ту же виртуальную сеть для AKS и Azure NetApp Files, создайте выделенную подсеть для Azure NetApp Files и делегируете подсеть Microsoft.NetApp/Volumes.
    2. При использовании разных виртуальных сетей установите пиринг между ними.

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

Для хранилища BLOB-объектов рекомендуется использовать следующие варианты проектирования:

  • Используйте пакет SDK для взаимодействия с хранилищем. Рекомендуется использовать пакет SDK на уровне приложения для взаимодействия с хранилищем BLOB-объектов.

  • Используйте CSI с NFS для взаимодействия с хранилищем. Если вы не можете использовать пакет SDK на уровне приложения для интерфейса с хранилищем BLOB-объектов, рекомендуется использовать параметр NFS версии 3 в драйвере CSI больших двоичных объектов. Дополнительные сведения см. в статье Об использовании драйвера служба хранилища интерфейса хранилища BLOB-объектов Azure (CSI).

  • Используйте идентификатор Microsoft Entra для доступа. Мы рекомендуем использовать идентификатор Microsoft Entra для авторизации доступа к хранилищу BLOB-объектов. Избегайте использования ключа общей учетной записи хранения. Дополнительные сведения см. в разделе "Авторизация доступа к BLOB-объектам" с помощью идентификатора Microsoft Entra.

  • Настройте уровни. Мы рекомендуем использовать политики управления жизненным циклом для перемещения редко доступ к данным на более холодный уровень доступа. Дополнительные сведения см. в разделе "Горячий", "холодный" и "архивный" уровней доступа для данных BLOB-объектов.

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

Узнайте, как область распределение затрат для развертывания, службы, метки, модуля pod или пространства имен в AKS с помощью Kubecost.

Управление затратами с помощью Kubecost