Поделиться через

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

  • Статья

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

Общие сведения о системе управления

Управление начинается с начальной системы управления, которую часто называют MVP управления. Эта система развертывает основные продукты Azure, необходимые для предоставления управления в рамках облачной среды.

Начальная система управления сосредоточена на следующих аспектах управления:

  • Базовая гибридная сеть и возможность подключения.
  • Управление доступом на основе ролей (RBAC) Azure для управления удостоверениями и доступом.
  • Стандарты именования и маркировки для единообразного определения ресурсов.
  • Организация ресурсов с помощью групп ресурсов, подписок и групп управления.
  • Используйте Политика Azure для применения политик управления.

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

Расширение дисциплин системы управления

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

Управление кластерами Kubernetes можно рассматривать с пяти разных перспектив.

Управление ресурсами Azure

Первой является перспектива ресурсов Azure. Убедитесь, что все кластеры соответствуют требованиям вашей организации. Сюда входят такие понятия, как топология сети, частный кластер, роли RBAC Azure для команд SRE, параметры диагностики, доступность регионов, рекомендации по пулу узлов, управление Реестром контейнеров Azure, параметры Azure Load Balancer, надстройки AKS, параметры диагностики и т. п. Такое управление обеспечивает согласованность "дизайна" и "топологии" кластеров в организациях. Это также должно охватывать начальную загрузку после развертывания кластера, например, какие агенты безопасности нужно установить и как они должны быть настроены.

Кластерами Snowflake трудно управлять в любой центральной емкости. Сократите число несоответствий между кластерами, чтобы политики могли применяться единообразно, а аномальные кластеры обнаруживались и не использовались. Сюда также могут входить технологии, используемые для развертывания кластеров, например, ARM, Bicep или Terraform.

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

Управление рабочими нагрузками Kubernetes

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

Рассмотрите возможность стандартизации общих средств и шаблонов, если это применимо. Составьте рекомендации по таким технологиям, как Helm, сетка служб, контроллеры объекта ingress, операторы GitOps, постоянные тома и т. д. Кроме того, здесь можно управлять использованием управляемого удостоверения объекта pod и получением секретов из Key Vault.

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

Политика Azure для AKS, применяемая на уровне кластера, может помочь с выполнением лишь некоторых из этих задач.

Роли операторов кластера (DevOps, SRE)

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

Кластер на рабочую нагрузку или несколько рабочих нагрузок на кластер

Четвертая перспектива — это управление при мультитенатности. То есть должны ли кластеры содержать «схожие» приложения, принадлежащие по определению одной команде рабочей нагрузки, и представлять один набор связанных компонентов рабочей нагрузки. Или кластеры должны быть мультитенатными по своей природе, имеющими несколько разнородных рабочих нагрузок и владельцев рабочей нагрузки, а их выполнение и управление ими в организации должно осуществляться аналогично предложению управляемой службы. Стратегия управления в значительной степени отличается для каждого из случаев, и поэтому следует контролировать применение выбранной стратегии. Если требуется поддержка обеих моделей, убедитесь, что план управления четко определяет, какие политики применяются для конкретных типов кластеров.

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

Меры по обеспечению актуального состояния

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

Базовые средства безопасности

В базовую конфигурацию безопасности можно добавить следующие рекомендации, касающиеся безопасности кластеров AKS:

Идентификация

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

Следующий шаг: управление решениями современных платформ приложений

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