ProHoster > Blog > uprava > Izaslanik. 1. Uvod

Izaslanik. 1. Uvod

Lijep pozdrav! Ovo je kratki članak koji odgovara na pitanja: "što je izaslanik?", "zašto je potreban?" i "odakle početi?".

Što je ovo

Envoy je L4-L7 balanser napisan u C++, fokusiran na visoke performanse i dostupnost. S jedne strane, ovo je na neki način analog nginxa i haproxyja, usporediv u izvedbi s njima. S druge strane, više je orijentiran na mikroservisnu arhitekturu i ima funkcionalnost ništa lošiju od java i go balansera, kao što su zuul ili traefik.

Tablica usporedbe haproxy/nginx/envoy, ne tvrdi da je apsolutna istina, ali daje opću sliku.

Nginx
haproksi
poslao
traefik

zvijezde na githubu
11.2k/ogledalo
1.1k/ogledalo
12.4k
27.6k

napisano u
C
C
C + +
go

API
ne
samo utičnica/push
dataplane/pull
povući

aktivni zdravstveni pregled
ne
da
da
da

Otvoreno praćenje
vanjski dodatak
ne
da
da

J.W.T.
vanjski dodatak
ne
da
ne

nastavak
Lua/C
Lua/C
Lua/C++
ne

Što za

Ovo je mlad projekt, puno stvari nedostaje, neke u ranoj alfa fazi. Ali poslao, također zbog svoje mladosti, brzo se razvija i već ima mnogo zanimljivih značajki: dinamičku konfiguraciju, mnoge gotove filtere, jednostavno sučelje za pisanje vlastitih filtera.
Područja primjene slijede iz ovoga, ali prvo postoje 2 antiuzorka:

  • Statički trzaj.

Činjenica je da trenutno u poslao nema podrške za predmemoriju. Googleovi dečki pokušavaju ovo popraviti. Ideja će biti implementirana jednom poslao sve suptilnosti (zoo zaglavlja) usklađenosti s RFC-om, a za specifične implementacije napraviti sučelje. Ali za sada nije čak ni alfa, arhitektura je u raspravi, PR otvoren (dok sam pisao PR članak, PR se zamrznuo, ali ova točka je još uvijek relevantna).

Za sada koristite nginx za statiku.

  • Statička konfiguracija.

Možete ga koristiti, ali poslao Nije za to stvoreno. Značajke u statičkoj konfiguraciji neće biti izložene. Ima mnogo trenutaka:

Kada uređujete konfiguraciju u yamlu, griješit ćete, grditi programere zbog opširnosti i misliti da su nginx/haproxy konfiguracije, iako manje strukturirane, konciznije. To je bit. Konfiguracija Nginxa i Haproxyja stvorena je za ručno uređivanje i poslao za generiranje iz koda. Cijela konfiguracija je opisana u protobuf, mnogo je teže pogriješiti generiranjem iz proto datoteka.

Canary, b/g scenariji implementacije i još mnogo toga obično se implementiraju samo u dinamičkoj konfiguraciji. Ne kažem da se to ne može raditi statično, svi to radimo. Ali za ovo morate staviti štake, u bilo koji od balansera, u poslao uključujući.

Zadaci za koje je Envoy neophodan:

  • Balansiranje prometa u složenim i dinamičkim sustavima. To uključuje servisnu mrežu, ali nije nužno jedina.
  • Potreba za funkcijom distribuiranog praćenja, složenom autorizacijom ili drugom funkcijom koja je dostupna u poslao izvan okvira ili prikladno implementiran, ali u nginx/haproxy morate biti okruženi lua i sumnjivim dodacima.

Oba, ako je potrebno, pružaju visoke performanse.

Kako ovo radi

Envoy se distribuira u binarnim datotekama samo kao docker slika. Slika već sadrži primjer statičke konfiguracije. Ali nas to zanima samo radi razumijevanja strukture.

izaslanik.yaml statička konfiguracija

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

Dinamička konfiguracija

Za koji problem tražimo rješenje? Ne možete samo ponovno učitati konfiguraciju balansera opterećenja pod opterećenjem; pojavit će se "mali" problemi:

  • Provjera valjanosti konfiguracije.

Konfiguracija može biti velika, može biti jako velika, ako je preopteretimo odjednom, povećavaju se šanse za grešku negdje.

  • Dugotrajne veze.

Prilikom inicijalizacije novog slušatelja, morate voditi računa o vezama koje rade na starom; ako se promjene događaju često i postoje dugotrajne veze, morat ćete tražiti kompromis. Pozdrav, kubernetes ingress na nginx.

  • Aktivni zdravstveni pregledi.

