ProHoster > Blog > Uprava > Odposlanec. 1. Uvod

Odposlanec. 1. Uvod

Pozdravi! To je kratek članek, ki odgovarja na vprašanja: "kaj je odposlanec?", "zakaj je potreben?" in "kje začeti?".

Kaj je to?

Envoy je balanser L4-L7, napisan v C++, osredotočen na visoko zmogljivost in razpoložljivost. Po eni strani je to na nek način analog nginxa in haproxyja, ki je po zmogljivosti primerljiv z njima. Po drugi strani pa je bolj usmerjen v arhitekturo mikrostoritev in ima funkcionalnost, ki ni slabša od java in go balancers, kot sta zuul ali traefik.

Primerjalna tabela haproxy/nginx/envoy, ne trdi, da je absolutna resnica, ampak daje splošno sliko.

nginx
haproksi
poslano
traefik

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

zapisano v
C
C
C + +
go

API
ne
samo vtičnica/push
dataplane/pull
potegnite

aktivni zdravstveni pregled
ne
ja
ja
ja

Odprto sledenje
zunanji vtičnik
ne
ja
ja

J.W.T.
zunanji vtičnik
ne
ja
ne

razširitev
Lua/C
Lua/C
Lua/C++
ne

Za kaj

To je mlad projekt, veliko stvari manjka, nekatere v zgodnji alfa fazi. Ampak poslano, tudi zaradi svoje mladosti, se hitro razvija in ima že veliko zanimivih funkcij: dinamično konfiguracijo, veliko že pripravljenih filtrov, preprost vmesnik za pisanje lastnih filtrov.
Iz tega sledijo področja uporabe, vendar najprej obstajata 2 antipatterna:

  • Statični odboj.

Dejstvo je, da trenutno v poslano brez podpore za predpomnjenje. Googlovi fantje to poskušajo popraviti. Ideja bo uresničena enkrat poslano vse podrobnosti (glave živalskega vrta) skladnosti z RFC in za posebne izvedbe naredite vmesnik. Ampak za zdaj še ni alfa, arhitektura je v razpravi, PR odprto (med pisanjem PR članka je PR zamrznil, vendar je ta točka še vedno aktualna).

Za zdaj uporabite nginx za statiko.

  • Statična konfiguracija.

Lahko ga uporabite, vendar poslano Ni bil ustvarjen za to. Funkcije v statični konfiguraciji ne bodo izpostavljene. Veliko je trenutkov:

Ko urejate konfiguracijo v yaml, se boste zmotili, grajali razvijalce zaradi dobesednosti in mislili, da so konfiguracije nginx/haproxy, čeprav manj strukturirane, bolj jedrnate. To je bistvo. Konfiguracija Nginx in Haproxy je bila ustvarjena za ročno urejanje in poslano za generiranje iz kode. Celotna konfiguracija je opisana v protobuf, je pri generiranju iz proto datotek veliko težje narediti napako.

Canary, scenariji uvajanja b/g in še veliko več se običajno izvaja samo v dinamični konfiguraciji. Ne pravim, da tega ni mogoče narediti statično, vsi to počnemo. Toda za to si morate nadeti bergle, v katerega koli od ravnotežij, v poslano tudi.

Naloge, pri katerih je Envoy nepogrešljiv:

  • Uravnoteženje prometa v kompleksnih in dinamičnih sistemih. To vključuje servisno mrežo, vendar ni nujno edina.
  • Potreba po funkciji porazdeljenega sledenja, kompleksni avtorizaciji ali drugi funkciji, ki je na voljo v poslano takoj po namestitvi ali priročno implementiran, toda v nginx/haproxy morate biti obkroženi z lua in dvomljivimi vtičniki.

Oba, če je potrebno, zagotavljata visoko zmogljivost.

Kako to deluje

Envoy se v binarnih datotekah distribuira samo kot slika dockerja. Slika že vsebuje primer statične konfiguracije. Vendar nas zanima samo zaradi razumevanja strukture.

statična konfiguracija 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

Dinamična konfiguracija

Za kakšen problem iščemo rešitev? Konfiguracije izravnalnika obremenitve ne morete preprosto znova naložiti pod obremenitvijo; pojavile se bodo "majhne" težave:

  • Preverjanje konfiguracije.

Konfiguracija je lahko velika, lahko je zelo velika, če jo preobremenimo naenkrat, se možnosti za napako kje povečajo.

  • Dolgotrajne povezave.

