Поделиться через

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

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

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

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

Маркер доступа

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

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

Подсказка

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

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

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

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

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

Это возможно с помощью собственных функций Kubernetes или с помощью автомасштабирования на основе событий Kubernetes (KEDA). KEDA — инкубационный проект CNCF, который стремится упростить автомасштабирование приложений.

Замечание

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

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

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

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

Подсказка

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

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

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

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

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

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

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

Замечание

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

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

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

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

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

Подсказка

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

Узнайте подробнее о том, как установить локальный шлюз Управления API в Kubernetes с помощью Helm.

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

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

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

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

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

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

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

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

Замечание

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

Политика DNS

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

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

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

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

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

Проверка состояния здоровья

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

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

Подсказка

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

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

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

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

Подсказка

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

Узнайте подробнее о том, как установить локальный шлюз Управления API в Kubernetes с помощью Helm.

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

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

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

Замечание

Если вы используете службу Azure Kubernetes, узнайте, как использовать зоны доступности в этой статье.

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

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

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

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

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

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

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

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

Замечание

Из-за известной проблемы с использованием базовой проверки подлинности в прокси-серверах HTTP не поддерживается проверка отзыва сертификатов (CRL). Дополнительные сведения см. в разделе "Параметры шлюзаSelf-Hosted ", как правильно настроить его.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечание

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

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

Самостоятельно размещаемый шлюз может выполняться без прав суперпользователя в 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, чтобы управлять сертификатами ЦС; в противном случае шлюз не будет запущен.

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