Рекомендации по управлению операциями для Служба Azure Kubernetes

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

Базовые показатели операций для AKS

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

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

Обратите внимание на следующие факторы:

• Учитывайте ограничения AKS. Используйте несколько экземпляров AKS, если вам нужно выполнить масштабирование для обхода таких ограничений.
• Помните о возможностях логически изолировать рабочие нагрузки в кластере и физически в отдельных кластерах.
• Помните о возможностях управлять потреблением ресурсов отдельных рабочих нагрузок.
• Помните о возможностях передавать Kubernetes данные о работоспособности рабочих нагрузок.
• Учитывайте различные размеры виртуальных машин и влияние использования одного или другого. Более крупные виртуальные машины могут обрабатывать более высокую нагрузку. Виртуальные машины малого размера можно заменить другими, если они недоступны в ходе планового или внепланового обслуживания. Кроме того, следует учитывать пулы узлов и виртуальные машины в масштабируемом наборе, что позволяет виртуальным машинам разных размеров в одном кластере. Более крупные виртуальные машины являются более оптимальными, так как AKS резервирует меньший процент ресурсов, что делает больше ресурсов доступными для рабочих нагрузок.
• Помните о возможностях мониторинга и ведения журнала для AKS. Kubernetes состоит из различных компонентов, а также для мониторинга и ведения журнала следует получить представление о его работоспособности, тенденциях и потенциальных проблемах.
• На основе мониторинга и ведения журнала может быть много событий, создаваемых Kubernetes или приложениями, работающими поверх. Оповещения позволяют отделять исторические записи журнала от тех записей, которые требуют немедленных действий.
• Помните об обновлениях, которые нужно установить. На уровне Kubernetes существуют основные, незначительные и исправления. Клиент должен применить эти обновления, чтобы оставаться поддерживаемыми в соответствии с политикой в upstream Kubernetes. На уровне рабочего узла исправления ядра ОС могут потребовать перезагрузки, которую клиент должен выполнить, и обновить до новых версий ОС. Помимо обновления вручную можно задать канал автоматического обновления для кластера.
• Помните об ограничениях ресурсов кластера и отдельных рабочих нагрузках.
• Помните о различиях между средством горизонтального автомасштабирования и средством автомасштабирования кластера.
• Рассмотрите возможность обеспечения защиты трафика между pod с помощью сетевых политик и подключаемого модуля политик Azure.
• Чтобы устранить неполадки с приложением и службами, работающими в AKS, может потребоваться просмотреть журналы, созданные компонентами плоскости управления. Может потребоваться включить журналы ресурсов для AKS , так как ведение журнала не включено по умолчанию.

Рекомендации

• Изучите сведения об ограничениях AKS:

  • Квоты и региональные ограничения
  • Ограничения Службы Azure Kubernetes

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

• Планируйте и применяйте квоты ресурсов на уровне пространства имен. Если pod не определяют запросы ресурсов и ограничения, отклоните развертывание с помощью политик и т. д. Это не относится к модулям pod kube-system, так как не все модули pod kube-system имеют запросы и ограничения. Наблюдайте за использованием ресурсов и при необходимости изменяйте квоты. Основные функции планировщика

• Добавьте пробы работоспособности в свои pod. Убедитесь, что модули pod содержат livenessProbeпробыreadinessProbe работоспособности и startupProbe AKS.

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

• Используйте решение для мониторинга. Аналитика контейнеров Azure Monitor настроена по умолчанию и предоставляет простой доступ к многим аналитическим сведениям. Вы можете использовать интеграцию Prometheus, если хотите получать детализированные сведения, или использовать Prometheus напрямую. Если вы также хотите запускать приложение мониторинга в AKS, используйте Azure Monitor для мониторинга приложения.

• Используйте оповещения метрик аналитики контейнеров Azure Monitor для предоставления уведомлений, когда требуется прямое действие.

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

• Используйте Помощник по Azure, чтобы получить рекомендации по затратам, безопасности, надежности, эффективности работы и производительности. Кроме того, используйте Microsoft Defender для облака для предотвращения и обнаружения угроз, таких как уязвимости образа.

• Используйте Kubernetes с поддержкой Azure Arc для управления кластерами Kubernetes, отличными от AKS, в Azure с помощью Политика Azure, Defender для облака, GitOps и т. д.

• Используйте запросы и ограничения pod для управления вычислительными ресурсами в кластере AKS. Запросы и ограничения pod сообщают планировщику Kubernetes о том, какие вычислительные ресурсы следует назначать pod.

Непрерывность бизнес-процессов и аварийное восстановление для защиты и восстановления AKS

Ваша организация должна разработать функции уровня платформы Службы Azure Kubernetes, соответствующие ее конкретным требованиям. Эти службы приложений имеют требования, связанные с целевым временем восстановления (RTO) и целевой точкой восстановления (RPO). Существует несколько рекомендаций по обеспечению аварийного восстановления AKS. Первым шагом является определение соглашения об уровне обслуживания (SLA) для вашей инфраструктуры и вашего приложения. Изучите сведения о соглашении об уровне обслуживания для Службы Azure Kubernetes (AKS). Информацию о вычислении времени работы за месяц см. в разделе Сведения о соглашении об уровне обслуживания.

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

