Envoy Proxy: налаштування circuit breaking, xDS, трасування

Envoy Proxy замість HAProxy: реальний кейс

Ми стикалися з ситуацією, коли HAProxy не справлявся з динамічним виявленням сервісів у Kubernetes. Retries з jitter були недоступні, а конфігурацію доводилося перезавантажувати вручну. Тоді ми впровадили Envoy як data plane — і отримали гнучкість, якої не вистачало. Envoy — це не просто проксі, а повноцінна платформа для мікросервісних архітектур. Він вміє динамічне виявлення upstream-сервісів через xDS API, трасування запитів з коробки, circuit breaking з outlier detection, retries з jitter. І весь конфіг оновлюється без перезапуску. Саме тому Envoy стоїть всередині Istio, Consul Connect та AWS App Mesh. Наші інженери з 5+ роками досвіду та 30+ проєктами в DevOps забезпечують якісне впровадження. Замовте налаштування Envoy для вашої інфраструктури під ключ — вартість розраховується індивідуально. Ми оцінимо ваш проект за 1 день.

Статична конфігурація: запуск без control plane

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

---
# envoy.yaml
static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                codec_type: AUTO
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: backend
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/api/"
                          route:
                            cluster: api_service
                            prefix_rewrite: "/"
                            timeout: 30s
                            retry_policy:
                              retry_on: "5xx,connect-failure"
                              num_retries: 3
                              retry_host_predicate:
                                - name: envoy.retry_host_predicates.previous_hosts
                              host_selection_retry_max_attempts: 3
                        - match:
                            prefix: "/"
                          route:
                            cluster: app_service
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
    - name: api_service
      connect_timeout: 5s
      type: STRICT_DNS
      lb_policy: LEAST_REQUEST
      load_assignment:
        cluster_name: api_service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: api-service
                      port_value: 8080
    - name: app_service
      connect_timeout: 5s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: app_service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: app-service
                      port_value: 3000
              - endpoint:
                  address:
                    socket_address:
                      address: app-service-2
                      port_value: 3000
admin:
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

Запуск через Docker:

docker run -d \
    -p 10000:10000 \
    -p 9901:9901 \
    -v ./envoy.yaml:/etc/envoy/envoy.yaml \
    envoyproxy/envoy:v1.29-latest \
    -c /etc/envoy/envoy.yaml

Circuit breaking: запобігання каскадним відмовам

Зазначимо: коли один сервіс починає гальмувати або падати, клієнти (інші мікросервіси) можуть накопичувати запити в чергах. Це викликає каскадну відмову всієї системи. Circuit breaker в Envoy відстежує стан upstream і зупиняє надсилання запитів до проблемного хоста. Конфігурація:

---
clusters:
  - name: payment_service
    connect_timeout: 2s
    circuit_breakers:
      thresholds:
        - priority: DEFAULT
          max_connections: 1000
          max_pending_requests: 500
          max_requests: 1000
          max_retries: 3
          track_remaining: true
    outlier_detection:
      consecutive_5xx: 5
      interval: 10s
      base_ejection_time: 30s
      max_ejection_percent: 50
      consecutive_gateway_failure: 3
      enforcing_consecutive_5xx: 100

Outlier Detection: якщо хост видає 5 помилок 5xx поспіль, він ежектується з пулу на 30 секунд. Після цього Envoy надсилає пробний запит — при успіху хост повертається.

Як outlier detection підвищує відмовостійкість?

Outlier detection в Envoy відстежує не тільки 5xx, а й gateway failures, connection failures, а також час відповіді. При перевищенні порогу хост виключається з балансування на заданий час. Це запобігає каскадним збоям і знижує MTTR на 40% у порівнянні з HAProxy. Envoy надає готове рішення з налаштуванням через YAML — без ручного скриптування.

Порівняння з альтернативами: Envoy проти HAProxy та nginx

Envoy надає в 3 рази більше метрик, ніж nginx, але поступається HAProxy за сирою продуктивністю (~200k req/s на ядро проти ~300k). Однак гнучкість і спостережуваність роблять його кращим для складних мікросервісних мереж. Circuit breaking в Envoy працює в 2 рази ефективніше, ніж ручне рішення на HAProxy.

Для індивідуального проєкту зв'яжіться з нами — ми підготуємо оцінку за 1 день.

Envoy як sidecar у Kubernetes

Класичний патерн — Envoy поруч із кожним pod:

---
# kubernetes deployment (фрагмент)
spec:
  containers:
    - name: app
      image: myapp:latest
      ports:
        - containerPort: 8080
    - name: envoy
      image: envoyproxy/envoy:v1.29-latest
      args:
        - "-c"
        - "/etc/envoy/envoy.yaml"
      ports:
        - containerPort: 10000
          name: proxy
        - containerPort: 9901
          name: admin
      volumeMounts:
        - name: envoy-config
          mountPath: /etc/envoy
  volumes:
    - name: envoy-config
      configMap:
        name: envoy-config

Без Istio sidecar налаштовується вручну. З Istio Envoy інжектується автоматично через MutatingWebhookConfiguration, конфігурація прилітає від Istiod через xDS.

Як xDS спрощує управління конфігурацією?

Для продакшн-інфраструктури з десятками сервісів статичний конфіг не масштабується. xDS API дозволяє control plane (Consul, Pilot в Istio) динамічно оновлювати конфігурацію без перезапуску:

---
# envoy-dynamic.yaml — тільки bootstrap, решта через xDS
dynamic_resources:
  lds_config:
    resource_api_version: V3
    api_config_source:
      api_type: GRPC
      transport_api_version: V3
      grpc_services:
        - envoy_grpc:
            cluster_name: xds_cluster
  cds_config:
    resource_api_version: V3
    api_config_source:
      api_type: GRPC
      transport_api_version: V3
      grpc_services:
        - envoy_grpc:
            cluster_name: xds_cluster
static_resources:
  clusters:
    - name: xds_cluster
      connect_timeout: 5s
      type: STATIC
      load_assignment:
        cluster_name: xds_cluster
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: control-plane.example.com
                      port_value: 18000

З xDS можна змінювати маршрути, додавати upstream-сервіси та оновлювати політики без перезапуску. Це особливо важливо для canary-деплоїв та A/B тестування.

Що входить в роботу (deliverables)

• Аудит поточної архітектури та проєктування конфігурації.
• Реалізація статичного або динамічного конфігу з circuit breaking, outlier detection, retries та трасуванням.
• Інтеграція з control plane (Istio, Consul) або standalone.
• Навантажувальне тестування та оптимізація.
• Дашборди Prometheus + Grafana.
• Runbook по експлуатації.
• Навчання команди (2 години).
• Підтримка 2 тижні після здачі.

Процес впровадження Envoy

Ми працюємо поетапно:

1. Аудит поточної архітектури (1-2 дні).
2. Проєктування конфігурації з урахуванням circuit breaking та трасування.
3. Реалізація на staging з навантажувальним тестуванням.
4. Деплой на production з поступовим перемиканням трафіку.
5. Документація та навчання команди.

В результаті ви отримуєте готову інфраструктуру Envoy (статичну або через xDS), інтеграцію з Istio, Consul або іншим control plane, моніторинг та алертинг (Prometheus + Grafana, дашборди), runbook по експлуатації та підтримку 2 тижні після здачі. Сертифіковані інженери з 5+ роками досвіду та 30+ проєктами гарантують стабільність та продуктивність.

Терміни та вартість

Отримайте консультацію — зв'яжіться з нами, і ми підготуємо попередню оцінку вашого проекту під ключ.