#Обзор

#Понимание сетевых взаимодействий

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

Обязанности облачной сетевой инфраструктуры можно разделить на несколько ключевых областей:

#Обнаружение сервисов и балансировка нагрузки

Обязанность: Автоматически обнаруживать запущенные экземпляры микросервисов и интеллектуально распределять трафик между ними.

Реализация:

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

  • Подключение Pod к центральному реестру (например, etcd)
  • Сервисы запрашивают реестр для поиска доступных экземпляров
  • Kubernetes CoreDNS обеспечивает встроенное обнаружение по именам сервисов

• Балансировка нагрузки

  • Ресурсы Kubernetes Service получают виртуальный IP (VIP)
  • Выступают в роли встроенного балансировщика нагрузки для backend Pod (Endpoints)
  • Равномерно распределяют запросы между экземплярами

#Управление трафиком и маршрутизация

Обязанность: Управлять трафиком с помощью тонко настроенных правил для реализации продвинутых схем развертывания.

Реализация:

• Ingress

  • «Входные ворота» кластера для внешнего HTTP/HTTPS трафика
  • Маршрутизация на основе хоста и пути
  • Завершение SSL

• Service Mesh (Istio, Linkerd)

  • Canary Releases: Направление процента трафика на новые версии
  • Fault Injection: Симуляция сбоев сервисов для тестирования устойчивости
  • Тайм-ауты, повторные попытки и circuit breaking: Повышение отказоустойчивости
  • Traffic Mirroring: Копирование производственного трафика в тестовые среды

#Сетевая безопасность

Обязанность: Обеспечивать модель безопасности «Zero Trust» для авторизованного взаимодействия сервисов.

Реализация:

• Network Policies

  • Правила, похожие на firewall, для коммуникации Pod
  • Определяют, какие Pod могут взаимодействовать друг с другом
  • Пример: «Только frontend Pod могут обращаться к backend database Pod»

• Mutual TLS (mTLS)

  • Шифрует и аутентифицирует все сервис-сервис взаимодействия
  • Обеспечивает безопасность данных и проверку идентичности
  • Широко используется в service mesh

#Основные сетевые уровни и компоненты

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

• Container Network Interfaces (CNI) для управления восточно-западным трафиком внутри кластера.
• Ingress Gateway Controller ALB (устаревший), NGINX Ingress Controller или Envoy Gateway (рекомендуется) для управления HTTPS входящим трафиком.
• MetalLB для обработки сервисов типа LoadBalancer.
• Дополнительно обеспечивает надежные функции сетевой безопасности и шифрования для обеспечения безопасного взаимодействия.

#GatewayAPI

Gateway API — официальный проект Kubernetes, ориентированный на маршрутизацию уровней L4 и L7 в Kubernetes. Этот проект представляет собой следующее поколение API для Ingress, балансировки нагрузки и service mesh в Kubernetes. С самого начала он был разработан как универсальный, выразительный и ориентированный на роли.

Общая модель ресурсов сосредоточена на 3 отдельных ролях и соответствующих ресурсах, которыми они должны управлять:

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

#Gateway API для Ingress

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

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

#Концепции Gateway API

Следующие цели проектирования определяют концепции Gateway API. Они демонстрируют, как Gateway стремится улучшить существующие стандарты, такие как Ingress.

• Ориентация на роли — Gateway состоит из API-ресурсов, моделирующих организационные роли, которые используют и настраивают сетевое взаимодействие Kubernetes.
• Портативность — это не улучшение, а требование сохранить универсальность. Как и Ingress, являющийся универсальной спецификацией с множеством реализаций, Gateway API разработан как переносимая спецификация, поддерживаемая многими реализациями.
• Выразительность — ресурсы Gateway API поддерживают основные функции, такие как сопоставление по заголовкам, взвешивание трафика и другие возможности, которые в Ingress были возможны только через пользовательские аннотации.
• Расширяемость — Gateway API позволяет связывать пользовательские ресурсы на различных уровнях API, что обеспечивает детальную настройку в соответствующих местах структуры API.

Некоторые другие заметные возможности включают:

• GatewayClasses — формализуют типы реализаций балансировки нагрузки. Эти классы позволяют пользователям легко и явно понимать, какие возможности доступны через модель ресурсов Kubernetes.
• Общие шлюзы и поддержка кросс-namespace — позволяют совместно использовать балансировщики нагрузки и VIP, разрешая независимым ресурсам Route подключаться к одному Gateway. Это позволяет командам (даже из разных Namespace) безопасно делить инфраструктуру без прямой координации.
• Типизированные маршруты и типизированные backend — Gateway API поддерживает типизированные ресурсы Route и различные типы backend. Это позволяет API быть гибким в поддержке различных протоколов (HTTP, gRPC) и различных целей backend (Kubernetes Services, хранилища, функции).

Для более подробного описания Gateway API, пожалуйста, обратитесь к документации gateway-api.

#Сравнение между Service, Ingress, Gateway API

Платформа Alauda Container Platform поддерживает несколько спецификаций входящего трафика в экосистеме Kubernetes. Этот документ сравнивает их (Service, Ingress, Gateway API), чтобы помочь пользователям сделать правильный выбор.

#Для трафика L4 (TCP/UDP)

