Расширенная архитектура микрослужб Службы Azure Kubernetes (AKS)

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

Эта архитектура основана на базовой архитектуре AKS, рекомендуемой корпорацией Майкрософт отправной точкой для инфраструктуры Служба Azure Kubernetes (AKS). Базовые функции инфраструктуры AKS, такие как Идентификация рабочей нагрузки Microsoft Entra, ограничения входящего трафика и исходящего трафика, ограничения ресурсов и другие безопасные конфигурации инфраструктуры AKS. Эти сведения о инфраструктуре не рассматриваются в этом документе. Перед продолжением содержимого микрослужб рекомендуется ознакомиться с базовым показателем AKS.

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

Архитектура

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

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

Рабочий процесс

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

1. HttpS-запрос отправляется для планирования сбора дронов. Запросы передаются через Шлюз приложений Azure в веб-приложение приема, которое выполняется как микрослужба в кластере в AKS.

2. Веб-приложение приема создает сообщение и отправляет его в очередь сообщений служебная шина.

3. Серверная система назначает дрон и уведомляет пользователя. Рабочий процесс:

   • Использует сведения о сообщении из очереди сообщений служебная шина.
   • Отправляет HTTPS-запрос в микрослужбу доставки, которая передает данные в Кэш Azure для Redis внешнее хранилище данных.
   • Отправляет HTTPS-запрос в микрослужбу планировщика дронов.
   • Отправляет HTTPS-запрос в микрослужбу пакета, которая передает данные во внешнее хранилище данных MongoDB.

4. Запрос HTTPS GET используется для возврата состояния доставки. Этот запрос проходит через Шлюз приложений в микрослужбу доставки.

5. Микрослужба доставки считывает данные из Кэш Azure для Redis.

Компоненты

Эта архитектура использует следующие компоненты Azure:

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

К функциям инфраструктуры AKS, используемым в этой архитектуре, относятся:

• Разделение пула узлов системы и пользователей
• Идентификатор Microsoft Entra, управляемый AKS, для управления доступом на основе ролей (RBAC)
• Идентификация рабочей нагрузки Microsoft Entra
• надстройка Политика Azure для AKS
• Сетевой интерфейс контейнеров Azure (CNI)
• Аналитика контейнеров Azure Monitor

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

Приватный канал Azure выделяет определенные частные IP-адреса для доступа к Реестр контейнеров Azure и Key Vault из частных конечных точек в подсети системы AKS и пула узлов пользователей.

Шлюз приложений Azure с брандмауэром веб-приложения (WAF) предоставляет маршруты HTTP(S) в кластер AKS и балансирует веб-трафик к веб-приложению. Эта архитектура использует Шлюз приложений Azure контроллер входящего трафика (AGIC) в качестве контроллера входящего трафика Kubernetes.

Бастион Azure обеспечивает безопасный протокол удаленного рабочего стола (RDP) и безопасный доступ к виртуальным машинам в виртуальных сетях с помощью протокола SSL без необходимости предоставлять виртуальные машины через общедоступные IP-адреса.

Брандмауэр Azure — это служба безопасности сети, которая защищает все ресурсы Azure виртуальная сеть. Брандмауэр разрешает только утвержденные службы и полные доменные имена (FQDN) в качестве исходящего трафика.

Внешнее хранилище и другие компоненты:

Azure Key Vault хранит ключи безопасности для служб AKS и управляет ими.

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

Azure Cosmos DB хранит данные с открытым исходным кодом Azure Cosmos DB для MongoDB. Микрослужбы обычно без отслеживания состояния и записывают их состояние во внешние хранилища данных. Azure Cosmos DB — это база данных NoSQL с API с открытым исходным кодом для MongoDB и Cassandra.

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

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

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

Другие компоненты системы поддержки операций (OSS):

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

Поставщик CSI хранилища секретов Хранилища ключей Azure, получает секреты, хранящиеся в Azure Key Vault, и использует интерфейс драйвера CSI хранилища секретов для подключения их к модулям pod Kubernetes.

Flux, открытое и расширяемое решение непрерывной доставки для Kubernetes, на основе набора средств GitOps.

