Η μετακίνηση του Τίντερ στο Κουμπέρνετς

Σενάριο: Chris O'Brien, Διευθυντής Μηχανικών | Chris Thomas, Διευθυντής Μηχανικών | Jinyong Lee, Ανώτερος Μηχανικός Λογισμικού | Επιμέλεια: Cooper Jackson, Μηχανικός Λογισμικού

Γιατί

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

Προσπαθούσαμε επίσης να αντιμετωπίσουμε προκλήσεις κλίμακας και σταθερότητας. Όταν η κλιμάκωση έγινε κρίσιμη, συχνά υποφέραμε μέσα σε αρκετά λεπτά αναμονής για νέες παρουσίες EC2 για σύνδεση στο διαδίκτυο. Η ιδέα για τον προγραμματισμό και την εξυπηρέτηση κοντέινερ εντός δευτερολέπτων σε αντίθεση με τα λεπτά ήταν ελκυστική για εμάς.

Δεν ήταν εύκολο. Κατά τη μετανάστευσή μας στις αρχές του 2019, φτάσαμε σε κρίσιμη μάζα στο σύμπλεγμα Kubernetes και ξεκινήσαμε να αντιμετωπίζουμε διάφορες προκλήσεις λόγω του όγκου της κυκλοφορίας, του μεγέθους του συμπλέγματος και του DNS. Λύσαμε ενδιαφέρουσες προκλήσεις για τη μετεγκατάσταση 200 υπηρεσιών και την εκτέλεση ενός συμπλέγματος Kubernetes σε κλίμακα συνολικής αξίας 1.000 κόμβων, 15.000 λοβών και 48.000 κοντέινερ που εκτελούνται.

Πως

Από τον Ιανουάριο του 2018, δουλέψαμε στα διάφορα στάδια της μετανάστευσης. Ξεκινήσαμε κάνοντας εμπορευματοκιβώτιο όλων των υπηρεσιών μας και αναπτύσσοντάς τα σε μια σειρά από περιβάλλοντα σταδιοδρομίας που φιλοξενούνται από το Kubernetes. Από τον Οκτώβριο, ξεκινήσαμε μεθοδικά να μεταφέρουμε όλες τις κληρονομικές υπηρεσίες μας στο Kubernetes. Μέχρι τον Μάρτιο του επόμενου έτους, ολοκληρώσαμε τη μετανάστευσή μας και η πλατφόρμα Tinder τρέχει τώρα αποκλειστικά στο Kubernetes.

Δημιουργία εικόνων για Kubernetes

Υπάρχουν περισσότερα από 30 αποθετήρια πηγαίου κώδικα για τις μικροϋπηρεσίες που εκτελούνται στο σύμπλεγμα Kubernetes. Ο κώδικας σε αυτά τα αποθετήρια είναι γραμμένος σε διαφορετικές γλώσσες (π.χ. Node.js, Java, Scala, Go) με πολλαπλά περιβάλλοντα χρόνου εκτέλεσης για την ίδια γλώσσα.

Το σύστημα κατασκευής έχει σχεδιαστεί για να λειτουργεί σε ένα πλήρως προσαρμόσιμο «περιβάλλον δημιουργίας» για κάθε μικροϋπηρεσία, η οποία συνήθως αποτελείται από ένα Dockerfile και μια σειρά εντολών κελύφους. Ενώ τα περιεχόμενά τους είναι πλήρως προσαρμόσιμα, αυτά τα περιβάλλοντα δημιουργίας είναι όλα γραμμένα ακολουθώντας μια τυποποιημένη μορφή. Η τυποποίηση των οικοδομικών πλαισίων επιτρέπει σε ένα σύστημα build να χειρίζεται όλες τις μικρο-υπηρεσίες.

Σχήμα 1-1 Τυποποιημένη διαδικασία κατασκευής μέσω του κοντέινερ Builder

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

Η υλοποίηση του κοντέινερ Builder απαιτούσε μια σειρά προηγμένων τεχνικών Docker. Αυτό το κοντέινερ Builder κληρονομεί τοπικό αναγνωριστικό χρήστη και μυστικά (π.χ. κλειδί SSH, διαπιστευτήρια AWS κ.λπ.), όπως απαιτείται για πρόσβαση σε ιδιωτικά αποθετήρια Tinder. Συναρμολογεί τοπικούς καταλόγους που περιέχουν τον πηγαίο κώδικα για να έχει έναν φυσικό τρόπο αποθήκευσης αντικειμένων κατασκευής. Αυτή η προσέγγιση βελτιώνει την απόδοση, επειδή εξαλείφει την αντιγραφή ενσωματωμένων αντικειμένων μεταξύ του κοντέινερ Builder και του κεντρικού υπολογιστή. Τα αποθηκευμένα χειροποίητα αντικείμενα επαναχρησιμοποιούνται την επόμενη φορά χωρίς περαιτέρω διαμόρφωση.

Για ορισμένες υπηρεσίες, χρειαζόμασταν να δημιουργήσουμε ένα άλλο κοντέινερ μέσα στο Builder για να ταιριάξουμε το περιβάλλον μεταγλώττισης-χρόνου με το περιβάλλον χρόνου εκτέλεσης (π.χ., η εγκατάσταση της βιβλιοθήκης Node.js bcrypt δημιουργεί δυαδικά αντικείμενα για πλατφόρμα). Οι απαιτήσεις χρόνου μεταγλώττισης ενδέχεται να διαφέρουν μεταξύ των υπηρεσιών και το τελικό Dockerfile συντάσσεται εν κινήσει.

Kubernetes Cluster Architecture And Migration

Μέγεθος συμπλέγματος

Αποφασίσαμε να χρησιμοποιήσουμε το kube-aws για αυτόματη παροχή συμπλέγματος σε παρουσίες Amazon EC2. Νωρίς, τρέξαμε τα πάντα σε μια ομάδα γενικών κόμβων. Αναγνωρίσαμε γρήγορα την ανάγκη διαχωρισμού του φόρτου εργασίας σε διαφορετικά μεγέθη και τύπους παρουσιών, για καλύτερη χρήση των πόρων. Ο λόγος ήταν ότι η εκτέλεση λιγότερων λοβών με πολύ σπείρωμα απέδωσε μαζί μας πιο προβλέψιμα αποτελέσματα απόδοσης από το να τους αφήσουμε να συνυπάρχουν με έναν μεγαλύτερο αριθμό λοβών με ένα νήμα.

Εγκαταστάσαμε στις:

  • m5.4xlarge για παρακολούθηση (Prometheus)
  • c5.4xlarge για φόρτο εργασίας Node.js (μονόστροφο φορτίο εργασίας)
  • c5.2xlarge για Java και Go (φόρτος εργασίας πολλαπλών νημάτων)
  • c5.4xlarge για το επίπεδο ελέγχου (3 κόμβοι)

Μετανάστευση

Ένα από τα βήματα προετοιμασίας για τη μετεγκατάσταση από την παλαιά υποδομή μας στο Kubernetes ήταν να αλλάξουμε την υπάρχουσα επικοινωνία μεταξύ υπηρεσιών για να δείξουμε σε νέους Elastic Load Balancers (ELBs) που δημιουργήθηκαν σε ένα συγκεκριμένο υποδίκτυο Virtual Private Cloud (VPC). Αυτό το υποδίκτυο ήταν ομαδοποιημένο στο Kubernetes VPC. Αυτό μας επέτρεψε να μεταναστεύσουμε λεπτομερώς τις ενότητες χωρίς να λαμβάνουμε υπόψη συγκεκριμένες παραγγελίες για εξαρτήσεις υπηρεσιών.

Αυτά τα τελικά σημεία δημιουργήθηκαν χρησιμοποιώντας σταθμισμένα σύνολα εγγραφών DNS που είχαν ένα CNAME που δείχνει κάθε νέο ELB. Για το cutover, προσθέσαμε μια νέα εγγραφή, δείχνοντας τη νέα υπηρεσία Kubernetes ELB, με βάρος 0. Στη συνέχεια, ορίσαμε το Time To Live (TTL) στο ρεκόρ σε 0. Το παλιό και το νέο βάρη προσαρμόστηκαν αργά σε τελικά καταλήγει με 100% στο νέο διακομιστή. Μετά την ολοκλήρωση του cutover, το TTL τέθηκε σε κάτι πιο λογικό.

Οι λειτουργικές μονάδες Java μας τιμούσαν το χαμηλό DNS TTL, αλλά οι εφαρμογές Node δεν το έκαναν. Ένας από τους μηχανικούς μας ξαναγράφει μέρος του κωδικού συγκέντρωσης σύνδεσης για να τον τυλίξει σε έναν διαχειριστή που θα ανανεώνει τα pools κάθε 60s. Αυτό λειτούργησε πολύ καλά για εμάς χωρίς αξιόλογη επιτυχία.

Εκμάθηση

Όρια υφάσματος δικτύου

Στις πρώτες πρωινές ώρες της 8ης Ιανουαρίου 2019, η πλατφόρμα του Tinder υπέστη επίμονη διακοπή λειτουργίας. Σε απάντηση σε μια άσχετη αύξηση του λανθάνοντος χρόνου πλατφόρμας νωρίτερα εκείνο το πρωί, οι μετρήσεις pod και κόμβων κλιμακώθηκαν στο σύμπλεγμα. Αυτό είχε ως αποτέλεσμα την εξάντληση της προσωρινής μνήμης ARP σε όλους τους κόμβους μας.

Υπάρχουν τρεις τιμές Linux που σχετίζονται με την προσωρινή μνήμη ARP:

Πίστωση

Το gc_thresh3 είναι ένα σκληρό καπάκι. Εάν λαμβάνετε καταχωρίσεις καταγραφής "υπερχείλιση πίνακα γειτόνων", αυτό υποδηλώνει ότι ακόμη και μετά από μια σύγχρονη συλλογή απορριμμάτων (GC) της προσωρινής μνήμης ARP, δεν υπήρχε αρκετός χώρος για την αποθήκευση της καταχώρησης γειτονικού. Σε αυτήν την περίπτωση, ο πυρήνας απλώς πέφτει πλήρως το πακέτο.

Χρησιμοποιούμε το Flannel ως δίκτυό μας στο Kubernetes. Τα πακέτα προωθούνται μέσω VXLAN. Το VXLAN είναι ένα σχήμα επικάλυψης Layer 2 μέσω δικτύου Layer 3. Χρησιμοποιεί ενθυλάκωση MAC Address-in-User Datagram Protocol (MAC-in-UDP) για να παρέχει ένα μέσο επέκτασης τμημάτων δικτύου Layer 2. Το πρωτόκολλο μεταφοράς μέσω του δικτύου φυσικών κέντρων δεδομένων είναι IP συν UDP.

Σχήμα 2-1 Διάγραμμα Flanel (πίστωση)

Σχήμα 2–2 Πακέτο VXLAN (πίστωση)

Κάθε κόμβος εργαζόμενου Kubernetes εκχωρεί το δικό του / 24 εικονικού χώρου διευθύνσεων από ένα μεγαλύτερο / 9 μπλοκ. Για κάθε κόμβο, αυτό έχει ως αποτέλεσμα 1 καταχώρηση πίνακα διαδρομής, 1 καταχώριση πίνακα ARP (στη διεπαφή flannel.1) και 1 καταχώρηση βάσης δεδομένων προώθησης (FDB). Αυτά προστίθενται κατά την πρώτη εκκίνηση του κόμβου εργαζομένου ή καθώς ανακαλύπτεται κάθε νέος κόμβος.

