Архитектура микрослужб в Службе Azure Kubernetes

Microsoft Entra ID
Реестр контейнеров Azure
Служба Azure Kubernetes (AKS)
Azure Load Balancer
Azure Pipelines
Azure Monitor

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

GitHub logo Эталонная реализация этой архитектуры доступна на сайте GitHub.

Архитектура

Diagram that shows the AKS reference architecture.

Скачайте файл Visio для этой архитектуры.

Если вы хотите увидеть более сложный пример микрослужб, построенный на основе базовой архитектуры AKS, см. статью "Расширенная архитектура микрослужб Служба Azure Kubernetes (AKS)

Workflow

Архитектура состоит из следующих компонентов:

Служба Azure Kubernetes (AKS). AKS — это управляемый кластер Kubernetes, размещенный в облаке Azure. Azure управляет службой API Kubernetes, и вам нужно управлять только узлами агента.

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

Входящий трафик. Сервер входящего трафика предоставляет маршруты HTTP(S) службам внутри кластера. Дополнительные сведения см. в разделе Шлюз API, приведенном ниже.

Azure Load Balancer. После создания кластера AKS кластер готов к использованию подсистемы балансировки нагрузки. Затем после развертывания службы NGINX подсистема балансировки нагрузки будет настроена с новым общедоступным IP-адресом, который будет передней частью контроллера входящего трафика. Таким образом подсистема балансировки нагрузки направляет интернет-трафик в входящий трафик.

Внешние хранилища данных. Микрослужбы обычно являются бессерверными и записывают состояние во внешние хранилища данных, такие как База данных SQL Azure или Azure Cosmos DB.

Идентификатор Microsoft Entra. AKS использует удостоверение Microsoft Entra для создания и управления другими ресурсами Azure, такими как подсистемы балансировки нагрузки Azure. Идентификатор Microsoft Entra также рекомендуется для проверки подлинности пользователей в клиентских приложениях.

Реестр контейнеров Azure. В Реестре контейнеров можно хранить закрытые образы Docker, которые развертываются в кластере. AKS может пройти проверку подлинности с помощью реестра контейнеров с помощью удостоверения Microsoft Entra. AKS не требует Реестр контейнеров Azure. Можно использовать другие реестры контейнеров, такие как Центр Docker. Просто убедитесь, что реестр контейнеров соответствует или превышает соглашение об уровне обслуживания (SLA) для рабочей нагрузки.

Azure Pipelines. Azure Pipelines входит в состав Azure DevOps Services и выполняет автоматизированные сборки, тесты и развертывания. Вы также можете использовать сторонние решения для CI/CD, такие как Jenkins.

Helm. Helm — это диспетчер пакетов для Kubernetes, способ объединить и обобщить объекты Kubernetes в одном модуле, который можно публиковать, развертывать, обновлять и обновлять.

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

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

Проект

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

Микрослужбы

Микрослужба — это слабо связанная, независимо развертываемая единица кода. Микрослужбы обычно взаимодействуют с помощью хорошо определенных API и доступны для обнаружения с помощью какой-то формы обнаружения служб. Служба всегда должна быть доступной даже при перемещении модулей pod. Объект службы Kubernetes — это естественный способ моделирования микрослужб в Kubernetes.

Шлюз API

Шлюзы API представляют собой общий конструктивный шаблон микрослужб. Шлюз API находится между внешними клиентами и микрослужбами. Он выполняет роль обратного прокси-сервера, который перенаправляет запросы от клиентов к микрослужбам. Кроме того, он может выполнять различные перекрестные задачи, такие как проверка подлинности, завершение SSL и ограничение скорости. Дополнительные сведения см. в разделе:

В Kubernetes функциональные возможности шлюза API в основном обрабатываются контроллером входящего трафика. Рекомендации описаны в разделе "Входящий трафик".

Хранилище данных

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

Дополнительные сведения см. в разделе "Проектирование микрослужб: рекомендации по работе с данными".

Избегайте хранения постоянных данных в локальном хранилище кластера, так как это связывает данные с узлом. Вместо этого используйте внешнюю службу, например База данных SQL Azure или Azure Cosmos DB. Другим вариантом является подключение постоянного тома данных к решению с помощью дисков Azure или Файлы Azure.

Дополнительные сведения см. в служба хранилища параметрах приложения в Служба Azure Kubernetes.

