Проектирование и эксплуатация кластеров

В этой статье рассматривается конфигурация кластера и структура сети. Узнайте, как обеспечить масштабируемость в будущем, автоматизировав подготовку инфраструктуры. Подготовка — это процесс настройки желаемой ИТ-инфраструктуры. Автоматическая подготовка инфраструктуры поддерживает удаленную установку и настраивает виртуальные среды. Она также помогает поддерживать высокий уровень доступности благодаря планированию непрерывности бизнес-процессов и аварийного восстановления.

Планирование, обучение и подтверждение

Следующий контрольный список и ресурсы Kubernetes помогут спланировать структуру кластера. В конце этого раздела вы сможете ответить на следующие вопросы:

  • Определили ли вы требования к проектированию сети для кластера?
  • У вас есть службы, предъявляющие различные требования? Сколько пулов узлов вы собираетесь использовать?

Контрольный список:

  • определите критерии проектирования сети. Ознакомьтесь с критериями проектирования сетевого кластера, сравните модели сети и выберите подключаемый модуль Kubernetes Network, соответствующий вашим потребностям. Для сетей с сетевыми интерфейсами контейнеров Azure (CNI) оцените количество IP-адресов, необходимое для нескольких модулей pod в каждом узле (по умолчанию 30) и количества узлов. Добавьте один узел, необходимый во время обновления. Если служб слишком много, при выборе служб подсистемы балансировки нагрузки можно воспользоваться контроллером объекта ingress, для уменьшения числа видимых конечных точек. Для Azure CNI служба CIDR должна быть уникальной в пределах виртуальной сети и всех подключенных виртуальных сетей, чтобы обеспечить соответствующую маршрутизацию.

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

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

  • Определите требования к доступности. Как минимум два модуля, лежащие в основе службы Azure Kubernetes, обеспечивают высокую доступность приложения при сбоях или перезапусках модуля pod. Используйте три или более модулей pod для управления нагрузкой во время сбоев и перезапуска модулей pod. В конфигурации кластера требуется как минимум два узла в группе доступности или масштабируемом наборе виртуальных машин для удовлетворения соглашения об уровне обслуживания 99,95%. Используйте не менее трех модулей pod, чтобы обеспечить планирование модулей pod во время сбоев и перезагрузки узла.

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

Переход к рабочей среде и применение рекомендаций по инфраструктуре

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

  • Сможете ли вы уверенно повторно развернуть инфраструктуру кластера?
  • Применялись ли квоты ресурсов?

Контрольный список:

  • Автоматизируйте подготовку кластера. При использовании решения инфраструктуры, управляемой как кодом, можно автоматизировать подготовку инфраструктуры, чтобы обеспечить повышенную устойчивость во время аварийных ситуаций и повысить гибкость при необходимости быстрого повторного развертывания инфраструктуры. Для получения дополнительной информации см. раздел Создание кластера Kubernetes с помощью службы Azure Kubernetes и Terraform.

  • Планирование доступности с помощью бюджетов неработоспособности pod. Чтобы поддерживать доступность приложений, определите бюджеты неработоспособности модуля pod (PDB), обеспечив доступность минимального количества модулей pod в кластере в случае сбоев оборудования или обновлений кластеров. Для получения дополнительной информации см. раздел Планирование доступности с помощью бюджетов неработоспособности pod.

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

Оптимизация и масштабирование

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

  • Есть ли у вас план по обеспечению непрерывности бизнес-процессов и аварийного восстановления?
  • Можно ли масштабировать кластер в соответствии с потребностями приложений?
  • Можете ли вы отслеживать работоспособность кластера и приложения и получать оповещения?

Контрольный список: