ProHoster > Blogi > Haldamine > saadik. 1. Sissejuhatus

saadik. 1. Sissejuhatus

Tervitused! See on lühike artikkel, mis vastab küsimustele: "Mis on saadik?", "Miks seda vaja on?" ja "kust alustada?".

Mis see on?

Envoy on C++ keeles kirjutatud L4-L7 tasakaalustaja, mis on keskendunud suurele jõudlusele ja saadavusele. Ühest küljest on see mingil moel nginxi ja haproxy analoog, mis on jõudluses nendega võrreldav. Teisest küljest on see rohkem orienteeritud mikroteenuste arhitektuurile ja selle funktsionaalsus pole halvem kui java and go tasakaalustajad, nagu zuul või traefik.

Haproxy/nginx/envoy võrdlustabel, see ei pretendeeri absoluutsele tõele, vaid annab üldpildi.

nginx
haproksü
saadik
traefik

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

sisse kirjutatud
C
C
C + +
go

API
ei
ainult pistikupesa/push
andmeplaan/tõmme
vedama

aktiivne tervisekontroll
ei
jah
jah
jah

Ava jälg
väline pistikprogramm
ei
jah
jah

J.W.T.
väline pistikprogramm
ei
jah
ei

laiendamine
Lua/C
Lua/C
Lua/C++
ei

Mida

See on noor projekt, palju asju on puudu, mõned alfa alguses. Aga saadik, areneb ka oma nooruse tõttu kiiresti ja sellel on juba palju huvitavaid funktsioone: dünaamiline konfiguratsioon, palju valmisfiltreid, lihtne liides oma filtrite kirjutamiseks.
Sellest tulenevad kasutusvaldkonnad, kuid kõigepealt on kaks antimustrit:

  • Staatiline tagasilöök.

Fakt on see, et hetkel sisse saadik vahemälu tugi puudub. Google'i poisid proovivad seda fikseerida. Idee viiakse ellu üks kord saadik kõik RFC vastavuse peensused (loomaaia päised) ja konkreetsete rakenduste jaoks luua liides. Kuid praegu pole see isegi alfa, arhitektuur on arutelu all, PR avatud (kui ma PR-artiklit kirjutasin, PR hangus, aga see punkt on endiselt asjakohane).

Praegu kasutage staatika jaoks nginxit.

  • Staatiline konfiguratsioon.

Võite seda kasutada, kuid saadik See pole selleks loodud. Staatilise konfiguratsiooni funktsioone ei avaldata. On palju hetki:

Yamlis konfiguratsiooni redigeerides eksite, kardate arendajaid paljusõnalisuse pärast ja arvate, et nginx/haproxy konfiguratsioonid, ehkki vähem struktureeritud, on sisutihedamad. See on asja mõte. Nginxi ja Haproxy konfiguratsioon loodi käsitsi redigeerimiseks ja saadik koodist genereerimiseks. Kogu konfiguratsiooni on kirjeldatud artiklis protobuf, on selle genereerimine protofailidest palju keerulisem viga teha.

Canary, b/g juurutamise stsenaariume ja palju muud rakendatakse tavaliselt ainult dünaamilises konfiguratsioonis. Ma ei ütle, et seda ei saa staatiliselt teha, me kõik teeme seda. Kuid selleks peate ükskõik millisesse tasakaalustajasse panema kargud saadik kaasa arvatud.

Ülesanded, mille jaoks saadik on asendamatu:

  • Liikluse tasakaalustamine keerulistes ja dünaamilistes süsteemides. See hõlmab teenindusvõrku, kuid see ei pruugi olla ainus.
  • Vajadus hajutatud jälgimisfunktsiooni, keeruka autoriseerimise või muu funktsiooni järele, mis on saadaval saadik kastist väljas või mugavalt juurutatud, aga nginx/haproxy puhul peab sind ümbritsema lua ja kahtlased pluginad.

Mõlemad tagavad vajadusel suure jõudluse.

Kuidas see töötab

Envoy levitatakse binaarfailidena ainult dokipildina. Pilt sisaldab juba staatilise konfiguratsiooni näidet. 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
    # 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

Dünaamiline konfiguratsioon

Millisele probleemile me lahendust otsime? Te ei saa koormusetasakaalu konfiguratsiooni lihtsalt uuesti laadida, vaid tekivad väikesed probleemid:

  • Konfiguratsiooni valideerimine.

Konfig võib olla suur, see võib olla väga suur, kui me selle korraga üle koormame, suureneb võimalus, et kuskil on viga.

  • Pikaealised sidemed.

Uue kuulaja lähtestamisel tuleb hoolitseda vanal töötavate ühenduste eest, kui muutused toimuvad sageli ja ühendused on pikaealised, siis tuleb otsida kompromissi. Tere, kubernetes ingress nginxis.

  • Aktiivne tervisekontroll.

