Απεσταλμένος. 1. Εισαγωγή

Χαιρετίσματα! Αυτό είναι ένα σύντομο άρθρο που απαντά στις ερωτήσεις: "Τι είναι απεσταλμένος;", "Γιατί χρειάζεται;" και "από πού να ξεκινήσω;"

Τι είναι αυτό;

Το Envoy είναι ένας εξισορροπητής φορτίου C++ L4-L7 που εστιάζει στην υψηλή απόδοση και τη διαθεσιμότητα. Από τη μία πλευρά, είναι κατά κάποιο τρόπο ένα ανάλογο του nginx και του haproxy, συγκρίσιμο με αυτά ως προς την απόδοση. Από την άλλη πλευρά, είναι περισσότερο προσανατολισμένο στην αρχιτεκτονική microservice και έχει λειτουργικότητα όχι χειρότερη από τους balancers σε Java και Go, όπως το zuul ή το traefik.

Συγκριτικός πίνακας haproxy/nginx/envoy, δεν ισχυρίζεται ότι είναι η απόλυτη αλήθεια, αλλά δίνει μια γενική εικόνα.

nginx
απροξία
αποστέλλονται
κυκλοφορία

αστέρια στο github
11.2k/καθρέφτης
1.1k/καθρέφτης
12.4k
27.6k

γραμμένο σε
C
C
C + +
go

API
όχι
μόνο πρίζα/σπρώξιμο
αεροπλάνο/τράβηγμα
τραβήξτε

ενεργό υγειονομικό έλεγχο
όχι
да
да
да

Ανοιχτή ανίχνευση
εξωτερικό πρόσθετο
όχι
да
да

J.W.T.
εξωτερικό πρόσθετο
όχι
да
όχι

επέκταση
Lua/C
Lua/C
Lua/C++
όχι

Γιατί

Αυτό είναι ένα νεανικό έργο, λείπουν πολλά πράγματα, μερικά είναι στην αρχή του alpha. Αλλά αποστέλλονται, μεταξύ άλλων λόγω της νεότητάς του, αναπτύσσεται γρήγορα και έχει ήδη πολλά ενδιαφέροντα χαρακτηριστικά: δυναμική διαμόρφωση, πολλά έτοιμα φίλτρα, μια απλή διεπαφή για τη σύνταξη των δικών σας φίλτρων.
Οι τομείς εφαρμογής προκύπτουν από αυτό, αλλά πρώτα, 2 αντι-μοτίβα:

  • Στατική ανάκρουση.

Το θέμα είναι ότι αυτή τη στιγμή μέσα αποστέλλονται δεν υπάρχει υποστήριξη προσωρινής αποθήκευσης. Τα παιδιά από το google το δοκιμάζουν να διορθώσω. Η ιδέα είναι να το εφαρμόζουμε μια στο τόσο αποστέλλονται όλες τις λεπτές αποχρώσεις (zoo of headers) της συμμόρφωσης με το RFC και δημιουργήστε μια διεπαφή για συγκεκριμένες υλοποιήσεις. Αλλά αυτό δεν είναι καν άλφα ακόμα, η αρχιτεκτονική είναι υπό συζήτηση, PR ανοιχτό (ενώ έγραφα το άρθρο, το PR συγχωνεύτηκε, αλλά αυτό το σημείο εξακολουθεί να είναι επίκαιρο).

Στο μεταξύ, χρησιμοποιήστε το nginx για στατικά.

  • Στατική διαμόρφωση.

Μπορείτε να το χρησιμοποιήσετε, αλλά αποστέλλονται δεν δημιουργήθηκε για αυτό. Οι δυνατότητες στη στατική διαμόρφωση δεν θα αποκαλυφθούν. Υπάρχουν πολλές στιγμές:

Όταν επεξεργάζεστε τη διαμόρφωση στο yaml, θα κάνετε λάθη, θα καταραστείτε τους προγραμματιστές επειδή είναι πολυλογείς και θα πιστεύετε ότι οι ρυθμίσεις παραμέτρων nginx/haproxy, αν και λιγότερο δομημένες, είναι πιο συνοπτικές. Αυτό είναι το θέμα. Η διαμόρφωση Nginx και Haproxy δημιουργήθηκε για χειροκίνητη επεξεργασία και αποστέλλονται για παραγωγή από κώδικα. Ολόκληρη η διαμόρφωση περιγράφεται στο πρωτόφουφ, η δημιουργία του από πρωτότυπα αρχεία καθιστά πολύ πιο δύσκολο να κάνετε λάθος.

Τα σενάρια ανάπτυξης Canary, b/g και πολλά άλλα συνήθως εφαρμόζονται μόνο σε δυναμική διαμόρφωση. Δεν λέω ότι δεν γίνεται στατικά, το κάνουμε όλοι. Αλλά για αυτό πρέπει να βάλετε πατερίτσες, σε οποιοδήποτε από τα εξισορροπητικά, μέσα αποστέλλονται συμπεριλαμβανομένου.

Καθήκοντα όπου ο Απεσταλμένος είναι απαραίτητος:

  • Εξισορρόπηση κίνησης σε πολύπλοκα και δυναμικά συστήματα. Το σέρβις πλέγμα πέφτει εδώ, αλλά δεν είναι απαραίτητα το μόνο.
  • Η ανάγκη για κατανεμημένη ανίχνευση, περίπλοκη εξουσιοδότηση ή άλλη λειτουργικότητα που είναι διαθέσιμη στο αποστέλλονται out of the box ή με βολική εφαρμογή, και στο nginx/haproxy πρέπει να περιβάλλεστε με lua και αμφισβητήσιμα πρόσθετα.

Και τα δύο είναι διαθέσιμα για να παρέχουν υψηλή απόδοση όταν απαιτείται.

Πώς λειτουργεί;

Το Envoy διανέμεται σε δυαδικά αρχεία μόνο ως εικόνα docker. Η εικόνα περιέχει ήδη ένα παράδειγμα στατικής διαμόρφωσης. Αλλά μας ενδιαφέρει μόνο για την κατανόηση της δομής.

στατική διαμόρφωση 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

Δυναμική διαμόρφωση

Σε ποιο πρόβλημα αναζητούμε λύση; Δεν μπορείτε απλώς να επανεκκινήσετε τη διαμόρφωση του εξισορροπητή υπό φόρτωση, θα προκύψουν "μικρά" προβλήματα:

  • Επικύρωση διαμόρφωσης.

Το config μπορεί να είναι μεγάλο, μπορεί να είναι πολύ μεγάλο, αν το υπερφορτώσουμε ταυτόχρονα, αυξάνονται οι πιθανότητες να υπάρχει κάπου κάποιο σφάλμα.

  • Μακροχρόνιες συνδέσεις.

Κατά την προετοιμασία ενός νέου ακροατή, πρέπει να φροντίσετε τις συνδέσεις που εκτελούνται στην παλιά. Εάν οι αλλαγές συμβαίνουν συχνά και υπάρχουν μακροχρόνιες συνδέσεις, θα πρέπει να βρείτε έναν συμβιβασμό. Γεια σας, kubernetes ingress στο nginx.

  • Ενεργοί έλεγχοι υγείας.

Εάν έχουμε ενεργούς ελέγχους υγείας, θα πρέπει να τους ελέγξουμε ξανά όλους στη νέα διαμόρφωση πριν στείλουμε επισκεψιμότητα. Αν υπάρχουν πολλά upstream, χρειάζεται χρόνος. Γεια σου, χαπροξί.

Πώς λύνεται αυτό σε αποστέλλονται, φορτώνοντας δυναμικά το config, ανάλογα με το μοντέλο του pool, μπορείτε να το χωρίσετε σε ξεχωριστά μέρη και να μην αρχικοποιήσετε ξανά το τμήμα που δεν έχει αλλάξει. Για παράδειγμα, ένας ακροατής, του οποίου είναι ακριβό να αρχικοποιηθεί ξανά, και αλλάζει σπάνια.

