Как у вас реализована балансировка в kubernets

Наша стратегия балансировки в Kubernetes

Наша инфраструктура Kubernetes построена на многоуровневом подходе к балансировке, который сочетает L4-балансировку на границе кластера с L7-роутингом внутри через Ingress-контроллеры. Мы используем несколько инструментов в зависимости от контекста.

1. Балансировка внешнего трафика (Edge Load Balancing)

Для входящего трафика извне кластера мы используем Cloud Load Balancer (Managed Service от нашего облачного провайдера), который направляет трафик на NodePort или LoadBalancer сервисы Kubernetes. Это позволяет равномерно распределять нагрузку между нодами.

Конфигурация сервиса типа LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: my-app

Для критически важных сервисов мы настраиваем health checks на уровне облачного балансировщика, чтобы автоматически исключать нездоровые ноды.

2. Балансировка внутреннего трафика (Ingress-контроллер)

Внутри кластера мы развернули NGINX Ingress Controller как основной инструмент L7-балансировки. Он позволяет:

• Маршрутизировать трафик на основе домена, пути или заголовков
• Реализовывать SSL/TLS termination
• Настраивать сложные правила балансировки

Пример конфигурации Ingress-ресурса:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api/(.*)
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

3. Service Mesh для сложных сценариев

Для микросервисных приложений с особыми требованиями к маршрутизации мы внедрили Istio как Service Mesh решение. Это дает нам:

• Продвинутые алгоритмы балансировки (least connections, round robin, random)
• Canary deployments и постепенный rollout
• Circuit breaking и retry policies
• Distributed tracing и мониторинг

Конфигурация DestinationRule для балансировки в Istio:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 10

4. Балансировка на уровне сервисов Kubernetes

Стандартные Kubernetes Services обеспечивают базовую балансировку через kube-proxy, который использует iptables или IPVS для распределения трафика между подами.

Мы предпочитаем режим IPVS для production-кластеров из-за:

• Более эффективного хэширования (меньшая нагрузка на CPU)
• Поддержки различных алгоритмов балансировки
• Лучшей масштабируемости при большом количестве сервисов

Проверка текущего режима:

kubectl get configmap kube-proxy -n kube-system -o yaml | grep -i mode

5. Мониторинг и оптимизация

Для мониторинга балансировки мы используем:

• Prometheus + Grafana для метрик нагрузки и ошибок
• Kiali для визуализации трафика в Service Mesh
• Кастомные дашборды для отслеживания распределения трафика между зонами доступности

Ключевые принципы нашей реализации:

1. Многоуровневая защита: Отказ на одном уровне компенсируется другими
2. Зональное распределение: Поды распределяются по разным зонам доступности
3. Автоматическое масштабирование: Horizontal Pod Autoscaler и Cluster Autoscaler
4. Гибкая настройка: Разные стратегии для разных типов сервисов
5. Безопасность по умолчанию: Network Policies и mTSS в Service Mesh

Такая архитектура позволяет нам обрабатывать пиковые нагрузки до 50k RPS с задержкой менее 100ms для 95-го перцентиля, обеспечивая при этом высокую доступность и отказоустойчивость сервисов.