Vyslanec. 1. Úvod

Pozdravy! Toto je krátký článek, který odpovídá na otázky: "co je vyslanec?", "proč je to potřeba?" a "kde začít?".

Co je to

Envoy je L4-L7 balancer napsaný v C++, zaměřený na vysoký výkon a dostupnost. Na jedné straně je to nějakým způsobem analog nginx a haproxy, srovnatelný s nimi ve výkonu. Na druhou stranu je více orientován na architekturu mikroslužeb a má funkčnost o nic horší než balancéry java and go, jako je zuul nebo traefik.

Srovnávací tabulka haproxy/nginx/envoy, netvrdí, že je to absolutní pravda, ale dává obecný obrázek.

Nginx
haproxy
odesláno
traefik

hvězdy na githubu
11.2k/zrcadlo
1.1k/zrcadlo
12.4
27.6

zapsáno v
C
C
C + +
go

API
ne
pouze zásuvka/tlač
dataplane/pull
táhnout

aktivní zdravotní prohlídka
ne
ano
ano
ano

Otevřené trasování
externí plugin
ne
ano
ano

JWT
externí plugin
ne
ano
ne

prodloužení
Lua/C
Lua/C
Lua/C++
ne

Proč

Toto je mladý projekt, spousta věcí chybí, některé jsou v rané alfě. Ale odesláno, i díky svému mládí, se rychle vyvíjí a má již mnoho zajímavých funkcí: dynamickou konfiguraci, mnoho hotových filtrů, jednoduché rozhraní pro psaní vlastních filtrů.
Z toho vyplývají oblasti použití, ale nejprve existují 2 antivzory:

• Statický zpětný ráz.

Faktem je, že v tuto chvíli v odesláno žádná podpora mezipaměti. Kluci z Googlu to zkouší opravit. Myšlenka bude jednou realizována odesláno všechny jemnosti (zoo záhlaví) souladu s RFC a pro konkrétní implementace vytvořit rozhraní. Ale zatím to není ani alfa, o architektuře se diskutuje, PR otevřené (při psaní PR článku PR zamrzlo, ale tento bod je stále aktuální).

Pro statiku zatím používejte nginx.

• Statická konfigurace.

Můžete to použít, ale odesláno K tomu to nebylo stvořeno. Prvky ve statické konfiguraci nebudou vystaveny. Momentů je mnoho:

Při úpravě konfigurace v yaml se budete mýlit, nadávat vývojářům za upovídanost a myslet si, že konfigurace nginx/haproxy, i když jsou méně strukturované, jsou stručnější. O to tu jde. Konfigurace Nginx a Haproxy byla vytvořena pro ruční úpravy a odesláno pro generování z kódu. Celá konfigurace je popsána v protobuf, jeho generování z proto souborů je mnohem obtížnější udělat chybu.

Scénáře nasazení Canary, b/g a mnohé další jsou běžně implementovány pouze v dynamické konfiguraci. Neříkám, že to nejde udělat staticky, děláme to všichni. Ale k tomu je třeba nasadit berle, v kterémkoli z balancérů odesláno včetně.

Úkoly, pro které je Envoy nepostradatelný:

• Vyvažování dopravy ve složitých a dynamických systémech. To zahrnuje síť služeb, ale není nutně jediná.
• Potřeba distribuované funkce trasování, komplexní autorizace nebo jiné funkce, která je k dispozici v odesláno po vybalení nebo pohodlně implementované, ale v nginx/haproxy musíte být obklopeni lua a pochybnými pluginy.

Oba v případě potřeby poskytují vysoký výkon.

Jak to funguje

Envoy je distribuován v binárních souborech pouze jako docker image. Obrázek již obsahuje příklad statické konfigurace. Nás to ale zajímá jen pro pochopení struktury.

statická konfigurace envoy.yaml

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
    # Comment out the following line to test on v6 networks
    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

Dynamická konfigurace

Na jaký problém hledáme řešení? Nemůžete jen znovu načíst konfiguraci load balanceru pod zatížením, objeví se „malé“ problémy:

• Ověření konfigurace.

Konfigurace může být velká, může být velmi velká, pokud ji přetížíme najednou, zvyšuje se šance, že někde dojde k chybě.

• Dlouhotrvající spojení.

Při inicializaci nového posluchače je třeba se postarat o připojení běžící na starém, pokud ke změnám dochází často a existují dlouhodobá připojení, budete muset hledat kompromis. Dobrý den, kubernetes ingress na nginx.

• Aktivní zdravotní kontroly.

Pokud máme aktivní kontroly stavu, musíme je všechny znovu zkontrolovat v nové konfiguraci před odesláním provozu. Pokud je proti proudu hodně, trvá to. Ahoj haproxy.

Jak je toto řešeno v odeslánoDynamickým načítáním konfigurace podle modelu fondu ji můžete rozdělit na samostatné části a nereinicializovat tu část, která se nezměnila. Například posluchač, jehož reinicializace je nákladná a málokdy se mění.

Konfigurace odesláno (ze souboru výše) má následující entity:

• posluchač — posluchač visící na konkrétní IP/portu
• virtuální hostitel - virtuální hostitel podle názvu domény
• trasa - vyrovnávací pravidlo
• shluk — skupina upstreamů s vyvažovacími parametry
• Koncový bod — upstream adresa instance

Každá z těchto entit a některé další mohou být vyplněny dynamicky, k tomu konfigurace specifikuje adresu služby, odkud bude konfigurace přijata. Služba může být REST nebo gRPC, výhodnější je gRPC.

Služby jsou pojmenovány v tomto pořadí: LDS, VHDS, RDS, CDS a EDS. Můžete kombinovat statickou a dynamickou konfiguraci s omezením, že dynamický prostředek nelze zadat ve statickém.

Pro většinu úloh stačí implementovat poslední tři služby, které se nazývají ADS (Aggregated Discovery Service), např. Jáva and go there je hotová implementace dataplane gRPC, ve které stačí vyplnit objekty ze zdroje.

Konfigurace má následující podobu:

dynamická konfigurace envoy.yaml

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

Při spuštění odesláno s touto konfigurací se připojí k řídicí rovině a pokusí se požádat o konfiguraci RDS, CDS a EDS. Je popsáno, jak probíhá proces interakce zde.

Ve zkratce, odesláno odešle požadavek označující typ požadovaného zdroje, verzi a parametry uzlu. Jako odpověď obdrží zdroj a verzi; pokud se verze v řídicí rovině nezměnila, nereaguje.
Existují 4 možnosti interakce:

• Jeden gRPC stream pro všechny typy zdrojů, je odeslán úplný stav zdroje.
• Samostatné proudy, plný stav.
• Jeden proud, přírůstkový stav.
• Samostatné proudy, inkrementální stav.

Inkrementální xDS umožňuje snížit provoz mezi řídicí rovinou a odesláno, to platí pro velké konfigurace. To ale komplikuje interakci, požadavek obsahuje seznam zdrojů pro odhlášení a přihlášení.

Náš příklad používá ADS - jeden stream pro RDS, CDS, EDS a neinkrementální režim. Chcete-li povolit přírůstkový režim, musíte zadat api_type: DELTA_GRPC

Protože požadavek obsahuje parametry uzlů, můžeme do řídicí roviny poslat různé zdroje pro různé instance odesláno, je to vhodné pro vytvoření servisní sítě.

Zahřát se

Na odesláno při spuštění nebo při přijetí nové konfigurace z řídicí roviny se spustí proces zahřívání prostředků. Dělí se na zahřívání posluchače a zahřívání clusteru. První se spustí, když dojde ke změnám v RDS/LDS, druhý při CDS/EDS. To znamená, že pokud se změní pouze upstream, posluchač nebude znovu vytvořen.

Během procesu zahřívání jsou během časového limitu očekávány závislé zdroje z řídicí roviny. Pokud dojde k vypršení časového limitu, inicializace nebude úspěšná a nový posluchač nezačne na portu naslouchat.
Pořadí inicializace: EDS, CDS, aktivní kontrola stavu, RDS, LDS. Když jsou aktivní kontroly stavu povoleny, provoz půjde proti proudu pouze po jedné úspěšné kontrole stavu.

Pokud byl posluchač znovu vytvořen, starý přejde do stavu DRAIN a bude odstraněn po uzavření všech připojení nebo vypršení časového limitu. --drain-time-s, výchozí 10 minut.

Je třeba pokračovat.

Zdroj: www.habr.com