Enviat. 1. Introducció

Salutacions! Aquest és un article breu que respon a les preguntes: "què és enviat?", "per què es necessita?" i "per on començar?".

Què és?

Envoy és un equilibrador L4-L7 escrit en C++, centrat en un alt rendiment i disponibilitat. D'una banda, es tracta d'alguna manera d'un anàleg de nginx i haproxy, comparable en rendiment a ells. D'altra banda, està més orientat a l'arquitectura de microserveis i té una funcionalitat no pitjor que els equilibradors java i go, com ara zuul o traefik.

Taula de comparació de haproxy/nginx/envoy, no pretén ser la veritat absoluta, però ofereix una imatge general.

nginx
haproxy
enviat
traefik

estrelles a github
11.2 k/mirall
1.1 k/mirall
12.4k
27.6k

escrit en
C
C
C + +
go

API
нет
només endoll/empènyer
pla de dades/tirar
tirar

control de salut actiu
нет
sí
sí
sí

Traçat obert
connector extern
нет
sí
sí

JWT
connector extern
нет
sí
нет

extensió
Lua/C
Lua/C
Lua/C++
нет

Per què?

Aquest és un projecte jove, hi falten moltes coses, algunes en alfa primerenca. Però enviat, també per la seva joventut, es desenvolupa ràpidament i ja té moltes característiques interessants: configuració dinàmica, molts filtres ja fets, una interfície senzilla per escriure els vostres propis filtres.
Les àrees d'aplicació se'n deriven, però primer hi ha 2 antipatrons:

• Recul estàtic.

El fet és que de moment en enviat sense suport de memòria cau. Els nois de Google ho estan provant per arreglar. La idea es posarà en pràctica un cop endins enviat totes les subtileses (capçaleres del zoo) del compliment de RFC i, per a implementacions específiques, feu una interfície. Però de moment ni tan sols és alfa, l'arquitectura està en discussió, PR obert (mentre escrivia l'article de PR, el PR es va congelar, però aquest punt encara és rellevant).

De moment, utilitzeu nginx per a l'estàtica.

• Configuració estàtica.

Podeu utilitzar-lo, però enviat No es va crear per això. Les característiques en una configuració estàtica no s'exposaran. Hi ha molts moments:

Quan editeu la configuració en yaml, us equivocareu, renyeu els desenvolupadors per la verbositat i penseu que les configuracions de nginx/haproxy, encara que menys estructurades, són més concises. Aquest és el punt. La configuració de Nginx i Haproxy es va crear per editar a mà i enviat per a la generació a partir del codi. Tota la configuració es descriu a protobuf, generar-lo a partir de fitxers proto és molt més difícil equivocar-se.

Els escenaris de desplegament Canary, b/g i molt més normalment només s'implementen en una configuració dinàmica. No dic que això no es pugui fer estàticament, ho fem tots. Però per a això cal posar-se crosses, en qualsevol dels equilibradors, a enviat inclòs.

Tasques per a les quals Envoy és indispensable:

• Balanç de trànsit en sistemes complexos i dinàmics. Això inclou la malla de servei, però no necessàriament és l'única.
• La necessitat de la funcionalitat de seguiment distribuït, l'autorització complexa o una altra funcionalitat disponible a enviat fora de la caixa o implementat convenientment, però a nginx/haproxy heu d'estar envoltat de plugins lua i dubtosos.

Tots dos, si cal, proporcionen un alt rendiment.

Com funciona això

Envoy es distribueix en binaris només com a imatge Docker. La imatge ja conté un exemple de configuració estàtica. Però ens interessa només per entendre l'estructura.

configuració estàtica envoy.yaml

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

Configuració dinàmica

A quin problema busquem solució? No podeu tornar a carregar la configuració de l'equilibrador de càrrega sota càrrega; sorgiran problemes "petits":

• Validació de la configuració.

La configuració pot ser gran, pot ser molt gran, si la sobrecarreguem tot alhora, les possibilitats d'un error en algun lloc augmenten.

• Connexions de llarga durada.

