Lähettiläs. 1. Esittely

Terveisiä! Tämä on lyhyt artikkeli, joka vastaa kysymyksiin: "mikä on lähettiläs?", "Miksi sitä tarvitaan?" ja "mistä aloittaa?".

Mikä tämä on?

Envoy on C++-kielellä kirjoitettu L4-L7-tasapainotin, joka keskittyy korkeaan suorituskykyyn ja käytettävyyteen. Toisaalta tämä on jollain tapaa nginxin ja haproxyn analogi, suorituskyvyltään verrattavissa niihin. Toisaalta se on enemmän mikropalveluarkkitehtuuriin suuntautunut ja sen toiminnallisuus ei ole huonompi kuin java and go balancers, kuten zuul tai traefik.

Vertailutaulukko haproxy/nginx/envoy, se ei väitä olevan absoluuttinen totuus, mutta antaa yleiskuvan.

Nginx
haproxy
lähettiläs
traefik

tähdet githubissa
11.2k/peili
1.1k/peili
12.4 km
27.6 km

kirjoitettu sisään
C
C
C + +
go

API
ei
vain pistorasia/työntö
datataso/veto
vetää

aktiivinen terveystarkastus
ei
kyllä
kyllä
kyllä

Avaa jäljitys
ulkoinen laajennus
ei
kyllä
kyllä

J.W.T.
ulkoinen laajennus
ei
kyllä
ei

laajentaminen
Lua/C
Lua/C
Lua/C++
ei

Mitä varten

Tämä on nuori projekti, josta puuttuu paljon asioita, joista osa on alkuvaiheessa. Mutta lähettiläs, myös nuoruudestaan ​​johtuen, kehittyy nopeasti ja sillä on jo monia mielenkiintoisia ominaisuuksia: dynaaminen konfigurointi, monia valmiita suodattimia, yksinkertainen käyttöliittymä omien suodattimien kirjoittamiseen.
Sovellusalueet seuraavat tästä, mutta ensin on olemassa 2 antimallia:

• Staattinen rekyyli.

Tosiasia on, että tällä hetkellä sisään lähettiläs ei välimuistin tukea. Googlen kaverit yrittävät tätä korjata. Idea toteutetaan kerran lähettiläs kaikki RFC-yhteensopivuuden hienoisuudet (zoo-otsikot) ja tee rajapinta tiettyjä toteutuksia varten. Mutta toistaiseksi se ei ole edes alfa, arkkitehtuurista keskustellaan, PR auki (kun kirjoitin PR-artikkelia, PR jumiutui, mutta tämä kohta on edelleen ajankohtainen).

Käytä toistaiseksi nginxiä statiikkaan.

• Staattinen kokoonpano.

Voit käyttää sitä, mutta lähettiläs Sitä varten se ei ole luotu. Staattisen kokoonpanon ominaisuuksia ei paljasteta. On monia hetkiä:

Kun muokkaat kokoonpanoa yamlissa, erehdyt, moitit kehittäjiä monisanaisuudesta ja luulet, että nginx/haproxy-konfiguraatiot, vaikka ne ovat vähemmän jäsenneltyjä, ovat tiiviimpiä. Se on asian ydin. Nginxin ja Haproxyn konfiguraatio luotiin käsin muokkaamista varten ja lähettiläs koodista luomiseen. Koko kokoonpano on kuvattu kohdassa protobuf, sen luominen prototiedostoista on paljon vaikeampaa tehdä virhe.

Canary-, b/g-käyttöönottoskenaariot ja paljon muuta toteutetaan yleensä vain dynaamisissa kokoonpanoissa. En väitä, etteikö tätä voisi tehdä staattisesti, me kaikki teemme sen. Mutta tätä varten sinun on asetettava kainalosauvat mihin tahansa tasapainottimeen lähettiläs mukaan lukien.

Tehtävät, joissa lähettiläs on välttämätön:

• Liikenteen tasapainottaminen monimutkaisissa ja dynaamisissa järjestelmissä. Tämä sisältää palveluverkon, mutta se ei välttämättä ole ainoa.
• Hajautetun jäljitystoiminnon, monimutkaisen valtuutuksen tai muiden käytettävissä olevien toimintojen tarve lähettiläs käyttövalmis tai kätevästi toteutettu, mutta nginx/haproxyssa sinun on oltava lua- ja epäilyttäviä laajennuksia ympäröimä.

Molemmat tarjoavat tarvittaessa korkean suorituskyvyn.

Kuinka tämä toimii

Envoy jaetaan binäärimuodossa vain Docker-kuvana. Kuvassa on jo esimerkki staattisesta kokoonpanosta. Mutta olemme kiinnostuneita siitä vain rakenteen ymmärtämiseksi.

envoy.yaml staattinen kokoonpano

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

Dynaaminen konfigurointi

Mihin ongelmaan etsimme ratkaisua? Et voi vain ladata kuormituksen tasapainottimen kokoonpanoa uudelleen kuormitettuna; "pieniä" ongelmia syntyy:

• Kokoonpanon validointi.

Kokoonpano voi olla suuri, se voi olla erittäin suuri, jos ylikuormitamme sen kerralla, virheen mahdollisuus jossain kasvaa.

• Pitkäikäiset yhteydet.

