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

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

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

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

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

nginx
απροξία
αποστέλλονται
traefik

αστέρια στο 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 το δοκιμάζουν να διορθώσω. Η ιδέα θα υλοποιηθεί μια φορά αποστέλλονται όλες οι λεπτές αποχρώσεις (κεφαλίδες ζωολογικού κήπου) της συμμόρφωσης με το 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.

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

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

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

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

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

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

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

Για τις περισσότερες εργασίες, αρκεί να υλοποιηθούν οι τρεις τελευταίες υπηρεσίες, που ονομάζονται ADS (Aggregated Discovery Service), για Ιάβα και πηγαίνετε εκεί υπάρχει μια έτοιμη υλοποίηση του 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 και μη αυξητική λειτουργία. Για να ενεργοποιήσετε την αυξητική λειτουργία, πρέπει να καθορίσετε api_type: DELTA_GRPC

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

Ζέσταμα

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

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

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

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

Πηγή: www.habr.com

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