Sendito. 1. Enkonduko

Saluton! Ĉi tio estas mallonga artikolo, kiu respondas la demandojn: "kio estas sendito?", "kial ĝi bezonas?" kaj "kie komenci?".

Kio estas ĉi tio?

Envoy estas L4-L7-balancilo skribita en C++, koncentrita pri alta rendimento kaj havebleco. Unuflanke, ĉi tio estas iel analogo de nginx kaj haproxy, komparebla en rendimento al ili. Aliflanke, ĝi estas pli orientita al mikroserva arkitekturo kaj havas funkciojn ne pli malbonajn ol java and go balancers, kiel zuul aŭ traefik.

Kompartabelo de haproxy/nginx/envoy, ĝi ne pretendas esti la absoluta vero, sed donas ĝeneralan bildon.

nginx
haproxy
sendita
traefik

steloj sur github
11.2k/spegulo
1.1k/spegulo
12.4k
27.6k

skribita en
C
C
C ++
go

API
neniu
nur ingo/puŝo
datumplano/tiro
tiri

aktiva sankontrolo
neniu
jes
jes
jes

Malfermu spuron
ekstera kromaĵo
neniu
jes
jes

J.W.T.
ekstera kromaĵo
neniu
jes
neniu

pligrandigo
Lua/C
Lua/C
Lua/C++
neniu

Kial

Ĉi tio estas juna projekto, mankas multaj aferoj, iuj en frua alfa. Sed sendita, ankaŭ pro sia juneco, disvolviĝas rapide kaj jam havas multajn interesajn funkciojn: dinamika agordo, multaj pretaj filtriloj, simpla interfaco por skribi viajn proprajn filtrilojn.
Aplikaj kampoj sekvas de ĉi tio, sed unue estas 2 kontraŭŝablonoj:

• Senmova regreso.

La fakto estas, ke nuntempe en sendita neniu kaŝmemoro subteno. La Guglo-uloj provas ĉi tion ripari. La ideo estos efektivigita unufoje enen sendita ĉiuj subtilecoj (zookapoj) de RFC-konformeco, kaj por specifaj efektivigoj fari interfacon. Sed nuntempe ĝi ne estas eĉ alfa, la arkitekturo estas diskutata, PR malfermita (dum mi verkis la PR-artikolon, la PR frostiĝis, sed ĉi tiu punkto ankoraŭ estas grava).

Nuntempe, uzu nginx por statiko.

• Statika agordo.

Vi povas uzi ĝin, sed sendita Ne por tio ĝi estis kreita. Trajtoj en senmova agordo ne estos elmontritaj. Estas multaj momentoj:

Kiam vi redaktas la agordon en yaml, vi eraros, riproĉos la programistojn pro multvorteco kaj pensu, ke la nginx/haproxy-agordoj, kvankam malpli strukturitaj, estas pli koncizaj. Jen la punkto. La agordo de Nginx kaj Haproxy estis kreita por redaktado permane, kaj sendita por generacio el kodo. La tuta agordo estas priskribita en protobuf, generi ĝin el pradosieroj estas multe pli malfacile erari.

Kanariaj, b/g deplojscenaroj kaj multe pli estas normale efektivigitaj nur en dinamika agordo. Mi ne diras, ke tio ne povas esti farita statike, ni ĉiuj faras ĝin. Sed por tio vi devas surmeti lambastonojn, en iu ajn el la balanciloj, en sendita inkluzive.

Taskoj por kiuj Sendito estas nemalhavebla:

• Trafikbalancado en kompleksaj kaj dinamikaj sistemoj. Ĉi tio inkluzivas la servan maŝon, sed ĝi ne estas nepre la sola.
• La bezono de distribuita spura funkcieco, kompleksa rajtigo aŭ alia funkcieco disponebla en sendita el la skatolo aŭ oportune efektivigita, sed en nginx/haproxy vi devas esti ĉirkaŭita de lua kaj dubindaj kromaĵoj.

Ambaŭ, se necese, provizas altan rendimenton.

Kiel tio funkcias

Envoy estas distribuita en binaroj nur kiel docker-bildo. La bildo jam enhavas ekzemplon de statika agordo. Sed ni interesiĝas pri ĝi nur por kompreni la strukturon.

envoy.yaml statika agordo

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

Dinamika agordo

Al kiu problemo ni serĉas solvon? Vi ne povas simple reŝargi la agordon de ŝarĝbalancilo sub ŝarĝo; "malgrandaj" problemoj aperos:

• Valumado de agordo.

La agordo povas esti granda, ĝi povas esti tre granda, se ni superŝarĝas ĉion samtempe, la ŝancoj de eraro ie pliiĝas.

• Longvivaj ligoj.

Dum pravalorigo de nova aŭskultanto, vi devas zorgi pri la konektoj funkcianta sur la malnova; se ŝanĝoj okazas ofte kaj estas longdaŭraj konektoj, vi devos serĉi kompromison. Saluton, kubernetes eniras sur nginx.