Объект сервисного обслуживания

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

  • IP-адрес . Объект Службы предоставляет статический внутренний IP-адрес для всех групп модулей pod (набор реплик). Когда модули pod создаются или перемещаются, служба всегда доступна по этому внутреннему IP-адресу.

  • Балансировка нагрузки. Трафик, отправляемый на IP-адрес службы, равномерно распределяется между модулями pod.

  • Обнаружение служб. Служба DNS Kubernetes назначает службам внутренние записи DNS. Это означает, что шлюз API может вызывать внутреннюю службу по DNS-имени. Один и тот же механизм может использоваться для связи между службами. Записи DNS упорядочены по пространству имен, поэтому если пространства имен соответствуют ограниченным контекстам, то DNS-имя службы будет естественным образом сопоставлено с доменом приложения.

На следующей схеме показана концептуальная связь между службами и модулями pod. Фактическое сопоставление с IP-адресами и портами конечных точек осуществляется с помощью kube-proxy, сетевого прокси-сервера Kubernetes.

Diagram showing services and pods.

Входящий трафик

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

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

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

  • Выгрузите функции из внутренних служб, таких как завершение SSL, проверка подлинности, ограничения IP-адресов или ограничение скорости клиента (регулирование).

Входящий трафик абстрагирует параметры конфигурации прокси-сервера. Вам также нужен контроллер входящего трафика, который обеспечивает базовую реализацию входящего трафика. Существуют контроллеры входящего трафика для Nginx, HAProxy, Traefik и Шлюз приложений Azure, среди прочего.

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

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

С другой стороны, если вам нужен полный контроль над параметрами, вы можете обойти эту абстракцию и настроить прокси-сервер вручную. Дополнительные сведения см. в разделе "Развертывание Nginx" или HAProxy в Kubernetes.

Примечание.

Для AKS можно также использовать Шлюз приложений Azure с помощью контроллера входящего трафика Шлюз приложений (AGIC). Шлюз приложений Azure может выполнять маршрутизацию уровня 7 и завершение SSL. Она также имеет встроенную поддержку брандмауэра веб-приложений (WAF). Если кластер AKS использует сеть CNI, Шлюз приложений можно развернуть в подсети виртуальной сети кластера или развернуть в другой виртуальной сети из виртуальной сети AKS, однако эти две виртуальные сети должны быть объединены. AGIC также поддерживает подключаемый модуль сети Kubenet. При использовании режима Kubenet контроллер входящего трафика должен управлять таблицей маршрутов в подсети Шлюз приложений, чтобы направлять трафик к IP-адресам pod. Дополнительные сведения см. в разделе "Настройка сети между Шлюз приложений и AKS".

Сведения о службах балансировки нагрузки в Azure см. в разделе "Обзор параметров балансировки нагрузки" в Azure.

Шифрование TLS/SSL

В распространенных реализациях контроллер входящего трафика используется для завершения SSL. Таким образом, в рамках развертывания контроллера входящего трафика необходимо создать сертификат TLS. Используйте только самозаверяемые сертификаты для целей разработки и тестирования. Дополнительные сведения см. в статье "Создание контроллера входящего трафика HTTPS" и использование собственных сертификатов TLS в Служба Azure Kubernetes (AKS).

Для рабочих нагрузок получите подписанные сертификаты из доверенных центров сертификации (ЦС). Сведения о создании и настройке сертификатов Let's Encrypt см. в статье "Создание контроллера входящего трафика со статическим общедоступным IP-адресом в Служба Azure Kubernetes (AKS)".

Кроме того, вам может потребоваться сменить сертификаты в соответствии с политиками организации. Дополнительные сведения см. в разделе "Смена сертификатов" в Служба Azure Kubernetes (AKS).

Пространства имен

Пространства имен используются для организации служб в кластере. Каждый объект в кластере Kubernetes принадлежит пространству имен. Когда создается новый объект, он по умолчанию назначается пространству имен default. Тем не менее рекомендуется создавать пространства имен, которые являются более описательными. Это позволяет упорядочить ресурсы в кластере.

Во-первых, пространства имен помогают предотвратить конфликты имен. Когда несколько команд развертывают микрослужбы в одном кластере, содержащем сотни микрослужб, ими становится трудно управлять, если все они принадлежат одному пространству имен. Кроме того, пространства имен позволяют:

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

  • Примените политики на уровне пространства имен, включая RBAC и политики безопасности.

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

