От Traefik к APISIX: Исследование Horizon Robotics в области Ingress Controller

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

В этом процессе, как обеспечить стабильность и эффективность бизнеса, пока продукт быстро итеративно развивается?

В этой статье мы рассмотрим пример платформы разработки искусственного интеллекта Horizon Robotics, чтобы увидеть, как API-шлюз Apache APISIX и Ingress Controller помогли команде разработчиков Horizon Robotics решить эту проблему.

Сравнение шлюзов

Ограничения Traefik

До использования APISIX Ingress Controller в бизнес-системе использовался Ingress Controller Traefik 1.x, но с ним возникло несколько проблем.

• Traefik 1.x настраивает правила маршрутизации через Ingress, и некоторые плагины нужно настраивать, добавляя Annotation. Таким образом, можно добавлять плагины только для всех правил под текущим Ingress, и невозможно достичь более детальной конфигурации.
• Traefik 1.x не поддерживает визуальную конфигурацию конкретных правил и не позволяет напрямую определить конкретный сервис, обращаясь к URL запроса через браузер.
• Конфигурационный файл по умолчанию Traefik (ConfigMap) имеет мало атрибутов, и многие настройки по умолчанию нужно искать в официальной документации, а некоторые параметры не совпадают с конфигурацией по умолчанию NGINX, что делает обслуживание более сложным.

В ответ на эти проблемы техническая команда Horizon Robotics решила заменить Ingress Controller. В начале процесса выбора команда рассматривала возможность обновления Traefik до версии 2.0 для решения вышеуказанных проблем, но поскольку также требовалось использовать новый CRD для обновления, а стоимость миграции была высока, пришлось рассмотреть другие решения Ingress Controller.

Преимущества APISIX Ingress Controller

На начальном этапе выбора мы в основном сравнивали Apache APISIX, Kong и Envoy. Однако другие решения в большей или меньшей степени не удовлетворяли потребности существующих сценариев с точки зрения функциональности или производительности, за исключением APISIX Ingress. Поэтому мы в итоге выбрали APISIX Ingress. Помимо некоторых общих функций, нас больше всего заинтересовали следующие моменты.

• Богатые плагины: Плагины экологически устойчивы, и все плагины, поддерживаемые APISIX, можно настроить декларативно с помощью apisix-ingress-controller, а плагины можно настраивать для отдельных бэкендов под ApisixRoute.
• Визуальная конфигурация: С помощью APISIX Dashboard можно видеть каждый apisix route. И если один и тот же домен настроен в нескольких namespaces или YAML-файлах, можно искать префикс пути в сочетании с APISIX Dashboard, чтобы быстро найти его в случае конфликта.
• Детальная проверка: APISIX Ingress Controller проверяет ресурсы, объявленные в CRD, которыми он управляет. Если в CRD объявлен несуществующий сервис, сообщение об ошибке будет сохранено в event ApisixRoute, и изменение не вступит в силу, что может уменьшить некоторые проблемы, вызванные неправильным использованием.
• Богатые функции: APISIX поддерживает горячее обновление и горячие плагины, перезапись прокси-запросов, множественную аутентификацию, разработку плагинов на нескольких языках и многие другие функции. Подробнее см. APISIX features.
• Активное сообщество: По сравнению с сообществами других открытых решений, APISIX имеет много активных участников и контрибьюторов на Slack, GitHub и в списке рассылки.
• Высокая производительность: Как видно из графика ниже, производительность APISIX примерно на 120% выше, чем у Envoy, при сравнении с нагрузочным тестом Envoy, и чем больше ядер, тем больше разница в QPS.

Общая архитектура

Как видно из архитектурной схемы ниже, APISIX Ingress служит точкой входа для всего трафика. Весь входящий трафик попадает в вышестоящие сервисы (бизнес-сервисы) через APISIX Ingress, будь то из командной строки, веб-интерфейса, SaaS-платформ или OpenAPI. Что касается аутентификации, поскольку в компании есть собственный сервис аутентификации, он напрямую использует плагин forward-auth APISIX для внешней аутентификации.

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

Сценарии

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

Загрузка больших файлов

Первый сценарий — загрузка больших файлов, что может быть менее распространено в обычных компаниях, но более часто встречается в компаниях, занимающихся обучением моделей ИИ. Этот сценарий в основном используется в системе обучения моделей Horizon Robotics, где данные, собранные разработчиками, загружаются в систему через сеть, и размер данных обычно превышает несколько сотен ГБ, и при слишком большом объеме загружаемых данных без настройки параметров APISIX может произойти OOM.

Поскольку значение по умолчанию client_body_buffer_size составляет 1 МБ, когда буфер заполняется, временные файлы записываются на диск, что приводит к высокой нагрузке на диск.

Если каталог, в который записываются временные файлы, указывает на общую память (/dev/shm), это снова приводит к высокой нагрузке на APISIX (кэш).

После непрерывной отладки мы обнаружили, что причина заключалась в том, что APISIX не поддерживал потоковую загрузку. Для этого сценария мы обновили версию APISIX с 2.11 до 2.13 и настроили параметры APISIX. Во-первых, мы изменили параметр proxy_request_buffering на off в APISIX ConfigMap, чтобы включить потоковую загрузку. Во-вторых, мы извлекли повторно используемую конфигурацию из CRD ApisixPluginConfig, предоставляемого APISIX Ingress Controller, и динамически установили client_max_body_size для маршрутов, требующих этого сценария, как конфигурацию уровня namespace.

Вызовы сервисов в мультиоблачных средах

Для вызовов сервисов в мультиоблачных средах часть бизнес-трафика сначала поступает в локальный IDC, а затем через APISIX Ingress попадает в Pod. Некоторые сервисы в Pod обращаются к сервисам AliCloud через доменное имя. Кроме того, существуют сценарии, где сервис вызывает другие сервисы, в основном для мультиоблачного обучения. Пользователи будут использовать IDC как точку входа и выбирать кластер для отправки задачи в соответствующий облачный кластер.

Внешняя аутентификация с forward-auth

Когда мы начали использовать APISIX Ingress, APISIX не поддерживал плагин forward-auth, поэтому мы определили пользовательский плагин на основе apisix-go-plugin-runner, но это создало дополнительный уровень вызовов gRPC, что затруднило отладку и сделало логирование невидимым. Поскольку APISIX начал поддерживать плагин forward-auth в начале этого года, мы заменили пользовательский плагин на официальный, что уменьшило один уровень вызовов gRPC и сделало мониторинг более удобным.

Мониторинг приложений

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

Итог

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