envoy - ghdrako/doc_snipets GitHub Wiki

Build

https://www.envoyproxy.io/docs/envoy/latest/start/building is included. But the binary file's size is too large, 469MB. Can you figure out how to make it smaller? Any suggestion is appreciated.

bazel --server_javabase=/usr/lib/jvm/java-11-amazon-corretto --host_jvm_args=-Djavax.net.ssl.trustStore=$CI_PROJECT_DIR/keystore.jks --host_jvm_args=-Djavax.net.ssl.trustStorePassword=changeit test  --jobs=16 -c opt --config=sizeopt --copt=-DENVOY_IGNORE_GLIBCXX_USE_CXX11_ABI_ERROR=1 --verbose_failures --distdir=$CI_PROJECT_DIR/ext/ --distdir=$CI_PROJECT_DIR/ext2/ --distdir=$CI_PROJECT_DIR/ext4/ --repository_cache=$CI_PROJECT_DIR/ext --repository_cache=$CI_PROJECT_DIR/ext2 --repository_cache=$CI_PROJECT_DIR/ext4 --linkopt=-Wl,--strip-all //test/...

Yeah, as you see, I built it by gitlab ci, an environment without internet access, downloading external dependencies manually. I put external dependencies in ext, ext2, ext4. And I used llvm.

the easiest/most supported path for compiling is using the docker build container and the bazel targets, ie

$ ./ci/run_envoy_docker.sh './ci/do_ci.sh release.server_only'

which builds optimized, stripped bins for dist targets

the bazel target you are looking for for a single binary (non-contrib) is

$ bazel build ... --stripopt=--strip-all -c opt //source/exe:envoy-static.stripped

lmk if that helps - the dev docs are due some update in the near future

Envoy

Envoy is a programmable L3/L4 and L7 proxy that powers today’s service mesh solutions including Istio, AWS App Mesh, Consul Connect, etc. At Envoy’s core lie several filters that provide a rich set of features for observing, securing, and routing network traffic to microservices.

Envoy exposes a set of APIs that let users and control planes statically and dynamically configure the proxy. By configuring a Listener, users can enable the flow of traffic through the proxy, and then enhance the data flow using several Filters. Using a combination of these filters, Envoy can measure, transform, and perform higher order access control operations.

                     |                                 |
LISTENER <---data--->| |filter|-->|filter|-->|filter|  |<--data--> SERVICE
                     |    filter chain                 |

Listener allows Envoy to listen to network traffic at a configured address. Each Listener then defines a set of filters that sit in the data path, collectively forming a filter chain. By composing and arranging a set of filters, users can configure Envoy to translate protocol messages, generate statistics, perform RBAC, etc. Envoy provides numerous built-in filters, and it also provides APIs to let you create your own!

Types of Filters

Envoy currently provides 3 types of filters that form a hierarchical filter chain.

  • Listener Filters
  • Network Filters
  • HTTP Filters

Listener Filters

Listener Filters access raw data and manipulate metadata of L4 connections during the initial (pre)connection phase. For example, the TLS Inspector Filter identifies if a connection is TLS encrypted and parses the TLS metadata associated with the connection.

Network Filters

Network Filters access and manipulate raw data on L4 connections i.e. TCP packets. For example, the TCP Proxy Filter routes client connection data to upstream hosts, and it also generates connection statistics.

HTTP Filters

HTTP Filters operate at L7 and are optionally created by a final Network filter i.e. the HTTP Connection Manager. These filters access and manipulate HTTP requests and responses. For example, the gRPC-JSON Transcoder Filter exposes a REST API for a gRPC backend and translates requests and responses into corresponding formats.

Benefits of Envoy Filters

As outlined earlier, Envoy filters provide several benefits to users.

  • Firstly, one can create an intermediate layer to handle clients gracefully when communicating with an incompatible server.
  • Next, you can measure the usage of APIs and services in a transparent and consistent manner.
  • Third, the proxy can perform protocol translation, allowing different protocols to interoperate.
  • Yet another benefit is that the proxy can make intelligent routing decisions (e.g. rate limiting) via a filter.
  • Finally, these filters can share data among each other via a mechanism called Filter State. By sharing state, a filter like the MySQL Filter can share information about the resources accessed and the operations performed with another filter like the RBAC Filter to provide a higher-order RBAC solution. Note that the current version of the MySQL filter relies on Dynamic Metadata to share state, which now stands deprecated in favor of Filter State.

Service

$sudo cat /etc/systemd/system/envoy.service
[Unit]
Description=Envoy Proxy
After=network.target

[Service]
User=envoy
Group=envoy
WorkingDirectory=/opt/envoy
ExecStart=/opt/envoy/bin/envoy -c /etc/envoy/envoy.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

Przyklad

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: preserve-external-request-id
  namespace: istio-ingress 
spec:
  workloadSelector:
    labels:
      istio: gateway
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
      patch:
        operation: MERGE
        value:
          typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
            preserve_external_request_id: true
  • Istio ingressgateway to po prostu Envoy proxy uruchomiony jako Deployment (zwykle w namespace istio-system).
  • On odbiera wszystkie przychodzące żądania HTTPS/HTTP do Twojego clustra Kubernetes.
  • Każde żądanie trafiające do ingressgateway przechodzi przez listener w Envoy’u (konfiguracja Envoy).
  • Listener używa filtra http_connection_manager, który odpowiada za obsługę HTTP: nagłówki, routing, tracing itd.
  • Envoy, domyślnie, zawsze ustawia nagłówek x-request-id dla każdego requestu.
  • Flaga preserve_external_request_id: true w http_connection_manager zmienia zachowanie: Jeśli klient przysłał x-request-id → Envoy go zachowa i przekaże dalej (nie wygeneruje nowego).