Поместите службы программ в отдельное пространство имен. Например, вы можете развернуть Elasticsearch или Prometheus для мониторинга кластера или Tiller для Helm.

Зонды работоспособности

Kubernetes определяет два типа проб работоспособности, доступных для модуля:

  • Проверка готовности: сообщает Kubernetes, готова ли модуль pod принимать запросы.

  • Проба активности: сообщает Kubernetes, следует ли удалить модуль pod и запустить новый экземпляр.

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

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

Пробы активности обрабатывают случай, когда модуль все еще работает, но не работоспособен и должен быть перезапущен. Например, предположим, что контейнер обслуживает HTTP-запросы, но по какой-то причине зависает. Контейнер не завершит работу аварийно, но он перестанет обрабатывать любые запросы. Если вы определите пробу активности HTTP, проба перестанет отвечать на запросы, что укажет Kubernetes на необходимость перезагрузки модуля.

Вот некоторые соображения при проектировании проб:

  • Если код имеет длительное время запуска, существует опасность, что проба активности сообщит об ошибке до завершения запуска. Чтобы предотвратить сбой initialDelaySeconds пробы, используйте параметр, который задерживает запуск пробы.

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

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

Ограничения ресурсов

Состязание ресурсов может повлиять на доступность службы. Определите ограничения ресурсов для контейнеров, чтобы один контейнер не мог перегружать ресурсы кластера (память и ЦП). Для ресурсов, не являющихся контейнерами, таких как потоки или сетевые подключения, рассмотрите возможность использования шаблона отсеков, чтобы изолировать ресурсы.

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

Безопасность

управление доступом на основе ролей (RBAC);

Kubernetes и Azure имеют механизмы управления доступом на основе ролей (RBAC).

  • Azure RBAC контролирует доступ к ресурсам в Azure, включая возможность создания новых ресурсов. Разрешения могут назначаться пользователям, группам или субъектам-службам. (Субъект-служба является удостоверением безопасности, используемым приложениями.)

  • Kubernetes RBAC контролирует разрешения для API Kubernetes. Например, создание модулей pod и перечисление модулей pod — это действия, которые могут быть авторизованы (или запрещены) пользователю через Kubernetes RBAC. Чтобы назначить пользователям разрешения Kubernetes, создайте роли и привязки ролей:

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

    • RoleBinding назначает пользователям или группам роль.

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

AKS интегрирует оба этих механизма RBAC. При создании кластера AKS его можно настроить для использования идентификатора Microsoft Entra для проверки подлинности пользователей. Дополнительные сведения о настройке этой функции см. в статье "Интеграция идентификатора Microsoft Entra с Служба Azure Kubernetes".

После настройки пользователь, который хочет получить доступ к API Kubernetes (например, через kubectl), должен войти с помощью учетных данных Microsoft Entra.

По умолчанию пользователь Microsoft Entra не имеет доступа к кластеру. Чтобы предоставить доступ, администратор кластера создает roleBindings, которые ссылаются на пользователей или группы Microsoft Entra. Если у пользователя нет разрешений для конкретной операции, она завершится сбоем.

Если у пользователей нет доступа по умолчанию, как администратор кластера получает разрешение на создание привязки ролей? Кластер AKS фактически имеет два типа учетных данных для вызова сервера API Kubernetes: пользователя кластера и администратора кластера. Учетные данные администратора кластера предоставляют полный доступ к кластеру. Команда Azure CLI az aks get-credentials --admin загружает учетные данные администратора кластера и сохраняет их в файле kubeconfig. Администратор кластера может использовать этот файл для создания ролей и привязок ролей.

Вместо управления объектами кластера Kubernetes и RoleBinding в собственном коде в Kubernetes рекомендуется использовать Azure RBAC для авторизации Kubernetes. Это обеспечивает унифицированное управление и управление доступом в ресурсах Azure, AKS и Kubernetes. Эти назначения ролей RBAC Azure могут нацелены на кластер или пространства имен в кластере для более точного управления доступом. Azure RBAC поддерживает ограниченный набор разрешений по умолчанию, и его можно объединить с собственным механизмом Kubernetes для управления ролями и roleBindings для поддержки расширенных или более подробных шаблонов доступа. При включении субъекты Microsoft Entra будут проверяться исключительно Azure RBAC, а обычные пользователи и учетные записи служб Kubernetes проверяются исключительно Kubernetes RBAC.