Επιπλέον, η επικοινωνία node-to-pod (ή pod-to-pod) ρέει τελικά μέσω της διεπαφής eth0 (απεικονίζεται στο διάγραμμα Flannel παραπάνω). Αυτό θα έχει ως αποτέλεσμα μια επιπλέον καταχώριση στον πίνακα ARP για κάθε αντίστοιχη πηγή κόμβου και προορισμό κόμβου.

Στο περιβάλλον μας, αυτός ο τύπος επικοινωνίας είναι πολύ συνηθισμένος. Για τα αντικείμενα υπηρεσίας Kubernetes, δημιουργείται ένα ELB και το Kubernetes καταγράφει κάθε κόμβο στο ELB. Το ELB δεν γνωρίζει pod και ο επιλεγμένος κόμβος ενδέχεται να μην είναι ο τελικός προορισμός του πακέτου. Αυτό συμβαίνει επειδή όταν ο κόμβος λαμβάνει το πακέτο από το ELB, αξιολογεί τους κανόνες του iptables για την υπηρεσία και επιλέγει τυχαία ένα pod σε έναν άλλο κόμβο.

Κατά τη στιγμή της διακοπής λειτουργίας, υπήρχαν 605 συνολικοί κόμβοι στο σύμπλεγμα. Για τους λόγους που περιγράφονται παραπάνω, αυτό ήταν αρκετό για να εκλείψει την προεπιλεγμένη τιμή gc_thresh3. Μόλις συμβεί αυτό, δεν πέφτουν μόνο πακέτα, αλλά ολόκληρο το Flanel / 24s του εικονικού χώρου διευθύνσεων λείπουν από τον πίνακα ARP. Η επικοινωνία κόμβου προς pod και οι αναζητήσεις DNS απέτυχαν. (Το DNS φιλοξενείται εντός του συμπλέγματος, όπως θα εξηγηθεί λεπτομερέστερα αργότερα σε αυτό το άρθρο.)

Για την επίλυση, αυξάνονται οι τιμές gc_thresh1, gc_thresh2 και gc_thresh3 και πρέπει να γίνει επανεκκίνηση του Flannel για να εγγράψετε ξανά δίκτυα που λείπουν.

Μη αναμενόμενη εκτέλεση DNS σε κλίμακα

Για να διευθετήσουμε τη μετανάστευσή μας, αξιοποιήσαμε το DNS σε μεγάλο βαθμό για να διευκολύνουμε τη διαμόρφωση της κίνησης και τη σταδιακή περικοπή από το παλαιό στο Kubernetes για τις υπηρεσίες μας. Ορίζουμε σχετικά χαμηλές τιμές TTL στα αντίστοιχα Route53 RecordSets. Όταν τρέξαμε την παλιά μας υποδομή σε παρουσίες EC2, η διαμόρφωση του προγράμματος επίλυσης επεσήμανε το DNS του Amazon. Το θεωρήσαμε δεδομένο και το κόστος ενός σχετικά χαμηλού TTL για τις υπηρεσίες μας και οι υπηρεσίες της Amazon (π.χ. DynamoDB) πήγαν σε μεγάλο βαθμό απαρατήρητες.

Καθώς επιβιβαζόμασταν όλο και περισσότερες υπηρεσίες στο Kubernetes, βρεθήκαμε να εκτελούμε μια υπηρεσία DNS που απαντούσε σε 250.000 αιτήματα ανά δευτερόλεπτο. Αντιμετωπίζαμε διαλείπουσες και σημαντικές χρονικές προθεσμίες αναζήτησης DNS στις εφαρμογές μας. Αυτό συνέβη παρά την εξαντλητική προσπάθεια συντονισμού και τον πάροχο DNS να μεταβεί σε ανάπτυξη CoreDNS που κάποτε έφτασε στα 1.000 λοβό καταναλώνοντας 120 πυρήνες.