Как сервисы типа LoadBalancer, так и Gateway API (TCP/UDP Routes) могут открывать трафик уровня 4 наружу. Однако они значительно отличаются по подходу к реализации и характеристикам производительности.

#LoadBalancer Service (Рекомендуется)

Реализация: Пересылка в пространстве ядра

• Пересылка трафика осуществляется напрямую ядром Linux (iptables/IPVS/eBPF)
• Минимальные накладные расходы и почти нативная производительность

Преимущества:

• Высокая производительность с низкой задержкой
• Меньшее потребление CPU и памяти
• Проверенная и зрелая технология

#Gateway API TCP/UDP Routes

Реализация: Прокси в пространстве пользователя

• Реализовано через Envoy Gateway (или другие контроллеры шлюзов)
• Трафик должен проходить из пространства ядра в пространство пользователя и обратно
• Дополнительные накладные расходы на обработку на уровне приложения

Недостатки:

• Снижение производительности по сравнению с решениями в пространстве ядра
• Более высокое потребление ресурсов (CPU/память)
• Дополнительная задержка из-за переключения контекста в пространство пользователя

#Рекомендация

Рекомендуется использовать сервисы типа LoadBalancer для маршрутизации трафика L4 из-за их превосходной производительности и меньших накладных расходов.

В настоящее время мы поддерживаем сервисы типа LoadBalancer через MetalLB.

#Для трафика L7 (HTTP/HTTPS)

Ingress, GatewayAPI и другие могут открывать трафик уровня 7 наружу, но отличаются по функциональности.

#Ingress

Ingress — стандартная спецификация, принятая сообществом Kubernetes и рекомендуемая для использования по умолчанию. Ingress обрабатывается экземплярами ALB, которыми управляет администратор платформы.

#GatewayAPI (Рекомендуется)

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

1. Ориентация на роли

   • Четкое разделение обязанностей: администратор инфраструктуры (GatewayClass, Gateway) и разработчик приложений (Routes)
   • Ingress смешивает инфраструктурные и прикладные аспекты в одном ресурсе

2. Выразительные возможности маршрутизации

   • Богатые правила сопоставления: HTTP-заголовки, параметры запроса, методы и др.
   • Ingress ограничен сопоставлением по хосту и пути
   • Встроенная поддержка разделения трафика, зеркалирования и продвинутых политик

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

   • Родная поддержка HTTP, HTTPS, TCP, UDP, gRPC и TLS passthrough
   • Ingress в основном ориентирован на HTTP/HTTPS

4. Расширяемость

   • Типобезопасные точки расширения через CRD (например, фильтры HTTPRoute, прикрепление политик)
   • Ingress сильно зависит от аннотаций конкретных поставщиков, что снижает портативность

5. Маршрутизация между Namespace

   • Маршруты могут ссылаться на сервисы в разных namespace (с ReferenceGrant)
   • Ingress обычно ограничен ссылками в пределах одного namespace

6. Несколько слушателей на Gateway

   • Один Gateway может обрабатывать несколько портов, протоколов и доменных имен
   • Ingress обычно требует отдельного ресурса для каждой конфигурации

7. Портативность и стандартизация

   • Независимый от поставщика API с тестами соответствия
   • Снижает привязку и улучшает совместимость между реализациями
   • Реализации Ingress сильно различаются по возможностям и аннотациям

8. Модель прикрепления и выбора

   • Маршруты явно прикрепляются к слушателям Gateway через parentRefs
   • Более ясные связи и упрощённое устранение неполадок
   • Ingress использует IngressClass, который менее гибок

В настоящее время мы поддерживаем GatewayApi через Envoygateway. Для миграции с ingress на gatewayapi смотрите руководство по миграции.

#Поток сетевого трафика

Пример потока сетевого трафика через кластер Alauda Container Platform.

External Client (Browser / curl) https://www.example.com
   │
   ▼
DNS Resolution (https://www.example.com) → IP (e.g. 34.23.88.11)
   │
   ▼
External Load Balancer [L4]
   │
   ▼
Envoy Gateway / Ingress NGINX Controller [L7]
   │
   ▼
Kubernetes Service (ClusterIP) [L4]
   │
   ▼
Pod (Application)

Объяснение потока:

1. Клиент (Browser / curl).

   Пользователь отправляет HTTPS-запрос на https://www.example.com. Клиент работает на уровне 7, инициируя DNS-запрос.

2. Разрешение DNS.

   DNS преобразует доменное имя в публичный IP-адрес (например, 34.23.88.11).

3. [L4] Внешний балансировщик нагрузки.

   Работает на уровне 4 (TCP/UDP). Перенаправляет входящие подключения на backend-ноды кластера. Примеры: AWS NLB, GCP TCP LB, MetalLB.

4. [L7] Envoy Gateway / Ingress Controller.

   Работает на уровне 7 (Прикладной уровень). Обрабатывает:

   • Завершение TLS

   • Маршрутизацию по имени хоста и пути

   • Политики и аутентификацию

   Направляет трафик к соответствующему Kubernetes Service.

5. [L4] Kubernetes Service (ClusterIP)

   Выступает как внутренний балансировщик нагрузки уровня 4 внутри кластера. Распределяет запросы на backend Pod на основе селекторов.

6. Pod (Приложение)

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