Πλατφόρμα σας επιτρέπει να απλοποιήσετε τη δημιουργία , συμπεριλαμβανομένης της υποδομής παρόχων υπηρεσιών cloud, σε πλατφόρμες εικονικοποίησης ή σε συστήματα γυμνού μετάλλου. Για να δημιουργήσουμε μια πραγματικά βασισμένη στο cloud πλατφόρμα, έπρεπε να λάβουμε αυστηρό έλεγχο όλων των στοιχείων που χρησιμοποιήθηκαν και έτσι να αυξήσουμε την αξιοπιστία μιας πολύπλοκης διαδικασίας αυτοματισμού.
Η προφανής λύση ήταν η χρήση του Red Hat Enterprise Linux CoreOS (μια παραλλαγή του Red Hat Enterprise Linux) και του CRI-O ως πρότυπο, και να γιατί...
Δεδομένου ότι το θέμα της ιστιοπλοΐας είναι πολύ καλό για την εύρεση αναλογιών κατά την εξήγηση της εργασίας των Kubernetes και των κοντέινερ, ας προσπαθήσουμε να μιλήσουμε για τα επιχειρηματικά προβλήματα που επιλύουν το CoreOS και το CRI-O, χρησιμοποιώντας ένα παράδειγμα . Το 1803, ο Marc Brunel επιφορτίστηκε με την παραγωγή 100 τεμαχίων ξάρτια για τις ανάγκες του αναπτυσσόμενου βρετανικού ναυτικού. Το μπλοκ αρματωσιάς είναι ένας τύπος αρματωσιάς που χρησιμοποιείται για την τοποθέτηση σχοινιών σε πανιά. Μέχρι τις αρχές του 19ου αιώνα, αυτά τα μπλοκ κατασκευάζονταν στο χέρι, αλλά ο Brunel κατάφερε να αυτοματοποιήσει την παραγωγή και άρχισε να παράγει τυποποιημένα μπλοκ χρησιμοποιώντας εργαλειομηχανές. Η αυτοματοποίηση αυτής της διαδικασίας σήμαινε ότι τα μπλοκ που προέκυψαν ήταν ουσιαστικά πανομοιότυπα, μπορούσαν να αντικατασταθούν εύκολα εάν σπάσουν και μπορούσαν να παραχθούν σε μεγάλες ποσότητες.
Τώρα φανταστείτε αν ο Brunel έπρεπε να κάνει αυτή τη δουλειά για 20 διαφορετικά μοντέλα πλοίων (εκδόσεις Kubernetes) και για πέντε διαφορετικούς πλανήτες με εντελώς διαφορετικά θαλάσσια ρεύματα και ανέμους (παρόχους σύννεφων). Επιπλέον, απαιτούνταν όλα τα πλοία (συστάδες OpenShift), ανεξάρτητα από τους πλανήτες στους οποίους εκτελείται η πλοήγηση, από την πλευρά των καπεταναίων (χειριστές που διαχειρίζονται τη λειτουργία των συστάδων) να συμπεριφέρονται το ίδιο. Για να συνεχίσουμε τη θαλάσσια αναλογία, οι καπετάνιοι πλοίων δεν ενδιαφέρονται καθόλου για το τι είδους μπλοκ ξάρτια (CRI-O) χρησιμοποιούνται στα πλοία τους - το κύριο πράγμα για αυτούς είναι ότι αυτά τα μπλοκ είναι ισχυρά και αξιόπιστα.
Το OpenShift 4, ως πλατφόρμα cloud, αντιμετωπίζει μια πολύ παρόμοια επιχειρηματική πρόκληση. Πρέπει να δημιουργηθούν νέοι κόμβοι τη στιγμή της δημιουργίας του συμπλέγματος, σε περίπτωση αποτυχίας σε έναν από τους κόμβους ή κατά την κλιμάκωση του συμπλέγματος. Όταν δημιουργείται και αρχικοποιείται ένας νέος κόμβος, τα κρίσιμα στοιχεία κεντρικού υπολογιστή, συμπεριλαμβανομένου του CRI-O, πρέπει να ρυθμιστούν ανάλογα. Όπως σε κάθε άλλη παραγωγή, οι «πρώτες ύλες» πρέπει να παρέχονται στην αρχή. Στην περίπτωση των πλοίων οι πρώτες ύλες είναι μέταλλο και ξύλο. Ωστόσο, στην περίπτωση δημιουργίας ενός κεντρικού υπολογιστή για την ανάπτυξη κοντέινερ σε ένα σύμπλεγμα OpenShift 4, πρέπει να έχετε αρχεία διαμόρφωσης και διακομιστές που παρέχονται από το API ως είσοδο. Στη συνέχεια, το OpenShift θα παρέχει το απαιτούμενο επίπεδο αυτοματισμού καθ' όλη τη διάρκεια του κύκλου ζωής, προσφέροντας την απαραίτητη υποστήριξη προϊόντων στους τελικούς χρήστες και έτσι θα αποσβέσει την επένδυση στην πλατφόρμα.
Το OpenShift 4 δημιουργήθηκε με τέτοιο τρόπο ώστε να παρέχει τη δυνατότητα βολικής ενημέρωσης του συστήματος καθ' όλη τη διάρκεια του κύκλου ζωής της πλατφόρμας (για τις εκδόσεις 4.X) για όλους τους μεγάλους παρόχους υπολογιστικού νέφους, πλατφόρμες εικονικοποίησης και ακόμη και συστήματα γυμνού μετάλλου. Για να γίνει αυτό, πρέπει να δημιουργηθούν κόμβοι με βάση εναλλάξιμα στοιχεία. Όταν ένα σύμπλεγμα απαιτεί μια νέα έκδοση του Kubernetes, λαμβάνει επίσης την αντίστοιχη έκδοση του CRI-O στο CoreOS. Δεδομένου ότι η έκδοση CRI-O συνδέεται απευθείας με το Kubernetes, αυτό απλοποιεί σημαντικά τυχόν μεταθέσεις για σκοπούς δοκιμής, αντιμετώπισης προβλημάτων ή υποστήριξης. Επιπλέον, αυτή η προσέγγιση μειώνει το κόστος για τους τελικούς χρήστες και το Red Hat.
Αυτός είναι ένας θεμελιωδώς νέος τρόπος σκέψης για τα συμπλέγματα Kubernetes και θέτει τα θεμέλια για τον σχεδιασμό ορισμένων πολύ χρήσιμων και συναρπαστικών νέων χαρακτηριστικών. Το CRI-O (Container Runtime Interface - Open Container Initiative, συντομογραφία CRI-OCI) αποδείχθηκε ότι ήταν η πιο επιτυχημένη επιλογή για τη μαζική δημιουργία κόμβων που είναι απαραίτητοι για την εργασία με το OpenShift. Το CRI-O θα αντικαταστήσει τον κινητήρα Docker που χρησιμοποιήθηκε στο παρελθόν, προσφέροντας στους χρήστες του OpenShift – ναι, καλά ακούσατε – ένας βαρετός κινητήρας κοντέινερ που δημιουργήθηκε ειδικά για εργασία με Kubernetes.
Ο κόσμος των ανοιχτών κοντέινερ
Ο κόσμος έχει κινηθεί προς ανοιχτά κοντέινερ εδώ και πολύ καιρό. Είτε στο Kubernetes είτε σε χαμηλότερα επίπεδα, έχει ως αποτέλεσμα ένα οικοσύστημα καινοτομίας σε κάθε επίπεδο.
Όλα ξεκίνησαν με τη δημιουργία του Open Containers Initiative . Σε αυτό το πρώιμο στάδιο της εργασίας, διαμορφώθηκαν οι προδιαγραφές των εμπορευματοκιβωτίων и . Αυτό εξασφάλιζε ότι τα εργαλεία θα μπορούσαν να χρησιμοποιούν ένα ενιαίο πρότυπο και μια ενοποιημένη μορφή εργασίας μαζί τους. Οι προδιαγραφές προστέθηκαν αργότερα , επιτρέποντας στους χρήστες να μοιράζονται εύκολα .
Στη συνέχεια, η κοινότητα Kubernetes ανέπτυξε ένα ενιαίο πρότυπο για μια συνδεόμενη διεπαφή, που ονομάζεται . Χάρη σε αυτό, οι χρήστες του Kubernetes μπόρεσαν να συνδέσουν διάφορους κινητήρες για να εργαστούν με κοντέινερ εκτός από το Docker.
Οι μηχανικοί της Red Hat και της Google είδαν την ανάγκη της αγοράς για μια μηχανή κοντέινερ που θα μπορούσε να δέχεται αιτήματα Kubelet μέσω του πρωτοκόλλου CRI και εισήγαγαν κοντέινερ που ήταν συμβατά με τις προδιαγραφές OCI που αναφέρονται παραπάνω. Έτσι . Αλλά με συγχωρείτε, δεν είπαμε ότι αυτό το υλικό θα ήταν αφιερωμένο στο CRI-O; Στην πραγματικότητα είναι, μόλις με την κυκλοφορία το έργο μετονομάστηκε σε CRI-O.
Σχήμα. 1.
Καινοτομία με CRI-O και CoreOS
Με την κυκλοφορία της πλατφόρμας OpenShift 4, άλλαξε , που χρησιμοποιείται από προεπιλογή στην πλατφόρμα και το Docker αντικαταστάθηκε από το CRI-O, προσφέροντας ένα οικονομικά αποδοτικό, σταθερό, απλό και βαρετό περιβάλλον για τη λειτουργία ενός κοντέινερ που αναπτύσσεται παράλληλα με το Kubernetes. Αυτό απλοποιεί σημαντικά την υποστήριξη και τη διαμόρφωση συμπλέγματος. Η διαμόρφωση του κινητήρα κοντέινερ και του κεντρικού υπολογιστή, καθώς και η διαχείρισή τους, γίνεται αυτοματοποιημένη στο OpenShift 4.
Περιμένετε, πώς είναι αυτό;
Σωστά, με την εμφάνιση του OpenShift 4, δεν υπάρχει πλέον ανάγκη σύνδεσης με μεμονωμένους κεντρικούς υπολογιστές και εγκατάσταση μηχανής κοντέινερ, διαμόρφωση αποθήκευσης, διαμόρφωση διακομιστών αναζήτησης ή διαμόρφωση δικτύου. Η πλατφόρμα OpenShift 4 έχει επανασχεδιαστεί πλήρως για να το χρησιμοποιεί όχι μόνο όσον αφορά τις εφαρμογές τελικού χρήστη, αλλά και όσον αφορά τις βασικές λειτουργίες σε επίπεδο πλατφόρμας, όπως η ανάπτυξη εικόνων, η διαμόρφωση του συστήματος ή η εγκατάσταση ενημερώσεων.
Το Kubernetes επέτρεπε πάντα στους χρήστες να διαχειρίζονται εφαρμογές ορίζοντας την επιθυμητή κατάσταση και χρησιμοποιώντας , για να διασφαλιστεί ότι η πραγματική κατάσταση ταιριάζει όσο το δυνατόν περισσότερο με την κατάσταση στόχο. Αυτό ανοίγει μεγάλες ευκαιρίες τόσο από αναπτυξιακή όσο και από επιχειρησιακή προοπτική. Οι προγραμματιστές μπορούν να ορίσουν την απαιτούμενη κατάσταση με στον χειριστή με τη μορφή αρχείου YAML ή JSON και, στη συνέχεια, ο χειριστής μπορεί να δημιουργήσει την απαιτούμενη παρουσία εφαρμογής στο περιβάλλον παραγωγής και η κατάσταση λειτουργίας αυτής της παρουσίας θα αντιστοιχεί πλήρως στην καθορισμένη.
Χρησιμοποιώντας Operators στην πλατφόρμα, το OpenShift 4 φέρνει αυτό το νέο παράδειγμα (χρησιμοποιώντας την έννοια του συνόλου και της πραγματικής κατάστασης) στη διαχείριση των RHEL CoreOS και CRI-O. Οι εργασίες διαμόρφωσης και διαχείρισης εκδόσεων του λειτουργικού συστήματος και του κινητήρα κοντέινερ αυτοματοποιούνται χρησιμοποιώντας το λεγόμενο . Το MCO απλοποιεί σημαντικά το έργο του διαχειριστή του συμπλέγματος, αυτοματοποιώντας ουσιαστικά τα τελευταία στάδια εγκατάστασης, καθώς και τις επόμενες λειτουργίες μετά την εγκατάσταση (λειτουργίες δεύτερης ημέρας). Όλα αυτά κάνουν το OpenShift 4 μια πραγματική πλατφόρμα cloud. Θα ασχοληθούμε με αυτό λίγο αργότερα.
Κοντέινερ που τρέχουν
Οι χρήστες είχαν την ευκαιρία να χρησιμοποιήσουν τη μηχανή CRI-O στην πλατφόρμα OpenShift από την έκδοση 3.7 στην κατάσταση Tech Preview και από την έκδοση 3.9 στην κατάσταση Generally Available (υποστηρίζεται αυτήν τη στιγμή). Επιπλέον, η Red Hat χρησιμοποιεί μαζικά στο OpenShift Online από την έκδοση 3.10. Όλα αυτά επέτρεψαν στην ομάδα που εργαζόταν στο CRI-O να αποκτήσει εκτενή εμπειρία στη μαζική εκτόξευση κοντέινερ σε μεγάλα συμπλέγματα Kubernetes. Για να έχουμε μια βασική κατανόηση του τρόπου με τον οποίο η Kubernetes χρησιμοποιεί το CRI-O, ας δούμε την παρακάτω εικόνα, η οποία δείχνει πώς λειτουργεί η αρχιτεκτονική.
Ρύζι. 2. Πώς λειτουργούν τα κοντέινερ σε ένα σύμπλεγμα Kubernetes
Το CRI-O απλοποιεί τη δημιουργία νέων κεντρικών υπολογιστών κοντέινερ συγχρονίζοντας ολόκληρο το ανώτερο επίπεδο κατά την προετοιμασία νέων κόμβων και κατά την κυκλοφορία νέων εκδόσεων της πλατφόρμας OpenShift. Η αναθεώρηση ολόκληρης της πλατφόρμας επιτρέπει ενημερώσεις/επιστροφές συναλλαγών και επίσης αποτρέπει αδιέξοδα στις εξαρτήσεις μεταξύ του πυρήνα της ουράς κοντέινερ, του κινητήρα κοντέινερ, των κόμβων (Kubelets) και του Κύριου κόμβου Kubernetes. Με την κεντρική διαχείριση όλων των στοιχείων πλατφόρμας, με έλεγχο και έκδοση εκδόσεων, υπάρχει πάντα μια σαφής διαδρομή από την κατάσταση Α στην κατάσταση Β. Αυτό απλοποιεί τη διαδικασία ενημέρωσης, βελτιώνει την ασφάλεια, βελτιώνει την αναφορά απόδοσης και συμβάλλει στη μείωση του κόστους των ενημερώσεων και των εγκαταστάσεων νέων εκδόσεων .
Επίδειξη της ισχύος των ανταλλακτικών στοιχείων
Όπως αναφέρθηκε προηγουμένως, η χρήση του Machine Config Operator για τη διαχείριση του κεντρικού υπολογιστή κοντέινερ και του κινητήρα κοντέινερ στο OpenShift 4 παρέχει ένα νέο επίπεδο αυτοματισμού που δεν ήταν προηγουμένως δυνατό στην πλατφόρμα Kubernetes. Για να δείξουμε τις νέες δυνατότητες, θα δείξουμε πώς μπορείτε να κάνετε αλλαγές στο αρχείο crio.conf. Για να μην μπερδευτείτε από την ορολογία, προσπαθήστε να εστιάσετε στα αποτελέσματα.
Αρχικά, ας δημιουργήσουμε αυτό που ονομάζεται διαμόρφωση χρόνου εκτέλεσης κοντέινερ - Configuration Runtime Container. Σκεφτείτε το ως έναν πόρο Kubernetes που αντιπροσωπεύει τη διαμόρφωση για το CRI-O. Στην πραγματικότητα, είναι μια εξειδικευμένη έκδοση κάτι που ονομάζεται MachineConfig, το οποίο είναι οποιαδήποτε διαμόρφωση που αναπτύσσεται σε μια μηχανή RHEL CoreOS ως μέρος ενός συμπλέγματος OpenShift.
Αυτός ο προσαρμοσμένος πόρος, που ονομάζεται ContainerRuntimeConfig, δημιουργήθηκε για να διευκολύνει τους διαχειριστές συμπλέγματος να διαμορφώσουν το CRI-O. Αυτό το εργαλείο είναι αρκετά ισχυρό ώστε να μπορεί να εφαρμοστεί μόνο σε ορισμένους κόμβους ανάλογα με τις ρυθμίσεις του MachineConfigPool. Σκεφτείτε το ως μια ομάδα μηχανών που εξυπηρετούν τον ίδιο σκοπό.
Παρατηρήστε τις δύο τελευταίες γραμμές που πρόκειται να αλλάξουμε στο αρχείο /etc/crio/crio.conf. Αυτές οι δύο γραμμές μοιάζουν πολύ με τις γραμμές στο αρχείο crio.conf, είναι:
vi ContainerRuntimeConfig.yaml
Συμπέρασμα:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Τώρα ας ωθήσουμε αυτό το αρχείο στο σύμπλεγμα Kubernetes και ας ελέγξουμε ότι δημιουργήθηκε πραγματικά. Λάβετε υπόψη ότι η λειτουργία είναι ακριβώς η ίδια με οποιονδήποτε άλλο πόρο Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Συμπέρασμα:
NAME AGE
set-log-and-pid 22h
Αφού δημιουργήσουμε το ContainerRuntimeConfig, πρέπει να τροποποιήσουμε ένα από τα MachineConfigPools για να ειδοποιήσουμε στην Kubernetes ότι θέλουμε να εφαρμόσουμε αυτήν τη διαμόρφωση σε μια συγκεκριμένη ομάδα μηχανημάτων στο σύμπλεγμα. Σε αυτήν την περίπτωση θα αλλάξουμε το MachineConfigPool για τους κύριους κόμβους:
oc edit MachineConfigPool/master
Συμπέρασμα (για λόγους σαφήνειας, μένει η κύρια ουσία):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Σε αυτό το σημείο, το MCO αρχίζει να δημιουργεί ένα νέο αρχείο crio.conf για το σύμπλεγμα. Σε αυτήν την περίπτωση, το πλήρως ολοκληρωμένο αρχείο διαμόρφωσης μπορεί να προβληθεί χρησιμοποιώντας το Kubernetes API. Θυμηθείτε, το ContainerRuntimeConfig είναι απλώς μια εξειδικευμένη έκδοση του MachineConfig, επομένως μπορούμε να δούμε το αποτέλεσμα κοιτάζοντας τις σχετικές γραμμές στο MachineConfigs:
oc get MachineConfigs | grep rendered
Συμπέρασμα:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Λάβετε υπόψη ότι το αρχείο διαμόρφωσης που προέκυψε για τους κύριους κόμβους ήταν μια νεότερη έκδοση από τις αρχικές διαμορφώσεις. Για να το δείτε, εκτελέστε την παρακάτω εντολή. Εν συνεχεία, σημειώνουμε ότι αυτό είναι ίσως ένα από τα καλύτερα one-liners στην ιστορία της Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Συμπέρασμα:
pids_limit = 2048
Τώρα ας βεβαιωθούμε ότι η διαμόρφωση έχει εφαρμοστεί σε όλους τους κύριους κόμβους. Πρώτα παίρνουμε μια λίστα με κόμβους στο σύμπλεγμα:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Τώρα ας δούμε το εγκατεστημένο αρχείο. Θα δείτε ότι το αρχείο έχει ενημερωθεί με τις νέες τιμές για τις οδηγίες pid και εντοπισμού σφαλμάτων που καθορίσαμε στον πόρο ContainerRuntimeConfig. Η ίδια η κομψότητα:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Συμπέρασμα:
...
pids_limit = 2048
...
log_level = "debug"
...
Όλες αυτές οι αλλαγές στο σύμπλεγμα έγιναν χωρίς καν να τρέξει SSH. Όλη η εργασία έγινε με πρόσβαση στον κύριο κόμβο Kuberentes. Δηλαδή, αυτές οι νέες παράμετροι διαμορφώθηκαν μόνο σε κύριους κόμβους. Οι κόμβοι εργαζομένων δεν άλλαξαν, γεγονός που καταδεικνύει τα οφέλη της μεθοδολογίας Kubernetes της χρήσης καθορισμένων και πραγματικών καταστάσεων σε σχέση με κεντρικούς υπολογιστές εμπορευματοκιβωτίων και κινητήρες εμπορευματοκιβωτίων με εναλλάξιμα στοιχεία.
Το παραπάνω παράδειγμα δείχνει τη δυνατότητα να κάνετε αλλαγές σε ένα μικρό σύμπλεγμα OpenShift Container Platform 4 με τρεις κόμβους παραγωγής ή σε ένα τεράστιο σύμπλεγμα παραγωγής με 3000 κόμβους. Σε κάθε περίπτωση, ο όγκος της εργασίας θα είναι ο ίδιος - και πολύ μικρός - απλώς διαμορφώστε το αρχείο ContainerRuntimeConfig και αλλάξτε μία ετικέτα στο MachineConfigPool. Και μπορείτε να το κάνετε αυτό με οποιαδήποτε έκδοση του OpenShift Container Platform 4.X που εκτελεί το Kubernetes καθ' όλη τη διάρκεια του κύκλου ζωής του.
Συχνά οι εταιρείες τεχνολογίας εξελίσσονται τόσο γρήγορα που δεν μπορούμε να εξηγήσουμε γιατί επιλέγουμε συγκεκριμένες τεχνολογίες για τα υποκείμενα στοιχεία. Οι κινητήρες εμπορευματοκιβωτίων ήταν ιστορικά το εξάρτημα με το οποίο αλληλεπιδρούν άμεσα οι χρήστες. Δεδομένου ότι η δημοτικότητα των εμπορευματοκιβωτίων ξεκίνησε φυσικά με την εμφάνιση των κινητήρων εμπορευματοκιβωτίων, οι χρήστες συχνά δείχνουν ενδιαφέρον για αυτούς. Αυτός είναι ένας ακόμη λόγος για τον οποίο η Red Hat επέλεξε το CRI-O. Τα κοντέινερ εξελίσσονται με έμφαση τώρα στην ενορχήστρωση και έχουμε διαπιστώσει ότι το CRI-O παρέχει την καλύτερη εμπειρία όταν εργάζεστε με το OpenShift 4.
Πηγή: www.habr.com