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

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

  • Статья

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

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

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

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

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

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

Совет

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

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

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

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

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

Это можно реализовать с помощью собственных функций 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<в файле 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 объекта Служба, равным Local. Таким образом, сохраняется IP-адрес вызывающей стороны (доступный в контексте запроса) и отключается балансировка нагрузки между узлами, устраняются сетевые прыжки, возникающие по этой причине. Имейте в виду, что этот параметр может привести к асимметричному распределению трафика в развертываниях с неравным количеством pod-модулей шлюзов на каждый узел.

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

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

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

Совет

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

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

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

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

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

Примечание.

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

Защита от перебоев в работе модулей pod

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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