Ερευνώντας άλλες πιθανές αιτίες και λύσεις, βρήκαμε ένα άρθρο που περιγράφει μια κατάσταση αγώνα που επηρεάζει το netfilter του πλαισίου φιλτραρίσματος πακέτων Linux. Τα χρονικά όρια λήξης DNS που είδαμε, μαζί με έναν αυξημένο μετρητή insert_failed στη διεπαφή Flannel, ευθυγραμμίστηκαν με τα ευρήματα του άρθρου.

Το ζήτημα παρουσιάζεται κατά τη Μετάφραση Διεύθυνσης Δικτύου Πηγή και Προορισμού (SNAT και DNAT) και την επακόλουθη εισαγωγή στον πίνακα σύνδεσης. Μια λύση που συζητήθηκε εσωτερικά και προτάθηκε από την κοινότητα ήταν να μετακινήσετε το DNS στον ίδιο τον κόμβο εργαζομένων. Σε αυτήν την περίπτωση:

  • Το SNAT δεν είναι απαραίτητο, επειδή η κίνηση παραμένει τοπικά στον κόμβο. Δεν χρειάζεται να μεταδοθεί μέσω της διεπαφής eth0.
  • Το DNAT δεν είναι απαραίτητο επειδή η διεύθυνση IP προορισμού είναι τοπική στον κόμβο και όχι τυχαία επιλεγμένη ομάδα δεδομένων ανά κανόνες.

Αποφασίσαμε να προχωρήσουμε με αυτήν την προσέγγιση. Το CoreDNS αναπτύχθηκε ως DaemonSet στο Kubernetes και εγχύσαμε τον τοπικό διακομιστή DNS του κόμβου στο resolv.conf κάθε pod, ρυθμίζοντας τη σημαία εντολών kubelet - cluster-dns. Η λύση ήταν αποτελεσματική για χρονικά όρια DNS.

Ωστόσο, εξακολουθούμε να βλέπουμε πατημένα πακέτα και το ένθετο της προσθήκης του Flannel. Αυτό θα συνεχιστεί ακόμη και μετά την παραπάνω λύση, επειδή αποφύγαμε μόνο το SNAT ή / και το DNAT για την κίνηση DNS. Η κατάσταση του αγώνα θα εξακολουθεί να ισχύει για άλλους τύπους κυκλοφορίας. Ευτυχώς, τα περισσότερα πακέτα μας είναι TCP και όταν προκύψει η κατάσταση, τα πακέτα θα μεταδοθούν επιτυχώς. Μια μακροπρόθεσμη επιδιόρθωση για όλους τους τύπους επισκεψιμότητας είναι κάτι που συζητούμε ακόμη.

Χρησιμοποιώντας τον απεσταλμένο για την επίτευξη καλύτερης εξισορρόπησης φορτίου

Καθώς μετεγκαταστήσαμε τις υπηρεσίες υποστήριξης στο Kubernetes, αρχίσαμε να υποφέρουμε από μη ισορροπημένο φορτίο σε όλες τις ομάδες. Ανακαλύψαμε ότι λόγω του HTTP Keepalive, οι συνδέσεις ELB κολλήθηκαν στα πρώτα έτοιμα λοβό κάθε κυλιόμενης ανάπτυξης, οπότε η περισσότερη επισκεψιμότητα διέρρευσε ένα μικρό ποσοστό των διαθέσιμων ομάδων. Ένας από τους πρώτους μετριασμούς που δοκιμάσαμε ήταν να χρησιμοποιήσουμε το 100% MaxSurge σε νέες αναπτύξεις για τους χειρότερους παραβάτες. Αυτό ήταν οριακά αποτελεσματικό και όχι βιώσιμο μακροπρόθεσμα με μερικές από τις μεγαλύτερες εφαρμογές.

