Πώς να συνδέσετε συμπλέγματα Kubernetes σε διαφορετικά κέντρα δεδομένων

Καλώς ορίσατε στη σειρά Γρήγορης Εκκίνησης Kubernetes. Αυτή είναι μια κανονική στήλη με τις πιο ενδιαφέρουσες ερωτήσεις που λαμβάνουμε στο διαδίκτυο και στις προπονήσεις μας. Απαντάει ο ειδικός της Kubernetes.

Ο σημερινός ειδικός είναι ο Daniel Polenchik (Ντανιέλε Πολέντσιτς). Ο Daniel εργάζεται ως εκπαιδευτής και προγραμματιστής λογισμικού στο Learnk8s.

Αν θέλετε απάντηση στην ερώτησή σας στην επόμενη ανάρτηση, επικοινωνήστε μαζί μας μέσω email ή Twitter: @learnk8s.

Χάσατε προηγούμενες αναρτήσεις; Αναζητήστε τα εδώ.

Πώς να συνδέσετε συμπλέγματα Kubernetes σε διαφορετικά κέντρα δεδομένων;

Εν συντομία: Το Kubefed v2 έρχεται σύντομα, και σας συμβουλεύω επίσης να διαβάσετε σχετικά Φορτωτής и έργο πολλαπλών συστάδων-προγραμματιστή.

Πολύ συχνά, η υποδομή αναπαράγεται και κατανέμεται σε διαφορετικές περιοχές, ειδικά σε ελεγχόμενα περιβάλλοντα.

Εάν μια περιοχή δεν είναι διαθέσιμη, η κυκλοφορία ανακατευθύνεται σε άλλη για να αποφευχθούν διακοπές.

Με το Kubernetes, μπορείτε να χρησιμοποιήσετε παρόμοια στρατηγική και να διανείμετε φόρτους εργασίας σε διαφορετικές περιοχές.

Μπορείτε να έχετε ένα ή περισσότερα συμπλέγματα ανά ομάδα, περιοχή, περιβάλλον ή συνδυασμό αυτών.

Τα συμπλέγματά σας μπορούν να φιλοξενηθούν σε πολλά σύννεφα και σε εγκαταστάσεις.

Πώς όμως να προγραμματιστεί η υποδομή για μια τέτοια γεωγραφική εξάπλωση;
Χρειάζεται να δημιουργήσετε ένα μεγάλο σύμπλεγμα για πολλά περιβάλλοντα cloud σε ένα μόνο δίκτυο;
Ή έχετε πολλά μικρά συμπλέγματα και βρείτε έναν τρόπο να τα ελέγξετε και να τα συγχρονίσετε;

Μία ηγετική ομάδα

Η δημιουργία ενός συμπλέγματος σε ένα μόνο δίκτυο δεν είναι τόσο εύκολη.

Φανταστείτε ότι έχετε ένα ατύχημα, η σύνδεση μεταξύ των τμημάτων συμπλέγματος χάνεται.

Εάν έχετε έναν κύριο διακομιστή, οι μισοί πόροι δεν θα μπορούν να λάβουν νέες εντολές επειδή δεν θα μπορούν να επικοινωνήσουν με τον κύριο διακομιστή.

Και ταυτόχρονα έχετε παλιούς πίνακες δρομολόγησης (kube-proxy δεν είναι δυνατή η λήψη νέων) και κανένα πρόσθετο pod (η kubelet δεν μπορεί να ζητήσει ενημερώσεις).

Ακόμη χειρότερα, εάν το Kubernetes δεν μπορεί να δει έναν κόμβο, τον επισημαίνει ως ορφανό και διανέμει τα pods που λείπουν στους υπάρχοντες κόμβους.

Ως αποτέλεσμα, έχετε διπλάσιο αριθμό λοβών.

Εάν δημιουργήσετε έναν κύριο διακομιστή ανά περιοχή, θα υπάρξουν προβλήματα με τον αλγόριθμο συναίνεσης στη βάση δεδομένων etcd. (περίπου. εκδ. - Στην πραγματικότητα, η βάση δεδομένων etcd δεν χρειάζεται να βρίσκεται στους κύριους διακομιστές. Μπορεί να εκτελεστεί σε ξεχωριστή ομάδα διακομιστών στην ίδια περιοχή. Ωστόσο, έχοντας λάβει ταυτόχρονα ένα σημείο αποτυχίας ενός cluster. Αλλά γρήγορα.)

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

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

Ο διαχειριστής ελεγκτή χρειάζεται περισσότερο χρόνο για να μάθει για την αλλαγή και να γράψει την απάντηση στη βάση δεδομένων.

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

etcd είναι τόσο ευαίσθητο σε καθυστέρηση που η επίσημη τεκμηρίωση συνιστά τη χρήση SSD αντί για κανονικούς σκληρούς δίσκους.

Επί του παρόντος δεν υπάρχουν καλά παραδείγματα μεγάλου δικτύου για ένα μόνο σύμπλεγμα.