Обратите внимание на следующие факторы:

• Кластер AKS должен использовать несколько узлов в пуле узлов, чтобы обеспечить минимальный уровень доступности для приложения.

• Задайте ограничения и запросы объектов pod. Установка этих ограничений позволяет Kubernetes:

  • эффективно предоставлять ресурсы ЦП и памяти объектам pod;
  • добиться повышенной плотности контейнеров на узле.

  Ограничения также позволяют повысить надежность и снизить затраты за счет более эффективного использования оборудования.

• Пригодность AKS для Зон доступности или групп доступности.

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

• Вы должны знать рекомендации по аварийному восстановлению в AKS. После этого определите, можно ли их применять к кластерам AKS, используемым для Azure Dev Spaces.

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

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

• Обновление и обслуживание кластера.

  • Всегда поддерживайте кластер в актуальном состоянии.
  • Не забывайте о процессе выпуска и устаревания.
  • Планирование обновлений и обслуживания.

• Сетевое подключение в случае отработки отказа.

  • Выберите маршрутизатор трафика, способный распределять трафик между зонами или регионами, с учетом своих требований. Эта архитектура развертывает службу Azure Load Balancer, так как она может распределять трафик, отличный от веб-трафика, между зонами.
  • Если вам нужно распределить трафик между регионами, рекомендуется использовать Azure Front Door.

• Плановая и внеплановая отработка отказа.

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

• Поддержка возможностей разработки DevOps для достижения целей уровня обслуживания.

• Определите, требуется ли соглашение об уровне обслуживания с финансовыми гарантиями для конечной точки сервера API Kubernetes.

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

Ниже приведены рекомендации по проектированию:

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

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

• Регулярное обслуживание кластера, например установка своевременных обновлений, является критически важным фактором для обеспечения надежности. Помните о окне поддержки версий Kubernetes в AKS и запланируйте обновления. Кроме того, рекомендуется отслеживать работоспособность объектов pod с помощью проб.

• По возможности удаляйте состояние службы из контейнеров. Вместо этого используйте платформу как услугу (PaaS) Azure, которая поддерживает репликацию в нескольких регионах.

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

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

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

  • Асинхронная репликация на основе инфраструктуры
  • асинхронная репликация на основе приложений;

• Оцените ограничения pod. Выполните тестирование и определите базовые показатели. Начните с одинаковых значений для запросов и ограничений. Затем постепенно корректируйте эти значения, пока не установите порог, способный привести к нестабильной работе кластера. Ограничения pod можно указать в манифестах развертывания.

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

• Задайте бюджеты неработоспособности pod. Этот параметр определяет количество реплик в развертывании, которые могут быть отключены во время обновления или модернизации.

• Применение квот ресурсов для пространств имен службы. Квота ресурса в пространстве имен гарантирует правильность установки запросов и ограничений pod в развертывании.

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

• Сохраните образы контейнера в Реестре контейнеров Azure и настройте георепликацию реестра в каждый регион AKS.

• Используйте соглашение об уровне обслуживания без простоя, чтобы обеспечить финансовое обеспечение, более высокое соглашение об уровне обслуживания для всех кластеров, включаемых в рабочие нагрузки рабочей среды. Соглашение об уровне обслуживания с гарантией времени доступности обеспечивает доступность на уровне 99,95 % для конечной точки сервера Kubernetes API любому кластеру, который использует Зоны доступности, или на уровне 99,9 % для кластеров, которые не используют Зоны доступности. Ваши узлы, пулы узлов и другие ресурсы рассматриваются в соответствии с соглашением об уровне обслуживания. AKS предлагает бесплатный уровень с целью уровня обслуживания (SLO) 99,5% для компонентов уровня управления. Кластеры без включения обслуживания об уровне обслуживания простоя не должны использоваться для рабочих нагрузок.

• Используйте несколько регионов и расположений пиринга для подключения Azure ExpressRoute.

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

• Соединяйте регионы с помощью глобального пиринга между виртуальными сетями. Если кластеры должны взаимодействовать друг с другом, обе виртуальных сети можно соединить с помощью пиринга между виртуальными сетями. Эта технология соединяет виртуальные сети друг с другом, обеспечивая высокую пропускную способность в магистральной сети Майкрософт даже в разных географических регионах.

• Благодаря разделенному протоколу на основе TCP с произвольной передачей данных служба Azure Front Door гарантирует, что конечные пользователи получат быстрое подключение к ближайшей точке подключения Front Door. Другие функции Azure Front Door включают в себя следующее:

  • завершение сеанса TLS;
  • Личный домен
  • Брандмауэр веб-приложения
  • Переопределение URL-адресов
  • Сходство сеансов

  Оцените требования к трафику для приложения, чтобы выбрать оптимальное решение.