ProHoster > Blog > administrasie > Gesant. 1. Inleiding

Gesant. 1. Inleiding

Groete! Hierdie is 'n kort artikel wat die vrae beantwoord: "wat is gesant?", "waarom is dit nodig?" en "waar om te begin?".

Wat is dit

Envoy is 'n L4-L7 balanseerder geskryf in C++, gefokus op hoë werkverrigting en beskikbaarheid. Aan die een kant is dit op een of ander manier 'n analoog van nginx en haproxy, vergelykbaar in prestasie met hulle. Aan die ander kant is dit meer gerig op mikrodiensargitektuur en het funksionaliteit nie erger as java en go-balanseerders, soos zuul of traefik nie.

Vergelykingstabel van haproxy/nginx/gesant, dit maak nie daarop aanspraak dat dit die absolute waarheid is nie, maar gee 'n algemene prentjie.

nginx
haproksie
gestuur
traefik

sterre op github
11.2k/spieël
1.1k/spieël
12.4k
27.6k

in geskryf
C
C
C + +
go

API
geen
Slegs sok/stoot
datavliegtuig/trek
trek

aktiewe gesondheidsondersoek
geen
Ja
Ja
Ja

Oop nasporing
eksterne inprop
geen
Ja
Ja

J.W.T.
eksterne inprop
geen
Ja
geen

uitbreiding
Lua/C
Lua/C
Lua/C++
geen

hoekom

Dit is 'n jong projek, daar ontbreek baie dinge, sommige in vroeë alfa. Maar gestuur, ook as gevolg van sy jeug, ontwikkel vinnig en het reeds baie interessante kenmerke: dinamiese konfigurasie, baie klaargemaakte filters, 'n eenvoudige koppelvlak om jou eie filters te skryf.
Toepassingsgebiede volg hieruit, maar eers is daar 2 antipatrone:

  • Statiese terugslag.

Die feit is dat op die oomblik in gestuur geen kasondersteuning nie. Die Google-ouens probeer dit om reg te stel. Die idee sal een keer geïmplementeer word gestuur al die subtiliteite (dieretuinopskrifte) van RFC-nakoming, en maak vir spesifieke implementering 'n koppelvlak. Maar vir nou is dit nie eers alfa nie, die argitektuur is onder bespreking, PR oop (terwyl ek die PR-artikel geskryf het, het die PR gevries, maar hierdie punt is steeds relevant).

Vir nou, gebruik nginx vir statika.

  • Statiese konfigurasie.

Jy kan dit gebruik, maar gestuur Dit is nie waarvoor dit geskep is nie. Kenmerke in 'n statiese opset sal nie blootgestel word nie. Daar is baie oomblikke:

Wanneer jy die konfigurasie in yaml redigeer, sal jy verkeerd wees, die ontwikkelaars skel vir breedvoerigheid en dink dat die nginx/haproxy-konfigurasies, hoewel minder gestruktureerd, meer bondig is. Dit is die punt. Die konfigurasie van Nginx en Haproxy is geskep vir redigering met die hand, en gestuur vir generering vanaf kode. Die hele konfigurasie word beskryf in protobuf, genereer dit uit proto lêers is baie moeiliker om 'n fout te maak.

Kanarie-, b/g-ontplooiingsscenario's en nog baie meer word gewoonlik slegs in 'n dinamiese konfigurasie geïmplementeer. Ek sê nie dat dit nie staties gedoen kan word nie, ons doen dit almal. Maar hiervoor moet jy krukke aansit, in enige van die balanseerders, in gestuur insluitend.

Take waarvoor gesant onontbeerlik is:

  • Verkeersbalansering in komplekse en dinamiese stelsels. Dit sluit die diensnetwerk in, maar dit is nie noodwendig die enigste nie.
  • Die behoefte aan verspreide opsporingsfunksionaliteit, komplekse magtiging of ander funksionaliteit wat beskikbaar is in gestuur uit die boks of gerieflik geïmplementeer, maar in nginx/haproxy moet jy omring word deur lua en twyfelagtige inproppe.

Albei, indien nodig, lewer hoë werkverrigting.

Hoe werk dit

Gesant word slegs in binaries as 'n docker-beeld versprei. Die prent bevat reeds 'n voorbeeld van 'n statiese konfigurasie. Maar ons stel net daarin belang om die struktuur te verstaan.

envoy.yaml statiese konfigurasie

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

Dinamiese konfigurasie

Vir watter probleem soek ons ​​'n oplossing? U kan nie net die lasbalanseerder-konfigurasie onder las herlaai nie; "klein" probleme sal opduik:

  • Konfigurasie validering.

Die konfigurasie kan groot wees, dit kan baie groot wees, as ons dit alles op een slag oorlaai, verhoog die kanse op 'n fout iewers.

  • Langlewende verbindings.