Ένας άλλος μετριασμός που χρησιμοποιήσαμε ήταν να διογκώσουμε τεχνητά αιτήματα πόρων σε κρίσιμες υπηρεσίες, έτσι ώστε οι ομάδες που έχουν τοποθετηθεί να έχουν περισσότερο χώρο μαζί με άλλες βαριές ομάδες. Αυτό επίσης δεν θα ήταν μακροπρόθεσμα αποδεκτό λόγω της σπατάλης πόρων και οι εφαρμογές Node μας ήταν μονό νήμα και επομένως όρια αποτελεσματικά σε 1 πυρήνα. Η μόνη σαφής λύση ήταν να χρησιμοποιηθεί καλύτερη εξισορρόπηση φορτίου.

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

Η διαμόρφωση με την οποία βρήκαμε ήταν να έχουμε ένα παρασκήνιο Envoy δίπλα σε κάθε pod που είχε μια διαδρομή και σύμπλεγμα για να χτυπήσει την τοπική θύρα κοντέινερ. Για να ελαχιστοποιήσουμε τον πιθανό καταρράκτη και να διατηρήσουμε μια μικρή ακτίνα έκρηξης, χρησιμοποιήσαμε έναν στόλο λοβών Envoy front-proxy, μία ανάπτυξη σε κάθε Ζώνη Διαθεσιμότητας (AZ) για κάθε υπηρεσία. Αυτά έπληξαν έναν μικρό μηχανισμό ανακάλυψης υπηρεσιών που ένας από τους μηχανικούς μας συνέταξε που απλώς επέστρεψε μια λίστα με pod σε κάθε ΑΖ για μια δεδομένη υπηρεσία.

Στη συνέχεια, η υπηρεσία front-Envoys χρησιμοποίησε αυτόν τον μηχανισμό ανακάλυψης υπηρεσίας με ένα σύμπλεγμα και διαδρομή ανάντη. Διαμορφώσαμε εύλογα χρονικά όρια, ενισχύσαμε όλες τις ρυθμίσεις του διακόπτη προστασίας κυκλώματος και, στη συνέχεια, θέσαμε μια ελάχιστη διαμόρφωση επανάληψης για να βοηθήσουμε με παροδικές αστοχίες και ομαλή ανάπτυξη. Προωθήσαμε καθεμία από αυτές τις υπηρεσίες του Envoy με TCP ELB. Ακόμα κι αν το keepalive από το κύριο μπροστινό στρώμα διακομιστή μεσολάβησης καρφιτσώθηκε σε συγκεκριμένες ομάδες Envoy, ήταν πολύ καλύτερα σε θέση να χειριστεί το φορτίο και είχαν ρυθμιστεί να ισορροπούν μέσω του minimal_request στο backend.

Για ανάπτυξη, χρησιμοποιήσαμε ένα γάντζο preStop τόσο στην εφαρμογή όσο και στην πλαϊνή μπάρα. Αυτό το άγκιστρο που ονομάζεται sidecar health check απέτυχε το τελικό σημείο του διαχειριστή, μαζί με έναν μικρό ύπνο, για να δώσει λίγο χρόνο για να επιτρέψει στις συνδέσεις πτήσης να ολοκληρωθούν και να αποστραγγιστούν.

Ένας λόγος που μπορέσαμε να κινηθούμε τόσο γρήγορα ήταν λόγω των πλούσιων μετρήσεων που μπορέσαμε να ενσωματώσουμε εύκολα στην κανονική ρύθμιση Prometheus. Αυτό μας επέτρεψε να δούμε ακριβώς τι συνέβαινε καθώς επαναλάβαμε τις ρυθμίσεις διαμόρφωσης και μειώσαμε την επισκεψιμότητα.