Quan inicialitzeu un oient nou, heu de tenir cura de les connexions que s'executen a l'antic; si els canvis es produeixen amb freqüència i hi ha connexions de llarga durada, haureu de buscar un compromís. Hola, Kubernetes ingress a nginx.

• Controls de salut actius.

Si tenim controls de salut actius, hem de revisar-los tots a la nova configuració abans d'enviar trànsit. Si hi ha molts aigües amunt, això requereix temps. Hola haproxy.

Com es resol això a enviatEn carregar la configuració de forma dinàmica, segons el model de la piscina, podeu dividir-la en parts separades i no reiniciar la part que no ha canviat. Per exemple, un oient, que és car de reiniciar i rarament canvia.

Configuració enviat (del fitxer anterior) té les entitats següents:

• oient — oient penjat en una IP/port específic
• host virtual - host virtual per nom de domini
• ruta - regla d'equilibri
• clúster — un grup de aigües amunt amb paràmetres d'equilibri
• punt final — Adreça de la instància amunt

Cadascuna d'aquestes entitats i algunes altres es poden omplir de forma dinàmica; per a això, la configuració especifica l'adreça del servei des d'on es rebrà la configuració. El servei pot ser REST o gRPC, és preferible gRPC.

Els serveis s'anomenen respectivament: LDS, VHDS, RDS, CDS i EDS. Podeu combinar una configuració estàtica i dinàmica, amb la limitació que no es pot especificar un recurs dinàmic en un de estàtic.

Per a la majoria de tasques, n'hi ha prou amb implementar els tres últims serveis, s'anomenen ADS (Aggregated Discovery Service), per java i aneu allà, hi ha una implementació preparada del pla de dades gRPC en la qual només heu d'omplir els objectes de la vostra font.

La configuració pren la forma següent:

configuració dinàmica envoy.yaml

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

En començar enviat amb aquesta configuració, es connectarà al pla de control i intentarà sol·licitar la configuració RDS, CDS i EDS. Es descriu com es produeix el procés d'interacció aquí.

En resum, enviat envia una sol·licitud indicant el tipus de recurs que es demana, la versió i els paràmetres del node. En resposta, rep un recurs i una versió; si la versió del pla de control no ha canviat, no respon.
Hi ha 4 opcions d'interacció:

• Un flux de gRPC per a tot tipus de recursos, s'envia l'estat complet del recurs.
• Corrents separats, en ple estat.
• Un flux, estat incremental.
• Corrents separats, estat incremental.

XDS incremental us permet reduir el trànsit entre el pla de control i enviat, això és rellevant per a configuracions grans. Però complica la interacció; la sol·licitud conté una llista de recursos per donar-se de baixa i subscriure's.

El nostre exemple utilitza ADS: un flux per a RDS, CDS, EDS i el mode no incremental. Per habilitar el mode incremental, heu d'especificar api_type: DELTA_GRPC

Com que la sol·licitud conté paràmetres de node, podem enviar diferents recursos al pla de control per a diferents instàncies enviat, això és convenient per crear una malla de servei.

Escalfar

En enviat a l'inici o en rebre una nova configuració des del pla de control, s'inicia el procés d'escalfament dels recursos. Es divideix en escalfament de l'oient i escalfament del grup. El primer s'inicia quan hi ha canvis en RDS/LDS, el segon quan CDS/EDS. Això vol dir que si només canvien els aigües amunt, l'oient no es recrea.

Durant el procés d'escalfament, s'esperen recursos dependents del pla de control durant el temps d'espera. Si es produeix el temps d'espera, la inicialització no tindrà èxit i el nou oient no començarà a escoltar al port.
Ordre d'inicialització: EDS, CDS, control de salut actiu, RDS, LDS. Amb les comprovacions de salut actives habilitades, el trànsit només pujarà després d'una comprovació de salut correcta.

Si l'oient s'ha recreat, l'antic passa a l'estat DRAIN i s'eliminarà un cop es tanquin totes les connexions o que caduqui el temps d'espera. --drain-time-s, 10 minuts per defecte.

Continuar.

Font: www.habr.com