Istio και Kubernetes σε παραγωγή. Μέρος 2. Ανίχνευση

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

Το πρώτο πράγμα που έρχεται στο μυαλό πολλών προγραμματιστών και διαχειριστών συστημάτων όταν ακούνε τις λέξεις Service Mesh is tracing. Πράγματι, προσθέτουμε έναν ειδικό διακομιστή μεσολάβησης σε κάθε κόμβο δικτύου από τον οποίο διέρχεται όλη η κίνηση TCP. Φαίνεται ότι είναι πλέον δυνατή η εύκολη αποστολή πληροφοριών σχετικά με όλες τις αλληλεπιδράσεις δικτύου στο δίκτυο. Δυστυχώς, στην πραγματικότητα υπάρχουν πολλές αποχρώσεις που πρέπει να ληφθούν υπόψη. Ας τους δούμε.

Παρανόηση νούμερο ένα: μπορούμε να λάβουμε διαδικτυακά δεδομένα πεζοπορίας δωρεάν.

Στην πραγματικότητα, σχετικά δωρεάν, μπορούμε να συνδέουμε μόνο τους κόμβους του συστήματός μας με βέλη και τον ρυθμό δεδομένων που περνά μεταξύ των υπηρεσιών (στην πραγματικότητα, μόνο τον αριθμό των byte ανά μονάδα χρόνου). Ωστόσο, στις περισσότερες περιπτώσεις, οι υπηρεσίες μας επικοινωνούν μέσω κάποιου είδους πρωτοκόλλου επιπέδου εφαρμογής, όπως HTTP, gRPC, Redis και ούτω καθεξής. Και, φυσικά, θέλουμε να δούμε πληροφορίες ανίχνευσης ειδικά για αυτά τα πρωτόκολλα· θέλουμε να δούμε τον ρυθμό αιτημάτων και όχι τον ρυθμό δεδομένων. Θέλουμε να κατανοήσουμε τον λανθάνοντα χρόνο των αιτημάτων χρησιμοποιώντας το πρωτόκολλό μας. Τέλος, θέλουμε να δούμε την πλήρη διαδρομή που ακολουθεί ένα αίτημα από τη σύνδεση στο σύστημά μας έως τη λήψη απάντησης από τον χρήστη. Αυτό το πρόβλημα δεν είναι πλέον τόσο εύκολο να λυθεί.

Αρχικά, ας δούμε πώς φαίνονται τα ανοίγματα ανίχνευσης αποστολής από αρχιτεκτονική άποψη στο Ίστιο. Όπως θυμόμαστε από το πρώτο μέρος, το Istio έχει ένα ξεχωριστό εξάρτημα που ονομάζεται Mixer για τη συλλογή τηλεμετρίας. Ωστόσο, στην τρέχουσα έκδοση 1.0.*, η αποστολή γίνεται απευθείας από διακομιστές μεσολάβησης, δηλαδή από διακομιστή μεσολάβησης envoy. Ο διακομιστής μεσολάβησης Envoy υποστηρίζει την αποστολή διαστημάτων ανίχνευσης χρησιμοποιώντας το πρωτόκολλο zipkin out of the box. Είναι δυνατή η σύνδεση άλλων πρωτοκόλλων, αλλά μόνο μέσω πρόσθετου. Με το Istio παίρνουμε αμέσως ένα συναρμολογημένο και διαμορφωμένο envoy proxy, το οποίο υποστηρίζει μόνο το πρωτόκολλο zipkin. Εάν θέλουμε να χρησιμοποιήσουμε, για παράδειγμα, το πρωτόκολλο Jaeger και να στείλουμε ανίχνευση ανίχνευσης μέσω UDP, τότε θα χρειαστεί να δημιουργήσουμε τη δική μας εικόνα istio-proxy. Υπάρχει υποστήριξη για προσαρμοσμένα πρόσθετα για istio-proxy, αλλά εξακολουθεί να είναι στην έκδοση alpha. Επομένως, εάν θέλουμε να κάνουμε χωρίς μεγάλο αριθμό προσαρμοσμένων ρυθμίσεων, το εύρος των τεχνολογιών που χρησιμοποιούνται για την αποθήκευση και τη λήψη διαστημάτων ανίχνευσης μειώνεται. Από τα κύρια συστήματα, στην πραγματικότητα, τώρα μπορείτε να χρησιμοποιήσετε το ίδιο το Zipkin ή το Jaeger, αλλά να στείλετε τα πάντα εκεί χρησιμοποιώντας το συμβατό πρωτόκολλο zipkin (το οποίο είναι πολύ λιγότερο αποτελεσματικό). Το ίδιο το πρωτόκολλο zipkin περιλαμβάνει την αποστολή όλων των πληροφοριών εντοπισμού σε συλλέκτες μέσω του πρωτοκόλλου HTTP, το οποίο είναι αρκετά ακριβό.

