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

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

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

Важно!

Поддержка образов контейнеров azure Управление API локальных шлюзов версии 0 и 1 заканчивается 1 октября 2023 г. вместе с соответствующим API конфигурации версии 1. Используйте наше руководство по миграции , чтобы использовать локальный шлюз версии 2.0.0 или более поздней версии с API конфигурации версии 2. Дополнительные сведения см. в документации по устареению.

Доступность

Важно!

Эта функция доступна в ценовых категориях Премиум и Разработка управления API.

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

Совет

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

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

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

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

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

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

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

Примечание

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

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

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

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

Можно загрузить полный список доступных тегов.

Совет

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

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

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

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

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

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

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

Личные доменные имена и SSL-сертификаты

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

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

Примечание

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

Политика DNS

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

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

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

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

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

Высокий уровень доступности

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

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

Совет

При установке с помощью 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-запросов к внутренним службам.

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

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

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

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

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

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

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

Дальнейшие действия