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

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

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

Архитектура

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

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

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

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

Следующий рабочий процесс соответствует предыдущей схеме:

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

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

3. В внутренней системе назначается беспилотный летательный аппарат и уведомляется пользователю. Микрослужба рабочего процесса выполняет следующие задачи:

   • Потребляет информацию о сообщении из очереди сообщений Service Bus.

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

   • Отправляет HTTPS-запрос микрослужбе планировщика дронов.

   • Отправляет HTTPS-запрос в микрослужбу пакета, которая передает данные во внешнее хранилище данных Azure DocumentDB.

   • Расширенные политики сетевых служб контейнеров (Cilium NetworkPolicy) управляют трафиком между службами в кластере, а плоскость данных прозрачно применяет необязательное шифрование модулей pod между узлами (WireGuard). Расширенные сетевые службы контейнеров по умолчанию не включены. Он извлекает данные на уровне узла и пода и передает их в Azure Monitor для сквозной видимости.

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

5. Микрослужба доставки считывает данные из Управляемого Redis в Azure.

Компоненты

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

  • Идентификатор Microsoft Entra, управляемый AKS, для управления доступом на основе ролей Azure (Azure RBAC) — это функция, которая интегрирует Идентификатор Microsoft Entra с AKS для обеспечения контроля доступа на основе удостоверений. В этой архитектуре обеспечивается безопасная централизованная проверка подлинности и авторизация для пользователей и рабочих нагрузок кластера.

  • Azure CNI, на базе Cilium , — это рекомендуемое сетевое решение для подключения непосредственно к виртуальной сети Azure. В этой архитектуре ip-адреса из виртуальной сети назначаются модулям pod, обеспечивая встроенные возможности политики сети и видимость трафика.

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

    • Наблюдаемость сети контейнеров использует инструменты на основе расширенного фильтра пакетов Berkeley (eBPF), такие как Hubble и Retina, для сбора запросов системы доменных имен (DNS), потоков от одного пода к другому и от пода к сервису, сброса пакетов и других метрик. Он работает в плоскостях данных Cilium и не Cilium Linux. Она также интегрируется с Azure Monitor Managed Service для Prometheus и Azure Managed Grafana для визуализации и оповещений. В этой архитектуре система наблюдения за сетью контейнеров диагностирует неправильные настройки политик, задержку или ошибки DNS, а также несбалансированность трафика между микрослужбами.

    • Безопасность сети контейнеров применяется к кластерам, использующим Azure CNI с поддержкой Cilium. Он применяет ресурсы Cilium NetworkPolicy, включая фильтрацию исходящего трафика на основе полностью квалифицированных доменных имен (FQDN), чтобы реализовать сегментацию сети нулевого доверия и сократить операционные издержки. В этой архитектуре политики FQDN в кластере работают с брандмауэром Azure или шлюзом NAT Azure для обеспечения выполнения ограничения эгресс-трафика до минимальных привилегий, при этом упрощая обслуживание политик.

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

  • Управляемый входящий трафик NGINX с надстройкой маршрутизации приложений — это функция в AKS, которая помогает предоставлять приложения в Интернете с помощью трафика HTTP или HTTPS. Он предоставляет предварительно настроенный контроллер входящего трафика NGINX для AKS. В этой архитектуре производится маршрутизация трафика к службам и обеспечивается подключение подов к шлюзу приложений.

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

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

• Шлюз приложений — это управляемая Azure служба, которая обеспечивает балансировку нагрузки уровня 7 и возможности брандмауэра веб-приложений (WAF). В этой архитектуре он предоставляет микрослужбу приема как общедоступную конечную точку и балансирует входящий веб-трафик приложению.

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

• Приватный канал Azure — это управляемая Azure служба, которая обеспечивает частное подключение к платформе Azure как услуга (PaaS) через магистральную сеть Майкрософт. В этой архитектуре он назначает частные IP-адреса для доступа к Реестру контейнеров Azure и Azure Key Vault из пулов узлов AKS через частные конечные точки.

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

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

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

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

• Azure Cosmos DB — это управляемая Azure, глобально распределенная служба NoSQL, реляционная и векторная база данных. В этой архитектуре Azure Cosmos DB и Azure DocumentDB служат внешними хранилищами данных для каждой микрослужбы.

• Key Vault — это управляемая Azure служба, которая безопасно хранит секреты, ключи и сертификаты и управляет ими. В этой архитектуре Key Vault хранит учетные данные, используемые микрослужбами для доступа к Azure Cosmos DB и Azure Managed Redis.

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

  Наблюдение за сетями контейнеров для расширенных сетевых служб контейнеров использует Hubble для видимости потока и Retina для курированной сетевой телеметрии. Эти средства интегрируются с управляемыми системами наблюдаемости, такими как управляемая служба Azure Monitor для Prometheus и управляемая Grafana от Azure, для устранения неполадок и создания отчетов по целям уровня обслуживания (SLO).

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

