Envoy. 1. Introduktion

Hej! Detta är en kort artikel som svarar på frågorna: "vad är envoy?", "varför behövs det?" och "hur börjar man?".

Vad är detta

Envoy är en L4-L7 lastbalanserare skriven i C++, designad för hög prestanda och tillgänglighet. Å ena sidan är det en slags analog till nginx och haproxy, och har jämförbar prestanda. Å andra sidan är den mer inriktad på mikrotjänstarkitektur och har funktionalitet som är minst lika bra som lastbalanserare på java och go, som zuul eller traefik.

Jämförande tabell för haproxy/nginx/envoy, den gör inte anspråk på absolut sanning, men ger en allmän bild.

nginx
haproxy
envoy
traefik

stjärnor på github
11.2k/mirror
1.1k/mirror
12.4k
27.6k

skriven i
C
C
C++
go

API
nej
endast socket/push
dataplan/pull
pull

aktiv hälsokontroll
nej
ja
ja
ja

Öppen spårning
extern plugin
nej
ja
ja

JWT
extern plugin
nej
ja
nej

Utvidgning
Lua/C
Lua/C
Lua/C++
nej

Varför

Detta är ett ungt projekt, det saknar mycket, och en del är i tidig alfa. Men envoy, delvis tack vare sin ungdom, utvecklas snabbt och har redan nu många intressanta möjligheter: dynamisk konfiguration, många färdiga filter, ett enkelt gränssnitt för att skriva egna filter.
Detta ger upphov till användningsområden, men för att börja med två antipatterns:

• Leverera statisk innehåll.

Problemet är att det för närvarande finns envoy ingen support för caching. Killarna från google försöker få detta åtgärdas. Idén är att en gång implementera i envoy alla nyanser (djungeln av headers) i enlighet med RFC, och för specifika implementationer skapa ett gränssnitt. Men just nu är det inte ens alfa, arkitekturen diskuteras, PR öppet (medan jag skrev artikeln så mergades PR, men denna punkt är fortfarande aktuell).

Tills vidare, använd nginx för statiskt innehåll.

• Statisk konfiguration.

Den kan användas, men envoy den skapades inte för detta. Möjligheterna i statisk konfiguration kommer inte att avslöjas. Det finns många punkter:

Genom att redigera konfigurationen i yaml kommer du att göra misstag, förbanna utvecklarna för deras omfattande beskrivning och tänka att konfigureringsfiler för nginx/haproxy, även om de är mindre strukturerade, är mer koncisa. Det är essensen. Konfigurationen för Nginx och Haproxy skapades för manuell redigering, medan envoy är skapad för att genereras från kod. Hela konfigurationen är beskriven i protobuf, att generera den via proto-filer är mycket svårare att göra fel.

Scenarier för canary, b/g-deploy och mycket mer kan normalt genomföras endast i dynamisk konfiguration. Jag säger inte att detta inte kan göras i statisk, vi gör allt detta. Men för detta krävs det att man bygger på workaround-lösningar, i vilken som helst av lastbalanserarna, i envoy även.

Uppgifter där Envoy är ovärderlig:

• Lastbalansering av trafik i komplexa och dynamiska system. Här ingår service mesh, men det är inte nödvändigtvis bara det.
• Behovet av funktionalitet för distribuerad spårning, komplex autentisering eller annat som finns i envoy standard eller som kan implementeras enkelt, medan i nginx/haproxy behövs lua och tveksamma plugins.

Båda behöver vid behov säkerställa hög prestanda.

Hur det fungerar

Envoy distribueras i binärform endast som dockerbild. I bilden finns det redan ett exempel på statisk konfiguration. Men vi är endast intresserade av den för att förstå strukturen.

envoy.yaml statisk konfiguration

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
    # Kommentera ut följande rad för att testa på v6-nätverk
    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 konfiguration

Vilket problem söker vi en lösning på? Man kan inte bara ta och ladda om balancerarens konfiguration under belastning, det kommer att uppstå "små" problem:

• Validering av konfiguration.

Konfigurationen kan vara stor, den kan vara väldigt stor, om vi laddar om allt på en gång ökar chansen att det finns ett fel någonstans.

• Långvariga anslutningar.

