Groetnis! Dit is in koart artikel dat de fragen beantwurdet: "wat is gesant?", "wêrom is it nedich?" en "wêr te begjinnen?".
Wat is dit
Envoy is in L4-L7 balancer skreaun yn C ++, rjochte op hege prestaasjes en beskikberens. Oan 'e iene kant is dit op ien of oare manier in analoog fan nginx en haproxy, fergelykber yn prestaasjes mei har. Oan 'e oare kant is it mear oriïntearre op mikroservice-arsjitektuer en hat funksjonaliteit net slimmer dan java en go balancers, lykas zuul of traefik.
Fergeliking tabel fan haproxy / nginx / envoy, it beweart net dat it de absolute wierheid is, mar jout in algemien byld.
nginx
haproksy
ferstjoerd
traefik
stjerren op github
11.2k/spegel
1.1k/spegel
12.4k
27.6k
skreaun yn
C
C
C ++
go
API
gjin
socket allinne / push
dataplane / pull
lûke
aktive sûnenscheck
gjin
ja
ja
ja
Iepen tracing
eksterne plugin
gjin
ja
ja
J.W.T.
eksterne plugin
gjin
ja
gjin
extension
Lua/C
Lua/C
Lua/C++
gjin
Wat foar
Dit is in jong projekt, der ûntbrekt in protte dingen, guon yn 'e iere alfa. Mar ferstjoerd, ek troch syn jeugd, ûntwikkelet rap en hat al in protte nijsgjirrige funksjes: dynamyske konfiguraasje, in protte klearmakke filters, in ienfâldige ynterface foar it skriuwen fan jo eigen filters.
Hjirút folgje gebieten fan tapassing, mar earst binne d'r 2 antipatterns:
- Statyske recoil.
It feit is dat op it stuit yn ferstjoerd gjin caching stipe. De Google-jonges besykje dit
Brûk no nginx foar statika.
- Statyske konfiguraasje.
Jo kinne it brûke, mar ferstjoerd Dêr is it net foar makke. Funksjes yn in statyske konfiguraasje wurde net bleatsteld. D'r binne in protte mominten:
By it bewurkjen fan de konfiguraasje yn yaml, sille jo fersin wurde, skele de ûntwikkelders út foar verbosity en tinke dat de nginx/haproxy-konfiguraasjes, hoewol minder strukturearre, koarter binne. Dat is it punt. De konfiguraasje fan Nginx en Haproxy waard makke foar it bewurkjen mei de hân, en ferstjoerd foar generaasje út koade. De hiele konfiguraasje wurdt beskreaun yn
Canary, b / g-ynsetsenario's en folle mear wurde normaal allinich ymplementearre yn in dynamyske konfiguraasje. Ik sis net dat dit net statysk kin, wy dogge it allegear. Mar hjirfoar moatte jo op krukken sette, yn ien fan 'e balancers, yn ferstjoerd ynklusyf.
Taken wêrfoar envoy ûnmisber is:
- Ferkear balâns yn komplekse en dynamyske systemen. Dit omfettet it tsjinstmesh, mar it is net needsaaklik de ienige.
- De needsaak foar ferdielde tracingfunksjonaliteit, komplekse autorisaasje of oare funksjonaliteit dy't beskikber is yn ferstjoerd út 'e doaze of handich ymplementearre, mar yn nginx / haproxy jo moatte wurde omjûn troch lua en dubieuze plugins.
Beide, as it nedich is, leverje hege prestaasjes.
Hoe docht dit wurk
Envoy wurdt allinich ferspraat yn binaries as in docker-ôfbylding. De ôfbylding befettet al in foarbyld fan in statyske konfiguraasje. Mar wy binne ynteressearre yn it allinnich foar it begripen fan de struktuer.
envoy.yaml statyske konfiguraasje
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
Dynamyske konfiguraasje
Foar hokker probleem sykje wy in oplossing? Jo kinne de load balancer-konfiguraasje net gewoan opnij laden ûnder load; "lytse" problemen sille ûntstean:
- Konfiguraasje falidaasje.
De konfiguraasje kin wêze grut, it kin wêze hiel grut, as wy overload it allegear yn ien kear, de kâns op in flater earne tanimme.
- Lange libbene ferbiningen.
By it inisjalisearjen fan in nije harker, moatte jo soargje foar de ferbiningen dy't rinne op 'e âlde; as feroaringen faak foarkomme en d'r binne langlibbene ferbiningen, moatte jo nei in kompromis sykje. Hallo, kubernetes ingress op nginx.
- Aktive sûnenskontrôles.
As wy aktive sûnenskontrôles hawwe, moatte wy se allegear dûbel kontrolearje yn 'e nije konfiguraasje foardat jo ferkear ferstjoere. As der in protte streamop binne, nimt dit tiid. Hallo haproxy.
Hoe wurdt dit oplost yn ferstjoerdTroch de konfiguraasje dynamysk te laden, neffens it swimbadmodel, kinne jo it diele yn aparte dielen en it diel dat net feroare is net opnij inisjalisearje. Bygelyks in harker, dy't djoer is om opnij te begjinnen en selden feroaret.
Konfiguraasje ferstjoerd (fan it hjirboppe bestân) hat de folgjende entiteiten:
- harker - harker hinget op in spesifike ip / haven
- firtuele host - firtuele host troch domeinnamme
- wei - balânsregel
- cluster - in groep upstreams mei balânsjende parameters
- einpunt - upstream eksimplaar adres
Elk fan dizze entiteiten plus guon oaren kinne dynamysk ynfolle wurde; hjirfoar spesifisearret de konfiguraasje it adres fan 'e tsjinst fan wêr't de konfiguraasje sil wurde ûntfongen. De tsjinst kin REST of gRPC wêze, gRPC is de foarkar.
De tsjinsten wurde respektivelik neamd: LDS, VHDS, RDS, CDS en EDS. Jo kinne kombinearje statyske en dynamyske konfiguraasje, mei de beheining dat in dynamyske boarne kin net oantsjutte yn in statyske.
Foar de measte taken is it genôch om de lêste trije tsjinsten út te fieren, se wurde ADS (Aggregated Discovery Service) neamd, foar
De konfiguraasje nimt de folgjende foarm:
envoy.yaml dynamyske konfiguraasje
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
By it opstarten ferstjoerd mei dizze konfiguraasje sil it ferbine mei it kontrôlefleanmasine en besykje de RDS-, CDS- en EDS-konfiguraasje oan te freegjen. Hoe't it ynteraksjeproses bart, wurdt beskreaun
Koartsein, ferstjoerd stjoert in fersyk dat oanjout fan it type boarne dat frege wurdt, de ferzje en parameters fan it knooppunt. As antwurd ûntfangt it in boarne en in ferzje; as de ferzje op it kontrôlefleanmasine net feroare is, reagearret it net.
D'r binne 4 ynteraksje opsjes:
- Ien gRPC-stream foar alle soarten boarnen, de folsleine status fan 'e boarne wurdt ferstjoerd.
- Aparte streamen, folsleine steat.
- Ien stream, inkrementele steat.
- Aparte streamen, inkrementele steat.
Incremental xDS kinne jo ferminderje ferkear tusken de kontrôle-fleantúch en ferstjoerd, dit is relevant foar grutte konfiguraasjes. Mar it komplisearret de ynteraksje; it fersyk befettet in list mei boarnen foar ôfmelde en ynskriuwe.
Us foarbyld brûkt ADS - ien stream foar RDS, CDS, EDS en net-inkrementele modus. Om ynkrementele modus yn te skeakeljen, moatte jo spesifisearje api_type: DELTA_GRPC
Sûnt it fersyk befettet knooppunt parameters, kinne wy stjoere ferskillende boarnen nei it kontrôle-fleantúch foar ferskate eksimplaren ferstjoerd, dit is handich foar it bouwen fan in tsjinstmesh.
Opwaarmje
op ferstjoerd by it opstarten of by it ûntfangen fan in nije konfiguraasje fan kontrôle-fleantúch, wurdt it resource warmupproses lansearre. It is ferdield yn harker warmup en cluster warmup. De earste wurdt lansearre as der feroaringen binne yn RDS / LDS, de twadde as CDS / EDS. Dit betsjut dat as allinich streamen feroarje, de harker net opnij makke wurdt.
Tidens it opwaarmingproses wurde ôfhinklike boarnen ferwachte fan it kontrôlefleanmasine tidens de time-out. As de time-out foarkomt, sil inisjalisaasje net suksesfol wêze en sil de nije harker net begjinne te harkjen op 'e haven.
Inisjalisaasjeoarder: EDS, CDS, aktive sûnenskontrôle, RDS, LDS. Mei aktive sûnenskontrôles ynskeakele, sil ferkear allinich streamop gean nei ien suksesfolle sûnenskontrôle.
As de harker opnij oanmakke is, giet de âlde yn 'e DRAIN-status en sil wiske wurde nei't alle ferbiningen sluten binne of de timeout ferrint --drain-time-s
, standert 10 minuten.
To continue.
Boarne: www.habr.com