ProHoster > Блог > Administracija > Izaslanik. 1. Uvod

Izaslanik. 1. Uvod

Pozdrav! Ovo je kratak članak koji odgovara na pitanja: "šta je izaslanik?", "zašto je potreban?" i "gdje početi?".

Šta je ovo

Envoy je L4-L7 balanser napisan na C++, fokusiran na visoke performanse i dostupnost. S jedne strane, ovo je na neki način analog nginx-a i haproxy-ja, uporediv po performansama s njima. S druge strane, više je orijentisan na mikroservisnu arhitekturu i ima funkcionalnost ništa lošiju od java and go balansera, kao što su zuul ili traefik.

Tabela poređenja haproxy/nginx/envoy, ne tvrdi da je apsolutna istina, ali daje opštu sliku.

nginx
haproksi
poslao
traefik

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

upisano u
C
C
C ++
go

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

aktivni zdravstveni pregled
ne
da
da
da

Otvoreno praćenje
eksterni dodatak
ne
da
da

J.W.T.
eksterni dodatak
ne
da
ne

produžetak
Lua/C
Lua/C
Lua/C++
ne

Za šta

Ovo je mlad projekat, dosta stvari nedostaje, neke su u ranoj alfi. Ali poslao, takođe zbog svoje mladosti, brzo se razvija i već ima mnogo zanimljivih karakteristika: dinamičku konfiguraciju, mnogo gotovih filtera, jednostavan interfejs za pisanje sopstvenih filtera.
Iz ovoga proizilaze područja primjene, ali prvo postoje 2 antiobrasci:

  • Statički trzaj.

Činjenica je da u ovom trenutku u poslao nema podrške za keširanje. Guglovi ovo pokušavaju popraviti. Ideja će biti realizovana jednom poslao sve suptilnosti (zoo zaglavlja) RFC usklađenosti, a za specifične implementacije napraviti interfejs. Ali za sada nije ni alfa, o arhitekturi se raspravlja, PR otvoren (dok sam pisao PR članak, PR se zamrznuo, ali ova tačka je i dalje relevantna).

Za sada koristite nginx za statiku.

  • Statička konfiguracija.

Možete ga koristiti, ali poslao Nije za to stvoren. Karakteristike u statičkoj konfiguraciji neće biti izložene. Postoji mnogo trenutaka:

Kada uređujete konfiguraciju u yaml-u, pogriješit ćete, prekoriti programere za opširnost i misliti da su nginx/haproxy konfiguracije, iako manje strukturirane, sažetije. To je poenta. Konfiguracija Nginxa i Haproxyja kreirana je za ručno uređivanje i poslao za generisanje iz koda. Cijela konfiguracija je opisana u protobuf, generisanjem iz proto fajlova je mnogo teže napraviti grešku.

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 to morate staviti štake, u bilo koji od balansera, unutra poslao uključujući.

Poslovi za koje je izaslanik neophodan:

  • Balansiranje saobraćaja u složenim i dinamičkim sistemima. Ovo uključuje servisnu mrežu, ali nije nužno jedina.
  • Potreba za distribuiranom funkcionalnošću praćenja, složenom autorizacijom ili drugom funkcionalnošću koja je dostupna u poslao iz kutije ili praktično 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čne konfiguracije. Ali nas to zanima samo radi razumijevanja strukture.

envoy.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 jednostavno ponovo učitati konfiguraciju balansera opterećenja pod opterećenjem; pojavit će se "mali" problemi:

  • Validacija konfiguracije.

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

  • Dugovječne veze.

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

  • Aktivni zdravstveni pregledi.

Ako imamo aktivne zdravstvene provjere, moramo ih sve još jednom provjeriti u novoj konfiguraciji prije slanja prometa. Ako ima puno uzvodnih tokova, za ovo treba vremena. Zdravo haproxy.

Kako je to riješeno u poslaoDinamičkim učitavanjem konfiguracije, prema modelu bazena, možete je podijeliti na odvojene dijelove i ne ponovo inicijalizirati dio koji se nije promijenio. Na primjer, slušalac, koji je skup za reinicijalizaciju i rijetko se mijenja.

Konfiguracija poslao (iz fajla iznad) ima sljedeće entitete:

  • slušalac — slušalac visi na određenom IP-u/portu
  • virtuelni host - virtuelni host po imenu domene
  • ruta - pravilo balansiranja
  • jato — grupa uzvodnih s parametrima balansiranja
  • krajnja tačka — upstream adresa instance

Svaki od ovih entiteta plus neki drugi mogu se popuniti dinamički; za to konfiguracija specificira adresu servisa odakle će biti primljena konfiguracija. Usluga može biti REST ili gRPC, gRPC je poželjniji.

Servisi su imenovani redom: 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 specificirati u statičkom.

Za većinu zadataka dovoljno je implementirati posljednja tri servisa, oni se zovu ADS (Aggregated Discovery Service), jer Java i idite tamo je gotova implementacija gRPC dataplane u kojoj samo trebate popuniti objekte iz vašeg izvora.

Konfiguracija ima sljedeći oblik:

envoy.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 sa ovom konfiguracijom, on će se povezati sa kontrolnom ravninom i pokušati da zatraži RDS, CDS i EDS konfiguraciju. Opisano je kako se odvija proces interakcije ovdje.

Ukratko, poslao šalje zahtjev koji ukazuje na tip resursa koji se traži, 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, potpuno stanje.
  • Jedan tok, inkrementalno stanje.
  • Odvojeni tokovi, inkrementalno stanje.

Inkrementalni xDS vam omogućava da smanjite promet između kontrolne ravni i poslao, ovo je relevantno za velike konfiguracije. Ali to komplikuje interakciju; zahtjev sadrži listu resursa za odjavu i pretplatu.

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

Pošto zahtjev sadrži parametre čvora, možemo slati različite resurse na kontrolnu ravan za različite instance poslao, ovo je pogodno za izgradnju servisne mreže.

Zagrijavanje

U poslao pri pokretanju ili kada primite novu konfiguraciju iz kontrolne ravni, pokreće se proces zagrijavanja resursa. Dijeli se na zagrijavanje slušatelja i zagrijavanje klastera. Prvi se pokreće kada dođe do promjena u RDS/LDS, drugi kada CDS/EDS. To znači da ako se samo uzvodni promijene, slušatelj neće biti ponovo kreiran.

Tokom procesa zagrijavanja, zavisni resursi se očekuju od kontrolne ravni za vrijeme isteka. Ako dođe do isteka vremena, inicijalizacija neće biti uspješna i novi slušatelj neće početi slušati na portu.
Redoslijed inicijalizacije: EDS, CDS, aktivni zdravstveni pregled, RDS, LDS. Uz omogućene aktivne provjere zdravlja, promet će ići uzvodno samo nakon jedne uspješne zdravstvene provjere.

Ako je slušatelj ponovo kreiran, stari prelazi u stanje DRAIN i bit će obrisan nakon što se sve veze zatvore ili istekne vremensko ograničenje --drain-time-s, zadano 10 minuta.

Nastaviti.

izvor: www.habr.com

Dodajte komentar