APISIX Ingress Controller интегрируется с Service Discovery

Требуется ли Service Discovery в облачных приложениях?

Предыстория

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

Эти компоненты должны динамически взаимодействовать, чтобы хорошо работать вместе. Обычно необходимо внедрить инструменты для обнаружения сервисов. Мы написали статью, в которой рассказываем о Service Discovery в микросервисах: Что такое Service Discovery в микросервисах - API7.ai.

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

Service Discovery в Kubernetes

В среде Kubernetes поды (pods) являются минимальной единицей развертывания.

В Kubernetes компонентам сложнее взаимодействовать друг с другом, так как IP-адрес пода не является постоянным и часто меняется.

Поэтому при развертывании приложений в Kubernetes еще важнее адаптироваться к этой динамической среде.

Kubernetes учитывает это требование и предоставляет собственный механизм обнаружения сервисов на основе DNS.

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

Каждому Service назначается постоянный ClusterIP. Таким образом, когда IP-адрес пода изменяется, другие компоненты все еще могут взаимодействовать через фиксированный ClusterIP Service.

В то же время сервис в Kubernetes автоматически обновляет A/AAAA запись в DNS кластера.

Запись выглядит следующим образом:

my-svc.my-namespace.svc.cluster-domain.example

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

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

Поэтому, если вы хотите снизить затраты на преобразование, необходимо сохранить исходный механизм обнаружения сервисов.

При этом условии, как лучше всего экспонировать сервисы, недавно перенесенные в Kubernetes?

Как APISIX Ingress работает с Service Discovery?

APISIX Ingress — это реализация Ingress-контроллера в Kubernetes. Он использует Apache APISIX в качестве плоскости данных и поддерживает настройку правил прокси через Ingress, пользовательские CRD и Gateway API. В то же время он также предоставляет интеграцию с инструментами для обнаружения сервисов, что позволяет легко проксировать зарегистрированные сервисы и экспонировать их клиенту.

Мы подробно объясним это в этом разделе.

Поддержка Service Discovery в APISIX

APISIX — это высокопроизводительный, полностью динамический облачный API-шлюз, который предоставляет более 80 встроенных плагинов, охватывающих большинство сценариев использования.

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

APISIX может быть интегрирован со следующими инструментами для обнаружения сервисов:

Consul
DNS
Eureka
Nacos

Просто добавьте следующую конфигурацию в файл конфигурации APISIX (в качестве примера используется DNS):

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # используйте реальный адрес вашего DNS-сервера

Таким образом, при настройке upstream APISIX может динамически разрешать фактическую информацию об адресе upstream через Service Discovery и проксировать запрос.

Как это делает APISIX Ingress?

APISIX Ingress использует APISIX в качестве компонента прокси плоскости данных. При первой интеграции с Service Discovery мы рассмотрели два варианта.

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

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

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

Как использовать APISIX Ingress?

Сначала убедитесь, что в конфигурации APISIX включена правильная конфигурация для обнаружения сервисов. В качестве примера используется DNS:

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

Создайте ресурс ApisixUpstream и измените его конфигурацию, связанную с discovery, в соответствии с вашим сценарием использования. Например, здесь заданы type: dns и serviceName, который нужно проксировать:

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

Наконец, создайте ресурс ApisixRoute, у которого upstreams ссылается на только что созданный ресурс ApisixUpstream:

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

После правильного создания вышеуказанных ресурсов вы можете получить доступ к httpbin.default.svc.cluster.local, зарегистрированному в DNS, через local.httpbin.org.

how client make requests

Преимущества и перспективы

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

Спасибо за чтение. Мы продолжаем работать над созданием APISIX Ingress, чтобы предоставить лучший пользовательский опыт!

Для получения дополнительной информации об API-шлюзах посетите наш блог или свяжитесь с нами.