Ako imamo aktivne provjere zdravlja, moramo ih još jednom provjeriti u novoj konfiguraciji prije slanja prometa. Ako postoji mnogo uzvodnih tokova, potrebno je vrijeme. Pozdrav haproxy.

Kako je to riješeno u poslaoDinamičkim učitavanjem konfiguracije, prema modelu bazena, možete je podijeliti u zasebne dijelove i ne inicijalizirati ponovno dio koji nije promijenjen. Na primjer, slušatelj, čije je ponovno inicijaliziranje skupo i rijetko se mijenja.

Konfiguracija poslao (iz gornje datoteke) ima sljedeće entitete:

  • slušalac — slušatelj koji visi na određenom ip/portu
  • virtualni host - virtualni host prema nazivu domene
  • put - pravilo balansiranja
  • grozd — skupina uzvodnih tokova s ​​parametrima uravnoteženja
  • krajnja — upstream adresa instance

Svaki od ovih entiteta plus neki drugi mogu se ispuniti dinamički; za to konfiguracija specificira adresu usluge s koje će biti primljena konfiguracija. Usluga može biti REST ili gRPC, gRPC je poželjan.

Usluge se redom nazivaju: LDS, VHDS, RDS, CDS i EDS. Možete kombinirati statičku i dinamičku konfiguraciju, uz ograničenje da se dinamički resurs ne može navesti u statičkom.

Za većinu zadataka dovoljno je implementirati posljednje tri usluge, one se zovu ADS (Aggregated Discovery Service), za Java i idemo, postoji gotova implementacija gRPC dataplanea u kojoj samo trebate ispuniti objekte iz svog izvora.

Konfiguracija ima sljedeći oblik:

izaslanik.yaml dinamička konfiguracija

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

Prilikom pokretanja poslao s ovom konfiguracijom, spojit će se na upravljačku razinu i pokušati zatražiti RDS, CDS i EDS konfiguraciju. Opisuje se kako se odvija proces interakcije здесь.

Ukratko, poslao šalje zahtjev koji ukazuje na vrstu traženog resursa, verziju i parametre čvora. Kao odgovor prima resurs i verziju; ako se verzija na kontrolnoj ravni nije promijenila, ne odgovara.
Postoje 4 opcije interakcije:

  • Jedan gRPC tok za sve vrste resursa, šalje se puni status resursa.
  • Odvojeni tokovi, full stanje.
  • Jedan tok, inkrementalno stanje.
  • Odvojeni tokovi, inkrementalno stanje.

Inkrementalni xDS omogućuje smanjenje prometa između kontrolne ravnine i poslao, ovo je relevantno za velike konfiguracije. Ali to komplicira interakciju; zahtjev sadrži popis resursa za otkazivanje pretplate i pretplatu.

Naš primjer koristi ADS - jedan tok za RDS, CDS, EDS i neinkrementalni način rada. Da biste omogućili inkrementalni način rada, morate navesti api_type: DELTA_GRPC

Budući da zahtjev sadrži parametre čvora, možemo poslati različite resurse u upravljačku razinu za različite instance poslao, ovo je prikladno za izgradnju servisne mreže.

Zagrijati se

Na poslao prilikom pokretanja ili primanja nove konfiguracije iz upravljačke ravnine, pokreće se proces zagrijavanja resursa. Dijeli se na zagrijavanje slušatelja i zagrijavanje klastera. Prvi se pokreće kada postoje promjene u RDS/LDS, drugi kada CDS/EDS. To znači da ako se mijenjaju samo uzvodni tokovi, slušatelj se ne stvara ponovno.

Tijekom procesa zagrijavanja očekuju se ovisni resursi iz kontrolne razine tijekom vremenskog ograničenja. Ako istekne vrijeme, inicijalizacija neće biti uspješna i novi slušatelj neće početi slušati na priključku.
Redoslijed inicijalizacije: EDS, CDS, aktivna provjera zdravlja, RDS, LDS. S uključenim aktivnim provjerama ispravnosti, promet će ići uzvodno tek nakon jedne uspješne provjere ispravnosti.

Ako je slušatelj ponovno stvoren, stari ide u DRAIN stanje i bit će izbrisan nakon zatvaranja svih veza ili isteka vremena čekanja --drain-time-s, zadano 10 minuta.

Nastaviti.

Izvor: www.habr.com

Dodajte komentar