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

Шлюз приложений Azure

Реестр контейнеров Azure

Служба Azure Kubernetes (AKS)

Виртуальная сеть Azure

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

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

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

Архитектура

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

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

Workflow

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

HttpS-запрос отправляется для планирования сбора дронов. Запросы передаются через Шлюз приложений Azure в веб-приложение приема, которое выполняется как микрослужба в кластере в AKS.
Веб-приложение приема создает сообщение и отправляет его в очередь сообщений служебная шина.
Серверная система назначает дрон и уведомляет пользователя. Рабочий процесс:
- Использует сведения о сообщении из очереди сообщений служебная шина.
- Отправляет HTTPS-запрос в микрослужбу доставки, которая передает данные в Кэш Azure для Redis внешнее хранилище данных.
- Отправляет HTTPS-запрос в микрослужбу планировщика дронов.
- Отправляет HTTPS-запрос в микрослужбу пакета, которая передает данные во внешнее хранилище данных MongoDB.
Запрос HTTPS GET используется для возврата состояния доставки. Этот запрос проходит через Шлюз приложений в микрослужбу доставки.
Микрослужба доставки считывает данные из Кэш Azure для Redis.

Компоненты

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

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

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

Виртуальная сеть 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: серверной части. Политика запрещает любой трафик, если он не был получен из pod с меткой, которая соответствует app.kubernetes.io/part-of: дронделивери.

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) критически важен для обнаружения аномалий, диагностики проблем и быстрого понимания зависимостей между службами. Приложение Аналитика, являющееся частью Azure Monitor, обеспечивает мониторинг APM для динамических приложений, написанных в .NET Core, Node.js, Java и многих других языках приложений.

Application Insights.

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

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

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

Example of an Application Insights dependency map for an AKS microservices application.

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

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

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

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

Архитектура

Workflow

Компоненты

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

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

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

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

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

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

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

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

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

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

Наблюдение

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

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

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

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

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

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

Обратная связь

Обратная связь

Дополнительные ресурсы

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

Архитектура

Workflow

Компоненты

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

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

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

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

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

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

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

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

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

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

Наблюдение

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

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

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

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

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

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

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

Обратная связь

Обратная связь

Дополнительные ресурсы