բանագնաց. 1. Ներածություն

Ողջույններ: Սա կարճ հոդված է, որը պատասխանում է «ի՞նչ է բանագնացը», «ինչո՞ւ է դա անհրաժեշտ» հարցերին։ և «որտեղի՞ց սկսել»:

Ինչ է սա

Envoy-ը L4-L7 հավասարակշռող է, որը գրված է C++-ով, որը կենտրոնացած է բարձր կատարողականության և հասանելիության վրա: Մի կողմից, սա ինչ-որ կերպ nginx-ի և haproxy-ի անալոգն է, որն իր կատարողականությամբ համեմատելի է նրանց հետ: Մյուս կողմից, այն ավելի կողմնորոշված ​​է դեպի միկրոսերվիսային ճարտարապետություն և ունի ֆունկցիոնալություն ոչ ավելի վատ, քան java and go հավասարակշռողները, ինչպիսիք են zuul-ը կամ traefik-ը:

Հապրոքսի/նգինքս/պատգամավորի համեմատական ​​աղյուսակը չի հավակնում լինել բացարձակ ճշմարտության, այլ տալիս է ընդհանուր պատկեր։

nginx
հիդրոքսին
ուղարկվել
տրեֆիկ

աստղեր github-ում
11.2կ/հայելին
1.1կ/հայելին
12.4k
27.6k

գրված է
C
C
C ++
go

API
ոչ
միայն վարդակից/հրել
տվյալների ինքնաթիռ/քաշեք
քաշել

ակտիվ առողջության ստուգում
ոչ
այո
այո
այո

Բաց հետագծում
արտաքին plugin
ոչ
այո
այո

Ջ.Վ.Տ.
արտաքին plugin
ոչ
այո
ոչ

երկարացնելը
Լուա/Կ
Լուա/Կ
Lua/C++
ոչ

Ինչի համար

Սա երիտասարդ նախագիծ է, շատ բան է պակասում, որոշները վաղ ալֆայում: Բայց ուղարկվել, նաև իր երիտասարդության շնորհիվ, արագ զարգանում է և արդեն ունի շատ հետաքրքիր առանձնահատկություններ՝ դինամիկ կոնֆիգուրացիա, բազմաթիվ պատրաստի ֆիլտրեր, պարզ ինտերֆեյս՝ սեփական ֆիլտրերը գրելու համար։
Կիրառման ոլորտները բխում են դրանից, բայց նախ կան 2 հակապատկեր.

• Ստատիկ հետք.

Փաստն այն է, որ այս պահին ներս ուղարկվել քեշավորման աջակցություն չկա: Google-ի տղաները փորձում են սա ամրագրել. Գաղափարը կիրականացվի մեկ անգամ ուղարկվել RFC-ի համապատասխանության բոլոր նրբությունները (կենդանաբանական այգու վերնագրերը) և հատուկ իրականացումների համար ստեղծել ինտերֆեյս: Բայց առայժմ դա նույնիսկ ալֆա չէ, ճարտարապետությունը քննարկման փուլում է, PR բաց (մինչ ես գրում էի PR հոդվածը, PR-ը սառեց, բայց այս կետը դեռ ակտուալ է):

Առայժմ օգտագործեք nginx ստատիկների համար:

• Ստատիկ կոնֆիգուրացիա:

Դուք կարող եք օգտագործել այն, բայց ուղարկվել Դրա համար այն չի ստեղծվել: Ստատիկ կազմաձևման առանձնահատկությունները չեն բացահայտվի: Շատ պահեր կան.

Յամլում կոնֆիգուրացիան խմբագրելիս կսխալվեք, կհանդիմանեք ծրագրավորողներին խոսակցականության համար և կմտածեք, որ nginx/haproxy կոնֆիգուրացիաները, թեև ավելի քիչ կառուցվածքային են, բայց ավելի հակիրճ են։ Դա է կետը: Nginx-ի և Haproxy-ի կոնֆիգուրացիան ստեղծվել է ձեռքով խմբագրելու համար և ուղարկվել կոդից առաջանալու համար։ Ամբողջ կոնֆիգուրացիան նկարագրված է պրոտոբուֆ, պրոտո ֆայլերից այն ստեղծելը շատ ավելի դժվար է սխալվել:

