ProHoster > Blog > Administrazioa > Mandataria. 1. Sarrera

Mandataria. 1. Sarrera

Zorionak! Hau galderei erantzuten dien artikulu laburra da: β€œzer da mandataria?”, β€œzertarako behar da?”. eta "nondik hasi?".

Zer da hau?

Envoy C++-n idatzitako L4-L7 orekatzailea da, errendimendu eta erabilgarritasun handian bideratuta. Alde batetik, hau, nolabait, nginx eta haproxy-ren analogoa da, haien errendimenduan parekoa. Bestalde, mikrozerbitzuen arkitekturara bideratuago dago eta java eta go balancers baino funtzionalitate txarragorik ez dauka, zuul edo traefik esaterako.

Haproxy/nginx/envoy-en konparazio taula, ez du egia absolutua denik aldarrikatzen, baina irudi orokorra ematen du.

nginx
haproxy
igorri
traefik

izarrak github-en
11.2k/ispilua
1.1k/ispilua
12.4k
27.6k

idatzita
C
C
C ++
go

API
Π½Π΅Ρ‚
entxufea bakarrik/bulkatu
datu-planoa/tira
tira

osasun-kontrol aktiboa
Π½Π΅Ρ‚
Bai
Bai
Bai

Trazadura irekia
kanpoko plugina
Π½Π΅Ρ‚
Bai
Bai

J.W.T.
kanpoko plugina
Π½Π΅Ρ‚
Bai
Π½Π΅Ρ‚

luzapena
Lua/C
Lua/C
Lua/C++
Π½Π΅Ρ‚

Zertarako

Proiektu gaztea da hau, gauza asko falta dira, batzuk alfa hasieran. Baina igorri, bere gaztetasunagatik ere, azkar garatzen ari da eta dagoeneko ezaugarri interesgarri asko ditu: konfigurazio dinamikoa, prest egindako iragazki asko, zure iragazkiak idazteko interfaze sinplea.
Aplikazio-eremuak hortik datoz, baina lehenik 2 kontrako eredu daude:

  • Atzerapauso estatikoa.

Kontua da momentuz igorri caching euskarririk ez. Google-ko mutilak hau saiatzen ari dira konpondu. Ideia behin ezarriko da igorri RFC betetzearen Γ±abardura guztiak (zoo goiburuak) eta inplementazio zehatzetarako interfaze bat egin. Baina oraingoz ez da alfa ere, arkitektura eztabaidan dago, PR irekia (PR artikulua idazten ari nintzen bitartean, PR izoztu egin zen, baina puntu hau oraindik garrantzitsua da).

Oraingoz, erabili nginx estatikorako.

  • Konfigurazio estatikoa.

Erabili dezakezu, baina igorri Ez da horretarako sortua izan. Konfigurazio estatikoko eginbideak ez dira agertuko. Momentu asko daude:

Yaml-en konfigurazioa editatzean, oker egongo zara, garatzaileei errieta egin eta pentsa ezazu nginx/haproxy konfigurazioak, egituratuta ez dauden arren, zehatzagoak direla. Hori da kontua. Nginx eta Haproxy-ren konfigurazioa eskuz editatzeko sortu zen, eta igorri kodetik sortzeko. atalean deskribatzen da konfigurazio osoa protobuf, proto fitxategietatik sortzea askoz zailagoa da akats bat egitea.

Canary, b/g inplementazio eszenatokiak eta askoz gehiago normalean konfigurazio dinamiko batean soilik inplementatzen dira. Ez dut esaten hau estatikoki egin ezin denik, denok egiten dugu. Baina horretarako makuluak jarri behar dituzu, edozein orekatzailetan, barruan igorri barne.

Envoy ezinbestekoa den zereginak:

  • Trafikoa orekatzea sistema konplexu eta dinamikoetan. Horrek zerbitzu-sarea barne hartzen du, baina ez da zertan bakarra.
  • Banatutako trazamenduaren funtzionaltasuna, baimen konplexua edo eskuragarri dagoen beste funtzionalitate baten beharra igorri kaxatik kanpo edo eroso inplementatuta, baina nginx/haproxy-n lua eta zalantzazko pluginez inguratuta egon behar duzu.

Biek, behar izanez gero, errendimendu handia ematen dute.

Nola egiten du lan

Envoy binarioetan banatzen da docker irudi gisa soilik. Irudiak dagoeneko badu konfigurazio estatiko baten adibide bat. Baina egitura ulertzeko soilik interesatzen zaigu.

envoy.yaml konfigurazio estatikoa

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

Konfigurazio dinamikoa

Zein arazori irtenbidea bilatzen ari gara? Ezin duzu karga-orekatzailearen konfigurazioa berriro kargatu kargapean; arazo "txikiak" sortuko dira:

  • Konfigurazioaren baliozkotzea.

Konfigurazioa handia izan daiteke, oso handia izan daiteke, dena aldi berean gainkargatzen badugu, nonbait errore bat izateko aukerak handitzen dira.

  • Iraupen luzeko konexioak.

