Рекомендации по управлению операциями для Служба Azure Kubernetes
Kubernetes — это относительно новая технология, которая быстро развивается и имеет впечатляющую экосистему. Таким образом, управлять им и защищать их может быть сложно.
Базовые показатели операций для AKS
Вы можете работать над эффективностью операций и успехом клиентов, правильно разработав решение Служба Azure Kubernetes (AKS) с учетом управления и мониторинга.
Рекомендации по проектированию
Примите во внимание следующие факторы.
- Учитывайте ограничения AKS. Используйте несколько экземпляров AKS, если вам нужно выполнить масштабирование для обхода таких ограничений.
- Помните о возможностях логически изолировать рабочие нагрузки в кластере и физически в отдельных кластерах.
- Помните о возможностях управлять потреблением ресурсов отдельных рабочих нагрузок.
- Помните о возможностях передавать Kubernetes данные о работоспособности рабочих нагрузок.
- Помните о различных размерах виртуальных машин и о влиянии использования одной из них. Более крупные виртуальные машины могут обрабатывать более высокую нагрузку. Виртуальные машины малого размера можно заменить другими, если они недоступны в ходе планового или внепланового обслуживания. Кроме того, следует учитывать пулы узлов и виртуальные машины в масштабируемом наборе, что позволяет использовать виртуальные машины разных размеров в одном кластере. Более крупные виртуальные машины являются более оптимальными, так как AKS резервирует меньший процент ресурсов, что делает больше ресурсов доступными для ваших рабочих нагрузок.
- Помните о возможностях мониторинга и ведения журнала для AKS. Kubernetes состоит из различных компонентов, и мониторинг и ведение журнала должны предоставлять представление о работоспособности, тенденциях и потенциальных проблемах.
- Основываясь на мониторинге и ведении журнала, Kubernetes или приложениях, работающих поверх, может создаваться множество событий. Оповещения позволяют отделять исторические записи журнала от тех записей, которые требуют немедленных действий.
- Помните об обновлениях, которые нужно установить. На уровне Kubernetes существуют основные, дополнительные версии и версии исправлений. Клиент должен применить эти обновления, чтобы поддерживать их в соответствии с политикой в вышестоящий Kubernetes. На уровне узла рабочей роли для установки исправлений ядра ОС может потребоваться перезагрузка, которую должен выполнить клиент, и выполнить обновление до новых версий ОС. Помимо обновления вручную можно задать канал автоматического обновления для кластера.
- Учитывайте ограничения ресурсов кластера и отдельные рабочие нагрузки.
- Помните о различиях между средством горизонтального автомасштабирования и средством автомасштабирования кластера.
- Рассмотрите возможность обеспечения защиты трафика между pod с помощью сетевых политик и подключаемого модуля политик Azure.
- Чтобы устранить неполадки с приложением и службами, работающими в AKS, может потребоваться просмотреть журналы, созданные компонентами уровня управления. Может потребоваться включить журналы ресурсов для AKS , так как ведение журнала не включено по умолчанию.
Рекомендации
Изучите сведения об ограничениях AKS:
Используйте логическую изоляцию на уровне пространства имен для разделения приложений, команд, сред и бизнес-подразделений. Многотенантность и изоляция кластеров. Кроме того, пулы узлов могут помочь в узлах с разными спецификациями узлов, а обслуживание, например 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 % доступности конечной точки сервера API Kubernetes для кластеров, использующих Зоны доступности, и 99,9 % доступности для кластеров, которые не используют Зоны доступности. На узлы, пулы узлов и другие ресурсы распространяется соглашение об уровне обслуживания. AKS предлагает бесплатный уровень с целевым уровнем обслуживания (SLO) 99,5 % для компонентов уровня управления. Кластеры без включенного SLA времени доступности не следует использовать для рабочих нагрузок.
Используйте несколько регионов и расположений пиринга для подключения Azure ExpressRoute.
Если возникает сбой, затрагивающий расположение поставщика пиринга или регион Azure, избыточная архитектура гибридной сети помогает обеспечить непрерывное подключение между различными местоположениями.
Соединяйте регионы с помощью глобального пиринга между виртуальными сетями. Если кластеры должны взаимодействовать друг с другом, обе виртуальных сети можно соединить с помощью пиринга между виртуальными сетями. Эта технология соединяет виртуальные сети друг с другом, обеспечивая высокую пропускную способность в магистральной сети Майкрософт, даже в разных географических регионах.
Благодаря разделенному протоколу на основе TCP с произвольной передачей данных служба Azure Front Door гарантирует, что конечные пользователи получат быстрое подключение к ближайшей точке подключения Front Door. Другие функции Azure Front Door включают в себя следующее:
- завершение сеанса TLS;
- Личный домен
- Брандмауэр веб-приложения
- Переопределение URL-адресов
- Сходство сеансов
Оцените требования к трафику для приложения, чтобы выбрать оптимальное решение.