#Обзор

#Понимание сетевого взаимодействия

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

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

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

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

Реализация:

• Service Discovery

  • Pods регистрируются в центральном реестре (например, etcd)
  • Services запрашивают реестр, чтобы найти доступные экземпляры
  • Kubernetes CoreDNS обеспечивает встроенное обнаружение через имена service

• Load Balancing

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

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

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

Реализация:

• Ingress

  • Входная точка кластера для внешнего HTTP/HTTPS-трафика
  • Маршрутизация на основе host/path
  • Завершение SSL

• Service Mesh (Istio, Linkerd)

  • Canary Releases: направлять определенный процент трафика на новые версии
  • Fault Injection: имитировать сбои сервисов для тестирования отказоустойчивости
  • Timeouts, Retries & Circuit Breaking: повышать устойчивость к сбоям
  • Traffic Mirroring: копировать production traffic в тестовые среды

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

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

Реализация:

• Network Policies

  • Правила, аналогичные firewall, для взаимодействия Pod
  • Определяют, какие Pods могут взаимодействовать друг с другом
  • Пример: "Только frontend Pods могут получать доступ к backend database Pods"

• Mutual TLS (mTLS)

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

#Наблюдаемость

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

Реализация:

• Непрерывная видимость

  • Собирайте cluster-wide network flow logs с помощью NetObserv
  • Обогащайте записи потоков Kubernetes metadata
  • Храните данные и выполняйте запросы к ним для устранения неполадок и аудита

• Диагностика по запросу

  • Используйте CLI для захвата потоков или пакетов для краткосрочного анализа
  • Поддерживайте интерактивный просмотр в режиме TUI или фоновые задачи захвата
  • Экспортируйте результаты для автономных инструментов анализа, таких как Wireshark

• Типичные сценарии использования

  • Выявление разорванных соединений, узких мест с задержками и неожиданных маршрутов трафика
  • Проверка взаимодействия service-to-service и обнаружение аномалий
  • Расследование инцидентов как по сводным потокам, так и по необработанным пакетам

Подробнее см. Наблюдаемость сети.

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

Container network — это комплексное сетевое решение, предназначенное для cloud-native приложений. Оно обеспечивает бесперебойное east-west взаимодействие внутри кластеров и эффективное управление north-south трафиком во внешних сетях, а также предоставляет основные сетевые функции. Оно состоит из следующих ключевых компонентов:

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

#Gateway API

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

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

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

#Gateway API для Ingress

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

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

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

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

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

Также стоит отметить другие возможности:

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

Для более подробного описания Gateway API обратитесь к документации Gateway API.

#Сравнение Service, Ingress, Gateway API

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

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

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

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

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

• Переадресация трафика выполняется непосредственно ядром Linux (iptables/IPVS/eBPF)
• Минимальные накладные расходы и производительность, близкая к нативной

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

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

#Gateway API TCP/UDP Routes

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

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

Недостатки:

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

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

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

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

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

Хотя Ingress и Gateway API могут публиковать трафик L7 наружу, их возможности различаются.

#Ingress

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

#Gateway API (рекомендуется)

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

1. Ориентированная на роли архитектура

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

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

   • Богатые правила сопоставления: HTTP headers, query parameters, methods и т. д.
   • Ingress ограничен сопоставлением по host и path
   • Встроенная поддержка разделения трафика, mirroring и расширенных политик

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

   • Нативная поддержка HTTP, HTTPS, TCP, UDP, gRPC и TLS passthrough
   • Ingress в первую очередь ориентирован только на HTTP/HTTPS

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

   • Точки расширения с проверкой типов через CRDs (например, HTTPRoute filters, policy attachments)
   • Ingress сильно зависит от vendor-specific annotations, что приводит к проблемам с портируемостью

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

   • Routes могут ссылаться на Services в разных Namespace (с помощью ReferenceGrant)
   • Ingress обычно ограничен ссылками в пределах одного Namespace

6. Несколько listeners на Gateway

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

7. Портируемость и стандартизация

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

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

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

В настоящее время мы поддерживаем Gateway API через Envoy Gateway. Для миграции с Ingress на Gateway API обратитесь к migration guide

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

Пример потока сетевого трафика через кластер 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. Client (Browser / curl).

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

2. DNS Resolution.

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

3. [L4] External Load Balancer.

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

4. [L7] Envoy Gateway / Ingress Controller.

   Работает на уровне 7 (Application Layer). Обрабатывает:

   • TLS termination

   • Маршрутизацию по hostname и path

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

   Он маршрутизирует трафик к соответствующему Kubernetes Service.

5. [L4] Kubernetes Service (ClusterIP)

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

6. Pod (Application)

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