Ο Pavel Selivanov, αρχιτέκτονας λύσεων Southbridge και δάσκαλος Slurm, έδωσε μια ομιλία στο DevOpsConf 2019. Αυτή η ομιλία είναι μέρος ενός από τα θέματα του προχωρημένου μαθήματος Slurm Mega Kubernetes.
πραγματοποιείται στη Μόσχα 18-20 Νοεμβρίου.
- Μόσχα, 22-24 Νοεμβρίου.
πάντα διαθέσιμος.
Κάτω από την περικοπή - απομαγνητοφώνηση της έκθεσης.
Καλησπέρα, συνάδελφοι και συμπαθούντες. Σήμερα θα μιλήσω για την ασφάλεια.
Βλέπω ότι υπάρχουν πολλοί άνθρωποι ασφαλείας στην αίθουσα σήμερα. Σας ζητώ προκαταβολικά συγγνώμη εάν χρησιμοποιώ όρους από τον κόσμο της ασφάλειας όχι όπως κάνετε συνήθως.
Έτυχε πριν από περίπου έξι μήνες, ένα δημόσιο σύμπλεγμα Kubernetes έπεσε στα χέρια μου. Δημόσιο - σημαίνει ότι υπάρχει ο ν-ος αριθμός χώρων ονομάτων, σε αυτούς τους χώρους ονομάτων υπάρχουν χρήστες που είναι απομονωμένοι στο χώρο ονομάτων τους. Όλοι αυτοί οι χρήστες ανήκουν σε διαφορετικές εταιρείες. Λοιπόν, υποτέθηκε ότι αυτό το σύμπλεγμα θα έπρεπε να χρησιμοποιηθεί ως CDN. Δηλαδή, σου δίνουν ένα σύμπλεγμα, δίνουν έναν χρήστη εκεί, πηγαίνεις εκεί στον χώρο ονομάτων σου, αναπτύσσεις τα μέτωπά σου.
Η προηγούμενη εταιρεία μου προσπάθησε να πουλήσει μια τέτοια υπηρεσία. Και μου ζητήθηκε να ρίξω το σύμπλεγμα για το θέμα - αν μια τέτοια λύση είναι κατάλληλη ή όχι.
Ήρθα σε αυτό το σύμπλεγμα. Μου δόθηκαν περιορισμένα δικαιώματα, περιορισμένος χώρος ονομάτων. Εκεί τα παιδιά κατάλαβαν τι είναι ασφάλεια. Διάβασαν τι είναι το Role-based Access Control (RBAC) στο Kubernetes - και το έστριψαν έτσι ώστε να μην μπορώ να τρέξω τα pod ξεχωριστά από τις αναπτύξεις. Δεν θυμάμαι το πρόβλημα που προσπαθούσα να λύσω τρέχοντας ένα pod χωρίς ανάπτυξη, αλλά ήθελα πραγματικά να εκτελέσω μόνο ένα pod. Αποφάσισα για τύχη να δω τι δικαιώματα έχω στο cluster, τι μπορώ να κάνω, τι δεν μπορώ, τι τσάκωσαν εκεί. Ταυτόχρονα, θα σας πω τι έχουν ρυθμίσει λανθασμένα στο RBAC.
Έτυχε ότι σε δύο λεπτά πήρα έναν διαχειριστή στο σύμπλεγμα τους, κοίταξα όλους τους γειτονικούς χώρους ονομάτων, είδα τα μέτωπα παραγωγής εταιρειών που είχαν ήδη αγοράσει την υπηρεσία και είχαν αναπτύξει εκεί. Μετά βίας σταμάτησα τον εαυτό μου για να μην έρθω σε κάποιον μπροστά και βάλω μερικές βρισιές στην κεντρική σελίδα.
Θα σας πω με παραδείγματα πώς το έκανα και πώς να αμυνθώ από αυτό.
Αλλά πρώτα, επιτρέψτε μου να συστηθώ. Με λένε Πάβελ Σελιβάνοφ. Είμαι αρχιτέκτονας για το Southbridge. Καταλαβαίνω το Kubernetes, τα DevOps και κάθε είδους φανταχτερά πράγματα. Οι μηχανικοί του Southbridge και εγώ τα κατασκευάζουμε όλα και συμβουλεύομαι.
Εκτός από τις κύριες δραστηριότητές μας, πρόσφατα ξεκινήσαμε έργα που ονομάζονται Slurms. Προσπαθούμε να φέρουμε λίγο στις μάζες την ικανότητά μας να δουλεύουμε με Kubernetes, να διδάξουμε και σε άλλους πώς να δουλεύουν με K8.
Τι θα μιλήσω σήμερα. Το θέμα της έκθεσης είναι προφανές - σχετικά με την ασφάλεια του συμπλέγματος Kubernetes. Αλλά θέλω να πω αμέσως ότι αυτό το θέμα είναι πολύ μεγάλο - και ως εκ τούτου θέλω να διευκρινίσω αμέσως για τι σίγουρα δεν θα μιλήσω. Δεν θα μιλήσω για χακαρισμένους όρους που έχουν ήδη χρησιμοποιηθεί υπερβολικά εκατό φορές στο Διαδίκτυο. Τυχόν RBAC και πιστοποιητικά.
Θα μιλήσω για αυτό που με πληγώνει και τους συναδέλφους μου από την ασφάλεια σε ένα σύμπλεγμα Kubernetes. Βλέπουμε αυτά τα προβλήματα τόσο με τους παρόχους που παρέχουν συμπλέγματα Kubernetes όσο και με τους πελάτες που έρχονται σε εμάς. Και ακόμη και για πελάτες που έρχονται σε εμάς από άλλες εταιρείες διαχείρισης συμβούλων. Δηλαδή, το μέγεθος της τραγωδίας είναι πολύ μεγάλο στην πραγματικότητα.
Κυριολεκτικά τρία σημεία για τα οποία θα μιλήσω σήμερα:
- Δικαιώματα χρήστη έναντι δικαιωμάτων pod. Τα δικαιώματα χρήστη και τα δικαιώματα pod δεν είναι το ίδιο πράγμα.
- Συλλογή πληροφοριών για το σύμπλεγμα. Θα δείξω ότι μπορείτε να συλλέξετε όλες τις πληροφορίες που χρειάζεστε από ένα σύμπλεγμα χωρίς να έχετε ειδικά δικαιώματα σε αυτό το σύμπλεγμα.
- Επίθεση DoS στο σύμπλεγμα. Εάν δεν καταφέρουμε να συλλέξουμε πληροφορίες, θα είμαστε σε θέση να τοποθετήσουμε το σύμπλεγμα σε κάθε περίπτωση. Θα μιλήσω για επιθέσεις DoS σε στοιχεία ελέγχου συμπλέγματος.
Ένα άλλο γενικό πράγμα που θα αναφέρω είναι αυτό στο οποίο το δοκίμασα όλο, στο οποίο μπορώ να πω με βεβαιότητα ότι όλα λειτουργούν.
Ως βάση, παίρνουμε την εγκατάσταση ενός συμπλέγματος Kubernetes χρησιμοποιώντας το Kubespray. Αν κάποιος δεν ξέρει, αυτό είναι στην πραγματικότητα ένα σύνολο ρόλων για τον Ansible. Το χρησιμοποιούμε όλη την ώρα στη δουλειά. Το καλό είναι ότι μπορείς να κυλήσεις οπουδήποτε - και μπορείς να κυλήσεις πάνω στα κομμάτια του σιδήρου, και κάπου στο σύννεφο. Μία μέθοδος εγκατάστασης είναι κατάλληλη καταρχήν για τα πάντα.
Σε αυτό το σύμπλεγμα, θα έχω Kubernetes v1.14.5. Ολόκληρο το σύμπλεγμα Cube, το οποίο θα εξετάσουμε, χωρίζεται σε χώρους ονομάτων, κάθε χώρος ονομάτων ανήκει σε μια ξεχωριστή ομάδα, τα μέλη αυτής της ομάδας έχουν πρόσβαση σε κάθε χώρο ονομάτων. Δεν μπορούν να πάνε σε διαφορετικούς χώρους ονομάτων, μόνο στους δικούς τους. Αλλά υπάρχει ένας συγκεκριμένος λογαριασμός διαχειριστή που έχει δικαιώματα σε ολόκληρο το σύμπλεγμα.
Υποσχέθηκα ότι το πρώτο πράγμα που θα έχουμε είναι να αποκτήσουμε δικαιώματα διαχειριστή στο σύμπλεγμα. Χρειαζόμαστε ένα ειδικά προετοιμασμένο λοβό που θα σπάσει το σύμπλεγμα Kubernetes. Το μόνο που χρειάζεται να κάνουμε είναι να το εφαρμόσουμε στο σύμπλεγμα Kubernetes.
kubectl apply -f pod.yamlΑυτό το pod θα έρθει σε έναν από τους κύριους του συμπλέγματος Kubernetes. Και το σύμπλεγμα θα επιστρέψει ευχαρίστως ένα αρχείο που ονομάζεται admin.conf μετά από αυτό. Στην Κούβα, αυτό το αρχείο αποθηκεύει όλα τα πιστοποιητικά διαχειριστή και ταυτόχρονα διαμορφώνεται το API συμπλέγματος. Αυτό είναι πόσο εύκολο είναι να αποκτήσετε πρόσβαση διαχειριστή, νομίζω, στο 98% των συμπλεγμάτων Kubernetes.
Και πάλι, αυτό το pod δημιουργήθηκε από έναν προγραμματιστή στο σύμπλεγμα σας, ο οποίος έχει πρόσβαση για να αναπτύξει τις προτάσεις του σε έναν μικρό χώρο ονομάτων. Δεν είχε κανένα δικαίωμα. Ωστόσο, το πιστοποιητικό επέστρεψε.
Και τώρα για μια ειδικά προετοιμασμένη εστία. Εκκινούμε σε οποιαδήποτε εικόνα. Ας πάρουμε ως παράδειγμα το debian:jessie.
Έχουμε κάτι σαν αυτό:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Τι είναι η ανοχή; Οι κύριοι σε ένα σύμπλεγμα Kubernetes συνήθως επισημαίνονται με ένα πράγμα που ονομάζεται κηλίδα. Και η ουσία αυτής της "μόλυνσης" είναι ότι λέει ότι οι λοβοί δεν μπορούν να αντιστοιχιστούν σε κύριους κόμβους. Αλλά κανείς δεν μπαίνει στον κόπο να δείξει σε κανένα λοβό ότι είναι ανεκτικό στη "μόλυνση". Η ενότητα Toleration λέει απλώς ότι εάν το NoSchedule είναι εγκατεστημένο σε κάποιον κόμβο, τότε το pod μας είναι ανεκτικό σε μια τέτοια μόλυνση - και δεν υπάρχουν προβλήματα.
Επιπλέον, λέμε ότι το λοβό μας δεν είναι μόνο ανεκτικό, αλλά θέλει επίσης να χτυπήσει επίτηδες τον κύριο. Γιατί οι δάσκαλοι έχουν το πιο νόστιμο πράγμα που χρειαζόμαστε - όλα τα πιστοποιητικά. Επομένως, λέμε nodeSelector - και έχουμε μια τυπική ετικέτα στα κύρια, η οποία σας επιτρέπει να επιλέξετε από όλους τους κόμβους του συμπλέγματος ακριβώς εκείνους τους κόμβους που είναι κύριοι.
Με αυτά τα δύο τμήματα, σίγουρα θα έρθει στον κύριο. Και θα του επιτραπεί να ζήσει εκεί.
Αλλά μόνο το να έρθουμε στον κύριο δεν μας αρκεί. Δεν θα μας δώσει τίποτα. Στη συνέχεια λοιπόν έχουμε αυτά τα δύο πράγματα:
hostNetwork: true
hostPID: true Καθορίζουμε ότι το pod μας που εκτελούμε θα βρίσκεται στον χώρο ονομάτων του πυρήνα, στον χώρο ονομάτων δικτύου και στον χώρο ονομάτων PID. Μόλις εκτελείται ένα pod στο master, θα μπορεί να δει όλες τις πραγματικές, ζωντανές διεπαφές αυτού του κόμβου, να ακούσει όλη την κίνηση και να δει τα PID όλων των διεργασιών.
Μετά είναι μέχρι τα μικρά πράγματα. Πάρε etcd και διάβασε ότι θέλεις.
Το πιο ενδιαφέρον είναι αυτό το χαρακτηριστικό Kubernetes, το οποίο υπάρχει από προεπιλογή.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Και η ουσία του είναι ότι μπορούμε, στο pod που εκκινούμε, ακόμη και χωρίς δικαιώματα σε αυτό το σύμπλεγμα, να πούμε ότι θέλουμε να δημιουργήσουμε έναν τόμο τύπου hostPath. Πάρτε λοιπόν το μονοπάτι από τον κεντρικό υπολογιστή από τον οποίο θα ξεκινήσουμε - και πάρτε το ως όγκο. Και μετά το ονομάζουμε: οικοδεσπότης. Τοποθετούμε όλο αυτό το hostPath μέσα στο pod. Σε αυτό το παράδειγμα, στον κατάλογο /host.
Για άλλη μια φορά θα επαναλάβω. Είπαμε στο pod να έρθει στο master, να πάρει το hostNetwork και το hostPID εκεί - και να προσαρτήσει ολόκληρη τη ρίζα του master μέσα σε αυτό το pod.
Καταλαβαίνετε ότι στο debian έχουμε bash running και αυτό το bash λειτουργεί για εμάς ως root. Δηλαδή, μόλις πήραμε root στο master, ενώ δεν είχαμε δικαιώματα στο σύμπλεγμα Kubernetes.
Στη συνέχεια, όλη η εργασία είναι να μεταβείτε στον κατάλογο / κεντρικός υπολογιστής / etc / kubernetes / pki, αν δεν κάνω λάθος, πάρτε όλα τα κύρια πιστοποιητικά του συμπλέγματος εκεί και, κατά συνέπεια, γίνετε ο διαχειριστής του συμπλέγματος.
Όταν τα βλέπουμε με αυτόν τον τρόπο, αυτά είναι μερικά από τα πιο επικίνδυνα δικαιώματα σε pods, ανεξάρτητα από τα δικαιώματα που έχει ο χρήστης:
Εάν έχω δικαιώματα να εκτελώ μια ομάδα διαφημίσεων σε κάποιο χώρο ονομάτων συμπλέγματος, τότε αυτή η ομάδα διαφημίσεων έχει αυτά τα δικαιώματα από προεπιλογή. Μπορώ να εκτελέσω προνομιούχα pods, τα οποία είναι γενικά όλα τα δικαιώματα, ουσιαστικά ριζοβολώντας έναν κόμβο.
Το αγαπημένο μου είναι ο χρήστης Root. Και η Kubernetes έχει αυτήν την επιλογή Εκτέλεση ως μη ρίζας. Αυτό είναι ένα είδος προστασίας από έναν χάκερ. Ξέρετε τι είναι ο «ιός της Μολδαβίας»; Εάν ξαφνικά είστε χάκερ και ήρθατε στο σύμπλεγμα Kubernetes μου, τότε εμείς, οι φτωχοί διαχειριστές, ρωτάμε: «Παρακαλώ, υποδείξτε στα pods σας με ποιον θα χακάρετε το σύμπλεγμα μου, που θα εκτελεστεί ως non-root. Διαφορετικά, θα αποδειχθεί ότι ξεκινάτε τη διαδικασία στο pod σας κάτω από τη ρίζα και θα είναι πολύ εύκολο για εσάς να με χακάρετε. Προστατέψτε τον εαυτό σας, σας παρακαλώ».
Όγκος διαδρομής κεντρικού υπολογιστή - κατά τη γνώμη μου, ο ταχύτερος τρόπος για να λάβετε το επιθυμητό αποτέλεσμα από το σύμπλεγμα Kubernetes.
Τι να τα κάνεις όμως όλα αυτά;
Σκέψεις που πρέπει να κάνει κάθε κανονικός διαχειριστής που συναντά Kubernetes: «Ναι, σας είπα, το Kubernetes δεν λειτουργεί. Έχει τρύπες. Και ολόκληρος ο Κύβος είναι μαλακίες». Στην πραγματικότητα, υπάρχει κάτι όπως τεκμηρίωση, και αν κοιτάξετε εκεί, τότε υπάρχει μια ενότητα .
Αυτό είναι ένα τέτοιο αντικείμενο yaml - μπορούμε να το δημιουργήσουμε στο σύμπλεγμα Kubernetes - το οποίο ελέγχει τις πτυχές ασφαλείας στην περιγραφή των pods. Δηλαδή, στην πραγματικότητα, ελέγχει τα δικαιώματα χρήσης οποιουδήποτε hostNetwork, hostPID, ορισμένων τύπων τόμων που βρίσκονται στα pod κατά την εκκίνηση. Με τη βοήθεια του Pod Security Policy, όλα αυτά μπορούν να περιγραφούν.
Το πιο ενδιαφέρον πράγμα σχετικά με την Πολιτική Ασφάλειας Pod είναι ότι στο σύμπλεγμα Kubernetes, όλα τα προγράμματα εγκατάστασης PSP όχι απλώς δεν περιγράφονται με κανέναν τρόπο, αλλά απλώς απενεργοποιούνται από προεπιλογή. Η Πολιτική Ασφάλειας Pod είναι ενεργοποιημένη χρησιμοποιώντας την προσθήκη αποδοχής.
Εντάξει, ας αναπτύξουμε την Πολιτική Ασφάλειας Pod στο σύμπλεγμα, ας πούμε ότι έχουμε κάποια pods υπηρεσίας στον χώρο ονομάτων, στα οποία έχουν πρόσβαση μόνο οι διαχειριστές. Ας πούμε, σε όλα τα υπόλοιπα, τα pods έχουν περιορισμένα δικαιώματα. Επειδή πιθανότατα οι προγραμματιστές δεν χρειάζεται να εκτελούν προνομιούχες ομάδες στο σύμπλεγμα σας.
Και φαίνεται να είμαστε καλά. Και το σύμπλεγμα Kubernetes μας δεν μπορεί να χακαριστεί σε δύο λεπτά.
Υπάρχει ένα πρόβλημα. Πιθανότατα, εάν έχετε ένα σύμπλεγμα Kubernetes, τότε η παρακολούθηση είναι εγκατεστημένη στο σύμπλεγμα σας. Αναλαμβάνω μάλιστα να προβλέψω ότι αν το σύμπλεγμα σας έχει παρακολούθηση, τότε λέγεται Προμηθέας.
Αυτό που θα σας πω τώρα θα ισχύει τόσο για τον χειριστή Prometheus όσο και για τον Prometheus που παραδίδεται στην καθαρή του μορφή. Το ερώτημα είναι, εάν δεν μπορώ να βρω έναν διαχειριστή στο σύμπλεγμα τόσο γρήγορα, τότε αυτό σημαίνει ότι πρέπει να ψάξω περισσότερο. Και μπορώ να ψάξω χρησιμοποιώντας την παρακολούθηση σας.
Πιθανώς, όλοι διαβάζουν τα ίδια άρθρα στο Habré και η παρακολούθηση βρίσκεται στον χώρο ονομάτων παρακολούθησης. Το τιμόνι ονομάζεται περίπου το ίδιο για όλους. Η εικασία μου είναι ότι αν εγκαταστήσετε το πηδάλιο stable/prometheus θα πρέπει να καταλήξετε με περίπου τα ίδια ονόματα. Και ακόμη και πιθανότατα δεν θα χρειαστεί να μαντέψω το όνομα DNS στο σύμπλεγμα σας. Γιατί είναι στάνταρ.
Στη συνέχεια, έχουμε ένα συγκεκριμένο dev ns, στο οποίο μπορείτε να εκτελέσετε ένα συγκεκριμένο pod. Και μετά από αυτό το pod είναι πολύ εύκολο να το κάνετε αυτό:
$ curl http://prometheus-kube-state-metrics.monitoring Το prometheus-kube-state-metrics είναι ένας από τους εξαγωγείς prometheus που συλλέγει μετρήσεις από το ίδιο το Kubernetes API. Υπάρχουν πολλά δεδομένα εκεί, τι τρέχει στο cluster σας, τι είναι, τι προβλήματα έχετε με αυτό.
Ως απλό παράδειγμα:
kube_pod_container_info{namespace="kube-system",pod="kube-apiserver-k8s-1",container="kube-apiserver",image=
"gcr.io/google-containers/kube-apserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Κάνοντας ένα απλό αίτημα μπούκλας από ένα μη προνομιούχο pod, μπορείτε να λάβετε πληροφορίες όπως αυτή. Αν δεν ξέρετε ποια έκδοση του Kubernetes τρέχετε, θα σας πει εύκολα.
Και το πιο ενδιαφέρον είναι ότι εκτός από το γεγονός ότι έχετε πρόσβαση στο kube-state-metrics, μπορείτε εξίσου καλά να έχετε απευθείας πρόσβαση στον ίδιο τον Prometheus. Μπορείτε να συλλέξετε μετρήσεις από εκεί. Μπορείτε ακόμη και να δημιουργήσετε μετρήσεις από εκεί. Ακόμη και θεωρητικά, μπορείτε να δημιουργήσετε ένα τέτοιο ερώτημα από ένα σύμπλεγμα στον Προμηθέα, το οποίο απλά θα το απενεργοποιήσει. Και η παρακολούθησή σας γενικά θα σταματήσει να λειτουργεί από το σύμπλεγμα.
Και εδώ τίθεται ήδη το ερώτημα εάν οποιαδήποτε εξωτερική παρακολούθηση παρακολουθεί την παρακολούθηση σας. Μόλις είχα την ευκαιρία να λειτουργήσω σε ένα σύμπλεγμα Kubernetes χωρίς καμία απολύτως συνέπεια για τον εαυτό μου. Δεν θα ξέρετε καν ότι εργάζομαι εκεί, αφού η παρακολούθηση δεν υπάρχει πλέον.
Όπως και με το PSP, φαίνεται ότι το πρόβλημα είναι ότι όλες αυτές οι φανταχτερές τεχνολογίες - Kubernetes, Prometheus - απλά δεν λειτουργούν και είναι γεμάτες τρύπες. Όχι πραγματικά.
Υπάρχει κάτι τέτοιο - .
Εάν είστε κανονικός διαχειριστής, τότε πιθανότατα γνωρίζετε σχετικά με την Πολιτική δικτύου ότι πρόκειται για ένα άλλο yaml, από το οποίο υπάρχουν ήδη dofiga στο σύμπλεγμα. Και οι Πολιτικές Δικτύου σίγουρα δεν χρειάζονται. Και ακόμα κι αν διαβάσετε τι είναι η Πολιτική Δικτύου, τι είναι ένα τείχος προστασίας yaml Kubernetes, σας επιτρέπει να περιορίσετε τα δικαιώματα πρόσβασης μεταξύ χώρων ονομάτων, μεταξύ ομάδων, τότε σίγουρα αποφασίσατε ότι το τείχος προστασίας yaml στο Kubernetes βασίζεται στις επόμενες αφαιρέσεις ... Όχι-όχι. Σίγουρα δεν είναι απαραίτητο.
Ακόμα κι αν δεν είπαν στους ειδικούς ασφαλείας σας ότι με τη βοήθεια των Kubernetes σας, μπορείτε να φτιάξετε ένα πολύ εύκολο και απλό τείχος προστασίας και πολύ λεπτομερές. Εάν δεν το γνωρίζουν ακόμα και δεν σας τραβήξουν: "Λοιπόν, δώσε το, δώσε το ..." Τότε σε κάθε περίπτωση, χρειάζεστε Πολιτική δικτύου για να αποκλείσετε την πρόσβαση σε ορισμένα μέρη υπηρεσιών που μπορείτε να αφαιρέσετε από το σύμπλεγμα σας χωρίς καμία εξουσιοδότηση.
Όπως στο παράδειγμα που έδωσα, μπορείτε να τραβήξετε μετρήσεις κατάστασης kube από οποιονδήποτε χώρο ονομάτων στο σύμπλεγμα Kubernetes χωρίς να έχετε κανένα δικαίωμα να το κάνετε. Οι πολιτικές δικτύου έχουν κλειστή πρόσβαση από όλους τους άλλους χώρους ονομάτων στον χώρο ονομάτων παρακολούθησης και, όπως ήταν, τα πάντα: καμία πρόσβαση, κανένα πρόβλημα. Σε όλα τα διαγράμματα που υπάρχουν, τόσο στον τυπικό prometheus όσο και στον prometheus που είναι στον χειριστή, υπάρχει απλώς μια επιλογή στις τιμές του τιμονιού για να ενεργοποιηθούν απλώς οι πολιτικές δικτύου για αυτούς. Απλά πρέπει να το ενεργοποιήσετε και θα λειτουργήσουν.
Υπάρχει πραγματικά ένα πρόβλημα εδώ. Όντας ένας κανονικός γενειοφόρος διαχειριστής, πιθανότατα αποφασίσατε ότι δεν χρειάζονται πολιτικές δικτύου. Και αφού διαβάσατε κάθε είδους άρθρα σχετικά με πόρους όπως το Habr, αποφασίσατε ότι το flannel, ειδικά με τη λειτουργία host-gateway, είναι το καλύτερο πράγμα που μπορείτε να επιλέξετε.
Τι να κάνω;
Μπορείτε να δοκιμάσετε να αναδιατάξετε τη λύση δικτύου που έχετε στο σύμπλεγμα Kubernetes, προσπαθήστε να την αντικαταστήσετε με κάτι πιο λειτουργικό. Στο ίδιο Calico, για παράδειγμα. Αλλά αμέσως θέλω να πω ότι το έργο της αλλαγής της λύσης δικτύου στο λειτουργικό σύμπλεγμα Kubernetes είναι αρκετά μη τετριμμένο. Το έλυσα δύο φορές (και τις δύο φορές, όμως, θεωρητικά), αλλά δείξαμε πώς να το κάνουμε ακόμη και στο Slurms. Για τους μαθητές μας, δείξαμε πώς να αλλάξουμε τη λύση δικτύου σε ένα σύμπλεγμα Kubernetes. Κατ 'αρχήν, μπορείτε να προσπαθήσετε να βεβαιωθείτε ότι δεν υπάρχει χρόνος διακοπής λειτουργίας στο σύμπλεγμα παραγωγής. Αλλά μάλλον δεν θα τα καταφέρεις.
Και το πρόβλημα στην πραγματικότητα λύνεται πολύ απλά. Υπάρχουν πιστοποιητικά στο σύμπλεγμα και ξέρετε ότι τα πιστοποιητικά σας θα χαλάσουν σε ένα χρόνο. Λοιπόν, και συνήθως μια κανονική λύση με πιστοποιητικά στο σύμπλεγμα - γιατί θα κάνουμε ένα ατμόλουτρο, θα σηκώσουμε ένα νέο σύμπλεγμα δίπλα του, θα το αφήσουμε να σαπίσει στο παλιό και θα επανατοποθετήσουμε τα πάντα. Αλήθεια, όταν σαπίσει, όλα θα ξαπλώσουν για μια μέρα, αλλά μετά ένα νέο σύμπλεγμα.
Όταν σηκώνετε ένα νέο σύμπλεγμα, εισάγετε ταυτόχρονα Calico αντί για φανέλα.
Τι να κάνετε εάν έχετε πιστοποιητικά που έχουν εκδοθεί για εκατό χρόνια και δεν πρόκειται να ανακατανείμετε το σύμπλεγμα; Υπάρχει κάτι τέτοιο Kube-RBAC-Proxy. Αυτή είναι μια πολύ ωραία εξέλιξη, σας επιτρέπει να ενσωματώσετε τον εαυτό του ως κοντέινερ sidecar σε οποιοδήποτε pod σε ένα σύμπλεγμα Kubernetes. Και στην πραγματικότητα προσθέτει εξουσιοδότηση μέσω του ίδιου του RBAC της Kubernetes σε αυτό το pod.
Υπάρχει ένα πρόβλημα. Προηγουμένως, αυτή η λύση Kube-RBAC-Proxy ήταν ενσωματωμένη στον προμηθέα του χειριστή. Αλλά μετά είχε φύγει. Τώρα οι σύγχρονες εκδόσεις βασίζονται στο γεγονός ότι έχετε πολιτικές δικτύου και τις κλείνετε με αυτές. Και έτσι πρέπει να ξαναγράψετε λίγο το διάγραμμα. Αν μάλιστα πας στο , υπάρχουν παραδείγματα για το πώς να το χρησιμοποιήσετε ως πλευρικά καρέ και τα γραφήματα θα πρέπει να ξαναγραφτούν ελάχιστα.
Υπάρχει ακόμη ένα μικρό πρόβλημα. Όχι μόνο ο Προμηθέας δίνει σε κανέναν τις μετρήσεις του. Στην περίπτωσή μας, όλα τα στοιχεία του συμπλέγματος Kubernetes μπορούν επίσης να δώσουν τις μετρήσεις τους.
Αλλά όπως είπα, αν δεν μπορείτε να αποκτήσετε πρόσβαση στο σύμπλεγμα και να συλλέξετε πληροφορίες, τότε μπορείτε τουλάχιστον να κάνετε κακό.
Θα σας δείξω λοιπόν γρήγορα δύο τρόπους με τους οποίους ένα σύμπλεγμα Kubernetes μπορεί να αρρωστήσει.
Θα γελάσετε όταν σας πω, πρόκειται για δύο πραγματικές περιπτώσεις.
Μέθοδος ένα. Εξάντληση πόρων.
Λανσάρουμε άλλο ένα ειδικό pod. Θα έχει αυτό το τμήμα.
resources:
requests:
cpu: 4
memory: 4Gi Όπως γνωρίζετε, τα αιτήματα είναι η ποσότητα της CPU και της μνήμης που είναι δεσμευμένη στον κεντρικό υπολογιστή για συγκεκριμένες ομάδες αιτημάτων. Εάν έχουμε έναν κεντρικό υπολογιστή τεσσάρων πυρήνων στο σύμπλεγμα Kubernetes και τέσσερις ομάδες CPU φτάνουν εκεί με αιτήματα, τότε δεν μπορούν να έρθουν άλλες ομάδες με αιτήματα σε αυτόν τον κεντρικό υπολογιστή.
Εάν εκτελέσω ένα τέτοιο pod, τότε εκδώσω την εντολή:
$ kubectl scale special-pod --replicas=...Τότε κανείς άλλος δεν θα μπορεί να αναπτυχθεί στο σύμπλεγμα Kubernetes. Επειδή όλοι οι κόμβοι θα ξεμείνουν από αιτήματα. Και έτσι θα σταματήσω το σύμπλεγμα Kubernetes σας. Εάν το κάνω αυτό το βράδυ, τότε οι αναπτύξεις μπορούν να σταματήσουν για αρκετό καιρό.
Αν κοιτάξουμε ξανά την τεκμηρίωση του Kubernetes, θα δούμε κάτι τέτοιο που ονομάζεται Limit Range. Ορίζει τους πόρους για τα αντικείμενα συμπλέγματος. Μπορείτε να γράψετε ένα αντικείμενο Limit Range στο yaml, να το εφαρμόσετε σε συγκεκριμένους χώρους ονομάτων - και περαιτέρω σε αυτόν τον χώρο ονομάτων μπορείτε να πείτε ότι έχετε πόρους για προεπιλεγμένες, μέγιστες και ελάχιστες ομάδες.
Με τη βοήθεια ενός τέτοιου πράγματος, μπορούμε να περιορίσουμε τους χρήστες σε συγκεκριμένους χώρους ονομάτων προϊόντων ομάδας από τη δυνατότητα να υποδεικνύουν κάθε είδους άσχημα πράγματα στα pod τους. Αλλά δυστυχώς, ακόμα κι αν πείτε στον χρήστη ότι δεν μπορείτε να εκτελέσετε pods με αιτήματα για περισσότερες από μία CPU, υπάρχει μια τέτοια υπέροχη εντολή κλίμακας, καλά, ή μέσω του πίνακα εργαλείων μπορούν να κάνουν κλίμακα.
Και εδώ μπαίνει το νούμερο δύο. Εκτέλεση 11 111 111 111 111 λοβών. Είναι έντεκα δισεκατομμύρια. Αυτό δεν οφείλεται στο ότι βρήκα έναν τέτοιο αριθμό, αλλά γιατί το είδα μόνος μου.
Πραγματική ιστορία. Αργά το βράδυ ήμουν έτοιμος να φύγω από το γραφείο. Κοιτάζω, μια ομάδα προγραμματιστών κάθεται στη γωνία και μανιωδώς κάνει κάτι με φορητούς υπολογιστές. Πηγαίνω στα παιδιά και ρωτάω: «Τι έπαθες;»
Λίγο νωρίτερα, στις εννιά το βράδυ, ένας από τους προγραμματιστές πήγαινε σπίτι. Και αποφάσισα: «Τώρα θα κλιμακώσω την αίτησή μου σε ένα». Πάτησα ένα και το Διαδίκτυο έγινε λίγο βαρετό. Πάτησε πάλι το ένα, πάτησε το ένα, πάτησε Enter. Πέταξε ό,τι μπορούσε. Στη συνέχεια, το Διαδίκτυο ήρθε στη ζωή - και όλα άρχισαν να κλιμακώνονται μέχρι αυτή την ημερομηνία.
Είναι αλήθεια ότι αυτή η ιστορία δεν έλαβε χώρα στο Kubernetes, εκείνη την εποχή ήταν το Nomad. Τελείωσε με το γεγονός ότι μετά από μια ώρα από τις προσπάθειές μας να σταματήσουμε το Nomad από πεισματικές προσπάθειες κλιμάκωσης, ο Nomad απάντησε ότι δεν θα σταματήσει να κλιμακώνεται και δεν θα έκανε τίποτα άλλο. «Είμαι κουρασμένος, φεύγω». Και γύρισε.
Φυσικά προσπάθησα να κάνω το ίδιο στο Kubernetes. Έντεκα δισεκατομμύρια pods Kubernetes δεν άρεσε, είπε: «Δεν μπορώ. Υπερβαίνει τα εσωτερικά καλύμματα. Αλλά 1 λοβοί θα μπορούσαν.
Ως απάντηση στο ένα δισεκατομμύριο, ο Κύβος δεν αποσύρθηκε στον εαυτό του. Πραγματικά άρχισε να κλιμακώνεται. Όσο προχωρούσε η διαδικασία, τόσο περισσότερος χρόνος χρειαζόταν για τη δημιουργία νέων λοβών. Αλλά και πάλι η διαδικασία συνεχίστηκε. Το μόνο πρόβλημα είναι ότι αν μπορώ να εκτελώ pods στον χώρο ονομάτων μου επ' αόριστον, τότε ακόμα και χωρίς αιτήματα και όρια, μπορώ να εκτελέσω έναν τέτοιο αριθμό ομάδων με ορισμένες εργασίες που με τη βοήθεια αυτών των εργασιών οι κόμβοι θα αρχίσουν να αθροίζονται από τη μνήμη, στην CPU. Όταν τρέχω τόσα πολλά pod, οι πληροφορίες από αυτά πρέπει να μπαίνουν στο χώρο αποθήκευσης, δηλαδή, κ.λπ. Και όταν μπαίνουν πάρα πολλές πληροφορίες, η αποθήκευση αρχίζει να αποδίδει πολύ αργά - και το Kubernetes αρχίζει να γίνεται αμβλύ.
Και ένα ακόμη πρόβλημα ... Όπως γνωρίζετε, τα στοιχεία ελέγχου Kubernetes δεν είναι κάποιου είδους κεντρικό πράγμα, αλλά πολλά στοιχεία. Εκεί, συγκεκριμένα, υπάρχει ένας διαχειριστής ελεγκτή, προγραμματιστής και ούτω καθεξής. Όλοι αυτοί οι τύποι θα αρχίσουν να κάνουν περιττές ηλίθιες δουλειές ταυτόχρονα, οι οποίες με τον καιρό θα αρχίσουν να χρειάζονται όλο και περισσότερο χρόνο. Ο διαχειριστής ελεγκτή θα δημιουργήσει νέα pods. Το Scheduler θα προσπαθήσει να βρει έναν νέο κόμβο για αυτούς. Οι νέοι κόμβοι στο σύμπλεγμα σας πιθανότατα θα εξαντληθούν σύντομα. Το σύμπλεγμα Kubernetes θα αρχίσει να τρέχει όλο και πιο αργά.
Αποφάσισα όμως να πάω ακόμα παραπέρα. Όπως γνωρίζετε, η Kubernetes έχει ένα πράγμα που ονομάζεται υπηρεσία. Λοιπόν, από προεπιλογή στα συμπλέγματά σας, πιθανότατα η υπηρεσία λειτουργεί χρησιμοποιώντας πίνακες IP.
Εάν εκτελέσετε ένα δισεκατομμύριο pods, για παράδειγμα, και στη συνέχεια χρησιμοποιήσετε ένα σενάριο για να αναγκάσετε την Kubernetis να δημιουργήσει νέες υπηρεσίες:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Σε όλους τους κόμβους του συμπλέγματος, όλο και περισσότεροι νέοι κανόνες iptables θα δημιουργούνται περίπου ταυτόχρονα. Επιπλέον, ένα δισεκατομμύριο κανόνες iptables θα δημιουργηθούν για κάθε υπηρεσία.
Έλεγξα όλο αυτό το θέμα σε πολλές χιλιάδες, έως και μια ντουζίνα. Και το πρόβλημα είναι ότι ήδη σε αυτό το όριο είναι αρκετά προβληματικό να κάνουμε ssh στον κόμβο. Επειδή τα πακέτα, περνώντας μέσα από τόσες πολλές αλυσίδες, αρχίζουν να μην αισθάνονται πολύ καλά.
Και όλα αυτά λύνονται με τη βοήθεια του Kubernetes. Υπάρχει ένα τέτοιο όριο αντικειμένου Πόρων. Ορίζει τον αριθμό των διαθέσιμων πόρων και αντικειμένων για τον χώρο ονομάτων στο σύμπλεγμα. Μπορούμε να δημιουργήσουμε ένα αντικείμενο yaml σε κάθε χώρο ονομάτων συμπλέγματος Kubernetes. Με τη βοήθεια αυτού του αντικειμένου, μπορούμε να πούμε ότι έχουμε ορισμένο αριθμό αιτημάτων, όρια που έχουν εκχωρηθεί για αυτόν τον χώρο ονομάτων, και επιπλέον μπορούμε να πούμε ότι είναι δυνατό να δημιουργηθούν 10 υπηρεσίες και 10 ομάδες σε αυτόν τον χώρο ονομάτων. Και ένας μόνο προγραμματιστής μπορεί ακόμη και να συντρίψει τον εαυτό του τα βράδια. Ο Kubernetes θα του πει: "Δεν μπορείτε να κλιμακώσετε τα pods σας σε τέτοιο ποσό, επειδή υπερβαίνει το όριο των πόρων." Αυτό είναι, το πρόβλημα λύθηκε. .
Ένα πρόβλημα προκύπτει σε σχέση με αυτό. Νιώθετε πόσο δύσκολο γίνεται να δημιουργήσετε έναν χώρο ονομάτων στο Kubernetes. Για να το δημιουργήσουμε, πρέπει να λάβουμε υπόψη ένα σωρό πράγματα.
Όριο πόρων + Όριο εύρος + RBAC
• Δημιουργία χώρου ονομάτων
• Δημιουργία εντός ορίου εύρους
• Δημιουργία εντός ορίου πόρων
• Δημιουργήστε έναν λογαριασμό υπηρεσίας για CI
• Δημιουργία rolebinding για CI και χρήστες
• Εκκινήστε προαιρετικά τα απαραίτητα σέρβις
Ως εκ τούτου, με την ευκαιρία αυτή, θα ήθελα να μοιραστώ τις εξελίξεις μου. Υπάρχει κάτι τέτοιο που ονομάζεται χειριστής SDK. Αυτός είναι ο τρόπος στο σύμπλεγμα Kubernetes για να γράψετε δηλώσεις για αυτό. Μπορείτε να γράψετε δηλώσεις με το Ansible.
Στην αρχή, γράψαμε στο Ansible και μετά κοίταξα τι ήταν ο χειριστής SDK και ξαναέγραψα τον ρόλο του Ansible σε τελεστή. Αυτή η δήλωση σάς επιτρέπει να δημιουργήσετε ένα αντικείμενο στο σύμπλεγμα Kubernetes που ονομάζεται εντολή. Μέσα στην εντολή, σας επιτρέπει να περιγράψετε σε yaml το περιβάλλον αυτής της εντολής. Και μέσα στο περιβάλλον της ομάδας, μας επιτρέπει να περιγράψουμε ότι διαθέτουμε τόσους πολλούς πόρους.
Λίγο .
Και εν κατακλείδι. Τι να τα κάνεις όλα αυτά;
Πρώτα. Η πολιτική ασφαλείας του Pod είναι καλή. Και παρά το γεγονός ότι κανένας από τους εγκαταστάτες του Kubernetes δεν τα χρησιμοποιεί μέχρι σήμερα, εξακολουθείτε να πρέπει να τα χρησιμοποιείτε στα συμπλέγματά σας.
Η πολιτική δικτύου δεν είναι κάποια άλλη περιττή δυνατότητα. Αυτό είναι που πραγματικά χρειάζεται στο σύμπλεγμα.
LimitRange/ResourceQuota - ήρθε η ώρα να το χρησιμοποιήσετε. Ξεκινήσαμε να το χρησιμοποιούμε εδώ και πολύ καιρό και για πολύ καιρό ήμουν σίγουρος ότι το χρησιμοποιούσαν όλοι. Αποδείχθηκε ότι αυτό είναι σπάνιο.
Εκτός από αυτά που ανέφερα κατά τη διάρκεια της αναφοράς, υπάρχουν μη τεκμηριωμένες λειτουργίες που σας επιτρέπουν να επιτεθείτε στο σύμπλεγμα. Κυκλοφόρησε πρόσφατα .
Μερικά πράγματα είναι τόσο λυπηρά και πονεμένα. Για παράδειγμα, υπό ορισμένες συνθήκες, τα cubelets σε ένα σύμπλεγμα Kubernetes μπορούν να δώσουν τα περιεχόμενα του καταλόγου warlocks και σε έναν μη εξουσιοδοτημένο χρήστη.
υπάρχουν οδηγίες για το πώς να αναπαράγετε όλα όσα είπα. Υπάρχουν αρχεία με παραδείγματα παραγωγής, πώς μοιάζει το ResourceQuota, το Pod Security Policy. Και όλα αυτά μπορούν να αγγίξουν.
Σας ευχαριστώ όλους.
Πηγή: www.habr.com