Учебное пособие по Kubernetes Gateway API: замена Ingress на Cilium Gateway для HTTP-трафика

---

Введение

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

Представьте, что вы работаете над растущей платформой Kubernetes, где вам необходимо:

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

Здесь Kubernetes Gateway API меняет ваш подход к сетевому взаимодействию сервисов. Являясь следующим этапом развития после Ingress, Gateway API предоставляет ориентированный на роли, расширяемый и нейтральный к производителям способ управления HTTP и HTTPS трафиком в кластерах Kubernetes.

Вы изучите Gateway API, используя Cilium Gateway на DigitalOcean Kubernetes (DOKS), что означает отсутствие необходимости в развертывании дополнительных контроллеров и нативную интеграцию CNI.

В этом обширном руководстве вы узнаете о основах Gateway API и реализуете готовый к производству HTTP-сервис с расширенными возможностями маршрутизации, используя нативную поддержку Gateway от Cilium.

Ключевые выводы

Этот всесторонний учебник по API шлюза Kubernetes охватывает все, от основных понятий до развертывания в производственной среде:

Основные концепции и архитектура

• Gateway API против Ingress Controller: Поймите основные различия и когда переходить от традиционного Ingress
• Реализация Cilium Gateway: Используйте нативную поддержку Cilium в DOKS для развертывания API Gateway с нулевыми затратами.
• Модель Ресурсов на Основе Ролей: Разделение Master GatewayClass, Gateway и HTTPRoute для улучшения сотрудничества в команде

Практическая реализация

• Маршрутизация HTTP-трафика: Настройте маршрутизацию на основе пути, соответствие заголовкам и фильтрацию параметров запроса
• Современное управление трафиком: Реализация разделения трафика, балансировки нагрузки и маршрутизации между пространствами имен
• Запуск производства: Настройка интеграции DNS с ExternalDNS и правильное обнаружение сервисов

Лучшие практики и оптимизация

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

Предварительные требования: Базовые знания Kubernetes и работающий кластер DOKS. Новичок в Kubernetes? Начните с нашего руководства по основам Kubernetes.

Предварительные условия

Перед началом этого руководства убедитесь, что у вас есть:

• Работающий VPC Native кластер DigitalOcean Kubernetes (версия 1.33+)
• kubectl установлен и настроен для общения с вашим кластером
• Установлены CRD API шлюза (DOKS включает Cilium, который поддерживает это по умолчанию)
• Зарегистрированное имя домена и доступ к DNS

Обратите внимание, что в домене dolearn.xyz используются в примерах, обязательно замените эти ссылки на ваш собственный домен.

Почему Gateway API? Лучший способ обработки HTTP маршрутизации

Если вы работали с Kubernetes Ingress, вы, вероятно, ощутили его ограничения. Хотя Ingress открыл путь для экспонирования HTTP(S) нагрузок, он быстро проявил свои недостатки:

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

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

Здесь вступает в дело Gateway API. Разработанный Kubernetes SIG-Network как следующая эволюция сетевого сервиса, он предлагает ориентированную на роли, портативную и расширяемую модель для маршрутизации трафика.

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

Ключевые преимущества Gateway API над Ingress**

1. Богатая, выразительная маршрутизация

Перейдите за простое соответствие хост/путь. Gateway API поддерживает условия заголовков, параметры запроса и взвешенное разделение трафика из коробки, что делает канарейные релизы, A/B тесты и развертывания blue-green полноценными гражданами, а не хаками, спрятанными в аннотациях.

2. Четкое разделение ролей

API шлюза вводит четкое разделение обязанностей с использованием трех видов ресурсов:

• Поставщики инфраструктуры определяют GatewayClass
• Кластерные операторы развертывают Шлюз
• Разработчики определяют HTTPRoute (или другие ресурсы маршрутов, такие как GRPCRoute)

Мы более подробно рассмотрим каждый ресурс позже в этом учебном пособии.

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

3. Готовность к перекрёстным пространствам имен и многопользовательской среде

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

4. Независимый от поставщика и портативный

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

5. Продвинутое управление движением, без аннотационного хаоса

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

