10 κοινά λάθη Kubernetes

Σημείωση. μετάφρ.: Οι συντάκτες αυτού του άρθρου είναι μηχανικοί από μια μικρή τσέχικη εταιρεία, pipetail. Κατάφεραν να συνθέσουν μια υπέροχη λίστα με [μερικές φορές μπανάλ, αλλά ακόμα] πολύ πιεστικά προβλήματα και παρανοήσεις που σχετίζονται με τη λειτουργία των συμπλεγμάτων Kubernetes.

Κατά τη διάρκεια των ετών χρήσης του Kubernetes, έχουμε εργαστεί με μεγάλο αριθμό συμπλεγμάτων (διαχειριζόμενα και μη - σε GCP, AWS και Azure). Με τον καιρό, αρχίσαμε να παρατηρούμε ότι κάποια λάθη επαναλαμβάνονταν συνεχώς. Ωστόσο, δεν υπάρχει ντροπή σε αυτό: τα περισσότερα τα έχουμε κάνει μόνοι μας!

Το άρθρο περιέχει τα πιο συνηθισμένα σφάλματα και αναφέρει επίσης πώς να τα διορθώσετε.

1. Πόροι: αιτήματα και όρια

Αυτό το στοιχείο αξίζει σίγουρα τη μεγαλύτερη προσοχή και την πρώτη θέση στη λίστα.

Αίτημα CPU συνήθως είτε δεν προσδιορίζεται καθόλου είτε έχει πολύ χαμηλή τιμή (για να τοποθετήσετε όσο το δυνατόν περισσότερους λοβούς σε κάθε κόμβο). Έτσι, οι κόμβοι υπερφορτώνονται. Σε περιόδους υψηλού φορτίου, η επεξεργαστική ισχύς του κόμβου χρησιμοποιείται πλήρως και ένας συγκεκριμένος φόρτος εργασίας λαμβάνει μόνο αυτό που «ζήτησε» από Στραγγαλισμός CPU. Αυτό οδηγεί σε αυξημένο λανθάνοντα χρόνο εφαρμογής, χρονικά όρια και άλλες δυσάρεστες συνέπειες. (Διαβάστε περισσότερα σχετικά με αυτό στην άλλη πρόσφατη μετάφρασή μας: "Όρια CPU και επιθετικό throttling στο Kubernetes" - περίπου. μετάφρ.)

Καλύτερη προσπάθεια (επακρώς όχι συνιστάται):

resources: {}

Εξαιρετικά χαμηλό αίτημα CPU (εξαιρετικά όχι συνιστάται):

   resources:
      Requests:
        cpu: "1m"

Από την άλλη πλευρά, η παρουσία ενός ορίου CPU μπορεί να οδηγήσει σε αδικαιολόγητη παράκαμψη των κύκλων ρολογιού από τα pods, ακόμη και αν ο επεξεργαστής κόμβου δεν έχει φορτωθεί πλήρως. Και πάλι, αυτό μπορεί να οδηγήσει σε αυξημένες καθυστερήσεις. Η διαμάχη συνεχίζεται γύρω από την παράμετρο Ποσόστωση CPU CFS στον πυρήνα του Linux και τον περιορισμό της CPU ανάλογα με τα καθορισμένα όρια, καθώς και την απενεργοποίηση του ορίου CFS... Αλίμονο, τα όρια της CPU μπορούν να προκαλέσουν περισσότερα προβλήματα από όσα μπορούν να λύσουν. Περισσότερες πληροφορίες σχετικά με αυτό μπορείτε να βρείτε στον παρακάτω σύνδεσμο.

Υπερβολική επιλογή (υπερδέσμευση) προβλήματα μνήμης μπορεί να οδηγήσουν σε μεγαλύτερα προβλήματα. Η επίτευξη του ορίου της CPU συνεπάγεται παράβλεψη κύκλων ρολογιού, ενώ η επίτευξη του ορίου μνήμης συνεπάγεται τη θανάτωση του pod. Έχετε παρατηρήσει ποτέ OOMkill? Ναι, για αυτό ακριβώς μιλάμε.