Другие операции поддерживают системные компоненты

• Flux — это поддерживаемое Azure, открытое и расширяемое решение непрерывной доставки для Kubernetes, которое реализует GitOps для AKS. В этой архитектуре Flux автоматизирует развертывания путем синхронизации файлов манифеста приложения из репозитория Git, что обеспечивает согласованную и декларативную доставку микрослужб в кластер AKS.

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

• Поставщик провайдера драйвера CSI для хранилища секретов Key Vault — это драйвер, интегрированный с Azure, который позволяет кластерам AKS монтировать секреты из Key Vault с помощью томов CSI. В этой архитектуре секреты подключены непосредственно к контейнерам микрослужб, что позволяет безопасно получить учетные данные для Azure Cosmos DB и Azure Managed Redis.

Альтернативы

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

Вы можете использовать ArgoCD в качестве средства GitOps вместо Flux. Flux и ArgoCD доступны как расширения кластера.

Вместо хранения учетных данных для Azure Cosmos DB и Azure Managed Redis в хранилищах ключей рекомендуется использовать управляемые удостоверения для проверки подлинности, так как механизмы проверки подлинности без пароля являются более безопасными. Дополнительные сведения см. в статье "Использование управляемых удостоверений для подключения к Azure Cosmos DB с виртуальной машины Azure " и аутентификации управляемого удостоверения с помощью идентификатора Microsoft Entra для доступа к ресурсам служебной шины. Azure Управляемый Redis также поддерживает проверку подлинности с помощью управляемых удостоверений.

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

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

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

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

Управляемые входящий трафик NGINX с надстройкой маршрутизации приложений

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

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

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

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

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

Рекомендуется использовать контроллер входящего трафика с внутренним (частным) IP-адресом и внутренним балансировщиком нагрузки, интегрировав его в частные зоны DNS Azure для разрешения имен хостов микросервисов. Настройте частный IP-адрес или имя узла контроллера входящего трафика в качестве адреса внутреннего пула в шлюзе приложений. Шлюз приложений получает трафик на общедоступной конечной точке, выполняет проверки WAF и направляет трафик в частный IP-адрес входящего трафика.

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

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

Сети и сетевая политика

Используйте Azure CNI на базе Cilium. Плоскость данных eBPF имеет подходящую производительность маршрутизации и поддерживает любой кластер размера. Cilium изначально применяет Kubernetes NetworkPolicy и обеспечивает широкие возможности отслеживания трафика. Дополнительные сведения см. в статье "Настройка Azure CNI с помощью Cilium" в AKS.

Для конкретных потребностей в управлении IP-адресами Azure CNI под управлением Cilium поддерживает как модели IP-адресов pod, маршрутируемые виртуальными сетями, так и наложения. Дополнительные сведения см. в статье Azure CNI с помощью Cilium.

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

Политики сети указывают, как модули POD AKS взаимодействуют друг с другом и с другими сетевыми конечными точками. По умолчанию для всех входящих и исходящих трафика разрешено и из модулей pod. При проектировании взаимодействия микрослужб друг с другом и с другими конечными точками следует учитывать принцип нулевого доверия, где доступ к любой службе, устройству, приложению или репозиторию данных требует явной настройки. Определите и примените политику сети Kubernetes NetworkPolicy (реализованную Advanced Container Networking Services/Cilium) для сегментирования трафика между микрослужбами и ограничения исходящего соединения только разрешенных полных доменных имен (FQDN).

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

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

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

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

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

При использовании Azure CNI на базе Cilium Kubernetes NetworkPolicy реализуется Cilium. Для специализированных требований Azure предоставляет другие подсистемы сетевой политики, включая диспетчер сетевых политик Azure и Calico. Мы рекомендуем Cilium в качестве обработчика политик сети по умолчанию.

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

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

• Вычислительные ресурсы, такие как центральные единицы обработки (ЦП), память и графические единицы обработки (GPU)

• Ресурсы хранилища, включая количество томов или объем дискового пространства для определенного класса хранилища.

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

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

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

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

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

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

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

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

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

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

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

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

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

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'
}

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

minCount: 2
maxCount: 5

Автомасштабирование горизонтального модуля pod

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

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

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

apiVersion: autoscaling/v2
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
        target:
          type: Utilization
          averageUtilization: 70

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

Дополнительные сведения см. в разделе "Параметры масштабирования" для приложений в AKS.

Автомасштабирование вертикального модуля pod

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

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

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

Надстройка Kubernetes Event-Driven Autoscaling (KEDA) позволяет автоматизировать масштабирование на основе событий, чтобы обеспечить масштабирование микрослужбы для устойчивого и экономичного удовлетворения спроса. Например, KEDA может масштабировать микрослужбы, когда количество сообщений в очереди служебной шины превышает определенные пороговые значения.

