Σήμερα σκοπεύω να μιλήσω για το πώς να γράφετε εφαρμογές και ποιες είναι οι απαιτήσεις για να λειτουργεί καλά η εφαρμογή σας στο Kubernetes. Για να μην υπάρχουν πονοκέφαλοι με την εφαρμογή, ώστε να μην χρειάζεται να εφεύρετε και να δημιουργήσετε "γρατσουνιές" γύρω από αυτήν - και όλα λειτουργούν όπως σκόπευε η ίδια η Kubernetes.
Αυτή η διάλεξη είναι μέρος του "" Μπορείτε να δείτε τις ανοιχτές θεωρητικές διαλέξεις του Εσπερινού Σχολείου . Για όσους προτιμούν κείμενο αντί βίντεο, ετοιμάσαμε αυτό το άρθρο.
Ονομάζομαι Pavel Selivanov, αυτή τη στιγμή είμαι ο κορυφαίος μηχανικός DevOps στο Mail.ru Cloud Solutions, φτιάχνουμε σύννεφα, φτιάχνουμε kubernetes διαχείρισης και ούτω καθεξής. Τα καθήκοντά μου τώρα περιλαμβάνουν βοήθεια στην ανάπτυξη, διάδοση αυτών των cloud, ανάπτυξη των εφαρμογών που γράφουμε και απευθείας ανάπτυξη των εργαλείων που παρέχουμε στους χρήστες μας.
Κάνω DevOps, νομίζω τα τελευταία, πιθανώς, τρία χρόνια. Αλλά, κατ' αρχήν, κάνω ό,τι κάνει το DevOps για πιθανώς περίπου πέντε χρόνια τώρα. Πριν από αυτό, ασχολήθηκα κυρίως με θέματα διαχειριστή. Ξεκίνησα να δουλεύω με την Kubernetes πριν από πολύ καιρό - πιθανότατα έχουν περάσει περίπου τέσσερα χρόνια από τότε που ξεκίνησα να δουλεύω μαζί της.
Γενικά, ξεκίνησα όταν το Kubernetes ήταν η έκδοση 1.3, πιθανώς, και ίσως η 1.2 - όταν ήταν ακόμη στα σπάργανα. Τώρα δεν είναι πλέον στα σπάργανα - και είναι προφανές ότι υπάρχει τεράστια ζήτηση στην αγορά για μηχανικούς που θα ήθελαν να μπορούν να κάνουν Kubernetes. Και οι εταιρείες έχουν πολύ μεγάλη ζήτηση για τέτοιους ανθρώπους. Επομένως, στην πραγματικότητα, εμφανίστηκε αυτή η διάλεξη.
Αν μιλάμε σύμφωνα με το σχέδιο για το τι θα μιλήσω, φαίνεται κάπως έτσι, σε αγκύλες γράφει (TL;DR) - «πολύ καιρό. μη διαβάζεις». Η σημερινή μου παρουσίαση θα αποτελείται από ατελείωτες λίστες.
Στην πραγματικότητα, εγώ ο ίδιος δεν μου αρέσουν τέτοιες παρουσιάσεις όταν γίνονται, αλλά αυτό είναι ένα τέτοιο θέμα που όταν ετοίμαζα αυτήν την παρουσίαση, απλά δεν κατάλαβα πώς να οργανώσω αυτές τις πληροφορίες διαφορετικά.
Επειδή, σε γενικές γραμμές, αυτές οι πληροφορίες είναι «ctrl+c, ctrl+v», από, μεταξύ άλλων, το Wiki μας στην ενότητα DevOps, όπου έχουμε γραπτές απαιτήσεις για προγραμματιστές: «Παιδιά, για να ξεκινήσουμε την εφαρμογή σας στο Kubernetes, θα έπρεπε να είναι έτσι."
Γι' αυτό η παρουσίαση αποδείχθηκε τόσο μεγάλη λίστα. Συγνώμη. Θα προσπαθήσω να πω όσο το δυνατόν περισσότερα για να μην είναι βαρετό αν γίνεται.
Τι θα δούμε τώρα:
- Αυτά είναι, πρώτον, αρχεία καταγραφής (αρχεία καταγραφής εφαρμογών;), τι να κάνετε με αυτά στο Kubernetes, τι να κάνετε με αυτά, τι πρέπει να είναι.
- τι να κάνετε με τις διαμορφώσεις στο Kubernetes, ποιοι είναι οι καλύτεροι και οι χειρότεροι τρόποι διαμόρφωσης μιας εφαρμογής για το Kubernetes.
- Ας μιλήσουμε για το τι είναι γενικά οι έλεγχοι προσβασιμότητας, πώς θα πρέπει να μοιάζουν.
- Ας μιλήσουμε για το τι είναι ένα χαριτωμένο κλείσιμο.
- Ας μιλήσουμε ξανά για πόρους.
- Ας αγγίξουμε για άλλη μια φορά το θέμα της αποθήκευσης δεδομένων.
- και στο τέλος θα σας πω ποιος είναι ο όρος αυτή η μυστηριώδης cloud-native εφαρμογή. Συννεφιαστικότητα, ως επίθετο αυτού του όρου.
κούτσουρα
Προτείνω να ξεκινήσετε με τα κούτσουρα - με το πού πρέπει να ωθηθούν αυτά τα αρχεία καταγραφής στο Kubernetes. Τώρα έχετε ξεκινήσει μια εφαρμογή στο Kubernetes. Σύμφωνα με τα κλασικά, παλαιότερα οι εφαρμογές έγραφαν πάντα αρχεία καταγραφής κάπου σε ένα αρχείο. Οι κακές εφαρμογές έγραψαν αρχεία καταγραφής σε ένα αρχείο στον αρχικό κατάλογο του προγραμματιστή που εκκίνησε την εφαρμογή. Οι καλές εφαρμογές έγραψαν αρχεία καταγραφής σε ένα αρχείο κάπου μέσα /var/log.
Αντίστοιχα, περαιτέρω, οι καλοί διαχειριστές είχαν διαμορφώσει κάποια πράγματα στις υποδομές τους που θα μπορούσαν να περιστρέψουν αυτά τα αρχεία καταγραφής - το ίδιο rsyslog, που κοιτάζει αυτά τα αρχεία καταγραφής και όταν τους συμβαίνει κάτι, υπάρχουν πολλά, δημιουργεί αντίγραφα ασφαλείας , βάζει αρχεία καταγραφής εκεί , διαγράφει παλιά αρχεία, περισσότερο από μία εβδομάδα, έξι μήνες και μερικά ακόμη. Θεωρητικά θα πρέπει να έχουμε προβλέψεις ώστε απλά επειδή η εφαρμογή γράφει logs να μην εξαντλείται ο χώρος στους διακομιστές παραγωγής (combat servers;). Και, κατά συνέπεια, ολόκληρη η παραγωγή δεν σταμάτησε λόγω των κορμών.
Όταν μετακομίζουμε στον κόσμο των Kubernetes και τρέχουμε το ίδιο πράγμα εκεί, το πρώτο πράγμα που μπορείτε να προσέξετε είναι το γεγονός ότι οι άνθρωποι, όπως έγραψαν αρχεία καταγραφής σε ένα αρχείο, συνεχίζουν να τα γράφουν.
Αποδεικνύεται ότι αν μιλάμε για Kubernetes, το σωστό μέρος για να γράψετε αρχεία καταγραφής κάπου από ένα κοντέινερ docker είναι απλώς να τα γράψετε από την εφαρμογή στο λεγόμενο Stdout/Stderr, δηλαδή στις τυπικές ροές εξόδου του λειτουργικού συστήματος, η τυπική έξοδος σφάλματος. Αυτός είναι ο πιο σωστός, απλούστερος και πιο λογικός τρόπος για να βάλετε τα αρχεία καταγραφής καταρχήν στο Docker και συγκεκριμένα στο Kubernetis. Διότι εάν η εφαρμογή σας γράφει αρχεία καταγραφής στο Stdout/Stderr, τότε εναπόκειται στο Docker και το πρόσθετο Kubernetes να αποφασίσουν τι θα κάνουν με αυτά τα αρχεία καταγραφής. Το Docker θα δημιουργήσει από προεπιλογή τα ειδικά αρχεία του σε μορφή JSON.
Εδώ τίθεται το ερώτημα, τι θα κάνετε μετά με αυτά τα κούτσουρα; Ο ευκολότερος τρόπος είναι ξεκάθαρος, έχουμε τη δυνατότητα να κάνουμε kubectl logs και κοιτάξτε αυτά τα κούτσουρα αυτών των «λοβών». Αλλά, πιθανώς, αυτή δεν είναι μια πολύ καλή επιλογή - κάτι άλλο πρέπει να γίνει με τα κούτσουρα.
Προς το παρόν, ας μιλήσουμε ταυτόχρονα, αφού θίξαμε το θέμα των κορμών, για κάτι που θα έπρεπε να μοιάζει με τα κούτσουρα. Δηλαδή, αυτό δεν ισχύει άμεσα για το Kubernetes, αλλά όταν αρχίσουμε να σκεφτόμαστε τι να κάνουμε με τα κούτσουρα, καλό θα ήταν να το σκεφτούμε και αυτό.
Χρειαζόμαστε ένα είδος εργαλείου, με φιλικό τρόπο, που θα πάρει αυτά τα αρχεία καταγραφής που τοποθετεί ο docker μας στα αρχεία του και θα τα στείλει κάπου. Σε γενικές γραμμές, συνήθως λανσάρουμε κάποιου είδους πράκτορα μέσα στο Kubernetes με τη μορφή ενός DaemonSet - ενός συλλέκτη αρχείων καταγραφής, στον οποίο απλώς λέγεται πού βρίσκονται τα αρχεία καταγραφής που συλλέγει το Docker. Και αυτός ο συλλεκτικός πράκτορας απλώς τα παίρνει, ίσως και με κάποιο τρόπο τα αναλύει στην πορεία, ίσως τα εμπλουτίσει με κάποιες πρόσθετες μετα-πληροφορίες και, τελικά, τα στέλνει για αποθήκευση κάπου. Παραλλαγές είναι ήδη δυνατές εκεί. Το πιο συνηθισμένο είναι πιθανώς το Elasticsearch, όπου μπορείτε να αποθηκεύσετε αρχεία καταγραφής και να τα ανακτήσετε εύκολα από εκεί. Στη συνέχεια, χρησιμοποιώντας ένα αίτημα, χρησιμοποιώντας το Kibana, για παράδειγμα, δημιουργήστε γραφήματα με βάση αυτά, δημιουργήστε ειδοποιήσεις με βάση αυτά και ούτω καθεξής.
Η πιο σημαντική ιδέα, θέλω να το επαναλάβω ξανά, είναι ότι μέσα στο Docker, ιδιαίτερα στο Kubernetes, η αποθήκευση των αρχείων καταγραφής σας σε ένα αρχείο είναι πολύ κακή ιδέα.
Διότι πρώτον, είναι δύσκολο να μπουν τα αρχεία καταγραφής μέσα στο κοντέινερ σε ένα αρχείο. Πρέπει πρώτα να μεταβείτε στο κοντέινερ, να εκτελέσετε εκεί και, στη συνέχεια, να δείτε τα αρχεία καταγραφής. Το επόμενο σημείο είναι ότι εάν έχετε αρχεία καταγραφής σε ένα αρχείο, τότε τα κοντέινερ έχουν συνήθως ένα μινιμαλιστικό περιβάλλον και δεν υπάρχουν βοηθητικά προγράμματα που συνήθως χρειάζονται για κανονική εργασία με κορμούς. Θάψτε τα, δείτε τα, ανοίξτε τα σε ένα πρόγραμμα επεξεργασίας κειμένου. Η επόμενη στιγμή είναι όταν έχουμε αρχεία καταγραφής σε ένα αρχείο μέσα σε ένα κοντέινερ, αν αυτό το κοντέινερ διαγραφεί, καταλαβαίνετε, τα αρχεία καταγραφής θα πεθάνουν μαζί του. Κατά συνέπεια, οποιαδήποτε επανεκκίνηση του δοχείου σημαίνει ότι δεν υπάρχουν άλλα κούτσουρα. Και πάλι κακή επιλογή.
Και το τελευταίο σημείο είναι ότι μέσα σε κοντέινερ συνήθως έχετε την αίτησή σας και αυτό είναι - συνήθως είναι η μόνη διαδικασία που εκτελείται. Δεν υπάρχει καμία απολύτως συζήτηση για οποιαδήποτε διαδικασία που θα εναλλάσσει αρχεία με τα αρχεία καταγραφής σας. Μόλις αρχίσουν να γράφονται τα αρχεία καταγραφής σε ένα αρχείο, αυτό σημαίνει ότι, με συγχωρείτε, θα αρχίσουμε να χάνουμε τον διακομιστή παραγωγής. Επειδή, πρώτον, είναι δύσκολο να βρεθούν, κανείς δεν τους παρακολουθεί, συν κανένας δεν τους ελέγχει - κατά συνέπεια, το αρχείο μεγαλώνει ατελείωτα μέχρι να εξαντληθεί ο χώρος στον διακομιστή. Επομένως, λέω ξανά ότι η σύνδεση στο Docker, ιδίως στο Kubernetes, σε ένα αρχείο είναι κακή ιδέα.
Το επόμενο σημείο, εδώ θέλω να μιλήσω ξανά για αυτό - καθώς αγγίζουμε το θέμα των αρχείων καταγραφής, θα ήταν καλό να μιλήσουμε για το πώς πρέπει να φαίνονται τα αρχεία καταγραφής για να είναι βολική η εργασία μαζί τους. Όπως είπα, το θέμα δεν σχετίζεται άμεσα με το Kubernetes, αλλά σχετίζεται πολύ καλά με το θέμα του DevOps. Στο θέμα της κουλτούρας ανάπτυξης και της φιλίας μεταξύ αυτών των δύο διαφορετικών τμημάτων - Dev και Ops, έτσι ώστε όλοι να είναι άνετα.
Αυτό σημαίνει ότι ιδανικά, σήμερα, τα αρχεία καταγραφής θα πρέπει να γράφονται σε μορφή JSON. Εάν έχετε κάποια ακατανόητη δική σας εφαρμογή, η οποία γράφει αρχεία καταγραφής σε ακατανόητες μορφές επειδή εισάγετε κάποιο είδος εκτύπωσης ή κάτι τέτοιο, τότε ήρθε η ώρα να ψάξετε στο google κάποιου είδους πλαίσιο, κάποιο είδος περιτυλίγματος που σας επιτρέπει να εφαρμόσετε κανονική καταγραφή. ενεργοποιήστε εκεί τις παραμέτρους καταγραφής στο JSON, επειδή το JSON είναι μια απλή μορφή, η ανάλυση είναι απλή.
Εάν το JSON σας δεν λειτουργεί σύμφωνα με ορισμένα κριτήρια, κανείς δεν ξέρει τι, τότε τουλάχιστον γράψτε αρχεία καταγραφής σε μορφή που να μπορεί να αναλυθεί. Εδώ, μάλλον, αξίζει να σκεφτείτε το γεγονός ότι, για παράδειγμα, εάν εκτελείτε ένα σωρό κοντέινερ ή απλώς επεξεργάζεστε με το nginx και το καθένα έχει τις δικές του ρυθμίσεις καταγραφής, τότε μάλλον φαίνεται ότι θα σας είναι πολύ άβολο να αναλύστε τα. Επειδή για κάθε νέα παρουσία του nginx πρέπει να γράψετε τον δικό σας αναλυτή, επειδή γράφουν αρχεία καταγραφής διαφορετικά. Και πάλι, μάλλον άξιζε να σκεφτούμε να βεβαιωθούμε ότι όλες αυτές οι περιπτώσεις nginx είχαν την ίδια διαμόρφωση καταγραφής και έγραφαν όλα τα αρχεία καταγραφής τους απολύτως ομοιόμορφα. Το ίδιο ισχύει για όλες τις εφαρμογές.
Στο τέλος, θέλω επίσης να ρίξω λάδι στη φωτιά ότι, ιδανικά, τα αρχεία καταγραφής με μορφή πολλαπλών γραμμών θα πρέπει να αποφεύγονται. Εδώ είναι το θέμα, αν έχετε ποτέ εργαστεί με συλλέκτες κορμών, τότε πιθανότατα έχετε δει τι σας υπόσχονται, ότι μπορούν να δουλέψουν με κορμούς πολλών γραμμών, να ξέρουν πώς να τα συλλέγουν και ούτω καθεξής. Στην πραγματικότητα, κατά τη γνώμη μου, ούτε ένας συλλέκτης σήμερα δεν μπορεί να συλλέξει κούτσουρα πολλαπλών γραμμών κανονικά, πλήρως και χωρίς σφάλματα. Με ανθρώπινο τρόπο, ώστε να είναι βολικό και χωρίς λάθη.
Αλλά το stack trace είναι πάντα αρχεία καταγραφής πολλών γραμμών και πώς να τα αποφύγετε. Το ερώτημα εδώ είναι ότι ένα αρχείο καταγραφής είναι μια εγγραφή ενός συμβάντος και το stactrace δεν είναι στην πραγματικότητα ένα αρχείο καταγραφής. Εάν συλλέξουμε αρχεία καταγραφής και τα τοποθετήσουμε κάπου στο Elasticsearch και στη συνέχεια σχεδιάσουμε γραφήματα από αυτά, δημιουργήσουμε ορισμένες αναφορές δραστηριότητας χρηστών στον ιστότοπό σας, τότε όταν λαμβάνετε ένα ίχνος στοίβας, σημαίνει ότι συμβαίνει κάτι απροσδόκητο. μια κατάσταση που δεν χειρίζεται την εφαρμογή σας. Και είναι λογικό να ανεβάζετε αυτόματα ένα ίχνος στοίβας κάπου σε ένα σύστημα που μπορεί να τα παρακολουθεί.
Αυτό είναι λογισμικό (το ίδιο Sentry) που έχει κατασκευαστεί ειδικά για να λειτουργεί με stack trace. Μπορεί να δημιουργήσει αμέσως αυτοματοποιημένες εργασίες, να τις αναθέσει σε κάποιον, να ειδοποιήσει όταν εμφανίζονται stacttraces, να ομαδοποιήσει αυτά τα stacttraces κατά έναν τύπο και ούτω καθεξής. Κατ 'αρχήν, δεν έχει πολύ νόημα να μιλάμε για stactraces όταν μιλάμε για κούτσουρα, επειδή τελικά αυτά είναι διαφορετικά πράγματα με διαφορετικούς σκοπούς.
Διαμόρφωση
Στη συνέχεια, μιλάμε για τη διαμόρφωση στο Kubernetes: τι να κάνετε με αυτό και πώς θα πρέπει να ρυθμιστούν οι εφαρμογές μέσα στο Kubernetes. Γενικά, συνήθως λέω ότι το Docker δεν είναι για κοντέινερ. Όλοι γνωρίζουν ότι το Docker έχει να κάνει με κοντέινερ, ακόμα και εκείνοι που δεν έχουν δουλέψει πολύ με το Docker. Επαναλαμβάνω, το Docker δεν είναι για κοντέινερ.
Το Docker, κατά τη γνώμη μου, έχει να κάνει με τα πρότυπα. Και υπάρχουν πρότυπα για σχεδόν τα πάντα: πρότυπα για τη δημιουργία της εφαρμογής σας, πρότυπα για την εγκατάσταση της εφαρμογής σας.
Και αυτό το πράγμα - το χρησιμοποιούσαμε πριν, μόλις έγινε ιδιαίτερα δημοφιλές με την εμφάνιση των κοντέινερ - αυτό το πράγμα ονομάζεται μεταβλητές ENV (περιβάλλοντος), δηλαδή μεταβλητές περιβάλλοντος που υπάρχουν στο λειτουργικό σας σύστημα. Αυτός είναι γενικά ένας ιδανικός τρόπος για να διαμορφώσετε την εφαρμογή σας, γιατί αν έχετε εφαρμογές σε JAVA, Python, Go, Perl, Θεός φυλάξοι, και μπορούν όλες να διαβάσουν τον κεντρικό υπολογιστή της βάσης δεδομένων, τον χρήστη της βάσης δεδομένων, τις μεταβλητές του κωδικού πρόσβασης της βάσης δεδομένων, τότε είναι ιδανικό. Έχετε εφαρμογές σε τέσσερις διαφορετικές γλώσσες διαμορφωμένες στο σχέδιο βάσης δεδομένων με τον ίδιο τρόπο. Δεν υπάρχουν άλλες διαφορετικές ρυθμίσεις παραμέτρων.
Όλα μπορούν να ρυθμιστούν χρησιμοποιώντας μεταβλητές ENV. Όταν μιλάμε για Kubernetes, υπάρχει ένας πολύ καλός τρόπος για να δηλώσετε μεταβλητές ENV ακριβώς μέσα στο Deployment. Αντίστοιχα, αν μιλάμε για μυστικά δεδομένα, τότε μπορούμε αμέσως να προωθήσουμε μυστικά δεδομένα από μεταβλητές ENV (κωδικούς πρόσβασης σε βάσεις δεδομένων κ.λπ.) σε ένα μυστικό, να δημιουργήσουμε ένα μυστικό σύμπλεγμα και να υποδείξουμε στην περιγραφή ENV στο Deployment ότι δεν δηλώνουμε απευθείας Η τιμή αυτής της μεταβλητής και η τιμή αυτής της μεταβλητής κωδικού πρόσβασης βάσης δεδομένων θα διαβαστούν από το μυστικό. Αυτή είναι η τυπική συμπεριφορά Kubernetes. Και αυτή είναι η πιο ιδανική επιλογή για να διαμορφώσετε τις εφαρμογές σας. Απλά σε επίπεδο κώδικα, και πάλι αυτό ισχύει για προγραμματιστές. Εάν είστε DevOps, μπορείτε να ρωτήσετε: «Παιδιά, διδάξτε την εφαρμογή σας να διαβάζει μεταβλητές περιβάλλοντος. Και θα είμαστε όλοι χαρούμενοι».
Εάν όλοι στην εταιρεία διαβάζουν τις ίδιες μεταβλητές περιβάλλοντος, τότε αυτό είναι υπέροχο. Για να μην συμβεί κάποιοι να περιμένουν τη βάση δεδομένων postgres, άλλοι να περιμένουν το όνομα της βάσης δεδομένων, άλλοι να περιμένουν κάτι άλλο, άλλοι να περιμένουν ένα dbn κάποιου είδους, ώστε, κατά συνέπεια, να υπάρχει ομοιομορφία.
Το πρόβλημα προκύπτει όταν έχετε τόσες πολλές μεταβλητές περιβάλλοντος που μόλις ανοίγετε το Deployment - και υπάρχουν πεντακόσιες γραμμές μεταβλητών περιβάλλοντος. Σε αυτήν την περίπτωση, έχετε απλώς ξεπεράσει τις μεταβλητές περιβάλλοντος - και δεν χρειάζεται πλέον να βασανίζετε τον εαυτό σας. Σε αυτήν την περίπτωση, θα ήταν λογικό να αρχίσετε να χρησιμοποιείτε ρυθμίσεις παραμέτρων. Δηλαδή, εκπαιδεύστε την εφαρμογή σας να χρησιμοποιεί ρυθμίσεις παραμέτρων.
Το μόνο ερώτημα είναι ότι οι ρυθμίσεις παραμέτρων δεν είναι αυτό που νομίζετε. Το Config.pi δεν είναι μια ρύθμιση παραμέτρων που είναι βολική στη χρήση. Ή κάποια διαμόρφωση στη δική σας μορφή, εναλλακτικά προικισμένη - δεν είναι και αυτή η ρύθμιση που εννοώ.
Αυτό για το οποίο μιλάω είναι διαμόρφωση σε αποδεκτές μορφές, δηλαδή, μακράν το πιο δημοφιλές πρότυπο είναι το πρότυπο .yaml. Είναι ξεκάθαρο πώς να το διαβάσετε, είναι αναγνώσιμο από τον άνθρωπο, είναι ξεκάθαρο πώς να το διαβάσετε από την εφαρμογή.
Κατά συνέπεια, εκτός από το YAML, μπορείτε επίσης, για παράδειγμα, να χρησιμοποιήσετε το JSON, η ανάλυση είναι περίπου τόσο βολική όσο η YAML όσον αφορά την ανάγνωση της διαμόρφωσης της εφαρμογής από εκεί. Είναι αισθητά πιο άβολο για τους ανθρώπους να διαβάζουν. Μπορείτε να δοκιμάσετε τη μορφή, a la ini. Είναι αρκετά βολικό στην ανάγνωση, από ανθρώπινη σκοπιά, αλλά μπορεί να είναι άβολο να το επεξεργαστείτε αυτόματα, με την έννοια ότι εάν θέλετε να δημιουργήσετε ποτέ τις δικές σας ρυθμίσεις, η μορφή ini μπορεί να είναι ήδη άβολη στη δημιουργία.
Αλλά σε κάθε περίπτωση, όποια μορφή κι αν επιλέξετε, το θέμα είναι ότι από την άποψη του Kubernetes είναι πολύ βολικό. Μπορείτε να βάλετε ολόκληρο το config σας στο Kubernetes, στο ConfigMap. Στη συνέχεια, πάρτε αυτό το configmap και ζητήστε το να τοποθετηθεί μέσα στο pod σας σε κάποιον συγκεκριμένο κατάλογο, όπου η εφαρμογή σας θα διαβάσει τη διαμόρφωση από αυτό το configmap σαν να ήταν απλώς ένα αρχείο. Αυτό, στην πραγματικότητα, είναι αυτό που είναι καλό να κάνετε όταν έχετε πολλές επιλογές διαμόρφωσης στην εφαρμογή σας. Ή είναι απλώς κάποιο είδος περίπλοκης δομής, υπάρχει φωλιά.
Εάν έχετε ένα configmap, τότε μπορείτε πολύ καλά να διδάξετε την εφαρμογή σας, για παράδειγμα, να παρακολουθεί αυτόματα τις αλλαγές στο αρχείο όπου είναι τοποθετημένο το configmap και επίσης να φορτώνει αυτόματα την εφαρμογή σας όταν αλλάζουν οι ρυθμίσεις παραμέτρων. Αυτή θα ήταν γενικά μια ιδανική επιλογή.
Και πάλι, έχω ήδη μιλήσει για αυτό - οι μυστικές πληροφορίες δεν βρίσκονται στο configmap, οι μυστικές πληροφορίες δεν βρίσκονται σε μεταβλητές, οι μυστικές πληροφορίες δεν είναι στα μυστικά. Από εκεί, συνδέστε αυτές τις μυστικές πληροφορίες με τη διπλωματία. Συνήθως αποθηκεύουμε όλες τις περιγραφές αντικειμένων Kubernetes, αναπτύξεις, configmaps, υπηρεσίες στο git. Αντίστοιχα, η τοποθέτηση του κωδικού πρόσβασης στη βάση δεδομένων στο git, ακόμα κι αν είναι το git σας, που έχετε εσωτερικά στην εταιρεία, είναι κακή ιδέα. Επειδή, τουλάχιστον, το git θυμάται τα πάντα και η απλή αφαίρεση κωδικών πρόσβασης από εκεί δεν είναι τόσο εύκολη.
Ελεγχος υγείας
Το επόμενο σημείο είναι αυτό το πράγμα που ονομάζεται έλεγχος υγείας. Σε γενικές γραμμές, ένας έλεγχος υγείας είναι απλώς ο έλεγχος ότι η αίτησή σας λειτουργεί. Ταυτόχρονα, μιλάμε συχνότερα για ορισμένες διαδικτυακές εφαρμογές, για τις οποίες, κατά συνέπεια, από την άποψη του υγειονομικού ελέγχου (καλύτερα να μην μεταφράζεται εδώ και περαιτέρω) αυτό θα είναι κάποιο ειδικό URL, το οποίο επεξεργάζονται ως ένα πρότυπο, συνήθως κάνουν /health.
Κατά την πρόσβαση σε αυτήν τη διεύθυνση URL, κατά συνέπεια, η εφαρμογή μας λέει είτε "ναι, εντάξει, όλα είναι καλά με εμένα, 200" είτε "όχι, όλα δεν είναι καλά με εμένα, περίπου 500". Αντίστοιχα, αν η εφαρμογή μας δεν είναι http, όχι web εφαρμογή, τώρα μιλάμε για κάποιο είδος δαίμονα, μπορούμε να καταλάβουμε πώς να κάνουμε υγειονομικούς ελέγχους. Δηλαδή δεν είναι απαραίτητο, αν η εφαρμογή δεν είναι http, τότε όλα λειτουργούν χωρίς υγειονομικό έλεγχο και αυτό δεν μπορεί να γίνει με κανέναν τρόπο. Μπορείτε να ενημερώνετε περιοδικά κάποιες πληροφορίες στο αρχείο, μπορείτε να βρείτε κάποια ειδική εντολή για τον δαίμονά σας, όπως, daemon status, που θα πει "ναι, όλα είναι καλά, ο δαίμονας λειτουργεί, είναι ζωντανός."
Σε τι χρησιμεύει; Το πρώτο και πιο προφανές είναι ίσως γιατί χρειάζεται έλεγχος υγείας - για να καταλάβουμε ότι η εφαρμογή λειτουργεί. Θέλω να πω, είναι απλώς ανόητο, όταν είναι ανοιχτό τώρα, φαίνεται ότι λειτουργεί, οπότε μπορείτε να είστε σίγουροι ότι λειτουργεί. Και αποδεικνύεται ότι η εφαρμογή εκτελείται, το κοντέινερ λειτουργεί, το παράδειγμα λειτουργεί, όλα είναι καλά - και τότε οι χρήστες έχουν ήδη κόψει όλους τους αριθμούς τηλεφώνου από την τεχνική υποστήριξη και λένε "τι είσαι..., εσύ αποκοιμήθηκε, τίποτα δεν λειτουργεί».
Ένας έλεγχος υγείας είναι ακριβώς ένας τέτοιος τρόπος για να δείτε από την πλευρά του χρήστη ότι λειτουργεί. Μία από τις μεθόδους. Ας το πούμε έτσι. Από την άποψη του Kubernetes, αυτός είναι επίσης ένας τρόπος για να κατανοήσουμε πότε ξεκινά η εφαρμογή, επειδή καταλαβαίνουμε ότι υπάρχει διαφορά μεταξύ του πότε ξεκίνησε, δημιουργήθηκε και ξεκίνησε το κοντέινερ και πότε ξεκίνησε η εφαρμογή απευθείας σε αυτό το κοντέινερ. Γιατί αν πάρουμε κάποια μέση εφαρμογή java και προσπαθήσουμε να την εκκινήσουμε στο dock, τότε για σαράντα δευτερόλεπτα, ή ακόμα και ένα λεπτό, ή ακόμα και δέκα, μπορεί να ξεκινήσει μια χαρά. Σε αυτή την περίπτωση, μπορείς τουλάχιστον να χτυπήσεις τις θύρες του, δεν θα απαντήσει εκεί, δηλαδή δεν είναι ακόμα έτοιμο να λάβει κίνηση.
Και πάλι, με τη βοήθεια ενός ελέγχου υγείας και με τη βοήθεια του γεγονότος ότι στρίβουμε εδώ, μπορούμε να καταλάβουμε στο Kubernetes ότι όχι μόνο το κοντέινερ έχει ανέβει στην εφαρμογή, αλλά η ίδια η εφαρμογή έχει ξεκινήσει, ανταποκρίνεται ήδη στο έλεγχος υγείας, που σημαίνει ότι μπορούμε να στείλουμε κίνηση εκεί.
Αυτό για το οποίο μιλάω τώρα ονομάζονται δοκιμές ετοιμότητας/ζωντανής μέσα στο Kubernetes· κατά συνέπεια, τα τεστ ετοιμότητάς μας είναι υπεύθυνα για τη διαθεσιμότητα της εφαρμογής στην εξισορρόπηση. Δηλαδή, εάν πραγματοποιηθούν δοκιμές ετοιμότητας στην εφαρμογή, τότε όλα είναι εντάξει, η επισκεψιμότητα του πελάτη πηγαίνει στην εφαρμογή. Εάν δεν πραγματοποιηθούν δοκιμές ετοιμότητας, τότε η εφαρμογή απλά δεν συμμετέχει, η συγκεκριμένη περίπτωση δεν συμμετέχει στην εξισορρόπηση, αφαιρείται από την εξισορρόπηση, η κίνηση πελατών δεν ρέει. Αντίστοιχα, απαιτούνται δοκιμές Liveness εντός του Kubernetes, έτσι ώστε εάν η εφαρμογή κολλήσει, να μπορεί να επανεκκινηθεί. Εάν το τεστ ζωντανότητας δεν λειτουργεί για μια εφαρμογή που έχει δηλωθεί στο Kubernetes, τότε η εφαρμογή όχι απλώς αφαιρείται από την εξισορρόπηση, αλλά επανεκκινείται.
Και εδώ είναι ένα σημαντικό σημείο που θα ήθελα να αναφέρω: από πρακτική άποψη, το τεστ ετοιμότητας χρησιμοποιείται συνήθως πιο συχνά και χρειάζεται πιο συχνά από το τεστ ζωντάνιας. Δηλαδή, το να δηλώνεις απλώς αλόγιστα και δοκιμές ετοιμότητας και ζωντάνιας, επειδή το Kubernetes μπορεί να το κάνει αυτό, και ας χρησιμοποιήσουμε όλα όσα μπορεί να κάνει, δεν είναι πολύ καλή ιδέα. Θα εξηγήσω γιατί. Επειδή το σημείο νούμερο δύο στις δοκιμές είναι ότι θα ήταν καλή ιδέα να ελέγξετε την υποκείμενη υπηρεσία στους ελέγχους υγείας σας. Αυτό σημαίνει ότι εάν έχετε μια διαδικτυακή εφαρμογή που δίνει κάποιες πληροφορίες, τις οποίες με τη σειρά της, φυσικά, πρέπει να τις πάρει από κάπου. Σε μια βάση δεδομένων, για παράδειγμα. Λοιπόν, αποθηκεύει τις πληροφορίες που έρχονται σε αυτό το REST API στην ίδια βάση δεδομένων. Στη συνέχεια, κατά συνέπεια, εάν ο υγειονομικός έλεγχος σας ανταποκρίνεται απλά όπως ο slashhealth με επικοινωνία, η εφαρμογή λέει "200, εντάξει, όλα είναι καλά" και ταυτόχρονα η βάση δεδομένων της αίτησής σας δεν είναι προσβάσιμη και η εφαρμογή υγειονομικού ελέγχου λέει "200, εντάξει, όλα είναι καλά ” - Αυτό είναι κακός έλεγχος υγείας. Δεν πρέπει να λειτουργεί έτσι.
Δηλαδή την αίτησή σας, όταν έρχεται ένα αίτημα /health, δεν απαντά απλώς, "200, οκ", πρώτα πηγαίνει, για παράδειγμα, στη βάση δεδομένων, προσπαθεί να συνδεθεί με αυτήν, κάνει κάτι πολύ βασικό εκεί, όπως επιλέξτε ένα, απλώς ελέγχει ότι υπάρχει σύνδεση στο βάση δεδομένων και μπορείτε να ρωτήσετε τη βάση δεδομένων. Αν όλα αυτά ήταν επιτυχή, τότε η απάντηση είναι «200, εντάξει». Εάν δεν είναι επιτυχής, λέει ότι υπάρχει σφάλμα, η βάση δεδομένων δεν είναι διαθέσιμη.
Ως εκ τούτου, από αυτή την άποψη, επιστρέφω ξανά στα τεστ ετοιμότητας/ζωηρότητας - γιατί πιθανότατα χρειάζεστε ένα τεστ ετοιμότητας, αλλά ένα τεστ ζωντάνιας είναι υπό αμφισβήτηση. Γιατί αν περιγράψεις τους υγειονομικούς ελέγχους όπως ακριβώς είπα, τότε θα αποδειχθεί ότι δεν είναι διαθέσιμος στο τμήμα της περίπτωσηςв или со всех instanceσε μια βάση δεδομένων, για παράδειγμα. Όταν δηλώσατε ένα τεστ ετοιμότητας, οι έλεγχοι υγείας μας άρχισαν να αποτυγχάνουν και, κατά συνέπεια, όλες οι εφαρμογές από τις οποίες δεν είναι προσβάσιμη η βάση δεδομένων, απλώς απενεργοποιούνται από την εξισορρόπηση και στην πραγματικότητα «κολλάνε» απλώς σε παραμελημένη κατάσταση και περιμένουν τις βάσεις δεδομένων τους να δουλειά.
Αν έχουμε δηλώσει μια δοκιμή ζωντανότητας, τότε φανταστείτε ότι η βάση δεδομένων μας έχει σπάσει και στο Kubernetes σας τα μισά από όλα αρχίζουν να επανεκκινούνται επειδή η δοκιμή ζωντανότητας αποτυγχάνει. Αυτό σημαίνει ότι πρέπει να κάνετε επανεκκίνηση. Δεν είναι καθόλου αυτό που θέλετε, είχα και προσωπική εμπειρία στην πράξη. Είχαμε μια εφαρμογή συνομιλίας που ήταν γραμμένη σε JS και τροφοδοτήθηκε σε μια βάση δεδομένων Mongo. Και το πρόβλημα ήταν ότι ήταν στην αρχή της δουλειάς μου με την Kubernetes, περιγράψαμε την ετοιμότητα, τη ζωντάνια των δοκιμών με βάση την αρχή ότι η Kubernetes μπορεί να το κάνει, οπότε θα το χρησιμοποιήσουμε. Κατά συνέπεια, σε κάποιο σημείο ο Mongo έγινε λίγο «βαρετός» και το δείγμα άρχισε να αποτυγχάνει. Κατά συνέπεια, σύμφωνα με τη δοκιμή βροχόπτωσης, οι λοβοί άρχισαν να «σκοτώνουν».
Όπως καταλαβαίνετε, όταν "σκοτώνονται", αυτό είναι μια συνομιλία, δηλαδή, υπάρχουν πολλές συνδέσεις από πελάτες που κρέμονται από αυτό. Επίσης "σκοτώνονται" - όχι, όχι πελάτες, μόνο συνδέσεις - όχι όλοι ταυτόχρονα, και λόγω του ότι δεν σκοτώνονται την ίδια στιγμή, άλλοι νωρίτερα, άλλοι αργότερα, δεν ξεκινούν την ίδια στιγμή χρόνος. Συν το τυπικό τυχαίο, δεν μπορούμε να προβλέψουμε με ακρίβεια χιλιοστού του δευτερολέπτου την ώρα έναρξης της εφαρμογής κάθε φορά, οπότε το κάνουν μία φορά τη φορά. Ένα infospot ανεβαίνει, προστίθεται στην εξισορρόπηση, όλοι οι πελάτες έρχονται εκεί, δεν μπορεί να αντέξει τέτοιο φορτίο, γιατί είναι μόνος του, και, χοντρικά, δουλεύουν εκεί καμιά δεκαριά, και πέφτει. Ο επόμενος σηκώνεται, όλο το φορτίο είναι πάνω του, πέφτει κι αυτός. Λοιπόν, αυτές οι πτώσεις απλώς συνεχίζουν να καταρράνονται. Στο τέλος, πώς λύθηκε αυτό - έπρεπε απλώς να σταματήσουμε αυστηρά την επισκεψιμότητα των χρηστών σε αυτήν την εφαρμογή, να αφήσουμε όλες τις παρουσίες να αυξηθούν και στη συνέχεια να ξεκινήσουμε όλη την επισκεψιμότητα των χρηστών ταυτόχρονα, έτσι ώστε να έχει ήδη κατανεμηθεί και στις δέκα περιπτώσεις.
Αν δεν είχε ανακοινωθεί αυτό το τεστ ζωντάνιας, το οποίο θα ανάγκαζε όλα να επανεκκινήσουν, η εφαρμογή θα το είχε χειριστεί μια χαρά. Αλλά τα πάντα από την εξισορρόπηση είναι απενεργοποιημένα για εμάς, επειδή οι βάσεις δεδομένων είναι απρόσιτες και όλοι οι χρήστες έχουν «πέσει». Στη συνέχεια, όταν αυτή η βάση δεδομένων γίνει διαθέσιμη, τα πάντα περιλαμβάνονται στην εξισορρόπηση, αλλά οι εφαρμογές δεν χρειάζεται να ξεκινήσουν ξανά και δεν χρειάζεται να χάνετε χρόνο και πόρους για αυτό. Είναι όλοι ήδη εδώ, είναι έτοιμοι για κυκλοφορία, οπότε η κυκλοφορία μόλις ανοίγει, όλα είναι καλά - η εφαρμογή είναι στη θέση της, όλα συνεχίζουν να λειτουργούν.
Επομένως, τα τεστ ετοιμότητας και ζωντάνιας είναι διαφορετικά, ακόμη και επιπλέον, μπορείτε θεωρητικά να κάνετε διαφορετικούς ελέγχους υγείας, έναν τύπο ακτίνων, έναν τύπο liv, για παράδειγμα, και να ελέγξετε διαφορετικά πράγματα. Κατά τη διάρκεια των δοκιμών ετοιμότητας, ελέγξτε τα backend σας. Και σε ένα τεστ ζωντάνιας, για παράδειγμα, δεν ελέγχετε από την άποψη ότι το τεστ ζωντανότητας είναι γενικά απλώς μια εφαρμογή που ανταποκρίνεται, εάν είναι σε θέση να ανταποκριθεί καθόλου.
Γιατί το τεστ ζωντάνιας, σε γενικές γραμμές, είναι όταν είμαστε «κολλημένοι». Ένας ατελείωτος βρόχος έχει ξεκινήσει ή κάτι άλλο - και δεν διεκπεραιώνονται άλλα αιτήματα. Επομένως, είναι λογικό ακόμη και να τα χωρίσουμε - και να εφαρμόσουμε διαφορετική λογική σε αυτά.
Σχετικά με το τι πρέπει να απαντήσετε όταν κάνετε τεστ, όταν κάνετε υγειονομικούς ελέγχους. Είναι απλά ένας πόνος. Όσοι είναι εξοικειωμένοι με αυτό πιθανότατα θα γελάσουν - αλλά σοβαρά, έχω δει υπηρεσίες στη ζωή μου που απαντούν "200" στο XNUMX% των περιπτώσεων. Δηλαδή ποιος είναι πετυχημένος. Ταυτόχρονα όμως στο σώμα της απάντησης γράφουν «έτσι και τέτοιο λάθος».
Δηλαδή, η κατάσταση απόκρισης έρχεται σε εσάς - όλα είναι επιτυχημένα. Αλλά ταυτόχρονα, πρέπει να αναλύσετε το σώμα, επειδή το σώμα λέει "συγγνώμη, το αίτημα έληξε με σφάλμα" και αυτό είναι απλώς πραγματικότητα. Αυτό το είδα στην πραγματική ζωή.
Και έτσι ώστε κάποιοι να μην το βρίσκουν αστείο και άλλοι να το βρίσκουν πολύ οδυνηρό, αξίζει ακόμα να τηρείτε έναν απλό κανόνα. Σε υγειονομικούς ελέγχους και κατ' αρχήν κατά την εργασία με διαδικτυακές εφαρμογές.
Αν όλα πήγαν καλά, τότε απαντήστε με τη διακοστή απάντηση. Καταρχήν, οποιαδήποτε απάντηση διακοσιοστών θα σας ταιριάζει. Αν διαβάζετε πολύ καλά το κουρελιασμένο και γνωρίζετε ότι ορισμένες καταστάσεις απαντήσεων διαφέρουν από άλλες, απαντήστε με τις κατάλληλες: 204, 5, 10, 15, οτιδήποτε. Εάν δεν είναι πολύ καλό, τότε απλώς «δύο μηδέν μηδέν». Αν όλα πάνε άσχημα και ο υγειονομικός έλεγχος δεν ανταποκρίνεται, τότε απαντήστε με οποιοδήποτε πεντακοσιάρικο. Και πάλι, εάν καταλαβαίνετε πώς να απαντήσετε, πόσο διαφορετικές καταστάσεις απόκρισης διαφέρουν μεταξύ τους. Εάν δεν καταλαβαίνετε, τότε το 502 είναι η επιλογή σας για να απαντήσετε σε υγειονομικούς ελέγχους εάν κάτι πάει στραβά.
Αυτό είναι ένα άλλο σημείο, θέλω να επανέλθω λίγο σχετικά με τον έλεγχο των υποκείμενων υπηρεσιών. Εάν ξεκινήσετε, για παράδειγμα, να ελέγχετε όλες τις υποκείμενες υπηρεσίες που βρίσκονται πίσω από την αίτησή σας - τα πάντα γενικά. Αυτό που παίρνουμε από την άποψη της αρχιτεκτονικής μικροϋπηρεσιών, έχουμε μια τέτοια έννοια όπως "χαμηλή σύζευξη" - δηλαδή όταν οι υπηρεσίες σας εξαρτώνται ελάχιστα η μία από την άλλη. Εάν ένα από αυτά αποτύχει, όλα τα άλλα χωρίς αυτήν τη λειτουργία θα συνεχίσουν απλώς να λειτουργούν. Μερικές από τις λειτουργίες απλώς δεν λειτουργούν. Αντίστοιχα, αν συνδέσετε όλους τους υγειονομικούς ελέγχους μεταξύ τους, τότε θα καταλήξετε να πέσει ένα πράγμα στην υποδομή, και επειδή έπεσε, όλοι οι υγειονομικοί έλεγχοι όλων των υπηρεσιών αρχίζουν επίσης να αποτυγχάνουν - και γενικά υπάρχει περισσότερη υποδομή για την ολόκληρη η αρχιτεκτονική microservice Αρ. Όλα σκοτεινιάστηκαν εκεί.
Επομένως, θέλω να το επαναλάβω ξανά ότι πρέπει να ελέγξετε τις υποκείμενες υπηρεσίες, αυτές χωρίς τις οποίες η αίτησή σας σε εκατό τοις εκατό δεν μπορεί να κάνει τη δουλειά της. Δηλαδή, είναι λογικό ότι εάν έχετε ένα REST API μέσω του οποίου ο χρήστης αποθηκεύει στη βάση δεδομένων ή ανακτά από τη βάση δεδομένων, τότε ελλείψει βάσης δεδομένων, δεν μπορείτε να εγγυηθείτε ότι θα εργαστείτε με τους χρήστες σας.
Αλλά εάν οι χρήστες σας, όταν τους αφαιρείτε από τη βάση δεδομένων, εμπλουτίζονται επιπλέον με κάποια άλλα μεταδεδομένα, από άλλο backend, τα οποία εισάγετε πριν στείλετε μια απάντηση στο frontend - και αυτό το backend δεν είναι διαθέσιμο, αυτό σημαίνει ότι δίνετε απάντηση χωρίς κανένα μέρος των μεταδεδομένων.
Στη συνέχεια, έχουμε επίσης ένα από τα οδυνηρά ζητήματα κατά την εκκίνηση εφαρμογών.
Στην πραγματικότητα, αυτό δεν ισχύει μόνο για το Kubernetes σε γενικές γραμμές· συνέβη ότι η κουλτούρα κάποιου είδους μαζικής ανάπτυξης και ειδικότερα τα DevOps άρχισε να διαδίδεται περίπου την ίδια εποχή με το Kubernetes. Επομένως, σε γενικές γραμμές, αποδεικνύεται ότι πρέπει να κλείσετε με χάρη την εφαρμογή σας χωρίς Kubernetes. Ακόμη και πριν από το Kubernetes, οι άνθρωποι το έκαναν αυτό, αλλά με την έλευση του Kubernetes, αρχίσαμε να μιλάμε για αυτό μαζικά.
Χαριτωμένος τερματισμός λειτουργίας
Γενικά, τι είναι το Graceful Shutdown και γιατί χρειάζεται; Αυτό είναι όταν η εφαρμογή σας διακόπτεται για κάποιο λόγο, πρέπει να το κάνετε app stop - ή λαμβάνετε, για παράδειγμα, ένα σήμα από το λειτουργικό σύστημα, η εφαρμογή σας πρέπει να το κατανοήσει και να κάνει κάτι γι' αυτό. Το χειρότερο σενάριο, φυσικά, είναι όταν η αίτησή σας λάβει ένα SIGTERM και είναι σαν "SIGTERM, ας περιμένουμε, δουλέψτε, μην κάνετε τίποτα". Αυτή είναι μια εντελώς κακή επιλογή.
Μια σχεδόν εξίσου κακή επιλογή είναι όταν η εφαρμογή σας λαμβάνει ένα SIGTERM και είναι όπως "είπαν segterm, αυτό σημαίνει ότι τελειώνουμε, δεν έχω δει, δεν ξέρω κανένα αίτημα χρήστη, δεν ξέρω τι είδους αιτήματα που εργάζομαι αυτή τη στιγμή, είπαν SIGTERM, αυτό σημαίνει ότι τελειώνουμε " Αυτή είναι επίσης μια κακή επιλογή.
Ποια επιλογή είναι καλή; Το πρώτο σημείο είναι να ληφθεί υπόψη η ολοκλήρωση των εργασιών. Μια καλή επιλογή είναι ο διακομιστής σας να εξακολουθεί να λαμβάνει υπόψη τι κάνει εάν λάβει SIGTERM.
Το SIGTERM είναι ένα soft shutdown, είναι ειδικά σχεδιασμένο, μπορεί να υποκλαπεί σε επίπεδο κώδικα, μπορεί να υποβληθεί σε επεξεργασία, πείτε ότι τώρα, περιμένετε, πρώτα θα τελειώσουμε τη δουλειά που έχουμε, μετά θα βγούμε.
Από την οπτική γωνία του Kubernetes, έτσι φαίνεται. Όταν λέμε σε ένα pod που εκτελείται στο σύμπλεγμα Kubernetes, "παρακαλώ σταματήστε, φύγετε" ή κάνουμε επανεκκίνηση ή πραγματοποιείται ενημέρωση όταν το Kubernetes αναδημιουργεί τα pod, το Kubernetes στέλνει ακριβώς το ίδιο μήνυμα SIGTERM στο pod, περιμένει κάποια στιγμή, και , αυτή είναι η ώρα που περιμένει, είναι επίσης ρυθμισμένη, υπάρχει μια τέτοια ειδική παράμετρος στα διπλώματα και ονομάζεται Graceful ShutdownTimeout. Όπως καταλαβαίνετε, δεν λέγεται έτσι για τίποτα, και δεν είναι άσκοπο που το συζητάμε τώρα.
Εκεί μπορούμε να πούμε συγκεκριμένα πόσο καιρό πρέπει να περιμένουμε από τη στιγμή που θα στείλουμε το SIGTERM στην εφαρμογή και όταν καταλάβουμε ότι η εφαρμογή φαίνεται να έχει τρελαθεί για κάτι ή έχει «κολλήσει» και δεν πρόκειται να τελειώσει - και πρέπει να στείλε το SIGKILL, δηλαδή σκληρά ολοκλήρωσε τη δουλειά του. Δηλαδή, κατά συνέπεια, έχουμε κάποιο είδος δαίμονα που τρέχει, επεξεργάζεται λειτουργίες. Κατανοούμε ότι κατά μέσο όρο οι λειτουργίες μας στις οποίες δουλεύει ο δαίμονας δεν διαρκούν περισσότερο από 30 δευτερόλεπτα τη φορά. Κατά συνέπεια, όταν φτάσει το SIGTERM, καταλαβαίνουμε ότι ο δαίμονάς μας μπορεί, το πολύ, να τερματίσει 30 δευτερόλεπτα μετά το SIGTERM. Το γράφουμε, για παράδειγμα, 45 δευτερόλεπτα για κάθε ενδεχόμενο και λέμε ότι SIGTERM. Μετά από αυτό περιμένουμε 45 δευτερόλεπτα. Θεωρητικά, σε αυτό το διάστημα ο δαίμονας θα έπρεπε να είχε ολοκληρώσει το έργο του και να είχε τελειώσει μόνος του. Αλλά αν ξαφνικά δεν μπορούσε, σημαίνει ότι πιθανότατα έχει κολλήσει—δεν επεξεργάζεται πλέον κανονικά τα αιτήματά μας. Και σε 45 δευτερόλεπτα μπορείτε να τον καρφώσετε με ασφάλεια.
Και εδώ, μάλιστα, μπορούν να ληφθούν υπόψη ακόμη και 2 πτυχές. Πρώτον, κατανοήστε ότι εάν λάβατε ένα αίτημα, αρχίσατε να εργάζεστε με αυτό με κάποιο τρόπο και δεν απαντήσατε στον χρήστη, αλλά λάβατε το SIGTERM, για παράδειγμα. Είναι λογικό να το τελειοποιήσουμε και να απαντήσουμε στον χρήστη. Αυτό είναι το νούμερο ένα σημείο από αυτή την άποψη. Το δεύτερο σημείο εδώ είναι ότι εάν γράψετε τη δική σας εφαρμογή, γενικά χτίσετε την αρχιτεκτονική με τέτοιο τρόπο ώστε να λαμβάνετε ένα αίτημα για την εφαρμογή σας, τότε ξεκινάτε δουλειά, ξεκινάτε να κατεβάζετε αρχεία από κάπου, να κατεβάζετε μια βάση δεδομένων και οτιδήποτε άλλο. - Οτι. Σε γενικές γραμμές, ο χρήστης σας, το αίτημά σας μένει για μισή ώρα και περιμένει να του απαντήσετε - τότε, πιθανότατα, πρέπει να εργαστείτε στην αρχιτεκτονική. Δηλαδή, απλά λάβετε υπόψη ακόμη και την κοινή λογική ότι εάν οι λειτουργίες σας είναι σύντομες, τότε είναι λογικό να αγνοήσετε το SIGTERM και να το τροποποιήσετε. Εάν οι λειτουργίες σας είναι μεγάλες, τότε δεν έχει νόημα να αγνοήσετε το SIGTERM σε αυτήν την περίπτωση. Είναι λογικό να επανασχεδιαστεί η αρχιτεκτονική για να αποφευχθούν τόσο μεγάλες εργασίες. Για να μην περιμένουν απλώς οι χρήστες. Δεν ξέρω, φτιάξτε κάποιο είδος websocket εκεί, κάντε reverse hook που ο διακομιστής σας θα στείλει ήδη στον πελάτη, οτιδήποτε άλλο, αλλά μην αναγκάζετε τον χρήστη να κολλήσει για μισή ώρα και απλώς να περιμένετε για μια περίοδο λειτουργίας μέχρι να απαντήστε του. Γιατί είναι απρόβλεπτο πού μπορεί να σπάσει.
Όταν η αίτησή σας τερματιστεί, θα πρέπει να δώσετε κάποιον κατάλληλο κωδικό εξόδου. Δηλαδή, εάν η εφαρμογή σας ζητήθηκε να κλείσει, να σταματήσει και ήταν σε θέση να σταματήσει κανονικά, τότε δεν χρειάζεται να επιστρέψετε κάποιο είδος κωδικού εξόδου 1,5,255 και ούτω καθεξής. Οτιδήποτε δεν είναι μηδενικός κώδικας, τουλάχιστον σε συστήματα Linux, είμαι σίγουρος γι' αυτό, θεωρείται ανεπιτυχές. Δηλαδή, θεωρείται ότι η αίτησή σας σε αυτή την περίπτωση έληξε με λάθος. Αντίστοιχα, με φιλικό τρόπο, εάν η αίτησή σας ολοκληρώθηκε χωρίς σφάλμα, λέτε 0 στην έξοδο. Εάν η αίτησή σας αποτύχει για κάποιο λόγο, λέτε non-0 στην έξοδο. Και μπορείτε να εργαστείτε με αυτές τις πληροφορίες.
Και η τελευταία επιλογή. Είναι κακό όταν ο χρήστης σας στέλνει ένα αίτημα και κολλάει για μισή ώρα ενώ το επεξεργάζεστε. Αλλά γενικά, θα ήθελα επίσης να πω για το τι αξίζει γενικά από την πλευρά του πελάτη. Δεν έχει σημασία αν έχετε εφαρμογή για κινητά, front-end κ.λπ. Είναι απαραίτητο να ληφθεί υπόψη ότι γενικά η συνεδρία του χρήστη μπορεί να τερματιστεί, οτιδήποτε μπορεί να συμβεί. Ένα αίτημα μπορεί να σταλεί, για παράδειγμα, να υποβληθεί σε υποεπεξεργασία και να μην επιστραφεί απάντηση. Το frontend σας ή η εφαρμογή σας για κινητά - οποιαδήποτε διεπαφή γενικά, ας το πούμε έτσι - θα πρέπει να το λαμβάνει υπόψη. Εάν εργάζεστε με υποδοχές ιστού, αυτός είναι γενικά ο χειρότερος πόνος που είχα ποτέ.
Όταν οι προγραμματιστές κάποιων τακτικών συνομιλιών δεν γνωρίζουν ότι, αποδεικνύεται, η διαδικτυακή πρίζα μπορεί να σπάσει. Για αυτούς, όταν συμβαίνει κάτι στο διακομιστή μεσολάβησης, απλώς αλλάζουμε τη διαμόρφωση και κάνει επαναφόρτωση. Φυσικά, όλες οι μακροχρόνιες συνεδρίες είναι κουρασμένες σε αυτή την περίπτωση. Οι προγραμματιστές έρχονται τρέχοντας κοντά μας και λένε: "Παιδιά, τι κάνετε, η συνομιλία χάλασε για όλους τους πελάτες μας!" Τους λέμε: «Τι κάνετε; Δεν μπορούν οι πελάτες σας να επανασυνδεθούν; Λένε: «Όχι, χρειαζόμαστε να μην σκίζονται οι συνεδρίες». Εν ολίγοις, αυτό είναι πραγματικά ανοησία. Πρέπει να ληφθεί υπόψη η πλευρά του πελάτη. Ειδικά, όπως λέω, με μακράς διάρκειας περιόδους σύνδεσης, όπως οι υποδοχές ιστού, μπορεί να σπάσει και, απαρατήρητο από τον χρήστη, πρέπει να μπορείτε να εγκαταστήσετε ξανά τέτοιες συνεδρίες. Και τότε όλα είναι τέλεια.
Πόροι
Στην πραγματικότητα, εδώ θα σας πω μόνο μια ευθεία ιστορία. Και πάλι από την πραγματική ζωή. Το πιο άρρωστο πράγμα που έχω ακούσει ποτέ για τους πόρους.
Πόροι σε αυτήν την περίπτωση, εννοώ, κάποιου είδους αιτήματα, όρια που μπορείτε να βάλετε σε pods στα συμπλέγματά σας Kubernetes. Το πιο αστείο πράγμα που άκουσα από έναν προγραμματιστή... Ένας από τους συναδέλφους μου προγραμματιστές σε προηγούμενο χώρο εργασίας είπε κάποτε: "Η εφαρμογή μου δεν θα ξεκινήσει στο σύμπλεγμα." Κοίταξα να δω ότι δεν ξεκινούσε, αλλά είτε δεν ταίριαζε στους πόρους είτε είχαν θέσει πολύ μικρά όρια. Εν ολίγοις, η εφαρμογή δεν μπορεί να ξεκινήσει λόγω πόρων. Λέω: «Δεν θα ξεκινήσει λόγω πόρων, εσείς αποφασίζετε πόσα χρειάζεστε και ορίζετε μια επαρκή τιμή». Λέει: «Τι είδους πόροι;» Άρχισα να του εξηγώ ότι πρέπει να τεθούν Kubernetes, όρια στα αιτήματα και μπλα, μπλα, μπλα. Ο άντρας άκουσε για πέντε λεπτά, έγνεψε καταφατικά και είπε: «Ήρθα εδώ για να δουλέψω ως προγραμματιστής, δεν θέλω να μάθω τίποτα για πόρους. Ήρθα εδώ για να γράψω κώδικα και αυτό είναι». Είναι λυπηρό. Αυτή είναι μια πολύ θλιβερή ιδέα από τη σκοπιά ενός προγραμματιστή. Ειδικά στον σύγχρονο κόσμο, θα λέγαμε, των προοδευτικών devops.
Γιατί χρειάζονται καθόλου πόροι; Υπάρχουν 2 τύποι πόρων στο Kubernetes. Κάποια ονομάζονται αιτήματα, άλλα ονομάζονται όρια. Με πόρους θα καταλάβουμε ότι βασικά υπάρχουν πάντα μόνο δύο βασικοί περιορισμοί. Δηλαδή, χρονικά όρια CPU και όρια RAM για ένα κοντέινερ που τρέχει στο Kubernetes.
Ένα όριο θέτει ένα ανώτατο όριο στον τρόπο χρήσης ενός πόρου στην εφαρμογή σας. Δηλαδή, αν πείτε 1 GB RAM στα όρια, τότε η εφαρμογή σας δεν θα μπορεί να χρησιμοποιήσει περισσότερο από 1 GB RAM. Και αν ξαφνικά θέλει και προσπαθήσει να το κάνει αυτό, τότε μια διαδικασία που ονομάζεται oom killer, εκτός μνήμης, δηλαδή, θα έρθει και θα σκοτώσει την εφαρμογή σας - δηλαδή, απλά θα επανεκκινήσει. Οι εφαρμογές δεν θα επανεκκινήσουν με βάση την CPU. Όσον αφορά την CPU, εάν μια εφαρμογή προσπαθήσει να χρησιμοποιήσει πολλά, περισσότερα από αυτά που καθορίζονται στα όρια, η CPU απλώς θα επιλεγεί αυστηρά. Αυτό δεν οδηγεί σε επανεκκίνηση. Αυτό είναι το όριο - αυτό είναι το ανώτερο όριο.
Και υπάρχει ένα αίτημα. Ένα αίτημα είναι πώς το Kubernetes κατανοεί πώς οι κόμβοι στο σύμπλεγμα Kubernetes γεμίζονται με εφαρμογές. Δηλαδή, ένα αίτημα είναι ένα είδος δέσμευσης της αίτησής σας. Λέει τι θέλω να χρησιμοποιήσω: "Θα ήθελα να κρατήσετε τόσο CPU και τόση μνήμη για μένα." Μια τόσο απλή αναλογία. Τι γίνεται αν έχουμε έναν κόμβο που έχει, δεν ξέρω, 8 CPU συνολικά. Και ένα pod φτάνει εκεί, του οποίου τα αιτήματα λένε 1 CPU, που σημαίνει ότι ο κόμβος έχει 7 CPUs. Δηλαδή, κατά συνέπεια, μόλις φτάσουν 8 pods σε αυτόν τον κόμβο, καθένα από τα οποία έχει 1 CPU στα αιτήματά του, ο κόμβος, σαν από την άποψη του Kubernetes, έχει τελειώσει από CPU και δεν μπορούν να γίνουν περισσότερα pods με αιτήματα. εκτοξεύτηκε σε αυτόν τον κόμβο. Εάν όλοι οι κόμβοι εξαντληθούν από CPU, τότε το Kubernetes θα αρχίσει να λέει ότι δεν υπάρχουν κατάλληλοι κόμβοι στο σύμπλεγμα για να τρέξουν τα pod σας επειδή η CPU έχει εξαντληθεί.
Γιατί χρειάζονται αιτήματα και γιατί χωρίς αιτήματα, νομίζω ότι δεν χρειάζεται να ξεκινήσει κάτι στο Kubernetes; Ας φανταστούμε μια υποθετική κατάσταση. Εκκινείτε την εφαρμογή σας χωρίς αιτήματα, η Kubernetes δεν ξέρει πόσα από αυτά που έχετε, σε ποιους κόμβους μπορείτε να την ωθήσετε. Λοιπόν, σπρώχνει, σπρώχνει, σπρώχνει στους κόμβους. Κάποια στιγμή, θα αρχίσετε να λαμβάνετε επισκεψιμότητα στην εφαρμογή σας. Και μια από τις εφαρμογές αρχίζει ξαφνικά να χρησιμοποιεί πόρους μέχρι τα όρια που έχει σύμφωνα με τα όρια. Αποδεικνύεται ότι υπάρχει μια άλλη εφαρμογή κοντά και χρειάζεται επίσης πόρους. Ο κόμβος αρχίζει στην πραγματικότητα να εξαντλείται από πόρους, για παράδειγμα, OP. Ο κόμβος αρχίζει στην πραγματικότητα να εξαντλείται από πόρους, για παράδειγμα, μνήμη τυχαίας πρόσβασης (RAM). Όταν εξαντληθεί η ισχύς ενός κόμβου, πρώτα από όλα το docker θα σταματήσει να ανταποκρίνεται, μετά το cubelet και μετά το λειτουργικό σύστημα. Απλώς θα χάσουν τις αισθήσεις τους και οπωσδήποτε ΟΛΑ θα σταματήσουν να λειτουργούν για εσάς. Δηλαδή, αυτό θα οδηγήσει στο να κολλήσει ο κόμβος σας και θα χρειαστεί να τον επανεκκινήσετε. Με λίγα λόγια, η κατάσταση δεν είναι πολύ καλή.
Και όταν έχετε αιτήματα, τα όρια δεν είναι πολύ διαφορετικά, τουλάχιστον όχι πολλές φορές περισσότερα από τα όρια ή τα αιτήματα, τότε μπορείτε να έχετε μια τέτοια κανονική, ορθολογική πλήρωση εφαρμογών στους κόμβους των συμπλεγμάτων Kubernetes. Ταυτόχρονα, η Kubernetes γνωρίζει περίπου πόσα από αυτά που τοποθετεί πού, πόσα από αυτά πού χρησιμοποιείται. Δηλαδή, είναι ακριβώς μια τέτοια στιγμή. Είναι σημαντικό να το κατανοήσουμε. Και είναι σημαντικό να ελέγξετε ότι αυτό υποδεικνύεται.
Αποθήκευση δεδομένων
Το επόμενο σημείο μας αφορά την αποθήκευση δεδομένων. Τι να τους κάνεις και γενικά τι να κάνεις με την επιμονή στο Kubernetes;
Νομίζω, πάλι, μέσα μας , υπήρχε ένα θέμα σχετικά με τη βάση δεδομένων στο Kubernetes. Και μου φαίνεται ότι ξέρω ακόμη και κατά προσέγγιση τι σας είπαν οι συνάδελφοί σας όταν ρωτήθηκαν: "Είναι δυνατόν να τρέξετε μια βάση δεδομένων στο Kubernetes;" Για κάποιο λόγο, μου φαίνεται ότι οι συνάδελφοί σας θα έπρεπε να σας είχαν πει ότι εάν ρωτάτε εάν είναι δυνατόν να τρέξετε μια βάση δεδομένων στο Kubernetes, τότε είναι αδύνατο.
Η λογική εδώ είναι απλή. Σε κάθε περίπτωση, θα σας εξηγήσω άλλη μια φορά, εάν είστε ένας πολύ καλός τύπος που μπορεί να δημιουργήσει ένα αρκετά ανεκτικό σύστημα αποθήκευσης δικτύου, κατανοήστε πώς να τοποθετήσετε μια βάση δεδομένων σε αυτήν την περίπτωση, πώς θα πρέπει να λειτουργεί το cloud native in containers σε μια βάση δεδομένων γενικά. Πιθανότατα, δεν έχετε καμία ερώτηση για το πώς να το εκτελέσετε. Εάν έχετε μια τέτοια ερώτηση, και θέλετε να βεβαιωθείτε ότι όλα ξεδιπλώνονται και στέκονται μέχρι θανάτου στην παραγωγή και δεν πέφτουν ποτέ, τότε αυτό δεν συμβαίνει. Είναι σίγουρο ότι θα πυροβολήσετε τον εαυτό σας στο πόδι με αυτήν την προσέγγιση. Οπότε καλύτερα να μην το κάνεις.
Τι πρέπει να κάνουμε με τα δεδομένα που θα ήθελε να αποθηκεύσει η εφαρμογή μας, κάποιες εικόνες που ανεβάζουν οι χρήστες, κάποια πράγματα που δημιουργεί η εφαρμογή μας κατά τη λειτουργία της, για παράδειγμα κατά την εκκίνηση; Τι να κάνετε μαζί τους στο Kubernetes;
Σε γενικές γραμμές, ιδανικά, ναι, φυσικά, το Kubernetes είναι πολύ καλά σχεδιασμένο και γενικά σχεδιάστηκε αρχικά για εφαρμογές ανιθαγενών. Δηλαδή για εκείνες τις εφαρμογές που δεν αποθηκεύουν καθόλου πληροφορίες. Αυτό είναι ιδανικό.
Αλλά, φυσικά, η ιδανική επιλογή δεν υπάρχει πάντα. Και λοιπόν? Το πρώτο και απλούστερο σημείο είναι να πάρετε κάποιο είδος S3, απλώς όχι σπιτικό, το οποίο επίσης δεν είναι ξεκάθαρο πώς λειτουργεί, αλλά από κάποιον πάροχο. Ένας καλός, κανονικός πάροχος - και διδάξτε την εφαρμογή σας να χρησιμοποιεί το S3. Δηλαδή, όταν ο χρήστης σας θέλει να ανεβάσει ένα αρχείο, πείτε "εδώ, παρακαλώ, μεταφορτώστε το στο S3". Όταν θέλει να το λάβει, πείτε: "Εδώ είναι ένας σύνδεσμος για το S3 πίσω και πάρτε το από εδώ." Αυτό είναι ιδανικό.
Εάν ξαφνικά για κάποιο λόγο αυτή η ιδανική επιλογή δεν είναι κατάλληλη, έχετε μια εφαρμογή που δεν γράψατε, δεν αναπτύξατε ή είναι κάποιου είδους τρομερή κληρονομιά, δεν μπορεί να χρησιμοποιήσει το πρωτόκολλο S3, αλλά πρέπει να συνεργαστεί με τοπικούς καταλόγους στο τοπικούς φακέλους. Πάρτε κάτι περισσότερο ή λιγότερο απλό, αναπτύξτε το Kubernetes. Δηλαδή το να περιφράξεις αμέσως τον Κεφ για κάποιες ελάχιστες εργασίες, μου φαίνεται, είναι κακή ιδέα. Γιατί ο Ceph, φυσικά, είναι καλός και μοδάτος. Αλλά αν δεν καταλαβαίνετε πραγματικά τι κάνετε, τότε μόλις βάλετε κάτι στον Ceph, μπορείτε πολύ εύκολα και απλά να μην το βγάλετε ποτέ ξανά από εκεί. Επειδή, όπως γνωρίζετε, το Ceph αποθηκεύει δεδομένα στο cluster του σε δυαδική μορφή και όχι με τη μορφή απλών αρχείων. Επομένως, εάν ξαφνικά χαλάσει το σύμπλεγμα Ceph, τότε υπάρχει πλήρης και μεγάλη πιθανότητα να μην λάβετε ποτέ ξανά τα δεδομένα σας από εκεί.
Θα έχουμε ένα μάθημα για τον Κεφ, μπορείτε .
Επομένως, είναι καλύτερο να κάνετε κάτι απλό όπως ένας διακομιστής NFS. Το Kubernetes μπορεί να συνεργαστεί μαζί τους, μπορείτε να προσαρτήσετε έναν κατάλογο σε έναν διακομιστή NFS - η εφαρμογή σας είναι ακριβώς όπως ένας τοπικός κατάλογος. Ταυτόχρονα, φυσικά, πρέπει να καταλάβετε ότι, πάλι, πρέπει να κάνετε κάτι με το NFS σας, πρέπει να καταλάβετε ότι μερικές φορές μπορεί να γίνει απρόσιτο και να εξετάσετε το ερώτημα τι θα κάνετε σε αυτήν την περίπτωση. Ίσως θα έπρεπε να δημιουργηθεί αντίγραφο ασφαλείας κάπου σε ξεχωριστό μηχάνημα.
Το επόμενο σημείο για το οποίο μίλησα είναι τι πρέπει να κάνετε εάν η εφαρμογή σας δημιουργεί ορισμένα αρχεία κατά τη λειτουργία. Για παράδειγμα, όταν ξεκινά, δημιουργεί κάποιο στατικό αρχείο, το οποίο βασίζεται σε ορισμένες πληροφορίες που λαμβάνει η εφαρμογή μόνο κατά την εκκίνηση. Τι στιγμή. Εάν δεν υπάρχουν πολλά τέτοια δεδομένα, τότε δεν χρειάζεται να ασχοληθείτε καθόλου, απλώς εγκαταστήστε αυτήν την εφαρμογή για τον εαυτό σας και εργαστείτε. Το μόνο ερώτημα εδώ είναι τι, κοίτα. Πολύ συχνά, κάθε είδους παλαιού τύπου συστήματα, όπως το WordPress και ούτω καθεξής, ειδικά με τροποποιημένα κάποιου είδους έξυπνα πρόσθετα, έξυπνους προγραμματιστές PHP, συχνά ξέρουν πώς να το κάνουν έτσι ώστε να δημιουργούν κάποιο είδος αρχείου για τον εαυτό τους. Αντίστοιχα, το ένα δημιουργεί ένα αρχείο, το δεύτερο δημιουργεί ένα δεύτερο αρχείο. Είναι διαφορετικοί. Η εξισορρόπηση γίνεται στο σύμπλεγμα Kubernetes των πελατών απλά τυχαία. Κατά συνέπεια, αποδεικνύεται ότι δεν ξέρουν πώς να συνεργαστούν για παράδειγμα. Το ένα δίνει μια πληροφορία, το άλλο δίνει στο χρήστη άλλες πληροφορίες. Αυτό είναι κάτι που πρέπει να αποφύγετε. Δηλαδή, στο Kubernetes, όλα όσα εκκινείτε είναι εγγυημένα ότι μπορούν να λειτουργήσουν σε πολλές περιπτώσεις. Γιατί το Kubernetes είναι ένα συγκινητικό πράγμα. Αντίστοιχα, μπορεί να μετακινήσει οτιδήποτε, όποτε θέλει, χωρίς να ρωτήσει κανέναν απολύτως. Επομένως, πρέπει να βασιστείτε σε αυτό. Ό,τι εκκινείται σε μία περίπτωση αργά ή γρήγορα θα αποτύχει. Όσο περισσότερες κρατήσεις έχετε, τόσο το καλύτερο. Αλλά και πάλι, λέω, αν έχεις λίγα τέτοια αρχεία, τότε μπορείς να τα βάλεις ακριβώς από κάτω σου, ζυγίζουν λίγο. Εάν υπάρχουν λίγο περισσότερα από αυτά, μάλλον δεν πρέπει να τα σπρώξετε μέσα στο δοχείο.
Θα συμβούλευα ότι υπάρχει ένα τόσο υπέροχο πράγμα στο Kubernetes, μπορείτε να χρησιμοποιήσετε την ένταση. Συγκεκριμένα, υπάρχει ένας τόμος τύπου κενό σκην. Δηλαδή, απλώς το Kubernetes θα δημιουργήσει αυτόματα έναν κατάλογο στους καταλόγους υπηρεσιών του στον διακομιστή από τον οποίο ξεκινήσατε. Και θα σου το δώσει για να το χρησιμοποιήσεις. Υπάρχει μόνο ένα σημαντικό σημείο. Δηλαδή, τα δεδομένα σας δεν θα αποθηκευτούν μέσα στο κοντέινερ, αλλά στον κεντρικό υπολογιστή στον οποίο εκτελείτε. Επιπλέον, το Kubernetes μπορεί να ελέγξει τέτοια άδεια dir υπό κανονική διαμόρφωση και είναι σε θέση να ελέγχει το μέγιστο μέγεθός τους και να μην επιτρέπει την υπέρβασή του. Το μόνο σημείο είναι ότι αυτό που έχετε γράψει σε κενό dir δεν χάνεται κατά την επανεκκίνηση του pod. Δηλαδή, αν το pod σας πέσει κατά λάθος και ξανασηκωθεί, οι πληροφορίες στο άδειο dir δεν θα πάνε πουθενά. Μπορεί να το χρησιμοποιήσει ξανά σε μια νέα αρχή - και αυτό είναι καλό. Εάν το λοβό σας φύγει κάπου, τότε φυσικά θα φύγει χωρίς δεδομένα. Δηλαδή, μόλις εξαφανιστεί το pod από τον κόμβο όπου εκτοξεύτηκε με κενό dir, διαγράφεται το κενό dir.
Τι άλλο είναι καλό για το άδειο σκηνικό; Για παράδειγμα, μπορεί να χρησιμοποιηθεί ως προσωρινή μνήμη. Ας φανταστούμε ότι η εφαρμογή μας δημιουργεί κάτι εν κινήσει, το δίνει στους χρήστες και το κάνει για μεγάλο χρονικό διάστημα. Επομένως, η εφαρμογή, για παράδειγμα, τη δημιουργεί και τη δίνει στους χρήστες και ταυτόχρονα την αποθηκεύει κάπου, έτσι ώστε την επόμενη φορά που θα έρθει ο χρήστης για το ίδιο πράγμα, να είναι πιο γρήγορο να το δώσει αμέσως παραγόμενο. Το Empty dir μπορεί να ζητηθεί στον Kubernetes για δημιουργία στη μνήμη. Και έτσι, οι κρυφές μνήμες σας μπορούν γενικά να λειτουργούν με αστραπιαία ταχύτητα - όσον αφορά την ταχύτητα πρόσβασης στο δίσκο. Δηλαδή, έχετε ένα κενό dir στη μνήμη, στο λειτουργικό σύστημα είναι αποθηκευμένο στη μνήμη, αλλά για εσάς, για τον χρήστη μέσα στο pod, μοιάζει απλώς με έναν τοπικό κατάλογο. Δεν χρειάζεστε την εφαρμογή για να διδάξετε συγκεκριμένα κάποια μαγεία. Απλώς παίρνετε απευθείας και τοποθετείτε το αρχείο σας σε έναν κατάλογο, αλλά, στην πραγματικότητα, στη μνήμη του λειτουργικού συστήματος. Αυτό είναι επίσης ένα πολύ βολικό χαρακτηριστικό όσον αφορά το Kubernetes.
Τι προβλήματα έχει το Minio; Το βασικό πρόβλημα με το Minio είναι ότι για να λειτουργήσει αυτό το πράγμα πρέπει να τρέχει κάπου και να υπάρχει κάποιο σύστημα αρχείων, δηλαδή αποθήκευση. Και εδώ συναντάμε τα ίδια προβλήματα που έχει ο Κεφ. Δηλαδή το Minio πρέπει να αποθηκεύσει κάπου τα αρχεία του. Είναι απλώς μια διεπαφή HTTP για τα αρχεία σας. Επιπλέον, η λειτουργικότητα είναι σαφώς πιο φτωχή από αυτή του S3 της Amazon. Προηγουμένως, δεν ήταν σε θέση να εξουσιοδοτήσει σωστά τον χρήστη. Τώρα, από όσο γνωρίζω, μπορεί ήδη να δημιουργήσει κουβάδες με διαφορετικές εξουσιοδοτήσεις, αλλά και πάλι, μου φαίνεται ότι το κύριο πρόβλημα είναι, ας το πω έτσι, τουλάχιστον το υποκείμενο σύστημα αποθήκευσης.
Πώς επηρεάζει τα όρια το Empty dir στη μνήμη; Δεν επηρεάζει τα όρια με κανέναν τρόπο. Βρίσκεται στη μνήμη του οικοδεσπότη και όχι στη μνήμη του κοντέινερ σας. Δηλαδή, το κοντέινερ σας δεν βλέπει το κενό dir στη μνήμη ως μέρος της κατειλημμένης μνήμης του. Ο οικοδεσπότης το βλέπει αυτό. Αντίστοιχα, ναι, από τη σκοπιά του kubernetes, όταν αρχίσετε να το χρησιμοποιείτε, καλό θα ήταν να καταλάβετε ότι αφιερώνετε μέρος της μνήμης σας στο κενό σκην. Και κατά συνέπεια, κατανοήστε ότι η μνήμη μπορεί να εξαντληθεί όχι μόνο λόγω εφαρμογών, αλλά και επειδή κάποιος γράφει σε αυτές τις κενές διευθύνσεις.
νεφελότητα
Και το τελευταίο υποθέμα είναι τι είναι το Cloudnative. Γιατί χρειάζεται; Συννεφιά και ούτω καθεξής.
Όσες εφαρμογές δηλαδή είναι ικανές και γραμμένες ώστε να λειτουργούν σε μια σύγχρονη υποδομή cloud. Αλλά, στην πραγματικότητα, το Cloudnative έχει μια άλλη τέτοια πτυχή. Ότι αυτή δεν είναι μόνο μια εφαρμογή που λαμβάνει υπόψη όλες τις απαιτήσεις μιας σύγχρονης υποδομής cloud, αλλά ξέρει επίσης πώς να λειτουργεί με αυτήν τη σύγχρονη υποδομή cloud, εκμεταλλευτείτε τα πλεονεκτήματα και τα μειονεκτήματα του γεγονότος ότι λειτουργεί σε αυτά τα σύννεφα. Μην υπερβαίνετε απλώς και εργάζεστε στα σύννεφα, αλλά επωφεληθείτε από τα οφέλη της εργασίας στο cloud.
Ας πάρουμε απλώς το Kubernetes ως παράδειγμα. Η εφαρμογή σας εκτελείται στο Kubernetes. Η εφαρμογή σας μπορεί πάντα, ή μάλλον οι διαχειριστές της εφαρμογής σας, να μπορούν πάντα να δημιουργήσουν έναν λογαριασμό υπηρεσίας. Δηλαδή, έναν λογαριασμό για εξουσιοδότηση στο ίδιο το Kubernetes στον διακομιστή του. Προσθέστε κάποια δικαιώματα που χρειαζόμαστε εκεί. Και μπορείτε να αποκτήσετε πρόσβαση στο Kubernetes μέσα από την εφαρμογή σας. Τι μπορείτε να κάνετε με αυτόν τον τρόπο; Για παράδειγμα, από την εφαρμογή, λάβετε δεδομένα σχετικά με το πού βρίσκονται οι άλλες εφαρμογές σας, άλλα παρόμοια στιγμιότυπα και συγκεντρωθείτε μαζί με κάποιο τρόπο πάνω από το Kubernetes, εάν υπάρχει τέτοια ανάγκη.
Και πάλι, είχαμε κυριολεκτικά μια υπόθεση πρόσφατα. Έχουμε έναν ελεγκτή που παρακολουθεί την ουρά. Και όταν εμφανίζονται κάποιες νέες εργασίες σε αυτήν την ουρά, πηγαίνει στο Kubernetes - και μέσα στο Kubernetes δημιουργεί ένα νέο pod. Δίνει σε αυτό το pod κάποια νέα εργασία και μέσα στο πλαίσιο αυτού του pod, το pod εκτελεί την εργασία, στέλνει μια απάντηση στον ίδιο τον ελεγκτή και στη συνέχεια ο ελεγκτής κάνει κάτι με αυτές τις πληροφορίες. Για παράδειγμα, προσθέτει μια βάση δεδομένων. Δηλαδή, πάλι, αυτό είναι ένα συν του γεγονότος ότι η εφαρμογή μας εκτελείται στο Kubernetes. Μπορούμε να χρησιμοποιήσουμε την ίδια την ενσωματωμένη λειτουργικότητα του Kubernetes για να επεκτείνουμε με κάποιο τρόπο και να κάνουμε τη λειτουργικότητα της εφαρμογής μας πιο βολική. Δηλαδή, μην κρύβετε κάποιο είδος μαγείας για το πώς να ξεκινήσετε μια εφαρμογή, πώς να ξεκινήσετε έναν εργαζόμενο. Στο Kubernetes, στέλνετε απλώς ένα αίτημα στην εφαρμογή εάν η εφαρμογή είναι γραμμένη σε Python.
Το ίδιο ισχύει αν πάμε πέρα από το Kubernetes. Έχουμε τα Kubernetes μας να τρέχουν κάπου - είναι καλό αν είναι σε κάποιο είδος σύννεφου. Και πάλι, μπορούμε να χρησιμοποιήσουμε, και θα έπρεπε, πιστεύω, να χρησιμοποιήσουμε τις δυνατότητες του ίδιου του cloud όπου τρέχουμε. Από τα στοιχειώδη πράγματα που μας παρέχει το σύννεφο. Balance, δηλαδή, μπορούμε να δημιουργήσουμε cloud balancers και να τους χρησιμοποιήσουμε. Αυτό είναι ένα άμεσο πλεονέκτημα αυτού που μπορούμε να χρησιμοποιήσουμε. Επειδή η εξισορρόπηση του cloud, πρώτον, απλώς αφαιρεί βλακωδώς την ευθύνη από εμάς για το πώς λειτουργεί, πώς διαμορφώνεται. Επιπλέον, είναι πολύ βολικό, επειδή τα κανονικά Kubernetes μπορούν να ενσωματωθούν με τα σύννεφα.
Το ίδιο ισχύει και για την κλιμάκωση. Το κανονικό Kubernetes μπορεί να ενσωματωθεί με παρόχους cloud. Ξέρει πώς να κατανοήσει ότι εάν το σύμπλεγμα εξαντληθεί από κόμβους, δηλαδή ο χώρος του κόμβου έχει εξαντληθεί, τότε πρέπει να προσθέσετε - το ίδιο το Kubernetes θα προσθέσει νέους κόμβους στο σύμπλεγμα σας και θα ξεκινήσει να εκκινεί ομάδες σε αυτούς. Δηλαδή όταν έρθει το φορτίο σας αρχίζει να αυξάνεται ο αριθμός των εστιών. Όταν οι κόμβοι στο σύμπλεγμα εξαντληθούν για αυτές τις ομάδες, το Kubernetes εκκινεί νέους κόμβους και, κατά συνέπεια, ο αριθμός των ομάδων μπορεί ακόμα να αυξηθεί. Και είναι πολύ βολικό. Αυτή είναι μια άμεση ευκαιρία να κλιμακωθεί το σύμπλεγμα εν κινήσει. Όχι πολύ γρήγορα, με την έννοια ότι δεν είναι ένα δευτερόλεπτο, είναι περισσότερο σαν ένα λεπτό για να προσθέσετε νέους κόμβους.
Αλλά από την εμπειρία μου, πάλι, είναι ό,τι πιο ωραίο έχω δει ποτέ. Όταν το σύμπλεγμα Cloudnative κλιμακώθηκε με βάση την ώρα της ημέρας. Ήταν μια υπηρεσία υποστήριξης που χρησιμοποιήθηκε από άτομα στο back office. Δηλαδή, έρχονται στη δουλειά στις 9 π.μ., αρχίζουν να συνδέονται στο σύστημα και, κατά συνέπεια, το σύμπλεγμα Cloudnative, όπου εκτελούνται όλα, αρχίζει να διογκώνεται, ξεκινώντας νέα pods, ώστε όλοι όσοι έρχονται στη δουλειά να μπορούν να δουλέψουν με την εφαρμογή. Όταν φεύγουν από την εργασία τους στις 8 μ.μ. ή στις 6 μ.μ., τα συμπλέγματα Kubernetes παρατηρούν ότι κανείς δεν χρησιμοποιεί πλέον την εφαρμογή και αρχίζουν να συρρικνώνονται. Εξοικονόμηση έως και 30 τοις εκατό είναι εγγυημένη. Λειτουργούσε στο Amazon εκείνη την εποχή· εκείνη την εποχή δεν υπήρχε κανείς στη Ρωσία που να μπορούσε να το κάνει τόσο καλά.
Θα σας πω ευθέως, η εξοικονόμηση είναι 30 τοις εκατό απλώς και μόνο επειδή χρησιμοποιούμε Kubernetes και εκμεταλλευόμαστε τις δυνατότητες του cloud. Τώρα αυτό μπορεί να γίνει στη Ρωσία. Δεν θα κάνω διαφήμιση σε κανέναν, φυσικά, αλλά ας πούμε απλώς ότι υπάρχουν πάροχοι που μπορούν να το κάνουν αυτό, να το παρέχουν αμέσως με ένα κουμπί.
Υπάρχει ένα τελευταίο σημείο στο οποίο θα ήθελα επίσης να επιστήσω την προσοχή σας. Προκειμένου η εφαρμογή σας, η υποδομή σας να είναι Cloudnative, είναι λογικό να αρχίσετε επιτέλους να προσαρμόζετε την προσέγγιση που ονομάζεται Υποδομή ως Κώδικας. Δηλαδή, αυτό σημαίνει ότι η εφαρμογή σας, ή μάλλον η υποδομή σας, χρειάζεται ακριβώς με τον ίδιο τρόπο που κωδικός Περιγράψτε την αίτησή σας, τη λογική της επιχείρησής σας με τη μορφή κώδικα. Και δουλέψτε με αυτό ως κώδικα, δηλαδή δοκιμάστε το, αναπτύξτε το, αποθηκεύστε το στο git, εφαρμόστε το CICD σε αυτό.
Και αυτό ακριβώς σας επιτρέπει, πρώτον, να έχετε πάντα τον έλεγχο της υποδομής σας, να καταλαβαίνετε πάντα σε ποια κατάσταση βρίσκεται. Δεύτερον, αποφύγετε χειροκίνητες λειτουργίες που προκαλούν σφάλματα. Τρίτον, αποφύγετε απλώς αυτό που ονομάζεται κύκλος εργασιών, όταν χρειάζεται συνεχώς να εκτελείτε τις ίδιες χειροκίνητες εργασίες. Τέταρτον, σας επιτρέπει να ανακάμψετε πολύ πιο γρήγορα σε περίπτωση αποτυχίας. Στη Ρωσία, κάθε φορά που μιλάω για αυτό, υπάρχει πάντα ένας τεράστιος αριθμός ανθρώπων που λένε: «Ναι, είναι ξεκάθαρο, αλλά έχετε προσεγγίσεις, εν ολίγοις, δεν χρειάζεται να διορθώσετε τίποτα». Αλλά είναι αλήθεια. Εάν κάτι είναι χαλασμένο στην υποδομή σας, τότε από την άποψη της προσέγγισης Cloudnative και από την άποψη της Υποδομής ως Κώδικας, αντί να το διορθώσετε, να πάτε στον διακομιστή, να βρείτε τι έχει χαλάσει και να το διορθώσετε, είναι πιο εύκολο για να διαγράψετε τον διακομιστή και να τον δημιουργήσετε ξανά. Και όλα αυτά θα τα έχω αποκαταστήσει.
Όλα αυτά τα θέματα συζητούνται με περισσότερες λεπτομέρειες στο . Ακολουθώντας τον σύνδεσμο μπορείτε να εξοικειωθείτε με το πρόγραμμα και τις συνθήκες. Το βολικό είναι ότι μπορείτε να κατακτήσετε το Kubernetes μελετώντας από το σπίτι ή τη δουλειά για 1-2 ώρες την ημέρα.
Πηγή: www.habr.com