Uutta kuuntelijaa alustettaessa on huolehdittava vanhalla ajettavista yhteyksistä, jos muutoksia tapahtuu usein ja yhteyksiä on pitkäkestoisia, joutuu etsimään kompromissia. Hei, kubernetes ingress on nginx.

• Aktiiviset terveystarkastukset.

Jos meillä on aktiivisia terveystarkastuksia, meidän on tarkistettava ne kaikki uudessa kokoonpanossa ennen liikenteen lähettämistä. Jos ylävirtaa on paljon, tämä vie aikaa. Hei haproxy.

Miten tämä on ratkaistu lähettiläsLataamalla konfiguraation dynaamisesti, poolimallin mukaan, voit jakaa sen erillisiin osiin etkä alusta uudelleen sitä osaa, joka ei ole muuttunut. Esimerkiksi kuuntelija, jonka uudelleenalustaminen on kallista ja muuttuu harvoin.

kokoonpano lähettiläs (yllä olevasta tiedostosta) sisältää seuraavat entiteetit:

• kuuntelija — Tietyssä ip/portissa riippuva kuuntelija
• virtuaalinen isäntä - virtuaalinen isäntä verkkotunnuksen nimellä
• reitti - tasapainotussääntö
• klusteri — joukko alkupään osia tasapainotusparametreineen
• päätepiste — ylävirran ilmentymän osoite

Jokainen näistä ja joitain muita entiteettejä voidaan täyttää dynaamisesti; tätä varten konfiguraatio määrittää palvelun osoitteen, josta konfiguraatio vastaanotetaan. Palvelu voi olla REST tai gRPC, gRPC on parempi.

Palvelut on nimetty vastaavasti: LDS, VHDS, RDS, CDS ja EDS. Voit yhdistää staattisen ja dynaamisen konfiguroinnin sillä rajoituksella, että dynaamista resurssia ei voi määrittää staattiseen.

Useimpiin tehtäviin riittää, että toteutat kolme viimeistä palvelua, joita kutsutaan nimellä ADS (Aggregated Discovery Service). Jaava ja mene sinne on valmis toteutus gRPC-tietotasosta, jossa sinun tarvitsee vain täyttää objektit lähteestäsi.

Kokoonpano on seuraavassa muodossa:

envoy.yaml dynaaminen kokoonpano

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

Käynnistyksen yhteydessä lähettiläs tällä asetuksella se muodostaa yhteyden ohjaustasoon ja yrittää pyytää RDS-, CDS- ja EDS-kokoonpanoa. Miten vuorovaikutusprosessi tapahtuu, kuvataan täällä.

Lyhyesti, lähettiläs lähettää pyynnön, joka ilmoittaa pyydetyn resurssin tyypin, solmun version ja parametrit. Vastauksena se saa resurssin ja version; jos ohjaustason versio ei ole muuttunut, se ei vastaa.
Vuorovaikutusvaihtoehtoja on 4:

• Yksi gRPC-virta kaikentyyppisille resursseille, resurssin koko tila lähetetään.
• Erilliset streamit, täysi kunto.
• Yksi virtaus, inkrementaalinen tila.
• Erilliset virrat, inkrementaalinen tila.

Inkrementaalisen xDS:n avulla voit vähentää liikennettä ohjaustason ja ohjaustason välillä lähettiläs, tämä koskee suuria kokoonpanoja. Mutta se vaikeuttaa vuorovaikutusta: pyyntö sisältää luettelon tilauksen peruuttamista ja tilaamista varten tarvittavista resursseista.

Esimerkkimme käyttää ADS:ää - yksi stream RDS-, CDS-, EDS- ja ei-inkrementaalitilassa. Jos haluat ottaa inkrementaalisen tilan käyttöön, sinun on määritettävä api_type: DELTA_GRPC

Koska pyyntö sisältää solmuparametreja, voimme lähettää ohjaustasolle erilaisia ​​resursseja eri esiintymiä varten lähettiläs, tämä on kätevä palveluverkon rakentamiseen.

Lämmitellä

Päälle lähettiläs käynnistettäessä tai kun uusi konfiguraatio vastaanotetaan ohjaustasolta, resurssien lämmitysprosessi käynnistetään. Se on jaettu kuuntelijan lämmittelyyn ja klusterin lämmittelyyn. Ensimmäinen käynnistyy, kun RDS/LDS:ssä on muutoksia, toinen kun CDS/EDS. Tämä tarkoittaa, että jos vain ylävirtaukset muuttuvat, kuuntelijaa ei luoda uudelleen.

Lämmitysprosessin aikana ohjaustasolta odotetaan riippuvia resursseja aikakatkaisun aikana. Jos aikakatkaisu tapahtuu, alustus ei onnistu eikä uusi kuuntelija aloita kuuntelua portissa.
Alustusjärjestys: EDS, CDS, aktiivinen terveystarkastus, RDS, LDS. Kun aktiiviset terveystarkastukset ovat käytössä, liikenne siirtyy vastavirtaan vasta yhden onnistuneen terveystarkastuksen jälkeen.

Jos kuuntelija luotiin uudelleen, vanha siirtyy DRAIN-tilaan ja poistetaan, kun kaikki yhteydet on suljettu tai aikakatkaisu umpeutuu. --drain-time-s, oletuksena 10 minuuttia.

Jatkettava.

Lähde: will.com