Θέλετε να ελαχιστοποιήσετε την πιθανότητα να συμβεί αυτό; Μην υπερεκχωρείτε τη μνήμη και χρησιμοποιήστε το Εγγυημένο QoS (Ποιότητα υπηρεσίας) θέτοντας το αίτημα μνήμης στο όριο (όπως στο παρακάτω παράδειγμα). Διαβάστε περισσότερα για αυτό στο Παρουσιάσεις Henning Jacobs (Επικεφαλής Μηχανικός στο Zalando).

Διαρρηγμένος (μεγαλύτερες πιθανότητες να σκοτωθείτε OOM):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

Εγγυημένα:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

Τι θα βοηθήσει ενδεχομένως κατά τη δημιουργία πόρων;

Με metrics-server μπορείτε να δείτε την τρέχουσα κατανάλωση πόρων της CPU και τη χρήση μνήμης ανά pods (και κοντέινερ μέσα σε αυτά). Το πιθανότερο είναι ότι το χρησιμοποιείτε ήδη. Απλώς εκτελέστε τις παρακάτω εντολές:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

Ωστόσο, δείχνουν μόνο την τρέχουσα χρήση. Μπορεί να σας δώσει μια γενική ιδέα της τάξης μεγέθους, αλλά τελικά θα χρειαστείτε ιστορικό αλλαγών στις μετρήσεις με την πάροδο του χρόνου (για να απαντήσετε σε ερωτήσεις όπως: «Ποιο ήταν το μέγιστο φορτίο της CPU;», «Ποιο ήταν το φορτίο χθες το πρωί;», κ.λπ.). Για αυτό μπορείτε να χρησιμοποιήσετε Προμηθέας, DataDog και άλλα εργαλεία. Λαμβάνουν απλώς μετρήσεις από τον διακομιστή μετρήσεων και τις αποθηκεύουν και ο χρήστης μπορεί να τις ρωτήσει και να τις σχεδιάσει ανάλογα.

VerticalPodAutoscaler позволяет αυτοματοποιήστε αυτή η διαδικασία. Παρακολουθεί το ιστορικό χρήσης της CPU και της μνήμης και θέτει νέα αιτήματα και όρια με βάση αυτές τις πληροφορίες.

Η αποτελεσματική χρήση της υπολογιστικής ισχύος δεν είναι εύκολη υπόθεση. Είναι σαν να παίζεις Tetris όλη την ώρα. Εάν πληρώνετε πάρα πολλά για υπολογιστική ισχύ με χαμηλή μέση κατανάλωση (ας πούμε ~10%), συνιστούμε να δείτε προϊόντα που βασίζονται στο AWS Fargate ή στο Virtual Kubelet. Είναι κατασκευασμένα σε ένα μοντέλο χρέωσης χωρίς διακομιστή/πληρωμή ανά χρήση, το οποίο μπορεί να αποδειχθεί φθηνότερο σε τέτοιες συνθήκες.

2. Ανιχνευτές ζωντάνιας και ετοιμότητας

Από προεπιλογή, οι έλεγχοι ζωντανότητας και ετοιμότητας δεν είναι ενεργοποιημένοι στο Kubernetes. Και μερικές φορές ξεχνούν να τα ανάψουν...

Αλλά πώς αλλιώς μπορείτε να ξεκινήσετε μια επανεκκίνηση της υπηρεσίας σε περίπτωση θανατηφόρου σφάλματος; Και πώς γνωρίζει ο εξισορροπητής φορτίου ότι ένα pod είναι έτοιμο να δεχθεί κίνηση; Ή ότι μπορεί να χειριστεί περισσότερη κίνηση;

Αυτές οι δοκιμές συχνά συγχέονται μεταξύ τους:

• Ζωτικότητα — Έλεγχος «επιβίωσης», ο οποίος επανεκκινεί το pod εάν αποτύχει.
• Ετοιμότητα — έλεγχος ετοιμότητας, εάν αποτύχει, αποσυνδέει το pod από την υπηρεσία Kubernetes (αυτό μπορεί να ελεγχθεί χρησιμοποιώντας kubectl get endpoints) και η κυκλοφορία δεν φτάνει σε αυτό μέχρι να ολοκληρωθεί με επιτυχία ο επόμενος έλεγχος.

Και οι δύο αυτοί έλεγχοι ΠΡΑΓΜΑΤΟΠΟΙΗΘΗΚΕ ΚΑΤΑ ΟΛΟΚΛΗΡΟ ΤΟΝ ΚΥΚΛΟ ΖΩΗΣ ΤΟΥ POD. Είναι πολύ σημαντικό.