Kui meil on aktiivsed tervisekontrollid, peame need kõik uues konfiguratsioonis enne liikluse saatmist üle kontrollima. Kui ülesvoolu on palju, võtab see aega. Tere haproxy.

Kuidas see on lahendatud saadikLaadides konfiguratsiooni dünaamiliselt, vastavalt basseini mudelile, saate selle jagada eraldi osadeks ja mitte uuesti initsialiseerida seda osa, mis pole muutunud. Näiteks kuulaja, mille taasalustamine on kallis ja vahetub harva.

Konfiguratsioon saadik (ülaltoodud failist) sisaldab järgmisi üksusi:

  • kuulaja — kuulaja, mis ripub kindla ip/pordi küljes
  • virtuaalne host - virtuaalne host domeeninime järgi
  • tee - tasakaalustamise reegel
  • klastri — rühm ülesvoolu koos tasakaalustavate parameetritega
  • tulemusnäitaja — ülesvoolu eksemplari aadress

Kõik need olemid ja mõned teised saab dünaamiliselt täita; selleks määrab konfiguratsioon teenuse aadressi, kust konfiguratsioon vastu võetakse. Teenus võib olla REST või gRPC, eelistatav on gRPC.

Teenused on nimetatud vastavalt: LDS, VHDS, RDS, CDS ja EDS. Saate kombineerida staatilise ja dünaamilise konfiguratsiooni piiranguga, et dünaamilist ressurssi ei saa määrata staatilises.

Enamiku ülesannete jaoks piisab kolme viimase teenuse rakendamisest, neid nimetatakse ADS-iks (Aggregated Discovery Service). Java ja minge, seal on gRPC andmetasandi valmis juurutus, milles peate lihtsalt täitma oma allikast pärit objektid.

Konfiguratsioon on järgmisel kujul:

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 saadik selle konfiguratsiooniga loob see ühenduse juhttasandiga ja proovib taotleda RDS-i, CDS-i ja EDS-i konfiguratsiooni. Kirjeldatakse, kuidas interaktsiooniprotsess toimub siin.

Lühidalt, saadik saadab päringu, mis näitab taotletava ressursi tüüpi, sõlme versiooni ja parameetreid. Vastuseks saab ta ressursi ja versiooni; kui juhttasandil olev versioon pole muutunud, siis ta ei reageeri.
Interaktsioonivalikuid on neli:

  • Üks gRPC voog igat tüüpi ressursside jaoks, saadetakse ressursi täielik olek.
  • Eraldi ojad, täis seisukord.
  • Üks voog, järkjärguline olek.
  • Eraldi vood, astmeline olek.

Inkrementaalne xDS võimaldab teil vähendada liiklust juhttasandi ja juhttasandi vahel saadik, on see oluline suurte konfiguratsioonide puhul. Kuid see muudab suhtlemise keerulisemaks; taotlus sisaldab ressursside loendit tellimuse tühistamiseks ja tellimiseks.

Meie näide kasutab ADS-i – üks voog RDS-i, CDS-i, EDS-i ja mitteinkrementaalse režiimi jaoks. Lisarežiimi lubamiseks peate määrama api_type: DELTA_GRPC

Kuna päring sisaldab sõlme parameetreid, saame erinevate eksemplaride jaoks juhttasandile saata erinevaid ressursse saadik, see on mugav teenindusvõrgu ehitamiseks.

Soojendama

Edasi saadik käivitamisel või juhttasandilt uue konfiguratsiooni saamisel käivitatakse ressursi soojendamise protsess. See jaguneb kuulaja soojendamiseks ja klastri soojendamiseks. Esimene käivitatakse, kui RDS/LDS-is on muudatusi, teine, kui CDS/EDS. See tähendab, et kui muutuvad ainult ülesvoolud, siis kuulajat uuesti ei looda.

Soojendusprotsessi ajal oodatakse juhttasandilt sõltuvaid ressursse ajalõpu ajal. Kui aegumine toimub, siis lähtestamine ei õnnestu ja uus kuulaja ei hakka pordis kuulama.
Initsialiseerimisjärjekord: EDS, CDS, aktiivne tervisekontroll, RDS, LDS. Kui aktiivsed tervisekontrollid on lubatud, läheb liiklus ülesvoolu alles pärast ühte edukat tervisekontrolli.

Kui kuulaja loodi uuesti, läheb vana olekusse DRAIN ja see kustutatakse pärast kõigi ühenduste sulgemist või ajalõpu aegumist --drain-time-s, vaikimisi 10 minutit.

Et jätkata.

Allikas: www.habr.com

Lisa kommentaar