Kubernetes Gateway API v1.0: Стоит ли переходить?

Navendu Pottekkat

Navendu Pottekkat

December 15, 2023

Ecosystem

Прошло более месяца с момента выпуска Kubernetes Gateway API версии 1.0, что ознаменовало переход к статусу общедоступности для некоторых ключевых API.

Я писал о Gateway API, когда он перешел в бета-версию в прошлом году, но спустя год вопрос остается актуальным. Стоит ли переходить с Ingress API на Gateway API?

Мой ответ из прошлого года был отрицательным. И у меня были веские причины.

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

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

С выпуском версии 1.0 это может измениться. Gateway API стал гораздо более функциональным, и его 20+ реализаций быстро догоняют.

Поэтому, если вы начинаете с нуля и выбираете между Ingress и Gateway API, я рекомендую выбрать Gateway API, если API и выбранная вами реализация поддерживают все необходимые вам функции.

Что не так с Ingress API?

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

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

Эти специфичные для реализации аннотации также сложны в управлении и противоречат цели управления Ingress в Kubernetes-ориентированном стиле.

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

Gateway API стремится раз и навсегда решить эту проблему, предоставляя независимость от поставщиков, как у Ingress API, и гибкость CRD. Он хорошо позиционирован для достижения этой цели.

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

Очевидные преимущества

Выразительность, расширяемость и ориентация на роли — это ключевые идеи, которые сформировали развитие Gateway API.

В отличие от Ingress API, Gateway API представляет собой набор нескольких API (HTTPRoute, Gateway, GatewayClass и т.д.), каждый из которых ориентирован на разные роли в организации.

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

Gateway API

Эта ориентированная на роли архитектура API позволяет разным людям использовать кластер, сохраняя контроль.

Gateway API также гораздо более функционален, чем Ingress API. Функции, которые требуют аннотаций в Ingress API, поддерживаются "из коробки" в Gateway API.

Официальное расширение

Хотя Gateway API является официальным API Kubernetes, он реализован как набор CRD.

Это ничем не отличается от использования стандартных ресурсов Kubernetes. Но вам просто нужно установить эти CRD как официальное расширение.

Поддержка Gateway API в APISIX

Это позволяет быстро итерировать по сравнению с Kubernetes, который медленно движется к долгосрочной стабильности.

Будет ли он распространяться?

Как часто напоминает нам этот известный комикс XKCD, стандарты имеют тенденцию к распространению.

Версия этого наблюдалась в Ingress и Gateway API. Обычно это происходит так:

  1. Появляется стандарт для объединения различных проектов/их стандартов (Kubernetes Ingress API).
  2. Унифицированный стандарт имеет ограничения, которые хотят преодолеть разработчики (Ingress API был ограничен).
  3. Реализации отклоняются от стандарта из-за этих ограничений (Пользовательские CRD, аннотации).
  4. Каждая реализация теперь имеет свой собственный стандарт (непереносимые CRD, аннотации).
  5. Появляется новый стандарт для объединения этих различных стандартов (Kubernetes Gateway API).

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

Опять же, у меня есть веские причины.

Широкое распространение критически важно для предотвращения распространения стандартов, так как у реализаций меньше стимулов работать над другим стандартом. Gateway API уже имеет более 25 реализаций.

Реализация может соответствовать Gateway API на разных уровнях:

  1. Основной: Все реализации должны соответствовать этим требованиям.
  2. Расширенный: Эти функции могут быть доступны только в некоторых реализациях, но являются стандартными API.
  3. Специфичные для реализации: Специфичны для реализаций, но добавлены через стандартные точки расширения.

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

Проект Service Mesh Interface (SMI) был аналогичной попыткой стандартизировать настройку сервисных сеток в Kubernetes. Однако проект получил мало внимания после первоначального участия проектов сервисных сеток и постепенно угас.

SMI не поддерживал многие общие функции, которые пользователи ожидали от сервисной сетки. Он также не двигался достаточно быстро, чтобы поддерживать эти функции. В конечном итоге реализации сервисных сеток отстали в соответствии с SMI (я работал в тесном сотрудничестве с SMI в рамках CNCF TAG Network над проектом, который сообщал о соответствии SMI).

Это универсальные причины, но проект теперь возрождается через Gateway API. Инициатива Gateway API for Mesh Management and Administration (GAMMA) направлена на расширение Gateway API для работы с сервисными сетками.

Проект SMI недавно объединился с инициативой GAMMA, что отлично для Gateway API. Istio, несомненно, самая популярная сервисная сетка, также объявила, что Gateway API будет стандартным API для управления Istio в будущем. Такие внедрения предотвращают распространение.

Руководство по миграции

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

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

Возьмем простой ресурс Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

Это будет направлять весь трафик с указанным адресом хоста на сервис httpbin.

Чтобы преобразовать его в ресурс Gateway API, мы можем выполнить:

ingress2gateway print --input_file=ingress.yaml

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

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

Жизнеспособные альтернативы

Существуют другие жизнеспособные альтернативы для настройки шлюзов в Kubernetes.

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

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

В любом случае, Gateway API здесь, чтобы остаться.

Tags:
Gateway API
Kubernetes