Почему APISIX Ingress Controller лучше, чем NGINX Ingress Controller?

Ingress предоставляет доступ к сервисам в Kubernetes, где маршрутизация трафика управляется правилами, настроенными на ресурсе Ingress. Для работы с Ingress также необходим Ingress controller.

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

• Ingress-NGINX — это Ingress контроллер, реализованный сообществом Kubernetes и широко используемый в сообществе.
• APISIX Ingress controller использует Apache APISIX, проект с открытым исходным кодом под эгидой ASF (Apache Software Foundation), в качестве своей плоскости данных.

Ingress NGINX vs. APISIX Ingress

Сравнение функций

В таблице ниже сравниваются основные функции Ingress NGINX и APISIX Ingress, включая протоколы, проверки работоспособности/устойчивости, стратегии балансировки нагрузки, аутентификацию, интеграцию с Kubernetes и т.д. Таблица взята с learnk8s.io.

Различия

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

Обнаружение сервисов

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

Поддержка протоколов

Хотя оба Ingress поддерживают протоколы HTTP/HTTPS, APISIX поддерживает больше протоколов. Он поддерживает TLS для шифрования TCP-трафика. Также поддерживаются MQTT, Dubbo и kafka для проксирования.

Проверки работоспособности/устойчивости

Проверки здоровья

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

Функциональность проверки здоровья пока не поддерживается в Ingress NGINX, но APISIX Ingress предоставляет эту возможность:

• Активная проверка: Используйте пробы, чтобы убедиться, что Pods в бэкенде здоровы. Если N последовательных проб, отправленных на узел, завершаются неудачей, узел будет помечен как нездоровый. Балансировщик нагрузки будет игнорировать нездоровые узлы, чтобы они не могли получать запросы. Включение активных проверок здоровья может эффективно отключать нездоровые Pods, чтобы избежать потери трафика.
• Пассивная проверка: Пассивная проверка здоровья не требует дополнительных проб. Каждый запрос, отправленный на узел, действует как проба. Если N последовательных запросов к здоровому узлу завершаются неудачей, узел будет помечен как нездоровый. Поскольку невозможно заранее определить состояние узла, может быть некоторое количество неудачных запросов. Такая ситуация часто возникает во время обновлений, и мы можем использовать понижение уровня сервиса, чтобы избежать большого количества неудачных запросов.

Пример настройки проверок здоровья для сервиса httpbin в APISIX Ingress:

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

Автоматический выключатель

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

Как и функциональность проверки здоровья, функциональность автоматического выключателя не поддерживается в Ingress NGINX. В APISIX Ingress плагин api-breaker помогает реализовать это.

Пример настройки автоматического выключателя в APISIX Ingress:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

Поддержка большего количества плагинов и методов аутентификации

Ingress NGINX в основном использует Annotations и ConfigMap для настройки, и поддерживаемые плагины относительно ограничены. Если вы хотите использовать JWT, HAMC или другие методы аутентификации, вам придется интегрировать их самостоятельно.

APISIX Ingress поддерживает 80+ плагинов в APISIX изначально, включая такие методы аутентификации, как JWT, HAMC, wolf-rbac и т.д. Эти плагины предоставляют широкий спектр функциональности, охватывающей большинство сценариев использования.

Пример аутентификации HMAC на маршруте APISIX:

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

Расширяемость Ingress NGINX и APISIX Ingress

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

Как Ingress NGINX расширяет свои функции

Ingress NGINX может быть расширен только путем встраивания Lua-программ.

Пример разработки плагина для Ingress NGINX:

1. Напишите Lua-программу example-plugin
2. Установите плагин в /etc/nginx/lua/plugins/<your plugin name> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin в pod ingress-nginx
3. Включите example-plugin в ConfigMap и ссылайтесь на этот объект ConfigMap при установке Ingress NGINX

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

Как APISIX Ingress расширяет свои функции

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

• Разработку плагинов через Lua: просто и практически без потери производительности
• Разработку через plugin-runner: поддерживаются языки программирования, такие как JAVA/Python/Go, что позволяет пользователям настраивать свои плагины без изучения новых языков
• Плагины через WASM: любой язык, поддерживающий сборку WASM, может быть использован для разработки плагинов

Кроме того, вы можете напрямую писать Lua-код через плагин serverless, чтобы быстро удовлетворить бизнес-потребности.

Почему APISIX Ingress поддерживает CustomResourceDefinition (CRD)?

В настоящее время APISIX Ingress поддерживает три декларативные конфигурации: Ingress, CRD и Gateway API. Мы в основном сравним Ingress и CRD здесь. А Gateway API будет рассмотрен позже.

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

• Простота использования, так как он больше соответствует семантике проектирования плоскости данных
• Повторное использование конфигураций для уменьшения избыточности
• Улучшенная функциональность и расширяемость
• Плоскость данных APISIX имеет активное сообщество, быстрые обновления и выпуски, и CRD может легко поддерживать больше возможностей плоскости данных

Проблема Ingress NGINX: Отсутствие поддержки горячей перезагрузки

Проблемы, вызванные статической конфигурацией

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

Ситуации, вызывающие перезагрузку NGINX

• Создание нового ресурса Ingress
• Добавление раздела TLS к существующему Ingress
• Изменение аннотаций Ingress может также повлиять на конфигурацию upstream (например, аннотации балансировки нагрузки не требуют перезагрузки)
• Добавление или удаление пути в Ingress
• Удаление ресурсов Ingress, Service или Secret
• Обновление Secret

Перечисленные выше ситуации охватывают большинство сценариев использования Ingress контроллера. В кластерной среде с частыми развертываниями приложений операции (создание, обновление, удаление и т.д.) ресурсов, таких как Ingress и Secret, будут постоянно запускаться. Это приведет к резкому увеличению количества перезагрузок NGINX, что значительно повлияет на производственную среду.

Архитектура Ingress NGINX определяет, что он должен сначала генерировать конфигурацию NGINX и перезагружать ее для завершения обновления конфигурации. Проблема перезагрузки не может быть решена без изменения архитектуры. Чтобы решить эту проблему, APISIX Ingress больше не зависит от конфигурации NGINX в своей реализации маршрутизации и перешел на чисто память-ориентированную архитектуру. Динамическая маршрутизация реализована через горячую перезагрузку, и NGINX больше не нужно перезапускать.

Gateway API

Преимущества Kubernetes Gateway API

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

• Ролевой: Gateway состоит из API ресурсов. Разные API ресурсы представляют разные роли для использования и настройки сетевых ресурсов Kubernetes

• Сильная выразительность: Gateway API поддерживает базовую функциональность, включая сопоставление на основе заголовков, взвешивание трафика и другие возможности, которые были доступны в Ingress только через нестандартные аннотации

• Расширяемость: Gateway API позволяет связывать разные ресурсы на различных уровнях API. Это позволяет детально настраивать структуру API

Статус поддержки Gateway API

Kubernetes Gateway API является стандартом для расширения сервисной сетки Kubernetes. Его ресурс Gateway может использоваться как Kubernetes API для управления жизненным циклом шлюза, что очень мощно. Многие Ingress контроллеры активно поддерживают его, включая Istio, Kong, Traefik и т.д. К сожалению, Ingress NGXIN пока не планирует поддерживать Gateway API (Статус реализации Gateway API), тогда как APISIX Ingress уже поддерживает большинство функций Gateway API: включая HTTPRoute, TCPRoute, TLSRoute, UDPRoute и т.д.

Итог

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

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

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