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

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

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

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

Рекомендации по рекомендациям

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

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

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

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

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

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

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

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

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

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

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

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

Размер узлов в соответствии с требованиями к хранилищу

Рекомендации по рекомендациям

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

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

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

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

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

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

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

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

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

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

Рекомендации по рекомендациям

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

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

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

Основные концепции динамического создания и использования томов см. в описании утверждений постоянного тома.

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

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

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

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

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

Рекомендации по рекомендациям

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

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

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

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

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