Όπως είπα ήδη, θέλουμε να ανιχνεύσουμε πρωτόκολλα σε επίπεδο εφαρμογής. Αυτό σημαίνει ότι οι διακομιστές μεσολάβησης που βρίσκονται δίπλα σε κάθε υπηρεσία πρέπει να καταλάβουν τι είδους αλληλεπίδραση συμβαίνει τώρα. Από προεπιλογή, το Istio ρυθμίζει όλες τις θύρες να είναι απλό TCP, πράγμα που σημαίνει ότι δεν θα σταλούν ίχνη. Για να σταλούν τα ίχνη, πρέπει πρώτα να ενεργοποιήσετε αυτήν την επιλογή στη διαμόρφωση του κύριου πλέγματος και, αυτό που είναι πολύ σημαντικό, να ονομάσετε όλες τις θύρες των οντοτήτων υπηρεσίας kubernetes σύμφωνα με το πρωτόκολλο που χρησιμοποιείται στην υπηρεσία. Δηλαδή, για παράδειγμα, ως εξής:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Μπορείτε επίσης να χρησιμοποιήσετε σύνθετα ονόματα όπως http-magic (το Istio θα δει http και θα αναγνωρίσει αυτή τη θύρα ως τελικό σημείο http). Η μορφή είναι: proto-extra.

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

Για να καταλάβετε εάν το πρωτόκολλο έχει όντως οριστεί σωστά, πρέπει να μεταβείτε σε οποιοδήποτε από τα κοντέινερ του sidecar με τον διακομιστή μεσολάβησης και να υποβάλετε αίτημα στη θύρα διαχειριστή της διεπαφής του απεσταλμένου με τοποθεσία /config_dump. Στη διαμόρφωση που προκύπτει, πρέπει να δείτε το πεδίο λειτουργίας της επιθυμητής υπηρεσίας. Χρησιμοποιείται στο Ίστιο ως αναγνωριστικό για το πού υποβάλλεται το αίτημα. Για να προσαρμόσετε την τιμή αυτής της παραμέτρου στο Istio (θα τη δούμε στη συνέχεια στο σύστημα ανίχνευσης), είναι απαραίτητο να καθορίσετε τη σημαία serviceCluster στο στάδιο της εκκίνησης του κοντέινερ sidecar. Για παράδειγμα, μπορεί να υπολογιστεί ως εξής από μεταβλητές που λαμβάνονται από το downward kubernetes API:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Ένα καλό παράδειγμα για να καταλάβετε πώς λειτουργεί η ανίχνευση στον απεσταλμένο εδώ.

Το ίδιο το τελικό σημείο για την αποστολή διαστημάτων ανίχνευσης πρέπει επίσης να προσδιορίζεται στις σημαίες εκκίνησης του διακομιστή μεσολάβησης envoy, για παράδειγμα: --zipkinAddress tracing-collector.tracing:9411

Παρανόηση νούμερο δύο: μπορούμε να λάβουμε ανέξοδα πλήρη ίχνη αιτημάτων μέσω του συστήματος εκτός συσκευασίας

Δυστυχώς, δεν είναι. Η πολυπλοκότητα της υλοποίησης εξαρτάται από το πώς έχετε ήδη εφαρμόσει την αλληλεπίδραση των υπηρεσιών. Γιατί αυτό?

Γεγονός είναι ότι για να μπορέσει ο istio-proxy να κατανοήσει την αντιστοιχία των εισερχόμενων αιτημάτων σε μια υπηρεσία με όσους αποχωρούν από την ίδια υπηρεσία, δεν αρκεί απλώς να υποκλέψει όλη την κίνηση. Πρέπει να έχετε κάποιο είδος αναγνωριστικού επικοινωνίας. Ο διακομιστής μεσολάβησης HTTP envoy χρησιμοποιεί ειδικές κεφαλίδες, με τις οποίες ο envoy κατανοεί ποιο συγκεκριμένο αίτημα προς την υπηρεσία δημιουργεί συγκεκριμένα αιτήματα σε άλλες υπηρεσίες. Λίστα τέτοιων κεφαλίδων:

• x-request-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-sampled,
• σημαίες x-b3,
• x-ot-span-context.

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

Συμπέρασμα

Το Istio παρέχει ένα βολικό εργαλείο για τη συλλογή πληροφοριών ανίχνευσης μέσω ενός δικτύου, αλλά πρέπει να καταλάβετε ότι για την υλοποίηση θα χρειαστεί να προσαρμόσετε το σύστημά σας και να λάβετε υπόψη τα χαρακτηριστικά της υλοποίησης του Istio. Ως αποτέλεσμα, πρέπει να επιλυθούν δύο βασικά σημεία: ο καθορισμός του πρωτοκόλλου επιπέδου εφαρμογής (το οποίο πρέπει να υποστηρίζεται από τον πληρεξούσιο του απεσταλμένου) και η ρύθμιση της προώθησης πληροφοριών σχετικά με τη σύνδεση αιτημάτων στην υπηρεσία από αιτήματα από την υπηρεσία (χρησιμοποιώντας κεφαλίδες , στην περίπτωση του πρωτοκόλλου HTTP). Όταν επιλυθούν αυτά τα ζητήματα, έχουμε ένα ισχυρό εργαλείο που μας επιτρέπει να συλλέγουμε με διαφάνεια πληροφορίες από το δίκτυο, ακόμη και σε πολύ ετερογενή συστήματα γραμμένα σε πολλές διαφορετικές γλώσσες και πλαίσια.

Στο επόμενο άρθρο σχετικά με το Service Mesh, θα εξετάσουμε ένα από τα μεγαλύτερα προβλήματα με το Istio – τη μεγάλη κατανάλωση RAM από κάθε κοντέινερ μεσολάβησης sidecar και θα συζητήσουμε πώς μπορείτε να το αντιμετωπίσετε.

Πηγή: www.habr.com