Envoy. 1. Innledning

Hei! Dette er en liten artikkel som svarer på spørsmålene: "Hva er envoy?", "Hva trenger man det til?" og "Hvordan komme i gang?".

Hva er dette

Envoy er en L4-L7 lastbalanserer skrevet i C++, med fokus på høy ytelse og tilgjengelighet. På den ene siden er det på en måte en analog til nginx og haproxy, sammenlignbart med dem når det gjelder ytelse. På den annen side er den mer tilpasset mikrotjenestearkitektur og har funksjoner som ikke er dårligere enn lastbalanserere skrevet i Java og Go, som Zuul eller Traefik.

Sammenligningstabell for haproxy/nginx/envoy, som ikke nødvendigvis er absolutt sannhet, men gir et generelt bilde.

nginx
haproxy
envoy
traefik

stjerner på github
11.2k/mirror
1.1k/mirror
12.4k
27.6k

skrevet i
C
C
C++
go

API
nei
socket only/push
dataplane/pull
pull

aktiv helsesjekk
nei
ja
ja
ja

Åpen sporing
ekstern plugin
nei
ja
ja

JWT
ekstern plugin
nei
ja
nei

Utvidelse
Lua/C
Lua/C
Lua/C++
nei

Hvorfor

Dette er et ungt prosjekt, og det mangler mye, noe er i tidlig alfa. Men envoy, blant annet på grunn av sin ungdom, utvikler det seg raskt og har allerede mange spennende muligheter: dynamisk konfigurasjon, mange ferdige filtre, og et enkelt grensesnitt for å skrive egne filtre.
Herfra følger bruksområder, men først to antipatterns:

• Levering av statisk innhold.

Saken er at for øyeblikket i envoy er det ingen støtte for caching. Guttene fra Google prøver å få det til fikses. Ideen er å implementere alle detaljene (zoo av headere) i samsvar med RFC én gang, og for spesifikke implementeringer lage et grensesnitt. Men så langt er dette ikke engang alfa, arkitekturen er under diskusjon, envoy åpen (mens jeg skrev artikkelen ble PR-merget, men dette punktet er fortsatt aktuelt). PR I mellomtiden, bruk nginx for statisk innhold.

Statisk konfigurasjon.

• Du kan bruke det, men

ble ikke laget for dette. Mulighetene i statisk konfigurasjon vil ikke bli utnyttet. Det er mange punkter: envoy Når du redigerer konfigurasjonen i yaml, vil du gjøre feil, banne utviklerne for deres ordknapphet og tenke at konfigurasjoner for nginx/haproxy, selv om de er mindre strukturerte, er mer konsise. Dette er essensen. Konfigurasjonen til Nginx og Haproxy ble laget for manuell redigering, mens

er laget for generering fra kode. Hele konfigurasjonen er beskrevet i envoy , ved å generere den fra proto-filer er det mye vanskeligere å gjøre feil. protobufCanary-scenarier, b/g deploy og mye mer kan bare realiseres normalt i dynamisk konfigurasjon. Jeg sier ikke at dette ikke kan gjøres i statisk konfigurasjon, vi gjør alt dette. Men for dette må man bruke klosser, i en hvilken som helst av balanseverken, i

inkludert. envoy Oppgaver der Envoy er uunnværlig:

Oppgåver der Envoy er uunnverleg:

• Lastbalansering av trafikk i komplekse og dynamiske systemer. Dette inkluderer service mesh, men det er ikke nødvendigvis bare det.
• Behovet for funksjonalitet som distribuert sporing, kompleks autorisasjon eller annet som finnes i envoy boks eller enkelt implementeres, mens nginx/haproxy krever lua og tvilsomme plugins.

Begge deler må sørge for høy ytelse hvis nødvendig.

Hvordan det fungerer

Envoy distribueres i binærfiler kun som docker bilde. I bildet er det allerede et eksempel på statisk konfigurasjon. Men vi er kun interessert i dette for å forstå strukturen.

envoy.yaml statisk konfigurasjon

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "\/"
                route:
                  host_rewrite: www.google.com
                  cluster: service_google
          http_filters:
          - name: envoy.router
  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Kommenter ut linjen under for å teste på v6-nettverk
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_google
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.google.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
        sni: www.google.com

Dynamisk konfigurasjon

