[grnog] Docker infrastructure creation

[Giorgos Keramidas]

2016-06-15 14:33 GMT-07:00 Andreas Polyrakis <apolyr at noc.grnet.gr>:
On 15/06/16 22:26, Kostas Zorbadelos wrote:

> Καλησπέρα,
>
> γνωρίζω ότι στη λίστα μάλλον υπάρχουν σχετικοί άνθρωποι αυτό. Ενδιαφέρομαι
> να φτιάξω μια υποδομή για deployment docker containers. Θα το λέγαμε μάλλον
> ένα μικρό private cloud ή κάτι τέτοιο. Ο στόχος μου είναι η διαχείριση των
> containers και το config τους να είναι όσο αυτοματοποιημένο γίνεται, ώστε
> να είναι εύκολο σε μια ομάδα operations να φτιάξει ένα container ενός
> συγκεκριμένου τύπου (θα υπάρχουν 2-3 τύποι containers) και να το κάνει
> deploy σε ένα φυσικό μηχάνημα. Το μόνο που έχω στα χέρια μου είναι τα
> φυσικά μηχανήματα.
>
> Προσανατολίζομαι στη χρήση Ansible (ή Vagrant που ακούσαμε πρόσφατα on-top
> of) έχοντας hardcoded σε inventory τα φυσικά μου μηχανήματα και το δικτυακό
> config τους. Έχει νόημα η δημιουργία ενός Openstack setup; Είναι αρκετά
> ώριμο αυτό ώστε να δημιουργηθεί από έναν άνθρωπο σε εύλογο χρονικό
> διάστημα; Έχετε άλλες προτάσεις;
>
> Για όποιον έχει προτάσεις, μπορεί να επικοινωνήσει μαζί μου και off-list.
>


> Κώστα,
>
> Αν μιλάμε για docker containers, έχω ακούσει καλά λόγια για το
> http://kubernetes.io/
> Ίσως κάποιος με περισσότερο συστεμικό προφίλ από εμένα να ήθελε να
> σχολιάσει.
>

Το kubernetes δεν είναι και το πιο αξιόπιστο project για να βασιστεί κανείς
πάνω του για long-term support, ή τουλάχιστον δεν ήταν μέχρι πολύ πρόσφατα.
Ενώ έχει πολλές "αξιώσεις" σχετικά με το τι θα μπορεί να κάνει, κάποια
στιγμή, στο απώτερο μέλλον, η πραγματικότητα είναι ότι είναι κάπως περίεργη
η ιδέα που έχει ο κόσμος για το project.

Πολλοί νομίζουν ότι επειδή στο project δραστηριοποιούνται και μηχανικοί του
Google ότι είναι το open source αντίγραφο του Borg*[1]*.

Αυτό δεν έχει καμία σχέση με την πραγματικότητα όμως:

- Το borg βασίζεται σε κλειστές, proprietary εφαρμογές και πλατφόρμες του
Google.
- Το kubernetes είναι 100% open source.


- Το borg μπορεί να τρέξει clusters με δεκάδες χιλιάδες μηχανήματα και
εκατοντάδες χιλιάδες jobs.
- Το kubernetes έχει scaling problems όταν τρέχει clusters με 150 ή 200
μηχανήματα και περίπου 1000 jobs.

- Το borg είναι γραμμένο 100% σε C++ για λόγους performance, και
χρησιμοποιεί απευθείας πολλά core UNIX APIs & calls.

- Το kubernetes είναι γραμμένο σε golang, με ό,τι αυτό συνεπάγεται.

- Το borg έχει αποδείξει ότι μπορεί να κάνει σχεδόν τα πάντα για πάνω από
μια δεκαετία σε τεράστιο scale.

- Το kubernetes έβγαλε την έκδοση 1.0 πριν από σχεδόν ένα χρόνο κι ακόμα
έχει bugs που σκοτώνουν τα docker containers όταν κάνει restart το
"kubelet" σε κάθε node ενός cluster (see
https://github.com/kubernetes/kubernetes/issues/27502)


[1] http://research.google.com/pubs/pub43438.html


Προσωπικά θα έμενα *όσο πιο μακριά γίνεται* από το kubernetes, για τους
παραπάνω και *πολλούς* ακόμα λόγους.

Για να απαντήσω και στην αρχική ερώτηση όμως:

Ένα cluster management framework δεν αρκεί να έχει μόνο το docker για να
είναι ολοκληρωμένο. Είναι πολλά τα μέρη ενός "συστήματος" που μπορεί να
δεχτεί αιτήσεις για δημιουργία "jobs" και εκτέλεση αυτών.  Ποιά τεχνολογία
θα μπορέσει να χρησιμοποιήσει κανείς για κάθε μέρος του συστήματος
εξαρτάται πολύ από το σκοπό που έχει.

Ας πούμε μερικές από τις ερωτήσεις που έχω εγώ για τον Κώστα είναι:

1. Image building? Σε ενδιαφέρει να μπορεί οποιοσδήποτε να μπορεί να τρέχει
οποιοδήποτε 'image' ή θα έχεις εσύ τον έλεγχο του "base image" για τα jobs
που τρέχεις;

2. Security? Αν αφήνεις τον κόσμο να τρέχει οποιοδήποτε image και να
ανοίγει ports από το εσωτερικό του container του προς τον έξω κόσμο, πώς
σκέφτεσαι να αποφύγεις την πιθανότητα να τρέχει κάποιος ένα docker image
που έχει μέσα το προπέρσινο OpenSSL library με το heartbleed και ότι αυτο
συνεπάγεται;

3. Job Configuration? Ποιό "API" σκέφτεσαι να παρέχεις σε κάποιον για να
ξεκινάει ένα 'job' που αποτελείται από N instances του ίδιου 'task' (image
clone).

4. Scheduling? Θα χρησιμοποιείς κάποιο 'scheduler' για να κάνεις δυναμικό
resource management και buddy-based allocation για 'tasks' που έχουν
συμβατές απαιτήσεις σε πηγές (π.χ. ένα network-heavy image στο ίδιο
μηχάνημα με ένα cpu-hungry batch job, κλπ)

[ Σημαντική σημείωση: το scheduling & buddy based allocation δεν είναι
καθόλου εύκολο πρόβλημα, ειδικά αν θέλεις να μπορείς να διαχειριστείς και
spikes απαιτήσεων από ένα δυναμικά μεταβαλλόμενο αριθμό από jobs &
sub-tasks. ]

5. Αν δεν χρησιμοποιείς scheduler θα δίνεις όλο το μηχάνημα σε ένα
'task/image';  Και τότε πως θα αποφύγεις να είναι πολύ under-utilized οι
πόροι του κάθε physical machine ή VM;

6. Monitoring?  Αν παρέχεις σε άλλους τη δυνατότητα να τρέξουν τα δικά τους
apps σε ένα δικό σου cluster, κάποια στιγμή θα πρέπει να τους δώσεις
πρόσβαση σε monitoring APIs, tools & frameworks. Υπάρχουν πολλές επιλογές
(π.χ. OpenTSDB για timeseries-based data, prometheus ή riemann για
monitoring daemons, κλπ.)  Το πιο σημαντικό είναι το distributed service
monitoring να μην είναι after-thought αλλά να είναι μέρος του συστήματος
από την πρώτη στιγμή.

7. Alerting?  Πώς μπορώ να ρυθμίσω alerts; Με βάση timeseries &
manipulation από timeseries; Σε τι μορφή; Πόση ώρα χρειάζεται για ένα alert
config να ενεργοποιηθεί από τη στιγμή που το γράφω (αλλιώς γνωστό και ως
"nagios master update latency == forever").

8. Service discovery?  Αν μπορώ να τρέξω 100 'tasks' που αποτελούν μέρος
του service με όνομα "webserver", κάπως πρέπει να μπορώ να ρωτήσω το
σύστημα για το ακριβές host:port location του κάθε service instance. Αυτό
είναι άλλο ένα μέρος του συστήματος που μπορεί να έχει ή πολύ μικρό ή
ατελείωτο complexity.  Κι εδώ υπάρχουν πολλές ενδιαφέρουσες επιλογές (π.χ.
το fleet του CoreOS).

Όλα τα μέρη του συστήματος έχουν σημασία.  Κι όλα μπορεί να είναι από
one-off χακιές μέχρι well-integrated μέρη ενός παζλ με συνοχή και λογική.

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

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

Φιλικά,

Γιώργος
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nogalliance.org/pipermail/grnog-members/attachments/20160615/db4a7ef8/attachment.html>