ProHoster > Dienoraštis > Administravimas > pasiuntinys. 1. Įvadas

pasiuntinys. 1. Įvadas

Sveikinimai! Tai trumpas straipsnis, kuriame atsakoma į klausimus: „kas yra pasiuntinys?“, „kam to reikia? ir "nuo ko pradėti?".

Kas tai yra

Envoy yra L4-L7 balansyras, parašytas C++ kalba, orientuotas į didelį našumą ir prieinamumą. Viena vertus, tai tam tikra prasme yra nginx ir haproxy analogas, kurio veikimas yra panašus į juos. Kita vertus, jis labiau orientuotas į mikroservisų architektūrą ir turi ne ką prastesnį funkcionalumą nei java and go balansuotojai, tokie kaip zuul ar traefik.

Haproxy/nginx/envoy palyginamoji lentelė nepretenduoja į absoliučią tiesą, bet pateikia bendrą vaizdą.

nginx
haproksija
pasiuntinys
traefik

žvaigždės github'e
11.2k/veidrodis
1.1k/veidrodis
12.4k
27.6k

parašyta
C
C
C + +
go

API
ne
tik lizdas / stumti
duomenų plokštuma/traukimas
traukti

aktyvus sveikatos patikrinimas
ne
taip
taip
taip

Atidaryti sekimą
išorinis papildinys
ne
taip
taip

J.W.T.
išorinis papildinys
ne
taip
ne

pratęsimas
Lua/C
Lua/C
Lua/C++
ne

Už ką

Tai jaunas projektas, trūksta daug dalykų, kai kurių yra ankstyvoje alfa versijoje. Bet pasiuntinys, taip pat dėl ​​savo jaunystės, sparčiai vystosi ir jau turi daug įdomių funkcijų: dinamiška konfigūracija, daug paruoštų filtrų, paprasta sąsaja savo filtrų rašymui.
Iš to išplaukia taikymo sritys, tačiau pirmiausia yra 2 antimodeliai:

  • Statinis atatranka.

Faktas yra tas, kad šiuo metu m pasiuntinys nėra talpyklos palaikymo. „Google“ vaikinai tai bando išspręsti. Idėja bus įgyvendinta vieną kartą pasiuntinys visas RFC atitikties subtilybes (zoologijos sodo antraštes), o konkretiems diegimams sukurti sąsają. Bet kol kas tai net ne alfa, diskutuojama dėl architektūros, PR atviras (kol rašiau PR straipsnį, PR užstrigo, bet šis punktas vis dar aktualus).

Kol kas statikai naudokite nginx.

  • Statinė konfigūracija.

Galite naudoti, bet pasiuntinys Ne tam jis buvo sukurtas. Statinės konfigūracijos funkcijos nebus atskleistos. Yra daug akimirkų:

Redaguodami konfigūraciją yaml, suklysite, barsite kūrėjus už daugiažodiškumą ir manysite, kad nginx / haproxy konfigūracijos, nors ir mažiau struktūrizuotos, yra glaustesnės. Tai yra esmė. „Nginx“ ir „Haproxy“ konfigūracija buvo sukurta redaguoti rankiniu būdu ir pasiuntinys generavimui iš kodo. Visa konfigūracija aprašyta protobufas, sugeneruoti jį iš proto failų yra daug sunkiau padaryti klaidą.

Canary, b/g diegimo scenarijai ir daug daugiau paprastai įgyvendinami tik dinaminėje konfigūracijoje. Nesakau, kad to negalima padaryti statiškai, mes visi tai darome. Bet tam reikia užsidėti ramentus bet kuriame iš balansyro pasiuntinys įskaitant.

Užduotys, kurioms pasiuntinys yra nepakeičiamas:

  • Eismo balansavimas sudėtingose ​​ir dinamiškose sistemose. Tai apima aptarnavimo tinklą, bet nebūtinai vienintelis.
  • Reikia paskirstytos sekimo funkcijos, sudėtingo autorizavimo ar kitos funkcijos, kuri yra pasiekiama pasiuntinys išimtas iš dėžutės arba patogiai įdiegtas, bet nginx/haproxy turi būti apsuptas lua ir abejotinų įskiepių.

Abu, jei reikia, užtikrina aukštą našumą.

Kaip tai veikia

Envoy platinamas dvejetainiais failais tik kaip docker vaizdas. Vaizde jau yra statinės konfigūracijos pavyzdys. Bet mus tai domina tik dėl struktūros supratimo.

pasiuntinys.yaml statinė konfigūracija

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

Dinaminė konfigūracija

Kokiai problemai ieškome sprendimo? Negalite tiesiog iš naujo įkelti apkrovos balansavimo priemonės konfigūracijos esant apkrovai; atsiras „mažų“ problemų:

  • Konfigūracijos patvirtinimas.

Konfigūracija gali būti didelė, gali būti labai didelė, jei perkrauname viską iš karto, padidėja tikimybė, kad kažkur bus klaida.

  • Ilgaamžiai ryšiai.

