ProHoster > Blogi > Haldamine > Envoy. 1. Sissejuhatus

Envoy. 1. Sissejuhatus

Tere! See on väike artikkel, mis vastab küsimustele: "mis on envoy?", "miks see vajalik on?" ja "kust alustada?".

Mis see on

Envoy on L4-L7 taseme laadija, mis on kirjutatud C++ keeles, keskendudes kõrgele jõudlusele ja kättesaadavusele. Ühelt poolt on see teatud mõttes sarnane nginx-ile ja haproxy-le, võrreldav nendega jõudluse järgi. Teiselt poolt on see suunatud rohkem mikroteenuste arhitektuurile ja omab funktsioone, mis ei jää viletsaks Java ja Go taseme laadijatele, nagu zuul või traefik.

haproxy/nginx/envoy võrdlustabel, mis ei pretendeeri absoluutsele tõele, kuid annab üldise ülevaate.

nginx
haproxy
envoy
traefik

tähed githubis
11.2k/mirror
1.1k/mirror
12.4k
27.6k

kirjutas
C
C
C++
go

API
ei
ainult socket/push
andmeplaan/pull
pull

aktiivne tervisekontroll
ei
jah
jah
jah

Ava jälgimine
väline plugin
ei
jah
jah

JWT
väline plugin
ei
jah
ei

Laien
Lua/C
Lua/C
Lua/C++
ei

Miks

See on noor projekt, kus on palju, mida ei ole, ja mõned asjad on varases alfa faasis. Kuid envoy, sealhulgas selle noore ea tõttu, areneb see kiiresti ja omab juba palju huvitavaid võimalusi: dünaamiline konfiguratsioon, palju valmis filtreid, lihtne liides oma filtrite kirjutamiseks.
Seetõttu tulenevad rakenduse valdkonnad, kuid alustuseks 2 antimalemist:

  • staatika andmine.

Asjaolu on see, et hetkel ei ole envoy toetust vahemälu hoidmisele. Google’i mehed üritavad seda parandada. Idee on ühtselt rakendada kõik RFC nõuete vastavuse nüansid (peajoont jahtides) ja teha konkreetsete rakenduste jaoks liides. Kuid hetkel ei ole see isegi alfa, arhitektuur on arutamisel, envoy avatud (kui ma artiklit kirjutasin, siis PR liideti, kuid see punkt on endiselt aktuaalne). PR Ja seni kasutage staatika jaoks nginx-i.

Staatiline konfiguratsioon.

  • Seda saab kasutada, kuid

see ei olnud selleks loodud. Staatilise konfiguratsiooni võimalusi ei avata. Asju on palju: envoy YAML-is konfiguratsiooni redigeerides eksite, needite arendajaid sõnakasutuse üle ja mõtle, et nginx/haproxy konfiguratsioonid, kuigi vähem struktureeritud, on lakoonilisemad. Just selles on asi. Nginx ja Haproxy konfiguratsioon loodi käsitsi redigeerimiseks, aga

genereerimiseks koodist. Terve konfiguratsioon on kirjeldatud envoy , genereerides seda proto-failidest, on eksida palju keerulisem. protobufCanary, b/g juurutamise stsenaariumid ja palju muud, rakenduvad normaalselt ainult dünaamilises konfiguratsioonis. Ma ei ütle, et seda ei saaks teha staatilises, me teeme seda kõik. Kuid selleks tuleb kasutada asendusi, ükskõik kumba laadijat,

sealhulgas. envoy Ülesanded, kus Envoy on asendamatu:

Задачи в которых Envoy незаменим:

  • Liikluskoormuse tasakaalustamine keerulistes ja dünaamilistes süsteemides. Siia kuulub service mesh, kuid see ei piirdub ainult sellega.
  • Jagatud jälgimise, keerulise autoriseerimise või muu funktsiooni vajadus, mis on olemas envoy kastist väljas või on mugavalt teostatav, samas kui nginx/haproxy puhul tuleb kasutada lua't ja kahtlaseid pluginaid.

Mõlemad võimaldavad vajadusel tagada kõrge jõudluse.

Kuidas see töötab

Envoy'd levitatakse ainult binaaride kujul docker pildina. Pildis on juba näide staatilisest konfiguratsioonist. Kuid meid huvitab see ainult struktuuri mõistmiseks.

envoy.yaml staatiline konfiguratsioon

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
    # Kommentaarige järgmine rida välja, et testida v6 võrkudes
    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

Dünaamiline konfiguratsioon

Millise probleemi lahendamist me otsime? Ei saa lihtsalt võtta ja taastada koormajate konfiguratsiooni koormuse all, see tekitab 'väikeseid' probleeme:

  • Konfiguratsiooni valideerimine.

Konfiguratsioon võib olla suur, isegi väga suur, kui me laadime selle korraga uuesti, kasvab tõenäosus, et kuskil on viga.

  • Pikaajalised ühendused.