Ten CRD (EnvoyFilter) mówi:

  • workloadSelector – wybierz Pod’y z etykietą istio: gateway.
  • W namespace istio-ingress. (jeśli tam masz swój ingressgateway).
  • W środku, przez configPatches, szukasz filtra o nazwie envoy.filters.network.http_connection_manager.
  • I doklejasz/mergujesz tam preserve_external_request_id: true.
  • Efekt: konfiguracja filtra http_connection_manager w ingressgateway zmienia się i od tego momentu Envoy przestaje nadpisywać nagłówek x-request-id.

This EnvoyFilter config is enabling preserve_external_request_id for your Istio ingress gateway. That means if a client sends an x-request-id header, Envoy won’t overwrite it with a new one, but will forward it downstream. Here’s a breakdown of what you’ve got:

Explanation

  • apiVersion / kind
  • Using Istio’s EnvoyFilter CRD (networking.istio.io/v1alpha3).
  • metadata
    • name: filter name is preserve-external-request-id
    • namespace: applies in the istio-ingress namespace (make sure your ingress gateway pod is actually running there—by default it’s istio-system unless customized).
  • workloadSelector
    • Matches workloads with label istio: gateway. Verify that your ingress gateway Deployment has this label (sometimes it’s istio: ingressgateway instead).
  • configPatches
    • applyTo: NETWORK_FILTER: You’re patching a network filter in the Envoy config.
    • match: Targets the http_connection_manager filter inside the ingress gateway’s listener.
    • patch: Uses MERGE to override the existing config with preserve_external_request_id: true.

Effect

  • Incoming x-request-id headers from external clients are preserved instead of being replaced.
  • If the header is missing, Envoy will still generate one.
  • This is useful when you want to correlate requests across multiple systems (e.g., external load balancers, API gateways, tracing systems).

Things to Check

  • Namespace & labels:
    • Ensure your ingress gateway pod has the label istio: gateway in the istio-ingress namespace. Otherwise, this EnvoyFilter won’t apply. Run:
kubectl get pods -n istio-ingress --show-labels

If your gateway runs in istio-system, update the namespace.

  • Validation:
    • After applying, you can verify Envoy’s live config:
istioctl proxy-config listeners <gateway-pod> -n istio-ingress

Look for preserve_external_request_id: true.

Test

  • Wyślij request z własnym x-request-id z zewnat do aplikcji w klastrze:
curl -vk https://twoj-domena/ -H "x-request-id: test-123"
  • W aplikacji w Kubernetesie sprawdź nagłówki – jeśli widzisz x-request-id: test-123, to działa poprawnie.
  • Możesz też podejrzeć live-config w Envoy:
istioctl proxy-config listeners <gateway-pod> -n istio-ingress

i tam szukać preserve_external_request_id: true.

http_connection_manager

request od klienta → ustawienie nagłówków → łańcuch filtrów → router → upstream

http_connection_manager to jeden z network filterów w Envoy (czyli działa na poziomie połączenia), ale jest wyjątkowy, bo:

  • Sam robi część roboty (np. generuje x-request-id, access logi, tracing).
  • Jest „kontenerem” dla innych filtrów HTTP (czyli buduje pipeline: JWT → CORS → RBAC → Router itd.).

Co dokładnie robi http_connection_manager?

  1. Obsługa requestów i response’ów HTTP
  • Parsuje request HTTP/1.1, HTTP/2, HTTP/3 (jeśli Envoy obsługuje QUIC).
  • Obsługuje nagłówki specyficzne dla Envoy, np. x-request-id, x-envoy-attempt-count, x-envoy-peer-metadata.
  • Może dodać/zmodyfikować nagłówki systemowe (np. x-request-id, x-envoy-decorator-operation).
  1. Routing
  • Współpracuje z route_config, gdzie definiowane są reguły: „jeśli ścieżka /foo, to wyślij do cluster service-foo”.
  • Na końcu zawsze wywołuje filtr router, który faktycznie wysyła request do upstreamu (Twojej aplikacji).
  1. Łańcuch filtrów HTTP
  • Przekazuje request przez listę http_filters.
  • Filtry mogą np. zatrzymać request (gdy JWT nieprawidłowe) albo dodać nagłówki.
  • Kolejność ma ogromne znaczenie.
  1. Access logging
  • http_connection_manager obsługuje definicje access logów → możesz logować każde żądanie, response, latency, nagłówki itp.
  • Logi mogą być kierowane do pliku, do stdout albo do gRPC.
  1. Tracing
  • Integruje się z systemami jak Jaeger, Zipkin, Datadog.
  • Wstawia nagłówki tracingowe (x-b3-traceid, traceparent).
  • Decyduje, czy dany request ma być próbkowany do trace.
  1. Statystyki i metryki
  • Generuje metryki (np. liczba requestów, czas odpowiedzi, liczba błędów 5xx).
  • To te dane, które Prometheus potem zbiera z Envoya.
  1. Idle/connection management
  • Obsługuje time-outy: request timeout, idle timeout.
  • Zarządza keepalive (HTTP/2 PING, idle connection close).
  1. Inne opcje
  • Obsługuje redirecty (301/302) w oparciu o reguły routingu.
  • Może robić internal redirect (przekierować request na inną ścieżkę w środku Envoy).
  • Potrafi ustawiać defaultowe odpowiedzi, jeśli żaden route nie pasuje.
⚠️ **GitHub.com Fallback** ⚠️