Entzule berri bat hasterakoan, zaharrean exekutatzen diren konexioak zaindu behar dituzu; aldaketak maiz gertatzen badira eta iraupen luzeko konexioak badaude, konpromisoa bilatu beharko duzu. Kaixo, kubernetes ingress nginx-en.

  • Osasun-kontrol aktiboak.

Osasun egiaztapen aktiboak baditugu, guztiak konfigurazio berrian egiaztatu behar ditugu trafikoa bidali aurretik. Upstream asko baldin badaude, honek denbora behar du. Kaixo haproxy.

Nola konpontzen da hau igorriKonfigurazioa dinamikoki kargatuz, igerileku-ereduaren arabera, zati bereizietan banatu dezakezu eta aldatu ez den zatia ez berriro abiarazi. Esaterako, entzule bat, garestia dena berriro hasieratzea eta gutxitan aldatzen dena.

konfigurazioa igorri (goiko fitxategitik) entitate hauek ditu:

  • entzulea β€” entzulea ip/portu zehatz batean zintzilik
  • ostalari birtuala - ostalari birtuala domeinu-izenaren arabera
  • ibilbidea - oreka-araua
  • cluster β€” oreka-parametroak dituen ur-talde bat
  • amaierako puntua β€” gorako instantziaren helbidea

Entitate horietako bakoitza eta beste batzuk modu dinamikoan bete daitezke; horretarako, konfigurazioak konfigurazioa jasoko duen zerbitzuaren helbidea zehazten du. Zerbitzua REST edo gRPC izan daiteke, gRPC hobe da.

Zerbitzuek hurrenez hurren izena dute: LDS, VHDS, RDS, CDS eta EDS. Konfigurazio estatikoa eta dinamikoa konbina ditzakezu, baliabide dinamiko bat estatiko batean ezin dela zehaztu.

Zeregin gehienetarako, nahikoa da azken hiru zerbitzuak ezartzea, ADS (Aggregated Discovery Service) deitzen zaie, Java eta joan gRPC dataplane-ren inplementazio prest dagoen eta bertan zure iturburuko objektuak bete besterik ez dituzu behar.

Konfigurazioak forma hau hartzen du:

envoy.yaml konfigurazio dinamikoa

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

Abiaraztean igorri konfigurazio honekin, kontrol-planora konektatuko da eta RDS, CDS eta EDS konfigurazioa eskatzen saiatuko da. Interakzio-prozesua nola gertatzen den deskribatzen da Hemen.

Laburbilduz, igorri eskaera bat bidaltzen du eskatzen den baliabide mota, nodoaren bertsioa eta parametroak adieraziz. Erantzun gisa, baliabide bat eta bertsio bat jasotzen ditu; kontrol-planoko bertsioa aldatu ez bada, ez du erantzuten.
4 interakzio aukera daude:

  • Mota guztietako baliabideetarako gRPC korronte bat, baliabidearen egoera osoa bidaltzen da.
  • Erreka bereiziak, egoera osoa.
  • Korronte bat, egoera inkrementala.
  • Korronte bereiziak, egoera inkrementala.

Incremental xDS-k kontrol-hegazkinaren eta trafikoa murrizteko aukera ematen du igorri, hau garrantzitsua da konfigurazio handietarako. Baina elkarrekintza zaildu egiten du; eskaerak harpidetza kentzeko eta harpidetzeko baliabideen zerrenda dauka.

Gure adibideak ADS erabiltzen du - korronte bat RDS, CDS, EDS eta gehikuntzarik gabeko modurako. Modu inkrementala gaitzeko, zehaztu behar duzu api_type: DELTA_GRPC

Eskaerak nodo-parametroak dituenez, baliabide desberdinak bidal ditzakegu kontrol-planora instantzia desberdinetarako igorri, hau erosoa da zerbitzu-sare bat eraikitzeko.

Berotu

On igorri abiaraztean edo kontrol-planotik konfigurazio berri bat jasotzean, baliabideak berotzeko prozesua abiarazten da. Entzuleen beroketa eta kluster beroketa bereizten da. Lehenengoa RDS/LDSn aldaketak daudenean abiarazten da, bigarrena CDS/EDS denean. Horrek esan nahi du upstream-ak soilik aldatzen badira, entzulea ez dela birsortzen.

Berotze-prozesuan zehar, kontrol-planoaren menpeko baliabideak espero dira denbora-mugan. Denbora-muga gertatzen bada, hasieratzea ez da arrakastatsua izango eta entzule berria ez da portuan entzuten hasiko.
Hasierako ordena: EDS, CDS, osasun-kontrol aktiboa, RDS, LDS. Osasun egiaztapen aktiboak gaituta, trafikoa korrontean igoko da osasun egiaztapen arrakastatsu baten ondoren soilik.

Entzulea birsortu bada, zaharra DRAIN egoerara pasako da eta konexio guztiak itxi ondoren edo denbora-muga amaitu ondoren ezabatuko da. --drain-time-s, lehenetsita 10 minutu.

Jarraitu behar da.

Iturria: www.habr.com

Gehitu iruzkin berria