Βασικά, η κοινότητα προγραμματιστών και η ομάδα SIG-cluster προσπαθούν να καταλάβουν πώς να ενορχηστρώνουν τα συμπλέγματα με τον ίδιο τρόπο που ο Kubernetes ενορχηστρώνει τα κοντέινερ.

Επιλογή 1: ομοσπονδιακές ομάδες με kubefed

Επίσημη απάντηση από το SIG-cluster - kubefed2, μια νέα έκδοση του αρχικού πελάτη και χειριστή της ομοσπονδίας kube.

Για πρώτη φορά, προσπαθήσαμε να διαχειριστούμε μια συλλογή συμπλεγμάτων ως μεμονωμένο αντικείμενο χρησιμοποιώντας το εργαλείο ομοσπονδίας kube.

Η αρχή ήταν καλή, αλλά στο τέλος, η ομοσπονδία kube δεν έγινε δημοφιλής, επειδή δεν υποστήριζε όλους τους πόρους.

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

Φανταστείτε πώς μπορείτε να περιγράψετε τη διαίρεση των αντιγράφων για κάθε σύμπλεγμα σε μια ομοσπονδία χρησιμοποιώντας έναν μόνο σχολιασμό.

Αποδείχθηκε ότι ήταν ένα πλήρες χάος.

Το SIG-cluster έκανε εξαιρετική δουλειά μετά το kubefed v1 και αποφάσισε να προσεγγίσει το πρόβλημα από διαφορετική οπτική γωνία.

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

Για κάθε πόρο που θα συνενωθεί, έχετε έναν προσαρμοσμένο ορισμό CRD σε τρεις ενότητες:

• έναν τυπικό ορισμό ενός πόρου, όπως η ανάπτυξη·
• τμήμα placement, όπου ορίζετε πώς θα διανεμηθεί ο πόρος στην ομοσπονδία.
• τμήμα override, όπου για έναν συγκεκριμένο πόρο μπορείτε να παρακάμψετε το βάρος και τις παραμέτρους από την τοποθέτηση.

Ακολουθεί ένα παράδειγμα ομαδικής παράδοσης με ενότητες τοποθέτησης και παράκαμψης.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

Όπως μπορείτε να δείτε, η προσφορά χωρίζεται σε δύο ομάδες: cluster1 и cluster2.

Το πρώτο σύμπλεγμα παρέχει τρία αντίγραφα και το δεύτερο έχει τιμή 5.

Εάν χρειάζεστε περισσότερο έλεγχο στον αριθμό των αντιγράφων, το kubefed2 παρέχει ένα νέο αντικείμενο ReplicaSchedulingPreference όπου μπορούν να σταθμιστούν τα αντίγραφα:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

Η δομή CRD και το API δεν είναι ακόμη έτοιμα και η ενεργή εργασία βρίσκεται σε εξέλιξη στο επίσημο αποθετήριο του έργου.

Προσέξτε το kubefed2, αλλά έχετε κατά νου ότι δεν είναι ακόμα αρκετά καλό για περιβάλλον παραγωγής.

Μάθετε περισσότερα για το kubefed2 από επίσημο άρθρο για το kubefed2 στο ιστολόγιο Kubernetes και επίσημο αποθετήριο του έργου kubefed.

Επιλογή 2: Ομαδοποίηση στυλ Booking.com

Οι προγραμματιστές της Booking.com δεν ασχολήθηκαν με το kubefed v2, αλλά κατέληξαν στο Shipper, έναν χειριστή για παράδοση σε πολλαπλά cluster, πολλαπλές περιοχές και πολλά σύννεφα.

Φορτωτής κάπως παρόμοιο με το kubefed2.

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

Αλλά Η δουλειά του αποστολέα είναι να μειώσει τον κίνδυνο σφαλμάτων παράδοσης.

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

Όταν προωθείτε έναν πόρο σε ένα σύμπλεγμα, ο ελεγκτής Αποστολέας αναπτύσσει σταδιακά αυτήν την αλλαγή σε όλα τα ενοποιημένα συμπλέγματα.

Επίσης ο αποστολέας είναι πολύ περιορισμένος.

Για παράδειγμα, παίρνει ως είσοδο τα διαγράμματα Helm και δεν υποστηρίζει πόρους βανίλιας.
Σε γενικές γραμμές, ο Αποστολέας λειτουργεί ως εξής.

Αντί για μια τυπική διανομή, πρέπει να δημιουργήσετε έναν πόρο εφαρμογής που να περιλαμβάνει ένα γράφημα Helm:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Ο αποστολέας είναι μια καλή επιλογή για τη διαχείριση πολλαπλών συμπλεγμάτων, αλλά η στενή του σχέση με την Helm είναι μόνο εμπόδιο.

Τι κι αν μεταβούμε όλοι από το Helm στο προσαρμόστε ή capan?

Μάθετε περισσότερα για τον Shipper και τη φιλοσοφία του στο αυτό το επίσημο δελτίο τύπου.

