Сравнение Kubernetes Gateway и Ingress API
October 21, 2022
Несколько месяцев назад новый Kubernetes Gateway API перешел в бета-версию.
Зачем вам нужен еще один API для обработки внешнего трафика, если у вас есть стабильный Kubernetes Ingress API и десятки реализаций? Какие проблемы Ingress API решает новый Gateway API? Означает ли это конец Ingress API?
Я постараюсь ответить на эти вопросы в этой статье, рассмотрев эти API на практике и изучив их эволюцию.
Стандартизация внешнего доступа к сервисам: Ingress API
Kubernetes Ingress API был создан для стандартизации предоставления доступа к сервисам в Kubernetes для внешнего трафика. Ingress API преодолел ограничения стандартных типов сервисов, таких как NodePort и LoadBalancer, добавив такие функции, как маршрутизация и SSL-терминация.
Существует более 20 реализаций Ingress-контроллеров. В этой статье я буду использовать Apache APISIX и его Ingress-контроллер для примеров.
Вы можете создать ресурс Ingress для настройки APISIX или любой другой реализации Ingress.
Пример ниже показывает, как можно маршрутизировать трафик между двумя версиями приложения с помощью APISIX Ingress:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: api-routes spec: ingressClassName: apisix rules: - host: local.navendu.me http: paths: - backend: service: name: bare-minimum-api-v1 port: number: 8080 path: /v1 pathType: Prefix - backend: service: name: bare-minimum-api-v2 port: number: 8081 path: /v2 pathType: Prefix
Совет: Вы можете ознакомиться с этим практическим руководством, чтобы узнать больше о настройке Ingress в Kubernetes с использованием Apache APISIX Ingress-контроллера.
Поскольку Ingress API не привязан к какой-либо конкретной реализации контроллера, вы можете заменить APISIX на любой другой Ingress-контроллер, и он будет работать аналогично.
Это подходит для простой маршрутизации. Но API ограничен, и если вы хотите использовать все функции, предоставляемые вашим Ingress-контроллером, вам придется использовать аннотации.
Например, Kubernetes Ingress API не предоставляет схему для настройки перезаписи URL. Перезапись полезна, когда URL вашего бэкенда отличается от пути, настроенного в вашем правиле Ingress.
APISIX поддерживает эту функцию, и вам нужно использовать пользовательские аннотации для ее использования:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: api-routes annotations: k8s.apisix.apache.org/rewrite-target-regex: "/app/(.*)" k8s.apisix.apache.org/rewrite-target-regex-template: "/$1" spec: ingressClassName: apisix rules: - host: local.navendu.me http: paths: - backend: service: name: bare-minimum-api port: number: 8080 path: /app pathType: Prefix
Это создает ресурс Ingress, который настраивает APISIX для маршрутизации всех запросов с префиксом /app на бэкенд с удаленным префиксом. Например, запрос к /app/version будет перенаправлен на /version.
Аннотации специфичны для выбранного вами Ingress-контроллера. Эти "проприетарные" расширения ограничивают изначально задуманную портативность Ingress API.
Пользовательские CRD > Ingress API
Использование аннотаций также снижает удобство использования Ingress-контроллеров.
Поэтому контроллеры решили ограничения Ingress API, создав собственные пользовательские ресурсы. Пример ниже показывает настройку Ingress для маршрутизации трафика между двумя версиями приложения с использованием пользовательского ресурса APISIX:
apiVersion: apisix.apache.org/v2 kind: ApisixRoute metadata: name: api-routes spec: http: - name: route-1 match: hosts: - local.navendu.me paths: - /v1 backends: - serviceName: bare-minimum-api-v1 servicePort: 8080 - name: route-2 match: hosts: - local.navendu.me paths: - /v2 backends: - serviceName: bare-minimum-api-v2 servicePort: 8081
Эти CRD значительно упростили настройку Ingress, но вы привязаны к конкретной реализации Ingress-контроллера. Без эволюции Ingress API вам приходилось выбирать между удобством использования и портативностью.
Расширение Ingress и эволюция до Gateway API
Ingress API не был сломан; он был ограничен. Gateway API был разработан для преодоления этих ограничений.
(Gateway API) стремится развивать сетевое взаимодействие сервисов Kubernetes через выразительные, расширяемые и ролевые интерфейсы ...
Он вдохновлен пользовательскими CRD различных Ingress-контроллеров, упомянутых ранее.
Gateway API добавляет много функций "поверх" возможностей Ingress API. Это включает в себя маршрутизацию на основе HTTP-заголовков, взвешенное разделение трафика и другие функции, которые требуют использования пользовательских аннотаций в Ingress API.
Разделение трафика с использованием ресурса APISIX Ingress (см. ApisixRoute/v2 reference):
apiVersion: apisix.apache.org/v2 kind: ApisixRoute metadata: name: traffic-split spec: http: - name: rule-1 match: hosts: - local.navendu.me paths: - /get* backends: - serviceName: bare-minimum-api-v1 servicePort: 8080 weight: 90 - serviceName: bare-minimum-api-v2 servicePort: 8081 weight: 10
Разделение трафика с использованием Gateway API (см. Canary traffic rollout):
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: traffic-split spec: hostnames: - local.navendu.me rules: - backendRefs: - name: bare-minimum-api-v1 port: 8080 weight: 90 - name: bare-minimum-api-v2 port: 8081 weight: 10
Еще одно улучшение по сравнению с Ingress API — это то, как Gateway API разделяет обязанности. В Ingress разработчик приложения и оператор кластера работают с одним и тем же объектом Ingress, не осознавая обязанностей друг друга, что открывает двери для ошибок конфигурации.
Gateway API разделяет конфигурации на объекты Route и Gateway, предоставляя автономию разработчику приложения и оператору кластера. На диаграмме ниже это объясняется более подробно:
Это конец Ingress API?
Gateway API относительно новый, и его реализации постоянно меняются. Напротив, Ingress API находится в стабильной версии и прошел испытание временем.
Если ваш случай использования включает только простую маршрутизацию, и вы готовы использовать пользовательские аннотации для получения дополнительных функций, Ingress API по-прежнему остается надежным выбором.
Поскольку Gateway API является надмножеством Ingress API, возможно, имеет смысл объединить их. Благодаря сообществу SIG Network, Gateway API продолжает развиваться и скоро будет готов к использованию в production.
Большинство Ingress-контроллеров и сервисных сеток уже реализовали Gateway API вместе с Ingress API, и по мере развития проекта появятся новые реализации.
Лично я, по крайней мере на данный момент, предпочел бы использовать пользовательские CRD, предоставляемые Ingress-контроллерами, такими как Apache APISIX, вместо Ingress или Gateway API.