Wanneer jy 'n nuwe luisteraar inisialiseer, moet jy sorg vir die verbindings wat op die ou een loop; as veranderinge gereeld voorkom en daar langlewende verbindings is, sal jy 'n kompromie moet soek. Hallo, kubernetes intree op nginx.

  • Aktiewe gesondheidsondersoeke.

As ons aktiewe gesondheidsondersoeke het, moet ons dit almal in die nuwe konfigurasie nagaan voordat ons verkeer stuur. As daar baie stroomop is, neem dit tyd. Hallo haproxy.

Hoe word dit opgelos in gestuurDeur die konfigurasie dinamies te laai, volgens die swembadmodel, kan jy dit in afsonderlike dele verdeel en nie die deel wat nie verander het nie, herinitialiseer nie. Byvoorbeeld, 'n luisteraar, wat duur is om te herinitialiseer en selde verander.

opset gestuur (van die lêer hierbo) het die volgende entiteite:

  • luisteraar — luisteraar hang aan 'n spesifieke ip/poort
  • virtuele gasheer - virtuele gasheer volgens domeinnaam
  • roete - balanserende reël
  • cluster — 'n groep stroomop met balanseringsparameters
  • eindpunt — stroomop instansie adres

Elkeen van hierdie entiteite plus 'n paar ander kan dinamies ingevul word; hiervoor spesifiseer die konfigurasie die adres van die diens vanwaar die konfigurasie ontvang sal word. Die diens kan REST of gRPC wees, gRPC is verkieslik.

Die dienste word onderskeidelik genoem: LDS, VHDS, RDS, CDS en EDS. Jy kan statiese en dinamiese konfigurasie kombineer, met die beperking dat 'n dinamiese hulpbron nie in 'n statiese een gespesifiseer kan word nie.

Vir die meeste take is dit genoeg om die laaste drie dienste te implementeer, dit word ADS (Aggregated Discovery Service) genoem, vir Java en gaan daar is 'n klaargemaakte implementering van gRPC dataplane waarin jy net die voorwerpe van jou bron moet invul.

Die konfigurasie neem die volgende vorm aan:

envoy.yaml dinamiese konfigurasie

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

Met die aanvang gestuur met hierdie konfigurasie sal dit aan die beheervlak koppel en probeer om die RDS-, CDS- en EDS-konfigurasie aan te vra. Hoe die interaksieproses plaasvind, word beskryf hier.

Kortom, gestuur stuur 'n versoek wat die tipe hulpbron wat aangevra word, die weergawe en parameters van die nodus aandui. In reaksie ontvang dit 'n hulpbron en 'n weergawe; as die weergawe op die beheervlak nie verander het nie, reageer dit nie.
Daar is 4 interaksie-opsies:

  • Een gRPC-stroom vir alle soorte hulpbronne, die volle status van die hulpbron word gestuur.
  • Aparte strome, volledige toestand.
  • Een stroom, inkrementele toestand.
  • Afsonderlike strome, inkrementele toestand.

Inkrementele xDS laat jou toe om verkeer tussen die beheer-vliegtuig en gestuur, dit is relevant vir groot konfigurasies. Maar dit bemoeilik die interaksie; die versoek bevat 'n lys hulpbronne om uit te teken en in te teken.

Ons voorbeeld gebruik ADS - een stroom vir RDS, CDS, EDS en nie-inkrementele modus. Om inkrementele modus te aktiveer, moet jy spesifiseer api_type: DELTA_GRPC

Aangesien die versoek nodusparameters bevat, kan ons verskillende hulpbronne na die beheervlak stuur vir verskillende gevalle gestuur, dit is gerieflik vir die bou van 'n diensmaas.

Maak warm

Op gestuur by opstart of wanneer 'n nuwe konfigurasie vanaf beheervlak ontvang word, word die hulpbronopwarmingsproses van stapel gestuur. Dit word verdeel in luisteraaropwarming en trosopwarming. Die eerste word bekendgestel wanneer daar veranderinge in RDS/LDS is, die tweede wanneer CDS/EDS. Dit beteken dat as net stroomop verander, die luisteraar nie herskep word nie.

Tydens die opwarmingsproses word afhanklike hulpbronne van die beheervlak verwag tydens die uitteltyd. As die uitteltyd plaasvind, sal inisialisering nie suksesvol wees nie en die nuwe luisteraar sal nie op die poort begin luister nie.
Inisialiseringsorde: EDS, CDS, aktiewe gesondheidskontrole, RDS, LDS. Met aktiewe gesondheidsondersoeke geaktiveer, sal verkeer net stroomop gaan na een suksesvolle gesondheidsondersoek.

As die luisteraar herskep is, gaan die ou een in die DRAIN-toestand en sal uitgevee word nadat alle verbindings gesluit is of die uitteltyd verstryk --drain-time-s, verstek 10 minute.

Om voortgesit te word.

Bron: will.com

Voeg 'n opmerking