В современном Service Mesh Envoy — это основная рабочая сила, а Istio — генерал, который командует армией прокси-серверов. Каждый сервис получает свой персональный Envoy (sidecar), а Istio через control plane раздает этим Envoy указания: кого пускать, кого блокировать, как балансировать нагрузку.

Когда микросервис хочет поговорить с соседом, его запрос сначала попадает в локальный Envoy. Тот сверяется с картой маршрутов от Istio и принимает решение: пропустить запрос, перенаправить на другую версию сервиса или вообще отклонить. Такая архитектура превращает сеть микросервисов в управляемую структуру — какие бы правила не придумал оператор, они моментально распространяются на все прокси.

Вот пример базовой конфигурации Envoy для обработки входящего HTTP-трафика:

static_resources:
  listeners:
  - name: http_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    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
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: local_service
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  
  clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: local_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8081

А вот как настраивается более продвинутая конфигурация с retry policy и circuit breaker:

clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    circuit_breakers:
      thresholds:
        - priority: DEFAULT
          max_connections: 1000
          max_pending_requests: 1000
          max_requests: 1000
          max_retries: 3
    retry_policy:
      retry_on: connect-failure,refused-stream,unavailable
      num_retries: 3
      per_try_timeout: 1s
    load_assignment:
      cluster_name: local_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8081

В финальной конфигурации часто добавляют health checks и outlier detection:

clusters:
  - name: local_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    health_checks:
      - timeout: 1s
        interval: 5s
        unhealthy_threshold: 3
        healthy_threshold: 1
        http_health_check:
          path: "/health"
    outlier_detection:
      consecutive_5xx: 5
      base_ejection_time: 30s
      max_ejection_percent: 50

Роль Envoy в этой схеме сложно переоценить. Он не просто пробрасывает трафик, а собирает детальную телеметрию: латентность запросов, коды ответов, размеры payload. Все эти данные стекаются в центральную систему мониторинга, позволяя видеть полную картину взаимодействия сервисов.

В итоге Service Mesh на базе Istio и Envoy — это как операционная система для микросервисов. Разработчикам не нужно думать о network resilience, service discovery или сборе метрик. Все эти задачи делегированы инфраструктурному слою. А значит, команды могут сфокусироваться на бизнес-логике, не изобретая велосипеды для базовых сетевых операций.

🏴‍☠️ @happy_devops