Μια κοινή παρανόηση είναι ότι οι ανιχνευτές ετοιμότητας εκτελούνται μόνο κατά την εκκίνηση, έτσι ώστε ο εξισορροπητής να μπορεί να γνωρίζει ότι το pod είναι έτοιμο (Ready) και μπορεί να ξεκινήσει την επεξεργασία της κυκλοφορίας. Ωστόσο, αυτή είναι μόνο μία από τις επιλογές για τη χρήση τους.

Ένα άλλο είναι η πιθανότητα να ανακαλύψετε ότι η κίνηση στο pod είναι υπερβολική και το υπερφορτώνει (ή το pod εκτελεί υπολογισμούς με ένταση πόρων). Σε αυτή την περίπτωση βοηθάει ο έλεγχος ετοιμότητας μειώστε το φορτίο στο λοβό και «ψύξτε» το. Η επιτυχής ολοκλήρωση ενός ελέγχου ετοιμότητας στο μέλλον επιτρέπει αυξήστε ξανά το φορτίο στο λοβό. Σε αυτήν την περίπτωση (αν αποτύχει η δοκιμή ετοιμότητας), η αποτυχία της δοκιμής ζωντάνιας θα ήταν πολύ αντιπαραγωγική. Γιατί να επανεκκινήσετε ένα pod που είναι υγιές και εργάζεται σκληρά;

Επομένως, σε ορισμένες περιπτώσεις, δεν είναι καθόλου καλύτεροι έλεγχοι από την ενεργοποίησή τους με εσφαλμένα διαμορφωμένες παραμέτρους. Όπως αναφέρθηκε παραπάνω, εάν ο έλεγχος ζωντάνιας αντιγράφει έλεγχος ετοιμότητας, τότε είστε σε μεγάλο πρόβλημα. Πιθανή επιλογή είναι η διαμόρφωση μόνο δοκιμή ετοιμότηταςΚαι επικίνδυνη ζωντάνια αφήστε στην άκρη.

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

3. LoadBalancer για κάθε υπηρεσία HTTP

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

Εάν ανοίξετε την υπηρεσία ως type: LoadBalancer, ο ελεγκτής του (ανάλογα με τον πάροχο υπηρεσιών) θα παρέχει και θα διαπραγματευτεί ένα εξωτερικό LoadBalancer (δεν εκτελείται απαραίτητα στο L7, αλλά μάλλον ακόμη και στο L4) και αυτό μπορεί να επηρεάσει το κόστος (εξωτερική στατική διεύθυνση IPv4, υπολογιστική ισχύς, χρέωση ανά δευτερόλεπτο ) λόγω της ανάγκης δημιουργίας μεγάλου αριθμού τέτοιων πόρων.

Σε αυτή την περίπτωση, είναι πολύ πιο λογικό να χρησιμοποιείτε έναν εξωτερικό εξισορροπητή φορτίου, ανοίγοντας υπηρεσίες όπως type: NodePort. Ή καλύτερα, επεκτείνετε κάτι παρόμοιο nginx-ingress-controller (ή traefik), που θα είναι ο μόνος NodePort τελικό σημείο που σχετίζεται με τον εξωτερικό εξισορροπητή φορτίου και θα δρομολογεί την κυκλοφορία στο σύμπλεγμα χρησιμοποιώντας είσοδος-Πόροι Kubernetes.

Άλλες (μικρο)υπηρεσίες εντός συμπλέγματος που αλληλεπιδρούν μεταξύ τους μπορούν να «επικοινωνούν» χρησιμοποιώντας υπηρεσίες όπως ClusterIP και έναν ενσωματωμένο μηχανισμό εντοπισμού υπηρεσιών μέσω DNS. Απλώς μην χρησιμοποιείτε το δημόσιο DNS/IP τους, καθώς αυτό μπορεί να επηρεάσει την καθυστέρηση και να αυξήσει το κόστος των υπηρεσιών cloud.

4. Αυτόματη κλιμάκωση ενός συμπλέγματος χωρίς να λαμβάνονται υπόψη τα χαρακτηριστικά του

