<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-06-15 14:33 GMT-07:00 Andreas Polyrakis <span dir="ltr"><<a href="mailto:apolyr@noc.grnet.gr" target="_blank">apolyr@noc.grnet.gr</a>></span>:<br><span style="font-size:13.3333px;line-height:18.6667px">On 15/06/16 22:26, Kostas Zorbadelos wrote:</span><br style="font-size:13.3333px;line-height:18.6667px"><blockquote class="gmail_quote" style="font-size:13.3333px;line-height:18.6667px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Καλησπέρα,<br><br>γνωρίζω ότι στη λίστα μάλλον υπάρχουν σχετικοί άνθρωποι αυτό. Ενδιαφέρομαι να φτιάξω μια υποδομή για deployment docker containers. Θα το λέγαμε μάλλον ένα μικρό private cloud ή κάτι τέτοιο. Ο στόχος μου είναι η διαχείριση των containers και το config τους να είναι όσο αυτοματοποιημένο γίνεται, ώστε να είναι εύκολο σε μια ομάδα operations να φτιάξει ένα container ενός συγκεκριμένου τύπου (θα υπάρχουν 2-3 τύποι containers) και να το κάνει deploy σε ένα φυσικό μηχάνημα. Το μόνο που έχω στα χέρια μου είναι τα φυσικά μηχανήματα.<br><br>Προσανατολίζομαι στη χρήση Ansible (ή Vagrant που ακούσαμε πρόσφατα on-top of) έχοντας hardcoded σε inventory τα φυσικά μου μηχανήματα και το δικτυακό config τους. Έχει νόημα η δημιουργία ενός Openstack setup; Είναι αρκετά ώριμο αυτό ώστε να δημιουργηθεί από έναν άνθρωπο σε εύλογο χρονικό διάστημα; Έχετε άλλες προτάσεις;<br><br>Για όποιον έχει προτάσεις, μπορεί να επικοινωνήσει μαζί μου και off-list.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Κώστα,<br>
<br>
Αν μιλάμε για docker containers, έχω ακούσει καλά λόγια για το <a href="http://kubernetes.io/" rel="noreferrer" target="_blank">http://kubernetes.io/</a><br>
Ίσως κάποιος με περισσότερο συστεμικό προφίλ από εμένα να ήθελε να σχολιάσει.<br></blockquote><div><br></div><div>Το kubernetes δεν είναι και το πιο αξιόπιστο project για να βασιστεί κανείς πάνω του για long-term support, ή τουλάχιστον δεν ήταν μέχρι πολύ πρόσφατα. Ενώ έχει πολλές "αξιώσεις" σχετικά με το τι θα μπορεί να κάνει, κάποια στιγμή, στο απώτερο μέλλον, η πραγματικότητα είναι ότι είναι κάπως περίεργη η ιδέα που έχει ο κόσμος για το project.</div><div><br></div><div>Πολλοί νομίζουν ότι επειδή στο project δραστηριοποιούνται και μηχανικοί του Google ότι είναι το open source αντίγραφο του Borg<b>[1]</b>. </div><div><br></div><div>Αυτό δεν έχει καμία σχέση με την πραγματικότητα όμως:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- Το borg βασίζεται σε κλειστές, proprietary εφαρμογές και πλατφόρμες του Google.</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>- Το kubernetes είναι 100% open source.</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- Το borg μπορεί να τρέξει clusters με δεκάδες χιλιάδες μηχανήματα και εκατοντάδες χιλιάδες jobs.</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>- Το kubernetes έχει scaling problems όταν τρέχει clusters με 150 ή 200 μηχανήματα και περίπου 1000 jobs.</div><div><br></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- Το borg είναι γραμμένο 100% σε C++ για λόγους performance, και χρησιμοποιεί απευθείας πολλά core UNIX APIs & calls.</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- Το kubernetes είναι γραμμένο σε golang, με ό,τι αυτό συνεπάγεται.</div><div><br></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- Το borg έχει αποδείξει ότι μπορεί να κάνει σχεδόν τα πάντα για πάνω από μια δεκαετία σε τεράστιο scale.</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- Το kubernetes έβγαλε την έκδοση 1.0 πριν από σχεδόν ένα χρόνο κι ακόμα έχει bugs που σκοτώνουν τα docker containers όταν κάνει restart το "kubelet" σε κάθε node ενός cluster (see <a href="https://github.com/kubernetes/kubernetes/issues/27502">https://github.com/kubernetes/kubernetes/issues/27502</a>)</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>[1] <a href="http://research.google.com/pubs/pub43438.html">http://research.google.com/pubs/pub43438.html</a></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div> </div><div>Προσωπικά θα έμενα <i>όσο πιο μακριά γίνεται</i> από το kubernetes, για τους παραπάνω και <i>πολλούς</i> ακόμα λόγους.</div><div><br></div><div>Για να απαντήσω και στην αρχική ερώτηση όμως:</div><div><br></div><div>Ένα cluster management framework δεν αρκεί να έχει μόνο το docker για να είναι ολοκληρωμένο. Είναι πολλά τα μέρη ενός "συστήματος" που μπορεί να δεχτεί αιτήσεις για δημιουργία "jobs" και εκτέλεση αυτών.  Ποιά τεχνολογία θα μπορέσει να χρησιμοποιήσει κανείς για κάθε μέρος του συστήματος εξαρτάται πολύ από το σκοπό που έχει.</div><div><br></div><div>Ας πούμε μερικές από τις ερωτήσεις που έχω εγώ για τον Κώστα είναι:</div><div><br></div><div>1. Image building? Σε ενδιαφέρει να μπορεί οποιοσδήποτε να μπορεί να τρέχει οποιοδήποτε 'image' ή θα έχεις εσύ τον έλεγχο του "base image" για τα jobs που τρέχεις;</div><div><br></div><div>2. Security? Αν αφήνεις τον κόσμο να τρέχει οποιοδήποτε image και να ανοίγει ports από το εσωτερικό του container του προς τον έξω κόσμο, πώς σκέφτεσαι να αποφύγεις την πιθανότητα να τρέχει κάποιος ένα docker image που έχει μέσα το προπέρσινο OpenSSL library με το heartbleed και ότι αυτο συνεπάγεται;</div><div><br></div><div>3. Job Configuration? Ποιό "API" σκέφτεσαι να παρέχεις σε κάποιον για να ξεκινάει ένα 'job' που αποτελείται από N instances του ίδιου 'task' (image clone).</div><div><br></div><div>4. Scheduling? Θα χρησιμοποιείς κάποιο 'scheduler' για να κάνεις δυναμικό resource management και buddy-based allocation για 'tasks' που έχουν συμβατές απαιτήσεις σε πηγές (π.χ. ένα network-heavy image στο ίδιο μηχάνημα με ένα cpu-hungry batch job, κλπ)</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote">[ Σημαντική σημείωση: το scheduling & buddy based allocation δεν είναι καθόλου εύκολο πρόβλημα, ειδικά αν θέλεις να μπορείς να διαχειριστείς και spikes απαιτήσεων από ένα δυναμικά μεταβαλλόμενο αριθμό από jobs & sub-tasks. ]</div><div class="gmail_quote"><br></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div>5. Αν δεν χρησιμοποιείς scheduler θα δίνεις όλο το μηχάνημα σε ένα 'task/image';  Και τότε πως θα αποφύγεις να είναι πολύ under-utilized οι πόροι του κάθε physical machine ή VM;</div><div><br></div><div>6. Monitoring?  Αν παρέχεις σε άλλους τη δυνατότητα να τρέξουν τα δικά τους apps σε ένα δικό σου cluster, κάποια στιγμή θα πρέπει να τους δώσεις πρόσβαση σε monitoring APIs, tools & frameworks. Υπάρχουν πολλές επιλογές (π.χ. OpenTSDB για timeseries-based data, prometheus ή riemann για monitoring daemons, κλπ.)  Το πιο σημαντικό είναι το distributed service monitoring να μην είναι after-thought αλλά να είναι μέρος του συστήματος από την πρώτη στιγμή.</div><div><br></div><div>7. Alerting?  Πώς μπορώ να ρυθμίσω alerts; Με βάση timeseries & manipulation από timeseries; Σε τι μορφή; Πόση ώρα χρειάζεται για ένα alert config να ενεργοποιηθεί από τη στιγμή που το γράφω (αλλιώς γνωστό και ως "nagios master update latency == forever").</div><div><br></div><div>8. Service discovery?  Αν μπορώ να τρέξω 100 'tasks' που αποτελούν μέρος του service με όνομα "webserver", κάπως πρέπει να μπορώ να ρωτήσω το σύστημα για το ακριβές host:port location του κάθε service instance. Αυτό είναι άλλο ένα μέρος του συστήματος που μπορεί να έχει ή πολύ μικρό ή ατελείωτο complexity.  Κι εδώ υπάρχουν πολλές ενδιαφέρουσες επιλογές (π.χ. το fleet του CoreOS).</div><div><br></div><div>Όλα τα μέρη του συστήματος έχουν σημασία.  Κι όλα μπορεί να είναι από one-off χακιές μέχρι well-integrated μέρη ενός παζλ με συνοχή και λογική.</div><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Για να μην μακρηγορώ ατελείωτα όμως, Κώστα είναι πολύ ενδιαφέρον αυτό που θέλεις να κάνεις και πολύ φιλόδοξο.</div><div><br></div><div>Δεν έχω συγκεκριμένες προτάσεις για το κάθε μέρος του συστήματος που να παίζουν για όλες τις πιθανές περιπτώσεις, αλλά είμαι σίγουρα στη διάθεσή σου (ή οποιουδήποτε άλλου) για συζήτηση σχετικά με το θέμα.</div><div><br></div><div>Φιλικά,<br><br></div><div>Γιώργος</div><div><br></div><div><br></div><div><br></div><div><br></div></div>
</div></div>