Интеграция DOKS и Cilium

В DigitalOcean Kubernetes (DOKS) Cilium является реализацией CNI по умолчанию. Это имеет важные последствия для команд, выбирающих между Ingress и Gateway API:

Если вы продолжите использовать Ingress, вы будете нести ответственность за управление собственным контроллером входящего трафика (NGINX, HAProxy, Traefik и т. д.). Это означает дополнительные затраты — развертывание, поддержание его работоспособности и отслеживание обновлений.

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

Для получения дополнительной информации смотрите наши руководство по настройке кластера DOKS и функциям сетевой связи Cilium.

Структурные элементы API шлюза

GatewayClass

Класс шлюза определяет тип шлюза, который может использовать ваш кластер. Think of it as a шаблон, который говорит Kubernetes как должны вести себя шлюзы. В нашем случае класс шлюза — это Cilium. Класс шлюза создается и управляется DigitalOcean.

Шлюз

Ворота — это экземпляр класса GatewayClass. Они представляют собой фактическую точку входа в ваш кластер, поддерживаемую балансировщиком нагрузки в облачной настройке. Ворота создаются кем-то из команды DevOps или на платформе, обычно это команда, которая управляет кластерами Kubernetes и общей инфраструктурой.

Врата объединяют три основных вещи:

1. ИмяКлассаШлюза

   • Привязывает шлюз к конкретной реализации.

2. Слушатели

   • Это похоже на “пункты въезда” в кластер.

3. Слушатель указывает:

   • Протокол (например, HTTP, HTTPS, TCP, gRPC).
4. Порт (например, 80 или 443).
5. Имя(на) хоста(ов) (например, example.com, *.app.io).
6. TLS терминция (если шлюз должен обрабатывать сертификаты).
7. Правила привязки маршрутов — какие виды маршрутов могут быть связаны здесь.
8. По сути, слушатели — это то, как вы определяете какой тип трафика этот шлюз готов принимать и обрабатывать.

9. Адреса

   • Фактические IP-адреса или фронтенды балансировщика нагрузки, которые предоставляет контроллер Gateway.
10. Это может быть облачный балансировщик нагрузки, кластерный IP или даже просто настройка узлового порта, в зависимости от вашей среды.

HTTP маршруты

Определяет правила маршрутизации HTTP для одного или нескольких сервисов в вашем кластере. HTTPRoutes обычно создаются разработчиками.

HTTPRoute состоит из:

• Ссылки на родителей
  Они определяют, к каким Шлюзам и каким конкретным слушателям на этих Шлюзах данный маршрут может быть прикреплен.

• Имена хостов

  • HTTP маршруты могут сузить круг соответствующих им имен хостов (например, api.example.com, shop.example.com).
• Если несколько маршрутов используют шлюз, имена хостов гарантируют, что трафик направляется к правильному бэкенду.

Правила

• Где происходит совпадение и маршрутизация. Вы можете сопоставлять на основе:

Префиксы пути (/api, /shop)

Заголовки (X-Canary: true).

Параметры запроса.

Фильтры: применяйте преобразования, такие как перенаправления, переписывание заголовков, модификации запросов/ответов или зеркалирование трафика.

BackendRefs: Укажите целевые службы (или бэкенды) с поддержкой распределения трафика с помощью весов.

Тайм-ауты: Управление жизненным циклом запросов с ограничениями (например, тайм-аут запроса).

Давайте развернем образец приложения и откроем его с помощью Шлюза и HTTPRoute.

Шаг 1 — Разверните пример приложения

Выполните эту команду из вашего терминала (убедитесь, что у вас настроен kubectl для подключения к вашему кластеру Kubernetes на DigitalOcean):

kubectl apply      -f https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/platform/kube/bookinfo.yaml 

Применение манифеста bookinfo.yaml запускает четыре микросервиса Bookinfo: productpage, details, reviews и ratings — с ядром

• Сервисы на порту 9080, чтобы сделать каждый микросервис доступным для обнаружения.
• Развертывания для запуска Pods (подробности и оценки имеют v1, productpage имеет v1, а reviews имеют v1, v2 и v3).
• Служебные аккаунты, чтобы дать каждой службе свою собственную личность.