Так как учетные данные администратора кластера имеют такие разрешения, используйте Azure RBAC для ограничения доступа к ним:

  • "Роль администратора кластера службы Azure Kubernetes" имеет разрешение на скачивание учетных данных администратора кластера. Эта роль должна быть назначена только администраторам кластера.

  • "Роль пользователя кластера службы Azure Kubernetes" имеет разрешение на скачивание учетных данных пользователя кластера. Пользователям, не являющимся администраторами, может быть назначена эта роль. Эта роль не предоставляет каких-либо конкретных разрешений на ресурсы Kubernetes в кластере— это просто позволяет пользователю подключаться к серверу API.

При определении политик RBAC (как Kubernetes, так и Azure) следует учитывать роли в организации:

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

Рекомендуется назначать разрешения Kubernetes RBAC по пространству имен, используя роли и RoleBindings, а не ClusterRoles и ClusterRoleBindings.

Наконец, есть вопрос о разрешениях кластера AKS для создания ресурсов Azure и управления ими, таких как подсистемы балансировки нагрузки, сети или хранилище. Для проверки подлинности с помощью API Azure кластер использует субъект-службу Microsoft Entra. Если субъект-служба не указан при создании кластера, он создается автоматически. Однако рекомендуется сначала создать субъект-службу и назначить ему минимальные разрешения RBAC. Дополнительные сведения см. в статье Субъекты-службы со службой Azure Kubernetes.

Управление секретами и учетные данные приложения

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

Для ресурсов Azure следует использовать управляемые удостоверения. Идея управляемого удостоверения заключается в том, что приложение или служба имеют удостоверение, хранящееся в идентификаторе Microsoft Entra, и использует это удостоверение для проверки подлинности в службе Azure. Приложение или служба имеет субъект-службу, созданный для него в идентификаторе Microsoft Entra ID, и выполняет проверку подлинности с помощью маркеров OAuth 2.0. Исполняемый код процесса может прозрачно получить маркер для использования. Таким образом, вам не нужно хранить пароли или строки подключения. Управляемые удостоверения можно использовать в AKS, назначив удостоверения Microsoft Entra отдельным модулям pod с помощью Идентификация рабочей нагрузки Microsoft Entra (предварительная версия).

В настоящее время не все службы Azure поддерживают проверку подлинности с помощью управляемых удостоверений. Список см . в службах Azure, поддерживающих проверку подлинности Microsoft Entra.

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

  • Azure Key Vault. В AKS можно подключить один или несколько секретов из Key Vault в качестве тома. Том считывает секреты из хранилища ключей. Модуль может считывать секреты так же, как обычный том. Дополнительные сведения см. в разделе "Использование поставщика Azure Key Vault для драйвера CSI хранилища секретов" в кластере AKS.

    Модуль pod проходит проверку подлинности с помощью удостоверения рабочей нагрузки или с помощью управляемого удостоверения, назначаемого пользователем или системой. Дополнительные сведения см. в статье "Предоставление удостоверения для доступа к поставщику Хранилища ключей Azure" для драйвера CSI хранилища секретов.

  • Хранилище HashiCorp. Приложения Kubernetes могут проходить проверку подлинности с помощью HashiCorp Vault с помощью управляемых удостоверений Microsoft Entra. См. раздел HashiCorp Vault с идентификатором Microsoft Entra. Вы можете развернуть хранилище в Kubernetes, попробуйте запустить его в отдельном выделенном кластере из кластера приложений.

  • Секреты Kubernetes. Можно также просто использовать секреты Kubernetes. Этот вариант настроить проще всего, но он имеет некоторые проблемы. Секреты хранятся в хранилище etcd, которое является распределенным хранилищем "ключ — значение". AKS шифрует неактивные данные etcd. Ключами шифрования управляет корпорация Майкрософт.

Использование таких хранилищ, как HashiCorp или Azure Key Vault, предоставляет ряд преимуществ:

  • централизованное управление секретами;
  • все секреты шифруются в неактивном состоянии;
  • централизованное управление ключами;
  • управление доступом к секретам;
  • Аудит

Безопасность контейнеров и оркестратора

