Προσδοκώντας Vitaly Khabarov συνέντευξη Ντμίτρι Στολιάροφ (), τεχνικός διευθυντής και συνιδρυτής της εταιρείας Flant. Ο Βιτάλι ρώτησε τον Ντμίτρι για το τι κάνει ο Φλαντ, για το Kubernetes, την ανάπτυξη του οικοσυστήματος, την υποστήριξη. Συζητήσαμε γιατί χρειάζεται το Kubernetes και αν χρειάζεται καθόλου. Και επίσης σχετικά με τις μικροϋπηρεσίες, το Amazon AWS, την προσέγγιση «Θα είμαι τυχερός» στα DevOps, το μέλλον της ίδιας της Kubernetes, γιατί, πότε και πώς θα καταλάβει τον κόσμο, τις προοπτικές των DevOps και τι πρέπει να προετοιμαστούν οι μηχανικοί στο λαμπρό και εγγύς μέλλον με απλοποίηση και νευρωνικά δίκτυα.
ακούστε ως podcast στο DevOps Deflop - ένα podcast ρωσικής γλώσσας για το DevOps και παρακάτω είναι η έκδοση κειμένου.
Εδώ και κάτω κάνει ερωτήσεις μηχανικός από το Express42.
Σχετικά με το "Flant"
- Γεια σου Δήμα. Είστε ο τεχνικός διευθυντής»» και επίσης ο ιδρυτής του. Πείτε μας τι κάνει η εταιρεία και τι είστε σε αυτήν;
Ντμίτρι: Από έξω φαίνεται ότι είμαστε οι τύποι που κυκλοφορούμε εγκαθιστώντας το Kubernetes για όλους και κάνουμε κάτι με αυτό. Αλλά αυτό δεν είναι αλήθεια. Ξεκινήσαμε ως εταιρεία που ασχολείται με το Linux, αλλά για πολύ μεγάλο χρονικό διάστημα η κύρια δραστηριότητά μας ήταν η εξυπηρέτηση της παραγωγής και των έργων με το κλειδί στο χέρι. Συνήθως φτιάχνουμε ολόκληρη την υποδομή από την αρχή και μετά είμαστε υπεύθυνοι για αυτό για πολύ, πολύ καιρό. Επομένως, η κύρια δουλειά που κάνει το “Flant” και για το οποίο λαμβάνει χρήματα είναι ανάληψη ευθύνης και υλοποίηση παραγωγής με το κλειδί στο χέρι.
Εγώ, ως τεχνικός διευθυντής και ένας από τους ιδρυτές της εταιρείας, περνάω όλη μέρα και νύχτα προσπαθώντας να καταλάβω πώς να αυξήσω την προσβασιμότητα της παραγωγής, να απλοποιήσω τη λειτουργία της, να κάνω τη ζωή των διαχειριστών πιο εύκολη και τη ζωή των προγραμματιστών πιο ευχάριστη .
Σχετικά με την Kubernetes
— Τον τελευταίο καιρό βλέπω πολλές αναφορές από τον Flant και για το Kubernetes. Πώς καταλήξατε σε αυτό;
Ντμίτρι: Έχω ήδη μιλήσει για αυτό πολλές φορές, αλλά δεν με πειράζει να το επαναλάβω καθόλου. Νομίζω ότι είναι σωστό να επαναλάβουμε αυτό το θέμα γιατί υπάρχει σύγχυση μεταξύ αιτίας και αποτελέσματος.
Χρειαζόμασταν πραγματικά ένα εργαλείο. Αντιμετωπίσαμε πολλά προβλήματα, παλέψαμε, τα ξεπεράσαμε με διάφορα δεκανίκια και νιώσαμε την ανάγκη για ένα εργαλείο. Περάσαμε από πολλές διαφορετικές επιλογές, φτιάξαμε τα δικά μας ποδήλατα και αποκτήσαμε εμπειρία. Σταδιακά φτάσαμε στο σημείο όπου αρχίσαμε να χρησιμοποιούμε το Docker σχεδόν αμέσως μόλις εμφανίστηκε - γύρω στο 2013. Την εποχή της εμφάνισής του, είχαμε ήδη μεγάλη εμπειρία με κοντέινερ, είχαμε ήδη γράψει ένα ανάλογο του «Docker» - μερικά από τα δικά μας δεκανίκια στην Python. Με την εμφάνιση του Docker, κατέστη δυνατό να πετάξουμε τα δεκανίκια και να χρησιμοποιήσουμε μια αξιόπιστη και υποστηριζόμενη από την κοινότητα λύση.
Με την Kubernetes η ιστορία είναι παρόμοια. Όταν άρχισε να κερδίζει δυναμική - για εμάς αυτή είναι η έκδοση 1.2 - είχαμε ήδη ένα σωρό δεκανίκια τόσο στη Shell όσο και στο Chef, τα οποία με κάποιο τρόπο προσπαθήσαμε να ενορχηστρώσουμε με τον Docker. Ψάχναμε σοβαρά για το Rancher και διάφορες άλλες λύσεις, αλλά μετά εμφανίστηκε η Kubernetes, στην οποία όλα εφαρμόζονται όπως ακριβώς θα τα κάναμε ή ακόμα καλύτερα. Δεν υπάρχει τίποτα για παράπονο.
Ναι, υπάρχει κάποια ατέλεια εδώ, υπάρχει κάποια ατέλεια εκεί - υπάρχουν πολλές ατέλειες, και το 1.2 είναι γενικά τρομερό, αλλά... Το Kubernetes είναι σαν ένα κτίριο υπό κατασκευή - κοιτάς το έργο και καταλαβαίνεις ότι θα είναι δροσερό. Εάν το κτίριο έχει τώρα θεμέλια και δύο ορόφους, τότε καταλαβαίνετε ότι είναι καλύτερο να μην μετακομίσετε ακόμα, αλλά δεν υπάρχουν τέτοια προβλήματα με το λογισμικό - μπορείτε ήδη να το χρησιμοποιήσετε.
Δεν είχαμε μια στιγμή που σκεφτήκαμε να χρησιμοποιήσουμε το Kubernetes ή όχι. Το περιμέναμε πολύ πριν εμφανιστεί και προσπαθήσαμε να δημιουργήσουμε ανάλογα.
Σχετικά με την Kubernetes
— Συμμετέχετε άμεσα στην ανάπτυξη του ίδιου του Kubernetes;
Ντμίτρι: Μέτριο. Μάλλον συμμετέχουμε στην ανάπτυξη του οικοσυστήματος. Στέλνουμε έναν ορισμένο αριθμό αιτημάτων έλξης: στον Προμηθέα, σε διάφορους χειριστές, στο Helm - στο οικοσύστημα. Δυστυχώς, δεν είμαι σε θέση να παρακολουθώ όλα όσα κάνουμε και μπορεί να κάνω λάθος, αλλά δεν υπάρχει ούτε μία δεξαμενή από εμάς στον πυρήνα.
— Ταυτόχρονα, αναπτύσσετε πολλά από τα εργαλεία σας γύρω από το Kubernetes;
Ντμίτρι: Η στρατηγική είναι η εξής: πάμε και τραβάμε αιτήματα σε όλα όσα ήδη υπάρχουν. Εάν τα αιτήματα έλξης δεν γίνονται δεκτά εκεί, απλώς τα διαχωρίζουμε μόνοι μας και ζούμε μέχρι να γίνουν δεκτά με τις κατασκευές μας. Στη συνέχεια, όταν φτάσει στο upstream, επιστρέφουμε στην upstream έκδοση.
Για παράδειγμα, έχουμε έναν χειριστή Prometheus, με τον οποίο αλλάξαμε μπρος-πίσω στο upstream του συγκροτήματός μας πιθανότατα ήδη 5 φορές. Χρειαζόμαστε κάποιο είδος δυνατότητας, στείλαμε ένα αίτημα έλξης, πρέπει να το κυκλοφορήσουμε αύριο, αλλά δεν θέλουμε να περιμένουμε να κυκλοφορήσει ανάντη. Αντίστοιχα, συναρμολογούμε μόνοι μας, διαθέτουμε το συγκρότημα μας με το χαρακτηριστικό μας, το οποίο χρειαζόμαστε για κάποιο λόγο, σε όλα τα cluster μας. Στη συνέχεια, για παράδειγμα, μας το γυρίζουν στο upstream με τις λέξεις: «Παιδιά, ας το κάνουμε για μια γενικότερη περίπτωση», το τελειώνουμε εμείς ή κάποιος άλλος και με την πάροδο του χρόνου συγχωνεύεται ξανά.
Προσπαθούμε να αναπτύξουμε ό,τι υπάρχει. Πολλά στοιχεία που δεν υπάρχουν ακόμη, δεν έχουν εφευρεθεί ακόμη, ή έχουν εφευρεθεί, αλλά δεν έχουν προλάβει να τα εφαρμόσουν - το κάνουμε. Και όχι επειδή μας αρέσει η διαδικασία ή η κατασκευή ποδηλάτων ως βιομηχανία, αλλά απλώς επειδή χρειαζόμαστε αυτό το εργαλείο. Συχνά τίθεται το ερώτημα, γιατί κάναμε αυτό ή εκείνο το πράγμα; Η απάντηση είναι απλή - ναι, γιατί έπρεπε να πάμε παραπέρα, να λύσουμε κάποιο πρακτικό πρόβλημα και το λύσαμε με αυτήν την τούλα.
Το μονοπάτι είναι πάντα έτσι: ψάχνουμε πολύ προσεκτικά και, αν δεν βρούμε λύση για το πώς να φτιάξουμε ένα τρόλεϊ από ένα καρβέλι ψωμί, τότε φτιάχνουμε το δικό μας καρβέλι και το δικό μας τρόλεϊ.
Εργαλεία Flanta
— Γνωρίζω ότι το Flant διαθέτει πλέον τελεστές πρόσθετου, τελεστές κελύφους και εργαλεία dapp/werf. Όπως καταλαβαίνω, αυτό είναι το ίδιο όργανο σε διαφορετικές ενσαρκώσεις. Καταλαβαίνω επίσης ότι υπάρχουν πολλά περισσότερα διαφορετικά εργαλεία στο Flaunt. Αυτό είναι αλήθεια?
Ντμίτρι: Έχουμε πολλά περισσότερα στο GitHub. Από ότι θυμάμαι τώρα, έχουμε ένα statusmap - ένα πάνελ για τη Γραφάνα που άρεσε σε όλους. Αναφέρεται σχεδόν σε κάθε δεύτερο άρθρο σχετικά με την παρακολούθηση του Kubernetes στο Medium. Είναι αδύνατο να εξηγήσουμε εν συντομία τι είναι ένας χάρτης κατάστασης - χρειάζεται ξεχωριστό άρθρο, αλλά είναι πολύ χρήσιμο για την παρακολούθηση της κατάστασης με την πάροδο του χρόνου, καθώς στο Kubernetes συχνά χρειάζεται να δείξουμε την κατάσταση με την πάροδο του χρόνου. Έχουμε επίσης LogHouse - αυτό είναι ένα πράγμα που βασίζεται στο ClickHouse και στη μαύρη μαγεία για τη συλλογή αρχείων καταγραφής στο Kubernetes.
Πολλά βοηθητικά προγράμματα! Και θα υπάρξουν ακόμη περισσότερες, γιατί φέτος θα κυκλοφορήσουν αρκετές εσωτερικές λύσεις. Από τα πολύ μεγάλα που βασίζονται στον τελεστή πρόσθετου, υπάρχουν πολλά πρόσθετα για το Kubernetes, αλά πώς να εγκαταστήσετε σωστά το sert manager - ένα εργαλείο για τη διαχείριση πιστοποιητικών, πώς να εγκαταστήσετε σωστά το Prometheus με μια δέσμη αξεσουάρ - αυτά είναι περίπου είκοσι διαφορετικά δυαδικά που εξάγουν δεδομένα και συλλέγουν κάτι, σε αυτό ο Προμηθέας έχει τα πιο εκπληκτικά γραφικά και ειδοποιήσεις. Όλα αυτά είναι απλώς ένα σωρό πρόσθετα στο Kubernetes, τα οποία είναι εγκατεστημένα σε ένα σύμπλεγμα, και μετατρέπονται από απλά σε cool, εξελιγμένα, αυτόματα, στα οποία έχουν ήδη επιλυθεί πολλά ζητήματα. Ναι, κάνουμε πολλά.
Ανάπτυξη Οικοσυστήματος
«Μου φαίνεται ότι αυτή είναι μια πολύ μεγάλη συμβολή στην ανάπτυξη αυτού του οργάνου και των μεθόδων χρήσης του». Μπορείτε να υπολογίσετε χονδρικά ποιος άλλος θα συνεισέφερε την ίδια στην ανάπτυξη του οικοσυστήματος;
Ντμίτρι: Στη Ρωσία, από τις εταιρείες που δραστηριοποιούνται στην αγορά μας, κανείς δεν είναι καν κοντά. Φυσικά, αυτή είναι μια ηχηρή δήλωση, επειδή υπάρχουν σημαντικοί παίκτες όπως η Mail και η Yandex - κάνουν επίσης κάτι με την Kubernetes, αλλά ακόμη και αυτοί δεν πλησιάζουν τη συνεισφορά εταιρειών σε ολόκληρο τον κόσμο που κάνουν πολύ περισσότερα από εμάς. Είναι δύσκολο να συγκρίνουμε το Flant, που έχει προσωπικό 80 ατόμων, και τη Red Hat, που έχει 300 μηχανικούς μόνο ανά Kubernetes, αν δεν κάνω λάθος. Είναι δύσκολο να συγκριθεί. Έχουμε 6 άτομα στο τμήμα RnD, συμπεριλαμβανομένου και εμένα, που κόβουμε όλα τα εργαλεία μας. 6 άτομα έναντι 300 μηχανικών της Red Hat - είναι κάπως δύσκολο να συγκριθεί.
- Ωστόσο, όταν ακόμη και αυτά τα 6 άτομα μπορούν να κάνουν κάτι πραγματικά χρήσιμο και ξενερωμένο, όταν έρχονται αντιμέτωποι με ένα πρακτικό πρόβλημα και δίνουν τη λύση στην κοινότητα - μια ενδιαφέρουσα περίπτωση. Κατανοώ ότι σε μεγάλες εταιρείες τεχνολογίας, όπου έχουν τη δική τους ομάδα ανάπτυξης και υποστήριξης Kubernetes, καταρχήν, μπορούν να αναπτυχθούν τα ίδια εργαλεία. Αυτό είναι ένα παράδειγμα για αυτούς του τι μπορεί να αναπτυχθεί και να δοθεί στην κοινότητα, δίνοντας ώθηση σε ολόκληρη την κοινότητα που χρησιμοποιεί το Kubernetes.
Ντμίτρι: Αυτό είναι μάλλον ένα χαρακτηριστικό του ολοκληρωτή, η ιδιαιτερότητά του. Έχουμε πολλά έργα και βλέπουμε πολλές διαφορετικές καταστάσεις. Για εμάς, ο κύριος τρόπος για να δημιουργήσουμε προστιθέμενη αξία είναι να αναλύσουμε αυτές τις περιπτώσεις, να βρούμε κοινά σημεία και να τις κάνουμε όσο το δυνατόν πιο φθηνές για εμάς. Εργαζόμαστε ενεργά σε αυτό. Μου είναι δύσκολο να μιλήσω για τη Ρωσία και τον κόσμο, αλλά έχουμε περίπου 40 μηχανικούς DevOps στην εταιρεία που εργάζονται στο Kubernetes. Δεν νομίζω ότι υπάρχουν πολλές εταιρείες στη Ρωσία με συγκρίσιμο αριθμό ειδικών που καταλαβαίνουν την Kubernetes, αν υπάρχουν καθόλου.
Καταλαβαίνω τα πάντα για τον τίτλο εργασίας DevOps engineer, όλοι καταλαβαίνουν τα πάντα και συνηθίζουν να αποκαλούν μηχανικούς DevOps μηχανικούς DevOps, δεν θα το συζητήσουμε αυτό. Όλοι αυτοί οι 40 καταπληκτικοί μηχανικοί DevOps αντιμετωπίζουν και λύνουν προβλήματα καθημερινά, απλώς αναλύουμε αυτήν την εμπειρία και προσπαθούμε να γενικεύσουμε. Καταλαβαίνουμε ότι αν μείνει μέσα μας, τότε σε ένα ή δύο χρόνια το εργαλείο θα είναι άχρηστο, γιατί κάπου στην κοινότητα θα εμφανιστεί μια έτοιμη Τούλα. Δεν έχει νόημα η συσσώρευση αυτής της εμπειρίας εσωτερικά - απλώς εξαντλεί ενέργεια και χρόνο σε dev/null. Και δεν το λυπόμαστε καθόλου. Δημοσιεύουμε τα πάντα με μεγάλη ευχαρίστηση και κατανοούμε ότι πρέπει να δημοσιευθούν, να αναπτυχθούν, να προωθηθούν, να προωθηθούν, ώστε οι άνθρωποι να τα χρησιμοποιήσουν και να προσθέσουν την εμπειρία τους - τότε όλα μεγαλώνουν και ζουν. Μετά από δύο χρόνια το όργανο δεν πάει στα σκουπίδια. Δεν είναι κρίμα να συνεχίσεις να δυναμώνεις, γιατί είναι ξεκάθαρο ότι κάποιος χρησιμοποιεί το εργαλείο σου και μετά από δύο χρόνια το χρησιμοποιούν όλοι.
Αυτό είναι μέρος της μεγάλης στρατηγικής μας με το dapp/werf. Δεν θυμάμαι πότε ξεκινήσαμε να το κάνουμε, φαίνεται πριν από 3 χρόνια. Αρχικά, ήταν γενικά στο κέλυφος. Ήταν μια σούπερ απόδειξη της ιδέας, λύσαμε μερικά από τα ιδιαίτερα προβλήματά μας - λειτούργησε! Αλλά υπάρχουν προβλήματα με το κέλυφος, είναι αδύνατο να επεκταθεί περαιτέρω, ο προγραμματισμός στο κέλυφος είναι μια άλλη εργασία. Είχαμε τη συνήθεια να γράφουμε στο Ruby, κατά συνέπεια, ξαναφτιάξαμε κάτι στο Ruby, αναπτύξαμε, αναπτύξαμε, αναπτύξαμε και αντιμετωπίσαμε το γεγονός ότι η κοινότητα, το πλήθος που δεν λέει «το θέλουμε ή δεν το θέλουμε, » σηκώνει τη μύτη του στη Ρούμπι, πόσο αστείο είναι αυτό; Συνειδητοποιήσαμε ότι θα έπρεπε να γράψουμε όλα αυτά τα πράγματα στο Go απλώς για να συναντήσουμε το πρώτο σημείο στη λίστα ελέγχου: Το εργαλείο DevOps θα πρέπει να είναι ένα στατικό δυαδικό. Το να είσαι Go ή όχι δεν είναι τόσο σημαντικό, αλλά ένα στατικό δυαδικό γραμμένο στο Go είναι καλύτερο.
Ξοδέψαμε την ενέργειά μας, ξαναγράψαμε το dapp στο Go και το ονομάσαμε werf. Το Dapp δεν υποστηρίζεται πλέον, δεν αναπτύσσεται, εκτελείται σε κάποια τελευταία έκδοση, αλλά υπάρχει μια απόλυτη διαδρομή αναβάθμισης προς την κορυφή και μπορείτε να την ακολουθήσετε.
Γιατί δημιουργήθηκε το dapp;
— Μπορείτε να μας πείτε εν συντομία γιατί δημιουργήθηκε το dapp, ποια προβλήματα λύνει;
Ντμίτρι: Ο πρώτος λόγος είναι στη συνέλευση. Αρχικά, είχαμε σοβαρά προβλήματα με την κατασκευή όταν το Docker δεν είχε δυνατότητες πολλαπλών σταδίων, οπότε κάναμε multi-stage μόνοι μας. Στη συνέχεια, είχαμε πολλά περισσότερα προβλήματα με τον καθαρισμό της εικόνας. Όλοι όσοι κάνουν CI/CD, νωρίτερα παρά αργότερα, αντιμετωπίζουν το πρόβλημα ότι υπάρχουν πολλές συλλεγμένες εικόνες, πρέπει με κάποιο τρόπο να καθαρίσετε ό,τι δεν χρειάζεται και να αφήσετε ό,τι χρειάζεται.
Ο δεύτερος λόγος είναι η ανάπτυξη. Ναι, υπάρχει το Helm, αλλά λύνει μόνο μερικά από τα προβλήματα. Είναι αρκετά αστείο, γράφεται ότι «Η Helm είναι ο Διαχειριστής Πακέτων για την Kubernetes». Ακριβώς αυτό που «το». Υπάρχουν επίσης οι λέξεις «Διαχειριστής πακέτων» - ποια είναι η συνήθης προσδοκία από έναν Διαχειριστή πακέτων; Λέμε: "Διαχειριστής πακέτων - εγκαταστήστε το πακέτο!" και περιμένουμε να μας πει: «Το πακέτο παραδόθηκε».
Είναι ενδιαφέρον ότι λέμε: "Helm, εγκαταστήστε το πακέτο" και όταν απαντά ότι το εγκατέστησε, αποδεικνύεται ότι μόλις ξεκίνησε την εγκατάσταση - έδειξε τον Kubernetes: "Εκκίνηση αυτό το πράγμα!", και αν ξεκίνησε ή όχι , είτε δουλεύει είτε όχι, η Helm δεν λύνει καθόλου αυτό το θέμα.
Αποδεικνύεται ότι το Helm είναι απλώς ένας προεπεξεργαστής κειμένου που φορτώνει δεδομένα στο Kubernetes.
Αλλά ως μέρος οποιασδήποτε ανάπτυξης, θέλουμε να μάθουμε εάν η εφαρμογή έχει κυκλοφορήσει για παραγωγή ή όχι; Το roll out to prod σημαίνει ότι η εφαρμογή έχει μετακινηθεί εκεί, η νέα έκδοση έχει αναπτυχθεί και τουλάχιστον δεν κολλάει εκεί και ανταποκρίνεται σωστά. Η Helm δεν λύνει αυτό το πρόβλημα με κανέναν τρόπο. Για να το λύσετε, πρέπει να ξοδέψετε πολλή προσπάθεια, γιατί πρέπει να δώσετε στην Kubernetes την εντολή να ανοίξει και να παρακολουθήσει τι συμβαίνει εκεί - είτε έχει αναπτυχθεί είτε κυκλοφορήσει. Και υπάρχουν επίσης πολλές εργασίες που σχετίζονται με την ανάπτυξη, τον καθαρισμό και τη συναρμολόγηση.
Σχέδια
Φέτος θα ξεκινήσουμε την τοπική ανάπτυξη. Θέλουμε να επιτύχουμε αυτό που ήταν προηγουμένως στο Vagrant - πληκτρολογήσαμε "vagrant up" και αναπτύξαμε εικονικές μηχανές. Θέλουμε να φτάσουμε στο σημείο όπου υπάρχει ένα έργο στο Git, γράφουμε "werf up" εκεί και εμφανίζει ένα τοπικό αντίγραφο αυτού του έργου, που έχει αναπτυχθεί σε ένα τοπικό mini-Kub, με όλους τους καταλόγους που είναι κατάλληλοι για ανάπτυξη συνδεδεμένους . Ανάλογα με τη γλώσσα ανάπτυξης, αυτό γίνεται διαφορετικά, αλλά παρόλα αυτά, έτσι ώστε η τοπική ανάπτυξη να μπορεί να πραγματοποιηθεί εύκολα κάτω από προσαρτημένα αρχεία.
Το επόμενο βήμα για εμάς είναι επενδύστε στην ευκολία για τους προγραμματιστές. Για να αναπτύξετε γρήγορα ένα έργο τοπικά με ένα εργαλείο, αναπτύξτε το, ωθήστε το στο Git και θα αναπτυχθεί επίσης σε στάδιο ή δοκιμές, ανάλογα με τους αγωγούς και, στη συνέχεια, χρησιμοποιήστε το ίδιο εργαλείο για να μεταβείτε στην παραγωγή. Αυτή η ενότητα, η ενοποίηση, η αναπαραγωγιμότητα της υποδομής από το τοπικό περιβάλλον έως τις πωλήσεις είναι ένα πολύ σημαντικό σημείο για εμάς. Αλλά αυτό δεν είναι ακόμα στο werf - απλώς σχεδιάζουμε να το κάνουμε.
Αλλά ο δρόμος προς το dapp/werf ήταν πάντα ο ίδιος με τον Kubernetes στην αρχή. Αντιμετωπίσαμε προβλήματα, τα λύσαμε με λύσεις - καταλήξαμε σε μερικές λύσεις για τον εαυτό μας στο κέλυφος, σε οτιδήποτε. Στη συνέχεια προσπάθησαν με κάποιο τρόπο να ισιώσουν αυτές τις λύσεις, να τις γενικεύσουν και να τις ενοποιήσουν σε δυαδικά σε αυτήν την περίπτωση, τις οποίες απλώς μοιραζόμαστε.
Υπάρχει ένας άλλος τρόπος να δούμε όλη αυτή την ιστορία, με αναλογίες.
Το Kubernetes είναι ένα πλαίσιο αυτοκινήτου με κινητήρα. Δεν υπάρχουν πόρτες, γυαλί, ραδιόφωνο, χριστουγεννιάτικο δέντρο - τίποτα απολύτως. Μόνο το πλαίσιο και ο κινητήρας. Και υπάρχει Helm - αυτό είναι το τιμόνι. Cool - υπάρχει ένα τιμόνι, αλλά χρειάζεστε επίσης μια καρφίτσα τιμονιού, ράφι τιμονιού, κιβώτιο ταχυτήτων και τροχούς και δεν μπορείτε να κάνετε χωρίς αυτά.
Στην περίπτωση του werf, αυτό είναι ένα άλλο στοιχείο του Kubernetes. Μόνο που τώρα στην άλφα έκδοση του werf, για παράδειγμα, το Helm είναι μεταγλωττισμένο μέσα στο werf, γιατί έχουμε βαρεθεί να το κάνουμε μόνοι μας. Υπάρχουν πολλοί λόγοι για να το κάνετε αυτό, θα σας πω λεπτομερώς γιατί συγκεντρώσαμε ολόκληρο το τιμόνι μαζί με το πηδάλιο μέσα στο werf .
Τώρα το werf είναι ένα πιο ολοκληρωμένο στοιχείο. Παίρνουμε ένα τελειωμένο τιμόνι, μια καρφίτσα τιμονιού - δεν είμαι πολύ καλός στα αυτοκίνητα, αλλά αυτό είναι ένα μεγάλο μπλοκ που ήδη λύνει ένα αρκετά ευρύ φάσμα προβλημάτων. Δεν χρειάζεται να περάσουμε μόνοι μας από τον κατάλογο, να επιλέξουμε ένα εξάρτημα για ένα άλλο, να σκεφτούμε πώς να τα βιδώσουμε μεταξύ τους. Παίρνουμε έναν έτοιμο συνδυασμό που λύνει μεγάλο αριθμό προβλημάτων ταυτόχρονα. Αλλά στο εσωτερικό του είναι κατασκευασμένο από τα ίδια στοιχεία ανοιχτού κώδικα, εξακολουθεί να χρησιμοποιεί το Docker για τη συναρμολόγηση, το Helm για ορισμένες από τις λειτουργίες και υπάρχουν πολλές άλλες βιβλιοθήκες. Αυτό είναι ένα ενσωματωμένο εργαλείο για να βγάζετε το δροσερό CI/CD από το κουτί γρήγορα και άνετα.
Είναι δύσκολο να διατηρηθεί το Kubernetes;
— Μιλάτε για την εμπειρία που ξεκινήσατε να χρησιμοποιείτε το Kubernetes, αυτό είναι ένα πλαίσιο για εσάς, ένας κινητήρας και ότι μπορείτε να κρεμάσετε πολλά διαφορετικά πράγματα σε αυτό: ένα σώμα, ένα τιμόνι, βίδες σε πετάλια, καθίσματα. Τίθεται το ερώτημα - πόσο δύσκολη είναι η υποστήριξη της Kubernetes για εσάς; Έχετε μεγάλη εμπειρία, πόσο χρόνο και πόρους ξοδεύετε για την υποστήριξη της Kubernetes απομονωμένη από οτιδήποτε άλλο;
Ντμίτρι: Αυτή είναι μια πολύ δύσκολη ερώτηση και για να απαντήσουμε, πρέπει να καταλάβουμε τι είναι υποστήριξη και τι θέλουμε από την Kubernetes. Ίσως μπορείτε να αποκαλύψετε;
— Από όσο ξέρω και όπως βλέπω, τώρα πολλές ομάδες θέλουν να δοκιμάσουν την Kubernetes. Όλοι προσαρμόζονται σε αυτό, το βάζουν στα γόνατά τους. Έχω την αίσθηση ότι οι άνθρωποι δεν καταλαβαίνουν πάντα την πολυπλοκότητα αυτού του συστήματος.
Ντμίτρι: Ειναι ετσι.
— Πόσο δύσκολο είναι να πάρεις και να εγκαταστήσεις το Kubernetes από την αρχή ώστε να είναι έτοιμο για παραγωγή;
Ντμίτρι: Πόσο δύσκολο πιστεύετε ότι είναι η μεταμόσχευση καρδιάς; Καταλαβαίνω ότι αυτή είναι μια συμβιβαστική ερώτηση. Το να χρησιμοποιείς νυστέρι και να μην κάνεις λάθος δεν είναι τόσο δύσκολο. Εάν σας πουν πού να κόψετε και πού να ράψετε, τότε η ίδια η διαδικασία δεν είναι περίπλοκη. Είναι δύσκολο να εγγυηθεί κανείς κάθε φορά ότι όλα θα πάνε καλά.
Η εγκατάσταση του Kubernetes και η έναρξη λειτουργίας του είναι εύκολη: τσικ! — εγκατεστημένο, υπάρχουν πολλές μέθοδοι εγκατάστασης. Τι γίνεται όμως όταν προκύπτουν προβλήματα;
Πάντα προκύπτουν ερωτήματα - τι δεν έχουμε λάβει ακόμη υπόψη μας; Τι δεν κάναμε ακόμα; Ποιες παράμετροι πυρήνα Linux καθορίστηκαν εσφαλμένα; Κύριε, τα αναφέραμε κιόλας;! Ποια στοιχεία Kubernetes έχουμε παραδώσει και ποια όχι; Προκύπτουν χιλιάδες ερωτήματα και για να τα απαντήσετε, πρέπει να περάσετε 15-20 χρόνια σε αυτόν τον κλάδο.
Έχω ένα πρόσφατο παράδειγμα σχετικά με αυτό το θέμα που μπορεί να αποκαλύψει την έννοια του προβλήματος "Είναι δύσκολο να διατηρηθεί το Kubernetes;" Πριν από λίγο καιρό σκεφτήκαμε σοβαρά αν θα έπρεπε να προσπαθήσουμε να εφαρμόσουμε το Cilium ως δίκτυο στο Kubernetes.
Επιτρέψτε μου να εξηγήσω τι είναι το Cilium. Το Kubernetes έχει πολλές διαφορετικές υλοποιήσεις του υποσυστήματος δικτύωσης και μία από αυτές είναι πολύ ενδιαφέρουσα - το Cilium. Ποιο είναι το νόημά του; Στον πυρήνα, πριν από λίγο καιρό έγινε δυνατή η εγγραφή αγκίστρων για τον πυρήνα, τα οποία με τον ένα ή τον άλλο τρόπο εισβάλλουν στο υποσύστημα δικτύου και σε διάφορα άλλα υποσυστήματα και σας επιτρέπουν να παρακάμψετε μεγάλα κομμάτια στον πυρήνα.
Ο πυρήνας του Linux έχει ιστορικά μια διαδρομή ip, ένα υπερφίλτρο, γέφυρες και πολλά διαφορετικά παλιά στοιχεία που είναι 15, 20, 30 ετών. Γενικά, δουλεύουν, όλα είναι υπέροχα, αλλά τώρα έχουν στοιβαγμένα δοχεία, και μοιάζει με έναν πύργο από 15 τούβλα το ένα πάνω στο άλλο, και στέκεσαι πάνω του στο ένα πόδι - μια περίεργη αίσθηση. Αυτό το σύστημα έχει αναπτυχθεί ιστορικά με πολλές αποχρώσεις, όπως η σκωληκοειδής απόφυση στο σώμα. Σε ορισμένες περιπτώσεις, για παράδειγμα, υπάρχουν προβλήματα απόδοσης.
Υπάρχει ένα υπέροχο BPF και η δυνατότητα να γράφετε άγκιστρα για τον πυρήνα - τα παιδιά έγραψαν τα δικά τους άγκιστρα για τον πυρήνα. Το πακέτο μπαίνει στον πυρήνα του Linux, το βγάζουν ακριβώς στην είσοδο, το επεξεργάζονται όπως θα έπρεπε χωρίς γέφυρες, χωρίς TCP, χωρίς στοίβα IP - με λίγα λόγια, παρακάμπτοντας όλα όσα είναι γραμμένα στον πυρήνα του Linux και μετά φτύνουν έξω στο δοχείο.
Τι συνέβη? Πολύ ωραία απόδοση, δροσερά χαρακτηριστικά - απλά ωραία! Αλλά το κοιτάμε αυτό και βλέπουμε ότι σε κάθε μηχανή υπάρχει ένα πρόγραμμα που συνδέεται με το Kubernetes API και, με βάση τα δεδομένα που λαμβάνει από αυτό το API, δημιουργεί κώδικα C και μεταγλωττίζει δυαδικά αρχεία που φορτώνει στον πυρήνα, έτσι ώστε αυτά τα άγκιστρα να λειτουργούν στο χώρο του πυρήνα.
Τι συμβαίνει αν κάτι πάει στραβά; Δεν ξέρουμε. Για να το καταλάβετε αυτό, πρέπει να διαβάσετε όλο αυτόν τον κώδικα, να κατανοήσετε όλη τη λογική και είναι εκπληκτικό πόσο δύσκολο είναι. Αλλά, από την άλλη πλευρά, υπάρχουν αυτές οι γέφυρες, τα φίλτρα δικτύου, η δρομολόγηση ip - δεν έχω διαβάσει τον πηγαίο κώδικα τους, ούτε και οι 40 μηχανικοί που εργάζονται στην εταιρεία μας. Ίσως μόνο λίγοι καταλαβαίνουν κάποια σημεία.
Και ποια είναι η διαφορά; Αποδεικνύεται ότι υπάρχει η διαδρομή ip, ο πυρήνας του Linux και υπάρχει ένα νέο εργαλείο - τι διαφορά έχει, δεν καταλαβαίνουμε το ένα ή το άλλο. Αλλά φοβόμαστε να χρησιμοποιήσουμε κάτι νέο - γιατί; Γιατί αν το εργαλείο είναι 30 ετών, τότε σε 30 χρόνια έχουν βρεθεί όλα τα σφάλματα, έχουν πατηθεί όλα τα λάθη και δεν χρειάζεται να γνωρίζετε τα πάντα - λειτουργεί σαν μαύρο κουτί και λειτουργεί πάντα. Όλοι γνωρίζουν ποιο διαγνωστικό κατσαβίδι να κολλήσει σε ποιο σημείο, ποιο tcpdump να λειτουργήσει ποια στιγμή. Όλοι γνωρίζουν καλά τα βοηθητικά προγράμματα διάγνωσης και κατανοούν πώς λειτουργεί αυτό το σύνολο στοιχείων στον πυρήνα του Linux - όχι πώς λειτουργεί, αλλά πώς να το χρησιμοποιήσετε.
Και το απίστευτα δροσερό Cilium δεν είναι 30 ετών, δεν έχει γεράσει ακόμα. Η Kubernetes έχει το ίδιο πρόβλημα, αντιγράψτε. Ότι το Cilium έχει εγκατασταθεί τέλεια, ότι το Kubernetes έχει εγκατασταθεί τέλεια, αλλά όταν κάτι πάει στραβά στην παραγωγή, μπορείτε να καταλάβετε γρήγορα σε μια κρίσιμη κατάσταση τι πήγε στραβά;
Όταν λέμε είναι δύσκολο να διατηρήσεις το Kubernetes - όχι, είναι πολύ εύκολο και ναι, είναι απίστευτα δύσκολο. Το Kubernetes λειτουργεί εξαιρετικά από μόνο του, αλλά με ένα δισεκατομμύριο αποχρώσεις.
Σχετικά με την προσέγγιση «Θα είμαι τυχερός».
— Υπάρχουν εταιρείες όπου αυτές οι αποχρώσεις είναι σχεδόν εγγυημένο ότι θα εμφανιστούν; Ας υποθέσουμε ότι η Yandex μεταφέρει ξαφνικά όλες τις υπηρεσίες στο Kubernetes, θα υπάρχει τεράστιο φορτίο εκεί.
Ντμίτρι: Όχι, δεν πρόκειται για κουβέντα για το φορτίο, αλλά για τα πιο απλά πράγματα. Για παράδειγμα, έχουμε Kubernetes, αναπτύξαμε την εφαρμογή εκεί. Πώς ξέρετε ότι λειτουργεί; Απλώς δεν υπάρχει έτοιμο εργαλείο για να καταλάβουμε ότι η εφαρμογή δεν κολλάει. Δεν υπάρχει έτοιμο σύστημα που να στέλνει ειδοποιήσεις· πρέπει να διαμορφώσετε αυτές τις ειδοποιήσεις και κάθε χρονοδιάγραμμα. Και ενημερώνουμε το Kubernetes.
Έχω το Ubuntu 16.04. Μπορείτε να πείτε ότι αυτή είναι μια παλιά έκδοση, αλλά είμαστε ακόμα σε αυτήν επειδή είναι LTS. Υπάρχει systemd, η απόχρωση του οποίου είναι ότι δεν καθαρίζει τις ομάδες C. Το Kubernetes εκτοξεύει pods, δημιουργεί ομάδες C, μετά διαγράφει pods και με κάποιο τρόπο αποδεικνύεται - δεν θυμάμαι τις λεπτομέρειες, συγγνώμη - ότι παραμένουν τα systemd slics. Αυτό οδηγεί στο γεγονός ότι με την πάροδο του χρόνου, οποιοδήποτε αυτοκίνητο αρχίζει να επιβραδύνει έντονα. Δεν πρόκειται καν για θέμα highload. Εάν εκκινηθούν μόνιμα pods, για παράδειγμα, εάν υπάρχει ένα Cron Job που δημιουργεί συνεχώς pods, τότε το μηχάνημα με το Ubuntu 16.04 θα αρχίσει να επιβραδύνει μετά από μια εβδομάδα. Θα υπάρχει συνεχώς υψηλός μέσος όρος φορτίου λόγω του γεγονότος ότι έχουν δημιουργηθεί ένα σωρό ομάδες C. Αυτό είναι το πρόβλημα που θα αντιμετωπίσει όποιος απλώς εγκαθιστά το Ubuntu 16 και το Kubernetes από πάνω.
Ας υποθέσουμε ότι ενημερώνει με κάποιο τρόπο το systemd ή κάτι άλλο, αλλά στον πυρήνα του Linux μέχρι το 4.16 είναι ακόμα πιο αστείο - όταν διαγράφετε ομάδες C, διαρρέουν στον πυρήνα και στην πραγματικότητα δεν διαγράφονται. Επομένως, μετά από ένα μήνα εργασίας σε αυτό το μηχάνημα, θα είναι αδύνατο να δούμε τα στατιστικά στοιχεία της μνήμης για τις εστίες. Βγάζουμε ένα αρχείο, το ρίχνουμε στο πρόγραμμα και ένα αρχείο κυλάει για 15 δευτερόλεπτα, επειδή ο πυρήνας χρειάζεται πολύ χρόνο για να μετρήσει μέσα του ένα εκατομμύριο ομάδες C, οι οποίες φαίνεται να έχουν διαγραφεί, αλλά όχι - διαρρέουν .
Υπάρχουν ακόμα πολλά τέτοια μικρά πράγματα εδώ κι εκεί. Αυτό δεν είναι ένα ζήτημα που μπορεί μερικές φορές να αντιμετωπίσουν οι εταιρείες κολοσσοί κάτω από πολύ βαριά φορτία - όχι, είναι θέμα καθημερινών πραγμάτων. Οι άνθρωποι μπορούν να ζήσουν έτσι για μήνες - εγκατέστησαν το Kubernetes, ανέπτυξαν την εφαρμογή - φαίνεται να λειτουργεί. Για πολλούς ανθρώπους αυτό είναι φυσιολογικό. Δεν θα ξέρουν καν ότι αυτή η εφαρμογή θα διακοπεί για κάποιο λόγο, δεν θα λάβουν ειδοποίηση, αλλά γι 'αυτούς αυτό είναι ο κανόνας. Προηγουμένως, ζούσαμε σε εικονικές μηχανές χωρίς παρακολούθηση, τώρα μετακομίσαμε στο Kubernetes, επίσης χωρίς παρακολούθηση - ποια είναι η διαφορά;
Το ερώτημα είναι ότι όταν περπατάμε πάνω στον πάγο, δεν γνωρίζουμε ποτέ το πάχος του, εκτός αν το μετρήσουμε εκ των προτέρων. Πολλοί άνθρωποι περπατούν και δεν ανησυχούν, γιατί έχουν περπατήσει στο παρελθόν.
Από την άποψή μου, η απόχρωση και η πολυπλοκότητα της λειτουργίας οποιουδήποτε συστήματος είναι να διασφαλίσουμε ότι το πάχος του πάγου είναι ακριβώς αρκετό για να λύσουμε τα προβλήματά μας. Αυτό είναι που μιλάμε.
Στο IT, μου φαίνεται, υπάρχουν πάρα πολλές προσεγγίσεις "θα είμαι τυχερός". Πολλοί άνθρωποι εγκαθιστούν λογισμικό και χρησιμοποιούν βιβλιοθήκες λογισμικού με την ελπίδα ότι θα σταθούν τυχεροί. Γενικά, πολλοί άνθρωποι είναι τυχεροί. Μάλλον γι' αυτό λειτουργεί.
— Από την απαισιόδοξη εκτίμησή μου, μοιάζει με αυτό: όταν οι κίνδυνοι είναι υψηλοί και η εφαρμογή πρέπει να λειτουργεί, τότε απαιτείται υποστήριξη από το Flaunt, ίσως από τη Red Hat, ή χρειάζεστε τη δική σας εσωτερική ομάδα αφιερωμένη ειδικά στην Kubernetes, η οποία είναι έτοιμη να το τραβήξεις.
Ντμίτρι: Αντικειμενικά, έτσι είναι. Το να μπείτε μόνοι σας στην ιστορία του Kubernetes για μια μικρή ομάδα εμπεριέχει διάφορους κινδύνους.
Χρειαζόμαστε δοχεία;
— Μπορείτε να μας πείτε πόσο διαδεδομένο είναι το Kubernetes στη Ρωσία;
Ντμίτρι: Δεν έχω αυτά τα δεδομένα και δεν είμαι σίγουρος ότι τα έχει κάποιος άλλος. Λέμε: "Kubernetes, Kubernetes", αλλά υπάρχει ένας άλλος τρόπος να δούμε αυτό το ζήτημα. Επίσης, δεν ξέρω πόσο διαδεδομένα είναι τα κοντέινερ, αλλά γνωρίζω έναν αριθμό από αναφορές στο Διαδίκτυο ότι το 70% των κοντέινερ ενορχηστρώνονται από την Kubernetes. Ήταν μια αξιόπιστη πηγή για ένα αρκετά μεγάλο δείγμα σε όλο τον κόσμο.
Στη συνέχεια, μια άλλη ερώτηση - χρειαζόμαστε δοχεία; Η προσωπική μου αίσθηση και η συνολική θέση της εταιρείας Flant είναι ότι το Kubernetes είναι ένα de facto πρότυπο.
Δεν θα υπάρχει τίποτα άλλο εκτός από Kubernetes.
Πρόκειται για μια απόλυτη αλλαγή παιχνιδιού στον τομέα της διαχείρισης υποδομών. Απλά απόλυτο - αυτό είναι, όχι πια Ansible, Chef, εικονικές μηχανές, Terraform. Δεν μιλάω για τις παλιές μεθόδους συλλογικής εκμετάλλευσης. Ο Kubernetes είναι ένας απόλυτος αλλαγή, και τώρα θα είναι μόνο έτσι.
Είναι σαφές ότι για κάποιους χρειάζονται μερικά χρόνια και για άλλους μερικές δεκαετίες για να το συνειδητοποιήσουν. Δεν έχω καμία αμφιβολία ότι δεν θα υπάρχει τίποτα άλλο εκτός από το Kubernetes και αυτή τη νέα εμφάνιση: δεν καταστρέφουμε πλέον το λειτουργικό σύστημα, αλλά χρησιμοποιούμε υποδομή ως κωδικός, μόνο όχι με κωδικό, αλλά με yml - μια υποδομή που περιγράφεται δηλωτικά. Έχω την αίσθηση ότι θα είναι πάντα έτσι.
— Δηλαδή, όσες εταιρείες δεν έχουν ακόμη μεταβεί στο Kubernetes σίγουρα θα στραφούν σε αυτό ή θα παραμείνουν στη λήθη. Σε καταλαβα καλα?
Ντμίτρι: Αυτό επίσης δεν είναι απολύτως αλήθεια. Για παράδειγμα, εάν έχουμε την εργασία να τρέξουμε έναν διακομιστή DNS, τότε μπορεί να εκτελεστεί στο FreeBSD 4.10 και μπορεί να λειτουργήσει τέλεια για 20 χρόνια. Απλά δούλεψε και τέλος. Ίσως σε 20 χρόνια κάτι θα χρειαστεί να ενημερωθεί μια φορά. Εάν μιλάμε για λογισμικό με τη μορφή που ξεκινήσαμε και στην πραγματικότητα λειτουργεί για πολλά χρόνια χωρίς ενημερώσεις, χωρίς αλλαγές, τότε, φυσικά, δεν θα υπάρχει Kubernetes. Δεν χρειάζεται εκεί.
Όλα όσα σχετίζονται με CI/CD - όπου χρειάζεται Συνεχής Παράδοση, όπου χρειάζεται να ενημερώσετε τις εκδόσεις, να κάνετε ενεργές αλλαγές, όπου χρειάζεται να δημιουργήσετε ανοχή σφαλμάτων - μόνο Kubernetes.
Σχετικά με τις μικροϋπηρεσίες
- Εδώ έχω μια μικρή παραφωνία. Για να εργαστείτε με το Kubernetes, χρειάζεστε εξωτερική ή εσωτερική υποστήριξη - αυτό είναι το πρώτο σημείο. Δεύτερον, όταν μόλις ξεκινάμε την ανάπτυξη, είμαστε μια μικρή startup, δεν έχουμε τίποτα ακόμα, η ανάπτυξη για την Kubernetes ή την αρχιτεκτονική microservice γενικά μπορεί να είναι δύσκολη και όχι πάντα οικονομικά δικαιολογημένη. Με ενδιαφέρει η γνώμη σας - οι νεοφυείς επιχειρήσεις πρέπει να αρχίσουν αμέσως να γράφουν για την Kubernetes από την αρχή ή μπορούν ακόμα να γράψουν ένα μονόλιθο και μετά να έρθουν μόνο στο Kubernetes;
Ντμίτρι: Ωραία ερώτηση. Έχω μια συζήτηση για τις μικροϋπηρεσίες Πολλές φορές έχω συναντήσει ανθρώπους που προσπαθούν να σφυρηλατήσουν καρφιά με μικροσκόπιο. Η ίδια η προσέγγιση είναι σωστή· εμείς οι ίδιοι σχεδιάζουμε το εσωτερικό μας λογισμικό με αυτόν τον τρόπο. Αλλά όταν το κάνετε αυτό, πρέπει να καταλάβετε ξεκάθαρα τι κάνετε. Η λέξη που μισώ περισσότερο για τις μικροϋπηρεσίες είναι "micro". Ιστορικά, αυτή η λέξη προήλθε από εκεί και για κάποιο λόγο οι άνθρωποι πιστεύουν ότι το micro είναι πολύ μικρό, λιγότερο από ένα χιλιοστό, όπως ένα μικρόμετρο. Αυτό είναι λάθος.
Για παράδειγμα, υπάρχει ένας μονόλιθος που είναι γραμμένος από 300 άτομα και όλοι όσοι συμμετείχαν στην ανάπτυξη καταλαβαίνουν ότι υπάρχουν προβλήματα και πρέπει να σπάσει σε μικρο-κομμάτια - περίπου 10 κομμάτια, καθένα από τα οποία είναι γραμμένο από 30 άτομα σε ελάχιστη έκδοση. Αυτό είναι σημαντικό, απαραίτητο και δροσερό. Αλλά όταν μας έρχεται μια startup, όπου 3 πολύ κουλ και ταλαντούχα παιδιά έγραψαν 60 microservices στα γόνατά τους, κάθε φορά που ψάχνω για Corvalol.
Μου φαίνεται ότι αυτό έχει ήδη μιλήσει χιλιάδες φορές - πήραμε έναν κατανεμημένο μονόλιθο με τη μία ή την άλλη μορφή. Αυτό δεν δικαιολογείται οικονομικά, είναι πολύ δύσκολο γενικά σε όλα. Απλώς το έχω δει τόσες φορές που με πονάει πραγματικά, γι' αυτό συνεχίζω να μιλάω γι' αυτό.
Στην αρχική ερώτηση, υπάρχει μια σύγκρουση μεταξύ του γεγονότος ότι, αφενός, το Kubernetes είναι τρομακτικό στη χρήση, επειδή δεν είναι σαφές τι μπορεί να σπάσει εκεί ή να μην λειτουργήσει, από την άλλη πλευρά, είναι σαφές ότι όλα πάνε εκεί. και τίποτα άλλο εκτός από Kubernetes δεν θα υπάρχει. Απάντηση - ζυγίστε το ποσό του οφέλους που έρχεται, το ποσό των εργασιών που μπορείτε να λύσετε. Αυτό είναι στη μία πλευρά της ζυγαριάς. Από την άλλη πλευρά, υπάρχουν κίνδυνοι που σχετίζονται με το χρόνο διακοπής λειτουργίας ή με τη μείωση του χρόνου απόκρισης, του επιπέδου διαθεσιμότητας - με τη μείωση των δεικτών απόδοσης.
Εδώ είναι - είτε κινούμαστε γρήγορα και το Kubernetes μας επιτρέπει να κάνουμε πολλά πράγματα πολύ πιο γρήγορα και καλύτερα, είτε χρησιμοποιούμε αξιόπιστες, δοκιμασμένες στο χρόνο λύσεις, αλλά κινούμαστε πολύ πιο αργά. Αυτή είναι μια επιλογή που πρέπει να κάνει κάθε εταιρεία. Μπορείτε να το σκεφτείτε ως ένα μονοπάτι στη ζούγκλα - όταν περπατήσετε για πρώτη φορά, μπορείτε να συναντήσετε ένα φίδι, μια τίγρη ή έναν τρελό ασβό, και όταν έχετε περπατήσει 10 φορές, έχετε πατήσει το μονοπάτι, αφαιρεθεί τα κλαδιά και περπατήστε πιο εύκολα. Κάθε φορά το μονοπάτι φαρδαίνει. Μετά είναι ένας ασφαλτοστρωμένος δρόμος, και αργότερα μια όμορφη λεωφόρος.
Το Kubernetes δεν μένει ακίνητο. Ερώτηση πάλι: Το Kubernetes, αφενός, είναι 4-5 δυαδικά, αφετέρου, είναι ολόκληρο το οικοσύστημα. Αυτό είναι το λειτουργικό σύστημα που έχουμε στα μηχανήματα μας. Τι είναι αυτό? Ubuntu ή Curios; Αυτός είναι ο πυρήνας του Linux, μια δέσμη πρόσθετων στοιχείων. Όλα αυτά εδώ, ένα δηλητηριώδες φίδι πετάχτηκε έξω από το δρόμο, χτίστηκε ένας φράχτης εκεί. Το Kubernetes αναπτύσσεται πολύ γρήγορα και δυναμικά και ο όγκος των κινδύνων, ο όγκος του αγνώστου μειώνεται κάθε μήνα και, κατά συνέπεια, αυτές οι κλίμακες εξισορροπούνται.
Απαντώντας στην ερώτηση τι πρέπει να κάνει μια εκκίνηση, θα έλεγα - ελάτε στο Flaunt, πληρώστε 150 χιλιάδες ρούβλια και αποκτήστε μια εύκολη υπηρεσία DevOps με το κλειδί στο χέρι. Εάν είστε μια μικρή startup με λίγους προγραμματιστές, αυτό λειτουργεί. Αντί να προσλάβετε τους δικούς σας DevOps, οι οποίοι θα πρέπει να μάθουν πώς να λύνουν τα προβλήματά σας και να πληρώνουν μισθό αυτή τη στιγμή, θα έχετε μια λύση με το κλειδί στο χέρι για όλα τα ζητήματα. Ναι, υπάρχουν κάποια μειονεκτήματα. Εμείς, ως outsourcer, δεν μπορούμε να συμμετέχουμε τόσο πολύ και να ανταποκρινόμαστε γρήγορα στις αλλαγές. Έχουμε όμως πολλή τεχνογνωσία και έτοιμες πρακτικές. Εγγυόμαστε ότι σε οποιαδήποτε κατάσταση σίγουρα θα το καταλάβουμε γρήγορα και θα αναστήσουμε οποιονδήποτε Kubernetes από τους νεκρούς.
Συνιστώ ανεπιφύλακτα την εξωτερική ανάθεση σε startups και καθιερωμένες επιχειρήσεις μέχρι ένα μέγεθος όπου μπορείτε να αφιερώσετε μια ομάδα 10 ατόμων σε λειτουργίες, γιατί διαφορετικά δεν έχει νόημα. Είναι σίγουρα λογικό να το αναθέσουμε σε τρίτους.
Σχετικά με την Amazon και την Google
— Μπορεί ένας οικοδεσπότης από μια λύση από την Amazon ή την Google να θεωρηθεί ως εξωτερική ανάθεση;
Ντμίτρι: Ναι, φυσικά, αυτό λύνει μια σειρά από ζητήματα. Αλλά και πάλι υπάρχουν αποχρώσεις. Πρέπει ακόμα να καταλάβετε πώς να το χρησιμοποιήσετε. Για παράδειγμα, υπάρχουν χίλια μικρά πράγματα στη δουλειά του Amazon AWS: το Load Balancer πρέπει να ζεσταθεί ή πρέπει να γραφτεί εκ των προτέρων ένα αίτημα ότι "παιδιά, θα λάβουμε κίνηση, ζεσταίνετε το Load Balancer για εμάς!" Πρέπει να γνωρίζετε αυτές τις αποχρώσεις.
Όταν απευθύνεσαι σε άτομα που ειδικεύονται σε αυτό, κλείνεις σχεδόν όλα τα τυπικά πράγματα. Τώρα έχουμε 40 μηχανικούς, μέχρι το τέλος του χρόνου θα είναι πιθανώς 60 - σίγουρα τα έχουμε συναντήσει όλα αυτά. Ακόμα κι αν συναντήσουμε ξανά αυτό το πρόβλημα σε κάποιο έργο, ρωτάμε γρήγορα ο ένας τον άλλον και ξέρουμε πώς να το λύσουμε.
Πιθανώς η απάντηση είναι - φυσικά, μια φιλοξενούμενη ιστορία κάνει κάποιο μέρος πιο εύκολο. Το ερώτημα είναι αν είστε έτοιμοι να εμπιστευτείτε αυτούς τους hosters και αν θα σας λύσουν τα προβλήματά σας. Η Amazon και η Google τα κατάφεραν καλά. Για όλες τις περιπτώσεις μας - ακριβώς. Δεν έχουμε άλλες θετικές εμπειρίες. Όλα τα άλλα σύννεφα με τα οποία προσπαθήσαμε να δουλέψουμε δημιουργούν πολλά προβλήματα - το Ager και ό,τι υπάρχει στη Ρωσία και όλα τα είδη OpenStack σε διαφορετικές υλοποιήσεις: Headster, Overage - ό,τι θέλετε. Όλα δημιουργούν προβλήματα που δεν θέλετε να λύσετε.
Επομένως, η απάντηση είναι ναι, αλλά, στην πραγματικότητα, δεν υπάρχουν πολλές ώριμες φιλοξενούμενες λύσεις.
Ποιος χρειάζεται το Kubernetes;
— Κι όμως, ποιος χρειάζεται την Kubernetes; Ποιος πρέπει ήδη να μεταβεί στο Kubernetes, ποιος είναι ο τυπικός πελάτης Flaunt που έρχεται ειδικά για το Kubernetes;
Ντμίτρι: Αυτή είναι μια ενδιαφέρουσα ερώτηση, γιατί αυτή τη στιγμή, στον απόηχο των Kubernetes, πολλοί άνθρωποι έρχονται σε εμάς: "Παιδιά, ξέρουμε ότι κάνετε Kubernetes, κάντε το για εμάς!" Τους απαντάμε: «Κύριοι, δεν κάνουμε Kubernetes, κάνουμε prod και ό,τι σχετίζεται με αυτό». Γιατί αυτή τη στιγμή είναι απλά αδύνατο να φτιάξεις ένα προϊόν χωρίς να κάνεις όλο το CI/CD και όλη αυτή την ιστορία. Όλοι έχουν απομακρυνθεί από τη διαίρεση ότι έχουμε ανάπτυξη με ανάπτυξη και μετά εκμετάλλευση με εκμετάλλευση.
Οι πελάτες μας περιμένουν διαφορετικά πράγματα, αλλά όλοι περιμένουν κάποιο καλό θαύμα που έχουν ορισμένα προβλήματα, και τώρα - hop! — Θα τα λύσει ο Kubernetes. Οι άνθρωποι πιστεύουν στα θαύματα. Στο μυαλό τους καταλαβαίνουν ότι δεν θα γίνει θαύμα, αλλά στην ψυχή τους ελπίζουν - τι κι αν αυτός ο Kubernetes θα μας λύσει τώρα τα πάντα, μιλάνε τόσο πολύ για αυτό! Ξαφνικά αυτός τώρα - φτάρνισμα! - και μια ασημένια σφαίρα, φτέρνισμα! — και έχουμε 100% χρόνο λειτουργίας, όλοι οι προγραμματιστές μπορούν να απελευθερώσουν ό,τι μπει στην παραγωγή 50 φορές και δεν χαλάει. Σε γενικές γραμμές, ένα θαύμα!
Όταν μας έρχονται τέτοιοι άνθρωποι, λέμε: «Συγγνώμη, αλλά δεν υπάρχει θαύμα». Για να είστε υγιείς, πρέπει να τρώτε καλά και να ασκείτε. Για να έχετε ένα αξιόπιστο προϊόν, πρέπει να κατασκευαστεί αξιόπιστα. Για να έχετε ένα βολικό CI/CD, πρέπει να το κάνετε έτσι. Είναι πολλή δουλειά που πρέπει να γίνει.
Απαντώντας στην ερώτηση ποιος χρειάζεται Kubernetes - κανείς δεν χρειάζεται Kubernetes.
Μερικοί άνθρωποι έχουν την εσφαλμένη αντίληψη ότι χρειάζονται Kubernetes. Οι άνθρωποι χρειάζονται, έχουν μια βαθιά ανάγκη να σταματήσουν να σκέφτονται, να μελετούν και να ενδιαφέρονται για όλα τα προβλήματα των υποδομών και τα προβλήματα λειτουργίας των εφαρμογών τους. Θέλουν οι εφαρμογές απλώς να λειτουργούν και απλώς να αναπτύσσονται. Για αυτούς, το Kubernetes είναι η ελπίδα ότι θα πάψουν να ακούν την ιστορία ότι «είμασταν ξαπλωμένοι εκεί», ή «δεν μπορούμε να κυκλοφορήσουμε» ή κάτι άλλο.
Ο τεχνικός διευθυντής έρχεται συνήθως σε εμάς. Του ζητούν δύο πράγματα: αφενός να μας δώσει χαρακτηριστικά αφετέρου τη σταθερότητα. Σας προτείνουμε να το πάρετε πάνω σας και να το κάνετε. Η ασημένια σφαίρα, ή μάλλον επαργυρωμένη, είναι ότι θα σταματήσετε να σκέφτεστε αυτά τα προβλήματα και να χάνετε χρόνο. Θα έχετε ειδικούς ανθρώπους που θα κλείσουν αυτό το θέμα.
Η διατύπωση ότι εμείς ή οποιοσδήποτε άλλος χρειαζόμαστε την Kubernetes είναι εσφαλμένη.
Οι διαχειριστές χρειάζονται πραγματικά το Kubernetes, γιατί είναι ένα πολύ ενδιαφέρον παιχνίδι με το οποίο μπορείς να παίξεις και να το πεις. Ας είμαστε ειλικρινείς - όλοι αγαπούν τα παιχνίδια. Είμαστε όλοι παιδιά κάπου, και όταν βλέπουμε ένα καινούργιο, θέλουμε να το παίξουμε. Για κάποιους, αυτό έχει αποθαρρυνθεί, για παράδειγμα, στη διοίκηση, επειδή έχουν ήδη παίξει αρκετά και είναι ήδη κουρασμένοι σε σημείο που απλά δεν θέλουν. Αλλά αυτό δεν χάνεται τελείως σε κανέναν. Για παράδειγμα, αν έχω βαρεθεί τα παιχνίδια στον τομέα της διαχείρισης συστημάτων και των DevOps εδώ και πολύ καιρό, τότε εξακολουθώ να λατρεύω τα παιχνίδια, εξακολουθώ να αγοράζω καινούργια. Όλοι οι άνθρωποι, με τον ένα ή τον άλλο τρόπο, εξακολουθούν να θέλουν κάποιο είδος παιχνιδιών.
Δεν χρειάζεται να παίζεις με την παραγωγή. Ό,τι συνιστώ κατηγορηματικά να μην κάνετε και αυτό που βλέπω τώρα μαζικά: "Ω, ένα νέο παιχνίδι!" — έτρεξαν να το αγοράσουν, το αγόρασαν και: «Ας το πάμε τώρα στο σχολείο να το δείξουμε σε όλους τους φίλους μας». Μην το κάνεις αυτό. Ζητώ συγγνώμη, τα παιδιά μου μόλις μεγαλώνουν, βλέπω συνέχεια κάτι στα παιδιά, το παρατηρώ στον εαυτό μου και μετά το γενικεύω στους άλλους.
Η τελική απάντηση είναι: δεν χρειάζεσαι Kubernetes. Πρέπει να λύσετε τα προβλήματά σας.
Αυτό που μπορείτε να πετύχετε είναι:
- prod δεν πέφτει?
- Ακόμα κι αν προσπαθήσει να πέσει, το γνωρίζουμε εκ των προτέρων και μπορούμε να βάλουμε κάτι μέσα.
- μπορούμε να το αλλάξουμε με την ταχύτητα με την οποία το απαιτεί η επιχείρησή μας και μπορούμε να το κάνουμε εύκολα· δεν μας δημιουργεί κανένα πρόβλημα.
Υπάρχουν δύο πραγματικές ανάγκες: αξιοπιστία και δυναμισμός/ευελιξία διάθεσης. Όλοι όσοι εκτελούν αυτήν τη στιγμή κάποιο είδος έργων πληροφορικής, ανεξάρτητα από το είδος της επιχείρησης - μαλακό για τη διευκόλυνση του κόσμου, και που το κατανοούν αυτό, πρέπει να λύσουν αυτές τις ανάγκες. Το Kubernetes με τη σωστή προσέγγιση, με τη σωστή κατανόηση και με αρκετή εμπειρία σας επιτρέπει να τα λύσετε.
Σχετικά με τον διακομιστή χωρίς διακομιστή
— Αν κοιτάξετε λίγο πιο μακριά στο μέλλον, προσπαθώντας να λύσετε το πρόβλημα της απουσίας πονοκεφάλων με υποδομές, με την ταχύτητα διάθεσης και την ταχύτητα αλλαγής της εφαρμογής, εμφανίζονται νέες λύσεις, για παράδειγμα, χωρίς διακομιστή. Νιώθετε κάποια δυνατότητα προς αυτή την κατεύθυνση και, ας πούμε, κίνδυνο για την Kubernetes και παρόμοιες λύσεις;
Ντμίτρι: Εδώ πρέπει να κάνουμε πάλι μια παρατήρηση ότι δεν είμαι μάντης που κοιτάω μπροστά και λέει - έτσι θα είναι! Αν και μόλις έκανα το ίδιο πράγμα. Κοιτάζω τα πόδια μου και βλέπω ένα σωρό προβλήματα εκεί, για παράδειγμα, πώς λειτουργούν τα τρανζίστορ σε έναν υπολογιστή. Είναι αστείο, σωστά; Αντιμετωπίζουμε κάποια σφάλματα στην CPU.
Κάντε χωρίς διακομιστές αρκετά αξιόπιστο, φθηνό, αποτελεσματικό και βολικό, επιλύοντας όλα τα ζητήματα οικοσυστήματος. Εδώ συμφωνώ με τον Elon Musk ότι χρειάζεται ένας δεύτερος πλανήτης για να δημιουργηθεί ανοχή σφαλμάτων για την ανθρωπότητα. Αν και δεν ξέρω τι λέει, καταλαβαίνω ότι δεν είμαι έτοιμος να πετάξω ο ίδιος στον Άρη και δεν θα συμβεί αύριο.
Με τον διακομιστή χωρίς διακομιστή είναι ξεκάθαρο ότι αυτό είναι ένα ιδεολογικά σωστό πράγμα, όπως η ανοχή σφαλμάτων για την ανθρωπότητα - το να έχεις δύο πλανήτες είναι καλύτερο από έναν. Αλλά πώς να το κάνουμε τώρα; Η αποστολή μιας αποστολής δεν είναι πρόβλημα εάν επικεντρώσετε τις προσπάθειές σας σε αυτήν. Η αποστολή πολλών αποστολών και η εγκατάσταση πολλών χιλιάδων ανθρώπων εκεί, νομίζω, είναι επίσης ρεαλιστική. Αλλά το να το κάνω εντελώς ανεκτικό σε σφάλματα, έτσι ώστε η μισή ανθρωπότητα να ζει εκεί, μου φαίνεται πλέον αδύνατο, χωρίς να το εξετάζω.
Με έναν προς έναν χωρίς διακομιστή: το πράγμα είναι ωραίο, αλλά απέχει πολύ από τα προβλήματα του 2019. Πιο κοντά στο 2030 - ας ζήσουμε για να το δούμε. Δεν έχω καμία αμφιβολία ότι θα ζήσουμε, σίγουρα θα ζήσουμε (επαναλάβετε πριν πάτε για ύπνο), αλλά τώρα πρέπει να λύσουμε άλλα προβλήματα. Είναι σαν να πιστεύεις στο παραμυθένιο πόνυ Rainbow. Ναι, ένα-δυο τοις εκατό των υποθέσεων λύνονται, και λύνονται τέλεια, αλλά υποκειμενικά, το ουράνιο τόξο χωρίς διακομιστή... Για μένα, αυτό το θέμα είναι πολύ μακρινό και πολύ ακατανόητο. Δεν είμαι έτοιμος να μιλήσω. Το 2019 δεν μπορείτε να γράψετε ούτε μία εφαρμογή χωρίς διακομιστή.
Πώς θα εξελιχθεί το Kubernetes
— Καθώς προχωράμε προς αυτό το δυνητικά υπέροχο μακρινό μέλλον, πώς πιστεύετε ότι θα αναπτυχθούν το Kubernetes και το οικοσύστημα γύρω του;
Ντμίτρι: Το έχω σκεφτεί πολύ αυτό και έχω ξεκάθαρη απάντηση. Το πρώτο είναι κρατικό - στο κάτω-κάτω, ο ανιθαγενής είναι πιο εύκολο να γίνει. Η Kubernetes αρχικά επένδυσε περισσότερα σε αυτό, όλα ξεκίνησαν από αυτό. Οι ανιθαγενείς δουλεύουν σχεδόν τέλεια στο Kubernetes, απλά δεν υπάρχει τίποτα για να παραπονεθεί. Υπάρχουν ακόμα πολλά προβλήματα, ή μάλλον, αποχρώσεις. Όλα εκεί λειτουργούν ήδη υπέροχα για εμάς, αλλά εμείς είμαστε. Θα χρειαστούν τουλάχιστον μερικά χρόνια ακόμη για να λειτουργήσει αυτό για όλους. Αυτό δεν είναι ένας υπολογισμένος δείκτης, αλλά η αίσθηση μου από το κεφάλι μου.
Εν ολίγοις, το statefull θα πρέπει - και θα - να αναπτυχθεί πολύ έντονα, επειδή όλες οι εφαρμογές μας αποθηκεύουν το καθεστώς, δεν υπάρχουν εφαρμογές ανιθαγενών. Αυτό είναι μια ψευδαίσθηση, χρειάζεστε πάντα κάποιο είδος βάσης δεδομένων και κάτι άλλο. Το Statefull έχει να κάνει με τη διόρθωση όλων των δυνατοτήτων, τη διόρθωση όλων των σφαλμάτων, τη βελτίωση όλων των προβλημάτων που αντιμετωπίζονται αυτήν τη στιγμή - ας το ονομάσουμε υιοθέτηση.
Το επίπεδο του αγνώστου, το επίπεδο των άλυτων προβλημάτων, το επίπεδο της πιθανότητας να συναντήσετε κάτι θα πέσει σημαντικά. Αυτή είναι μια σημαντική ιστορία. Και χειριστές - ό,τι σχετίζεται με την κωδικοποίηση της λογικής διαχείρισης, λογική ελέγχου για να λάβουμε μια εύκολη υπηρεσία: MySQL easy service, RabbitMQ easy service, Memcache easy service - γενικά, όλα αυτά τα στοιχεία που χρειαζόμαστε εγγυημένα την επεξεργασία το κιβώτιο. Αυτό απλώς λύνει τον πόνο που θέλουμε μια βάση δεδομένων, αλλά δεν θέλουμε να τη διαχειριζόμαστε ή θέλουμε το Kubernetes, αλλά δεν θέλουμε να τη διαχειριστούμε.
Αυτή η ιστορία ανάπτυξης χειριστή με τη μία ή την άλλη μορφή θα είναι σημαντική τα επόμενα δύο χρόνια.
Νομίζω ότι η ευκολία χρήσης θα πρέπει να αυξηθεί πολύ - το κουτί θα γίνεται όλο και πιο μαύρο, όλο και πιο αξιόπιστο, με όλο και πιο απλά πόμολα.
Κάποτε άκουσα μια παλιά συνέντευξη με τον Isaac Asimov από τη δεκαετία του '80 στο YouTube στο Saturday Night Live - ένα πρόγραμμα όπως το Urgant, μόνο ενδιαφέρον. Τον ρώτησαν για το μέλλον των υπολογιστών. Είπε ότι το μέλλον είναι στην απλότητα, όπως και το ραδιόφωνο. Ο ραδιοφωνικός δέκτης ήταν αρχικά ένα πολύπλοκο πράγμα. Για να πιάσεις ένα κύμα, έπρεπε να γυρίσεις τα πόμολα για 15 λεπτά, να γυρίσεις τα σουβλάκια και γενικά να ξέρεις πώς λειτουργούν όλα, να καταλάβεις τη φυσική της μετάδοσης ραδιοκυμάτων. Ως αποτέλεσμα, έμεινε μόνο ένα κουμπί στο ραδιόφωνο.
Τώρα το 2019 ποιο ραδιόφωνο; Στο αυτοκίνητο, ο ραδιοφωνικός δέκτης βρίσκει όλα τα κύματα και τα ονόματα των σταθμών. Η φυσική της διαδικασίας δεν έχει αλλάξει εδώ και 100 χρόνια, αλλά η ευκολία χρήσης έχει αλλάξει. Τώρα, και όχι μόνο τώρα, ήδη από το 1980, όταν έγινε μια συνέντευξη με τον Azimov, όλοι χρησιμοποιούσαν το ραδιόφωνο και κανείς δεν σκεφτόταν πώς λειτουργούσε. Πάντα δούλευε - αυτό είναι δεδομένο.
Ο Azimov είπε τότε ότι θα ήταν το ίδιο με τους υπολογιστές - η ευκολία χρήσης θα αυξηθεί. Ενώ το 1980 έπρεπε να εκπαιδευτείτε στο να πατάτε κουμπιά σε έναν υπολογιστή, αυτό δεν θα συμβαίνει στο μέλλον.
Έχω την αίσθηση ότι με το Kubernetes και με την υποδομή θα υπάρξει επίσης τεράστια αύξηση στην ευκολία χρήσης. Αυτό, κατά τη γνώμη μου, είναι προφανές - βρίσκεται στην επιφάνεια.
Τι να κάνετε με τους μηχανικούς;
— Τι θα συμβεί τότε με τους μηχανικούς και τους διαχειριστές συστημάτων που υποστηρίζουν την Kubernetes;
Ντμίτρι: Τι συνέβη με τον λογιστή μετά την έλευση του 1C; Περίπου το ίδιο. Πριν από αυτό, μετρούσαν στα χαρτιά - τώρα στο πρόγραμμα. Η παραγωγικότητα της εργασίας έχει αυξηθεί κατά τάξεις μεγέθους, αλλά η ίδια η εργασία δεν έχει εξαφανιστεί. Αν παλαιότερα χρειάζονταν 10 μηχανικοί για να βιδώσουν μια λάμπα, τώρα ένας θα είναι αρκετός.
Η ποσότητα του λογισμικού και ο αριθμός των εργασιών, μου φαίνεται, αυξάνεται τώρα με ταχύτερο ρυθμό από ό,τι εμφανίζονται τα νέα DevOps και η αποτελεσματικότητα αυξάνεται. Υπάρχει μια συγκεκριμένη έλλειψη στην αγορά αυτή τη στιγμή και θα διαρκέσει πολύ. Αργότερα, όλα θα επιστρέψουν σε κάποιο είδος κανονικότητας, στην οποία η αποτελεσματικότητα της εργασίας θα αυξηθεί, θα υπάρχουν όλο και περισσότεροι χωρίς διακομιστές, ένας νευρώνας θα προσαρτηθεί στο Kubernetes, ο οποίος θα επιλέξει όλους τους πόρους ακριβώς όπως χρειάζεται και γενικά κάντε τα πάντα μόνοι σας, όπως θα έπρεπε - το άτομο απλώς απομακρυνθείτε και μην ανακατευτείτε.
Αλλά κάποιος θα πρέπει ακόμα να πάρει αποφάσεις. Είναι σαφές ότι το επίπεδο των προσόντων και της εξειδίκευσης αυτού του ατόμου είναι υψηλότερο. Στις μέρες μας στο λογιστήριο δεν χρειάζονται 10 υπάλληλοι να κρατούν βιβλία για να μην κουράζουν τα χέρια τους. Απλώς δεν είναι απαραίτητο. Πολλά έγγραφα σαρώνονται αυτόματα και αναγνωρίζονται από το ηλεκτρονικό σύστημα διαχείρισης εγγράφων. Ένας έξυπνος αρχιλογιστής αρκεί, ήδη με πολύ μεγαλύτερες δεξιότητες, με καλή κατανόηση.
Γενικά, αυτός είναι ο τρόπος που πρέπει να ακολουθηθεί σε όλους τους κλάδους. Είναι το ίδιο με τα αυτοκίνητα: προηγουμένως, ένα αυτοκίνητο ήρθε με έναν μηχανικό και τρεις οδηγούς. Στις μέρες μας, η οδήγηση αυτοκινήτου είναι μια απλή διαδικασία στην οποία συμμετέχουμε όλοι καθημερινά. Κανείς δεν πιστεύει ότι ένα αυτοκίνητο είναι κάτι περίπλοκο.
Η τεχνολογία DevOps ή συστημάτων δεν θα εξαφανιστεί - η εργασία υψηλού επιπέδου και η αποτελεσματικότητα θα αυξηθούν.
— Άκουσα επίσης μια ενδιαφέρουσα ιδέα ότι η δουλειά θα αυξηθεί πραγματικά.
Ντμίτρι: Φυσικά, εκατό τοις εκατό! Επειδή ο όγκος του λογισμικού που γράφουμε αυξάνεται συνεχώς. Ο αριθμός των προβλημάτων που επιλύουμε με το λογισμικό αυξάνεται συνεχώς. Ο όγκος της δουλειάς αυξάνεται. Τώρα η αγορά DevOps είναι τρομερά υπερθερμασμένη. Αυτό φαίνεται στις προσδοκίες μισθών. Με την καλή έννοια, χωρίς να υπεισέλθω σε λεπτομέρειες, θα πρέπει να υπάρχουν juniors που θέλουν X, μεσαίοι που θέλουν 1,5X και ανώτεροι που θέλουν 2X. Και τώρα, αν κοιτάξετε την αγορά μισθών DevOps της Μόσχας, ένας κατώτερος θέλει από Χ έως 3Χ και ένας ανώτερος θέλει από Χ έως 3Χ.
Κανείς δεν ξέρει πόσο κοστίζει. Το επίπεδο μισθού μετριέται με την εμπιστοσύνη σας - ένα πλήρες τρελοκομείο, για να είμαι ειλικρινής, μια τρομερά υπερθερμασμένη αγορά.
Φυσικά, αυτή η κατάσταση θα αλλάξει πολύ σύντομα - θα πρέπει να επέλθει κάποιος κορεσμός. Αυτό δεν συμβαίνει με την ανάπτυξη λογισμικού - παρά το γεγονός ότι όλοι χρειάζονται προγραμματιστές και όλοι χρειάζονται καλούς προγραμματιστές, η αγορά καταλαβαίνει ποιος αξίζει τι - η βιομηχανία έχει κατασταλάξει. Αυτό δεν συμβαίνει με τα DevOps αυτές τις μέρες.
— Από ό,τι άκουσα, κατέληξα στο συμπέρασμα ότι ο τρέχων διαχειριστής συστήματος δεν πρέπει να ανησυχεί πάρα πολύ, αλλά είναι καιρός να αναβαθμίσει τις δεξιότητές του και να προετοιμαστεί για το γεγονός ότι αύριο θα υπάρχει περισσότερη δουλειά, αλλά θα είναι πιο υψηλά προσόντα.
Ντμίτρι: Εκατό τοις εκατό. Γενικά, ζούμε στο 2019 και ο κανόνας της ζωής είναι αυτός: δια βίου μάθηση - μαθαίνουμε σε όλη μας τη ζωή. Μου φαίνεται ότι τώρα όλοι το γνωρίζουν και το νιώθουν αυτό, αλλά δεν αρκεί να το ξέρεις - πρέπει να το κάνεις. Κάθε μέρα πρέπει να αλλάζουμε. Αν δεν το κάνουμε αυτό, τότε αργά ή γρήγορα θα πέσουμε στο περιθώριο του επαγγέλματος.
Να είστε προετοιμασμένοι για απότομες στροφές 180 μοιρών. Δεν αποκλείω μια κατάσταση όπου κάτι αλλάζει ριζικά, κάτι νέο επινοείται - συμβαίνει. Λυκίσκος! - και τώρα ενεργούμε διαφορετικά. Είναι σημαντικό να είστε προετοιμασμένοι για αυτό και να μην ανησυχείτε. Μπορεί να συμβεί ότι αύριο ό,τι κάνω θα αποδειχθεί περιττό - τίποτα, έχω σπουδάσει όλη μου τη ζωή και είμαι έτοιμος να μάθω κάτι άλλο. Δεν είναι πρόβλημα. Δεν χρειάζεται να φοβάστε την ασφάλεια της εργασίας, αλλά πρέπει να είστε προετοιμασμένοι να μαθαίνετε συνεχώς κάτι νέο.
Ευχές και ένα λεπτό διαφήμιση
- Έχεις κάποια επιθυμία;
Ντμίτρι: Ναι, έχω πολλές ευχές.
Πρώτη και εμπορική - εγγραφείτε σε . Αγαπητοί αναγνώστες, μπείτε στο YouTube και εγγραφείτε στο κανάλι μας. Σε περίπου ένα μήνα θα ξεκινήσουμε την ενεργό επέκταση της υπηρεσίας βίντεο. Θα έχουμε πολύ εκπαιδευτικό περιεχόμενο για το Kubernetes, ανοιχτό και ποικίλο: από πρακτικά πράγματα, μέχρι εργαστήρια, έως βαθιά θεμελιώδη θεωρητικά πράγματα και πώς να χρησιμοποιείτε το Kubernetes στο επίπεδο αρχών και προτύπων.
Η δεύτερη εμπορική επιθυμία - πηγαίνετε στο και βάλε αστέρια γιατί τρεφόμαστε με αυτά. Αν δεν μας δώσεις αστέρια, δεν θα έχουμε να φάμε. Είναι σαν μάνα σε ένα παιχνίδι υπολογιστή. Κάνουμε κάτι, κάνουμε, προσπαθούμε, κάποιος λέει ότι αυτά είναι τρομερά ποδήλατα, κάποιος ότι όλα είναι εντελώς λάθος, αλλά συνεχίζουμε και ενεργούμε απολύτως ειλικρινά. Βλέπουμε ένα πρόβλημα, το λύνουμε και μοιραζόμαστε την εμπειρία μας. Γι' αυτό, δώστε μας ένα αστέρι, δεν θα φύγει από εσάς, αλλά θα έρθει σε εμάς, γιατί τρεφόμαστε με αυτά.
Τρίτη, σημαντική και όχι πλέον εμπορική επιθυμία - σταματήστε να πιστεύετε στα παραμύθια. Είστε επαγγελματίες. Το DevOps είναι ένα πολύ σοβαρό και υπεύθυνο επάγγελμα. Σταματήστε να παίζετε στο χώρο εργασίας. Αφήστε το να κάνει κλικ για εσάς και θα το καταλάβετε. Φανταστείτε ότι έρχεστε στο νοσοκομείο και εκεί ο γιατρός πειραματίζεται πάνω σας. Καταλαβαίνω ότι αυτό μπορεί να είναι προσβλητικό για κάποιον, αλλά, πιθανότατα, δεν πρόκειται για εσάς, αλλά για κάποιον άλλο. Πες και στους άλλους να σταματήσουν. Αυτό πραγματικά καταστρέφει τη ζωή για όλους μας - πολλοί αρχίζουν να αντιμετωπίζουν τις λειτουργίες, τους διαχειριστές και τους DevOps ως μάγκες που έχουν σπάσει κάτι ξανά. Αυτό «έσπασε» τις περισσότερες φορές λόγω του γεγονότος ότι πήγαμε να παίξουμε και δεν κοιτούσαμε με ψυχρή συνείδηση ότι έτσι είναι, και έτσι είναι.
Αυτό δεν σημαίνει ότι δεν πρέπει να πειραματιστείτε. Πρέπει να πειραματιστούμε, το κάνουμε μόνοι μας. Για να είμαστε ειλικρινείς, εμείς οι ίδιοι μερικές φορές παίζουμε παιχνίδια - αυτό, φυσικά, είναι πολύ κακό, αλλά τίποτα ανθρώπινο δεν μας είναι ξένο. Ας κηρύξουμε το 2019 έτος σοβαρών, καλά μελετημένων πειραμάτων και όχι παιχνιδιών στην παραγωγή. Μάλλον έτσι.
- Ευχαριστώ πολύ!
Ντμίτρι: Ευχαριστώ, Vitaly, τόσο για τον χρόνο όσο και για τη συνέντευξη. Αγαπητοί αναγνώστες, σας ευχαριστώ πολύ αν φθάσατε ξαφνικά σε αυτό το σημείο. Ελπίζω να σας φέραμε τουλάχιστον μερικές σκέψεις.
Στη συνέντευξη, ο Ντμίτρι έθιξε το θέμα του werf. Τώρα αυτό είναι ένα καθολικό ελβετικό μαχαίρι που λύνει σχεδόν όλα τα προβλήματα. Όμως δεν ήταν πάντα έτσι. Επί στο πανηγύρι Ο Ντμίτρι Στολιάροφ θα σας πει λεπτομερώς για αυτό το εργαλείο. στην έκθεση θα υπάρχουν τα πάντα: προβλήματα και κρυφές αποχρώσεις του Kubernetes, επιλογές για την επίλυση αυτών των δυσκολιών και η τρέχουσα εφαρμογή του werf λεπτομερώς. Ελάτε μαζί μας στις 27 και 28 Μαΐου, θα δημιουργήσουμε τα τέλεια εργαλεία.
Πηγή: www.habr.com