vyslanec. 1. Úvod

pozdravujem! Toto je krátky článok, ktorý odpovedá na otázky: "čo je vyslanec?", "prečo je to potrebné?" a "kde začať?".

Čo to je?

Envoy je L4-L7 balancer napísaný v C++, zameraný na vysoký výkon a dostupnosť. Na jednej strane je to nejakým spôsobom analóg nginx a haproxy, ktorý je s nimi porovnateľný. Na druhej strane je viac orientovaný na architektúru mikroslužieb a jeho funkčnosť nie je horšia ako vyrovnávacie nástroje java a go, ako napríklad zuul alebo traefik.

Porovnávacia tabuľka haproxy/nginx/envoy, netvrdí, že je to absolútna pravda, ale poskytuje všeobecný obraz.

nginx
haproxy
odoslané
traefik

hviezdy na githube
11.2 k/zrkadlo
1.1 k/zrkadlo
12.4k
27.6k

napísané v
C
C
C + +
go

API
nie
len zásuvka/stlačiť
dataplane/pull
SEM

aktívna zdravotná prehliadka
nie
áno
áno
áno

Otvorené sledovanie
externý plugin
nie
áno
áno

J.W.T.
externý plugin
nie
áno
nie

predĺženie
Lua/C
Lua/C
Lua/C++
nie

Čo pre

Toto je mladý projekt, veľa vecí chýba, niektoré sú v ranej verzii alfa. ale odoslané, aj vďaka svojej mladosti sa rýchlo rozvíja a už má veľa zaujímavých funkcií: dynamickú konfiguráciu, veľa hotových filtrov, jednoduché rozhranie na písanie vlastných filtrov.
Z toho vyplývajú oblasti použitia, ale najprv existujú 2 antivzory:

• Statický spätný ráz.

Faktom je, že momentálne v odoslané žiadna podpora ukladania do vyrovnávacej pamäte. Chlapci z Googlu to skúšajú opraviť. Myšlienka sa raz zrealizuje odoslané všetky jemnosti (zoo hlavičky) súladu s RFC a pre špecifické implementácie vytvárajú rozhranie. Ale zatiaľ to nie je ani alfa, o architektúre sa diskutuje, PR otvorené (pri písaní PR článku mi PR zamrzlo, ale tento bod je stále aktuálny).

Zatiaľ na statiku používajte nginx.

• Statická konfigurácia.

Môžete to použiť, ale odoslané Na to to nebolo stvorené. Funkcie v statickej konfigurácii nebudú vystavené. Existuje veľa momentov:

Pri úprave konfigurácie v yaml sa pomýlite, nadávate vývojárom za podrobnosť a myslíte si, že konfigurácie nginx/haproxy, aj keď sú menej štruktúrované, sú stručnejšie. To je podstata. Konfigurácia Nginx a Haproxy bola vytvorená pre ručné úpravy a odoslané na generovanie z kódu. Celá konfigurácia je popísaná v protobuf, pri jeho generovaní z proto súborov je oveľa ťažšie urobiť chybu.

Canary, scenáre nasadenia b/g a mnohé ďalšie sa bežne implementujú iba v dynamickej konfigurácii. Nehovorím, že sa to nedá robiť staticky, robíme to všetci. Ale na to si musíte obliecť barle v ktoromkoľvek z vyvažovačov odoslané vrátane.

Úlohy, pre ktoré je Envoy nepostrádateľný:

• Vyvažovanie dopravy v zložitých a dynamických systémoch. To zahŕňa servisnú sieť, ale nie je nevyhnutne jediná.
• Potreba distribuovanej funkcie sledovania, komplexnej autorizácie alebo inej funkcie, ktorá je dostupná v odoslané z krabice alebo pohodlne implementované, ale v nginx/haproxy musíte byť obklopení lua a pochybnými pluginmi.

Oba v prípade potreby poskytujú vysoký výkon.

Ako to funguje

Envoy je distribuovaný v binárnych súboroch iba ako docker image. Obrázok už obsahuje príklad statickej konfigurácie. Ale nás to zaujíma len pre pochopenie štruktúry.

envoy.yaml statická konfigurácia

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á konfigurácia

Na aký problém hľadáme riešenie? Konfiguráciu vyrovnávača zaťaženia nemôžete len znova načítať pri zaťažení; vyskytnú sa „malé“ problémy:

• Overenie konfigurácie.

Konfigurácia môže byť veľká, môže byť veľmi veľká, ak ju preťažíme naraz, zvyšuje sa šanca, že niekde nastane chyba.

• Dlhotrvajúce spojenia.