Vid initiering av en ny lyssnare, måste man ta hand om anslutningarna som arbetar på den gamla, om ändringarna sker ofta och det finns långvariga anslutningar, måste man hitta en kompromiss. Hej, kubernetes ingress på nginx.

• Aktiva hälsokontroller.

Om vi har aktiva hälsokontroller, bör vi kontrollera dem alla på den nya konfigurationen innan vi skickar trafik. Om det finns många upstreams tar det tid. Hej, haproxy.

Hur detta löses i envoy, genom att dynamiskt ladda konfigureringen, enligt poolmodellen, kan den delas upp i separata delar och inte ominitieras för den del som inte har ändrats. Till exempel en lyssnare, som är kostsam att ominitiera, och som sällan ändras.

Konfiguration envoy (från filen ovan) har följande entiteter:

• lyssnare — en lyssnare som är kopplad till en viss ip/port
• virtuell värd — en virtuell värd baserad på domännamn
• route — balansregler
• cluster — en grupp upstreams med balansparameterar
• endpoint — adress till en upstream-instans

Varje av dessa entiteter samt vissa andra kan fyllas i dynamiskt, för detta anges en tjänstadress i konfigurationen varifrån konfigurationen ska hämtas. Tjänsten kan vara REST eller gRPC, helst bör gRPC användas.

Tjänsterna kallas respektive: LDS, VHDS, RDS, CDS och EDS. Statisk och dynamisk konfiguration kan kombineras, med begränsningen att en dynamisk resurs inte kan anges i den statiska.

För de flesta uppgifter är det tillräckligt att implementera de tre senaste tjänsterna, de kallas ADS (Aggregated Discovery Service), för java och go har en färdig gRPC dataplane-implementation där det endast är nödvändigt att fylla i objekten från sin egen källa.

Konfigurationen får följande utseende:

envoy.yaml dynamisk konfiguration

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 den körs visas följande: envoy med denna konfiguration, kommer den att ansluta till control-plane och försöka begära RDS, CDS och EDS-konfigurationen. Hur interaktionsprocessen går till är beskrivet här.

Kort sagt, envoy skickar en begäran med typ av begärd resurs, version och nodparametrar. I svaret får den resursen och versionen, om versionen på control-plane inte har ändrats, svarar den inte.
Det finns fyra alternativ för interaktion:

• En gRPC-ström för alla typer av resurser skickar den fullständiga statusen för resursen.
• Separata strömmar, fullständigt tillstånd.
• En ström, inkrementellt tillstånd.
• Separata strömmar, inkrementellt tillstånd.

Inkrementell xDS minskar trafiken mellan kontrollplanet och envoy, vilket är relevant för stora konfigurationer. Men det komplicerar interaktionen, en lista över resurser för avprenumeration och prenumeration överförs i förfrågan.

I vårt exempel används ADS – en ström för RDS, CDS, EDS och icke-inkrementellt läge. För att aktivera inkrementellt läge måste du ange api_type: DELTA_GRPC

Eftersom det finns nodparametrar i förfrågan kan vi skicka olika resurser till olika instanser på kontrollplanet envoy, vilket är praktiskt för att bygga en service mesh.

Uppvärmning

På envoy vid start eller när en ny konfiguration tas emot från kontrollplanet startar processen för uppvärmning av resurser. Den är uppdelad i listener-uppvärmning och cluster-uppvärmning. Den första startar vid förändringar i RDS/LDS, den andra vid CDS/EDS. Det betyder att om bara upstreams ändras, kommer lyssnaren inte att återskapas.

Under uppvärmningen förväntas beroende resurser från kontrollplanet inom tidsgränsen. Om tidsgränsen har passerat, kommer initieringen att misslyckas, den nya lyssnaren kommer inte att börja lyssna på porten.
Initieringsordning: EDS, CDS, aktiv hälsokontroll, RDS, LDS. När aktiva hälsokontroller är aktiverade, går trafik till upstreamen endast efter en lyckad hälsokontroll.

Om lyssnaren återskapas går den gamla över till tillståndet DRAIN och kommer att tas bort efter att alla anslutningar har stängts eller tidsgränsen har löpt ut --drain-time-s, som standard 10 minuter.

Fortsättning följer.

Källa: habr.com