Архитектурное решение для маршрутизации трафика с поддержкой WebSockets и защитой от DDoS В Kubernetes для маршрутизации трафика часто используется Network Load Balancer (NLB). Этот тип балансировщика обладает высокой скоростью обработки запросов, поддерживает большое количество маршрутов на доменные имена, а также позволяет передавать IP-адреса пользователей в заголовках HTTP-запросов при настройке параметра: externalTrafficPolicy: Local Однако, при защите от DDoS-атак с использованием сервиса Qrator возникла проблема несовместимости с поддержкой WebSockets, что требовало пересмотра архитектурного решения для корректной работы WebSocket-соединений. Архитектурное решение Для решения этой проблемы вынес поддомен, обслуживающий WebSocket-соединения, на Application Load Balancer (ALB). ALB поддерживает облачную защиту SmartWeb, которая эффективно противостоит DDoS-атакам и корректно работает с WebSockets. Этапы реализации 1. Настройка внутренних балансировщиков нагрузки Чтобы разделить трафик между фронтендом и бэкендом, создаются два внутренних балансировщика нагрузки. Они работают как промежуточный слой маршрутизации, который обеспечивает передачу трафика от внешнего ALB к соответствующим сервисам в кластере Kubernetes. Эти балансировщики доступны только из внутренней сети и недоступны извне, что обеспечивает дополнительный уровень безопасности. Пример конфигурации внутреннего балансировщика для бэкенд-сервиса: apiVersion: v1 kind: Service metadata: name: websocketslbback annotations: # Тип балансировщика. yandex.cloud/load-balancer-type: internal # Идентификатор подсети для внутреннего сетевого балансировщика нагрузки. yandex.cloud/subnet-id: e9bic***** spec: type: LoadBalancer loadBalancerIP: 10.200.0.253 # указываем диапазон внутренних ip адресов относящихся к сервисам externalTrafficPolicy: Local selector: app: myapp tier: backend-test ports: - port: 443 targetPort: 5000 Этот балансировщик принимает входящий трафик от ALB и направляет его на соответствующие backend-поды. 2. Настройка внешнего балансировщика нагрузки (ALB) Далее создается внешний ALB через консоль Яндекс.Облака, который обслуживает входящий трафик из интернета. Этот балансировщик играет роль основного маршрутизатора трафика и корректно обрабатывает WebSocket-соединения. Параметры конфигурации ALB: А) Зоны доступности: Указываются зоны, в которых будет развернут ALB, чтобы обеспечить отказоустойчивость. Б) Публичный IP-адрес: ALB получает публичный IP-адрес, позволяющий принимать трафик из внешних сетей. В) Порт: ALB работает на порту 443 (HTTPS) для шифрования трафика. Г) SSL-сертификат: Для шифрования трафика. Д) HTTP-роутер: Маршрутизация осуществляется через HTTP-роутер, который анализирует входящие запросы по доменному имени и пути и перенаправляет их на соответствующие внутренние балансировщики. 3. Маршрутизация через HTTP-роутер ALB использует HTTP-роутер для маршрутизации входящего трафика: А) Виртуальные хосты: В HTTP-роутере настраиваются виртуальные хосты с указанием доменных имен и путей, на которые будет направляться трафик. Это позволяет эффективно разделять трафик между разными сервисами на основе URL-запросов. Б) Поддержка WebSockets: Включается поддержка WebSockets для виртуальных хостов, отвечающих за обработку WebSocket-трафика. 4. Настройка групп бэкендов HTTP-роутер перенаправляет трафик на внутренние балансировщики, используя группы бэкендов. В этих группах указываются: А) Порт, на который отправлять трафик. Б) Целевая группа, представляющая внутренний балансировщик, который распределяет трафик по бэкенд-подам внутри Kubernetes. Таким образом, это решение объединяет преимущества как NLB, так и ALB, создавая надежную и гибкую инфраструктуру для маршрутизации трафика в Kubernetes, с учетом особенностей WebSocket-трафика и требований безопасности. #DevOps