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

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

Эта статья содержит рекомендации по выбору хранилища для операторов кластера. В этой статье рассматриваются следующие вопросы:

Выбор подходящего типа хранилища

Рекомендации по лучшим практикам

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

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

• Нуждаются ли ваши приложения в хранилище, которое подключается к отдельным pod?
• Нужно ли вашим приложениям хранилище, которое используется несколькими группами pod совместно?
• Достаточно ли доступа к данным только для чтения?
• Предполагается ли запись больших объемов структурированных данных?

В следующей таблице описаны доступные типы хранилищ и их возможности.

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

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

• Диски уровня "Премиум"
  • Работают на высокопроизводительных твердотельных накопителях (SSD).
  • Рекомендуется для всех производственных задач.
• Стандартные диски
  • Работают на обычных вращающихся дисках (HDD).
  • Подходят для архивирования или нечастого доступа к данным.

Хотя уровень хранилища по умолчанию для драйвера CSI диска Azure — SSD уровня "Премиум", пользовательский класс storageClass может использовать SSD уровня "Премиум", "Стандартный" или "Стандартный HDD".

Чтобы выбрать правильный уровень хранилища, важно понимать требования к производительности приложения и шаблоны доступа. Дополнительные сведения о размерах управляемых дисков и уровнях производительности см. в обзоре Azure Управляемые диски.

Создание и использование классов хранения для определения требований приложения

Тип используемого хранилища определяется в классах хранения Kubernetes. Затем класс хранения указывается в спецификации pod или развертывания. Взаимодействие определений классов хранения используется для создания подходящего хранилища и его подключения к pod'ам.

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

Настройте размер узлов в соответствии с потребностями в хранилище.

Рекомендации по лучшим практикам

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

Узлы AKS работают на виртуальных машинах Azure различные типов и размеров. Каждый размер виртуальной машины обеспечивает:

• разный объем базовых ресурсов, например ЦП и памяти;
• максимальное количество подключаемых дисков.

Производительность хранилища также варьируется в зависимости от размеров виртуальных машин в отношении максимального числа операций ввода-вывода в секунду (IOPS) как для локальных, так и для подключенных дисков.

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

Например, хотя для виртуальных машин размеров Standard_B2ms и Standard_DS2_v2 предусмотрен аналогичный объем ресурсов ЦП и памяти, у них разная потенциальная производительность хранилища:

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

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

См. дополнительные сведения о размерах виртуальных машин Linux в Azure.

Рассмотрим временные диски данных NVMe для максимальной производительности

Рекомендации по лучшим практикам

Рассматривайте временные NVMe диски данных, когда требуется наивысшая пропускная способность хранилища и IOPS, и ваша рабочая нагрузка может терпеть временный характер локального хранения узла. Временные NVMe-диски данных обеспечивают низкую задержку и подключенное к узлу хранилище с максимально доступной в Azure пропускной способностью и производительностью IOPS. Диски NVMe доступны на виртуальных машинах серии L, E и GPU с расширением поддержки новых семейств виртуальных машин Azure версии 6 и v7, таких как серии D, серии F и серии H.

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

Ниже приведены распространенные сценарии, которые используют временные диски данных NVMe:

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

Так как данные NVMe привязаны к экземпляру ноды, планируйте бюджеты сбоев подов и убедитесь, что приложение может быстро перестроиться из устойчивого хранилища или репликации. Данные, размещенные на этих дисках, теряются всякий раз, когда узел деаллоцирован, реинсталирован или выходит из строя.

Дополнительные рекомендации по временным дискам данных NVMe см. в разделе Лучшие практики для эфемерных дисков данных NVMe в службе Azure Kubernetes Service (AKS). Чтобы предоставить емкость NVMe модулям pod, используйте хранилище контейнеров Azure, которое может управлять и создавать временные или постоянные тома, поддерживаемые локальными дисками NVMe. Рекомендации по реализации см. в статье "Использование хранилища контейнеров Azure с AKS".

Динамическая подготовка томов

Рекомендации по лучшим практикам

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

Для подключения хранилища к группам pod используйте постоянные тома. Устойчивые тома можно создавать вручную или динамически. Создание постоянных томов вручную повышает расходы на управление и ограничивает возможности масштабирования. Динамическая подготовка постоянных томов упрощает управление хранилищем и дает возможность вашим приложениям расти и масштабироваться по мере необходимости.

Запрос постоянного тома позволяет динамически создавать хранилища по мере необходимости. Базовые диски Azure создаются по запросу от подов. В определении pod'а запросите создание тома и его подключение к указанному пути монтирования.

Для получения сведений о том, как динамически создавать и использовать тома, см. запросы на постоянные тома.

Чтобы увидеть в действии эти тома, узнайте, как динамически создавать и использовать постоянный том с дисками Azure или Azure Files.

В рамках определений класса хранения установите соответствующую политику освобождения (reclaimPolicy). Эта политика "reclaimPolicy" управляет поведением базового ресурса хранилища Azure, когда удаляется pod. Базовый ресурс хранилища можно удалить или оставить для использования pod в будущем. В политике reclaimPolicy можно выбрать режим retain или delete.

Оцените потребности своего сценария применения и регулярно проводите проверки сохраняемого объема хранилища, чтобы снизить затраты на неиспользуемое хранилище.

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

Защита и резервное копирование данных

Рекомендации по лучшим практикам

Создавайте резервные копии данных, используя соответствующий инструмент в зависимости от типа хранилища, например Velero или Azure Backup. Проверяйте целостность и безопасность этих резервных копий.

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

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

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

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