Pri inicializácii nového poslucháča sa musíte postarať o pripojenia bežiace na starom, ak sa zmeny vyskytujú často a existujú dlhodobé pripojenia, budete musieť hľadať kompromis. Dobrý deň, kubernetes ingress na nginx.

• Aktívne kontroly zdravotného stavu.

Ak máme aktívne kontroly stavu, pred odoslaním prenosu ich musíme všetky skontrolovať v novej konfigurácii. Ak je proti prúdu veľa, vyžaduje to čas. Ahoj haproxy.

Ako je toto vyriešené v odoslanéDynamickým načítaním konfigurácie podľa modelu fondu ju môžete rozdeliť na samostatné časti a neinicializovať znova časť, ktorá sa nezmenila. Napríklad poslucháč, ktorého opätovná inicializácia je nákladná a málokedy sa mení.

konfigurácia odoslané (zo súboru vyššie) má nasledujúce entity:

• poslucháč — poslucháč visiaci na špecifickom IP/porte
• virtuálny hostiteľ - virtuálny hostiteľ podľa názvu domény
• trasa - vyvažovacie pravidlo
• zhluk — skupina odberateľov s vyvažovacími parametrami
• koncový bod — upstream adresa inštancie

Každá z týchto entít a niektoré ďalšie môžu byť vyplnené dynamicky; na tento účel konfigurácia špecifikuje adresu služby, odkiaľ bude konfigurácia prijatá. Služba môže byť REST alebo gRPC, výhodnejšie je gRPC.

Služby sú pomenované takto: LDS, VHDS, RDS, CDS a EDS. Môžete kombinovať statickú a dynamickú konfiguráciu s obmedzením, že dynamický prostriedok nemožno zadať v statickom.

Pre väčšinu úloh stačí implementovať posledné tri služby, ktoré sa nazývajú ADS (Aggregated Discovery Service), napr. Jáva a choďte tam je hotová implementácia gRPC dataplane, v ktorej stačí vyplniť objekty z vášho zdroja.

Konfigurácia má nasledujúcu formu:

dynamická konfigurácia 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

Pri štarte odoslané s touto konfiguráciou sa pripojí k riadiacej rovine a pokúsi sa vyžiadať konfiguráciu RDS, CDS a EDS. Je popísané, ako prebieha proces interakcie tu.

V skratke, odoslané odošle požiadavku označujúcu typ požadovaného zdroja, verziu a parametre uzla. Ako odpoveď dostane zdroj a verziu; ak sa verzia v riadiacej rovine nezmenila, neodpovedá.
Existujú 4 možnosti interakcie:

• Jeden prúd gRPC pre všetky typy zdrojov, odošle sa úplný stav zdroja.
• Samostatné prúdy, kompletný stav.
• Jeden prúd, prírastkový stav.
• Oddelené prúdy, prírastkový stav.

Inkrementálne xDS vám umožňuje znížiť premávku medzi riadiacou rovinou a odoslané, je to relevantné pre veľké konfigurácie. To však komplikuje interakciu, žiadosť obsahuje zoznam zdrojov na odhlásenie a prihlásenie.

Náš príklad používa ADS - jeden stream pre RDS, CDS, EDS a neinkrementálny režim. Ak chcete povoliť prírastkový režim, musíte zadať api_type: DELTA_GRPC

Keďže požiadavka obsahuje parametre uzla, môžeme do riadiacej roviny poslať rôzne zdroje pre rôzne inštancie odoslané, je to vhodné na vytvorenie servisnej siete.

warmup

Na odoslané pri spustení alebo pri prijatí novej konfigurácie z riadiacej roviny sa spustí proces zahrievania prostriedkov. Delí sa na zahrievanie poslucháča a zahrievanie klastra. Prvý sa spustí pri zmenách v RDS/LDS, druhý pri CDS/EDS. To znamená, že ak sa zmenia iba upstreamy, poslucháč nie je znovu vytvorený.

Počas procesu zahrievania sa počas časového limitu očakávajú závislé zdroje z riadiacej roviny. Ak uplynie časový limit, inicializácia nebude úspešná a nový poslucháč nezačne počúvať na porte.
Inicializačný príkaz: EDS, CDS, aktívna kontrola stavu, RDS, LDS. Ak sú povolené aktívne kontroly stavu, návštevnosť bude smerovať proti prúdu iba po jednej úspešnej kontrole stavu.

Ak bol poslucháč znova vytvorený, starý prejde do stavu DRAIN a bude odstránený po zatvorení všetkých pripojení alebo po uplynutí časového limitu --drain-time-s, predvolene 10 minút.

Bude pokračovať.

Zdroj: hab.com