Εάν θέλετε να εμβαθύνετε στον κώδικα, μεταβείτε στο επίσημο αποθετήριο του έργου.

Επιλογή 3: "μαγική" συγχώνευση συμπλέγματος

Το Kubefed v2 και ο Αποστολέας συνεργάζονται με την ομοσπονδία συμπλέγματος παρέχοντας νέους πόρους στα συμπλέγματα μέσω ενός προσαρμοσμένου ορισμού πόρων.

Τι γίνεται όμως αν δεν θέλετε να ξαναγράψετε όλα τα προμήθεια, StatefulSets, DaemonSets κ.λπ. που πρόκειται να συγχωνευθούν;

Πώς να συμπεριλάβετε ένα υπάρχον σύμπλεγμα στην ομοσπονδία χωρίς να αλλάξετε το YAML;

Το multi-cluster-scheduler είναι ένα έργο Admirality, το οποίο ασχολείται με τον προγραμματισμό φόρτου εργασίας σε συμπλέγματα.

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

Κάθε λοβό που δημιουργείται αντικαθίσταται αμέσως με ένα ομοίωμα.

χρήσεις πολλαπλών συστάδων-προγραμματιστή web hook για την τροποποίηση της πρόσβασηςγια να υποκλέψετε την κλήση και να δημιουργήσετε ένα αδρανές εικονικό pod.

Το αρχικό pod περνά από έναν άλλο κύκλο προγραμματισμού όπου, μετά από ψηφοφορία ολόκληρης της ομοσπονδίας, λαμβάνεται μια απόφαση φιλοξενίας.

Τέλος, το pod παραδίδεται στο σύμπλεγμα στόχο.

Ως αποτέλεσμα, έχετε ένα επιπλέον pod που δεν κάνει τίποτα, απλώς καταλαμβάνει χώρο.

Το πλεονέκτημα είναι ότι δεν χρειάζεται να γράψετε νέους πόρους για να συνδυάσετε προμήθειες.

Κάθε πόρος που δημιουργεί ένα pod είναι αυτόματα έτοιμος για συνένωση.

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

Όμως, ενώ ο Αποστολέας προσπαθεί κυρίως να μετριάσει τις επιπτώσεις των αποστολών, ο προγραμματισμός πολλαπλών συστάδων είναι πιο γενικός και ίσως πιο κατάλληλος για εργασίες παρτίδας.

Δεν διαθέτει προηγμένο μηχανισμό σταδιακής παράδοσης.

Περισσότερα για τον προγραμματιστή πολλαπλών συστάδων μπορείτε να βρείτε στη διεύθυνση επίσημη σελίδα αποθετηρίου.

Εάν θέλετε να διαβάσετε σχετικά με τον προγραμματισμό πολλαπλών συστάδων σε δράση, το Admiralty έχει ενδιαφέρουσα περίπτωση χρήσης με την Argo - ροές εργασιών, συμβάντα, CI και CD Kubernetes.

Άλλα εργαλεία και λύσεις

Η σύνδεση και η διαχείριση πολλαπλών συμπλεγμάτων είναι μια πολύπλοκη εργασία και δεν υπάρχει λύση που να ταιριάζει σε όλους.

Εάν θέλετε να μάθετε περισσότερα σχετικά με αυτό το θέμα, ακολουθούν ορισμένοι πόροι:

• Submariner της Rancher είναι ένα εργαλείο που συνδέει δίκτυα επικάλυψης διαφορετικών συμπλεγμάτων Kubernetes.
• Η αλυσίδα λιανικής Target χρησιμοποιεί Το Unimatrix σε συνδυασμό με το Spinnaker για να ενορχηστρώσει την ανάπτυξη σε πολλαπλά cluster.
• Δοκιμάστε να χρησιμοποιήσετε IPV6 και ενιαίο δίκτυο σε πολλές περιοχές.
• Μπορείτε να χρησιμοποιήσετε ένα πλέγμα υπηρεσιών, για παράδειγμα Istio για σύνδεση πολλαπλών συστάδων.
• Το Cilium, ένα πρόσθετο διεπαφής δικτύου κοντέινερ, προσφέρει λειτουργία πλέγματος συμπλέγματος, το οποίο σας επιτρέπει να συνδυάσετε πολλά συμπλέγματα

Αυτά για σήμερα

Σας ευχαριστώ που διαβάσατε μέχρι το τέλος!

Εάν γνωρίζετε πώς να συνδέσετε πιο αποτελεσματικά πολλαπλά συμπλέγματα, πες μας.

Θα προσθέσουμε τη μέθοδο σας στους συνδέσμους.

Ιδιαίτερες ευχαριστίες στον Chris Nesbitt-Smith (Κρις Νέσμπιτ-Σμιθ) και Vincent de Sme (Vincent De Smet) (στον μηχανικό αξιοπιστίας στο swatmobile.io) για να διαβάσετε το άρθρο και να μοιραστείτε χρήσιμες πληροφορίες σχετικά με τον τρόπο λειτουργίας της ομοσπονδίας.

Πηγή: www.habr.com