Követ. 1. Bemutatkozás

Üdvözlet! Ez egy rövid cikk, amely választ ad a kérdésekre: „mi az a küldött?”, „miért van rá szükség?” és "hol kezdjem?".

Mi ez

Az Envoy egy C++ nyelven írt L4-L7 balansz, amely a nagy teljesítményre és rendelkezésre állásra összpontosít. Egyrészt ez valamilyen módon az nginx és a haproxy analógja, teljesítményükben összehasonlítható velük. Másrészt inkább a mikroszolgáltatási architektúra felé orientálódik, és a funkcionalitása nem rosszabb, mint a java and go egyensúlyozók, mint például a zuul vagy a traefik.

Haproxy/nginx/envoy összehasonlító táblázata, nem állítja az abszolút igazságot, de általános képet ad.

nginx
haproxi
követ
traefik

csillagok a githubon
11.2k/tükör
1.1k/tükör
12.4k
27.6k

beírva
C
C
C + +
go

API
nincs
csak aljzat/tolható
adatsík/húzás
húzza

aktív egészségügyi vizsgálat
nincs
igen
igen
igen

Nyissa meg a nyomkövetést
külső plugin
nincs
igen
igen

J.W.T.
külső plugin
nincs
igen
nincs

kiterjesztés
Lua/C
Lua/C
Lua/C++
nincs

Miért

Ez egy fiatal projekt, sok minden hiányzik, néhány az alfa elején. De követ, szintén fiatalságának köszönhetően, gyorsan fejlődik, és máris számos érdekességgel rendelkezik: dinamikus konfiguráció, sok kész szűrő, egyszerű felület a saját szűrők írásához.
Ebből az alkalmazási területek következnek, de először is van 2 antiminta:

• Statikus visszarúgás.

A tény az, hogy jelenleg in követ nincs gyorsítótár támogatás. A Google srácok ezt próbálják javítani. Az ötlet egyszer megvalósul követ az RFC-megfelelőség minden finomságát (zoo-fejlécét), és az egyes megvalósításokhoz interfészt készít. De egyelőre még nem is alfa, az építészetről folyik a vita, PR nyitott (amíg a PR cikket írtam, a PR lefagyott, de ez a pont továbbra is aktuális).

Egyelőre az nginx-et használd a statikához.

• Statikus konfiguráció.

Használhatod, de követ Nem erre hozták létre. A statikus konfigurációban lévő funkciók nem jelennek meg. Sok pillanat van:

Amikor yaml-ben szerkeszted a konfigurációt, tévedsz, szidni fogod a fejlesztőket a bőbeszédűségért, és úgy gondolod, hogy az nginx/haproxy konfigurációk, bár kevésbé strukturáltak, tömörebbek. Ez a lényeg. Az Nginx és a Haproxy konfigurációja kézzel szerkeszthető, és követ kódból való generáláshoz. A teljes konfiguráció leírása a protobuf, protofájlokból generálva sokkal nehezebb hibázni.

A Canary, a b/g telepítési forgatókönyvek és még sok más általában csak dinamikus konfigurációban valósul meg. Nem azt mondom, hogy ezt nem lehet statikusan megtenni, mindannyian ezt tesszük. De ehhez mankókat kell feltenni bármelyik kiegyensúlyozóba követ beleértve.

Feladatok, amelyekhez a Küldött nélkülözhetetlen:

• Forgalom kiegyenlítés összetett és dinamikus rendszerekben. Ez magában foglalja a szervizhálót is, de nem feltétlenül az egyetlen.
• Elosztott nyomkövetési funkciók, összetett engedélyezési vagy egyéb olyan funkciók iránti igény, amelyek elérhetők követ dobozból vagy kényelmesen megvalósítva, de az nginx/haproxy-ban lua-val és kétes bővítményekkel kell körülvenni.

Ha szükséges, mindkettő nagy teljesítményt biztosít.

Ez hogy működik

Az Envoy bináris fájlokban csak docker képként kerül terjesztésre. A kép már tartalmaz egy példát statikus konfigurációra. De minket csak a szerkezet megértése érdekel.

envoy.yaml statikus konfiguráció

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

Dinamikus konfiguráció

Milyen problémára keresünk megoldást? A terheléselosztó konfigurációját nem lehet csak úgy újratölteni terhelés alatt; „kis” problémák merülnek fel:

• Konfiguráció érvényesítése.

A konfig lehet nagy, lehet nagyon nagy, ha egyszerre túlterheljük, megnő az esélye, hogy valahol hiba lesz.

• Hosszú életű kapcsolatok.