Τα αποτελέσματα ήταν άμεσα και προφανή. Ξεκινήσαμε με τις πιο μη ισορροπημένες υπηρεσίες και σε αυτό το σημείο το έχουμε μπροστά από δώδεκα από τις πιο σημαντικές υπηρεσίες του συμπλέγματος μας. Φέτος σκοπεύουμε να προχωρήσουμε σε ένα πλέγμα πλήρους εξυπηρέτησης, με πιο εξελιγμένη ανακάλυψη υπηρεσιών, διακοπή κυκλώματος, ανίχνευση outlier, περιορισμό ρυθμού και ανίχνευση.

Σχήμα 3-1 Σύγκριση CPU μιας υπηρεσίας κατά τη διάρκεια της διακοπής σε απεσταλμένο

Το τελικό αποτέλεσμα

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

Στην παλαιά υποδομή μας, όταν απαιτήθηκε πρόσθετη κλίμακα, συχνά υποφέραμε μέσα σε αρκετά λεπτά αναμονής για νέες παρουσίες EC2 για σύνδεση στο διαδίκτυο. Τα κοντέινερ προγραμματίζουν και εξυπηρετούν την κυκλοφορία εντός δευτερολέπτων σε αντίθεση με τα λεπτά. Ο προγραμματισμός πολλαπλών κοντέινερ σε μία μόνο παρουσία EC2 παρέχει επίσης βελτιωμένη οριζόντια πυκνότητα. Ως αποτέλεσμα, προβάλλουμε σημαντική εξοικονόμηση κόστους σε EC2 το 2019 σε σύγκριση με το προηγούμενο έτος.

Χρειάστηκαν σχεδόν δύο χρόνια, αλλά ολοκληρώσαμε τη μετανάστευσή μας τον Μάρτιο του 2019. Η πλατφόρμα Tinder εκτελείται αποκλειστικά σε ένα σύμπλεγμα Kubernetes που αποτελείται από 200 υπηρεσίες, 1.000 κόμβους, 15.000 λοβό και 48.000 κοντέινερ. Η υποδομή δεν είναι πλέον έργο που προορίζεται για τις ομάδες λειτουργίας μας. Αντ 'αυτού, οι μηχανικοί σε ολόκληρο τον οργανισμό μοιράζονται αυτήν την ευθύνη και έχουν τον έλεγχο του τρόπου κατασκευής και ανάπτυξης των εφαρμογών τους με όλα ως κώδικα.

Δείτε επίσης

Πώς εμποδίζετε κάποιον να σας αναφέρει στο Instagram;Η φίλη χτυπιέται από έναν άντρα στο Snapchat της. Δεν θα τον διαγράψει ή θα του πει να αποσυρθεί από το αίτημά μου, γι 'αυτό το στέλνω προσωπικά στο Instagram και του λέω να διακόψει κάθε επαφή από αυτήν. Τώρα είναι τρελή και με αποκαλεί τρελό. Ποιος είναι σωστός;Είστε άγχος για τις γραμμές SnapChat; Γιατί θέλετε να συνεχίσετε;Πώς μπορώ να χρησιμοποιήσω ένα Instagram BioLink για να κερδίσω χρήματα;Γιατί δεν μπορώ να δημοσιεύσω \ u201καταγραφή \ u201d ιστορίες Instagram;Υπάρχει τρόπος να απενεργοποιήσετε την αυτόματη λήψη των φωνητικών μηνυμάτων στο WhatsApp; Εάν ναι, ποια είναι η διαδικασία για να γίνει αυτό;Πρέπει να καταργήσω τον πρώην μου ως ακόλουθο από το Instagram; Μόλις ανακάλυψα ότι αυτό ήταν δυνατό. Σύντομη ιστορία: ήταν ένα κρύο χωρισμό και δεν έχουμε μιλήσει από τότε (σχεδόν 3 χρόνια). Ποιο θα έβλαπτε περισσότερο: τον ενημερώνω για τη ζωή μου ή τον κόβω;Πώς μπορώ να θέσω σε σίγαση τις αναρτήσεις κάποιου Instagram στο Android;