Uue kuulaja initsialiseerimisel tuleb hoolitseda vanades funktsioneerivate ühenduste eest, kui muudatused toimuvad sageli ja on pikaajalisi ühendusi, tuleb leida kompromiss. Tere, kubernetes ingress nginx'il.

  • Aktiivsed tervisekontrollid.

Kui meil on aktiivsed tervisekontrollid, tuleb need kõik uue konfiguratsiooni korral enne liikluse edastamist ümber kontrollida. Kui upstream'e on palju, võtab see aega. Tere, haproxy.

Kuidas seda lahendatakse envoy, laadides konfiguratsiooni dünaamiliselt, mudeli pimeda kaudu, saab jagada selle eraldi osadeks ja mitte reinitsialiseerida osa, mis ei ole muutunud. Näiteks listener, mille reinitsialiseerimine on kallis, muutub harva.

Konfiguratsioon envoy (ülemisest failist) sisaldab järgmisi üksuseid:

  • listener — listener, mis on seotud teatud ip/portiga
  • virtual host — virtuaalne host domeeninime järgi
  • route — tasakaalustamise reegel
  • cluster — grupi upstreamide tasakaalustamisparameetrid
  • endpoint — upstreami instantsi aadress

Igaüht neist üksustest, pluss mõned teised, saab täita dünaamiliselt, selleks määratakse konfiguratsioonis teenuse aadress, kust saadakse konfiguratsioon. Teenus võib olla REST või gRPC, eelistatult kasutada gRPC-d.

Teenuseid nimetatakse vastavalt: LDS, VHDS, RDS, CDS ja EDS. Saate kombineerida staatilist ja dünaamilist konfiguratsiooni, piiranguga, et dünaamilist ressursi ei saa määrata staatiliseks.

Enamikuks ülesannetest on piisav rakendada kolme viimast teenust, neid nimetatakse ADS (Kumulatiivne Leidmisteenus), java ja go-l on olemas valmis gRPC dataplane'i rakendus, kus piisab ainult objektide täitmisest oma allikast.

Konfiguratsioon omandab järgmise kuju:

envoy.yaml dünaamiline konfiguratsioon

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äivitamisel envoy selle konfiguratsiooniga, ta ühendub control-plane'iga ja proovib küsida RDS, CDS ja EDS konfiguratsiooni. Kuidas toimingud toimuvad on kirjeldatud siin.

Lühidalt öeldes, envoy saadetakse päring, kus on näidatud küsitava ressursi tüüp, versioon ja node'i parameetrid. Vastuseks saadakse ressurss ja versioon, kui control-plane'i versioon ei ole muutunud, ei vastata.
On 4 varianti suhtlemiseks:

  • Üks gRPC stream kõigi ressursside tüüpide jaoks, saadetakse kogu ressursi seisund.
  • Eraldi voogud, täielik olek.
  • Üks voog, inkrementealne olek.
  • Eraldi voogud, inkrementealne olek.

Inkrementealne xDS aitab vähendada liiklust juhtimisplaadi ja envoy, see on asjakohane suurte konfiguratsioonide korral. Kuid see keerutab suhtlemist, kuna päringus edastatakse ressursid, millele soovitakse tellimuse lõpetamist ja tellimist.

Meie näites kasutatakse ADS-i — üks voog RDS, CDS, EDS jaoks ja mitte-inkrementealne režiim. Inkrementealse režiimi aktiveerimiseks tuleb määrata api_type: DELTA_GRPC

Kuna päringus on sõlme parameetrid, saame juhtimisplaadile saata erinevaid ressursse erinevate instantside jaoks envoy, see on mugav teenuse mesh'i ülesehitamiseks.

Soojendus

Pealehe envoy käivitub alustamisel või uue konfiguratsiooni saamisel juhtimisplaadilt, algab ressurside soojendamise protsess. See jaguneb kuulajate soojendamiseks ja klastrite soojendamiseks. Esimene käivitub RDS/LDS muudatuste korral, teine CDS/EDS korral. See tähendab, et kui ülesvoolud muutuvad, ei uuendata kuulajat.

Soojendamise protsessi käigus oodatakse juhtimisplaadilt sõltuvaid ressursse ajutise ühisettepaneku jooksul. Kui tähtaeg on möödunud ja algatamine ei õnnestu, ei hakka uus kuulaja porti kuulama.
Algatamise järjekord: EDS, CDS, aktiivne tervisekontroll, RDS, LDS. Aktiivsete tervisekontrollide korral suunatakse liiklus ülesvoolu alles pärast ühte edukat tervisekontrolli.

Kui kuulaja uuendati, läheb vana DRAIN olekusse ja see eemaldatakse pärast kõigi ühenduste sulgemist või ajutise ühisettepaneku möödumist. --drain-time-s, vaikimisi 10 minutit.

Jätkub.

Allikas: habr.com

Osta usaldusväärne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne hostimine veebilehtede jaoks DDoS-i kaitsega, VPS VDS serverid | ProHoster