Почему Jiakaobaodian выбирает контроллер APISIX Ingress

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

Предыстория

Компания Wuhan Mucang Technology Co., Ltd была основана в 2011 году, и ее основными продуктами являются десятки автомобильных приложений, таких как Jiakaobaodian. С момента основания более 10 лет назад компания следовала технологическим трендам и начала внедрять облачные технологии в 2019 году, а различные проекты компании перешли на Kubernetes.

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

Проблемы с NGINX Ingress Controller

Сервисы в компании используют протоколы HTTP и TCP, и только инженеры по эксплуатации точно знают, как настроить TCP-прокси через NGINX Ingress Controller. Однако ресурсы эксплуатации ограничены. Было бы лучше, если бы мы передали часть базовых операций и конфигураций NGINX команде разработчиков, чтобы сэкономить затраты на эксплуатацию.

Кроме того, мы столкнулись со следующими проблемами:

Некоторые изменения конфигурации требуют перезагрузки;
TCP-прокси имеет высокую стоимость использования и не может охватить все сценарии для различных типов трафика;
Маршрутизация или операции с трафиком могут быть определены только через annotations, и мы не можем семантически определять и повторно использовать конфигурации;
Переписывание, разрыв цепи, перенаправление запросов и другие операции реализуются через annotations;
Отсутствие платформы управления, и сотрудникам эксплуатации приходится работать через YAML, что может привести к ошибкам;
Плохая переносимость;
Не способствует интеграции с контейнерной платформой.

По этим причинам мы решили заменить наш прежний Ingress Controller на новый.

Почему APISIX Ingress Controller

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

Хорошая расширяемость;
Поддержка горячей перезагрузки конфигурации;
Высокая производительность;
Множество плагинов;
Поддержка CRD для интеграции с собственной контейнерной платформой.

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

Теперь давайте рассмотрим всю архитектуру шлюза. В реальном бизнес-сценарии пользователи сначала перенаправляют трафик через SLB (Server Load Balancer), и когда трафик попадает в K8s, каждый сервис вызывается через кластер APISIX. Мы также реализуем множество общих функций (канареечные выпуски, управление потоком, разрыв цепи API, управление безопасностью трафика, управление запросами/ответами и т.д.) на стороне шлюза, чтобы унифицировать управление сервисами, снизить сложность бизнеса и сэкономить затраты.

Диаграмма архитектуры

Метод развертывания

Наш бизнес развернут на различных облачных платформах (Huawei Cloud, Tencent Cloud, Alibaba Cloud), и мы можем быстро вывести наш бизнес в онлайн через Helm Chart, который поддерживается APISIX Ingress Controller. При использовании APISIX Ingress Controller, если мы находим функции, которые можно улучшить, мы также отправляем PR, чтобы помочь сообществу обновлять и итерировать функции. В процессе реального развертывания мы настроили некоторые конфигурации в соответствии с особенностями нашего бизнеса, например:

Создание NameSpace через K8s, развертывание APISIX и APISIX Ingress Controller в разных NameSpace и разделение трафика по продуктовым линиям и важности сервисов;
Оптимизация параметров ядра Linux TCP в initContainer APISIX;
Поскольку нам нужно разделять трафик по продуктовым линиям и важности сервисов, необходимо настроить информацию о ClassName в K8s.

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

Интеграция с собственной контейнерной платформой с использованием CRD

APISIX Ingress Controller в настоящее время поддерживает множество ресурсов CRD, поэтому мы можем использовать ресурсы CRD для интеграции APISIX Ingress Controller с нашей собственной контейнерной платформой. Однако, поскольку APISIX не предоставляет Java Client, нам нужно использовать инструмент генерации кода, предоставленный K8s, для создания Model и использовать CustomObjectApi для управления CRD. Объекты ApisixRoute связаны с приложениями контейнерной платформы и структурированы с основными объектами, что позволяет как сотрудникам эксплуатации, так и менеджерам проектов работать в контейнерной платформе.

Сценарии применения

Аутентификация

До использования Apache APISIX мы реализовали аутентификацию на основе шлюза Istio, а после перехода на Apache APISIX мы выбрали использование плагина forward-auth, который переносит логику аутентификации и авторизации на внешний сервис аутентификации. Запрос пользователя перенаправляется на сервис аутентификации через шлюз, и когда сервис аутентификации отвечает статусом, отличным от 20x, исходный запрос блокируется, и результат заменяется. Таким образом, можно вернуть пользовательский отчет об ошибке или перенаправить пользователя на страницу аутентификации, если аутентификация не удалась.

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

Управление потоком

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

Поэтому мы используем плагины APISIX limit-conn, limit-req и limit-count для ограничения запросов и предотвращения лавинных сбоев. Ограничение потока и скорости проще реализовать путем изменения плагинов, и благодаря механизму горячей перезагрузки APISIX нет необходимости перезапускать плагины при их настройке, поэтому они вступают в силу сразу. Контролируя трафик, можно также остановить некоторые злонамеренные атаки и защитить безопасность системы. Мы также реализовали HPA (Horizontal Pod Autoscaler) на платформе K8s, который автоматически масштабируется вверх и вниз, если объем трафика слишком большой или слишком маленький, с плагинами ограничения потока и скорости APISIX, чтобы остановить массовые сбои.

Наблюдаемость

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

С плагином kafka-logger журналы доступа и ошибок, генерируемые APISIX, могут быть записаны непосредственно в кластер Apache Kafka. Благодаря этому преимуществу кластер APISIX может масштабироваться горизонтально и без состояния, без необходимости форматирования дисков, ротации журналов или выполнения других операций. Если журналы хранятся локально, нам нужно выполнять дополнительные операции, и мы не можем достичь быстрого масштабирования. Отправляя журналы в кластер Apache Kafka, мы также можем анализировать журналы в реальном времени и улучшать и оптимизировать систему на основе результатов анализа.

Заключение

Поскольку APISIX Ingress Controller только что был запущен, пока не так много сценариев применения. Мы продолжим углубляться в сценарии применения и предоставлять больше примеров использования сообществу.

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