В сценарии доставки дронов Fabrikam KEDA масштабирует микрослужбу рабочего процесса в зависимости от глубины очереди служебной шины и на основе выходных данных микрослужб приема. Список масштабируемых модулей KEDA для служб Azure см. в разделе интеграции с KEDA в AKS.

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

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

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

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

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

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

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

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

Наблюдение

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

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

• Функция Live Data в аналитике контейнеров отслеживает кластеры, узлы и контейнеры AKS для работоспособности и использования ресурсов.

• Azure Managed Grafana визуализирует метрики и панели мониторинга для кластеров и микрослужб.

Расширенные возможности отслеживания сетевых служб контейнеров дополняют эти средства, обеспечивая глубокую видимость сетевого поведения кластеров AKS на основе eBPF. Он фиксирует задержку DNS, потоки между подами и службами, отбрасывание политики сети и метрики протоколов уровня 7, такие как коды состояния HTTP и время отклика. Эта телеметрия интегрируется с управляемой службой Azure Monitor для метрик Prometheus и управляемой Azure Grafana для панелей мониторинга. Плоскость данных Cilium eBPF обеспечивает видимость и устранение неполадок на уровне потока. В сочетании с расширенными сетевыми службами контейнеров и Azure Monitor эта возможность обеспечивает сквозное сетевое наблюдение. Эта интеграция позволяет обнаруживать узкие места сети, неправильно настроенные политики и проблемы связи, которые могут пропустить традиционный APM.

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

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

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

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

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

• Используйте средства защиты развертывания в кластере AKS. Средства защиты развертывания применяют рекомендации Kubernetes в кластере AKS с помощью элементов управления Политика Azure.

• Интеграция проверки безопасности в конвейеры сборки и развертывания микрослужбы. Управление средой DevOps с помощью Microsoft Defender для Cloud DevOps security. Используйте средства проверки и анализа статического кода без агента в рамках конвейеров непрерывной интеграции и непрерывного развертывания (CI/CD), чтобы определить и устранить уязвимости кода микрослужбы в процессе сборки и развертывания.

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

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

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

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

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

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

Расширенные сетевые службы контейнеров предоставляют сегментацию сети в кластере и элементы управления нулевым доверием для кластеров AKS. Используйте политики сети Cilium в Azure CNI, управляемые Cilium , для реализации сегментации уровня 3 и уровня 4 в кластере. Расширенная безопасность сетевых служб контейнеров расширяет эту основу путем добавления расширенных возможностей:

• Фильтрация исходящего трафика на основе FQDN, чтобы ограничить исходящий трафик утвержденными доменами.

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

• Шифрование WireGuard для обеспечения безопасности трафика между контейнерами и защиты конфиденциальных данных в процессе передачи.

  Эти функции работают вместе с защитой периметра, такими как группы безопасности сети (NSG) и Брандмауэр Azure, чтобы обеспечить многоуровневый подход к безопасности, который обеспечивает управление трафиком из кластера.

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

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

Сетевые плоскости данных и механизмы политики

Cilium в AKS в настоящее время поддерживается для узлов Linux и применяет NetworkPolicy в плоскости передачи данных. Обратите внимание на предупреждения политики, такие как ipBlock использование с IP-адресами узлов и IP-адресами pod-ов, а также на то, что pod-ы, подключенные к сети хоста, используют идентификатор хоста. Политики уровня Pod не применяются. Согласуйте версии AKS и Cilium с поддерживаемой матрицей версий. Дополнительные сведения см. в статье об ограничениях Azure CNI на базе Cilium.

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

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

• В разделе "Оптимизация затрат" в Well-Architected Framework описываются рекомендации по затратам.

• Используйте калькулятор цен Azure для оценки затрат для конкретного сценария.

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

• Рассмотрите возможность использования уровня "Бесплатный" AKS для рабочих нагрузок разработки и использования уровней "Стандартный" и "Премиум " для рабочих нагрузок.

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

Операционное превосходство

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

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

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

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

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

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Дополнительные сведения см. в контрольном списке проверки конструктора дляпроизводительности.

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

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

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

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

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

• Если из микрослужбы существует большое количество исходящих потоков, рассмотрите возможность использования шлюзов преобразования сетевых адресов (NAT), чтобы избежать исчерпания портов преобразования сетевых адресов (SNAT).

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

• Рекомендуется использовать Azure CNI с оверлейными сетями для экономии адресного пространства сети.

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

• Общие сведения об AKS
• Что такое виртуальная сеть?
• Что такое приватный канал?
• Что такое Шлюз приложений?
• Что такое Бастион Azure
• Общие сведения о Key Vault
• Общие сведения о реестре контейнеров
• Общие сведения о службе Azure Monitor
• Расширенные сетевые сервисы контейнеризации

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

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