Руководство по запуску локального шлюза в Kubernetes в рабочей среде

ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Премия

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

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

Authentication

По умолчанию токен доступа (также называемый ключом аутентификации) используется самостоятельно размещённым шлюзом для проверки подлинности в экземпляре API Management.

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

При автоматизации обновления токена используйте операцию Шлюз - сгенерировать токен. Сведения об управлении секретами Kubernetes см. в разделе "Секреты Kubernetes".

Вы также можете развернуть локальный шлюз в Kubernetes и включить проверку подлинности в экземпляре API Management с помощью Microsoft Entra ID. Дополнительные сведения и рекомендации см. в разделе "Параметры проверки подлинности локального шлюза".

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

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

Есть два способа автомасштабирования самостоятельно размещенного шлюза горизонтально.

  • Автомасштабирование на основе использования ресурсов (ЦП и памяти)
  • Автомасштабирование на основе количества запросов в секунду

Вы можете автомасштабировать с помощью встроенной функциональности Kubernetes или с помощью автомасштабирования на основе событий Kubernetes (KEDA). KEDA — это проект в стадии инкубации Фонда Cloud Native Computing Foundation (CNCF), который стремится сделать автоматическое масштабирование приложений простым.

Замечание

KEDA — это технология с открытым исходным кодом, которая не поддерживается Azure support и должна работать клиентами.

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

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

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

Подсказка

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

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

Kubernetes не предоставляет встроенный механизм автомасштабирования на основе трафика.

KEDA предоставляет несколько способов, которые могут помочь в автомасштабировании, основанном на трафике:

  • Можно масштабировать на основе метрик из входящего трафика Kubernetes, если они доступны в Prometheus или Azure Monitor с помощью встроенного масштабируемого модуля.
  • Вы можете установить надстройку HTTP, которая доступна в бета-версии и масштабируется на основе количества запросов в секунду.

Резервное копирование конфигурации

Настройте локальный том хранения для контейнера самостоятельно размещённого шлюза, для сохранения резервной копии последней загруженной конфигурации. Если подключение не работает, том хранения может использовать резервную копию при перезапуске. Путь подключения тома должен быть /apim/config и должен принадлежать группе с идентификатором 1001. Дополнительные сведения см. в этом GitHub примере.

Дополнительные сведения о хранилищах в Kubernetes см. в статье Тома Kubernetes. Чтобы изменить владение подключенным путем, см. securityContext.fsGroup параметр.

Замечание

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

Тег образа контейнера

Файл YAML, указанный в Azure portal, использует тег latest. Этот тег всегда ссылается на последнюю версию образа контейнера локального шлюза.

Рекомендуется использовать тег определенной версии в рабочей среде во избежание непреднамеренного обновления до более новой версии.

Вы можете скачать полный список доступных тегов.

Подсказка

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

Дополнительные сведения см. в статье "Развертывание локального шлюза в Kubernetes с помощью Helm".

Ресурсы контейнера

По умолчанию файл YAML, предоставленный в Azure portal, не указывает запросы ресурсов контейнера.

Надежно прогнозировать и рекомендовать объем ресурсов ЦП и памяти контейнера и количество реплик, необходимых для поддержки определенной рабочей нагрузки, невозможно. Многие факторы оказывают влияние, такие как:

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

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

Пользовательские доменные имена и SSL-сертификаты

Если вы используете пользовательские доменные имена для конечных точек API Management, особенно если для конечной точки управления используется пользовательское доменное имя, возможно, потребуется обновление значения config.service.endpoint в файле <gateway-name>.yaml для замены доменного имени по умолчанию на пользовательское доменное имя. Убедитесь, что конечная точка управления доступна из pod локального шлюза в кластере Kubernetes.

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

Замечание

При использовании локального шлюза версии 2 API Management предоставляет новую конечную точку конфигурации: <apim-service-name>.configuration.azure-api.net. Пользовательские имена узлов поддерживаются для этой конечной точки и могут использоваться вместо имени узла по умолчанию.

Политика DNS

Разрешение DNS-имен играет важную роль в способности локального шлюза подключаться к зависимостям в Azure и отправлять вызовы API серверным службам.

Файл YAML, указанный в Azure portal, применяет политику по умолчанию ClusterFirst. Эта политика приводит к тому, что запросы на разрешение имен, не разрешенные DNS кластера, будут переадресованы на вышестоящий DNS-сервер, унаследованный от узла.

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

Политика внешнего трафика