Подробности сценария

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

Потенциальные варианты использования

Это решение идеально подходит для самолетов, аэрокосмических и авиационных отраслей.

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

Реализуйте эти рекомендации при развертывании расширенных архитектур микрослужб AKS.

Контроллер входящего трафика шлюза приложений (AGIC)

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

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

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

Состояние кластера AKS преобразуется в конфигурацию Шлюз приложений и применяется через Azure Resource Manager.

Внешние контроллеры входящего трафика упрощают прием трафика в кластеры AKS, повышают безопасность и производительность и сохраняют ресурсы. Эта архитектура использует контроллер входящего трафика (AGIC) Шлюз приложений Azure для управления входящего трафика. Использование Шлюз приложений для обработки всего трафика устраняет потребность в дополнительной подсистеме балансировки нагрузки. Так как модули pod устанавливают прямые подключения к Шлюз приложений, количество необходимых прыжков уменьшается, что приводит к повышению производительности.

Шлюз приложений имеет встроенные возможности автомасштабирования, в отличие от контроллеров входящего трафика в кластере, которые должны быть масштабированы, если они используют нежелательный объем вычислительных ресурсов. Шлюз приложений может выполнять маршрутизацию уровня 7 и завершение SSL и интегрированную систему безопасности транспортного уровня (TLS) со встроенным брандмауэром веб-приложения (WAF).

Для параметра входящего трафика AGIC необходимо включить сеть CNI при настройке кластера AKS, так как Шлюз приложений развертывается в подсети виртуальной сети AKS. Мультитенантные рабочие нагрузки или один кластер, поддерживающий среды разработки и тестирования, могут потребовать больше контроллеров входящего трафика.

Политики сети нулевого доверия

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

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

После применения ограничивающей политики начните определять определенные сетевые правила, чтобы разрешить трафик в каждый модуль pod в микрослужбе и выйти из него. В следующем примере политика сети применяется к любому модулем pod в пространстве имен серверной части разработки с меткой, которая соответствует app.kubernetes.io/component: backend. Политика запрещает какой-либо трафик, если не был получен из модуля pod с меткой, которая соответствует app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Дополнительные сведения о политиках сети Kubernetes и дополнительных примерах потенциальных политик по умолчанию см . в документации по Kubernetes.

Квоты ресурсов

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

• Вычислительные ресурсы, например ЦП, память и GPU.
• Ресурсы хранилища, включая количество томов или объем дискового пространства для заданного класса хранилища.
• Число объектов, например максимальное количество секретов, служб или заданий, которые можно создать.

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

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

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

В следующем примере показана спецификация pod, которая задает запросы и ограничения квоты ресурсов:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Дополнительные сведения о квотах ресурсов см. в следующем разделе:

• Принудительное применение квот ресурсов
• Квоты ресурсов

Автомасштабирование

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

Автоматическое масштабирование кластера

Автомасштабирование кластера (ЦС) масштабирует количество узлов. Предположим, что модули pod не могут быть запланированы из-за ограничений ресурсов; Средство автомасштабирования кластера подготавливает дополнительные узлы. Необходимо определить минимальное количество узлов, чтобы сохранить кластер AKS и рабочие нагрузки, а также максимальное количество узлов для интенсивного трафика. ЦС проверяет каждые несколько секунд для ожидающих модулей pod или пустых узлов и масштабирует кластер AKS соответствующим образом.

В следующем примере показана конфигурация ЦС из шаблона ARM:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

Следующие строки в примере примера набора шаблонов ARM минимальные и максимальные узлы для ЦС:

"minCount": 2,
"maxCount": 5,

Автомасштабирование модулей

Горизонтальное автомасштабирование pod (HPA) масштабирует модули pod на основе наблюдаемых ЦП, памяти или пользовательских метрик. Чтобы настроить горизонтальное масштабирование pod, укажите целевые метрики и минимальное и максимальное количество реплик в спецификации модуля pod развертывания Kubernetes. Нагрузочный тест служб для определения этих чисел.