• Aktivaj sankontroloj.

Se ni havas aktivajn sankontrolojn, ni devas duoble kontroli ilin ĉiujn en la nova agordo antaŭ sendi trafikon. Se estas multaj kontraŭfluoj, tio bezonas tempon. Saluton haproxy.

Kiel tio estas solvita en senditaŜargante la agordon dinamike, laŭ la naĝejo-modelo, vi povas dividi ĝin en apartajn partojn kaj ne rekomencigi la parton, kiu ne ŝanĝiĝis. Ekzemple, aŭskultanto, kiu estas multekosta rekomencigi kaj malofte ŝanĝiĝas.

Agordo sendita (el la supra dosiero) havas la jenajn entojn:

• aŭskultanto — aŭskultanto pendanta sur specifa ip/haveno
• virtuala gastiganto - virtuala gastiganto per domajna nomo
• itinero - ekvilibra regulo
• areto — grupo de kontraŭfluoj kun ekvilibraj parametroj
• finpunkto — kontraŭflua instancadreso

Ĉiu el ĉi tiuj entoj kaj iuj aliaj povas esti plenigitaj dinamike; por tio, la agordo specifas la adreson de la servo de kie la agordo estos ricevita. La servo povas esti REST aŭ gRPC, gRPC estas preferinda.

La servoj estas nomitaj respektive: LDS, VHDS, RDS, CDS kaj EDS. Vi povas kombini statikan kaj dinamikan agordon, kun la limigo, ke dinamika rimedo ne povas esti specifita en senmova.

Por plej multaj taskoj, sufiĉas efektivigi la lastajn tri servojn, ili nomiĝas ADS (Aggregated Discovery Service), por java kaj iru tie estas preta efektivigo de gRPC-datuplano en kiu vi nur bezonas plenigi la objektojn de via fonto.

La agordo prenas la jenan formon:

envoy.yaml dinamika agordo

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

Ĉe ekfunkciigo sendita kun ĉi tiu agordo, ĝi konektos al la kontrolaviadilo kaj provos peti la agordon RDS, CDS kaj EDS. Kiel la interaga procezo okazas estas priskribita tie.

Mallonge, sendita sendas peton indikante la specon de rimedo petita, la versio kaj parametroj de la nodo. Responde, ĝi ricevas rimedon kaj version; se la versio sur la kontrolaviadilo ne ŝanĝiĝis, ĝi ne respondas.
Estas 4 interagaj opcioj:

• Unu gRPC-rivereto por ĉiuj specoj de rimedoj, la plena stato de la rimedo estas sendita.
• Apartaj riveretoj, plena kondiĉo.
• Unu fluo, pliiga stato.
• Apartaj riveretoj, pliiga stato.

Krementa xDS permesas redukti trafikon inter la kontrolaviadilo kaj sendita, ĉi tio estas grava por grandaj agordoj. Sed ĝi malfaciligas la interagadon; la peto enhavas liston de rimedoj por malaboni kaj aboni.

Nia ekzemplo uzas ADS - unu fluon por RDS, CDS, EDS kaj ne-pliiga reĝimo. Por ebligi pliigan reĝimon, vi devas specifi api_type: DELTA_GRPC

Ĉar la peto enhavas nodajn parametrojn, ni povas sendi malsamajn rimedojn al la kontrolaviadilo por malsamaj okazoj sendita, ĉi tio estas oportuna por konstrui servomaŝon.

Varmiĝo

En sendita ĉe ekfunkciigo aŭ kiam ricevas novan agordon de kontrol-aviadilo, la rimeda varmiga procezo estas lanĉita. Ĝi estas dividita en varmigo de aŭskultanto kaj varmigo de areto. La unua estas lanĉita kiam estas ŝanĝoj en RDS/LDS, la dua kiam CDS/EDS. Ĉi tio signifas, ke se nur kontraŭfluoj ŝanĝiĝas, la aŭskultanto ne estas rekreita.

Dum la varmiga procezo, dependaj resursoj estas atenditaj de la kontrolaviadilo dum la tempotempo. Se la tempoforigo okazas, inicialigo ne sukcesos kaj la nova aŭskultanto ne komencos aŭskulti sur la haveno.
Inicialiga ordo: EDS, CDS, aktiva sankontrolo, RDS, LDS. Kun aktivaj sankontroloj ebligitaj, trafiko iros kontraŭflue nur post unu sukcesa sankontrolo.

Se la aŭskultanto estis rekreita, la malnova iras en la DRAIN-ŝtaton kaj estos forigita post kiam ĉiuj konektoj estas fermitaj aŭ la tempo-tempo eksvalidiĝas. --drain-time-s, defaŭlte 10 minutoj.

Daŭrigota.

fonto: www.habr.com