Cluster, k8s, docker, lxd, Rpi4 και Laptop. Τι να χρησιμοποιήσω και πως;

Συνέχιση της συζήτησης από το GNU/Linux & Developer Laptop ;:

Η τελευταία τοποθέτηση:

Ευχαριστώ πολύ @drpaneas για τις κατευθύνσεις τις οδηγίες, της πηγές, τις προϋποθέσεις, τις λύσεις και τις προτάσεις σου.
Και τον χρόνο σου βέβαια.
Είναι μεγάλο το πλεονέκτημα όσων συμμετέχουμε σε ψηφιακές κοινότητες.
Παίρνουμε απαντήσεις από ανθρώπους που εργάζονται στο αντικείμενο που
μας ενδιαφέρει.
Απαντήσεις τις οποίες αν επιδιώκαμε να ανακαλύψουμε μόνοι μας μπορεί και
να τα κάναμε θάλασσα μιας και μιλάμε για υποδομές.
Για παράδειγμα είχα την εντύπωση ότι το LXD χρησιμοποιείται περισσότερο.
Παίζει κάποιο ρόλο σ’ αυτό η snap εγκατάσταση;
Όσον αφορά το δύσκολο κομμάτι του εγχειρήματος για να το κατανοήσω
θα πρέπει να κάνω πρώτα τα μαθήματα.
Για το υψηλό κόστος του εξοπλισμού, ευτυχώς υπάρχουν τα Rpi4, αλλά και μεταχειρισμένα ίσως.
Ποιο μηχάνημα του cluster πρέπει να είναι πιο δυνατό όσον αφορά στους ρόλους;
Χρησιμοποιούνται laptop στα cluster;

Για να διευκρινίσω περισσότερο το σκεπτικό πίσω από την ερώτηση:
Cluster (δεν ξέρω ποιος είναι ο σωστός όρος στα ελληνικά)
είναι δυνατόν να χτίσουμε ένα από αυτά με 1,2,3,4… RaspberryPi4, ή άλλες συσκευές, το οποίο θα ελέγχεται από laptop, για το σπίτι, την επιχείρηση, την κλινική, το σχολείο, την κοινότητα,… με πολλαπλασιαστική υπολογιστική ισχύ,
συνδιάζοντας τη διαλειτουργικότητα του Linux με τις τρέχουσες τεχνολογίες.

Μπορώ να χρησιμοποιήσω κάποια “βοήθεια” με γραφικό περιβάλλον;

Έχει αναφερθεί και ο @Kostas_Kostas σε παρόμοιο νήμα Rocks Cluster Distribution, αν δεν κάνω λάθος σε clusters “μηχανήματα” και εφαρμογές, απλά ήθελα να κάνω μία γενική αναφορά στο θέμα.
Το LXD το αναφέρω με αφορμή το παρακάτω άρθρο για το συνδυασμό των δύο κόσμων του Docker και του LXD:
http://www.makikiweb.com/Pi/lxc_on_the_pi.html

1 Like

Οι λόγοι που χρησιμοποιούν σήμερα kubernetes clusters δεν είναι η υπολογιστική ισχύ. Αυτό υπάρχει εδώ και καιρό (cloud). Η λογική σήμερα είναι να κατακερματίσουμε τις υπηρεσίες που παρέχουμε σε μικρότερα κομμάτια. πχ έστω ότι έχεις ένα e-shop, αυτό θέλει μία βάση δεδομένων, έναν webserver, authentication (αν έχεις login), καλάθι, τιμές, αναζήτηση, επαλήθευση πληρωμής (με διάφορους τρόπους). Το καθένα από αυτά μπορεί να αποτελεί ξεχωριστή οντότητα (προγραμματιστικά). Μάλιστα, γίνεται λόγος για ακόμα μεγαλύτερο κατακερματισμό αυτών, στις επημέρους λειτουργίες που επιτελούν (τις συναρτήσεις - Functions As A Service / Serverless).

Σε αυτό το νέο σκεπτικό, αλλάζει και ο ρόλος του administrator. Οταν χαλάει κάτι και δεν δουλεύει, δεν προσπαθεί να το φτιάξει, γιατί παίρνει περισσότερο χρόνο το debugging (να κατσει να βρεις τι φταίει και να το φτιάξεις), από το να το “σκοτώσεις” και να “σηκώσεις” ένα καινούριο. Μάλιστα, αν έχεις τις υπηρεσίες σου σύμφωνα με το Serverless μοντέλο, τότε γλυτώνεις και αρκετά χρήματα. Σκέψου ότι έχεις ένα website του οποίου ο server είναι … offline :P Και σηκώνεται μόνο όταν κάποιος επισκέπτεται το site. Το να σηκωθεί ένα webserver docker container παίρνει μερικά miliseconds, τα οποία δεν γίνονται αντιληπτά στους επισκέπτες. Συνεπώς και το μοντέλω χρέωσης του hosting γίνεται με βάση τα δευτερόλεπτα που λειτουργεί (online) η εκάστωτε υπηρεσία. Ενδεικτά η Κόκα Κόλα χρησιμοποιεί αυτό το μοντέλο για τα transcaction στα ψυγεία της. Το transactions για την αγορά μιας κοκα-κόλα γίνεται με serverless τρόπο, και έχουν γλυτώσει κάπου στα 75% του κόστους.

Τέλος πάντων, τα οφέλη είναι πολλά και μπορείς να τα βρεις αν ψάξεις και online – διαφορετικά θα γράψω σεντόνι :P

Σχετικά με τα LXD και το Docker: είναι δύο διαφορετικές προσεγγίσεις. Το Docker είναι αυτό που λέμε process container, ενώ το LXD (και άλλα, όπως πχ το systemd-nspaw) είναι OS container. Η φιλοσοφία του docker είναι να τρέχει μικρά processes, σαν αυτά που βλέπεις όταν δίνεις στο τερματικό:

ps aux

Ενώ το LXD και τα συναφή είναι για να σηκώσεις ένα ελαφρύτερο virtual machine, πχ ένα ubuntu. Για παράδειγμα μέσα σε ένα LXD container μπορείς να κάνεις reboot το ίδιο το container και να δεις το linux να μπουτάρει εκεί μέσα :P

Τέλος, πάμε στο Raspberry που ρώτησες. Δεν ξέρω την ελληνική ορολογία, αλλά μπορείς να σκεφτείς το cluster σαν σύμπλεγμα υπολογιστών που λειτουργούν μαζί. Συνήθως αποτελείται από:

  • master nodes
  • worker nodes

Τα master nodes είναι εκεί που βρίσκεται το “μυαλό” ας πούμε. Οι master nodes είναι υπεύθυνοι για να ξεκινάνε/σταματάνε containers, να μιλάνε σε διάφορες άλλες διεργασίες και να συντονίζουν την όλη κατάσταση. Για αυτό το λόγω θα πρέπει να μπορούν πάντα να πάρουν απόφαση για διάφορα ερωτήματα/προβλήματα που προκύπτουν: άρα πρέπει πάντα να έχεις μονό αριθμό master nodes: 1, 3, 5, 7 κλπ. Να μην υπάρχει περίπτωση ισοψηφίας δηλαδή, διαφορετικά το cluster σου δεν μπορεί να αποφασίσει, και είναι για πέταμα/νεκρό.

Τα worker nodes είναι εκεί που τρέχει το φορτίο, εκεί που τρέχουν τα προγράμματα που θες. Αν χαλάσει κάποιος worker node απλά τον πετάς και βάζεις καινούριο, δεν κάθεσαι να τον φτιάξεις. Σε αντίθεση, με τους master nodes πρέπει να προσέξεις – λόγω του προβλήματος της απόφασης που εξήγησα πιο πάνω. Επειδή οι worker nodes είναι αυτοί που τραβάνε το μεγαλύτερο ζόρι, συνήθως είναι μηχανήματα με καλύτερες προδιαγραφές (μνήμη, δίσκο, επεξεργαστή).

Τέλος, για να “μιλάς” και να διαχειρίζεσαι το cluster, μπορείς να το κάνεις από έναν άλλο υπολογιστή. Οποιος και να είναι, δεν παίζει ρόλο. Χρειάζεσαι έναν client και κάποια άλλα αρχεία για τo authentication (ποιος είσαι/χρήστης) και το authorization (τι μπορείς να κάνεις/δικαιώματα του χρήση σου). Βέβαια, μπορείς να διαχειριστής το cluster και από έναν master node, αλλά πρέπει να συνδεθείς σε αυτόν με κάποιο τρόπο (πχ ssh). Αυτό συμβαίνει γιατί στην ουσία ο client συνδέεται στον API Server που τρέχει στους master nodes. Αφού αυτοί είναι υπεύνοι να δίνουν διαταγές στο cluster, έχει νοήμα να μιλήσεις με αυτούς ;)

Μπορείς λοιπόν να στήσεις kubernetes cluster με Raspberry Pi θες να τα ρυθμίσεις ως εξής:
1 master node ή 3, ή 5 ή 7 κλπ
1 ή περισσότερους worker nodes
η διαχείριση τους μπορεί να γίνεται από ένα άλλο PC στο σπίτι.

Για το Raspberry έχεις δύο λύσεις:

  1. το k3s της Rancher (πχ διάβασε εδώ: https://blog.alexellis.io/self-hosting-kubernetes-on-your-raspberry-pi/). Αρκετά ελαφρύ, κάτι σαν Arch για kubernetes σκέψου.
  2. το kubeadm (ο επίσημος installer του kubernetes). Μπορείς να διαβάσεις το tutorial που έγραψε ένας συνάδελφός μου https://opensource.com/article/20/6/kubernetes-raspberry-pi

Πιθανώς να υπάρχουν κι άλλοι πιο “αυτόματοι” installers, αλλά θα σου πρότεινα να μείνεις μακρυά τους.

Για Raspberry θα πρότεινα να παίξεις με Raspberry 4 καθαρά για λόγους αρχιτεκτονικής (aarch64/arm64). Θα είναι και πιο εύκολο να βρεις docker images σε arm64 ;)

Γραφικά και ευκολία διαχείρισης με GUI
Αν θες κάτι σε γραφικό περιβάλλον τότε, φεύγουμε από το raspberry και πάμε σε cloud υπηρεσίες (AWS, Google, Azure – και RedHat OpenShift που παίζεις και στις 3). Εκεί πρέπει να πληρώσεις.

Αν δεν θες Raspberry Pi αλλά θες να το στήσεις σε κάποια virtual machines ή ακόμα και σταθερούς υπολογιστές, μπορείς να δοκιμάσεις το δωρεάν OpenShift που λέγεται OKD https://www.okd.io/

Πριν δοκιμάσεις να στήσεις openshift, μπορείς να πάρεις μία ιδέα από το interface του, στήνοντας ένα “δοκιμαστικό” cluster με ένα virtual machine. Στην ουσία θα είναι ταυτοχρονα ένας master και worker node. Αυτό το χρησιμοποιούμε για να κάνουμε testing: https://access.redhat.com/documentation/en-us/red_hat_codeready_containers/1.0/html/getting_started_guide/getting-started-with-codeready-containers_gsg απλά πρέπει να έχεις δυνατό PC.

ΥΣ: Το openshift θεωρείται η καλύτερη/ευκολότερη εμπειρία χρήσης kubernetes στην αγορά αυτή τη στιγμή.

6 Likes

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

2 Likes