Inicijuojant naują klausytoją reikia pasirūpinti ryšiais, veikiančiais senajame, jei pokyčiai vyksta dažnai ir yra ilgalaikiai ryšiai, teks ieškoti kompromiso. Sveiki, kubernetes ingress į nginx.

  • Aktyvūs sveikatos patikrinimai.

Jei atliekame aktyvius sveikatos patikrinimus, prieš siųsdami srautą turime juos visus dar kartą patikrinti naujoje konfigūracijoje. Jei prieš srovę yra daug, tai užtrunka. Sveiki, haproxy.

Kaip tai išspręsta pasiuntinysĮkeliant konfigūraciją dinamiškai, pagal baseino modelį, galima ją padalinti į atskiras dalis ir nepakitusios dalies iš naujo inicijuoti. Pavyzdžiui, klausytojas, kurį brangu iš naujo inicijuoti ir retai keičiasi.

Konfigūravimas pasiuntinys (iš anksčiau pateikto failo) turi šiuos objektus:

  • klausytojas - klausytojas, kabantis konkrečiame IP / prievade
  • virtualus kompiuteris - virtualus pagrindinis kompiuteris pagal domeno pavadinimą
  • maršrutas - balansavimo taisyklė
  • klasteris — aukštupių grupė su balansavimo parametrais
  • vertinamoji baigtis — ankstesnio egzemplioriaus adresas

Kiekvienas iš šių objektų ir kai kurie kiti gali būti užpildyti dinamiškai; tam konfigūracija nurodo paslaugos adresą, iš kurio bus gauta konfigūracija. Paslauga gali būti REST arba gRPC, pageidautina gRPC.

Paslaugos atitinkamai pavadintos: LDS, VHDS, RDS, CDS ir EDS. Galite derinti statinę ir dinaminę konfigūraciją su apribojimu, kad dinaminis išteklius negali būti nurodytas statiniame.

Daugeliui užduočių pakanka įdiegti paskutines tris paslaugas, jos vadinamos ADS (Aggregated Discovery Service). Java ir eikite ten yra paruoštas gRPC duomenų plokštumos įgyvendinimas, kuriame jums tereikia užpildyti objektus iš šaltinio.

Konfigūracija yra tokia:

pasiuntinys.yaml dinaminė konfigūracija

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

Paleidus pasiuntinys su šia konfigūracija jis prisijungs prie valdymo plokštumos ir bandys paprašyti RDS, CDS ir EDS konfigūracijos. Aprašyta, kaip vyksta sąveikos procesas čia.

Trumpai tariant, pasiuntinys siunčia užklausą, nurodydamas prašomo resurso tipą, mazgo versiją ir parametrus. Atsakydama ji gauna išteklius ir versiją; jei valdymo plokštumos versija nepasikeitė, ji nereaguoja.
Yra 4 sąveikos parinktys:

  • Vienas gRPC srautas visų tipų ištekliams, siunčiama visa išteklių būsena.
  • Atskiri srautai, pilna būklė.
  • Vienas srautas, laipsniška būsena.
  • Atskiri srautai, laipsniška būsena.

Inkrementinis xDS leidžia sumažinti srautą tarp valdymo plokštumos ir pasiuntinys, tai aktualu didelėms konfigūracijoms. Tačiau tai apsunkina sąveiką; užklausoje yra išteklių, skirtų atsisakyti prenumeratos ir užsiprenumeruoti, sąrašas.

Mūsų pavyzdyje naudojamas ADS – vienas srautas, skirtas RDS, CDS, EDS ir nepadidintam režimui. Norėdami įjungti laipsnišką režimą, turite nurodyti api_type: DELTA_GRPC

Kadangi užklausoje yra mazgo parametrų, galime siųsti skirtingus išteklius į valdymo plokštumą skirtingiems atvejams pasiuntinys, tai patogu kuriant aptarnavimo tinklelį.

Apšilimas

Apie pasiuntinys paleidžiant arba gavus naują konfigūraciją iš valdymo plokštumos, pradedamas resursų įšilimo procesas. Jis skirstomas į klausytojo apšilimą ir klasterio apšilimą. Pirmasis paleidžiamas, kai pasikeičia RDS/LDS, antrasis – kai CDS/EDS. Tai reiškia, kad pasikeitus tik prieš srovę, klausytojas nėra atkuriamas.

Apšilimo proceso metu tikimasi priklausomų išteklių iš valdymo plokštumos per skirtąjį laiką. Jei įvyks skirtasis laikas, inicijavimas nebus sėkmingas ir naujas klausytojas nepradės klausytis prievado.
Inicijavimo tvarka: EDS, CDS, aktyvus sveikatos patikrinimas, RDS, LDS. Įjungus aktyvius sveikatos patikrinimus, eismas vyks tik po vieno sėkmingo sveikatos patikrinimo.

Jei klausytojas buvo sukurtas iš naujo, senasis pereina į DRAIN būseną ir bus ištrintas, kai visi ryšiai bus nutraukti arba pasibaigs skirtasis laikas --drain-time-s, numatytoji 10 minučių.

Bus tęsiama.

Šaltinis: www.habr.com

Добавить комментарий