ЦС и HPA хорошо работают вместе, поэтому включите оба параметра автомасштабирования в кластере AKS. HPA масштабирует приложение, а ЦС масштабирует инфраструктуру.

В следующем примере задаются метрики ресурсов для HPA:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

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

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

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

В Kubernetes модуль pod может предоставлять два типа пробы работоспособности:

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

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

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

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

Наблюдение

В приложении микрослужб мониторинг управления производительностью приложений (APM) критически важен для обнаружения аномалий, диагностики проблем и быстрого понимания зависимостей между службами. Application Insights, которая является частью Azure Monitor, обеспечивает мониторинг APM для динамических приложений, написанных на .NET Core, Node.js, Java и многих других языках приложений.

Application Insights.

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

Чтобы контекстуализировать данные телеметрии служб с помощью Kubernetes, интегрируйте данные телеметрии Azure Monitor с AKS для сбора метрик из контроллеров, узлов и контейнеров, а также журналов контейнеров и узлов. Если вы используете .NET, библиотека Application Insights для Kubernetes дополняет данные телеметрии Application Insights изображения, контейнера, узла, модуля pod, метки и набора реплик.

На следующей схеме показан пример карты зависимостей приложения, которую Application Insights создает для трассировки телеметрии микрослужб AKS:

Дополнительные сведения о вариантах инструментирования общих языков интеграции Application Insights см. в разделе "Мониторинг приложений для Kubernetes".

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

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

Масштабируемость

При планировании масштабируемости следует учитывать следующие моменты.

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

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

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

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

• Мультитенантные или другие расширенные рабочие нагрузки могут иметь требования к изоляции пула узлов, которые требуют большего и вероятно меньшего размера подсетей. Дополнительные сведения о создании пулов узлов с уникальными подсетями см. в статье "Добавление пула узлов с уникальной подсетью". Организации имеют разные стандарты для своих центральных реализаций. Обязательно следуйте рекомендациям организации.

Управляемость

При планировании управляемости следует учитывать следующие моменты.

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

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

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

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

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

При планировании безопасности следует учитывать следующие моменты.

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

• С помощью управляемых удостоверений процесс выполнения может быстро получить маркеры OAuth 2.0 Azure Resource Manager; Нет необходимости в паролях или строка подключения. В AKS можно назначить удостоверения отдельным модулям pod с помощью Идентификация рабочей нагрузки Microsoft Entra.

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

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

• Не все службы Azure поддерживают проверку подлинности уровня данных с помощью идентификатора Microsoft Entra. Чтобы хранить учетные данные или секреты приложений для этих служб, сторонних служб или ключей API, используйте Azure Key Vault. Azure Key Vault обеспечивает централизованное управление, управление доступом, шифрование неактивных данных и аудит всех ключей и секретов.

• В AKS можно подключить один или несколько секретов из Key Vault в качестве тома. Затем модуль pod может считывать секреты Key Vault так же, как обычный том. Дополнительные сведения см. в проекте secret-store-csi-driver-provider-azure на сайте GitHub.

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

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

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

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

• Сведения о стоимости необходимых ресурсов см. в калькуляторе служб контейнеров.

• Рассмотрите возможность включения анализа затрат AKS для распределения затрат на инфраструктуру детализированного кластера определенными конструкциями Kubernetes.

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

• Общие сведения о Служба Azure Kubernetes
• Что такое виртуальная сеть Azure?
• Что собой представляет Приватный канал Azure?
• What is Azure Application Gateway? (Что собой представляет шлюз приложений Azure)
• Что такое Бастион Azure
• Сведения об Azure Key Vault
• Общие сведения о Реестр контейнеров Azure
• Вас приветствует Azure Cosmos DB
• Общие сведения о службе Azure Monitor

Связанные ресурсы

• Базовая архитектура для кластера Служба Azure Kubernetes (AKS)
• Проектирование, сборка и эксплуатация микрослужб в Azure с помощью Kubernetes
• Архитектура микрослужб в AKS
• Мониторинг архитектуры микрослужб в AKS
• Сценарий настройки производительности: распределенные бизнес-транзакции
• Создание конвейера CI/CD для микрослужб в Kubernetes