Canary, b/g տեղակայման սցենարները և շատ ավելին սովորաբար իրականացվում են միայն դինամիկ կազմաձևով: Ես չեմ ասում, որ դա ստատիկ կերպով չի կարելի անել, մենք բոլորս դա անում ենք։ Բայց դրա համար դուք պետք է հենակներ հագեք, հավասարակշռողներից որևէ մեկում, ներս ուղարկվել ներառյալ

Առաջադրանքներ, որոնց համար բանագնացը անփոխարինելի է.

• Երթևեկության հավասարակշռում բարդ և դինամիկ համակարգերում: Սա ներառում է սպասարկման ցանցը, բայց պարտադիր չէ, որ այն միակը լինի:
• Բաշխված հետագծման գործառույթի, համալիր թույլտվության կամ այլ ֆունկցիոնալության անհրաժեշտությունը, որը հասանելի է ուղարկվել արկղից դուրս կամ հարմար ներդրված, բայց nginx/haproxy-ում դուք պետք է շրջապատված լինեք lua-ով և կասկածելի փլագիններով:

Երկուսն էլ, անհրաժեշտության դեպքում, ապահովում են բարձր կատարողականություն:

Ինչպես է այն աշխատում

Envoy-ը բաշխվում է երկուական տարբերակով միայն որպես դոկերի պատկեր: Պատկերն արդեն պարունակում է ստատիկ կոնֆիգուրացիայի օրինակ: Բայց դա մեզ հետաքրքրում է միայն կառուցվածքը հասկանալու համար։

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

Դինամիկ կոնֆիգուրացիա

Ի՞նչ խնդրի լուծում ենք փնտրում։ Դուք չեք կարող պարզապես վերաբեռնել բեռի հավասարակշռիչի կոնֆիգուրացիան ծանրաբեռնվածության տակ, «փոքր» խնդիրներ կառաջանան.

• Կազմաձևման վավերացում:

Կազմաձևը կարող է մեծ լինել, կարող է լինել շատ մեծ, եթե այն միանգամից ծանրաբեռնենք, ինչ-որ տեղ սխալվելու հավանականությունը մեծանում է։

• Երկարատև կապեր.

Նոր լսողին սկզբնավորելիս պետք է հոգ տանել հնի վրա աշխատող կապերի մասին, եթե հաճախակի փոփոխություններ են տեղի ունենում և երկարատև կապեր կան, դուք պետք է փոխզիջում փնտրեք: Ողջույն, kubernetes-ը ներխուժում է nginx-ում:

• Ակտիվ առողջական ստուգումներ.

Եթե ​​մենք ունենք ակտիվ առողջական ստուգումներ, մենք պետք է կրկնակի ստուգենք դրանք բոլորը նոր կազմաձևում, նախքան տրաֆիկ ուղարկելը: Եթե ​​վերին հոսքերը շատ են, ապա դա ժամանակ է պահանջում: Բարև հապրոքսի:

Ինչպես է դա լուծվում ուղարկվելԿազմաձևը դինամիկ բեռնելով, ըստ լողավազանի մոդելի, դուք կարող եք այն բաժանել առանձին մասերի և չվերսկսել այն մասը, որը չի փոխվել: Օրինակ՝ ունկնդիր, որի վերսկսումը թանկ է և հազվադեպ է փոխվում:

Տեսիլ ուղարկվել (վերը նշված ֆայլից) ունի հետևյալ սուբյեկտները.

• ունկնդիր — լսող, որը կախված է կոնկրետ ip/port-ից
• վիրտուալ հյուրընկալող - վիրտուալ հոսթ դոմենի անունով
• երթուղին - հավասարակշռման կանոն
• բույլ — վերին հոսանքների խումբ՝ հավասարակշռող պարամետրերով
• վերջնակետ — վերին ատյանի հասցե

Այս սուբյեկտներից յուրաքանչյուրը և մի քանիսը կարող են լրացվել դինամիկ կերպով, դրա համար կոնֆիգուրացիան նշում է ծառայության հասցեն, որտեղից կստացվի կազմաձևը: Ծառայությունը կարող է լինել REST կամ gRPC, նախընտրելի է gRPC:

Ծառայությունները կոչվում են համապատասխանաբար՝ LDS, VHDS, RDS, CDS և EDS: Դուք կարող եք համատեղել ստատիկ և դինամիկ կոնֆիգուրացիան՝ այն սահմանափակմամբ, որ դինամիկ ռեսուրսը չի կարող նշվել ստատիկում:

Առաջադրանքների մեծ մասի համար բավական է իրականացնել վերջին երեք ծառայությունները, դրանք կոչվում են ADS (Aggregated Discovery Service), Java և գնացեք, կա gRPC տվյալների պլանի պատրաստի իրականացում, որտեղ դուք պարզապես պետք է լրացնեք օբյեկտները ձեր աղբյուրից:

Կազմաձևը ստանում է հետևյալ ձևը.

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

Վազելիս ուղարկվել Այս կոնֆիգուրով այն կմիանա կառավարման հարթությանը և կփորձի պահանջել RDS, CDS և EDS կոնֆիգուրացիա: Նկարագրված է, թե ինչպես է տեղի ունենում փոխազդեցության գործընթացը այստեղ.

Կարճ ասած, ուղարկվել ուղարկում է հարցում՝ նշելով պահանջվող ռեսուրսի տեսակը, հանգույցի տարբերակը և պարամետրերը: Ի պատասխան՝ այն ստանում է ռեսուրս և տարբերակ, եթե կառավարման հարթության տարբերակը չի փոխվել, չի արձագանքում։
Փոխազդեցության 4 տարբերակ կա.

• Մեկ gRPC հոսք բոլոր տեսակի ռեսուրսների համար, ռեսուրսի ամբողջական կարգավիճակն ուղարկվում է:
• Առանձին առուներ, լրիվ վիճակ։
• Մեկ հոսք, աստիճանական վիճակ:
• Առանձին հոսքեր, աստիճանական վիճակ։

Incremental xDS-ը թույլ է տալիս նվազեցնել երթևեկությունը կառավարման հարթության և ուղարկվել, սա տեղին է մեծ կոնֆիգուրացիաների համար: Բայց դա բարդացնում է փոխազդեցությունը, հարցումը պարունակում է ռեսուրսների ցանկ՝ բաժանորդագրությունից դուրս գալու և բաժանորդագրվելու համար:

Մեր օրինակն օգտագործում է ADS՝ մեկ հոսք RDS, CDS, EDS և ոչ աճող ռեժիմների համար: Աճող ռեժիմը միացնելու համար անհրաժեշտ է նշել api_type: DELTA_GRPC

Քանի որ հարցումը պարունակում է հանգույցի պարամետրեր, մենք կարող ենք տարբեր ռեսուրսներ ուղարկել կառավարման հարթություն տարբեր օրինակների համար ուղարկվել, սա հարմար է սպասարկման ցանց կառուցելու համար։

Տաքացում

On ուղարկվել գործարկման ժամանակ կամ կառավարման հարթությունից նոր կոնֆիգուրացիա ստանալիս գործարկվում է ռեսուրսի տաքացման գործընթացը: Այն բաժանված է լսողի տաքացման և կլաստերի տաքացման: Առաջինը գործարկվում է, երբ փոփոխություններ են լինում RDS/LDS-ում, երկրորդը՝ CDS/EDS-ում: Սա նշանակում է, որ եթե միայն վերին հոսքերը փոխվեն, լսողը չի վերստեղծվում:

Տաքացման գործընթացում հսկիչ-հարթությունից կախված ռեսուրսներ են սպասվում թայմաութի ժամանակ: Եթե ​​ժամանակի ավարտը տեղի ունենա, սկզբնավորումը հաջող չի լինի, և նոր լսողը չի սկսի լսել պորտում:
Նախնականացման կարգը՝ EDS, CDS, ակտիվ առողջության ստուգում, RDS, LDS: Եթե ​​ակտիվ առողջական ստուգումները միացված են, երթևեկությունը կշարունակվի վերևում միայն մեկ հաջող առողջական ստուգումից հետո:

Եթե ​​ունկնդիրը վերստեղծվել է, ապա հինը անցնում է DRAIN վիճակի և կջնջվի բոլոր կապերը փակելուց կամ ժամանակի ավարտից հետո: --drain-time-s, լռելյայն 10 րոպե։

Շարունակելի

Source: www.habr.com