დესპანი. 1. შესავალი

სალამი! ეს არის მოკლე სტატია, რომელიც პასუხობს კითხვებს: "რა არის დესპანი?", "რატომ არის საჭირო?" და "სად დავიწყოთ?".

რა არის ეს?

Envoy არის L4-L7 ბალანსერი დაწერილი C++-ში, რომელიც ორიენტირებულია მაღალ შესრულებაზე და ხელმისაწვდომობაზე. ერთის მხრივ, ეს გარკვეულწილად არის nginx-ისა და ჰაპროქსიის ანალოგი, რომელიც შედარებულია მათთან შესრულებით. მეორეს მხრივ, ის უფრო მეტად არის ორიენტირებული მიკროსერვისის არქიტექტურაზე და აქვს ფუნქციონირება არა უარესი ვიდრე java and go ბალანსერები, როგორიცაა zuul ან traefik.

ჰაპროქსის/ნგინქსის/დესპანის შედარების ცხრილი, ის არ აცხადებს აბსოლუტურ სიმართლეს, მაგრამ იძლევა ზოგად სურათს.

nginx
ჰაპროქსია
გაგზავნილი
ტრეფიკი

ვარსკვლავები github-ზე
11.2k/სარკე
1.1k/სარკე
12.4k
27.6k

ჩაწერილი
C
C
C + +
go

API
არარის
მხოლოდ სოკეტი/ბიძგი
მონაცემთა თვითმფრინავი/გაყვანილობა
გაიყვანოს

აქტიური ჯანმრთელობის შემოწმება
არარის
დიახ
დიახ
დიახ

ღია მიკვლევა
გარე მოდული
არარის
დიახ
დიახ

J.W.T.
გარე მოდული
არარის
დიახ
არარის

გაფართოება
ლუა/კ
ლუა/კ
ლუა/C++
არარის

რა არის

ეს ახალგაზრდა პროექტია, ბევრი რამ აკლია, ზოგი ადრეულ ალფაში. მაგრამ გაგზავნილი, ასევე ახალგაზრდობიდან გამომდინარე, სწრაფად ვითარდება და უკვე აქვს ბევრი საინტერესო ფუნქცია: დინამიური კონფიგურაცია, ბევრი მზა ფილტრი, მარტივი ინტერფეისი საკუთარი ფილტრების დასაწერად.
გამოყენების სფეროები აქედან გამომდინარეობს, მაგრამ პირველ რიგში არის 2 ანტიპატერნი:

• სტატიკური უკუცემა.

ფაქტია, რომ ამ მომენტში ქ გაგზავნილი არ არის ქეშირების მხარდაჭერა. Google-ის ბიჭები ამას ცდილობენ დაფიქსირება. იდეა განხორციელდება ერთხელ გაგზავნილი RFC შესაბამისობის ყველა დახვეწილობა (ზოოპარკის სათაურები) და კონკრეტული განხორციელებისთვის შექმენით ინტერფეისი. მაგრამ ახლა ეს ალფაც კი არ არის, არქიტექტურა განხილვის პროცესშია, PR ღია (პიარის სტატიას რომ ვწერდი, პიარი გაიყინა, მაგრამ ეს პუნქტი მაინც აქტუალურია).

ამ დროისთვის გამოიყენეთ nginx სტატიკისთვის.

• სტატიკური კონფიგურაცია.

შეგიძლიათ გამოიყენოთ, მაგრამ გაგზავნილი ამისთვის არ შეიქმნა. სტატიკური კონფიგურაციის ფუნქციები არ იქნება გამოვლენილი. ბევრი მომენტია:

Yaml-ში კონფიგურაციის რედაქტირებისას შეცდებით, გაკიცხავთ დეველოპერებს სიტყვიერების გამო და ფიქრობთ, რომ nginx/haproxy კონფიგურაციები, თუმცა ნაკლებად სტრუქტურირებული, მაგრამ უფრო ლაკონურია. Ამაშია ზუსტად ამის აზრი. Nginx-ისა და Haproxy-ის კონფიგურაცია შეიქმნა ხელით რედაქტირებისთვის და გაგზავნილი კოდიდან გენერირებისთვის. მთელი კონფიგურაცია აღწერილია პროტობუფიპროტო ფაილებიდან მისი გენერირება გაცილებით რთულია შეცდომის დაშვება.