Pri inicializaciji novega poslušalca morate poskrbeti za povezave, ki delujejo na starem; če se spremembe pogosto pojavljajo in obstajajo dolgožive povezave, boste morali iskati kompromis. Pozdravljeni, kubernetes ingress na nginx.

  • Aktivni zdravstveni pregledi.

Če imamo aktivne preglede zdravja, jih moramo vse dvakrat preveriti v novi konfiguraciji, preden pošljemo promet. Če je gorvodnih veliko, to zahteva čas. Pozdravljeni haproxy.

Kako je to rešeno v poslanoZ dinamičnim nalaganjem konfiguracije v skladu z modelom bazena jo lahko razdelite na ločene dele in ne boste znova inicializirali dela, ki se ni spremenil. Na primer poslušalec, katerega ponovna inicializacija je draga in se redko spreminja.

Konfiguracija poslano (iz zgornje datoteke) ima naslednje entitete:

  • poslušalec — poslušalec visi na določenem ip/vratu
  • virtualni gostitelj - virtualni gostitelj po imenu domene
  • pot - pravilo uravnoteženja
  • grozd — skupina zgornjih tokov s parametri izravnave
  • končna točka — naslov instance navzgor

Vsako od teh entitet in nekatere druge je mogoče izpolniti dinamično; za to konfiguracija določa naslov storitve, od koder bo prejeta konfiguracija. Storitev je lahko REST ali gRPC, prednost je gRPC.

Storitve so poimenovane: LDS, VHDS, RDS, CDS in EDS. Kombinirate lahko statično in dinamično konfiguracijo, z omejitvijo, da dinamičnega vira ni mogoče podati v statičnem.

Za večino opravil zadostuje implementacija zadnjih treh storitev, imenujemo jih ADS (Aggregated Discovery Service), za Java In pojdite, obstaja že pripravljena izvedba podatkovne ravnine gRPC, v kateri morate samo izpolniti objekte iz svojega vira.

Konfiguracija ima naslednjo obliko:

dinamična konfiguracija 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

Ob zagonu poslano s to konfiguracijo se bo povezal z nadzorno ravnino in poskušal zahtevati konfiguracijo RDS, CDS in EDS. Opisano je, kako poteka interakcijski proces tukaj.

V kratkem, poslano pošlje zahtevo, ki navaja vrsto zahtevanega vira, različico in parametre vozlišča. Kot odgovor prejme vir in različico; če se različica na nadzorni ravnini ni spremenila, se ne odzove.
Obstajajo 4 možnosti interakcije:

  • En tok gRPC za vse vrste virov, pošlje se celotno stanje vira.
  • Ločeni tokovi, popolno stanje.
  • En tok, inkrementalno stanje.
  • Ločeni tokovi, inkrementalno stanje.

Inkrementalni xDS vam omogoča zmanjšanje prometa med nadzorno ravnino in poslano, to je pomembno za velike konfiguracije. Vendar otežuje interakcijo, zahteva vsebuje seznam virov za odjavo in naročnino.

Naš primer uporablja ADS - en tok za RDS, CDS, EDS in neinkrementalni način. Če želite omogočiti inkrementalni način, morate podati api_type: DELTA_GRPC

Ker zahteva vsebuje parametre vozlišča, lahko v nadzorno ravnino pošljemo različne vire za različne instance poslano, je to priročno za gradnjo servisne mreže.

Ogreti se

Na poslano ob zagonu ali ob prejemu nove konfiguracije iz nadzorne ravnine se zažene postopek ogrevanja virov. Razdeljeno je na ogrevanje poslušalca in ogrevanje grozda. Prvi se zažene, ko pride do sprememb v RDS/LDS, drugi pa ob CDS/EDS. To pomeni, da če se spremenijo samo navzgornji tokovi, poslušalec ni ponovno ustvarjen.

Med postopkom ogrevanja se od nadzorne ravnine med časovno omejitvijo pričakujejo odvisni viri. Če pride do časovne omejitve, inicializacija ne bo uspešna in novi poslušalec ne bo začel poslušati na vratih.
Vrstni red inicializacije: EDS, CDS, aktivni zdravstveni pregled, RDS, LDS. Z omogočenimi aktivnimi zdravstvenimi pregledi bo promet šel navzgor šele po enem uspešnem zdravstvenem pregledu.

Če je bil poslušalec znova ustvarjen, gre stari v stanje DRAIN in bo izbrisan, ko se prekinejo vse povezave ali poteče časovna omejitev --drain-time-s, privzeto 10 minut.

Se nadaljuje.

Vir: www.habr.com

Dodaj komentar