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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Azure SQL
• База данных Azure для MySQL
• База данных Azure для PostgreSQL
• Azure Cosmos DB

Решения для хранения в AKS

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

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

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

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

  • Создание статического тома с дисками Azure
  • Динамическое создание и использование постоянного тома с дисками Azure

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

  • Параметры избыточности для управляемых дисков
  • Тип производительности и размер диска Azure

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

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

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

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

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

Хранилище контейнеров Azure

Хранилище контейнеров Azure — это облачная служба, предназначенная для управления томами, их развертывания и оркестрации. Эта служба изначально была создана для контейнеров. Если вы планируете использовать блочное хранилище с режимом ReadWriteOnce, используя диски Azure, временный диск или Azure Elastic SAN, хранилище контейнеров Azure предлагает преимущества прямого использования драйверов CSI:

• Повышение производительности цен. Совместное использование одного диска на нескольких виртуальных компьютерах для снижения избыточной подготовки и снижения затрат.
• Увеличение масштаба PV: поддерживает до 75 PV на узел, превосходя лимит в 64 PV с использованием драйверов CSI.
• Локальное NVMe с репликацией: обеспечивает субмиллисекундную задержку и устойчивость для эфемерных дисков, идеально подходит для рабочих нагрузок с встроенной репликацией, таких как "Cassandra".
• Быстрая подготовка и масштабирование: Пакетные операции ускоряют процесс предоставления и масштабирования томов по сравнению с последовательными операциями драйверов CSI.

Дополнительные сведения см. в статье "Что такое хранилище контейнеров Azure"?

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

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

Файлы Azure

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

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

  • Вручную создать и использовать том с общим хранилищем Azure Files
  • Динамическое создание и использование постоянного тома с файлами Azure

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

• SMB/CIFS или NFS. Для доступа к файлам Azure оцените, должна ли рабочая нагрузка использовать API для протокола по умолчанию, SMB/CIFS или если для рабочей нагрузки требуется поддержка NFS.

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

Файлы Azure NetApp

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

• Статический или динамически созданный общий ресурс Azure NetApp Files. Рекомендуется использовать статическую общую папку Azure NetApp Files, созданную за пределами AKS, или общую папку, которую AKS создает динамически через Astra Control. Дополнительные сведения можно найти здесь

  • Настройка томов Azure NetApp Files статическим образом
  • Динамическое предоставление томов Azure NetApp Files

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

• Планирование сети. Ознакомьтесь с рекомендациями по сети для Azure NetApp Files. Дополнительные сведения см. в статье Рекомендации по планированию сети для Azure NetApp Files.

Хранилище данных типа BLOB

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

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

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

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

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

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

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

• Драйвер для доступа к хранилищу. Рассмотрим, как приложение должно получить доступ к хранилищу 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 Generation 2.

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

В этом разделе приведены рекомендации, действующие для клиентов Azure.

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

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

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

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

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

В следующих разделах содержатся рекомендации по использованию хранилища контейнеров Azure с AKS.

Требования к хранилищу контейнеров Azure

• Предварительные требования к кластеру AKS: развертывание кластера AKS с как минимум тремя виртуальными машинами в пуле узлов, каждая с минимум четырьмя виртуальными ЦП.
• Ограничения режима доступа: хранилище контейнеров Azure поддерживает только режим доступа ReadWriteOnce. Для рабочих нагрузок, требующих доступа ReadWriteMany, используйте вместо этого файлы Azure. Дополнительные сведения о режимах доступа см. в документации по Kubernetes.

Выбор правильного типа хранилища контейнеров Azure

• Диски Azure. Используйте для баз данных уровня 1 и общего назначения, таких как MySQL, MongoDB и PostgreSQL. При использовании UltraSSD_LRS или PremiumV2_LRS дисков укажите параметры производительности (операции ввода-вывода в секунду и пропускную способность) непосредственно в определении пула носителей с параметрами IOPSReadWrite и MBpsReadWrite. Этот подход гарантирует, что хранилище контейнеров Azure подготавливает оптимальные ресурсы диска для ваших потребностей в производительности.

• Диски Azure Ephemeral: лучше всего подходит для приложений, требующих низкой задержки (субмиллисекунда) без требований к устойчивости данных или встроенной репликации данных на уровне приложения (например, Cassandra). Данные на временных дисках не сохраняются при перезагрузке виртуальной машины. Хотя хранилище контейнеров Azure с NVMe поддерживает репликацию томов для обеспечения устойчивости к сбоям с одним узлом, данные теряются при одновременной перезагрузке всех реплик. Тщательно оцените этот риск для конкретной рабочей нагрузки. NVMe доступен на виртуальных машинах серии L, оптимизированных для хранения данных.

Настройка устойчивости хранилища контейнеров Azure

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

Диски Azure

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

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

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

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

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

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

Файлы Azure

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

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

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

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

Файлы Azure NetApp

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

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

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

• Для пулов емкости используйте тип Auto QoS.

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

  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-объектов. Дополнительные сведения см. в статье Об использовании драйвера CSI для хранилища BLOB-объектов Azure.

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

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

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

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