Όταν προσθέτετε κόμβους και τους αφαιρείτε από ένα σύμπλεγμα, δεν θα πρέπει να βασίζεστε σε ορισμένες βασικές μετρήσεις, όπως η χρήση της CPU σε αυτούς τους κόμβους. Ο σχεδιασμός του pod πρέπει να λαμβάνει υπόψη πολλά περιορισμένο, όπως συγγένεια λοβών/κόμβων, κηλίδες και ανοχές, αιτήματα πόρων, QoS κ.λπ. Η χρήση ενός εξωτερικού αυτόματου κλιμακωτή που δεν λαμβάνει υπόψη αυτές τις αποχρώσεις μπορεί να οδηγήσει σε προβλήματα.

Φανταστείτε ότι ένα συγκεκριμένο pod θα πρέπει να προγραμματιστεί, αλλά όλη η διαθέσιμη ισχύς CPU ζητείται/αποσυναρμολογείται και το pod κολλάει σε κατάσταση Pending. Η εξωτερική αυτόματη κλιμάκωση βλέπει το μέσο τρέχον φορτίο της CPU (όχι το ζητούμενο) και δεν εκκινεί την επέκταση (κλιμάκωση) - δεν προσθέτει άλλον κόμβο. Ως αποτέλεσμα, αυτή η ομάδα διαφημίσεων δεν θα προγραμματιστεί.

Σε αυτή την περίπτωση, αντίστροφη κλιμάκωση (κλιμάκωση) — η αφαίρεση ενός κόμβου από ένα σύμπλεγμα είναι πάντα πιο δύσκολη στην υλοποίηση. Φανταστείτε ότι έχετε ένα κρατικό pod (με συνδεδεμένο μόνιμη αποθήκευση). Επίμονοι όγκοι συνήθως ανήκουν σε συγκεκριμένη ζώνη διαθεσιμότητας και δεν αναπαράγονται στην περιοχή. Έτσι, εάν ένας εξωτερικός αυτόματος διαβαθμιστής διαγράψει έναν κόμβο με αυτό το pod, ο προγραμματιστής δεν θα μπορεί να προγραμματίσει αυτό το pod σε άλλο κόμβο, καθώς αυτό μπορεί να γίνει μόνο στη ζώνη διαθεσιμότητας όπου βρίσκεται η μόνιμη αποθήκευση. Το Pod θα είναι κολλημένο στην κατάσταση Pending.

Πολύ δημοφιλές στην κοινότητα Kubernetes cluster-autoscaler. Λειτουργεί σε ένα σύμπλεγμα, υποστηρίζει API από μεγάλους παρόχους cloud, λαμβάνει υπόψη όλους τους περιορισμούς και μπορεί να κλιμακωθεί στις παραπάνω περιπτώσεις. Είναι επίσης σε θέση να κλιμακωθεί διατηρώντας όλα τα καθορισμένα όρια, εξοικονομώντας έτσι χρήματα (τα οποία διαφορετικά θα δαπανώνται σε αχρησιμοποίητη χωρητικότητα).

5. Παραμέληση των δυνατοτήτων IAM/RBAC

Προσοχή στη χρήση χρηστών IAM με επίμονα μυστικά για μηχανές και εφαρμογές. Οργανώστε την προσωρινή πρόσβαση χρησιμοποιώντας ρόλους και λογαριασμούς υπηρεσιών (λογαριασμοί υπηρεσίας).

Συχνά συναντάμε το γεγονός ότι τα κλειδιά πρόσβασης (και τα μυστικά) είναι κωδικοποιημένα στη διαμόρφωση της εφαρμογής, καθώς και να παραμελείται η εναλλαγή των μυστικών παρά την πρόσβαση στο Cloud IAM. Χρησιμοποιήστε ρόλους και λογαριασμούς υπηρεσιών IAM αντί για χρήστες όπου χρειάζεται.