Файл YAML, предоставленный через портал Azure, задает поле externalTrafficPolicy в объекте Service значением Local. Это сохраняет IP-адрес вызывающего абонента (доступно в контексте запроса) и отключает балансировку нагрузки между узлами, устраняя сетевые прыжки, вызванные этим. Помните, что эта настройка может привести к асимметричному распределению трафика в развертываниях, где число подов шлюза на узел неравномерно.

Проверка работоспособности

Используйте конечную точку HTTP-зондов /status-0123456789abcdef для проверки готовности и жизнеспособности в развертываниях ваших шлюзов. Это помогает направлять трафик только в те развертывания шлюза, которые успешно запущены и готовы обслуживать трафик или остаются отзывчивыми.

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

Подсказка

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

Высокая доступность

Локальный шлюз является важным компонентом инфраструктуры и должен быть высокодоступен. Однако сбой может произойти и произойдет.

Рассмотрите возможность защиты локального шлюза от нарушений.

Подсказка

При установке с помощью Helm, для обеспечения высокой доступности планирования, включите параметр конфигурации highAvailability.enabled.

Дополнительные сведения см. в статье "Развертывание локального шлюза в Kubernetes с помощью Helm".

Защита от сбоя узла

Чтобы предотвратить последствия из-за сбоев центра обработки данных или узлов, рекомендуется использовать кластер Kubernetes, использующий availability zones для обеспечения высокой доступности на уровне узла.

Зоны доступности позволяют планировать развертывание пода локального шлюза на узлах, распределённых по зонам, используя:

Замечание

Если вы используете Azure Kubernetes Service,см. Настройка зон доступности в Azure Kubernetes Service.

Защита от нарушения работы pod

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

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

Прокси-сервер HTTP(S)

Локальный шлюз обеспечивает поддержку прокси-сервера HTTP(S) с помощью традиционных переменных среды HTTP_PROXY, HTTPS_PROXY и NO_PROXY.

После настройки локальный шлюз автоматически использует прокси-сервер для всех исходящих запросов HTTP(S) к внутренним службам.

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

  • Инспектор API показывает дополнительные шаги, когда используется прокси-сервер HTTP(S) и его связанные взаимодействия.
  • Подробные журналы предоставляются для демонстрации поведения прокси-сервера запросов.

Замечание

Из-за известной проблемы с HTTP-прокси-серверами, использующими базовую проверку подлинности: проверка отзыва сертификатов (CRL) не поддерживается. Сведения о правильной настройке см. в справочнике по параметрам локального шлюза.

Предупреждение

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

Локальные журналы и метрики

Локальный шлюз отправляет данные телеметрии в Azure Monitor и Azure Application Insights в соответствии с параметрами конфигурации в связанной службе API Management. Когда соединение к Azure временно теряется, поток данных для Azure прерывается и данные теряются во время сбоя.

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

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

Пространства имен Kubernetes помогают разделить один кластер между несколькими командами, проектами или приложениями. Пространства имен предоставляют область действия для ресурсов и имен. Они могут быть связаны с квотой ресурсов и политиками access control.

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

Количество реплик

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

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

Производительность

Мы рекомендуем уменьшить уровень журналов контейнеров до уровня предупреждений (warn) для повышения производительности. Дополнительные сведения см. в справочнике по конфигурации локального шлюза.

Ограничение скорости запросов

Регулирование запросов в локальном шлюзе можно включить с помощью политики API Management rate-limit или rate-limit-by-key. Настройте количество ограничений скорости для синхронизации между экземплярами шлюза и узлами кластера путем открытия следующих портов в развертывании Kubernetes для обнаружения экземпляров:

  • Порт 4290 (UDP) для синхронизации ограничения скорости
  • Порт 4291 (UDP) для отправки пульса другим экземплярам

Замечание

Количество ограничений скорости в локальном шлюзе можно настроить для синхронизации локально (между экземплярами шлюза между узлами кластера), например с помощью развертывания диаграмм Helm для Kubernetes или использования шаблонов Azure portal deployment. Однако количество ограничений скорости не синхронизируется с другими ресурсами шлюза, настроенными в экземпляре API Management, включая управляемый шлюз в облаке.

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

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

Ниже приведен пример контекста безопасности для контейнера локального шлюза:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Предупреждение

Запуск локального шлюза с файловой системой только для чтения (readOnlyRootFilesystem: true) не поддерживается.

Предупреждение

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

Связанный контент

  • Last updated on