Рекомендуется защитить модули pod и контейнеры.

  • Мониторинг угроз: мониторинг угроз с помощью Microsoft Defender для контейнеров (или сторонних возможностей). Если вы размещаете контейнеры на виртуальной машине, используйте Microsoft Defender для серверов или 3-стороннюю возможность. Кроме того, можно интегрировать журналы из решения мониторинга контейнеров в Azure Monitorв Microsoft Sentinel или существующее решение SIEM.

  • Мониторинг уязвимостей. Непрерывно отслеживайте образы и выполняйте контейнеры для известных уязвимостей с помощью Microsoft Defender для облака или стороннего решения, доступного через Azure Marketplace.

  • Автоматизация исправлений изображений с помощью задач ACR, функции Реестр контейнеров Azure. Образ контейнера строится из уровней. Базовые уровни включают образ ОС и образы платформы приложений, такие как ASP.NET Core или Node.js. Базовые образы обычно создаются на уровень выше от разработчиков приложений и поддерживаются другими администраторами проектов. Если эти образы исправляются на вышестоящем уровне, важно обновлять, тестировать и повторно развертывать собственные образы, чтобы не осталось известных уязвимостей безопасности. Задачи ACR могут помочь автоматизировать этот процесс.

  • Храните образы в доверенном частном реестре, например Реестр контейнеров Azure или доверенном реестре Docker. Используйте проверяющий веб-перехватчик допуска в Kubernetes, чтобы модули могли извлекать образы только из доверенного реестра.

  • Принцип применения наименьших привилегий

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

DevOps

Эта эталонная архитектура предоставляет шаблон Azure Resource Manager для подготовки облачных ресурсов и его зависимостей. С помощью [шаблонов Azure Resource Manager][arm-template] можно использовать Azure DevOps Services для подготовки различных сред в минутах, например для реплика рабочих сценариев. Это позволяет сэкономить затраты и подготовить среду нагрузочного тестирования только при необходимости.

Рассмотрите возможность выполнения критериев изоляции рабочей нагрузки для структуры шаблона ARM, рабочая нагрузка обычно определяется как произвольное подразделение функций; Например, можно иметь отдельный шаблон для кластера, а затем другой для зависимостей. Изоляция рабочей нагрузки позволяет DevOps выполнять непрерывную интеграцию и непрерывную доставку (CI/CD), так как каждая рабочая нагрузка связана и управляется соответствующей командой DevOps.

Рекомендации по развертыванию (CI/CD)

Ниже приведены некоторые цели надежного процесса CI/CD для архитектуры микрослужб:

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

Дополнительные сведения о проблемах см. в разделе CI/CD для архитектур микрослужб.

Конкретные рекомендации и рекомендации см. в разделе CI/CD для микрослужб в Kubernetes.

Оптимизация затрат

Для оценки затрат используйте калькулятор цен Azure. Другие рекомендации описаны в разделе "Затраты" в Microsoft Azure Well-Architected Framework.

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

Служба Azure Kubernetes (AKS)

Затраты на AKS в развертывании, управлении и операциях кластера Kubernetes не связаны. Вы платите только за экземпляры виртуальных машин, хранилище и сетевые ресурсы, используемые кластером Kubernetes.

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

Azure Load Balancer

Плата взимается только за количество настроенных правил балансировки нагрузки и исходящего трафика. За правила преобразования сетевых адресов (NAT) плата не взимается. Почасовая плата за Load Balancer (цен. категория не взимается, если правила не настроены.

Дополнительные сведения см. в разделе "Цены на Azure Load Balancer".

Azure Pipelines

Эта эталонная архитектура использует только Azure Pipelines. Azure предлагает Azure Pipeline в качестве отдельной службы. Вы можете бесплатно разместить задание, размещенное корпорацией Майкрософт, с 1800 минут в месяц для CI/CD и одно локальное задание с неограниченной минутой в месяц, дополнительные задания имеют расходы. Дополнительные сведения см. в разделе о ценах на Azure DevOps Services.

Azure Monitor

Для Azure Monitor Log Analytics взимается плата за прием и хранение данных. Дополнительные сведения см. на странице цен на Azure Monitor.

Развертывание этого сценария

Чтобы развернуть эталонную реализацию для этой архитектуры, выполните действия, описанные в репозитории GitHub.

Следующие шаги