Hvilken problemstilling søker vi å løse? Man kan ikke bare ta og laste inn konfigurasjonen til balanseoren under belastning, det vil oppstå "små" problemer:

• Validering av konfigurasjon.

Konfigurasjonen kan være stor, den kan være veldig stor. Hvis vi laster den hele på en gang, øker sjansen for feil.

• Langvarige forbindelser.

Ved initialisering av en ny lytter, må man ta seg av forbindelser aktive på den gamle, hvis endringer skjer ofte og det er langvarige forbindelser, må man finne et kompromiss. Hei, kubernetes ingress på nginx.

• Aktive helse-sjekker.

Hvis vi har aktive helse-sjekker, bør vi verifisere alle på den nye konfigurasjonen før vi sender trafikken. Hvis det er mange upstream, tar det tid. Hei, haproxy.

Hvordan dette løses i envoy, ved å laste inn konfigurasjonen dynamisk, kan modellen dele opp i separate deler og unngå å reinitialisere delen som ikke har endret seg. For eksempel lytteren, som er kostbar å reinitialisere, endres sjelden.

Konfigurasjon envoy (fra filen over) har følgende entiteter:

• lytter — en lytter som henger på et bestemt ip/port
• virtuell vert — en virtuell vert etter domenenavn
• rute — balanse-regel
• klynge — en gruppe oppstrøms med balanseparametere
• endpoint — adressen til oppstrømsinstansen

Hver av disse entitetene pluss noen andre kan fylles ut dynamisk, for dette angis adressen til tjenesten fra hvor konfigurasjonen vil bli hentet i konfigurasjonen. Tjenesten kan være REST eller gRPC, gRPC anbefales.

Tjenestene kalles henholdsvis: LDS, VHDS, RDS, CDS og EDS. Man kan kombinere statisk og dynamisk konfigurasjon, med begrensningen at dynamisk ressurs ikke kan angis i statisk.

For de fleste oppgaver er det tilstrekkelig å implementere de siste tre tjenestene, de kalles ADS (Aggregated Discovery Service), for java og Go har en klar implementasjon av gRPC dataplane der man bare trenger å fylle ut objektene fra sin egen kilde.

Konfigurasjonen får følgende form:

envoy.yaml dynamisk konfigurasjon

dynamic_resources:
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_clr
  cds_config:
    ads: {}
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          rds:
            route_config_name: local_route
            config_source:
              ads: {}
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_clr
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: xds_clr
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: xds
                port_value: 6565

Når du starter envoy med denne konfigurasjonen, vil den koble seg til kontrollplanen og forsøke å be om RDS, CDS og EDS-konfigurasjonen. Hvordan interaksjonsprosessen skjer er beskrevet her.

Kort sagt, envoy sender den en forespørsel med type av den forespurte ressursen, versjonen og nodens parametere. I svar får den ressursen og versjonen, hvis versjonen på kontrollplanen ikke har endret seg, svarer den ikke.
Det finnes 4 alternativer for interaksjon:

• En gRPC-strøm for alle typer ressurser, som sender den fullstendige tilstanden til ressursen.
• Separate streams, full state.
• One stream, incremental state.
• Separate streams, incremental state.

Incremental xDS reduces traffic between the control plane and envoy, which is relevant for large configurations. However, it complicates interaction as the request carries a list of resources for subscription and unsubscription.

In our example, ADS is used — one stream for RDS, CDS, EDS in non-incremental mode. To enable incremental mode, you need to specify api_type: DELTA_GRPC

Since the request contains node parameters, we can send different resources for different instances to the control plane, envoy, which is convenient for building a service mesh.

Warmup

På envoy at startup or when receiving a new configuration from the control plane, the resource warmup process is initiated. It is divided into listener warmup and cluster warmup. The former is triggered by changes in RDS/LDS, and the latter when CDS/EDS changes. This means that if only upstreams change, the listener is not recreated.

During the warmup process, dependent resources from the control plane are awaited within a timeout. If the timeout expires, the initialization will not be successful, and the new listener will not start listening on the port.
The initialization order is: EDS, CDS, active health check, RDS, LDS. With active health checks enabled, traffic will go to the upstream only after one successful health check.

If the listener is recreated, the old one transitions to DRAIN state and will be removed after all connections are closed or after the timeout expires --drain-time-s, by default 10 minutes.

Fortsatt følger.

Kilde: habr.com