Σημείωση. μετάφρ.: Οι υπάλληλοι της παγκοσμίως διάσημης υπηρεσίας Tinder μοιράστηκαν πρόσφατα ορισμένες τεχνικές λεπτομέρειες σχετικά με τη μετεγκατάσταση της υποδομής τους στο Kubernetes. Η διαδικασία κράτησε σχεδόν δύο χρόνια και είχε ως αποτέλεσμα την κυκλοφορία μιας πλατφόρμας πολύ μεγάλης κλίμακας στα K8, αποτελούμενη από 200 υπηρεσίες που φιλοξενούνται σε 48 χιλιάδες κοντέινερ. Ποιες ενδιαφέρουσες δυσκολίες αντιμετώπισαν οι μηχανικοί του Tinder και σε ποια αποτελέσματα έφτασαν; Διαβάστε αυτήν τη μετάφραση.
Γιατί;
Πριν από σχεδόν δύο χρόνια, το Tinder αποφάσισε να μεταφέρει την πλατφόρμα του στο Kubernetes. Η Kubernetes θα επέτρεπε στην ομάδα του Tinder να μεταφέρει σε εμπορευματοκιβώτια και να προχωρήσει στην παραγωγή με ελάχιστη προσπάθεια μέσω αμετάβλητης ανάπτυξης (αμετάβλητη ανάπτυξη). Σε αυτήν την περίπτωση, η συναρμολόγηση των εφαρμογών, η ανάπτυξή τους και η ίδια η υποδομή θα ορίζονται μοναδικά από τον κώδικα.
Ψάχναμε επίσης για μια λύση στο πρόβλημα της επεκτασιμότητας και της σταθερότητας. Όταν η κλιμάκωση έγινε κρίσιμη, συχνά έπρεπε να περιμένουμε αρκετά λεπτά για να εμφανιστούν νέες περιπτώσεις EC2. Η ιδέα να λανσάρουμε κοντέινερ και να ξεκινήσουμε την εξυπηρέτηση της κυκλοφορίας σε δευτερόλεπτα αντί για λεπτά έγινε πολύ ελκυστική για εμάς.
Η διαδικασία αποδείχθηκε δύσκολη. Κατά τη μετεγκατάστασή μας στις αρχές του 2019, το σύμπλεγμα Kubernetes έφτασε σε κρίσιμη μάζα και αρχίσαμε να αντιμετωπίζουμε διάφορα προβλήματα λόγω του όγκου επισκεψιμότητας, του μεγέθους του συμπλέγματος και του DNS. Στην πορεία, λύσαμε πολλά ενδιαφέροντα προβλήματα που σχετίζονται με τη μετεγκατάσταση 200 υπηρεσιών και τη διατήρηση ενός συμπλέγματος Kubernetes που αποτελείται από 1000 κόμβους, 15000 λοβούς και 48000 κοντέινερ.
Πώς;
Από τον Ιανουάριο του 2018, έχουμε περάσει από διάφορα στάδια μετανάστευσης. Ξεκινήσαμε με το κοντέινερ όλων των υπηρεσιών μας και την ανάπτυξή τους σε δοκιμαστικά περιβάλλοντα cloud της Kubernetes. Ξεκινώντας τον Οκτώβριο, αρχίσαμε να μεταφέρουμε μεθοδικά όλες τις υπάρχουσες υπηρεσίες στο Kubernetes. Μέχρι τον Μάρτιο του επόμενου έτους, ολοκληρώσαμε τη μετεγκατάσταση και τώρα η πλατφόρμα Tinder τρέχει αποκλειστικά στο Kubernetes.
Δημιουργία εικόνων για Kubernetes
Έχουμε πάνω από 30 αποθετήρια πηγαίου κώδικα για μικροϋπηρεσίες που εκτελούνται σε ένα σύμπλεγμα Kubernetes. Ο κώδικας σε αυτά τα αποθετήρια είναι γραμμένος σε διαφορετικές γλώσσες (για παράδειγμα, Node.js, Java, Scala, Go) με πολλαπλά περιβάλλοντα χρόνου εκτέλεσης για την ίδια γλώσσα.
Το σύστημα κατασκευής έχει σχεδιαστεί για να παρέχει ένα πλήρως προσαρμόσιμο «πλαίσιο κατασκευής» για κάθε microservice. Συνήθως αποτελείται από ένα Dockerfile και μια λίστα εντολών φλοιού. Το περιεχόμενό τους είναι πλήρως προσαρμόσιμο και ταυτόχρονα, όλα αυτά τα περιβάλλοντα κατασκευής είναι γραμμένα σύμφωνα με μια τυποποιημένη μορφή. Η τυποποίηση των πλαισίων κατασκευής επιτρέπει σε ένα ενιαίο σύστημα κατασκευής να χειρίζεται όλες τις μικροϋπηρεσίες.
Εικόνα 1-1. Τυποποιημένη διαδικασία κατασκευής μέσω κοντέινερ Builder
Για να επιτευχθεί η μέγιστη συνέπεια μεταξύ των χρόνων εκτέλεσης (περιβάλλοντα χρόνου εκτέλεσης) Η ίδια διαδικασία κατασκευής χρησιμοποιείται κατά την ανάπτυξη και τη δοκιμή. Αντιμετωπίσαμε μια πολύ ενδιαφέρουσα πρόκληση: έπρεπε να αναπτύξουμε έναν τρόπο για να διασφαλίσουμε τη συνοχή του περιβάλλοντος κατασκευής σε ολόκληρη την πλατφόρμα. Για να επιτευχθεί αυτό, όλες οι διαδικασίες συναρμολόγησης πραγματοποιούνται μέσα σε ένα ειδικό δοχείο. Οικοδόμος.
Η υλοποίηση του κοντέινερ απαιτούσε προηγμένες τεχνικές Docker. Το Builder κληρονομεί το τοπικό αναγνωριστικό χρήστη και τα μυστικά (όπως κλειδί SSH, διαπιστευτήρια AWS κ.λπ.) που απαιτούνται για την πρόσβαση στα ιδιωτικά αποθετήρια του Tinder. Προσαρτά τοπικούς καταλόγους που περιέχουν πηγές για την φυσική αποθήκευση τεχνουργημάτων κατασκευής. Αυτή η προσέγγιση βελτιώνει την απόδοση επειδή εξαλείφει την ανάγκη αντιγραφής τεχνουργημάτων κατασκευής μεταξύ του κοντέινερ του Builder και του κεντρικού υπολογιστή. Τα αποθηκευμένα τεχνουργήματα κατασκευής μπορούν να επαναχρησιμοποιηθούν χωρίς πρόσθετη διαμόρφωση.
Για ορισμένες υπηρεσίες, έπρεπε να δημιουργήσουμε ένα άλλο κοντέινερ για να αντιστοιχίσουμε το περιβάλλον μεταγλώττισης στο περιβάλλον χρόνου εκτέλεσης (για παράδειγμα, η βιβλιοθήκη bcrypt Node.js δημιουργεί δυαδικά τεχνουργήματα για συγκεκριμένη πλατφόρμα κατά την εγκατάσταση). Κατά τη διαδικασία μεταγλώττισης, οι απαιτήσεις μπορεί να διαφέρουν μεταξύ των υπηρεσιών και το τελικό Dockerfile μεταγλωττίζεται εν κινήσει.
Αρχιτεκτονική και μετανάστευση συμπλέγματος Kubernetes
Διαχείριση μεγέθους συμπλέγματος
Αποφασίσαμε να χρησιμοποιήσουμε kube-aws για αυτοματοποιημένη ανάπτυξη συμπλέγματος σε περιπτώσεις Amazon EC2. Στην αρχή, όλα λειτουργούσαν σε μια κοινή ομάδα κόμβων. Γρήγορα συνειδητοποιήσαμε την ανάγκη να διαχωρίσουμε τους φόρτους εργασίας ανά μέγεθος και τύπο εμφάνισης για να κάνουμε πιο αποτελεσματική χρήση των πόρων. Η λογική ήταν ότι η εκτέλεση πολλών φορτωμένων multi-threaded pods αποδείχθηκε πιο προβλέψιμη από άποψη απόδοσης από τη συνύπαρξή τους με μεγάλο αριθμό single-threaded pods.
Στο τέλος καταλήξαμε στο:
- m5.4x μεγάλο — για παρακολούθηση (Προμηθέας)·
- c5.4χρόνος - για φόρτο εργασίας Node.js (φόρτος εργασίας με ένα νήμα).
- c5.2χρόνος - για Java and Go (φόρτος εργασίας πολλαπλών νημάτων).
- c5.4χρόνος — για τον πίνακα ελέγχου (3 κόμβοι).
Η μετανάστευση
Ένα από τα προπαρασκευαστικά βήματα για τη μετάβαση από την παλιά υποδομή στο Kubernetes ήταν η ανακατεύθυνση της υπάρχουσας άμεσης επικοινωνίας μεταξύ των υπηρεσιών στους νέους εξισορροπητές φορτίου (Elastic Load Balancer (ELB). Δημιουργήθηκαν σε ένα συγκεκριμένο υποδίκτυο ενός εικονικού ιδιωτικού νέφους (VPC). Αυτό το υποδίκτυο συνδέθηκε με ένα Kubernetes VPC. Αυτό μας επέτρεψε να μετεγκαταστήσουμε τις μονάδες σταδιακά, χωρίς να λάβουμε υπόψη τη συγκεκριμένη σειρά εξαρτήσεων υπηρεσιών.
Αυτά τα τελικά σημεία δημιουργήθηκαν χρησιμοποιώντας σταθμισμένα σύνολα εγγραφών DNS που είχαν CNAME που δείχνουν σε κάθε νέο ELB. Για εναλλαγή, προσθέσαμε μια νέα καταχώρηση που δείχνει στο νέο ELB της υπηρεσίας Kubernetes με βάρος 0. Στη συνέχεια ορίσαμε το Time To Live (TTL) του συνόλου καταχώρισης σε 0. Μετά από αυτό, τα παλιά και τα νέα βάρη ήταν προσαρμόστηκε αργά και τελικά το 100% του φορτίου στάλθηκε σε έναν νέο διακομιστή. Μετά την ολοκλήρωση της εναλλαγής, η τιμή TTL επέστρεψε σε ένα πιο κατάλληλο επίπεδο.
Οι λειτουργικές μονάδες Java που είχαμε θα μπορούσαν να αντιμετωπίσουν χαμηλό TTL DNS, αλλά οι εφαρμογές Node δεν μπορούσαν. Ένας από τους μηχανικούς ξαναέγραψε μέρος του κωδικού της πισίνας σύνδεσης και το τύλιξε σε έναν διαχειριστή που ενημέρωνε τις πισίνες κάθε 60 δευτερόλεπτα. Η επιλεγμένη προσέγγιση λειτούργησε πολύ καλά και χωρίς καμία αξιοσημείωτη υποβάθμιση της απόδοσης.
Τα μαθήματα
Τα όρια του υφάσματος δικτύου
Τα ξημερώματα της 8ης Ιανουαρίου 2019, η πλατφόρμα Tinder συνετρίβη απροσδόκητα. Ως απόκριση σε μια άσχετη αύξηση στον λανθάνοντα χρόνο της πλατφόρμας νωρίτερα εκείνο το πρωί, ο αριθμός των λοβών και των κόμβων στο σύμπλεγμα αυξήθηκε. Αυτό προκάλεσε την εξάντληση της προσωρινής μνήμης ARP σε όλους τους κόμβους μας.
Υπάρχουν τρεις επιλογές Linux που σχετίζονται με την προσωρινή μνήμη ARP:
()
gc_thresh3 - αυτό είναι ένα δύσκολο όριο. Η εμφάνιση καταχωρήσεων «υπερχείλισης πίνακα γειτονικών» στο αρχείο καταγραφής σήμαινε ότι ακόμη και μετά τη σύγχρονη συλλογή απορριμμάτων (GC), δεν υπήρχε αρκετός χώρος στη μνήμη cache ARP για την αποθήκευση της γειτονικής καταχώρισης. Σε αυτήν την περίπτωση, ο πυρήνας απλώς απέρριψε το πακέτο εντελώς.
Χρησιμοποιούμε ως πλέγμα δικτύου στο Kubernetes. Τα πακέτα μεταδίδονται μέσω VXLAN. Το VXLAN είναι μια σήραγγα L2 που υψώνεται πάνω από ένα δίκτυο L3. Η τεχνολογία χρησιμοποιεί ενθυλάκωση MAC-in-UDP (MAC Address-in-User Datagram Protocol) και επιτρέπει την επέκταση των τμημάτων δικτύου Layer 2. Το πρωτόκολλο μεταφοράς στο φυσικό δίκτυο του κέντρου δεδομένων είναι IP συν UDP.
Εικόνα 2–1. διάγραμμα φανέλας ()
Εικόνα 2-2. πακέτο VXLAN ()
Κάθε κόμβος εργασίας Kubernetes εκχωρεί έναν εικονικό χώρο διευθύνσεων με μια μάσκα /24 από ένα μεγαλύτερο μπλοκ /9. Για κάθε κόμβο αυτό είναι μία καταχώρηση στον πίνακα δρομολόγησης, μία καταχώρηση στον πίνακα ARP (στη διεπαφή flannel.1) και μία καταχώρηση στον πίνακα μεταγωγής (FDB). Προστίθενται την πρώτη φορά που ξεκινά ένας κόμβος εργαζόμενος ή κάθε φορά που ανακαλύπτεται ένας νέος κόμβος.
Επιπλέον, η επικοινωνία node-pod (ή pod-pod) περνάει τελικά μέσω της διεπαφής eth0 (όπως φαίνεται στο διάγραμμα Flannel παραπάνω). Αυτό έχει ως αποτέλεσμα μια πρόσθετη καταχώρηση στον πίνακα ARP για κάθε αντίστοιχο κεντρικό υπολογιστή προέλευσης και προορισμού.
Στο περιβάλλον μας, αυτό το είδος επικοινωνίας είναι πολύ συνηθισμένο. Για αντικείμενα υπηρεσίας στο Kubernetes, δημιουργείται ένα ELB και το Kubernetes καταχωρεί κάθε κόμβο στο ELB. Το ELB δεν γνωρίζει τίποτα για τα pods και ο επιλεγμένος κόμβος μπορεί να μην είναι ο τελικός προορισμός του πακέτου. Το θέμα είναι ότι όταν ένας κόμβος λαμβάνει ένα πακέτο από το ELB, το θεωρεί λαμβάνοντας υπόψη τους κανόνες iptables για μια συγκεκριμένη υπηρεσία και επιλέγει τυχαία μια ομάδα σε έναν άλλο κόμβο.
Τη στιγμή της αποτυχίας, υπήρχαν 605 κόμβοι στο σύμπλεγμα. Για τους λόγους που αναφέρθηκαν παραπάνω, αυτό ήταν αρκετό για να ξεπεραστεί η σημασία gc_thresh3, που είναι η προεπιλογή. Όταν συμβεί αυτό, όχι μόνο τα πακέτα αρχίζουν να απορρίπτονται, αλλά ολόκληρος ο εικονικός χώρος διευθύνσεων Flannel με μια μάσκα /24 εξαφανίζεται από τον πίνακα ARP. Η επικοινωνία Node-pod και τα ερωτήματα DNS διακόπτονται (το DNS φιλοξενείται σε ένα σύμπλεγμα, διαβάστε αργότερα σε αυτό το άρθρο για λεπτομέρειες).
Για να λύσετε αυτό το πρόβλημα, πρέπει να αυξήσετε τις τιμές gc_thresh1, gc_thresh2 и gc_thresh3 και επανεκκινήστε το Flannel για να καταχωρήσετε ξανά τα δίκτυα που λείπουν.
Απροσδόκητη κλιμάκωση DNS
Κατά τη διαδικασία μετεγκατάστασης, χρησιμοποιήσαμε ενεργά το DNS για τη διαχείριση της κυκλοφορίας και τη σταδιακή μεταφορά υπηρεσιών από την παλιά υποδομή στο Kubernetes. Ορίσαμε σχετικά χαμηλές τιμές TTL για τα σχετικά RecordSets στο Route53. Όταν η παλιά υποδομή εκτελούσε σε στιγμιότυπα EC2, η διαμόρφωση του αναλυτή μας έδειχνε το Amazon DNS. Το θεωρήσαμε δεδομένο και ο αντίκτυπος του χαμηλού TTL στις υπηρεσίες μας και τις υπηρεσίες της Amazon (όπως το DynamoDB) πέρασε σε μεγάλο βαθμό απαρατήρητος.
Καθώς μεταφέραμε υπηρεσίες στο Kubernetes, διαπιστώσαμε ότι το DNS επεξεργαζόταν 250 χιλιάδες αιτήματα ανά δευτερόλεπτο. Ως αποτέλεσμα, οι εφαρμογές άρχισαν να αντιμετωπίζουν σταθερά και σοβαρά χρονικά όρια για ερωτήματα DNS. Αυτό συνέβη παρά τις απίστευτες προσπάθειες για βελτιστοποίηση και αλλαγή του παρόχου DNS σε CoreDNS (ο οποίος στο μέγιστο φορτίο έφτασε τα 1000 pod που εκτελούνται σε 120 πυρήνες).
Ενώ ερευνούσαμε άλλες πιθανές αιτίες και λύσεις, ανακαλύψαμε , περιγράφοντας τις συνθήκες αγώνα που επηρεάζουν το πλαίσιο φιλτραρίσματος πακέτων netfilter στο Linux. Τα τάιμ άουτ που παρατηρήσαμε, σε συνδυασμό με ένα αυξανόμενο κοντέρ insert_failed στη διεπαφή Flannel ήταν συνεπείς με τα ευρήματα του άρθρου.
Το πρόβλημα παρουσιάζεται στο στάδιο της μετάφρασης διεύθυνσης δικτύου πηγής και προορισμού (SNAT και DNAT) και επακόλουθη εισαγωγή στον πίνακα contrack. Ένας από τους τρόπους λύσης που συζητήθηκε εσωτερικά και προτάθηκε από την κοινότητα ήταν να μετακινηθεί το DNS στον ίδιο τον κόμβο εργαζόμενου. Σε αυτήν την περίπτωση:
- Το SNAT δεν χρειάζεται γιατί η κίνηση παραμένει μέσα στον κόμβο. Δεν χρειάζεται να δρομολογηθεί μέσω της διεπαφής eth0.
- Το DNAT δεν χρειάζεται αφού η IP προορισμού είναι τοπική στον κόμβο και όχι μια τυχαία επιλεγμένη ομάδα σύμφωνα με τους κανόνες iptables.
Αποφασίσαμε να μείνουμε σε αυτήν την προσέγγιση. Το CoreDNS αναπτύχθηκε ως DaemonSet στο Kubernetes και εφαρμόσαμε έναν τοπικό διακομιστή DNS κόμβου στο resolution.conf κάθε pod ορίζοντας μια σημαία --cluster-dns εντολές kubelet . Αυτή η λύση αποδείχθηκε αποτελεσματική για χρονικά όρια DNS.
Ωστόσο, είδαμε ακόμα απώλεια πακέτων και αύξηση στον μετρητή insert_failed στη διεπαφή Flannel. Αυτό συνεχίστηκε μετά την εφαρμογή της λύσης επειδή καταφέραμε να εξαλείψουμε το SNAT ή/και το DNAT μόνο για την κυκλοφορία DNS. Οι συνθήκες αγώνων διατηρήθηκαν για άλλους τύπους κυκλοφορίας. Ευτυχώς, τα περισσότερα από τα πακέτα μας είναι TCP και αν παρουσιαστεί κάποιο πρόβλημα απλώς αναμεταδίδονται. Εξακολουθούμε να προσπαθούμε να βρούμε μια κατάλληλη λύση για όλους τους τύπους κίνησης.
Χρήση Envoy για καλύτερη εξισορρόπηση φορτίου
Καθώς μεταφέραμε τις υπηρεσίες υποστήριξης στο Kubernetes, αρχίσαμε να υποφέρουμε από μη ισορροπημένο φορτίο μεταξύ των pods. Διαπιστώσαμε ότι το HTTP Keepalive έκανε τις συνδέσεις ELB να κρέμονται στα πρώτα έτοιμα pods κάθε ανάπτυξης που κυκλοφόρησε. Έτσι, το μεγαλύτερο μέρος της κίνησης περνούσε από ένα μικρό ποσοστό διαθέσιμων pod. Η πρώτη λύση που δοκιμάσαμε ήταν να ρυθμίσουμε το MaxSurge στο 100% σε νέες αναπτύξεις για τα χειρότερα σενάρια. Το αποτέλεσμα αποδείχθηκε ασήμαντο και απρόβλεπτο όσον αφορά τις μεγαλύτερες αναπτύξεις.
Μια άλλη λύση που χρησιμοποιήσαμε ήταν να αυξήσουμε τεχνητά τα αιτήματα πόρων για κρίσιμες υπηρεσίες. Σε αυτήν την περίπτωση, οι λοβοί που τοποθετούνται κοντά θα έχουν περισσότερο χώρο για ελιγμούς σε σύγκριση με άλλες βαριές λοβούς. Ούτε μακροπρόθεσμα θα λειτουργούσε γιατί θα ήταν σπατάλη πόρων. Επιπλέον, οι εφαρμογές Node μας ήταν μονού νήματος και, κατά συνέπεια, μπορούσαν να χρησιμοποιήσουν μόνο έναν πυρήνα. Η μόνη πραγματική λύση ήταν η χρήση καλύτερης εξισορρόπησης φορτίου.
Θέλαμε από καιρό να εκτιμήσουμε πλήρως . Η τρέχουσα κατάσταση μας επέτρεψε να το αναπτύξουμε με πολύ περιορισμένο τρόπο και να έχουμε άμεσα αποτελέσματα. Το Envoy είναι ένας διακομιστής μεσολάβησης επιπέδου XNUMX, ανοιχτού κώδικα, υψηλής απόδοσης, σχεδιασμένος για μεγάλες εφαρμογές SOA. Μπορεί να εφαρμόσει προηγμένες τεχνικές εξισορρόπησης φορτίου, συμπεριλαμβανομένων αυτόματων επαναλήψεων, διακοπτών κυκλώματος και καθολικού περιορισμού ρυθμού. (Σημείωση. μετάφρ.: Μπορείτε να διαβάσετε περισσότερα για αυτό στο για το Ιστιο, το οποίο βασίζεται στον Απεσταλμένο.)
Καταλήξαμε στην ακόλουθη διαμόρφωση: να έχετε ένα πλευρικό καρφί Envoy για κάθε pod και μια μεμονωμένη διαδρομή και συνδέστε το σύμπλεγμα στο κοντέινερ τοπικά μέσω θύρας. Για να ελαχιστοποιήσουμε την πιθανή καταρράκτη και να διατηρήσουμε μια μικρή ακτίνα επιτυχίας, χρησιμοποιήσαμε έναν στόλο εμπρός διακομιστή μεσολάβησης Envoy, ένα ανά Ζώνη Διαθεσιμότητας (AZ) για κάθε υπηρεσία. Βασίστηκαν σε μια απλή μηχανή ανακάλυψης υπηρεσιών γραμμένη από έναν από τους μηχανικούς μας που απλώς επέστρεφε μια λίστα με λοβούς σε κάθε AZ για μια δεδομένη υπηρεσία.
Το Service front-Envoys χρησιμοποίησε στη συνέχεια αυτόν τον μηχανισμό ανακάλυψης υπηρεσίας με ένα σύμπλεγμα και μια διαδρομή ανάντη. Ορίσαμε επαρκή χρονικά όρια, αυξήσαμε όλες τις ρυθμίσεις του διακόπτη κυκλώματος και προσθέσαμε ελάχιστη διαμόρφωση επανάληψης για να βοηθήσουμε με μεμονωμένες βλάβες και να εξασφαλίσουμε ομαλή ανάπτυξη. Τοποθετήσαμε ένα TCP ELB μπροστά από κάθε ένα από αυτά τα front-Envoys υπηρεσίας. Ακόμα κι αν το keepalive από το κύριο επίπεδο του διακομιστή μεσολάβησης είχε κολλήσει σε ορισμένα pods του Envoy, ήταν ακόμα σε θέση να χειριστούν το φορτίο πολύ καλύτερα και είχαν ρυθμιστεί να ισορροπούν μέσω του minimum_request στο backend.
Για την ανάπτυξη, χρησιμοποιήσαμε το άγκιστρο preStop τόσο σε υποδοχές εφαρμογών όσο και σε υποδοχές πλαϊνών καρτών. Το άγκιστρο ενεργοποίησε ένα σφάλμα κατά τον έλεγχο της κατάστασης του τερματικού σημείου διαχειριστή που βρίσκεται στο κοντέινερ του πλαϊνού καρέ και τέθηκε σε αδράνεια για λίγο, ώστε να επιτραπεί ο τερματισμός των ενεργών συνδέσεων.
Ένας από τους λόγους που μπορέσαμε να προχωρήσουμε τόσο γρήγορα οφείλεται στις λεπτομερείς μετρήσεις που μπορέσαμε να ενσωματώσουμε εύκολα σε μια τυπική εγκατάσταση του Prometheus. Αυτό μας επέτρεψε να δούμε ακριβώς τι συνέβαινε ενώ προσαρμόσαμε τις παραμέτρους διαμόρφωσης και ανακατανείμαμε την κυκλοφορία.
Τα αποτελέσματα ήταν άμεσα και εμφανή. Ξεκινήσαμε με τις πιο ανισόρροπες υπηρεσίες και αυτή τη στιγμή λειτουργεί μπροστά στις 12 πιο σημαντικές υπηρεσίες του cluster. Φέτος σχεδιάζουμε μια μετάβαση σε ένα πλήρες πλέγμα υπηρεσιών με πιο προηγμένη ανακάλυψη υπηρεσιών, διακοπή κυκλώματος, ανίχνευση ακραίων τιμών, περιορισμό ρυθμού και ανίχνευση.
Εικόνα 3–1. Σύγκλιση CPU μιας υπηρεσίας κατά τη μετάβαση στο Envoy
Τέλος αποτέλεσμα
Μέσω αυτής της εμπειρίας και της πρόσθετης έρευνας, έχουμε δημιουργήσει μια ισχυρή ομάδα υποδομής με ισχυρές δεξιότητες στο σχεδιασμό, την ανάπτυξη και τη λειτουργία μεγάλων συμπλεγμάτων Kubernetes. Όλοι οι μηχανικοί του Tinder έχουν πλέον τη γνώση και την εμπειρία να συσκευάζουν κοντέινερ και να αναπτύσσουν εφαρμογές στο Kubernetes.
Όταν προέκυψε η ανάγκη για πρόσθετη χωρητικότητα στην παλιά υποδομή, έπρεπε να περιμένουμε αρκετά λεπτά για να ξεκινήσουν οι νέες περιπτώσεις EC2. Τώρα τα κοντέινερ αρχίζουν να τρέχουν και αρχίζουν να επεξεργάζονται την κυκλοφορία μέσα σε δευτερόλεπτα αντί για λεπτά. Ο προγραμματισμός πολλαπλών δοχείων σε μία μόνο περίπτωση EC2 παρέχει επίσης βελτιωμένη οριζόντια συγκέντρωση. Ως αποτέλεσμα, προβλέπουμε σημαντική μείωση του κόστους EC2019 το 2 σε σύγκριση με πέρυσι.
Η μετανάστευση κράτησε σχεδόν δύο χρόνια, αλλά την ολοκληρώσαμε τον Μάρτιο του 2019. Επί του παρόντος, η πλατφόρμα Tinder λειτουργεί αποκλειστικά σε ένα σύμπλεγμα Kubernetes που αποτελείται από 200 υπηρεσίες, 1000 κόμβους, 15 pods και 000 κοντέινερ. Η υποδομή δεν είναι πλέον ο αποκλειστικός τομέας των επιχειρησιακών ομάδων. Όλοι οι μηχανικοί μας μοιράζονται αυτήν την ευθύνη και ελέγχουν τη διαδικασία κατασκευής και ανάπτυξης των εφαρμογών τους χρησιμοποιώντας μόνο κώδικα.
ΥΓ από τον μεταφραστή
Διαβάστε επίσης μια σειρά άρθρων στο blog μας:
- «».
- «».
- «».
- «».
- «».
- «».
- «».
- «».
- «».
- «».
Πηγή: www.habr.com