Шаг 2 — Разверните шлюз Cilium

Когда вы создаете Шлюз, вы также решаете, как он будет разделяться:

• Выделенный шлюз: Развернут в том же пространстве имен, что и приложение и его HTTPRoutes. Эта модель хорошо работает, когда каждая команда или приложение владеет своим собственным шлюзом.

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

Для нашего варианта использования давайте создадим выделенный шлюз.

apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata:   name: cilium-gateway-http spec:   gatewayClassName: cilium   listeners:   - protocol: HTTP     port: 80     name: web-gw     allowedRoutes:       namespaces:         from: Same 

шлюз и HTTP Routes приложения находятся в одном пространстве имен. Только команда sample-app может прикреплять маршруты к нему, что обеспечивает изоляцию маршрутизации и предотвращает использование этой точки входа другими командами/пространствами имен.

После применения вышеуказанного манифеста будут созданы два ресурса: шлюз и служба типа LoadBalancer. Обратите внимание, что создание балансировщика нагрузки и отображение его IP-адреса может занять несколько минут.

kubectl get gateways 

NAME                  CLASS    ADDRESS           PROGRAMMED   AGE cilium-gateway-http   cilium   134.209.130.13    True         47m 

kubectl get svc -o wide | grep LoadBalancer 

cilium-gateway-cilium-gateway-http   LoadBalancer   10.108.72.44    138.197.230.74    80:32015/TCP                 50m     <none> 

Шаг 3 — Создайте HTTPRoute

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

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata:   name: http-app-test spec:   parentRefs:   - name: cilium-gateway-http   hostnames:    - "httptest.dolearn.xyz"   rules:   - matches:     - path:         type: PathPrefix         value: /details     backendRefs:     - name: details       port: 9080          - matches:     - headers:       - type: Exact         name: magic         value: foo       queryParams:       - type: Exact         name: great         value: example       path:         type: PathPrefix         value: /       method: GET     backendRefs:     - name: productpage       port: 9080 

Что это делает?

• Ссылки на шлюз

  1. parentRefs указывает на шлюз cilium-gateway-http в таком же пространстве имен.
• Это говорит кластеру, какой шлюз должен обрабатывать эти маршруты.

• Определяет имена хостов

  1. Запросы к httptest.dolearn.xyz будут соответствовать этому HTTPRoute.

• Устанавливает правила маршрутизации
  Первое правило: Запросы с путями, начинающимися с /details, отправляются в сервис details на порту 9080.

  1. Второе правило: Запросы с

     • Заголовок magic: foo
• Параметр запроса great=example
• Путь, начинающийся с /
• Метод GET
  направляется на сервис productpage на порту 9080.

Шаг 4 — Настройка ExternalDNS с DigitalOcean (необязательно)

ExternalDNS автоматизирует управление записями DNS у вашего провайдера (в данном случае, DigitalOcean) на основе ресурсов Kubernetes, таких как Сервисы, Ingress и маршруты Gateway API.

1. Создайте токен API DigitalOcean

Вам понадобится персональный токен доступа с правами на запись для управления записями DNS.

2. Сохраните токен как секрет Kubernetes

Создайте секрет Kubernetes, который ExternalDNS будет использовать для аутентификации с DigitalOcean:

kubectl create secret generic digitalocean-dns    --from-literal=access-token=<YOUR_DIGITALOCEAN_TOKEN> 

3. Добавьте репозиторий Helm ExternalDNS

helm repo add external-dns https://kubernetes-sigs.github.io/external-dns/ helm repo update 

4. Настройка значений для развертывания Helm

env: # Passes the DigitalOcean token from the secret   - name: DO_TOKEN     valueFrom:       secretKeyRef:         name: digitalocean-dns         key: access-token  provider: # ExternalDNS provider configuration   name: digitalocean  policy: sync # Ensures ExternalDNS continuously reconciles DNS records txtOwnerId: gateway-api # Ensures ExternalDNS does not conflict others using this domain  sources: # Kubernetes resources to watch and create DNS records for   - service   - ingress   - gateway-grpcroute   - gateway-httproute 

5. Установите ExternalDNS

Разверните ExternalDNS с помощью Helm:

helm install external-dns external-dns/external-dns -f values.yaml 

6. Проверьте DNS записи

После развертывания ExternalDNS должен автоматически создавать записи DNS для ваших Сервисов/Ingress.

Вы можете проверить по следующим данным:

dig +short httptest.dolearn.xyz 138.197.230.74 

Ссылка: https://kubernetes-sigs.github.io/external-dns/latest/

В качестве альтернативы, вы можете вручную добавить записи DNS: https://docs.linux-console.net/products/networking/dns/how-to/manage-records/

Шаг 5 — Выполнение HTTP-запросов

Теперь, когда шлюз готов, вы можете отправлять HTTP-запросы к приложению, используя сервис.

curl --fail -s http://httptest.dolearn.xyz/details/1 | jq 

{   "id": 1,   "author": "William Shakespeare",   "year": 1595,   "type": "paperback",   "pages": 200,   "publisher": "PublisherA",   "language": "English",   "ISBN-10": "1234567890",   "ISBN-13": "123-1234567890" } 

curl -v -H 'magic: foo' http://httptest.dolearn.xyz?great=example 

* Host httptest.dolearn.xyz:80 was resolved. * IPv6: (none) * IPv4: 134.209.130.13 *   Trying 134.209.130.13:80... * Connected to httptest.dolearn.xyz (134.209.130.13) port 80 > GET /?great=example HTTP/1.1 > Host: httptest.dolearn.xyz > User-Agent: curl/8.7.1 > Accept: */* > magic: foo > * Request completely sent off < HTTP/1.1 200 OK < content-type: text/html; charset=utf-8 < content-length: 1683 < server: envoy < date: Mon, 25 Aug 2025 13:21:59 GMT < x-envoy-upstream-service-time: 8 < <!DOCTYPE html> <html>   <head>     <title>Simple Bookstore App</title> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1">  <!-- Latest compiled and minified CSS --> <link rel="stylesheet" href="static/bootstrap/css/bootstrap.min.css">  <!-- Optional theme --> <link rel="stylesheet" href="static/bootstrap/css/bootstrap-theme.min.css">    </head>   <body>   <p>     <h3>Hello! This is a simple bookstore application consisting of three services as shown below</h3> </p>  <table class="table table-condensed table-bordered table-hover"><tr><th>name</th><td>http://details:9080</td></tr><tr><th>endpoint</th><td>details</td></tr><tr><th>children</th><td><table class="table table-condensed table-bordered table-hover"><tr><th>name</th><th>endpoint</th><th>children</th></tr><tr><td>http://details:9080</td><td>details</td><td></td></tr><tr><td>http://reviews:9080</td><td>reviews</td><td><table class="table table-condensed table-bordered table-hover"><tr><th>name</th><th>endpoint</th><th>children</th></tr><tr><td>http://ratings:9080</td><td>ratings</td><td></td></tr></table></td></tr></table></td></tr></table>  <p>     <h4>Click on one of the links below to auto generate a request to the backend as a real user or a tester     </h4> </p> <p><a href="/productpage?u=normal">Normal user</a></p> <p><a href="/productpage?u=test">Test user</a></p>    <!-- Latest compiled and minified JavaScript --> <script src="static/jquery.min.js"></script>  <!-- Latest compiled and minified JavaScript --> <script src="static/bootstrap/js/bootstrap.min.js"></script>    </body> </html> * Connection #0 to host httptest.dolearn.xyz left intact 

И это всё! Вы успешно развернули образец приложения и выставили его с помощью шлюза и HTTPRoute.

Часто задаваемые вопросы

1. Как использовать Gateway API в Kubernetes?

Чтобы использовать Gateway API в Kubernetes, выполните следующие шаги:

1. Установите CRD API шлюза (автоматически включается в DOKS с Cilium)
2. Разверните контроллер шлюза (Cilium Gateway предустановлен на DOKS)
3. Создайте ресурс GatewayClass (управляемый DigitalOcean)
4. Определите шлюз для точки входа вашего трафика
5. Настроить ресурсы HTTPRoute для маршрутизации, специфичной для приложения

DOKS Advantage: С Cilium в качестве стандартного CNI поддержка Gateway API встроена — дополнительная развертка контроллера не требуется.

2. В чем разница между Gateway API и контроллером Ingress?

Gateway API — это современная эволюция управления трафиком в Kubernetes:

Ограничения входа:

• Аннотации, специфичные для контроллера, для расширенных функций
• Модель единственного ресурса, смешивающая инфраструктурные и прикладные аспекты
• Ограниченная поддержка многопользовательского режима

Преимущества API шлюза:

• Ролевой дизайн: Отдельные ресурсы для инфраструктурных команд ( шлюз) и разработчиков (HTTPRoute)
• Поддержка местных функций: Разделение трафика, сопоставление заголовков, маршрутизация между пространствами имен без аннотаций
• Переносимость поставщиков: Стандартизировано для различных реализаций

3. Могу ли я перейти с Ingress на Gateway API без простоя?

Да! API Gateway поддерживает стратегии постепенной миграции:

1. Параллельное развертывание: Запуск API Gateway вместе с существующими контроллерами Ingress
2. Миграция по сервисам: Перемещайте приложения постепенно
3. Голубо-зеленая миграция: Сначала протестируйте API шлюза с непроизводственным трафиком
4. Разделение трафика: Используйте нативное разделение трафика API Gateway для канареечных развертываний.

Узнайте больше в нашем руководстве по миграции Kubernetes.

4. Как Cilium Gateway сравнивается с другими реализациями API шлюза?

Cilium Gateway предлагает уникальные преимущества на DOKS:

• Нативная интеграция CNI: Нет отдельных контроллеров или дополнительных затрат ресурсов
• Производительность на основе eBPF: Аппаратное ускорение обработки трафика
• Встроенная наблюдаемость: Интегрирована с возможностями мониторинга Cilium
• Автоматическое масштабирование: Масштабируется вместе с узлами вашего кластера без ручной настройки

5. Каковы примеры Gateway API для распространенных случаев использования?

Общие шаблоны реализации API шлюза:

Маршрутная маршрутизация на основе пути:

rules: - matches:   - path:       type: PathPrefix       value: /api   backendRefs:   - name: api-service 

Маршрутизация на основе заголовков:

rules: - matches:   - headers:     - name: "version"       value: "v2"   backendRefs:   - name: api-v2-service 

Разделение трафика:

backendRefs: - name: service-v1   weight: 80 - name: service-v2   weight: 20 

6. Готов ли Gateway API для производственных сред?

Абсолютно! Gateway API получил статус GA и готов к использованию в производстве:

• Стабильное API: v1 API гарантирует обратную совместимость
• Широкое применение: Используется крупнейшими облачными провайдерами и предприятиями
• Активная разработка: Непрерывные улучшения и добавление новых функций
• Сильная экосистема: Увеличивающееся количество реализаций и инструментов

На DOKS: Cilium Gateway полностью поддерживается и рекомендуется для производственных нагрузок.

Заключение

Поздравляю! Вы успешно реализовали готовую к производству настройку Kubernetes Gateway API с Cilium. Вот что вы достигли:

• Развернуты микросервисы Bookinfo с правильным обнаружением службы
• Создан шлюз Cilium, использующий нативную интеграцию CNI DOKS
• Настроенные продвинутые правила HTTPRoute с маршрутизацией на основе пути и заголовков
• Настройте автоматизированное управление DNS с интеграцией ExternalDNS
• Тестировались реальные сценарии движения с несколькими условиями маршрутизации

Следующие шаги

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

• Готовность DOKS к эксплуатации, Часть 2: Включение HTTPS
• Настройте аутентификацию OAuth с внешними провайдерами
• Настройте мониторинг Prometheus для метрик Gateway

Изучите нашу обширную библиотеку учебников по Kubernetes, охватывающую все, от основ до корпоративных паттернов.

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