Ξεχάστε το kube2iam και μεταβείτε κατευθείαν στους ρόλους IAM για λογαριασμούς υπηρεσιών (όπως περιγράφεται στο ομώνυμο σημείωμα Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

Ένας σχολιασμός. Όχι τόσο δύσκολο, σωστά;

Επίσης, μην παραχωρείτε δικαιώματα σε λογαριασμούς υπηρεσιών και προφίλ παρουσίας admin и cluster-adminαν δεν το χρειάζονται. Αυτό είναι λίγο πιο δύσκολο να εφαρμοστεί, ειδικά στα RBAC K8, αλλά σίγουρα αξίζει τον κόπο.

6. Μην βασίζεστε στην αυτόματη αντισυγγένεια για λοβούς

Φανταστείτε ότι έχετε τρία αντίγραφα κάποιας ανάπτυξης σε έναν κόμβο. Ο κόμβος πέφτει, και μαζί του όλα τα αντίγραφα. Δυσάρεστη κατάσταση, σωστά; Αλλά γιατί όλα τα αντίγραφα ήταν στον ίδιο κόμβο; Δεν υποτίθεται ότι η Kubernetes παρέχει υψηλή διαθεσιμότητα (HA);!

Δυστυχώς, ο προγραμματιστής Kubernetes, με δική του πρωτοβουλία, δεν συμμορφώνεται με τους κανόνες της ξεχωριστής ύπαρξης (αντι-συγγένεια) για λοβούς. Πρέπει να αναφέρονται ρητά:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

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

Εδώ μιλάμε για podAntiAffinity σε διαφορετικούς κόμβους: topologyKey: "kubernetes.io/hostname", - και όχι για διαφορετικές ζώνες διαθεσιμότητας. Για να εφαρμόσετε ένα πλήρες HA, θα πρέπει να εμβαθύνετε σε αυτό το θέμα.

7. Παράβλεψη PodDisruptionBudgets

Φανταστείτε ότι έχετε ένα φόρτο παραγωγής σε ένα σύμπλεγμα Kubernetes. Περιοδικά, οι κόμβοι και το ίδιο το σύμπλεγμα πρέπει να ενημερώνονται (ή να παροπλίζονται). Το PodDisruptionBudget (PDB) είναι κάτι σαν μια συμφωνία εγγύησης υπηρεσίας μεταξύ διαχειριστών συμπλέγματος και χρηστών.

Το PDB σάς επιτρέπει να αποφεύγετε διακοπές της υπηρεσίας που προκαλούνται από έλλειψη κόμβων:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Σε αυτό το παράδειγμα, εσείς, ως χρήστης του συμπλέγματος, δηλώνετε στους διαχειριστές: "Γεια, έχω μια υπηρεσία zookeeper και ό,τι κι αν κάνετε, θα ήθελα να έχω πάντα διαθέσιμα τουλάχιστον 2 αντίγραφα αυτής της υπηρεσίας."

Μπορείτε να διαβάσετε περισσότερα για αυτό εδώ.

8. Πολλαπλοί χρήστες ή περιβάλλοντα σε ένα κοινό σύμπλεγμα

Χώροι ονομάτων Kubernetes (χώροι ονομάτων) δεν παρέχουν ισχυρή μόνωση.

Μια κοινή παρανόηση είναι ότι εάν αναπτύξετε ένα φορτίο χωρίς παραγωγή σε έναν χώρο ονομάτων και ένα φορτίο παραγωγής σε έναν άλλο, τότε δεν θα επηρεάσει ο ένας τον άλλον με κανέναν τρόπο... Ωστόσο, ένα ορισμένο επίπεδο απομόνωσης μπορεί να επιτευχθεί χρησιμοποιώντας αιτήματα/περιορισμούς πόρων, ορίζοντας ποσοστώσεις και τάξεις προτεραιότητας. Κάποια «φυσική» απομόνωση στο επίπεδο δεδομένων παρέχεται από συγγένειες, ανοχές, κηλίδες (ή κόμβους), αλλά αυτός ο διαχωρισμός είναι αρκετά δύσκολο υλοποιώ, εφαρμόζω.

Όσοι πρέπει να συνδυάσουν και τους δύο τύπους φόρτου εργασίας στο ίδιο σύμπλεγμα θα πρέπει να αντιμετωπίσουν την πολυπλοκότητα. Εάν δεν υπάρχει τέτοια ανάγκη, και μπορείτε να αντέξετε οικονομικά να έχετε ένα ένα ακόμη σύμπλεγμα (ας πούμε, σε ένα δημόσιο σύννεφο), τότε είναι καλύτερα να το κάνετε. Αυτό θα επιτύχει πολύ υψηλότερο επίπεδο μόνωσης.

9. εξωτερική πολιτική κυκλοφορίας: Σύμπλεγμα

Πολύ συχνά βλέπουμε ότι όλη η κίνηση μέσα στο σύμπλεγμα έρχεται μέσω μιας υπηρεσίας όπως το NodePort, για την οποία έχει οριστεί η προεπιλεγμένη πολιτική externalTrafficPolicy: Cluster... Σημαίνει ότι NodePort είναι ανοιχτός σε κάθε κόμβο του συμπλέγματος και μπορείτε να χρησιμοποιήσετε οποιονδήποτε από αυτούς για να αλληλεπιδράσετε με την επιθυμητή υπηρεσία (σύνολο λοβών).

Ταυτόχρονα, τα πραγματικά pods που σχετίζονται με την προαναφερθείσα υπηρεσία NodePort είναι συνήθως διαθέσιμα μόνο σε συγκεκριμένο υποσύνολο αυτών των κόμβων. Με άλλα λόγια, εάν συνδεθώ σε έναν κόμβο που δεν έχει το απαιτούμενο pod, θα προωθήσει την κυκλοφορία σε έναν άλλο κόμβο, προσθέτοντας ένα λυκίσκο και αυξανόμενη καθυστέρηση (εάν οι κόμβοι βρίσκονται σε διαφορετικές ζώνες διαθεσιμότητας/κέντρα δεδομένων, η καθυστέρηση μπορεί να είναι αρκετά υψηλή· επιπλέον, το κόστος κυκλοφορίας εξόδου θα αυξηθεί).

Από την άλλη πλευρά, εάν μια συγκεκριμένη υπηρεσία Kubernetes έχει ένα σύνολο πολιτικής externalTrafficPolicy: Local, τότε το NodePort ανοίγει μόνο σε εκείνους τους κόμβους όπου εκτελούνται πραγματικά τα απαιτούμενα pod. Όταν χρησιμοποιείτε εξωτερικό εξισορροπητή φορτίου που ελέγχει την κατάσταση (υγειονομικός έλεγχος) τελικά σημεία (πώς γίνεται AWS ELB), Αυτός θα στείλει κίνηση μόνο στους απαραίτητους κόμβους, που θα έχει ευεργετική επίδραση στις καθυστερήσεις, στις υπολογιστικές ανάγκες, στους λογαριασμούς εξόδου (και η κοινή λογική υπαγορεύει το ίδιο).

Υπάρχει μεγάλη πιθανότητα να χρησιμοποιείτε ήδη κάτι παρόμοιο traefik ή nginx-ingress-controller ως τελικό σημείο NodePort (ή LoadBalancer, το οποίο χρησιμοποιεί επίσης το NodePort) για τη δρομολόγηση της εισερχόμενης κίνησης HTTP και η ρύθμιση αυτής της επιλογής μπορεί να μειώσει σημαντικά τον λανθάνοντα χρόνο για τέτοια αιτήματα.

В αυτήν την έκδοση Μπορείτε να μάθετε περισσότερα σχετικά με την εξωτερική πολιτική κυκλοφορίας, τα πλεονεκτήματα και τα μειονεκτήματά της.

10. Μην δεσμεύεστε με συστάδες και μην κάνετε κατάχρηση του επιπέδου ελέγχου

Προηγουμένως, ήταν σύνηθες να καλούνται οι διακομιστές με τα κατάλληλα ονόματα: Anton, HAL9000 και Colossus... Σήμερα έχουν αντικατασταθεί από τυχαία δημιουργημένα αναγνωριστικά. Ωστόσο, η συνήθεια παρέμεινε, και τώρα τα σωστά ονόματα πηγαίνουν σε συστάδες.

Μια τυπική ιστορία (βασισμένη σε πραγματικά γεγονότα): όλα ξεκίνησαν με μια απόδειξη της ιδέας, έτσι το σύμπλεγμα είχε ένα περήφανο όνομα δοκιμών… Πέρασαν χρόνια και χρησιμοποιείται ΑΚΟΜΑ στην παραγωγή, και όλοι φοβούνται να το αγγίξουν.

Δεν υπάρχει τίποτα διασκεδαστικό όταν τα συμπλέγματα μετατρέπονται σε κατοικίδια, γι' αυτό συνιστούμε να τα αφαιρείτε περιοδικά κατά την εξάσκηση αποκατάστασης καταστροφών (αυτό θα βοηθήσει μηχανική χάους - περίπου μετάφρ.). Επιπλέον, δεν θα ήταν κακό να εργαστείτε στο επίπεδο ελέγχου (επίπεδο ελέγχου). Το να φοβάσαι να τον αγγίξεις δεν είναι καλό σημάδι. κ.λπ νεκρός? Παιδιά, είστε πραγματικά σε μπελάδες!

Από την άλλη, δεν πρέπει να παρασυρθείς με τη χειραγώγησή του. Με τον καιρό το επίπεδο ελέγχου μπορεί να γίνει αργό. Πιθανότατα, αυτό οφείλεται στο ότι δημιουργείται ένας μεγάλος αριθμός αντικειμένων χωρίς την περιστροφή τους (μια συνηθισμένη κατάσταση όταν χρησιμοποιείται το Helm με προεπιλεγμένες ρυθμίσεις, γι' αυτό η κατάστασή του σε configmaps/secrets δεν ενημερώνεται - ως αποτέλεσμα, χιλιάδες αντικείμενα συσσωρεύονται σε το επίπεδο ελέγχου) ή με συνεχή επεξεργασία αντικειμένων kube-api (για αυτόματη κλιμάκωση, για CI/CD, για παρακολούθηση, αρχεία καταγραφής συμβάντων, ελεγκτές κ.λπ.).

Επιπλέον, συνιστούμε να ελέγξετε τις συμφωνίες SLA/SLO με τον διαχειριζόμενο πάροχο Kubernetes και να δώσετε προσοχή στις εγγυήσεις. Ο πωλητής μπορεί να εγγυηθεί διαθεσιμότητα επιπέδου ελέγχου (ή τα υποσυστατικά του), αλλά όχι την καθυστέρηση p99 των αιτημάτων που του στέλνετε. Με άλλα λόγια, μπορείτε να μπείτε kubectl get nodes, και λάβετε απάντηση μόνο μετά από 10 λεπτά και αυτό δεν θα αποτελεί παραβίαση των όρων της σύμβασης παροχής υπηρεσιών.

11. Μπόνους: χρήση της πιο πρόσφατης ετικέτας

Αλλά αυτό είναι ήδη ένα κλασικό. Τον τελευταίο καιρό συναντάμε αυτή την τεχνική λιγότερο συχνά, αφού πολλοί, έχοντας μάθει από πικρή εμπειρία, έχουν σταματήσει να χρησιμοποιούν την ετικέτα :latest και άρχισε να καρφιτσώνει εκδόσεις. Ζήτω!

Συλλογή διατηρεί το αμετάβλητο των ετικετών εικόνας; Σας συνιστούμε να εξοικειωθείτε με αυτό το αξιοσημείωτο χαρακτηριστικό.

Περίληψη

Μην περιμένετε ότι όλα θα λειτουργήσουν από τη μια μέρα στην άλλη: Το Kubernetes δεν είναι πανάκεια. Κακή εφαρμογή θα παραμείνει έτσι ακόμα και στο Kubernetes (και μάλλον θα χειροτερέψει). Η απροσεξία θα οδηγήσει σε υπερβολική πολυπλοκότητα, αργή και αγχωτική εργασία του στρώματος ελέγχου. Επιπλέον, κινδυνεύετε να μείνετε χωρίς στρατηγική αποκατάστασης καταστροφών. Μην περιμένετε από την Kubernetes να παρέχει απομόνωση και υψηλή διαθεσιμότητα εκτός συσκευασίας. Αφιερώστε λίγο χρόνο κάνοντας την εφαρμογή σας πραγματικά εγγενή στο cloud.

Μπορείτε να εξοικειωθείτε με τις ανεπιτυχείς εμπειρίες διαφόρων ομάδων αυτή η συλλογή ιστοριών από τον Χένινγκ Τζέικομπς.

Όσοι επιθυμούν να προσθέσουν στη λίστα σφαλμάτων που δίνονται σε αυτό το άρθρο μπορούν να επικοινωνήσουν μαζί μας στο Twitter (@MarekBartik, @MstrsObserver).

ΥΓ από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

• «Σχεδιασμός συμπλεγμάτων Kubernetes: πόσα πρέπει να υπάρχουν;"?
• «Το ABC of Security στο Kubernetes: Έλεγχος ταυτότητας, εξουσιοδότηση, έλεγχος"?
• «Αυτόματη κλιμάκωση και διαχείριση πόρων στο Kubernetes"(επισκόπηση και αναφορά βίντεο)
• «ConfigMaps στο Kubernetes: αποχρώσεις που αξίζει να γνωρίζετε».

Πηγή: www.habr.com