Egy új hallgató inicializálása során ügyelni kell a régin futó kapcsolatokra, ha gyakran fordulnak elő változások és hosszú életű kapcsolatok vannak, akkor kompromisszumot kell keresni. Helló, kubernetes ingress az nginx-en.

• Aktív egészségügyi ellenőrzések.

Ha aktív állapotellenőrzéseink vannak, akkor az új konfigurációban mindegyiket duplán ellenőriznünk kell a forgalom elküldése előtt. Ha sok az upstream, ez időbe telik. Szia haproxy.

Hogyan van ez megoldva ben követA konfig dinamikus betöltésével, a pool modellnek megfelelően, külön részekre osztható, és nem inicializálható újra a nem változott rész. Például egy hallgató, amelynek újrainicializálása költséges és ritkán változik.

Configuration követ (a fenti fájlból) a következő entitásokkal rendelkezik:

• hallgató — egy adott ip/porton lógó hallgató
• virtuális gazdagép - virtuális gazdagép domain név szerint
• útvonal - egyensúlyozási szabály
• fürt — felfelé irányuló ágak csoportja kiegyenlítő paraméterekkel
• végpont — upstream példány címe

Ezen entitások mindegyike, valamint néhány másik dinamikusan kitölthető, ehhez a konfiguráció megadja annak a szolgáltatásnak a címét, ahonnan a konfiguráció érkezik. A szolgáltatás lehet REST vagy gRPC, a gRPC előnyösebb.

A szolgáltatások neve LDS, VHDS, RDS, CDS és EDS. Kombinálhatja a statikus és a dinamikus konfigurációt, azzal a korlátozással, hogy dinamikus erőforrás nem adható meg statikusban.

A legtöbb feladathoz elegendő az utolsó három szolgáltatás megvalósítása, ezek az úgynevezett ADS (Aggregated Discovery Service). Jáva és ott van a gRPC adatsík kész megvalósítása, amelyben csak ki kell töltenie az objektumokat a forrásból.

A konfiguráció a következő formában történik:

envoy.yaml dinamikus konfiguráció

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

Indításkor követ ezzel a konfigurációval csatlakozik a vezérlősíkhoz, és megpróbálja kérni az RDS, CDS és EDS konfigurációt. Le van írva, hogyan megy végbe az interakciós folyamat itt.

Röviden, követ kérést küld, amely jelzi a kért erőforrás típusát, a csomópont verzióját és paramétereit. Válaszul egy erőforrást és egy verziót kap, ha a vezérlősíkon lévő verzió nem változott, nem válaszol.
4 interakciós lehetőség van:

• Egy gRPC adatfolyam minden típusú erőforráshoz, az erőforrás teljes állapota elküldésre kerül.
• Külön patakok, teljes állapotban.
• Egy folyam, növekményes állapot.
• Külön folyamok, növekményes állapot.

Az inkrementális xDS lehetővé teszi a forgalom csökkentését a vezérlősík és a követ, ez a nagy konfigurációkra vonatkozik. De ez bonyolítja az interakciót: a kérelem tartalmazza a leiratkozáshoz és előfizetéshez szükséges erőforrások listáját.

Példánk az ADS-t használja – egy adatfolyam az RDS, CDS, EDS és nem növekményes módhoz. A növekményes mód engedélyezéséhez meg kell adnia api_type: DELTA_GRPC

Mivel a kérés csomóponti paramétereket tartalmaz, a különböző példányokhoz különböző erőforrásokat küldhetünk a vezérlősíkra követ, ez kényelmes egy szervizháló felépítéséhez.

Bemelegít

tovább követ indításkor vagy új konfiguráció fogadásakor a vezérlősíktól elindul az erőforrás-bemelegítési folyamat. Fel van osztva hallgató bemelegítésre és fürt bemelegítésre. Az első az RDS/LDS változása esetén indul el, a második a CDS/EDS esetén. Ez azt jelenti, hogy ha csak az upstreamek változnak, a hallgató nem jön létre újra.

A bemelegítési folyamat során függő erőforrások várhatók a vezérlősíktól az időtúllépés alatt. Ha az időtúllépés bekövetkezik, az inicializálás nem lesz sikeres, és az új figyelő nem kezdi el a figyelést a porton.
Inicializálási sorrend: EDS, CDS, aktív állapotfelmérés, RDS, LDS. Ha az aktív állapotellenőrzések engedélyezve vannak, a forgalom csak egy sikeres állapotellenőrzés után fog felfelé haladni.

Ha a figyelőt újra létrehozták, a régi DRAIN állapotba kerül, és az összes kapcsolat bezárása vagy az időkorlát lejárta után törlődik. --drain-time-s, alapértelmezett 10 perc.

Продолжение следует.

Forrás: will.com