Canary, b/g განლაგების სცენარები და მრავალი სხვა ჩვეულებრივ ხორციელდება მხოლოდ დინამიურ კონფიგურაციაში. მე არ ვამბობ, რომ ეს არ შეიძლება გაკეთდეს სტატიკურად, ჩვენ ამას ყველა ვაკეთებთ. მაგრამ ამისათვის თქვენ უნდა ჩაიცვათ ხელჯოხები, ნებისმიერ ბალანსერში, შიგნით გაგზავნილი მათ შორის

ამოცანები, რომელთათვისაც ელჩი შეუცვლელია:

• მოძრაობის დაბალანსება რთულ და დინამიურ სისტემებში. ეს მოიცავს სერვისის ქსელს, მაგრამ ის სულაც არ არის ერთადერთი.
• განაწილებული მიკვლევის ფუნქციონირების, რთული ავტორიზაციის ან სხვა ფუნქციონირების საჭიროება, რომელიც ხელმისაწვდომია გაგზავნილი out of box ან მოხერხებულად დანერგილი, მაგრამ 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/პორტზე დაკიდებული მსმენელი
• ვირტუალური მასპინძელი - ვირტუალური ჰოსტი დომენის სახელით
• მარშრუტი - დაბალანსების წესი
• კასეტური — ზედა დინების ჯგუფი ბალანსირების პარამეტრებით
• საბოლოო - ზემოთ ინსტანციის მისამართი

თითოეული ეს ერთეული პლუს ზოგიერთი სხვა შეიძლება შეივსოს დინამიურად; ამისათვის კონფიგურაცია განსაზღვრავს სერვისის მისამართს, საიდანაც მიიღება კონფიგურაცია. სერვისი შეიძლება იყოს 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 ნაკადი ყველა ტიპის რესურსისთვის, იგზავნება რესურსის სრული სტატუსი.
• ცალკე ნაკადები, სრული მდგომარეობა.
• ერთი ნაკადი, დამატებითი მდგომარეობა.
• ცალკეული ნაკადები, ინკრემენტული მდგომარეობა.

დამატებითი xDS საშუალებას გაძლევთ შეამციროთ მოძრაობა საკონტროლო სიბრტყეს შორის და გაგზავნილი, ეს აქტუალურია დიდი კონფიგურაციისთვის. მაგრამ ეს ართულებს ურთიერთქმედებას; მოთხოვნა შეიცავს რესურსების ჩამონათვალს გამოწერისა და გამოწერისთვის.

ჩვენს მაგალითში გამოიყენება ADS - ერთი ნაკადი RDS, CDS, EDS და არაინკრემენტული რეჟიმისთვის. დამატებითი რეჟიმის გასააქტიურებლად, თქვენ უნდა მიუთითოთ api_type: DELTA_GRPC

ვინაიდან მოთხოვნა შეიცავს კვანძის პარამეტრებს, ჩვენ შეგვიძლია გავაგზავნოთ სხვადასხვა რესურსი საკონტროლო სიბრტყეში სხვადასხვა ინსტანციისთვის გაგზავნილი, ეს მოსახერხებელია სერვისის ბადის ასაგებად.

Გახურება

წლის გაგზავნილი გაშვებისას ან საკონტროლო სიბრტყიდან ახალი კონფიგურაციის მიღებისას, იწყება რესურსის გახურების პროცესი. ის იყოფა მსმენელად და კლასტერულ დათბობად. პირველი იხსნება, როდესაც ხდება ცვლილებები RDS/LDS-ში, მეორე როცა CDS/EDS. ეს ნიშნავს, რომ თუ მხოლოდ ზედა დინების ცვლილება ხდება, მსმენელი ხელახლა არ იქმნება.

გახურების პროცესის დროს, საკონტროლო სიბრტყედან დამოკიდებული რესურსებია მოსალოდნელი ტაიმაუტის დროს. თუ ვადაა, ინიციალიზაცია წარმატებული არ იქნება და ახალი მსმენელი არ დაიწყებს მოსმენას პორტზე.
ინიციალიზაციის ბრძანება: EDS, CDS, აქტიური ჯანმრთელობის შემოწმება, RDS, LDS. აქტიური ჯანმრთელობის შემოწმების ჩართვის შემთხვევაში, ტრაფიკი გადავა მხოლოდ ერთი წარმატებული ჯანმრთელობის შემოწმების შემდეგ.

თუ მსმენელი ხელახლა შეიქმნა, ძველი გადადის DRAIN მდგომარეობაში და წაიშლება ყველა კავშირის დახურვის ან ვადის ამოწურვის შემდეგ --drain-time-sნაგულისხმევი 10 წუთი.

გაგრძელდება.

წყარო: www.habr.com