Управление кластерами современных платформ приложений

Статья
07/11/2023

Cloud Adoption Framework предоставляет основную методику для определения процессов управления операциями для любого облака. Эти рекомендации помогают определить базовые показатели управления операциями и другие специализированные уровни операций. Это руководство может быть применено для организаций, в которых используется сочетание подходов "Инфраструктура как услуга" (IaaS), "Платформа как услуга" (PaaS) и контейнерных рабочих нагрузок. В этой статье описано, что необходимо интегрировать с существующими операциями для подготовки к управлению контейнерами. В ней также описываются преимущества интеграции Службы Azure Kubernetes (AKS) в стратегию управления контейнерами.

Адаптация бизнеса в соответствии с потребностями управления операциями

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

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

Будет ли вы управлять несколькими технологическими решениями, такими как контейнеры, IaaS и PaaS на облачной платформе?
Будут ли централизованные команды поддерживать работу контейнера или платформы AKS и управление ими? Будут ли эти обязанности переданы отдельной команде по рабочим нагрузкам?
Будут ли централизованные команды поддерживать выполнение рабочих нагрузок в каждом контейнере или объекте pod и управление ими? Будут ли эти обязанности переданы отдельной команде по рабочим нагрузкам?
Используете ли вы контейнеры для критически важных рабочих нагрузок?
Используете ли вы контейнеры только для менее важных или служебных рабочих нагрузок, чтобы снизить затраты?
Насколько важна производительность и надежность индивидуальных рабочих нагрузок?
Являются ли приложения в контейнерах приложениями без сохранения состояния? Нужно ли сохранять состояние для защиты и восстановления рабочих нагрузок в контейнерах?

Ответы на эти вопросы помогут вам понять, как лучше всего интегрировать контейнеры и AKS в стратегию управления операциями.

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

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

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

Базовые показатели управления операциями

Базовый план операций, описанный в приведенных выше статьях, не обеспечивает поддержку для контейнеров или платформы AKS. Тем не менее, он предоставляет инструментальную основу, которая может быть расширена для поддержки контейнеров. Это такие инструменты как Azure Monitor, Azure Backup и др.

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

Операции платформы

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

Инвентаризация и визуальный контроль

Мониторинг контейнеров и кластеров AKS использует инструменты, панели мониторинга и оповещения, входящие в базовый план операций. Однако может потребоваться дополнительная настройка для получения данных из контейнеров в инструменты для мониторинга операций, например, в Azure Monitor для контейнеров. Ознакомьтесь с обзором Azure Monitor для контейнеров, чтобы собрать данные, необходимые для добавления контейнеров и операций платформы AKS в базовый план операций.

После настройки Azure Monitor для сбора данных в контейнерах можно отслеживать следующие области в рамках процессов централизованного управления:

Определите кластеры, работающие в различных регионах, в идеальном случае связанные с записью в дереве служб, и определите ключевые факторы в этих кластерах.
- Определите топологии пула узлов кластера, сети и хранилища для этих кластеров.
- Определите иерархическое представление версии AKS и версии образа узла.
Определите использование ресурсов узла кластера (процессы, память и хранилище).
Определите контейнеры, выполняющиеся на узлах, и их вклад в использование узлов.
Определите поведение кластеров при средней и максимальной нагрузке. Эта информация может помочь определить потребности в емкости, а также максимальную нагрузку, которую может выдержать кластер.
Настройте оповещения для упреждающего уведомления или записи, если загрузка процессора и памяти на узлах или контейнерах превышает пороговые значения или если в кластере происходит изменение состояния работоспособности на этапе сворачивания работоспособности инфраструктуры или узлов.
Используйте запросы для создания общего набора оповещений, панелей мониторинга и выполнения подробного анализа.

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

Просмотреть данные об использовании ресурсов рабочих нагрузок на узле, не относящихся к стандартным процессам, поддерживающим pod.
Выполните интеграцию с Prometheus для просмотра метрик приложения.
Отслеживайте рабочие нагрузки контейнеров, развернутые в локальной среде подсистемы AKS и в подсистеме AKS в Azure Stack.
Мониторинг рабочих нагрузок контейнера , развернутых в Azure Red Hat OpenShift.
Мониторинг рабочих нагрузок контейнера , развернутых в Kubernetes с поддержкой Azure Arc (предварительная версия).

Соответствие операций требованиям

Установка исправлений, настройка и определение размера происходят на нескольких различных уровнях в контейнерной среде. Операторы могут находиться в нескольких различных командах, в зависимости от выбранного вами подхода к операциям. Чтобы обеспечить соответствие операций требованиям, оператор должен отслеживать потребление, изменять размер ресурсов, чтобы найти баланс между производительностью и затратами, а также устанавливать исправления в базовых системах для снижения рисков и для исключения отклонений конфигурации. Центральные ИТ-организации обычно выполняют эти задачи в рамках базового плана операций для решений IaaS и PaaS.

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

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

Для обоих типов кластеров следуйте рекомендациям по обновлению, образам узлов и обновлениям ОС узла, приведенным ниже:

Защита и восстановление

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

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

Операции рабочих нагрузок

В разделе об операциях платформы выше раскрываются общие вопросы, связанные с управлением кластерами AKS. Являются ли кластеры Kubernetes технологической платформой для централизованного управления? Или они являются инструментом рабочей нагрузки, которым должны управлять команды, владеющие каждой рабочей нагрузкой? Ответ на этот вопрос будет разным для различных организаций. Большинство организаций сходятся на том, что контейнеры и AKS обеспечивают большую гибкость в работе с каждой конкретной рабочей нагрузкой для команд по выполнению рабочих нагрузок и предоставляют определенные функции для этих рабочих нагрузок, используя которые в архитектуре рабочих нагрузок владельцы и потребители рабочих нагрузок смогут получить преимущества.

Операции рабочей нагрузки могут создаваться на основе существующих базовых планов операций и операций, зависящих от платформы. Вы также можете безопасно управлять кластером AKS, используя полностью децентрализованные операции рабочих нагрузок. В любом случае, если вы хотите, чтобы операции были сосредоточены на конкретных результатах конкретной рабочей нагрузки, можно использовать Azure Well-Architected Framework и Microsoft Azure Well-Architected Review, чтобы точно определить типы операционных процессов и инструменты для рабочей нагрузки.

Следующий шаг: следующая итерация миграции

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