Διαμόρφωση αποστέλλονται (από το παραπάνω αρχείο) έχει τις ακόλουθες οντότητες:

  • ακροατής — ακροατής που κρέμεται σε μια συγκεκριμένη ip/θύρα
  • εικονικός οικοδεσπότης - εικονικός κεντρικός υπολογιστής με όνομα τομέα
  • Διαδρομή — κανόνας εξισορρόπησης
  • συστάδα — ομάδα ανάντη με παραμέτρους εξισορρόπησης
  • καταληκτικό σημείο — διεύθυνση ανοδικής παρουσίας

Κάθε μία από αυτές τις οντότητες και κάποιες άλλες μπορούν να συμπληρωθούν δυναμικά, για το σκοπό αυτό η διεύθυνση της υπηρεσίας από την οποία θα ληφθεί η διαμόρφωση καθορίζεται στη διαμόρφωση. Η υπηρεσία μπορεί να είναι REST ή gRPC, προτιμάται το gRPC.

Οι υπηρεσίες ονομάζονται ανάλογα: LDS, VHDS, RDS, CDS και EDS. Είναι δυνατός ο συνδυασμός στατικής και δυναμικής διαμόρφωσης, με τον περιορισμό ότι ένας δυναμικός πόρος δεν μπορεί να καθοριστεί σε έναν στατικό.

Για τις περισσότερες εργασίες, αρκεί να υλοποιηθούν οι τρεις τελευταίες υπηρεσίες, που ονομάζονται ADS (Aggregated Discovery Service), για Ιάβα Το and go έχει μια έτοιμη υλοποίηση του gRPC dataplane, στο οποίο χρειάζεται μόνο να συμπληρώσετε αντικείμενα από την πηγή σας.

Η διαμόρφωση έχει την ακόλουθη μορφή:

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 και non-incremental mode. Για να ενεργοποιήσετε την αυξητική λειτουργία, πρέπει να καθορίσετε api_type: DELTA_GRPC

Εφόσον το αίτημα περιέχει παραμέτρους κόμβου, μπορούμε να στείλουμε διαφορετικούς πόρους στο επίπεδο ελέγχου για διαφορετικές περιπτώσεις. αποστέλλονται, αυτό είναι βολικό για την κατασκευή ενός πλέγματος εξυπηρέτησης.

Ζέσταμα

Επί αποστέλλονται Κατά την εκκίνηση ή κατά τη λήψη μιας νέας διαμόρφωσης από το επίπεδο ελέγχου, ξεκινά η διαδικασία προθέρμανσης πόρων. Χωρίζεται σε προθέρμανση ακροατή και προθέρμανση συμπλέγματος. Το πρώτο εκκινείται όταν υπάρχουν αλλαγές στο RDS/LDS, το δεύτερο όταν υπάρχουν αλλαγές στο CDS/EDS. Αυτό σημαίνει ότι αν αλλάξουν μόνο τα upstream, ο ακροατής δεν αναδημιουργείται.

Κατά τη διαδικασία προθέρμανσης, αναμένονται εξαρτημένοι πόροι από το επίπεδο ελέγχου κατά τη διάρκεια του χρονικού ορίου. Εάν λήξει το χρονικό όριο, η προετοιμασία δεν θα είναι επιτυχής και ο νέος ακροατής δεν θα αρχίσει να ακούει στη θύρα.
Εντολή αρχικοποίησης: EDS, CDS, ενεργός έλεγχος υγείας, RDS, LDS. Όταν είναι ενεργοποιημένοι οι ενεργοί έλεγχοι υγείας, η κυκλοφορία θα πηγαίνει ανάντη μόνο μετά από έναν επιτυχημένο έλεγχο υγείας.

Εάν ένας ακροατής αναδημιουργηθεί, ο παλιός μεταβαίνει σε κατάσταση DRAIN και θα διαγραφεί αφού κλείσουν όλες οι συνδέσεις ή λήξει το χρονικό όριο. --drain-time-s, προεπιλογή 10 λεπτά.

Συνεχίζεται.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο